Japan [変更]

ホーム

製品

サービス & ソリューション

サポート & ダウンロード

マイアカウント

developerWorks Japan > WebSphere >

WMBとWSRRによる柔軟なESBメディエーション構築

ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

レベル: 中級

Bob Patten (wrpatten@us.ibm.com), Integration Architect, IBM
Subhash Kumar (subkumar@us.ibm.com), Integration Architect, IBM
Stuart C. Jones (stuartjones@us.ibm.com), Integration Solutions Architect, IBM

2006年 10月 18日

WebSphere Message Broker Enterprise Service BusでWebSphere Service Registry and Repositoryを使用すると、より柔軟で安定したESBメディエーションを作成する上で、どのように役立つのかを学びます。WebSphere Service Registry and Repositoryを使用することで、ビジネスが変更に関する問題の影響を受けにくくなります。

はじめに

この記事では、ESB（Enterprise Service Bus）実装としてWebSphere Message Broker（以降、Message Brokerと呼びます）を用いて、ESB環境でWebSphere Service Registry and Repository（以降、Registry and Repositoryと呼びます）を使用する方法について説明します。Registry and Repositoryを使用すると、エンドポイント・サービスと対話するESBメディエーションは、環境内の変更による影響を受けにくくなります。この対話でのESBは、サービス・エンドポイント（サービス・メタデータ）に関する情報を提供する動的な検索メカニズムとしてRegistry and Repositoryを使用します。これは、サービス・エンドポイント環境で変更が行われても、関連するESBメディエーションを変更する必要がないことを意味します。

Message BrokerとRegistry and Repositoryの間の対話は、Message Broker Version 6 Client for WebSphere Service Registry and Repositoryによって提供されます。この詳細と製品拡張のダウンロードについては、「参考文献」を参照してください。拡張には、Message Brokerフローを作成する場合に使用できる一連のMessage Brokerノードが含まれています。これらのノードは、対話の効率を改善するために、Registry and RepositoryへのAPI呼び出しとキャッシング・メカニズムをカプセル化します。

この記事では、SOAの基本概念とWebSphere Message Brokerを十分理解していることが前提となっています。

上に戻る

背景

SOAは、再利用、疎結合、柔軟性、相互運用性、統合、およびガバナンスにより、ビジネスに機敏性と回復力を提供します。上記の点に関するSOAの主要な実現機能の1つは、実装とサービス記述を区別して、サービスのライフ・サイクルを通じてサービス記述に関連付けられた記述メタデータを使用することです。Webサービス記述言語（WSDL）、XMLスキーマ、ポリシー、またはService Component Architecture（SCA）文書などの標準ベースのサービス・メタデータ成果物は、サービスが実行できること、サービスの起動方法、または他のサービスへの要求に関する技術的な詳細を収集します。サービスの潜在的なユーザーが、サービスをいつどのようにして使用できるか、またサービスが果たす目的は何かといったことを見抜けるように、セマンティック・アノテーションとその他のメタデータをこれらの成果物と関連付けることができます。

Message Brokerは、変換やサービス・エンドポイント・ルーティングなどの強力なメッセージ・メディエーション機能を提供するESB実装です。一般的なESB使用パターンの1つには、組織の公開済み（つまり外部に提供される）サービスとしての機能を果たすように構成されたメディエーションがあります。このようなメディエーション、すなわちMessage Brokerフローは着信メッセージを処理して、着信メッセージの要求を実行するために必要なタスクまたはステップを決定します。このとき一般的に、着信メッセージの実行は、バックエンド・サービスと呼ばれる、1つ以上のサービスに委譲されます。

