レベル: 中級 Boris Lublinsky, Enterprise Architect, ALDION Consulting Pte Ltd
2007年 5月 15日 ほんの数文字の違いで大きく意味が変わってくるのが、サービス・リポジトリーとサービス・レジストリーです。この 2 つは似たように聞こえますが、それぞれが SOA 実装で果す役割はまったく違います。この記事では、サービス・リポジトリーとサービス・レジストリーの違い、そして SOA にこの両方を組み込まなければならない理由を説明します。
はじめに: SOA 実装の基軸
最近の多くの文書 [Longworth, Clement, Seeley] では、レジストリー/リポジトリー機能をサービス指向アーキテクチャー (SOA) 実装の基軸として定義しています。例えば、David Longworth は 2005 年の Loosely Coupled の記事で、このように書いています。「レジストリー/リポジトリーをどのように実装するかが、エンタープライズ SOA の成功と失敗の分かれ道となります」[Longworth]。彼は、レジストリー/リポジトリーを以下の機能によって定義しています。
-
開発者の効率性。組織が既存のサービスとサービス関連の成果物を追跡し続けられるようにすることによって、既存のエンタープライズ・サービス関連のアセットを再利用できるようにする。
-
実行時のガバナンス。組織がサービス・エンドポイント・アドレスを仮想化し、一元管理できるようにする。
Luc Clement によると (同じく Loosely Coupled の記事)、レジストリーの機能を省略すると通常は以下の問題が発生するということです [Clement]。
- アプリケーションの整合性と完全性の欠如、ならびにエンタープライズ・サービスの設計と開発の整合性、完全性を確実にするためのガバナンスの欠如。
- アプリケーション機能の関連付けと再利用の難解さ。これには、特定のビジネス問題を解決し、必要なプロセスをサポートする既存のサービスを見つけられないという問題も含まれます。
- 保守が難しい独自仕様のソフトウェア、そしてサービスのコンシューマーとプロバイダーのロケーションを密結合させてしまうことになる直接サービス呼び出し。
残念ながら、これらの文書の大多数はサービス・リポジトリーとサービス・レジストリーの実行時および設計の特徴を混同して 1 つのシステムとして考えていますが、実際にはこの 2 つが SOA 実装で果たす役割はまったく異なります。
この記事では、リポジトリーとレジストリーの役割、そしてそれぞれが SOA 実装においてどのように使用されるかを説明します。
サービス・リポジトリー
企業全体に及ぶ SOA [Lublinsky] には、設計チームと実装チームとの相当な協力が求められます。
ビジネス・プロセスを設計するアナリストは、設計したプロセスに必要な機能を提供するサービスを見つけなければなりません。特定のビジネス問題を解決するのに最も適したサービスを見つけることは、プロセス実装の成功には不可欠です。しかし機能だけが、サービスが適しているかどうかを保証するわけではありません。例えばサービス・レベル・アグリーメント (SLA) やセキュリティー要件といった機能以外の要件に関することも、サービスを利用するかもしれないユーザーが、特定のソリューションに選んだ一連のサービスがうまく連携するかどうかを判断する上で役立ちます。そして最後に必要なのが、サービスの依存関係に対処することです。これらの検討事項によって、アナリストはソリューションの全体的な複雑性、そしてそのソリューションを用いることによって生じるかもしれない変更の影響を判断することができます。
技術者も同じく既存のサービスのポートフォリオに関心を持ちますが、その興味は別の角度から向けられます。例えば、アプリケーション・アーキテクトが注目するのはサービスの設計と実装です。既存のアプリケーションを基礎として特定のサービスを作成するかどうか、あるいは実装にビジネス・ルール・エンジンを導入するかどうかなどの懸案事項を解決することによって、サービス開発者が一層強固で維持しやすいサービス実装を作成できるようにします。
一方、インフラストラクチャー・アーキテクトが関心を向けるのは、サービスを非武装地帯 (DMZ) の内側または外側のどちらに配置するかといったアクセスとプロシージャーです。彼らはこれらの事項を検討して、サービスとサービス・コンシューマーのデプロイメントに必要なインフラストラクチャーを定義します。さらに、サービス呼び出しの最大数や平均数などのサービス利用率も関心分野の 1 つです。アーキテクトはサービス利用率に関する情報によって積極的にサービスのキャパシティーを管理し、サービスの取りやめを決定します。
要するに、それぞれに異なる見解と目標を持つ企業の至るところの利害関係者が、幅広いサービス関連情報に関心を寄せているということです。小規模なコミュニティーで使用する一握りのサービスを管理するのであれば、情報 (スプレッドシートなど) を臨機応変に配布するという方式で十分でしょう。しかし、そのような方式ではサービス指向アーキテクチャー (SOA) の目標 (つまり、再利用性、一貫性など) を達成するところまではいきません。静的 HTML ページでサービス情報を提供するという方法もありますが、この方法はどんどん時代遅れになってきています。同様に、「アーキテクトを介して」利用可能なサービスと予定されたサービスに関する知識を伝達するという方法も、肝心なリソースを情報のボトルネックに変えてしまいます。
つまり、企業規模の SOA 実装では、すべてのサービス関連成果物が企業全体のアセットとなるため、上記のすべての情報を 1 箇所に格納するアセット・リポジトリーが必要だということになります。さらに、このリポジトリーは SOA 利害関係者すべてが (検索や変更を行えるようにして) 連携できるようにしなければなりません。そのようなサービス・リポジトリーは、設計成果物、ランタイム・トポロジー、サービスの監視および管理ソリューションによって収集された情報、サービス・コード・リポジトリーをはじめ、すべてのサービス関連情報のソースを統合します。そして統一された表現でこれらの情報のすべてを表し、SOA 利害関係者すべてがそれぞれの職務機能に応じて一箇所でアクセスできるようにします。図 1 を参照してください。
図 1. 基本的なサービス・リポジトリーの相互作用
サービスには図 2 に示すように、方向付けから設計、実装、デプロイメント、使用、そして保守に至るまでのライフ・サイクルがあります。サービス・リポジトリーは、このライフ・サイクル全体にわたってサービスをサポートするために必要な情報を提供します。
図 2. 簡略化したサービス・ライフ・サイクル
新しいサービスの要件は、システムの分解中にビジネス分析によって特定されます。これらの要件が既存の要件の機能性に対して評価され、新しいサービスがリポジトリーに挿入されます。新しいサービスが承認されると該当するサービス契約が作成され、これも同じくリポジトリーに格納されます。
この時点で、サービスは実装に移ります。サービス実装の成果物を作成および保守してリポジトリーに格納するのは、開発チームの役目です。実装が完了してテストされると、サービスは実動環境にデプロイメントされます。次にリポジトリー情報がデプロイメント情報で拡張されます。
通常のサービス使用期間中には、使用率の測定基準 (サービス・コンシューマーとそのロケーションに関する情報も含む) がサービス管理システムおよびサービス監視システムからリポジトリーに定期的にインポートされます。時間が経つにつれサービスの使用法には欠陥が出てくるので、追加の要件が作成されてリポジトリーに取り込まれます。適切な承認を受けた追加要件はサービス拡張あるいはサービスの新規バージョンに変換され、同じくリポジトリーに取り込まれます。
サービス・リポジトリーの必須機能には、以下が含まれます。
サービスのカタログ作成とディスカバリー。
サービス・リポジトリーの主要な目的は、成果物固有のメタデータに基づいて成果物を見つけられるようにすることです。このメタデータは通常、成果物自体に含まれています。そのため、新規成果物がリポジトリーに公開されるときには常に、サービス・リポジトリーがこのメタデータを (カタログ作成ポリシーに従って) 自動的に抽出しなければなりません。サービス定義のカタログ作成中には、例えば以下の情報を自動的に取り込むことができます。
- サービス定義文書 (XML スキーマ文書、メッセージ・セマンティクス定義など) によってインポートされる補助文書へのリンク
- サービス契約文書で使用する XML 名前空間
- サービス契約で使用するインターフェースの名前と説明および XML 型
- サービスの呼び出しと実行を管理するポリシーへのリンク
カタログ作成を実装するには、リポジトリーに置かれたすべての成果物に対するメタデータを定義する必要があります。メタデータはリポジトリーに格納された各種のサービス成果物だけでなく、それぞれの成果物の進化にも十分対応できるように情報豊富で柔軟でなければなりません。サービス・リポジトリーに格納されるメタデータには、ビジネス・アナリストとサービス設計者が既存のサービスを探し出して特定のソリューションに対する適用性を判断するために使用する、あらゆる情報を含める必要があります。したがって、リポジトリーが提供するディスカバリー機能は、拡張可能であること、そしてさまざまなドメイン固有のディスカバリー・クエリーに対応可能であることが要件となります。一般的に、この要件はリポジトリーが複数のビジネス関連の分類法をサポートできるかどうかという能力として解釈されます。
妥当性検査。
企業標準に従っていない成果物を検出しても、何の価値もありません。そこで、サービス・リポジトリーはサービス関連情報へのアクセス・ポイントとして、組織およびドメイン固有のビジネス・ルールを施行し、成果物の企業ポリシーおよび標準への準拠を確実にする必要があります。妥当性検査のルールを施行できるということが、リポジトリーを SOA ガバナンスの重要部分にします。
D依存関係の管理。
サービス関連情報には通常、複数の相関関係を持つ成果物が含まれます。これらの成果物とは、例えばサービス・インターフェース、メッセージ・スキーマ、実装コード、使用法プロファイルなどです。さらに、サービス自体も他のサービスやビジネス・プロセスで再利用される可能性があります。これらすべての依存関係を追跡して変更が及ぼす影響を判断するのは、サービスの数が増えるにつれ困難なタスクとなってきます。サービス・リポジトリーはサービス成果物間の関係を管理することで、このタスクを簡単なものにします。そのためリポジトリーに必要とされるのが、標準の関係タイプを提供することです。さらに、追加要件に応じて組織がこれらのタイプを追加タイプで拡張できるようにもしなければなりません。
サービスの進化とバージョン管理。
いったん作成されたサービスは、時間が経つにつれ進化するのが通常です。この進化は、サービス機能やセマンティック・メッセージング、そして実装の変更によってもたらされます。そのような変更の多くでは、サービスの新しいバージョンを作成してデプロイメントする必要が出てきます。このバージョン管理情報を追跡するため、サービス・リポジトリーはサービスのタイプに関わらず、すべてのサービス成果物に対してバージョン管理機能を提供しなければなりません。
さらに、サービス・リポジトリーは変更/バージョン管理の通知機能へのサブスクリプションを用意して、関係者が予定されている変更や現在の変更について通知を受けられるようにする必要もあります。これにより、リポジトリーは変更に関する情報を関係者すべて、つまりサービス・コンシューマー開発チームに提供することができます。このようなサブスクリプション・メカニズムでは、対象となるイベントのタイプを指定できるようにして、サブスクライバーが通知で溢れないようにする必要があります。
成果物公開のガバナンス。
サービス・リポジトリーにサービス関連のアセットに関するすべての情報が集約されるにつれ、他のあらゆるエンタープライズ・アセット・リポジトリーと同じようにガバナンスが必要になってきます。このようなガバナンスには通常、サービス関連成果物の公開許可と成果物公開の承認プロセスが含まれます。
複数の成果物タイプのサポート。
サービス・リポジトリーを作成する上での大きな課題の 1 つは、サービス関連の成果物の多様性です。成果物には、サービス・インターフェースとメッセージ・スキーマを定義する XML 文書、実装コード、UML ダイアグラム、そしてテキスト文書など、さまざまなタイプがあります。多種多様なアセットに汎用表現を使うことで、リポジトリー実装を大幅に単純化することができます (「RAS (Reusable Assets Specification)」を参照)。
 |
