ここで Web サービスという用語は、WSDL によって記述され、
ブローカーによってサポートされるトランスポート (通常は、
HTTP、JMS、または MQ) の 1 つからアクセス可能なインターフェースを指します。
WSDL
WSDL 定義の論理部分は、交換されるビジネス・メッセージの形式を記述しています。
ブローカーはこれをインポートして、設計時にメッセージ・モデルを作成できます (WSDL からのインポートを参照してください)。
WSDL 定義の物理部分は、メッセージの交換に使用されるサービスおよびプロトコルの
実際のエンドポイントについて記述しています。
物理バインディング情報は、設計時にはインポートされません。以下の方法で、プロトコルおよびエンドポイントの詳細をメッセージ・フローにインプリメントする必要があります。
- バインディング SOAP/HTTP を使用します。この場合、HTTP ノード (フローが Web サービスを
インプリメントする場合は HTTPInput および HTTPReply、フローが Web サービスを起動する場合は HTTPRequest) を使用して、フローをインプリメントします。
- バインディング SOAP/JMS を使用します。この場合、JMS または MQ ノードを使用して、フローをインプリメントします。
- 1 つのトランスポートを使用してクライアントから入力メッセージを受け取るメッセージ・フローを構成し、別のトランスポートを使用して Web サービスまたはレガシー・アプリケーションと対話することができます。
- 複数のロケーションにメッセージを伝搬させることができます。例えば、HTTPReply ノードによってクライアントに戻される Web サービス応答は、最初に MQOutput ノードを使用して監査アプリケーションに (メッセージ・ヘッダーに必要な調整を行うため) 送られることがあります。
既存のメッセージ・モデルから WSDL 定義を生成する ことも可能です。
この場合、物理バインディング情報を指定する必要があります (メッセージ・セットからの Web サービス定義の生成を参照してください)。
ここで説明した WSDL バインディングは、特に以下の「WSDL ジェネレーター」ウィザードでサポートされるものです。
つまり、メッセージ形式として SOAP が使用されるものであり、この SOAP は MRM ドメインで XML として構文解析できます。
ただし、Web サービスの一般定義はこれより広範囲であり、SOAP 以外のメッセージ形式 (XML-RPC など) および HTTP または JMS 以外のトランスポート (SMTP など) も許容することに注意してください。
典型的な開始点は、以下のとおりです。
- クライアントに公開する既存のメッセージ・モデル (WSDL の生成が必要)
- ブローカーが Web サービスと対話することを可能にする既存の WSDL 定義 (WSDL のインポートが必要)
どちらも場合も、ブローカーは設計時に生成またはインポートされた WSDL に基づいて、実行時にメッセージを受け取ります。
(WSDL について詳しくは、WSDL とメッセージ・モデルの関係およびWSDL の妥当性検査を参照してください)。