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

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

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

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

ただし、この例では、Web サービスが保つべき外観についても制約があります。つまり、Web サービス・クライアントのための WSDL 定義がすでにあります。

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

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

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

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

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

  2. 既存の WSDL ファイルをインポートして、期待されるインスタンス文書のための 適切なメッセージ・モデルを作成します (データ構造のインポートを参照してください)。フローは対応する SOAP 要求を構文解析して、必要な既存データ形式との間で変換を行う必要があります。 インポートされたメッセージ定義を検査し、ESQL またはマッピング・エディターあるいはその両方を使用して、フローの作成を補助できます。 ブローカー・モデルからカテゴリー・ファイルを作成すること、または WSDL を生成することはしません。
  3. WSDL インポート・ステップにより、適切な SOAP mxsds がメッセージ・セットに自動的に組み込まれます。 これには特に、SOAP エンベロープ mxsd および (必要な場合) SOAP エンコード mxsd が含まれます。
  4. Web サービス要求を受け取るため、つまり Web サービス・プロバイダーとして機能するための、メッセージ・フローをインプリメントします。エンドポイント・ノードは、クライアントが使用するトランスポートに応じて、HTTP または MQ となります。 入力ノード・プロパティーは、以下のとおりです。
    • ドメイン: "MRM"
    • セット: SOAP エンベロープ定義を含むメッセージ・セット
    • タイプ: "Envelope"
    • 形式 "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 ノード、あるいはその両方を配置できます。 簡単なフローでは、必要であればすべての論理を単一の Compute ノードに保管できます。

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

関連概念
Web サービス、WSDL、およびメッセージ・フロー
ブローカーによる既存の Web サービスの呼び出し
ブローカーによる新規 Web サービス・インターフェースのインプリメント
ブローカーによる既存の Web サービス・インターフェースのインプリメント
ブローカーによる非 Web サービス・インターフェースの新規 Web サービスへのインプリメント
関連タスク
ブローカーによる既存の Web サービス・インターフェースのインプリメント - 詳細
ブローカーによる既存の Web サービスの呼び出し - 詳細
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac34580_