このシナリオでは、ブローカーは既存の Web サービス・インターフェースをインプリメントします。Web サービス用の WSDL はすでに存在し、メッセージ・セットの作成のためにインポートされます。
このメッセージ・セットをベースとするメッセージ・フローは、要求を受信してから、既存の Web サービス以外のアプリケーションから得たデータを使用して応答メッセージを作成します。

記号を理解する手掛かり:

可能な使用方法
- ブローカーは Web サービス・インプリメンテーションに、既存のインプリメンテーションからの異なる品質のサービスを提供します。
- ブローカーは、既存のインプリメンテーションのためのマイグレーション戦略を提供します。
設計のステップ
- WSDL をインポートして、WSDL によって記述された SOAP メッセージの定義を含むメッセージ・セットを作成します。
- 例えば C ヘッダー・ファイルまたは COBOL コピーブックなどの既存のインターフェース定義を
インポートすることにより、必要な既存のインターフェースにメッセージ・セットを適合させます。
- Web サービスをインプリメントするためのメッセージ・フローを開発します。
実行時
メッセージ・フローは Web サービス要求を受け取り、それを既存のアプリケーションが予期する形式に変換して、既存のアプリケーションを呼び出します。既存のアプリケーションからの応答は、有効な Web サービス応答に変換されます。
例 1
この例では、既存の HTTP Web サービス・クライアントが特定の対象 (株価、または為替レートなど) に関する情報を提供します。このサービスを社内のデータベース検索ソリューションに置き換える予定ですが、クライアントは広範囲にわたってデプロイされているため、クライアントを変更する予定はありません。
通常のメッセージ・フロー・パターンを次の例に示してあります。
どの場合も、中間要求ノードが次のようにしてデータベースで情報を検索します。
- SOAPInput ノードおよび SOAPReply ノードを使用する場合:
- HTTPInput ノードおよび HTTPReply ノードを使用する場合:
上記のフローでは、Input ノードが Web サービス要求を受信します。
すると、Compute1 は、必要な情報をデータベースから取り出し、そのデータを使用して必要な Web サービス応答を生成します。
その応答は、Reply ノードによってクライアントに返送されます。
この例では、Compute ノードに代えて、Mapping ノードを使用することができます。
例 2
この例では、既存アプリケーションは Web サービスとして公開されますが、Web サービスとのインターフェースに対しては制約があります。なぜなら、広範囲にわたって分散しているクライアントが、既存の WSDL 定義で定義されている似通ったサービスをすでに使用しているからです。
ブローカーは、同じインターフェースをクライアントに提供します。それは、元のサービスが別のサービス品質を提供しているか、または停止されることになっているからです。
通常のメッセージ・フロー・パターンを次の例に示してあります。
どの場合も、メッセージ・フローは、Web サービス要求を受信すると、WebSphere® MQを通してアプリケーションから戻されたデータを使用して、応答を作成します。
- SOAPInput、SOAPReply、および MQGet ノードを使用する場合:
- HTTPInput、HTTPReply、および MQGet ノードを使用する場合:
- 2 つのメッセージ・フローで SOAPInput ノードおよび SOAPReply ノードを使用する場合:
- 2 つのメッセージ・フローで HTTPInput ノードおよび HTTPReply ノードを使用する場合:
メッセージ・フローを開発するステップは次のとおりです。
- たとえば、アプリケーション用の C ヘッダー・ファイルをインポートすることによって、既存アプリケーション・インターフェース用のメッセージ・モデルを作成します。
- クライアント用の既存の WSDL 定義をインポートします。
- メッセージ・セットを使用してフローを作成し、Web サービス・インターフェースをインプリメントし、既存アプリケーションとの調停を行います。
メッセージ・フロー 1 および 2 は、
MQOutput および
MQGet ノードを使った、アプリケーションの同期呼び出しを示しています。
MQGet ノードでタイムアウトを設定して、リモート・アプリケーションの障害に備えることができます。
要求と応答の変換は、単一トランザクション内で処理されるので、ロールバックとリカバリーを単純化することができます。
ただし、各着信要求が完全に処理されて応答されてから、次の要求に移る必要があります。
アプリケーションが迅速に応答できない場合、この動作のためにパフォーマンスが影響を受ける可能性があります。
例 3 および 4 に示されているメッセージ・フローは、それと同等の非同期のものを示しています。
いずれの場合も、最初のフローは、メッセージをアプリケーションに送信した後に停止し、さらに別の要求の処理で使用できるようになります。
ただし、このシナリオでは、相関コンテキストを要求フロー内に保存し、応答フロー内で復元する必要があります。
相関コンテキストをキューに保管した後、応答フローの
MQGet ノードを使用して、それを取り出すことができます。
このフローの設計では、要求をアプリケーションに速やかにディスパッチし、受信順に応答を返送できるようになっています。
この例では、
Compute ノードに代えて、
Mapping ノードを使用することができます。
これらのシナリオでは、SOAP ドメインを使用するのが望ましいと思われます。
Web サービス用のドメインの選択の詳細は、WebSphere Message Broker と Web サービスを参照してください。
非同期要求/応答のシナリオの詳細は、MQGet ノードを使用する要求-応答シナリオ を参照してください。
非同期要求-応答のシナリオの詳細については、以下のサンプルでも説明されています。このサンプルを、Web サービスの使用に適合させることができます。
別の Web サービスのシナリオは、次のサンプルの中で説明されています:
サンプルに関する情報は、WebSphere Message
Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message
Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。