RAS (Reusable Asset Specification)
異なるアセット・タイプの汎用表現に対応するのが、OMG の RAS(OMG Reusable Assets Specification)[Larsen] です。RAS ではアセットを、問題の解決を提供する関連成果物の 1 つの集合として定義します
アセットとは、要件、ユース・ケース、設計モデル、コンポーネント仕様、コンポーネント、テスト・ケース、テスト・ドライバー、そしてテスト・データを含む完全なソリューションを意味することもあれば、単なる一連のユース・ケースとそれぞれのモデル、そしてユース・ケースを拡張するためのルールであることもあります。
優れたアセットには、以下の特性があります。
- 使いやすくカスタマイズが簡単で、別のコンテキストにも容易に適用できること
- 優れたソフトウェア・エンジニアリングの特性、つまり強固な凝集性、疎結合性、そして十分な機能を持っていること
- その用途と目的が理解しやすいこと
- 適合性を分析しやすく、アセットが特定のコンテキストに一致するかどうかを判断できること
以上の目標を達成するには、アセットはランタイム成果物 (コードやコンポーネントなど) の単なる集合ではなく、最終目標、用途、動機、そして前提条件を説明する成果物も含まれるものにしなければなりません。大抵、これらの成果物は元の要件と構想関連の成果物のサブセットとして理解され、アセットのランタイム要素を作成する際に使用されます。
RAS では、XML マニフェストという形で取り込まれたメタデータを使用してアセットを記述します。このマニフェストは、以下の図に示すようにアセットのパッケージの一部として提供されます。
マニフェストに最低でも含まれるのは、名前、バージョン、説明などの属性が含まれるアセット仕様です。アセット仕様は単純な名前/値の記述子のセットとして表される分類、そしてコンテキストの宣言 (特定のデプロイメントやデプロイメントのコンテキストなど) によって拡張できます。アセットの本体を構成するのは、特定の問題に対処する一連の成果物です。使用法のセクションには、アセットを適用およびカスタマイズする際のガイダンスがあります。そして関連アセット・セクションでは他のアセットとの関係を定義し、アセットの集合やアセット群を作成してより大局的なソリューションを形成できるようにします。
アセットには多くのタイプがあり、それぞれのタイプが異なる RAS プロファイルで表現されます。アセットのタイプは特定のニーズに合わせたカスタマイズをサポートするために拡張することができます。アセットをカスタマイズするには、RAS の中核的構造を維持する一方でプロファイル固有の拡張を指定するプロファイルを使用します。
検索エンジンとリポジトリーはマニフェスト・ファイルを使用して、アセットのコンテンツ、分類、関連アセットなどを探し出します。
|
|
サービス・レジストリー
サービスは、そのサービスが実装する機能を必要とするコンシューマーによって呼び出されることを目的に作成されます。サービスを呼び出すには、そのロケーション、つまりサービス・エンドポイント・アドレスを知っていなければなりません。最も単純なケースでは、エンドポイント・アドレスはサービス・コンシューマーの実装にハード・コーディングされます (Java™ 環境と .NET® 環境のいずれにしても、Web サービス・コンシューマーはこの方法で、サービスの Web サービス記述言語 (WSDL) をベースに生成されます。したがって、現在の多くのシステムがハード・コーディングされたエンドポイント・アドレスを使用しているのは当然のことです)。エンドポイント・アドレスをハード・コーディングするという方法は、サービス・コンシューマーの実装とサービス･ロケーションを緊密に結合することになります (ロケーション結合)。
図 4. コンシューマーによるサービスの直接呼出し
このように密結合された実装 (図 4) でサービス・エンドポイント・アドレスの変更に対応するには、サービス・コンシューマーの実装を変更しなければならなくなります。しかし、実装を変更するとエラーの元になり、サービス数の増加に対応するのも困難になります。複数の環境 (開発、テスト、品質保証、実動) を考えると、問題はさらに悪化するだけです。
エンドポイント・アドレスを構成ファイルに外部化すると、この実装の改善につながる可能性があります。この方法のほうが柔軟性に優れているのは、エンドポイント・アドレスをコンシューマーのコードから取り除き、構成ファイルに外部化するためです。エンドポイント・アドレスを外部化することで、サービス・コンシューマーはコードを変更しなくてもアドレスの変更に対応できるようになりますが、このオプションはコンシューマーとサービスの数が増えてくると (その結果、構成ファイルの数も増加すると) スケーラビリティーの問題にぶつかります。
この問題に対して最も柔軟で最も管理しやすいソリューションとなるのは、サービス照会をエンドポイント・アドレスと呼び出しポリシーに動的に分解する専用コンポーネント (つまり、サービス・レジストリー) を使用することです。この場合のサービス・レジストリーには、サービス・デプロイメントとそのロケーション、そしてロケーションごとの呼び出しに関連付けられたポリシーに関するすべての情報が含まれることになります。
Vinoski は IEEE インターネット・コンピューティングに関する記事「The social side of services (サービスの社会的な側面)」のなかで、サービス・レジストリーの有益性はサービスの数に応じて高くなると指摘しています [Vinoski]。彼は以下のように説明しています。
サービスの数が一定数に到達し、これを管理するために必要な技術的事項は以下のとおりです。
- 複数のサービスが 1 つにまとまって動作する場合、サービスが互いを認識する必要があります。
- サービスが互いを認識するには、それらのサービスがしっかり結びついているか、あるいはサービスが互いを動的に検出できる必要があります。
- サービスがしっかり結びつくということが、密結合になったり、あるサービスの実装を別のサービスで置き換えることが難しくなったりするのは望ましくありません。
- 動的ディスカバリーを容易にするには、サービスがそれ自体を通知でき、かつ他のサービスを見つけられる場所が必要になります。
- その場所は当然、レジストリーとなります。
サービス・レジストリーは元々、最初の Web サービス・アーキテクチャー・グループによって導入された概念です。このグループでは、サービス・コンシューマーとプロバイダーの「マッチ・メーカー」(ブローカー) として UDDI ( Universal Description, Discovery, and Integration) レジストリーを定義しました。UDDI の役目として考えられていたのは、コンシューマーが必要とする機能に応じて、動的にサービス・プロデューサーの選択肢を用意することです。その役割は、Yellow Pages と似ています。複数のベンダーや標準化団体の後押しがあったにも関わらず、UDDI がサービスの仲介に使用されることはありませんでした。今日の UDDI 使用法の大多数は、コンシューマーの設計段階で使用されるサービス WSDL ファイルの格納に限られています。
より実用的なサービス・レジストリーの使用法は、サービス・コンシューマーが必要とするサービス名とポリシーを基準にサービス・エンドポイントを実行時に検索することです。この場合、サービス定義はコンシューマーの開発期間中に利用可能になり、レジストリーの使用法は実行時のサービス・エンドポイント・アドレス解決と動的バインディングに限られます。図 5 に、この方法のアーキテクチャーを示します。
図 5. 基本的なサービス・レジストリーのアーキテクチャー
図 5 のアーキテクチャーは、エンタープライズ JavaBean (EJB) コンポーネントの動的バインディングに使用される JNDI (Java Naming and Directory Interface ) 実装と似ていて、サービス・エンドポイント・アドレスを後でバインディングすることによって、ロケーション結合を軽減しています。このソリューションでは、サービス・エンドポイント・アドレスをサービス・コンシューマーの実装によってハード・コーディングする必要も、構成ファイルに格納する必要もありません。さらに、サービス・エンドポイント・アドレスとそれぞれに関連付けられた呼び出しポリシーは、サービス・レジストリーで一元管理できます。
典型的なサービス・レジストリーの実装は、以下のいずれかのモデルでエンドポイント・アドレス解決とルーティングを行います。
図 6. サービス・レジストリーを使ったダイレクト・ルーティング
ダイレクト・ルーティング。
図 6 に示したこのモデルでは、レジストリーを照会するために必要となる情報はコンシューマーにあります。この情報に含まれるのは、サポートされるポリシーと必要なポリシーのセットです。レジストリーが一致するサービスを見つけると、コンシューマーがどのサービスを使用するかを決定して、要求をそのサービスに直接ルーティングします。
図 7. サービス・レジストリーにを使った中継によるルーティング
中継によるルーティング。
図 7 に示したこのモデルは、中継に依存してルーティングを処理します。サービス・コンシューマーはサービスと直接対話動作をしません。代わりにすべてのサービス要求は中継先に転送され、この中継地点が (コンシューマー固有の情報で) レジストリーを照会して使用するサービスを決定し、すべての要求をそのサービスに動的にルーティングします。このモデルは、メッセージを受信し、内部レジストリーに基づいて該当する宛先にメッセージをルーティングするエンタープライズ・アプリケーション統合 (EAI) ブローカーに似ています。多くのエンタープライズ・サービス・バス (ESB) 実装では、コンテキスト・ベースのルーティング中継モデルをサポートしています。
上記の 2 つの方式を比較したのが、表 1 です。
表 1. ルーティング方式の比較
| ダイレクト・ルーティング | 中継によるルーティング |
|---|
| 利点 |
- 最良の呼び出しパフォーマンス
- 最小限のインフラストラクチャー・オーバーヘッド。特に、メッセージ指向ミドルウェア (MOM) がトランスポートとして使用されている場合は、オーバーヘッドの軽減が顕著になる
|
- サービスの候補から選択する方法を 1 箇所で決定できるため、サービス・コンシューマーが呼び出し情報を格納および処理する手間がなくなる
| | 欠点 |
- コンシューマーの実装によっては、コンシューマー・ポリシー・ファイルでコンシューマーを再起動/リビルドしなければならない場合がある
|
- さまざまなコンシューマー/サービスに異なる SLA が必要な場合、中継地点が最も厳しい SLA をサポートできる必要がある
- ネットワーク・ホップを追加すると全体的な呼び出しパフォーマンスに影響が出る
- 中継地点が追加の (場合によっては単一の) 故障ポイントとなる
- 通常、中継地点を導入するにはインフラストラクチャーを追加する必要がある
|
ポジトリーとレジストリーの違い
これまで説明してきたように、サービス・リポジトリーとサービス・レジストリーはどちらもエンタープライズ SOA 実装全体で活躍します。サービス・リポジトリーはエンタープライズ SOA ガバナンスの基礎として、設計、実装、使用法の成果物を含め、あらゆるサービス関連情報の一元管理をサポートします。サービス･レジストリーはサービス・ロケーション仮想化の基礎として、すべてのエンタープライズ・サービスに対するロケーションと呼び出しポリシーを一元制御します。そんなサービス・リポジトリーとサービス・レジストリーの重要な違いは、以下のとおりです。
- リポジトリーには、設計やビルドの際に設計ツールに必要となるサービスの設計成果物と開発成果物がすべて含まれます。一方、レジストリーに含まれるのはこの情報のサブセットで、このサブセットは実行時のバインディングに必要となります。
- サービス・リポジトリーは大量のアセットを格納し、大勢のユーザーが臨機応変にこれらのアセットを照会して見つけられるようにするために最適化されます。この場合の主要な設計要件は、柔軟に分類ができることと、クエリーをサポートすることです。さらに、リポジトリー自体にもユーザー・フレンドリーなインターフェースにもスケーラビリティーが必要となります。一方サービス・レジストリーは、サービス・エンドポイント・アドレスを実行時に検索するための最適化が行われます。主要な設計要件は、検索のパフォーマンスと高可用性です。
- リポジトリーへのアクセスは、エンタープライズ境界の内側で行われます。一方、レジストリーにはエンタープライズ境界の内側と外側の両方からアクセスしなければならないことがよくあります。
つまりサービス・リポジトリーとサービス・レジストリーは選択肢ではなく、SOA 実装を成功させるには両方とも欠かせません。問題は、どちらをどこで使うかべきかということです。それぞれが果たす役割はまるで異なるため、この 2 つの概念の違いを念頭に置いておくことが重要となります。
参考文献 学ぶために
製品や技術を入手するために
-
IBM ソフトウェア製品のデモ版ソフトウェアを試してみてください。
-
IBM 製品の評価版をダウンロードして、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
著者について | | | Boris Lublinsky はソフトウェア・エンジニアリングと技術アーキテクチャーの分野で 25 年以上の経験を持ちます。この 7 年間、彼が専門に取り組んでいるのはエンタープライズ・アーキテクチャー、SOA、プロセス管理です。講演や執筆でも活躍する Dr. Lublinsky は、これまでに 40 を超える技術文書をさまざまな雑誌 (Avtomatika i telemechanica、IEEE Transactions on Automatic Control、Distributed Computing、Nuclear Instruments and Methods、Java Developer's Journal、XML Journal、Web Services Journal、JavaPro Journal、Enterprise Architect Journal、EAI Journal など) で発表しています。現在勤務している大規模な保険会社では、SOA ストラテジーおよびフレームワークの開発、維持などを職務としています。連絡先は、blublinsky@hotmail.com です。 |
記事の評価
| 
