 |
SOAの可能性を最大化するためには，システム的なインフラも非常に重要だ。そうした要素の一つが，「サービス・レジストリ」である。前回「ビジネス・サービス／メタデータ管理」のパーツとして説明したものに近い。
サービス・レジストリは，今後SOAに基づいたシステム構築が進展し，SOAを大規模・超大規模化していくうえで必ず登場するであろう技術／考え方である。ガートナーとしては，2010年までに，大規模・超大規模SOA実現事例の75％以上で，サービス・レジストリまたはこれと同様の機能が実装されると見ている。
いまSOAを推進しているユーザー企業の間では，サービスの数が数個から数十個レベルに増えることで，これまで顕在化しなかった問題や課題が現れつつある。
代表的なものの一つが，各サービスの利用形態や利用する上での手順，サービス同士の依存関係といった情報をどう管理するか，といった問題だ。ほかにも，開発者同士でサービスの情報を共有しなければ，サービスを使ったアプリケーションの構築や，サービスの再利用，新しいサービスの開発が適切に進まない，といった問題も起きつつある。“サービスの基本情報”は現状，必ずしもシステマティックに管理・共有されているとは言えないのが現状だろう。
サービスの開発，管理，実行時に活用
サービス・レジストリはそうした状況を踏まえて今後重要なインフラとして浮上する。基本的サービス・レジストリは，サービスのライフサイクルを管理する上で必要な，いわば「サービスのカタログ」を作成・管理する。
 図：サービス・レジストリの概要（出典：ガートナー ジャパン） |
カタログとして管理する項目は例えば，どんなサービスがどのシステムに実装されているか場所の管理，サービスの機能の記述，サービスの利用方法（パラメータ，メソッド，メッセージ構造），サービス同士の依存関係の記述，バージョン管理の情報といったものである。ユーザーの利用状況に合わせてサービスを複製して実行させたり，実行中のサービスを複数組み合わせたり，といった実行状況も情報として収集・管理する。こうした情報はサービスの開発・保守時・実行時に欠かせないものだ。
現在市場に出ているESB（エンタープライズ・サービス・バス）やアプリケーション・サーバー，開発ツールなどはサービス・レジストリに近い機能を提供している。しかし上記のように必要な要素を考えつつ列挙していくと，製品の機能としてはまだ進化の途上にある。
サービス・レジストリの相互運用性を確保するべき
サービス・レジストリに大切なのは相互運用性だ。ベンダーの違いを乗り越えて，オープンにアクセスできる仕様が求められる。A社製のサービス設計・開発ツールで開発したサービスをB社のアプリケーション・サーバーで動かす場合，サービス・レジストリに格納するサービスの情報に矛盾があってはならない。また，社内で複数走っているプロジェクトごとに，それぞれに合ったサービス設計・開発ツールを使うことがあるだろう。そうした場合に，異なるベンダーのサービス設計・開発ツールであっても，サービス・レジストリに入れるべき情報は相互に交換できるべきだ。
各ベンダーの製品が必要十分なサービス・レジストリの機能を持っていたとしても，それがベンダー内で“隠ぺい”されていては，ユーザー企業は使いようがない。どの時期・段階になるか確定的なことは言えないが，いずれにせよ，相互運用性の確保や，サービス・レジストリに格納するメタデータに関する標準化が進むと思われる。
だが，標準が完成するのを待つのがビジネス上得策かどうかは，十分に吟味する必要がある。また，標準に準拠したとする製品を導入しても、期待する相互運用性の要件が満足されるとは限らない。各社の適用指針と設計の工夫が必須となるだろう。
レジストリにおいても，異種混在環境の統合問題は今後顕在化する。こうした中，製品の実装非依存の設計，および設計指針としてのアーキテクチャが，より重要になるはずだ。
（次回に続く）
|
