WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

ブローカーによる既存の Web サービスの呼び出し

このシナリオでは、ブローカーが既存の Web サービス・インプリメンテーションを呼び出します。 Web サービス用の WSDL はすでに存在し、メッセージ・セットの作成のためにインポートされます。

このメッセージ・セットをベースにしたメッセージ・フローは、例えば SOAPRequest ノードを使用して、Web サービス要求を送信し、応答を受信します。

既存の Web サービスと、それを記述する WSDL を示す図。 WSDL は、メッセージ・セットを作成するためにインポートされます。
メッセージ・セットを使用するメッセージ・フローが作成されて、Web サービスが呼び出されます。この両者とも、ブローカーにデプロイされます。

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

この図には、他の図で使用される記号が説明されていますが、これはそれぞれの図に記述されているためにここでは説明をしません。

可能な使用方法

設計のステップ

  1. WSDL をインポートして、WSDL によって記述された SOAP メッセージの定義を含むメッセージ・セットを作成します。
  2. Web サービスを呼び出すためのメッセージ・フローを作成します。 SOAP ドメインを使用する場合は、メッセージ・フロー は、SOAPRequest ノード、SOAPAsyncRequest ノード、または SOAPAsyncResponse ノードを使用します。 ノードは、ステップ 1 でインポートした WSDL を使って構成されます。必要があれば、ブランクのメッセージ・フロー・エディターのキャンバスに WSDL をドロップすることによって、スケルトン・フローを最初から作成することができます。 SOAP ドメインを使用する場合は、トランスポート・ノードおよび、XML または MIME ドメインを使用して、メッセージ・フローを作成する必要があります。 例えば、WSDL バインディングが HTTP トランスポートを指定し、要求メッセージが SOAP である場合、HTTPRequest ノードを XMLNSC ドメインで使用することができます。 その後、Web サービスに関するエンドポイント情報を使用して、ノードを手動で構成することができます。
  3. デプロイメント用のブローカー・アーカイブ・ファイルを作成します。 ブローカー・アーカイブ・ファイルには、メッセージ・フローと、インポートされた WSDL の入ったメッセージ・セットが格納されます。 SOAP ドメインでは、WSDL が必ずデプロイされる必要があります。なぜなら、メッセージは、実行時に WSDL に照らして検証されるからです。論理ツリーには、WSDL 情報も組み込まれます。 メッセージ・セットには、SOAP、XMLNSC、または MRM ドメインでのメッセージの検証で使用できる XML スキーマ定義が入っています。

実行時

メッセージ・フローは適切にフォーマット設定された Web サービス要求を作成し、Web サービスを呼び出して、Web サービス応答を構文解析します。 SOAP ドメインを使用すると、メッセージ・フローでは SOAP 論理ツリー・モデルが使用されます。 SOAP ドメインを使用しない場合は、選択したドメインの論理ツリーがメッセージ・フローで使用されます。例えば、Web サービス・メッセージが SOAP with Attachments を使用する場合は、MIME ドメインを使用します。

例 1

Web サービスの仲介
この例では、クライアント・アプリケーションは Account という Web サービスを使用します。これは、別の組織によって使用可能にされた Web サービスです。 このクライアントは、社内で広範囲にわたって分散されています。 クライアントは、getBalance という操作を使用しますが、この getBalance 操作の定義を変更するために、Account サービスは変更されようとしています。 クライアントを変更する代わりに、Account サービスへのインターフェースを提供するメッセージ・フローを構成することができます。 そのメッセージ・フローは、Account サービスを呼び出して作業を行い、新規の Web サービスが、元の Web サービスを代行します。 これでクライアントは、新規のメッセージ・フローを使って、引き続き Account サービスを利用できます。
ここで示した通常のメッセージ・フロー・パターンの例では、中間要求ノードが Account サービスを呼び出します。
  • SOAPInputSOAPRequest、および SOAPReply ノードを使用する場合:
    この図は、SOAPInput、SOAPRequest、および SOAPReply ノードを使って Account サービスへのインターフェースを提供するメッセージ・フローを示しています。
  • SOAPInputSOAPAsyncRequestSOAPAsyncResponse、および SOAPReply ノードを使用する場合:
    この図は、SOAPInput、SOAPAsyncRequest、SOAPAsyncResponse、および SOAPReply ノードを使って Account サービスへのインターフェースを提供する 2 つのメッセージ・フローを示しています。
  • HTTPInputHTTPRequest、および HTTPReply ノードを使用する場合:
    この図は、HTTPInput、HTTPRequest、および HTTPReply ノードを使って Account サービスへのインターフェースを提供するメッセージ・フローを示しています。

