ブローカーによる新規 Web サービスのインプリメント - 詳細

以下に、ブローカーが Web サービスをインプリメントする典型的なエンドツーエンドのシナリオの概要を示します。

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

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

Web サービスは、既存のシステムによってすでに公開された操作に基づくインターフェースを提供することになります。このインターフェースは、すべての既存の操作、それらのサブセット、および複合操作の、 全部または一部を含むことがあります。

インターフェースを定義する方法は、以下のとおりです。
  1. 既存のシステムによって提供されるビジネス機能に注目します。
  2. 公開するこのビジネスのサブセットを選択します。
  3. それをインターフェース内でどのように表現するかを決定します (多数の独立した操作としてか、 または少数の多目的の操作としてか)
基本的な決定事項は、Web サービス・インターフェースを RPC スタイルまたは文書スタイルのどちらにするかということです。(Web サービス、WSDL、およびメッセージ・フロー、およびWSDL とメッセージ・モデルの関係を参照してください)。
  • RPC スタイルのインターフェースは、一般にいくつかの API によって提供される 基礎となる操作のセットにマップするように設計されていて、個々の操作 (メソッド呼び出し) は 相対的に小さなペイロードを持ちます。
  • 文書スタイルのインターフェースは、操作の数が少なく、それぞれのペイロードは大きくなります。例えば、融資要求を表す文書などに使用されます。
WS-I (http://www.ws-i.org/を参照) は、文書スタイルの WSDL の仕様を推奨していますが、多くの古い Web サービスでは RPC スタイルを使用しています。

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

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

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

  2. WSDL 定義を生成します。 必要なメッセージ・カテゴリーをすでに作成しているのでなければ、公開する Web サービス操作ごとにメッセージ・カテゴリーを作成して、既存のブローカー・メッセージを適切な SOAP 役割 (入力、出力、または障害) に関連付けます。(メッセージ・カテゴリー・ファイルの処理を参照してください。)
    • 文書スタイルの WSDL を選択した場合、メッセージ・セット自体は変更されません。
    • RPC スタイルの WSDL を選択した場合、各 WSDL 操作の要求および応答に対応するメッセージが、 自動的に作成されてメッセージ・セットに追加されます。
  3. WSDL 生成ステップにより、適切な SOAP mxsds (メッセージ定義ファイル) が メッセージ・セットに自動的に組み込まれます。 これには特に、SOAP エンベロープ mxsd および (WSDL のスタイルが RPC でエンコードされている場合) SOAP エンコード mxsd が含まれます。
  4. 新規の Web サービス・クライアントを作成している場合、選択した Web サービス・クライアント・テクノロジーと共に、生成された WSDL を使用します。これは、WebSphere Message Broker 以外のツール (Rational Application Developer または .NET など) を使用して行います。
  5. Web サービス要求を受け取るため、つまり Web サービス・プロバイダーとして機能するための、メッセージ・フローをインプリメントします。エンドポイント・ノードは、クライアントが使用するトランスポートに応じて、HTTP または MQ となります。 入力ノード・プロパティーは、以下のとおりです。
    • ドメイン: "MRM"
    • セット: SOAP エンベロープ定義を含むメッセージ・セット
    • タイプ: "Envelope"
    • 形式 "XML1"
  6. フローによって呼び出されると、パーサーは事前に準備された SOAP mxsd によって 定義された SOAP エンベロープから構成される論理ツリーを作成します。 構文解析は、SOAP エンベロープ (SOAP 本体およびヘッダー) 内の接続ポイント で自動的に続行して、メッセージ・セット内の他のメッセージ定義に対する突き合わせを試行します。 必要であれば、入力ノードでの妥当性検査を適用します。

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

  7. 許可されたペイロード・メッセージから既存のシステムにある必要なメッセージへのマッピングを提供できます。 例えば、メッセージ 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 Service Host サンプル

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