このシナリオでは、ブローカーが既存の Web サービス・インプリメンテーションを呼び出します。

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

可能な使用方法
- メッセージ・フローがあり、Web サービスとしてすでに使用可能な機能をそれが使用するようにしたい場合。
- 既存の Web サービスがあり、それに別のインターフェースを提供したい場合。
例えば、代替 Web サービス・インターフェース、またはWebSphere MQ インターフェースなどです。
- 既存の Web サービスがあり、インターフェースを変更しないでそのインプリメンテーションに何かの変更を行いたい場合。つまり、ブローカーは Web サービスに対する仲介者になります。例えば、メッセージ・フローを使用して監査を使用可能にしたり、Web サービスの応答を他のアプリケーションに透過的に伝搬します。
設計のステップ
- WSDL をインポートして、WSDL によって記述された SOAP メッセージの定義を含むメッセージ・セットを作成します。
- Web サービスを呼び出すためのメッセージ・フローを作成します。Web サービス・トランスポートが HTTP である場合、HTTPrequest ノードが使用されます。Web サービス・トランスポートが JMS である場合、適切な JMS または WebSphere MQ ノードが使用されます。
実行時
メッセージ・フローは適切にフォーマット設定された Web サービス要求を作成し、Web サービスを呼び出して、Web サービス応答を構文解析します。
例 1
これは、ブローカーが Web サービスへの仲介者として動作する例です。
- メッセージ・フローを、HTTPInput、HTTPRequest、および HTTPReply ノードを使用して作成します。
- Web サービス・クライアントは、Web サービス要求を生成します。そのサービス要求は、ブローカーによって HTTPInput ノードに送信されます。
- メッセージ・フローは、何かの方法でメッセージを処理します。
- HTTPRequest ノードは要求を元の Web サービスに送り、応答を受け取ります。
- フローは Web サービス応答を生成して、それを HTTPReply ノードに入れます。応答の全部または一部は、HTTPRequest ノードによって受け取られた応答に基づく可能性があります。
- ブローカーは、応答を Web サービス・クライアントに送信します。
WebSphere MQ で使用可能な別のアプリケーションが異なる形式での情報を必要とする場合、メッセージ・フローは、メッセージが最初に MQOutput ノードに伝搬されてこのアプリケーションに伝送され、その後フローの最後まで続行して、HTTPReply ノードが期待される Web サービス応答を送信するように取り決めることができます。適切な Compute ノードが、メッセージの変換 (必要な場合)、
およびメッセージ・ヘッダーの取り扱い (MQMD ヘッダーの追加など) のために必要とされます。
例 2
この例では、ブローカーは Web サービスのための監査を提供します。
- Warehouse ノードに接続された HTTPInput ノードを組み込んだメッセージ・フローを設計します。
- Web サービス・クライアントから受信した入力メッセージは、Warehouse ノードによってデータベースに格納されます。
- Warehouse ノードは、そのメッセージを Web サービスと対話する HTTPRequest ノードに渡します。
- 応答が受信されると、HTTPRequest ノードはその応答を、HTTPReply ノードに伝搬します。
- HTTPReply ノードは、Web サービス・クライアント用の応答を生成します。
例 3
- WebSphere MQ フローが Web サービスと対話する
- HTTP 接続を介して Web サービスにアクセスする
WebSphere MQ メッセージ・フローを設計します。
例えば、お客様の会社の人的資源部門のプロセスをサポートするメッセージ・フローを作成します。
プロセスでは、従業員 ID 番号を検索し、この情報を使ってメッセージを拡張する必要があります。
従業員 IDは、Web サービスを通してアクセスされる会社の従業員ディレクトリーで維持されます。

このシナリオでは、通常、HTTPRequest ノード・プロパティーの
「入力メッセージを Web サービス応答に置換する」チェック・ボックスのチェックをクリアし、同じノードにある「ツリー内の応答メッセージの位置」プロパティーで指定されているメッセージ・ツリー内の一時的な位置に企業ディレクトリー・サーバーからの応答を配置します。Compute2 では、ESQL をコーディングして結果をアンパックし、最終メッセージを適切に拡大します。
例 4
- メッセージ・フローは Web サービスの仲介として動作する。
- 新規インターフェースを認識していない Web サービス・クライアントの代わりに、
インターフェースを更新した Web サービスと対話するメッセージ・フローを設計します。
この新しいメッセージ・フローによって、より古いクライアントは自身のインターフェースを更新せずに、
新規インターフェースを使用してサーバーにアクセスすることができます。

Compute1 の ESQL をコーディングしてクライアントの要求をサーバーの要求にマップし、
Compute2 でサーバーの応答をクライアントの返信にマップします。
MRM ドメインにあるこれらの要求、返信、および応答メッセージを定義して、
1 つの形式から別の形式への変換を単純化することができます。
HTTPRequest ノードを構成して、HTTPInput ノードによって受信されるヘッダーから
HTTP ヘッダーを生成することができ、
それは移動する cookie および他のアプリケーション固有のヘッダーを考慮にいれています。
HTTPReply ノードは同等のタスクを提供して、
発信しているクライアントに戻るために、Web サービスからの応答からヘッダーを抽出することができます。
そのためには、HTTPRequest ノードと HTTPReply ノードの両方で、それぞれに該当する「..... からデフォルトの HTTP ヘッダーを生成する」チェック・ボックスを選択します。
ほとんどのシナリオで、元の要求には価値がなく、
クライアントの応答メッセージを生成できるようにサービスからの応答のみを必要とします。
その場合は、HTTPRequest ノードで、「入力メッセージを Web サービス応答に置換する」プロパティーを選択します。入力要求から任意のデータを保存したい場合、
これを Compute1 の LocalEnvironment に保管し、返信に組み込むための Compute2 でそれを検索します。