Registry and Repositoryは、サービス対話エンドポイント記述のマスター・メタデータ・リポジトリーで、SOAP/HTTPバインディングとの WSDLインターフェースを実装する従来のWebサービス、およびさまざまなSOAサービスが組み込まれています。このようなSOAサービスは、WSDL、XSD、およびポリシー宣言を使用して記述できますが、一連のプロトコルを使用して、さまざまなプログラミング・モデルに従って実装される可能性があります。Registry and Repositoryは、サービス・メタデータのレコードのコピーとして、多数のソースから取得されたサービス・メタデータを1箇所で検索および管理するよう設定します。ソースには、サービス・アプリケーション・デプロイメント、その他のサービス・メタデータ、エンドポイント・レジストリー、リポジトリーなどがあります。またRegistry and Repositoryには、サービス・エンドポイントに関する最新情報も含まれています。これは、以下でESBとサービス・レジストリーの統合について説明する際に重要になります。

上に戻る

サービス・レジストリーを使用してESBの柔軟性を向上させる

上で説明しましたが、図1に示すように、一般的なESBメディエーション・パターンでは、メディエーションが組織の公開済み（つまり外部に提供される）サービスとしての機能を果たすように構成されています。

図1 ESBを使用して公開されたサービス

メディエーションが委譲するバックエンド・サービスは、一般的に開発時（つまりメディエーション・フローの開発中）に指定されます。通常これらのバックエンド・サービスでは、使用するさまざまなサービス・エンドポイントに関する静的情報を指定します。SOA環境の柔軟性と応答性が向上すると、サービス・エンドポイント定義（メタデータ）内でかなりの変更が行われて、静的に定義されたメディエーションが不安定になる可能性があります。変更されたサービス・エンドポイントに合うようメディエーションを変更すると、コストに関する問題が発生します。コストに関する問題には、開発の変更、これらの新しいサービスのデプロイの遅れ、およびメディエーションの変更を監視するために発生する可能性があるビジネスプロセスや運用プロセスなど伴うコストがあります。

その一例として、Webサービスなど、起動するバックエンド・サービスのエンドポイントを含むメディエーションについて考えてみましょう。このエンドポイントは、静的URL、またはサービスのバインディングを記述するその他のメタデータを使用して表されます。この静的コンテンツに変更が必要な場合、メディエーションは不安定になります。変更とは、例えば、メディエーションから呼び出す必要がある新しいWebサービスのデプロイメントや、着信メッセージの変換が必要な新しいバックエンド・サービス、あるいは完全に異なるプロトコルを使用して実装されている新しいバックエンド・サービスのデプロイメントなどです。

メディエーションの不安定さに対処するには、もはやサービス・エンドポイントについて静的に定義された情報には依存しないメディエーションを開発します。それには、サービス・エンドポイントに関する最新情報を入手する場所と、その情報に効果的にアクセスするためのメカニズムが必要です。この問題を解決するために以前試行されていた方法では、概して、何らかの形でリレーショナル・データベースやキューなどのデータ・ストアにアクセスすることに依存していました。これらのメカニズムでは、メカニズムに特有の性質、すなわち、メディエーションからデータベースへのアクセスに関連するパフォーマンスの問題、および自己流のソリューションを使った作業による保守の問題に悩まされていました。

WebSphere Service Registry and Repositoryなどのサービス・レジストリーは、以前の自己流のメカニズムにミドルウェア・ソリューションを提供します。Registry and Repositoryからは、サービス・メタデータに関する最新情報にアクセスできるため、メディエーションは、サービス・エンドポイントのようなサービス・メタデータの変更に影響されなくなります。例えば、Registry and Repositoryを使用して、常に特定のサービス・エンドポイントの最新リリースが呼び出されるようにするか、入力メッセージの選択基準を基にして特定のエンドポイント・サービスを選択することができます。

Registry and Repositoryを使用するメディエーションは、最大限の柔軟性を維持します。これは、図2に示すように、意思決定で使用されるメタデータのコンテンツが外部化されているためです。

図2 ESBでのサービス・レジストリーの使用

上に戻る

ESBとサービス・レジストリーの対話

