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

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

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

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

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

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

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

可能な使用方法

設計のステップ

  1. WSDL をインポートして、WSDL によって記述された SOAP メッセージの定義を含むメッセージ・セットを作成します。
  2. 例えば C ヘッダー・ファイルまたは COBOL コピーブックなどの既存のインターフェース定義を インポートすることにより、必要な既存のインターフェースにメッセージ・セットを適合させます。
  3. Web サービスをインプリメントするためのメッセージ・フローを開発します。

実行時

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

例 1

この例では、既存の HTTP Web サービス・クライアントが特定の対象 (株価、または為替レートなど) に関する情報を提供します。このサービスを社内のデータベース検索ソリューションに置き換える予定ですが、クライアントは広範囲にわたってデプロイされているため、クライアントを変更する予定はありません。

通常のメッセージ・フロー・パターンを次の例に示してあります。 どの場合も、中間要求ノードが次のようにしてデータベースで情報を検索します。

  1. SOAPInput ノードおよび SOAPReply ノードを使用する場合:
    この図は、SOAPInput ノードおよび SOAPReply ノードを使ってデータベース検索ソリューションとして機能するメッセージ・フローを示しています。
  2. HTTPInput ノードおよび HTTPReply ノードを使用する場合:
    この図は、HTTPInput ノードおよび HTTPReply ノードを使ってデータベース検索ソリューションとして機能するメッセージ・フローを示しています。

上記のフローでは、Input ノードが Web サービス要求を受信します。 すると、Compute1 は、必要な情報をデータベースから取り出し、そのデータを使用して必要な Web サービス応答を生成します。 その応答は、Reply ノードによってクライアントに返送されます。 この例では、Compute ノードに代えて、Mapping ノードを使用することができます。

例 2

この例では、既存アプリケーションは Web サービスとして公開されますが、Web サービスとのインターフェースに対しては制約があります。なぜなら、広範囲にわたって分散しているクライアントが、既存の WSDL 定義で定義されている似通ったサービスをすでに使用しているからです。 ブローカーは、同じインターフェースをクライアントに提供します。それは、元のサービスが別のサービス品質を提供しているか、または停止されることになっているからです。

通常のメッセージ・フロー・パターンを次の例に示してあります。 どの場合も、メッセージ・フローは、Web サービス要求を受信すると、WebSphere® MQを通してアプリケーションから戻されたデータを使用して、応答を作成します。

  1. SOAPInputSOAPReply、および MQGet ノードを使用する場合:
    この図は、前後の本文で説明されているメッセージ・フローを示しています。
  2. HTTPInputHTTPReply、および MQGet ノードを使用する場合:
    この図は、前後の本文で説明されているメッセージ・フローを示しています。
  3. 2 つのメッセージ・フローで SOAPInput ノードおよび SOAPReply ノードを使用する場合:
    この図は、前後の本文で説明されているメッセージ・フローを示しています。
  4. 2 つのメッセージ・フローで HTTPInput ノードおよび HTTPReply ノードを使用する場合:
    この図は、前後の本文で説明されているメッセージ・フローを示しています。
メッセージ・フローを開発するステップは次のとおりです。
  1. たとえば、アプリケーション用の C ヘッダー・ファイルをインポートすることによって、既存アプリケーション・インターフェース用のメッセージ・モデルを作成します。
  2. クライアント用の既存の WSDL 定義をインポートします。
  3. メッセージ・セットを使用してフローを作成し、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 に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

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

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

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


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