このトピックでは、Web サービス・クライアントが WebSphere Business Integration Message Broker と対話する 4 つのシナリオについて説明されています。 これらには決定的なリストは含まれていませんが、 Web サービス・アプリケーション用にサポートされているオプションのいくつかを表しています。
このシナリオでは、通常、HTTPRequest ノード・プロパティーの 「入力メッセージを Web サービス応答に置換する (Replace input message with web service response)」チェック・ボックスのチェックをクリアし、 同じノードにある「ツリー内の応答メッセージの位置 (Response message location in tree)」プロパティーで指定されているメッセージ・ツリー内の一時的な位置に企業ディレクトリー・サーバーからの応答を配置します。 Compute2 では、ESQL をコーディングして結果をアンパックし、最終メッセージを適切に拡大します。
Compute1 の ESQL をコーディングしてクライアントの要求をサーバーの要求にマップし、 Compute2 でサーバーの応答をクライアントの返信にマップします。 MRM ドメインにあるこれらの要求、返信、および応答メッセージを定義して、 1 つの形式から別の形式への変換を単純化することができます。
HTTPRequest ノードを構成して、HTTPInput ノードによって受信されるヘッダーから HTTP ヘッダーを生成することができ、 それは移動する cookie および他のアプリケーション固有のヘッダーを考慮にいれています。 HTTPReply ノードは同等のタスクを提供して、 発信しているクライアントに戻るために、Web サービスからの応答からヘッダーを抽出することができます。 そのためには、 HTTPRequest ノードと HTTPReply ノードの両方で、 それぞれに該当する「..... からデフォルトの HTTP ヘッダーを生成する (Generate default HTTP headers from.....)」チェック・ボックスを選択します。
ほとんどのシナリオで、元の要求には価値がなく、 クライアントの応答メッセージを生成できるようにサービスからの応答のみを必要とします。 その場合は、 HTTPRequest ノードで、 「入力メッセージを Web サービス応答に置換する (Replace input message with web service response)」プロパティーを選択します。 入力要求から任意のデータを保存したい場合、 これを Compute1 の LocalEnvironment に保管し、返信に組み込むための Compute2 でそれを検索します。
入力または出力用に現在 WebSphere MQ を使用している ほとんどのメッセージ・フローは、置換または追加のプロトコルとして HTTP を使用するのに適しています。
MRM ドメインにある入力メッセージをモデル化し、モデルから WSDL を生成することができます。 または汎用 XML または XMLNS ドメイン・メッセージを処理することができます。 MRM ドメインにあるメッセージを定義した場合、 HTTPInput ノードを構成して入力メッセージを妥当性検査することができます。 メッセージがモデルに準拠しない場合、ノードは例外を生成します。
HTTPReply ノードを構成して、クライアントに送信する応答メッセージ用の デフォルトの HTTP ヘッダーのセットを生成することができます。 これは、メッセージ・フローを WebSphere MQ メッセージを処理するものから HTTP を処理するフローに変換するために行わなければならない変更を削減します。
最初のメッセージ・フローは、HTTPInput ノードの Web サービス・クライアントから、インバウンド要求を受け取ります。 それには、ある方法で要求を変換するためのCompute ノード、 および変更された要求を WebSphere MQ アプリケーションに送る MQOutput ノードが含まれています。
2番目のメッセージ・フローは、MQInput ノード内のそのアプリケーションから応答を受け取ります。 メッセージは、メッセージを変換し、元の Web サービス・クライアントへの返信としてそれを送る HTTPReply ノードに メッセージを伝搬する Compute ノードに渡されます。
各 Compute ノードによって完了した変換は単純な場合がありますが、 最初の ESQL コードは、WebSphere MQ アプリケーションからの返信が元の要求を送った クライアントに戻ることを保証するために、2番目によって検索された HTTP の状態についての情報を保管する必要があります。
最初のメッセージ・フローはメッセージを受け取り、何であれ必要な変換を行い、 アウトバウンド・メッセージにある HTTP 要求 ID をエンコードします。 (望むなら、要求 ID をデータベースに保管することもできます。) HTTPInput ノードは、Destination.HTTP.RequestIdentifier と呼ばれる LocalEnvironment ツリーにある フィールドとして、要求 ID を提供し、Compute1 はこの値を読み取り、保管することができます。
2 番目のメッセージ・フローは応答メッセージを受け取り、 クライアント・メッセージ形式にそれを変換します。 Compute2 は、メッセージから HTTP 要求 IDを読み取り、 この値を使用して LocalEnvironment.Destination.HTTP.RequestIdentifier を設定します。 HTTPReply ノードは、要求 ID を使用して、メッセージが適切な HTTP クライアントに到達するよう保証します。
このシナリオのインプリメンテーションは、MQMD の適切な処理を必要とします。 HTTP を介するメッセージになるメッセージは、MQOutput ノードに送られる前に、MQMD を追加する必要があります。 また、HTTPReply または HTTPRequest ノードの外に進む前に、 WebSphere MQ を介するようになるいかなるメッセージも、 MQMD を除去する必要があります (HTTP ストリームに MQMD を含むことが望まれていない場合)。
Compute1 のための ESQL モジュールには、このようなステートメントが含まれています。
SET OutputRoot.XML.A.MessageID = CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
Compute 2 のための ESQL モジュールには、このようなステートメントがコーディングされています。
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XML.A.MessageID AS BLOB);
関連概念
WebSphere MQ Web Services Transport
Web サービス記述言語 (WSDL) の生成
関連タスク
メッセージ・フローの作成
特定の Web サービス・シナリオのノードの構成
メッセージ・フロー・アプリケーションのデプロイ
デプロイメントの結果の検査
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
ac20440_ |