ESBは、サービス・レジストリーを使用して、起動する必要があるサービスに関するメタデータを取得します。このメタデータは、特定のサービス・エンドポイント、サポートされるポート・タイプ、特定のSLA要件を満たすサービス、またはその他のメタデータです。図3では、メディエーションがESB（この例では、Message Broker）で呼び出されると、ESBが、サービス・レジストリー（Registry and Repository）から必要なメタデータにアクセスするために特定のノードを使用して着信メッセージを処理することがわかります。次にESBは、取得されたメタデータを使用して、呼び出す正しいエンドポイントを設定します。さらに、代替の実行パスを決定するか、ポリシーを実施するか、またはその他のアクションを実行します。

図3 ESBでのRegistry and Repositoryのロケーション

上に戻る

レジストリー・コンテンツの理解

Registry and Repositoryコンテンツ・モデルで最も基本的なビルディング・ブロックは、XSDファイルや WSDLファイルなどのサービス・メタデータ成果物文書（物理文書）です。これらのサービス・メタデータ文書は、Registry and Repositoryで保管および管理されます。どのようなタイプのサービス・メタデータ成果物でもRegistry and Repositoryに保管することができます。一方Registry and Repositoryは、よく知られたSOAメタデータ・タイプ（WSDL、XSD、WS-Policy、およびSCDL）用の拡張機能を備えています。これらのタイプのサービス・メタデータ文書のコンテンツは、Registry and Repositoryの論理モデルで構成されます。論理モデルには、WSDLファイルに関連するportType、port、およびmessage、さらにXSD文書に関連するcomplexTypeまたはsimpleTypeなどのエンティティーがあります。論理モデルの要素には、基礎となる物理文書で定義されているように、プロパティーと、その特性のサブセットを反映する関係があります。例えばWSDLService要素には、namespaceプロパティーと、そこに含まれるポートとの関係があります。

Registry and Repositoryには、もう1つ他の種類のエンティティーがあり、大ざっぱにConceptと称されています。これは、Registry and Repositoryで物理文書を持たないものを表すために使用できる汎用オブジェクトです。Conceptsは、他のメタデータ・リポジトリー内のコンテンツへの参照を表すために使用できます。例えば、ポートレット・カタログ内のポートレット、資産リポジトリー内の資産、ソース・コード・ライブラリーに保持されているサービス実装成果物、または構成管理データベース内のSOAインフラストラクチャー・トポロジーに関する情報などです。また、例えば、検索を容易にするために物理成果物を1つのグループにまとめるために使用することもできます。

Registry and Repositoryは、サービス・メタデータ文書に直接関連するコンテンツだけでなく、ユーザー定義のメタデータ・タイプを多数サポートします。このようなメタデータは、サービス記述メタデータと呼ばれ、サービス・メタデータを装飾して、その意味を説明するために使用されます。Registry and Repositoryでは、プロパティ、リレーションシップ、および分類子の3つのタイプのサービス・セマンティクス・メタデータ・タイプがサポートされます。ユーザーは、WSDLファイルを表す物理モデル・エンティティーとプロパティーbusinessValueを関連付けることができます。または、portTypeを表す論理モデル内のエンティティーと、XML文書を表す物理モデル内のエンティティーの間の新しいリレーションシップmakesUseOfを定義することができます。あるいは、分類子importantThingsを作成して、論理モデル内のportエンティティーおよびポリシー文書を表す物理モデル内のエンティティーと関連付けることができます。これによって、セマンティック・クエリーはサービス・メタデータの個々の要素を対象にして、変更前に意味のある依存関係分析を行うことができるようになります。

Registry and Repositoryの主なユーザー・インターフェースは、Registry and RepositoryランタイムでデプロイされたWebアプリケーションです。このインターフェースは、予期されるユーザー・ロール・セットをサポートし、以下の機能を提供します。

検索、参照、および取得
パブリッシュとアノテーション
インポート/エクスポートや影響分析などのガバナンス・アクティビティー

図4に示すように、ユーザー・インターフェースは、パースペクティブ（Perspective）ペイン、ナビゲーション・ツリー（Navigation Tree）ペイン、および詳細（Details）ペインで構成されます。

図4 Registry and RepositoryのWebインターフェース

