ブローカーが既存の Web サービス・インターフェースをインプリメントする方法についての詳細

Web サービス・クライアントがあり、ブローカーが既存の非 Web サービス機能を使用できるようにする典型的なエンドツーエンドのシナリオについて学びます。

C または COBOL ベースの既存のシステムが、Web サービスとして役に立つように公開できるビジネス・ロジックを提供しています。

直前の例 (ブローカーが新規 Web サービスをインプリメントする方法についての詳細) と同様に、ブローカーが既存のシステム上の操作を呼び出す (つまりシステムがブローカーにインターフェースを公開する) ためには、いくつかの手段があります。通常は、既存のシステムで WebSphere® MQ が使用可能になります。 つまり、システムがアプリケーション・データを含む MQ メッセージを受け取り、 これらを基礎となるインプリメンテーションにディスパッチしてから、戻り値を WebSphere MQ 応答としてパッケージします。これら既存の操作に提供され、そこから戻されるデータ構造は、 C ヘッダー・ファイルまたは COBOL コピーブックで定義されています。

ただし、この例では、Web サービス・クライアントの WSDL 定義が既に存在しているので、Web サービスは、提供しなければならない機能だけに制限されます。

一例として、広く分散した Web サービスのクライアントがユーザーに特定のビジネス機能へのアクセス権をすでに付与している、というシナリオが考えられます。その場合、ブローカーの役割は、既存のシステムに基づく新規のインプリメンテーションに同じインターフェースを提供することです。 元の Web サービス・プロバイダーが異なる品質のサービスを提供するようになるか、または何かの理由でサービスを終了する可能性があります。

前の場合と同様に、ブローカーは WebSphere MQ を介して既存のシステム機能を呼び出すことができます。

シナリオをインプリメントする方法は、以下のとおりです。

  1. C インポーターを使用するなどして、既存の API データ構造をインポートします。文書スタイルの WSDL を使用する場合、インポーター・ウィザードが必要なグローバル・エレメントを ブローカー・モデル内に作成するようにしなければなりません。 Web Services Interoperability Organization (WS-I) は、Web サービス・ペイロードがネーム・スペースで修飾されることを勧めているので、ユーザーはインポートの際にターゲットのネーム・スペースを指定する必要があります。

    この段階で、 既存の操作を呼び出すときに使用するデータのメッセージ・モデルを持つことになります。

  2. 既存の WSDL ファイルをインポートして、期待されるインスタンス文書のための 適切なメッセージ・モデルを作成します (データ構造のインポートを参照してください)。フローは対応する SOAP 要求を構文解析して、必要な既存データ形式との間で変換を行う必要があります。 インポートされたメッセージ定義を検査し、ESQL またはマッピング・エディターを使用して、フローの作成を補助できます。ブローカー・モデルからカテゴリー・ファイルを作成すること、または WSDL を生成することはしません。
  3. WSDL インポート・ステップにより、適切な SOAP mxsd ファイルがメッセージ・セットに自動的に組み込まれます。インポートには特に、SOAP エンベロープ mxsd ファイルおよび (必要な場合) SOAP エンコード mxsd ファイルが含まれます。
  4. Web サービス要求を受け取るため、つまり Web サービス・プロバイダーとして機能するための、メッセージ・フローをインプリメントします。エンドポイント・ノードは、クライアントが使用するトランスポートに応じて、HTTP または WebSphere MQ となります。 入力ノード・プロパティーは、以下のとおりです。
    • メッセージ・ドメイン: MRM
    • メッセージ・セット: SOAP エンベロープ定義を含むメッセージ・セット
    • メッセージ・タイプ: エンベロープ
    • メッセージ形式: XML1
  5. フローによって呼び出されたパーサーは、用意されている SOAP mxsd ファイルで定義されている SOAP エンベロープに相当する論理ツリーを作成します。構文解析は、SOAP エンベロープ (SOAP 本体およびヘッダー) 内の接続ポイント で自動的に続行して、メッセージ・セット内の他のメッセージ定義に対する突き合わせを試行します。 必要であれば、入力ノードでの妥当性検査を適用します。

    この段階で、論理ツリーはありますが、どの SOAP ペイロードが受信されたかは分かりません。 「HTTP SOAPAction/action」フィールドを調べて、可能性のある内容を判別することはできますが、これが有効なのは HTTP だけです。 (SOAPAction の使用は、WS-I では勧められていません。)

  6. 許可されたペイロード・メッセージから既存のシステムにある必要なメッセージへの 単一のマッピングを提供できます。 例えば、単一のマッピング定義はメッセージ message1amessage1b を同じターゲット message2 にマップできます。
    その代わりに、各メッセージ・タイプ、または関連するメッセージ・タイプのグループに対して、別々のマッピングを提供することもできます。このアプローチにより、より管理可能で再使用可能なマッピング定義を作成できます。 欠点は、どのペイロードを受け取ったかを判別してからでなければ、マッピングを適用できないことです。ESQL は以下のようにコーディングできます。
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = 'foo') ...
     
    またはフィールド参照を使用して、以下のように行います。
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = "foo") ...
     
    内容が判明していれば、フローを適切に分岐して (例えば、RouteToLabel ノードを使用)、各分岐に内容固有の Mapping ノードと Compute ノードのいずれかまたは両方を配置できます。 簡単なフローでは、必要に応じてすべての論理を 1 つの Compute ノードにコーディングしてもかまいません。

    ここで、既存のシステムを (通常は WebSphere MQ を介して) 呼び出して、予期される応答を取得してから、Web サービス応答を伝搬します。このシナリオは、ブローカーが新規 Web サービスをインプリメントする方法についての詳細で取り上げたシナリオとよく似ていますが、メッセージ・フローが、Web サービス・クライアントの使用するデータ形式と、WebSphere MQ に対応した既存のシステムの使用する形式との間のマッピングも定義しなければならない点が異なります。メッセージ・フロー設計者は、ビジネス・アプリケーションが適当な時間内に期待される応答を送信しない 可能性について責任を持つ必要があります。

関連概念
XML ドメインのメッセージ・フロー
ブローカーによる既存の Web サービスの呼び出し
ブローカーによる新規 Web サービス・インターフェースのインプリメント
ブローカーによる既存の Web サービス・インターフェースのインプリメント
ブローカーによる新規 Web サービスに対する Web サービス以外のインターフェースのインプリメント
関連タスク
ブローカーが既存の Web サービス・インターフェースをインプリメントする方法についての詳細
ブローカーによる既存の Web サービスの呼び出し - 詳細
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
最終更新 : 2009-02-20 12:43:03

ac34580_