第3章 サービスで使用される論理メッセージの定義

サービスの操作は、操作が呼び出されたときに交換される論理メッセージを指定することによって定義されます。これらの論理メッセージは、ネットワークを介して渡されるデータを XML ドキュメントとして定義します。これらには、メソッド呼び出しの一部であるすべてのパラメーターが含まれています。 論理メッセージは、コントラクトの message 要素を使用して定義されます。各論理メッセージは、part 要素で定義された 1 つ以上のパーツで設定されます。

メッセージには各パラメーターを個別の部分としてリストできますが、推奨される方法は、操作に必要なデータをカプセル化する単一の部分のみを使用することです。

サービスによって公開される各操作は、1 つの入力メッセージと 1 つの出力メッセージのみを持つことができます。入力メッセージは、操作が呼び出されたときにサービスが受け取るすべての情報を定義します。出力メッセージは、操作が完了したときにサービスが返すすべてのデータを定義します。障害メッセージは、エラーが発生したときにサービスが返すデータを定義します。

さらに、各操作には任意の数の障害メッセージを含めることができます。障害メッセージは、サービスでエラーが発生したときに返されるデータを定義します。これらのメッセージには通常、コンシューマーがエラーを理解するのに十分な情報を提供する部分が 1 つだけあります。

既存のアプリケーションをサービスとして定義する場合は、操作を実装するメソッドで使用される各パラメーターがメッセージで表されていることを確認する必要があります。また、戻り値が操作の出力メッセージに含まれていることを確認する必要があります。

メッセージを定義するための 1 つのアプローチは、RPC スタイルです。RPC スタイルを使用する場合は、メソッドのパラメーターリストのパラメーターごとに 1 つの部分を使用してメッセージを定義します。各メッセージパーツは、コントラクトの types 要素で定義された型に基づきます。入力メッセージには、メソッドの入力パラメーターごとに 1 つの部分が含まれています。出力メッセージには、出力パラメーターごとに 1 つの部分と、必要に応じて戻り値を表す部分が含まれます。パラメーターが入力パラメーターと出力パラメーターの両方である場合、それは入力メッセージと出力メッセージの両方の一部としてリストされます。

RPC スタイルのメッセージ定義は、Tibco や CORBA などのトランスポートを使用するレガシーシステムをサービス対応にする場合に役立ちます。これらのシステムは、手順と方法を中心に設計されています。そのため、呼び出される操作のパラメーターリストに似たメッセージを使用してモデル化するのが最も簡単です。RPC スタイルは、サービスとそれが公開しているアプリケーションの間のよりクリーンなマッピングも作成します。

RPC スタイルは既存のシステムのモデリングに役立ちますが、サービスのコミュニティーはラップされたドキュメントスタイルを強く支持しています。ラップされたドキュメントスタイルでは、各メッセージは 1 つの部分で設定されます。メッセージのパーツは、コントラクトの types 要素で定義されたラッパー要素を参照します。ラッパー要素には次の特徴があります。

コントラクト内の各メッセージは、その名前空間内で一意の名前を持っている必要があります。次の命名規則を使用することを推奨します。

メッセージ部分は、論理メッセージの正式なデータ単位です。各パーツは part 要素を使用して定義され、name 属性と、データ型を指定する type 属性または element 属性によって識別されます。データ型の属性は、表3.1「part データ型の属性」 にリストされています。

メッセージは part の名前を再利用できます。たとえば、メソッドに参照によって渡されるか、入力/出力であるパラメーター foo がある場合、例3.1「再利用部分」 のように要求メッセージと応答メッセージの両方の一部にすることができます。

<message name="fooRequest">
  <part name="foo" type="xsd:int"/>
<message>
<message name="fooReply">
  <part name="foo" type="xsd:int"/>
<message>

<message name="fooRequest">
  <part name="foo" type="xsd:int"/>
<message>
<message name="fooReply">
  <part name="foo" type="xsd:int"/>
<message>

たとえば、個人情報を保存し、従業員の ID 番号に基づいて従業員のデータを返すメソッドを提供するサーバーがあるとします。データを検索するためのメソッドシグネチャーは、例3.2「personalInfo ルックアップメソッド」 のようになります。

personalInfo lookup(long empId)

personalInfo lookup(long empId)

このメソッドシグネチャーは、例3.3「RPC WSDL メッセージ定義」 に示す RPC スタイルの WSDL フラグメントにマッピングできます。

<message name="personalLookupRequest">
  <part name="empId" type="xsd:int"/>
<message/>
<message name="personalLookupResponse>
  <part name="return" element="xsd1:personalInfo"/>
<message/>

<message name="personalLookupRequest">
  <part name="empId" type="xsd:int"/>
<message/>
<message name="personalLookupResponse>
  <part name="return" element="xsd1:personalInfo"/>
<message/>

また、例3.4「ラップされたドキュメントの WSDL メッセージ定義」 に示すラップされたドキュメントスタイルの WSDL フラグメントにマップすることもできます。

<wsdl:types>
  <xsd:schema ... >
  ...
  <element name="personalLookup">
    <complexType>
      <sequence>
        <element name="empID" type="xsd:int" />
      </sequence>
    </complexType>
  </element>
  <element name="personalLookupResponse">
    <complexType>
      <sequence>
        <element name="return" type="personalInfo" />
      </sequence>
    </complexType>
  </element>
  </schema>
</types>
<wsdl:message name="personalLookupRequest">
  <wsdl:part name="empId" element="xsd1:personalLookup"/>
<message/>
<wsdl:message name="personalLookupResponse">
  <wsdl:part name="return" element="xsd1:personalLookupResponse"/>
<message/>

<wsdl:types>
  <xsd:schema ... >
  ...
  <element name="personalLookup">
    <complexType>
      <sequence>
        <element name="empID" type="xsd:int" />
      </sequence>
    </complexType>
  </element>
  <element name="personalLookupResponse">
    <complexType>
      <sequence>
        <element name="return" type="personalInfo" />
      </sequence>
    </complexType>
  </element>
  </schema>
</types>
<wsdl:message name="personalLookupRequest">
  <wsdl:part name="empId" element="xsd1:personalLookup"/>
<message/>
<wsdl:message name="personalLookupResponse">
  <wsdl:part name="return" element="xsd1:personalLookupResponse"/>
<message/>