Webインターフェースを使用して、Registry and Repositoryコンテンツのビューをカスタマイズすることができます。一連のユーザー・インターフェース定義ファイルは、Registry and Repositoryインターフェースを構成するさまざまなコンポーネントのコンテンツとレイアウトを記述します。ロール固有のパースペクティブもサポートされます。

上に戻る

Registry and RepositoryのMessage Brokerクライアント・サポート

Registry and Repository用のMessage Brokerクライアントは、2つの汎用ノードを使用してRegistry and Repository内のサービス・メタデータへのMessage Brokerランタイム・アクセスをサポートします。これらのノードを使用することで、メディエーションの変更、テスト、および再デプロイなどにコストをかけずに、Message Brokerフロー、すなわちメディエーションの柔軟性を向上させて、企業内の変更に適応させることができます。

Registry and Repositoryにアクセスするために使用される最初のMessage Broker汎用ノードは、特定のWebサービスのメタデータにアクセスして、サービスを起動できるように適切なエンドポイントとプロトコルを設定します。このノード（SRRetrieveITService ノード）のアイコンを以下に示します。

このノードの「プロパティー（Properties）」ダイアログでは、さまざまな異なるプロパティーに基づいてサービスを取得する方法を指定することができます。例えば、ポート・タイプ（PortType）の名前、名前空間、およびバージョンに基づいて特定のサービスを取得することができます。名前、名前空間、およびバージョンの組み合わせ（サービスの組またはトリプル）により、特定のサービスが一意的に識別されます。また、指定されたユーザー定義プロパティー・セットまたは特定の種別と一致するかどうかなど、特定の基準セットを基にして取得するサービス実装またはポートを指定することもできます。詳しくは、「サンプル」を参照してください。

図5 SRRetrieveITServiceノードの「プロパティー（Properties）」ダイアログ

Registry and Repositoryアクセス用のMessage Brokerでサポートされる別の汎用ノードは、SRRetrieveEntityです。このノードは、Registry and Repositoryに含まれるエンティティーのコンテンツを取得するために使用されます。これは、実行に関連する環境仕様は設定しませんが、代わりにエンティティーのコンテンツ全体をメディエーションで使用できるようにします。その後、メディエーションは必要に応じてこの情報を使用することができます。SRRetrieveEntityノードのアイコンを以下に示します。

SRRetrieveEntityの「プロパティー（Properties）」ダイアログは前のダイアログと似ています。ただし、このノードでは、サービスだけでなくRegistry and Repository内のすべてのエンティティーに明示的にアクセスできるという点が異なります。これは、Message Brokerフローがエンティティーの完全なメタデータ（そのコンテンツを含む）を取得でき、必要に応じてそのメタデータまたはコンテンツを使用することを意味します。例えば、Message Brokerフローはこのノードを使用してポリシー文書にアクセスして、そのコンテンツを使用して特定のポリシー・セットを実施することができます。SRRetrieveITServiceノードと同様に、SRRetrieveEntityノードでは、そのmatchPolicyで指定されているように複数のエンティティーを返すことができます。これにより、メディエーションは、Registry and Repositoryに単一の要求を行い、いくつかの文書を取得して必要に応じて使用することができます。

図6 SRRetrieveITServiceノードの「プロパティー（Properties）」ダイアログ

上に戻る

WSRRから取得したWebサービスを起動するサンプル・メッセージ・フロー

メディエーションが要求をlistenして、特定のWebサービスを取得してから、そのサービスを実行する必要があると仮定しましょう。この動作を図7に示すMessage Brokerフローで行う場合、要求をlistenするためには組み込みのHTTP Inputノードを使用して、Registry and Repositoryから特定のWebサービスを取得するためにはSRRetrieveITServiceノードを使用し、このWebサービスを起動するために組み込みのHTTP Requestノードを使用します。サービスが見つからない場合は、Message Brokerは対応するFailureまたはNoMatchの出力端末にメッセージを送信します。

図7 SRRetrieveITServiceノードを使用するサンプルのMessage Brokerフロー

