このシナリオでは、ブローカーが既存の Web サービス・インプリメンテーションを呼び出します。 Web サービス用の WSDL はすでに存在し、メッセージ・セットの作成のためにインポートされます。
このメッセージ・セットをベースにしたメッセージ・フローは、例えば SOAPRequest ノードを使用して、Web サービス要求を送信し、応答を受信します。
記号を理解する手掛かり:
可能な使用方法
- Web サービスを呼び出して、メッセージ・フローの一環として特定の処理を行いたい場合。
- 既存の Web サービスがあり、それに別のインターフェースを提供したい場合。 例えば、代替 Web サービス・インターフェース、またはWebSphere® MQ インターフェースなどです。
- 既存の Web サービスがあり、インターフェースを変更しないでそのインプリメンテーションに何かの変更を行いたい場合。つまり、ブローカーは Web サービスに対する仲介者になります。 例えば、メッセージ・フローを使用して監査を使用可能にしたり、Web サービスの応答を他のアプリケーションに透過的に伝搬します。
設計のステップ
- WSDL をインポートして、WSDL によって記述された SOAP メッセージの定義を含むメッセージ・セットを作成します。
- Web サービスを呼び出すためのメッセージ・フローを作成します。 SOAP ドメインを使用する場合は、メッセージ・フロー は、SOAPRequest ノード、SOAPAsyncRequest ノード、または SOAPAsyncResponse ノードを使用します。 ノードは、ステップ 1 でインポートした WSDL を使って構成されます。必要があれば、ブランクのメッセージ・フロー・エディターのキャンバスに WSDL をドロップすることによって、スケルトン・フローを最初から作成することができます。 SOAP ドメインを使用する場合は、トランスポート・ノードおよび、XML または MIME ドメインを使用して、メッセージ・フローを作成する必要があります。 例えば、WSDL バインディングが HTTP トランスポートを指定し、要求メッセージが SOAP である場合、HTTPRequest ノードを XMLNSC ドメインで使用することができます。 その後、Web サービスに関するエンドポイント情報を使用して、ノードを手動で構成することができます。
- デプロイメント用のブローカー・アーカイブ・ファイルを作成します。 ブローカー・アーカイブ・ファイルには、メッセージ・フローと、インポートされた WSDL の入ったメッセージ・セットが格納されます。 SOAP ドメインでは、WSDL が必ずデプロイされる必要があります。なぜなら、メッセージは、実行時に WSDL に照らして検証されるからです。論理ツリーには、WSDL 情報も組み込まれます。 メッセージ・セットには、SOAP、XMLNSC、または MRM ドメインでのメッセージの検証で使用できる XML スキーマ定義が入っています。
実行時
メッセージ・フローは適切にフォーマット設定された Web サービス要求を作成し、Web サービスを呼び出して、Web サービス応答を構文解析します。 SOAP ドメインを使用すると、メッセージ・フローでは SOAP 論理ツリー・モデルが使用されます。 SOAP ドメインを使用しない場合は、選択したドメインの論理ツリーがメッセージ・フローで使用されます。例えば、Web サービス・メッセージが SOAP with Attachments を使用する場合は、MIME ドメインを使用します。
例 1
- Web サービスの仲介
- この例では、クライアント・アプリケーションは Account という Web サービスを使用します。これは、別の組織によって使用可能にされた Web サービスです。 このクライアントは、社内で広範囲にわたって分散されています。 クライアントは、getBalance という操作を使用しますが、この getBalance 操作の定義を変更するために、Account サービスは変更されようとしています。 クライアントを変更する代わりに、Account サービスへのインターフェースを提供するメッセージ・フローを構成することができます。 そのメッセージ・フローは、Account サービスを呼び出して作業を行い、新規の Web サービスが、元の Web サービスを代行します。
これでクライアントは、新規のメッセージ・フローを使って、引き続き Account サービスを利用できます。
ここで示した通常のメッセージ・フロー・パターンの例では、中間要求ノードが Account サービスを呼び出します。
- SOAPInput、SOAPRequest、および SOAPReply ノードを使用する場合:
- SOAPInput、SOAPAsyncRequest、SOAPAsyncResponse、および SOAPReply ノードを使用する場合:
- HTTPInput、HTTPRequest、および HTTPReply ノードを使用する場合:
例の中のメッセージ・フローでは、変更後の Account サービスからの要求どおりに、Compute1 が元の getBalance メッセージを変更するのに対して、Compute2 は、応答メッセージを元のフォーマットに復元します。 WSDL のインポートまたは生成が完了すると、getBalance 操作用のメッセージ・モデルが用意されます。 getBalance 操作用のメッセージ・モデルが定義されている場合、Compute ノードに代えて、Mapping ノードを使用することができます。
HTTP の詳細
例に示されているとおりに HTTP トランスポート・ノードを使用する場合、HTTPRequest ノードを構成して、HTTPInput ノードで受信したヘッダーから HTTP ヘッダーを生成することができます。 この構成により、cookie およびその他のアプリケーション固有のヘッダーをメッセージ・フローを通して渡せるようになります。 HTTPReply ノードをタスクで使用して Web サービス応答からヘッダーを抽出し、元のクライアントに戻すことができます。 この構成を作成するには、HTTPRequest および HTTPReply の両方のノードで 「デフォルト HTTP ヘッダーの生成元」を選択します。 一般的に、クライアントへの応答を生成するのに元の要求メッセージは必要ないので、HTTPRequest ノード上で「入力メッセージを Web サービス応答に置換」を選択することができます。 入力要求のデータを保存したい場合、それを Compute1 の LocalEnvironment に保管し、Compute2 から取り出して応答に組み込みます。
例 2
- Web サービスの使用
- この例では、WebSphere MQ メッセージ・フローが、ある会社の人事部のプロセスをインプリメントします。 この処理の一環として、メッセージ・フローは Web サービスを呼び出して、社員 ID 番号を検索します。 社員 ID 番号は、Web サービスを通してアクセスできる社員ディレクトリーで保守されます。
ここで示した通常のメッセージ・フロー・パターンの例では、中間要求ノードが employee ID を呼び出します。
- MQInput、SOAPRequest、および MQOutput ノードを使用する場合:
- MQInput、SOAPAsyncRequest、SOAPAsyncResponse、および MQOutput ノードを使用する場合:
- MQInput、HTTPRequest、および MQOutput ノードを使用する場合:
この例の中のメッセージ・フローでは、Compute1 が Web サービスの要求メッセージを準備し、Compute2 が応答を処理します。
例えば、社員 ID を別のメッセージに組み入れるとします。
メッセージ・モデルが定義されている場合、この例では、Compute ノードに代えて、Mapping ノードを使用することができます。
HTTP の詳細
例に示されているとおりに HTTP トランスポート・ノードを使用する場合、通常は、HTTPRequest ノードのプロパティーの「入力メッセージを Web サービス応答に置換」をクリアします。
社内ディレクトリー・サーバーからの応答は、メッセージ・ツリー内の一時ロケーションに置かれます。 一時ロケーションは、同じノードのツリー・プロパティー内の「応答メッセージ・ロケーション」に指定します。 Compute2 では、結果の検索と最終メッセージの更新のための ESQL をコーディングすることができます。
これらのシナリオでは、SOAP ドメインを使用するのが望ましいと思われます。
Web サービス用のドメインの選択の詳細は、WebSphere Message Broker と Web サービスを参照してください。