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

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

ブローカーによる新規 Web サービス・インターフェースのインプリメント

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

次の図は、現在は Web サービスとしてアクセス可能ではない既存のアプリケーションのインターフェース定義 (例えば、ヘッダー・ファイル) から作成されたメッセージ・セットを示しています。 WSDL ファイルは、メッセージ・セットから生成されて、Web サービス・クライアントが使用できるようにエクスポートされます。 アプリケーションを呼び出すために、メッセージ・セットおよび WSDL を使用するメッセージ・フローが作成されます。 メッセージ・フローとメッセージ・セットは、ブローカーにデプロイされて、元のアプリケーションに対して Web サービス・インターフェースを提供します。

この図については、前後のテキストで説明されています。

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

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

このシナリオは、Web サービス・ファサードと呼ばれることもあります。 Web サービス・インターフェースの設計は、通常いくらかの再グループ化や既存のインターフェースの制限または強化が含まれ、既存の WSDL 定義には制約されません。

可能な使用方法

設計のステップ

  1. 例えば C ヘッダー・ファイルまたは COBOL コピーブックなどの既存のインターフェース定義を インポートすることにより、ビジネス・メッセージ用のメッセージ・セットを作成します。
  2. メッセージ・セットから WSDL 定義を生成します。
  3. Rational® Application Developer などの SOAP ツールキットを使用して、WSDL に基づく適切な Web サービス・クライアントを作成します。
  4. Web サービスをインプリメントするためのメッセージ・フローを開発します。

実行時

メッセージ・フローは Web サービス要求を受け取り、それを既存のアプリケーションが予期する形式に変換して、既存のアプリケーションを呼び出します。既存のアプリケーションからの応答は、有効な Web サービス応答に変換されます。

例 1

この例では、既存のメッセージ・フローを変更して、Web サービスを提供します。 既存のメッセージ・フローが、メッセージ・セット内のデータをモデル化する場合、そのメッセージ・セットから WSDL 定義を生成して、クライアントが使用できるようにすることができます。

入力または出力用に現在 WebSphere® MQ を使用しているほとんどのメッセージ・フローは、置換または追加のプロトコルとして Web サービスをサポートするのに適しています。

通常のメッセージ・フロー・パターンを以下に示します。 どの場合も、Input ノードと Reply ノードが、元の MQInput および MQOutput ノードに取って代わるか、または補完します。 このフローの主な部分を理解すれば、有用な処理を行うことができます。
  • SOAPInput および SOAPReply ノードを使用する場合:
    この図は、SOAPInput および SOAPReply ノードを使って Web サービスを提供するメッセージ・フローを示しています。
  • HTTPInput および HTTPReply ノードを使用する場合:
    この図は、HTTPInput および HTTPReply ノードを使って Web サービスを提供するメッセージ・フローを示しています。

SOAP ドメインを使用する場合、論理ツリーの形状は元のドメインのものとは異なるため、メッセージ・フローではその点を考慮に入れておく必要があります。 元のドメインで HTTP ノードを使用する場合、論理ツリーの形状は変わりません。 ドメインの選択の詳細は、WebSphere Message Broker と Web サービスを参照してください。

HTTP の詳細
HTTP ノードを使用する場合、HTTPReply ノードを構成して、クライアントに送信する応答メッセージ用のデフォルトの HTTP ヘッダーのセットを生成することができます。 デフォルトの HTTP ヘッダー・セットを生成すれば、メッセージ・フローを WebSphere MQ メッセージの処理用から、HTTP メッセージの処理用のフローに変換するために行う必要のある変更数が減ります。

例 2

この例では、WebSphere MQ アプリケーションへの非同期アクセス用のメッセージ・フローが作成されます。

通常のメッセージ・フロー・パターンを以下に示します。 どの場合も、フローは、Web サービス要求を受信すると、WebSphere MQ を通してアプリケーションから戻されたデータを使用して、応答を作成します。
  • 2 つのメッセージ・フローで SOAPInput および SOAPReply ノードを使用する場合:
    この図は、SOAPInput および SOAPReply ノードを使って WebSphere MQ アプリケーションへの非同期アクセスを提供する 2 つのメッセージ・フローを示しています。
  • 2 つのメッセージ・フローで HTTPInput および HTTPReply ノードを使用する場合:
    この図は、HTTPInput および HTTPReply ノードを使って WebSphere MQ アプリケーションへの非同期アクセスを提供する 2 つのメッセージ・フローを示しています。

どの場合も、最初のメッセージ・フローは、Web サービス・クライアントからインバウンド要求を受信します。 Compute1 ノードは、要求を変換し、MQOutput ノードは、変更後の要求を既存アプリケーションに送信します。

2 番目のメッセージ・フローでは、MQInput ノードがアプリケーションから応答を受信します。 その後 Compute2 ノードは、メッセージを変換してから、元の Web サービス・クライアントに応答する Reply ノードにそのメッセージを伝搬します。

Compute1 ノードは、Compute2 ノードによって検索される特定の相関情報も保存する必要があります。それによって、WebSphere MQ アプリケーションからの応答は、元の要求を送信したクライアントに必ず返送されます。

HTTP の詳細

HTTPInput および MQOutput ノードをアウトバウンド・メッセージとして使用し、MQInput および HTTPReply ノードを応答メッセージとして使用する場合:

この図は、HTTPInput および MQOutput ノードをアウトバウンド・メッセージとして、MQInput および HTTPReply ノードを応答メッセージとしてそれぞれ使用する方法を示しています。

相関情報を保存する方法の 1 つとして、Compute1 ノードがアウトバウンド・メッセージ内で相関 ID をエンコードする方法があります。(別の方法として、ID をデータベースに保管することもできます。) SOAPInput および HTTPInput ノードは、ローカル環境ツリー内のフィールドとして ID を入れます。これにより、Compute1 ノードは、その値を読み取って保管することができます。以下のセクションで説明されているように、ID の位置は SOAPInput ノードと HTTPInput ノードで異なります。

SOAP ノード

Compute2 ノードは、メッセージから SOAP 応答 ID を読み取り、この値を使用して LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier を設定します。SOAPReply ノードは、応答 ID を使用して、メッセージが正しい HTTP クライアントに必ず届くようにします。Compute1 ノードの ESQL モジュールに、以下のステートメントのようなコード・ステートメントを組み入れます。
SET OutputRoot.XMLNS.A.MessageID = 
CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
Compute2 ノードの ESQL モジュールに、以下のステートメントのようなコード・ステートメントを組み入れます。
SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier = 
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);

HTTP ノード

Compute2 ノードは、メッセージから HTTP 要求 ID を読み取り、この値を使用して LocalEnvironment.Destination.HTTP.RequestIdentifier を設定します。HTTPReply ノードは、要求 ID を使用して、メッセージが正しい HTTP クライアントに必ず届くようにします。 Compute1 ノードの ESQL モジュールに、以下のステートメントのようなコード・ステートメントを組み入れます。
SET OutputRoot.XMLNS.A.MessageID = 
CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
Compute2 ノードの ESQL モジュールに、以下のステートメントのようなコード・ステートメントを組み入れます。
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = 
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

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

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


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