このMessage Brokerフローの開発時には、図8に示すように、実行時に取得して実行する特定のWebサービスを見つけるための基準を指定するためにSRRetrieveITServiceノードの「プロパティー（Properties）」ダイアログが使用されます。この例の「プロパティー（Properties）」ダイアログでは、「ポート・タイプ名（PortType Name）」がDemoCustomerで、「ポート・タイプ名前空間（PortType Namespace）」がhttp://demo.sr.eis.ibm.comのWebサービスを検索するよう指定されています。さらに、取得されるサービスは、「ユーザー・プロパティー（user Properties）」のpolicyとcountryの値がそれぞれRMとUSAで、http://eis.ibm.com/ServiceRegistry/BusinessDomain/GenericObjectTypes#CustomerRelatedに分類されている必要があります。これらの基準をすべて満たすサービスのみが取得されます。最後に、ダイアログで「一致ポリシー（Match Policy）」に「1（One）」を指定します。これは、これらの基準を満たす1つのサービスのみが取得されることを意味します。要求されたサービスがRegistry and Repositoryに見つからない場合は、ノードのNoMatchターミナルにメッセージが送信され、実行はMessage BrokerのPostNoMatch Computeノードによって処理されます。

図8 サンプル・フローのSRRetrieveITServiceの「プロパティー（Property）」ダイアログ

上に示すSRRetrieveITServiceノードの「プロパティー（Properties）」ダイアログでは、取得する必要があるサービスが指定されています。Registry and Repositoryコンソールを使用すると、取得するサービスを検証することができます。これを行うには、「サービス・メタデータ（Service Metadata）」=>「ポート・タイプ（PortTypes）」を選択して、登録済みのすべてのポート・タイプを表示します。次に、指定されたサービス名（ここでは、DemoCustomer）を選択します。図9に示すように、詳細ペインでは、名前と名前空間がMessage Broker SRRetrieveITServiceノード・プロパティーで指定された基準を満たすことを確認することができます。

図9 サンプル・フローで使用されるportTypeのRegistry and Repository詳細ビュー

この例では、Message Brokerノードのプロパティーでは、特定のユーザー・プロパティーを持つサービスを取得することも指定されています。図10に示すように、Registry and Repositoryコンソールを使用すると、これらのユーザー・プロパティーがあるかどうかポート（この例では、DemoCustomer）を確認することができます。

図10 サンプル・フローで使用されるユーザー・プロパティーのRegistry and Repositoryビュー

最後に、図11に示すように、Registry and Repositoryコンソールを使用して、ポートに指定された種別が含まれていることを確認することができます。

図11 サンプル・フローで使用される種別のRegistry and Repositoryビュー

この例では、特定の基準セットに基づいてRegistry and Repositoryで定義されたサービスを見つけて取得するために、Message Brokerノードのプロパティーで指定された値がどのように使用されるかを理解しました。図12に示すように、Registry and Repositoryコンソールを使用して起動する実際のサービス（この例では、Webサービス）を特定して、Webサービスのロケーション（SOAPアドレス）を表示することができます。

図12 サンプル・フローで使用されるport/portTypeのWebサービス・エンドポイントのRegistry and Repositoryビュー

このWebサービスのエンドポイントを変更する必要がある場合は、オリジナルの物理文書（例えばWSDL）を変更する必要があります。その後、Message Brokerフローに影響を与えずにこのエンドポイントをRegistry and Repositoryに再インポートすることができます。メディエーションを実行すると、更新されたエンドポイントがRegistry and Repositoryから取得されます。

上に戻る

任意のWSRRエンティティーにアクセスするサンプル・メッセージ・フロー

図 13に示すサンプルのMessage Brokerフローでは、特定のエンティティーのすべてのメタデータ・コンテンツを取得するためにSRRetrieveEntityノードが使用されています。これは、Registry and Repositoryに含まれる任意のエンティティー（ポリシー文書など）です。次に、サンプル・フローは、（サンプルのために）組み込みのComputeノードを使用して、取得したエンティティーのコンテンツを表示します。実際のフローでは、エンティティーのコンテンツを使用して、追加のロジックを実行するか、特定のポリシーを実施します。