例の中のメッセージ・フローでは、変更後の Account サービスからの要求どおりに、Compute1 が元の getBalance メッセージを変更するのに対して、Compute2 は、応答メッセージを元のフォーマットに復元します。 WSDL のインポートまたは生成が完了すると、getBalance 操作用のメッセージ・モデルが用意されます。 getBalance 操作用のメッセージ・モデルが定義されている場合、Compute ノードに代えて、Mapping ノードを使用することができます。

HTTP の詳細

例に示されているとおりに HTTP トランスポート・ノードを使用する場合、HTTPRequest ノードを構成して、HTTPInput ノードで受信したヘッダーから HTTP ヘッダーを生成することができます。 この構成により、cookie およびその他のアプリケーション固有のヘッダーをメッセージ・フローを通して渡せるようになります。 HTTPReply ノードをタスクで使用して Web サービス応答からヘッダーを抽出し、元のクライアントに戻すことができます。 この構成を作成するには、HTTPRequest および HTTPReply の両方のノードで 「デフォルト HTTP ヘッダーの生成元」を選択します。 一般的に、クライアントへの応答を生成するのに元の要求メッセージは必要ないので、HTTPRequest ノード上で「入力メッセージを Web サービス応答に置換」を選択することができます。 入力要求のデータを保存したい場合、それを Compute1 の LocalEnvironment に保管し、Compute2 から取り出して応答に組み込みます。

例 2

Web サービスの使用
この例では、WebSphere MQ メッセージ・フローが、ある会社の人事部のプロセスをインプリメントします。 この処理の一環として、メッセージ・フローは Web サービスを呼び出して、社員 ID 番号を検索します。 社員 ID 番号は、Web サービスを通してアクセスできる社員ディレクトリーで保守されます。
ここで示した通常のメッセージ・フロー・パターンの例では、中間要求ノードが employee ID を呼び出します。
  • MQInputSOAPRequest、および MQOutput ノードを使用する場合:
    この図は、MQInput、SOAPRequest、および MQOutput ノードを使って Web サービスを呼び出すメッセージ・フローを示しています。
  • MQInputSOAPAsyncRequestSOAPAsyncResponse、および MQOutput ノードを使用する場合:
    この図は、MQInput、SOAPAsyncRequest、SOAPAsyncResponse、および MQOutput ノードを使って Web サービスを呼び出す 2 つのメッセージ・フローを示しています。
  • MQInputHTTPRequest、および MQOutput ノードを使用する場合:
    この図は、MQInput、HTTPRequest、および MQOutput ノードを使って Web サービスを呼び出すメッセージ・フローを示しています。

この例の中のメッセージ・フローでは、Compute1 が Web サービスの要求メッセージを準備し、Compute2 が応答を処理します。 例えば、社員 ID を別のメッセージに組み入れるとします。 メッセージ・モデルが定義されている場合、この例では、Compute ノードに代えて、Mapping ノードを使用することができます。

HTTP の詳細

例に示されているとおりに HTTP トランスポート・ノードを使用する場合、通常は、HTTPRequest ノードのプロパティーの「入力メッセージを Web サービス応答に置換」をクリアします。 社内ディレクトリー・サーバーからの応答は、メッセージ・ツリー内の一時ロケーションに置かれます。 一時ロケーションは、同じノードのツリー・プロパティー内の「応答メッセージ・ロケーション」に指定します。 Compute2 では、結果の検索と最終メッセージの更新のための ESQL をコーディングすることができます。

この図は、メッセージ・ツリー内の一時ロケーションに Web サービス応答を入れた後、それを検索できることを示しています。

これらのシナリオでは、SOAP ドメインを使用するのが望ましいと思われます。 Web サービス用のドメインの選択の詳細は、WebSphere Message Broker と Web サービスを参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:50


概念トピック概念トピック | バージョン 8.0.0.5 | ac34530_