多くのサービスを連携したSOAでは,パフォーマンスや信頼性を確保するための仕組みが欠かせない。サービス管理ツールを中心に,SOAをうまく運用するポイントを解説する。

 サービスの実装が完了し,BPELエンジンによってプロセス連携を実行できるようになると,SOAは運用フェーズに入る。複数のサービスから構成されるSOAアプリケーションでは,特にパフォーマンスの監視やアクセス・ポリシーの実装,セキュリティ管理などの徹底が求められる。

 例えば,複数のサービスが連携してトランザクション処理を行っているようなケースでは,途中のサービスのどれか一つが数秒ダウンしただけで,タイムアウトが発生する。その結果,トランザクション処理が異常終了してしまう恐れがある。

 それを避けるには,アプリケーションの構成要素の状態情報を監視し,サービスが適切なパフォーマンスを維持しながら稼働しているか把握しなければならない。しかも,各構成要素の状況を関連付けて包括的に管理することが求められる。しかし,これは実際には非常に難易度が高い。

 このような課題の解決に一役買うのが,サービス管理ツールと呼ばれる製品である。SOAの普及が進めば,この分野は市場の伸びが大きく期待されるので,Actional(現Progress Software)やAmber Point,SOA Softwareなどの専業ベンダーのほか,IBM,HPなどの大手ベンダーも参入を開始している。

 サービス管理ツールは,様々なアプリケーション・サーバーやデータベース上を流れるWebサービスを自動的に検出し,モニタリングする。もし,なんらかの問題を発見した際には,あらかじめ設定したポリシーに基づき,ロード・バランシングやフェールオーバーといった解決策を自動実行する。これにより,エンド・ツー・エンドのトランザクションの可視性を高め,ポリシーに基づくセキュリティ管理やアクセス制御を徹底し,SLM(Service Level Management)が実現される。サービス管理ツールの主要機能を図1にまとめた。

図1●サービス管理ツールの主要機能
図1●サービス管理ツールの主要機能
サービスネットワーク管理,セキュリティ管理,パフォーマンス管理,例外管理などの機能を備える

 また,サービスが増加するにつれて,どのようなサービスがどこに存在するのかを管理する仕組みも必要となる。これらの仕組みは,「サービス・リポジトリ」「サービス・レジストリ」と呼ばれる。

 サービス・リポジトリは,実装・展開されているサービスの仕様を格納し,SOAをベースとしたアプリケーション設計時に必要なサービスが既に存在するか否かを調べるために利用する。一方のサービス・レジストリは,従来のUDDI(Universal Description, Discovery and Integration)と同様にサービスの位置情報などが登録され,サービスの発見や動的なバインディングに利用される。こうした技術に強いベンチャー企業は大手ベンダーの買収の的になっている。このことは,これらの技術が,SOAの普及に必須の技術であることを裏付けているとも言える。

エージェントベースか,プロキシベースか

 サービス管理ツールの導入を検討する際に注意したいのが,そのアーキテクチャである。

 一般にサービス管理ツールには,「エージェントベース」と「プロキシベース」の二つのアーキテクチャがある(図2)。エージェントベースは,アプリケーション・サーバーなどに組み込まれたエージェントによって,Webサービスの動的な発見やモニタリングを行う。プロキシベースは,サービス・リクエスト受信のプロキシによって,運用ポリシーやセキュリティポリシーの徹底を図る。

図2●エージェントベース・アーキテクチャとプロキシベース・アーキテクチャ<br>両者には一長一短があり,両者を組み合わせた「ハイブリッド・アーキテクチャ」の製品が多くなってきている
図2●エージェントベース・アーキテクチャとプロキシベース・アーキテクチャ
両者には一長一短があり,両者を組み合わせた「ハイブリッド・アーキテクチャ」の製品が多くなってきている
[画像のクリックで拡大表示]

 両者にはそれぞれ一長一短がある。例えば,SOAアプリケーションを管理するのに必要となる,サービスの発見やエンド・ツー・エンドのセキュリティ確保などはエージェントベースのツールが得意とするところである。しかし,エージェントがサポートするアプリケーション・サーバーなどのプラットフォームに,制約があるツールも多い。

 プロキシベースのツールの場合は,そういった制約がない反面,サービスの発見は不得手である。また,プロキシという性質上,パフォーマンスへの影響も無視できないものとなる。こうした点を考慮した結果,エージェントベースとプロキシベースを組み合わせた「ハイブリッド・アーキテクチャ」を取る製品が多くなってきた。製品選択の際には,サービス管理ツールのアーキテクチャに目を向ける必要がある。

 SOAに関する技術や標準化は,今後も進化を続けていくので,継続した情報収集が欠かせない。製品の進化からも目が離せない。SOAの本格的な普及に向け,そのコンセプトを実装する製品を各ベンダーが相次いでリリースし,市場にあふれている。こうした製品は時間の経過とともに成熟し,より使いやすくなっている。

 しかし,技術や製品がそろっただけでは,SOAのメリットは享受できない。SOAで一番重要なのは,実際にSOAの考え方を採用し,開発を進めていく企業の姿勢である。

 SOAは通常,段階を踏んで導入される。一部のプロジェクトから全社へと適用範囲を拡大すると同時に,信頼性などを向上させていく。そのためには,サービスというソフトウエア部品を再利用していくという企業文化の醸成,社内のプロジェクト全体を見渡したうえでの効率的なサービス管理の仕組み作り,SOAに基づくシステム構築を推進する体制の整備などが求められる。

 SOAの導入効果をより高めるためには,IT部門だけでなく,ビジネス部門の理解と協力が不可欠である。業務横断的に適用し,企業全体あるいは企業を越えたビジネスに生かせるかどうかは,ビジネス部門の取り組みが鍵となる。

 「ビジネスの変化に柔軟かつ迅速に対応する」という,SOAのそもそもの目的を達成するためにも,この点は非常に重要である。ビジネス部門によるビジネス・プロセスの整理,見直し,どのような単位でコンポーネント化するかといった分析が行われた後に,IT部門の出番となる。理想的なのは,検討当初から,ビジネス部門とIT部門が互いに協力して進める体制だ。このように,SOAの適用を個別プロジェクトから全社的な取り組みへと展開させるには,技術的な面だけではなく,適切なガバナンスの仕組みを確立することも必要となる。