図13 SRRetrieveEntityノードを使用するサンプルのMessage Brokerフロー

前の例で確認したように、ノード・プロパティー（この例では、SRRetrieveEntityノードのプロパティー）は、Registry and Repositoryで指定された基準と一致するエンティティーを見つけて取得するために使用されます。これらの基準を満たす場合は、すべてのエンティティーのメタデータが取得されて、Message BrokerのLocalEnvironmentに保管されます。その後Message Brokerフローは、コンテンツまたはメタデータの任意の部分を使用することができます。図14は、SRRetrieveEntityノードを実行した後のMessage BrokerのLocalEnvironmentのサンプル・コンテンツを示します。

図14 SRRetrieveEntityノードを実行した後のMessage Broker LocalEnvironmentの例

上に戻る

まとめ

今回確認したように、ESBは、対話するサービス・メタデータの変更の影響をすぐに受けます。これは、大部分のサービス・エンドポイント情報が、作成時にESBメディエーションで静的に定義されるためです。このメタデータを変更することで、企業は、時間、生産性、および応答性について莫大な損失を被ることがあります。SOAの動的な可能性を活用することを望んでいる開発者は、これには制約が多く法外なコストがかかると感じています。しかし、サービス・レジストリーを使用してこのメタデータを取得すると、より柔軟で安定したESBメディエーションを作成することができます。その結果、環境全体が変更の影響を受けにくくなります。WebSphere Message BrokerとWebSphere Service Registry and Repositoryを使用することで、ESBをより動的かつ柔軟にして、企業のニーズへの適応性を高めることができます。これは、少ない総コストでビジネスの応答性が向上することを意味します。

参考文献

学ぶために

製品や技術を入手するために

Message Broker V6 Client for Registry and Repository SupportPac, IA9L (US)

著者について


		Bob Pattenは、I/Tスペシャリストであり、Enterprise Integration Servicesの現場に基づいた開発の主席アーキテクトです。彼はSOA（特に、WebSphere Service Registry and RepositoryとWebSphere Message Brokerの統合に関連するSOA）に関心を持っています。EISグループに参加する前は、IBM SWG Componentization Strategic Initiative創設時のアーキテクトであり、IBM Software Groupポートフォリオ・コンポーネントのモデリング作業の指導者でした。


		Subhash Kumarは、IBM Software Group Enterprise Integration SolutionsチームのI/Tアーキテクトです。彼は、現場に基づいた開発の方法論を使用したIBMのSOAミドルウェア製品を使用して、これを拡張して行う、SOAソリューションの設計、開発、およびデプロイメントに関心を持っています。EISチームに参加する前は、IBM Software Group Distribution Sectorチームのソリューション・アーキテクトでした。このチームは、サプライ・チェーン（RFID）、エンタープライズ・アプリケーション統合、ポータル・ワークプレイス、小売業のアプリケーション・インフラストラクチャー、および小売業界および消費財業界向けの取引相手とのコラボレーション・ソリューションに重点的に取り組んでいました。


		Stuart Jonesは、Worldwide WebSphere Technical Salesチームの統合ソリューション・アーキテクトです。彼は、顧客、ビジネス・パートナー、およびその他のIBMチームがWebSphereポートフォリオ、およびさまざまなコンポーネントがどのように組み合わされて、相互動作するのかを理解できるよう支援しています。また、顧客がビジネスと技術的な要件をソリューション・アーキテクチャーにマップする方法を理解できるよう支援しています。以前は、CICS、WebSphere MQ、およびWebSphere Message Brokerのリリース時にIBM製品開発に取り組んでいました。

記事の評価

この記事を共有する


del.icio.us	newsing	FC2ブックマーク

Choix！	ニフティクリップ	Yahoo!ブックマーク

MM/memo	CZブックマーク	livedoorクリップ

はてなブックマーク	Buzzurl（バザール）

上に戻る

日本IBMについて

プライバシー

お問い合わせ