2.1.1 シナリオ例：The GreatHホテル予約サービス (例Scenario: The GreatH Hotel Reservation Service)

ホテルGreatH（架空のホテル）は、離れ小島にある。 従来は、空き室予約の提供は、ファックスと電話に頼っていた。 GreatHホテルの設備と価格が競合相手の提示するものより良かったとしても、その競合相手の方がGreatHよりも多くの顧客を得ていることにHreatHでは気付いていた。 調査の後、この理由は、競合相手がWebサービスを提供しているためであることを知った。このサービスのおかげで、旅行代理店の予約システムはインターネット経由で直接空き室予約できるようになっていた。 今回、GreatHは我々を雇い、次の機能を持つ予約Webサービスを構築することにした：

• CheckAvailability。空室があるか確認するために、クライアントはチェックイン予定日、チェックアウト予定日、ルームタイプを指定しなければならない。このWebサービスは、そのような部屋が予約可能であれば宿泊料金（USドルの浮動小数点数）を返し、もしなければ宿泊料金として0を返す。もし、何れかの入力データが不正であれば、このサービスはエラーを返さなければならない。つまり、このサービスは、checkAvailabilityメッセージを受け取り、checkAvailabilityResponseまたはinvalidDataFaultメッセージを返す。

• MakeReservation。実際に予約するために、クライアントは、名前、住所、クレジット・カード情報を提供しなければならない。そして、予約が成功したら、サービスは予約確認番号を返す。サービスは、クレジットカード番号、または他のデータ・フィールドが不正であれば、エラーメッセージを返す。つまり、サービスはmakeReservationメッセージを受け取って、makeReservationResponseまたはinvalidCreditCardFaultメッセージを返す。

我々は、後で、トランザクションと安全な転送をサポートする完全なシステムを構築する必要があることを知っているが、最初は、最小機能だけを実装することにする。実際、我々の最初の例を単純化するために、CheckAvailabilityオペレーションだけを実装することにする。

後続の幾つかのセクションでは、要求されたWebサービスを記述するためのWSDL 2.0文書を開発するプロセスを通して、ステップ・バイ・ステップで進めていく。しかしながら、完全な例を見るまで待てない方々のために、これから作成されるWSDL 2.0文書をここに挙げておく。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsdlx= "http://www.w3.org/ns/wsdl-extensions">

  <documentation>
    この文書はGreatHサービスについて記述している。
    このサービスを利用するための、追加のアプリケーションレベルの要求 --
    WSDL 2.0で記述できる範囲以上のもの -- は、次のURIで得られる：
    http://greath.example.com/2004/reservation-documentation.html
  </documentation>

  <types>
    <xs:schema 
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://greath.example.com/2004/schemas/resSvc"
        xmlns="http://greath.example.com/2004/schemas/resSvc">

      <xs:element name="checkAvailability" type="tCheckAvailability"/>    
      <xs:complexType name="tCheckAvailability">     
        <xs:sequence>      
          <xs:element  name="checkInDate" type="xs:date"/>      
          <xs:element  name="checkOutDate" type="xs:date"/>      
          <xs:element  name="roomType" type="xs:string"/>      
        </xs:sequence>     
      </xs:complexType>   
            
      <xs:element name="checkAvailabilityResponse" type="xs:double"/>    
    
      <xs:element name="invalidDataError" type="xs:string"/>    

    </xs:schema>    
  </types>
  
  <interface  name = "reservationInterface" >

    <fault name = "invalidDataFault"
            element = "ghns:invalidDataError"/> 
   
    <operation name="opCheckAvailability" 
            pattern="http://www.w3.org/ns/wsdl/in-out" 
            style="http://www.w3.org/ns/wsdl/style/iri"
            wsdlx:safe = "true">
        <input messageLabel="In" 
              element="ghns:checkAvailability" />
        <output messageLabel="Out" 
              element="ghns:checkAvailabilityResponse" />
        <outfault ref="tns:invalidDataFault" messageLabel="Out"/>
    </operation>

  </interface>

  <binding name="reservationSOAPBinding" 
          interface="tns:reservationInterface"
          type="http://www.w3.org/ns/wsdl/soap"
          wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
 
    <fault ref="tns:invalidDataFault" 
      wsoap:code="soap:Sender"/>

    <operation ref="tns:opCheckAvailability" 
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>

  </binding>

  <service name="reservationService" 
       interface="tns:reservationInterface">

     <endpoint name="reservationEndpoint" 
               binding="tns:reservationSOAPBinding"
               address ="http://greath.example.com/2004/reservation"/>
        
  </service>

</description>

2.1.2 WSDL 2.0のターゲット名前空間の定義 (Defining a WSDL 2.0 Target Namespace)

我々のWSDL 2.0文書を書く前に、我々はそのためのWSDL 2.0ターゲット名前空間URIを決定する必要がある。WSDL 2.0のターゲット名前空間は、XMLスキーマのターゲット名前空間に似ている。 われわれのWSDL 2.0文書で定義される、インタフェース、バインディング、およびサービスの名前は、WSDL 2.0ターゲット名前空間と結び付けられる。つまり、別のWSDL 2.0ターゲット名前空間の類似した名前とは区別できる。（このことは、WSDL 2.0の、インポートやインタフェース継承メカニズムを使うときに、重要となる。）

WSDL 2.0ターゲット名前空間の値は、絶対URIでなければならない。さらに、そのWSDL 2.0ターゲット名前空間を記述に使うWebサービスを記述するWSDL 2.0文書を参照可能 (dereferenceable)であるべきである。例えば、GreatHのオーナーは、このURIからそのWSDL 2.0文書を得られるようにしておくべきである。（そしてもし、WSDL 2.0記述が複数の文書に分割されているのであれば、WSDL 2.0ターゲット名前空間はサービス記述に必要な全てのWSDL 2.0文書をインクルードするマスター文書を解決すべきである。）しかし、この参照可能 (dereferenceable)なURIに対する絶対的な要求はなく、WSDL 2.0処理系はそれが参照可能 (dereferenceable)であることに頼ってはならない。

この勧告は循環的に聞こえるかもしれないが、クライアントはWSDL 2.0文書をどこから得ても良いことを記憶しておいて欲しい -- そこは正規のソースである必要はない。しかし、WSDL 2.0ターゲット名前空間URIを参照 (dereferencing)することで、ユーザは正規なバージョンを得られるべきである。GreatHがそのサービスのオーナーとなるので、WSDL 2.0ターゲット名前空間URIはGreatH Webサイトか、その制御下にある場所を参照すべきである。

一度、我々がWSDL 2.0ターゲット名前空間URIを決定したら、我々のWSDL 2.0文書は、次の空のシェルから始めることができる。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    . . . >

  . . .
</description>

2.1.3 メッセージ型の定義 (Defining Message Types)

我々は、GreatHサービスがメッセージを送受信することを知っている。 サービスの記述の良い出発点は、サービスが用いるメッセージ型を定義することである。 そのために我々はXML Schemaを用いる。WSDL 2.0処理系は最低限XML Schemaをサポートしているものであるからである。 しかしながら、WSDL 2.0は他のスキーマ記述言語の利用を禁止しているわけではない。

WSDL 2.0では、メッセージ型をWSDL 2.0文書内で直接定義できる。定義場所はdescription要素の子要素であるtypes要素内である。 （あとで我々は、XML Schemaのimportメカニズムを使って、いかにして別々の文書で型定義を提供できるかを見ることになる。） 次のスキーマでは、我々が必要なcheckAvailability、checkAvailabilityResponseおよびinvalidDataErrorメッセージ型を定義している。

WSDL 2.0では、全ての正常およびフォルト・メッセージの型は、最上位レベルで単一の要素として定義されていなければならない（もちろん、各々の要素はその内部に任意の量の内部構造を持ってよい）。 つまり、メッセージ型は、複数の要素の連続や他の複合的な型から直接構成されてはならない。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    . . . >

  ...

  <types>
    <xs:schema 
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://greath.example.com/2004/schemas/resSvc"
        xmlns="http://greath.example.com/2004/schemas/resSvc">

      <xs:element name="checkAvailability" type="tCheckAvailability"/>    
      <xs:complexType name="tCheckAvailability">     
        <xs:sequence>      
          <xs:element  name="checkInDate" type="xs:date"/>      
          <xs:element  name="checkOutDate" type="xs:date"/>      
          <xs:element  name="roomType" type="xs:string"/>      
        </xs:sequence>     
      </xs:complexType>   
            
      <xs:element name="checkAvailabilityResponse" type="xs:double"/>    
    
      <xs:element name="invalidDataError" type="xs:string"/>    

    </xs:schema>    
  </types>
  . . .
</description>

2.1.4 インタフェースの定義 (Defining an Interface)

WSDL 2.0では、Webサービスの抽象機能の記述を、その機能が提供される具象的な方法と場所の詳細から分離できる。 こうして分離することによって、Webサービスとそれを記述するWSDL 2.0文書のライフサイクルにおいて、異なるレベルの再利用性と配布作業を促進する。

WSDL 2.0 interfaceは、抽象オペレーションの集合として、Webサービスの抽象インタフェースを定義し、各々のオペレーションは、クライアントとサービスの間の単純なやりとりを表現する。 各々のオペレーションが指定するのは、サービスがそのオペレーションの一部として送受信できるメッセージの型である。 各々のオペレーションは、メッセージ交換のパターンも指定する。このパターンは、関連するメッセージがパーティー間で転送されるシーケンスを示している。 例えば、in-outパターン（WSDL 2.0定義済み拡張 [WSDL 2.0 Adjuncts]第2.2.3節In-Out参照）は、もしクライアントがメッセージinをサービスに送ったら、サービスはクライアントにoutをメッセージとして送り返すか（正常ケースの場合）、フォルト・メッセージをクライアントに送り返す（異常ケースの場合）ことを示している。 我々は、より詳細なメッセージ交換パターンを、2.4.4.3 メッセージ交換パターン（Message Exchange Patterns (MEPs)）の理解で説明する。

GreatHサービスのために、我々は（まず）単一のオペレーションopCheckAvailabilityを含んだインタフェースを定義する。これは、typesの節で定義したcheckAvailabilityとcheckAvailabilityResponseメッセージ型を用いる。 我々はこのオペレーションのためにin-outパターンを用いる。これが、単純な応答-要求型のやり取りを表現する最も自然なものだからである。我々はこれの代わりに（例えば）、in-onlyとout-onlyを用いた別々のオペレーションを定義することもできる（WSDL 2.0定義済み拡張 [WSDL 2.0 Adjuncts]第2.2.1節In-Onlyと第2.2.5節Out-Only参照）。しかし、それはクライアントにとっては複雑なだけの作業になる可能性がある。クライアント開発者に、応答-要求の組として二つのオペレーションを一緒に使うべきであることを、別途指示しなければならなくなるだろうからだ。

正常な入力と出力のメッセージに加えて、我々はエラー・イベントで使いたいフォルト・メッセージも指定する必要がある。WSDL 2.0は、オペレーションを横断してフォルトの再利用を促進するために、フォルト・メッセージはinterface要素内で宣言できる。もしフォルトが発生したら、そのオペレーションのメッセージ交換パターンで指定された、どのメッセージ・シーケンスであっても、終了する。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    . . . 
    xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions">

  . . .
  <types>
        ...
  </types>
  
  <interface  name = "reservationInterface" >

    <fault name = "invalidDataFault"
            element = "ghns:invalidDataError"/> 
   
    <operation name="opCheckAvailability" 
            pattern="http://www.w3.org/ns/wsdl/in-out"
            style="http://www.w3.org/ns/wsdl/style/iri"
            wsdlx:safe = "true">
        <input messageLabel="In" 
              element="ghns:checkAvailability" />
        <output messageLabel="Out" 
              element="ghns:checkAvailabilityResponse" />
        <outfault ref="tns:invalidDataFault" messageLabel="Out"/>
    </operation>

  </interface>

  . . .
</description>

2.1.5 バインディングの定義 (Defining a Binding)

我々は、どんな抽象メッセージがGreatHサービスで交換できるかを指定してきたが、まだどのようにそれらのメッセージが交換されるかを指定していない。これがバインディングの目的である。 バインディングが指定するのは、そのサービスに対する具体的なメッセージ・フォーマットと転送プロトコルの詳細であり、そのインタフェース内のあらゆるオペレーションとフォルトに対して、そのような詳細を提供しなければならない。

一般的な場合では、各々のオペレーションとフォルトに対する詳細のバインディングは、次の例のように、binding要素内のoperation要素とfault要素を使って指定される。 しかしながら、ある場合には、情報提供のためのデフォルト規則（指定を省略したときの規則）を使うこともできる。 例えば、WSDL 2.0 SOAPバインディング拡張では、オペレーションに対する幾つかのデフォルト規則を定義している。（Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts [WSDL 2.0 Adjuncts], デフォルト・バインディング規則参照。）

新しい種類のメッセージ・フォーマットと転送プロトコルを含めるために、バインディングは、WSDL 2.0オープン内容モデルによる、WSDL 2.0の拡張を利用して定義されている。 （拡張可能性に対する更なる情報は4.1拡張性参照。） WSDL 2.0 Part 2 [WSDL 2.0 Adjuncts]は、バインディング拡張を、SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework]とHTTP 1.1 [IETF RFC 2616]に対する、定義済み拡張として定義する。SOAP 1.2やHTTP 1.1バインディングがWSDL 2.0文書で簡単に定義できるようにするためである。 （任意の拡張に対してと同様に、他のWSDL 2.0処理系は、新しい構造については、利用するものについてだけ、認識するだろう。）

GreatHサービスのために我々は、次に示すとおり、具体的なメッセージ・フォーマットとしてSOAP 1.2、その下層の転送プロトコルとしてHTTPを利用する。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  . . .

  <types>
    . . .
  </types>
  
  <interface  name = "reservationInterface" >
        ...
  </interface>

  <binding name="reservationSOAPBinding" 
          interface="tns:reservationInterface"
          type="http://www.w3.org/ns/wsdl/soap"
          wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">

    <operation ref="tns:opCheckAvailability" 
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
  
    <fault ref="tns:invalidDataFault" 
      wsoap:code="soap:Sender"/>

  </binding>

  . . .
</description>

2.1.6 サービスの定義 (Defining a Service)

ここまでは、バインディングでどのようにメッセージが転送されるかを指定してきた。service要素を使って、どこでサービスにアクセスできるかを指定する準備ができた。

WSDL 2.0サービスは、サービスがサポートする単一のインタフェースと、サービスにアクセスできる一連のエンドポイントのロケーションを指定する。 各々のエンドポイントは、そのエンドポイントで利用されるプロトコルと転送フォーマットを指定する、定義済みのバインディングも参照しなければならない。 一つのサービスは一つのインタフェースしか持つことができない。（この制約に関する更なる議論は、5.4同一サービスに対する複数インタフェースを参照。）

我々のGreatHサービスに対する定義がこれである。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  . . .

  <types>
    . . .
  </types>
  
  <interface  name = "reservationInterface" >
    . . .
  </interface>

  <binding name="reservationSOAPBinding" 
          interface="tns:reservationInterface"
        . . . >
    . . .
  </binding>

  <service name="reservationService" 
       interface="tns:reservationInterface">

     <endpoint name="reservationEndpoint" 
               binding="tns:reservationSOAPBinding"
               address ="http://greath.example.com/2004/reservation"/>
        
  </service>
  
</description>

2.1.7 サービスの文書化 (Documenting the Service)

我々が見てきたとおり、WSDL 2.0文書は、本質的にサービスに対する一部だけの記述だけである。 サービスとやり取りするための基本的なメカニズム -- メッセージタイプ、転送プロトコル、サービスの場所、など -- を捕らえているにせよ、一般的には、それを利用するための他のアプリケーション・レベルの要求を説明する追加のドキュメンテーションが必要になる。 例えば、そのドキュメンテーションでは、そのサービスの目的と利用、全てのメッセージの意味、それらの利用に当たっての制約、オペレーションを呼び出すべき順番を説明すべきだ。

documentation要素は、WSDL 2.0記述者が、幾つかの人可読 (human-readable)ドキュメンテーションをWSDL 2.0文書内に含められるようにする。 また、このサービスを利用するクライアント開発者にとって必要な、任意の追加外部文書を参照する場所としても便利だ。 ここの例では、我々は文書の冒頭で実例として挙げているだけであるが、documentation要素はWSDL 2.0文書内に幾つでも記述することができる（2.2.1 WSDL 2.0インフォセット参照）。

<?xml version="1.0" encoding="utf-8" ?> 
<description 
    . . . >

  <documentation>
    この文書はGreatHサービスについて記述している。
    このサービスを利用するための、追加のアプリケーションレベルの要求 --
    WSDL 2.0で記述できる範囲以上のもの -- は、次のURIで得られる：
    http://greath.example.com/2004/reservation-documentation.html
  </documentation>
  . . .  
</description>

2.2.1 WSDL 2.0インフォセット (WSDL 2.0 Infoset)

次のダイアグラムは、WSDL 2.0文書に対するXMLインフォセットの概要を与える。

図2-1. WSDL 2.0インフォセット・ダイアグラム

2.2.2 WSDL 2.0スキーマ (WSDL 2.0 Schema)

WSDL 2.0仕様は、[XML Schema Structures]で定義された規範的WSDL 2.0スキーマを提供する。これは、WSDL 2.0の妥当性検証 (validation)の材料として利用できる。 我々がここで「材料として」と云ったのは、WSDL 2.0仕様[WSDL 2.0 Core]はしばしばWSDL 2.0スキーマに対する更なる制約も提供するからだ。 規範的なスキーマに対して妥当であることに加えて、WSDL 2.0文書はWSDL 2.0仕様で定義された全ての制約にも従っていなければならない。

<description>
  <documentation />?
  [ <import /> | <include /> ]*
  <types />?
  [ <interface /> | <binding /> | <service /> ]*
</description>

2.2.3 WSDL 2.0コンポネント・モデル (WSDL 2.0 Component Model)

先ほどのWSDL 2.0インフォセット・モデルは、XMLインフォセットを用いて、WSDL 2.0文書の構造の要求を説明している。 しかしながら、WSDL 2.0言語はこのXMLインフォセットに対する、構造的な適合性にまたがって超越する、多くの意味的な制約も課している。 これらの制約を正確に記述するために、また、WSDL 2.0文書の意味を正確に定義する材料として、WSDL 2.0仕様では、XMLインフォセットを超越した追加の抽象レイヤとして、コンポネント・モデルを定義する。 制約と意味はこのコンポネント・モデルで定義され、各々のコンポネントの定義は、そのコンポネント・モデルにおける値を、XMLインフォセットの対応するアイテムから抜き出す方法のマッピングを含んでいる。 次のダイアグラムは、WSDL 2.0コンポネントとその内容の階層に関する概要を与える。

図2-2. WSDL 2.0コンポネント内容階層

一般的には、WSDL 2.0コンポネント・モデルは、先ほど説明したXMLインフォセットで要求される構造とは平行関係にある。 例えば、Description, Interface, Binding, Service and Endpointコンポネントは各々、description, interface, binding, service, and endpoint要素インフォメーションアイテムに対応する。 WSDL 2.0言語における構造の意味を含むのに、WSDL 2.0はコンポネント・モデルに深く頼っているので、Descriptionコンポネントを、description要素インフォメーション・アイテムの意味を表わすものとして考えることができて、従って、それは、全体としては、WSDL 2.0文書の意味を表わしている。

更に、これらのコンポネントの各々がプロパティを持っている。プロパティの値は、（通常は）それらの要素インフォメーション・アイテムの子供となる要素インフォメーション・アイテムと属性インフォメーションアイテムから抽出される。 例えば、Serviceコンポネントはservice要素インフォメーション・アイテムに対応し、Serviceコンポネントは{endpoint}プロパティを持つ。{endpoint}プロパティの値は、service要素インフォメーション・アイテムの子供であるendpoint要素に対応するEndpointコンポネントの集合である。(Whew!)

2.3.1 XML Schemaのインライン化 (Inlining XML Schema)

我々は、すでに2.1.3 メッセージ型の定義の中で、既にインライン化スキーマを利用した例を見てきた。 WSDL 2.0文書の中で、XMLスキーマが直にインライン化される場合、これを実現するためには、既存の最上位レベルのXMLスキーマによって定義されたxs:schema要素を利用する。これは、まるでtypes要素内にスキーマファイルがコピー&ペーストされたようなものである。 インライン化されたスキーマで定義されたスキーマ・コンポネントは、包含WSDL 2.0 descriptionでQNameで参照するために利用できるようになる。 例えば、例2-1では、インタフェース・オペレーション"opCheckAvailability"の入力メッセージは、インライン化されたスキーマの"ghns:checkAvailability"要素で定義される。

2.3.2 XML Schemaのインポート (Importing XML Schema)

XML Schemaコンポネントは、分離されたスキーマファイルで定義可能であり、types要素直下のxs:importを用いて、WSDL2.0 descriptionで利用可能できる。

分離されたスキーマファイルでスキーマを定義したくなるときには、多くの場合がる。 一つの理由は、スキーマ定義の再利用性だ。 インライン化されたスキーマ定義は、包含WSDL 2.0 descriptionでしか利用できない。 WSDL 2.0は、他のWSDLファイルをインポートするためのwsdl:importメカニズムを提供する。 インポートされたWSDL文書内でインライン化されているスキーマ定義は、他のWSDL 2.0コンポネント（インタフェース、バインディングなど）が利用可能になったとしても、自動的にはインポートするWSDL 2.0文書で利用可能にはならない。 従って、もし複数のWSDL 2.0 descriptionでスキーマ定義を共有したいのであれば、これらのスキーマ定義は別のXML Schema文書に配置しておき、types直下のxs:importを使って、各々のWSDL 2.0 descriptionへインポートすべきである。

例を見てみよう。 例2-3のメッセージ型が、ターゲット名前空間"http://greath.example.com/2004/schemas/resSvc"を持つ別のスキーマファイル"http://greath.example.com/2004/schemas/resSvc.xsd"で定義されているとすると、そのスキーマ定義は、xs:importを使ってWSDL 2.0 descriptionの中に持ち込むことができる。 インポートされた名前空間"http://greath.example.com/2004/schemas/resSvc"内のコンポネントだけが、WSDL 2.0文書内で参照するために利用可能になることに注意して欲しい。

<?xml version="1.0" encoding="utf-8" ?> 
<description xmlns="http://www.w3.org/ns/wsdl"
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
. . . >
. . .

<types>
        <xs:import namespace="http://greath.example.com/2004/schemas/resSvc" 
                schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/>  
</types>

. . .
</description>

wsdl:typesの直下で使われているxs:importが、インライン化されたスキーマ内で使われいてるxs:importとは異なる可視性を与えられていることに注意を向けることが重要である。 インライン化されたスキーマは、異なる名前空間内にある外部のスキーマ定義を持ち込むために、ネイティブXMLスキーマxs:importを使ってもよい； しかしながら、これがWS-I Basic ProfileのWSDL 1.1に対して勧告されたスキーマのインーポーティング・メカニズムであっても、XML Schema仕様によれば、そのような閉じたメッセージ定義は、インポートしているスキーマ（この例では、インライン化されたスキーマ）に対してしか可視的ではない。 それらは、包含WSDL 2.0 descriptionに対して可視的ではない。

もし我々が例2-8を、インライン化されたスキーマ内のXML Schemaネイティブxs:import要素を使うように変更すると、http://greath.example.com/2004/schemas/resSvcで定義されるスキーマ・コンポネントは、我々の例のWSDL 2.0定義のどこでも利用できなくなる。

<?xml version="1.0" encoding="utf-8" ?> 
<description xmlns="http://www.w3.org/ns/wsdl"
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
. . . >
. . .

<types>
        <xs:schema targetNamespace="http://greath.example.com/2004/schemas/resSvcWrapper">
                <xs:import namespace="http://greath.example.com/2004/schemas/resSvc" 
                schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/>  
        </xs:schema>
</types>

. . .
</description>

もちろん、インライン化されたXML Schemaは、インクルードされるスキーマが名前空間を持たない場合やインクルードするスキーマと同じ名前空間を持つ場合は、別のファイルに定義されたスキーマを参照するために、XML Schemaのネイティブxs:include要素を使ってもよい。 この場合は、XML Schemaによれば、インクルードされたスキーマ・コンポネントは、あたかもインクルードするスキーマにコピー&ペーストされたかのように、インクルードするスキーマの一部となる。 従って、インクルードされたスキーマコンポネントは、包含するWSDL 2.0 descriptionに対して、QNameによる参照のために利用可能でもある。

次の例は、例2-3と同様の効果を持つ：

<?xml version="1.0" encoding="utf-8" ?> 
<description xmlns="http://www.w3.org/ns/wsdl"
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
. . . >
. . .

<types>
        <xs:schema targetNamespace="http://greath.example.com/2004/schemas/resSvc">
                <xs:include schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/>  
        </xs:schema>
</types>

. . .
</description>

2.3.3 インポートとインクルード・メカニズムのサマリー (Summary of Import and Include Mechanisms)

ここまでで、我々はWSDLインポートとインクルード、およびスキーマ・インポートとインクルードの両方を簡単にカバーした。 次の表は、WSDL 2.0とML Schemaのincludeおよびimportメカニズム間に見られる類似と差異をまとめたものだ。 我々は、3.1 WSDLのインポートと3.2 Schemaのインポートで、インポーティング・メカニズムについて、もっと多くのことを話題にする。

2.4.1 インタフェースのシンタックス (Interface Syntax)

次の挙げたものが、interface要素のXMLシンタックスのサマリーである。単純化のために、任意指定の<documentation>要素については省略してある：

<description targetNamespace="xs:anyURI" >

  . . .
  <interface name="xs:NCName" 
          extends="list of xs:QName"? 
          styleDefault="list of xs:anyURI"? >

    <fault name="xs:NCName" 
            element="xs:QName"? >
    </fault>*

    <operation name="xs:NCName" 
            pattern="xs:anyURI" 
            style="list of xs:anyURI"? 
            wsdlx:safe="xs:boolean"? >

      <input messageLabel="xs:NCName"? 
            element="union of xs:QName, xs:Token"? >
      </input>*

      <output messageLabel="xs:NCName"? 
            element="union of xs:QName, xs:Token"? >
      </output>*

      <infault ref="xs:QName" messageLabel="xs:NCName"? > </infault>*

      <outfault ref="xs:QName" messageLabel="xs:NCName"? > </outfault>*

    </operation>*

  </interface>*
  . . .

</description>
  

interface要素には二つの任意指定の属性がある：styleDefaultとextendsだ。 styleDefault属性は、このインタフェース配下の全てのオペレーションに対するstyle属性のデフォルト値を定義するために使える（WSDL 2.0 Part 1 "styleDefault属性インフォメーション・アイテム"参照）。 extends属性は、継承のためのもので、次に説明する。

2.4.2 インタフェース継承 (Interface Inheritance)

任意指定のextends属性によって、インタフェースを、一つ以上のインタフェースから拡張あるいは継承できるようになる。 このような場合では、インタフェースは、それが直接定義するインタフェースと共に、それが拡張する複数のインタフェースを含んでいる。 インタフェースの拡張に関して二つの事柄が、いくらかの注意を払うに値する。

第一に、継承ループ（または無限再起）は禁止されている： あるインタフェースが継承するインタフェースは、それら自身ではそのインタフェースを、直接的と間接的とを問わず、継承してはならない。

第二に、二つの異なるインタフェースが、同じターゲット名前空間とオペレーション名を持つとき、何が起こるかを説明しなければならない。 これには二つの場合がある：それらのオペレーションのコンポネント・モデルが、同じであるか、異なっているかだ。 もしコンポネント・モデルが同じであれば（WSDL 2.0 Part 1 [WSDL 2.0 Core] " 等価なコンポネント"で定義されているコンポネント競合アルゴリズムを参照）、それらは同じオペレーションであるとみなさなけれる、例えば、それらは一つのオペレーションに縮約され、一度以上含まれているという事実は、エラーとは考えられない。 （オペレーションにとっては、コンポネント等価性は、基本的には二つのオペレーションが、同じ属性と子孫の集合を持つことを意味している。） 第二の場合、二つのオペレーションが同一WSDL 2.0ターゲット名前空間内で同じ名前を持つが、それらが等価ではない場合は、エラーである。 上記の理由で、同一の名前空間内の全てのオペレションは一意に名付けられていることを保証することは、グッド・プラクティスであると考えられる。

最後に、フォルトはinterface要素の子供として定義され得るので（次の節で記述されるように）、同一の名前競合規則がそれらの構造に適用される。

GreatHホテルが、全ての応答メッセージに対する標準的なメッセージ・ログ・オペレーションをメンテナンスしたいとしよう。 そこでは、このオペレーションが全ての予約システムをまたがって再利用可能であることを求めている。各々のサービスが、潜在的にロギング・サービスを利用するために、タイムスタンプとメッセージのオリジネータと一緒に受信する各メッセージの内容を送信する。 この要求を満たす一つの方法は、他のインタフェースによって継承されるインタフェースの中で、ログ・オペレーションを定義することである。 messageLog要素が、既にghns名前空間内に、要求されている内容で定義されているとすると、継承ユースケースは次の例のように説明される。 継承の結果、reservationInterfaceは、このとき、二つのオペレーションを含む：opCheckAvailabilityとopLogMessageだ。

                                        
<description ...>
        ...
        <interface  name = "messageLogInterface" >
                                
                <operation name="opLogMessage" 
                                pattern="http://www.w3.org/ns/wsdl/out-only">
                        <output messageLabel="out" 
                                element="ghns:messageLog" />
                </operation>

        </interface>

        <interface  name="reservationInterface" extends="tns:messageLogInterface" >
   
                <operation name="opCheckAvailability" 
                                pattern="http://www.w3.org/ns/wsdl/in-out"
                                style="http://www.w3.org/ns/wsdl/style/iri"
                                wsdlx:safe = "true">
                        <input messageLabel="In" 
                                element="ghns:checkAvailability" />
                        <output messageLabel="Out" 
                                element="ghns:checkAvailabilityResponse" />
                        <outfault ref="tns:invalidDataFault" messageLabel="Out"/>

                </operation>
        </interface>
        ...
</description>

interfaceの子要素について見ていこう、faultから始める。

2.4.3 インタフェース・フォルト (Interface Faults)

fault要素は、インタフェースのオペレーションの実行中に発生するかもしれないフォルトを宣言するために使われる。 それらは、複数のオペレーションにまたがって再利用できるようにするために、interface直下で宣言され、それらが適用されるオペレーションから参照される。

フォルトはメッセージととてもよく似ており、特殊なメッセージとしてみなせる。 フォルトとメッセージは両方とも、通常は要素宣言によって記述されるパイロードを運ぶかもしれない。 しかしながら、WSDL 2.0はフォルトとメッセージを若干異なる方法で扱う。 オペレーションのメッセージはその要素宣言を直接参照するが、オペレーションのフォルトはその要素宣言を、インタフェースで定義されたフォルト要素を通して、間接的に参照する。

フォルトをインタフェースレベルで定義する理由は、それらを複数のオペレーションにまたがって再利用できるようにするためだ。 この設計は特にバインディングが定義されるときに有用である。SOAPのようなバインディング拡張では、フォルトと関連する追加情報が存在するからだ。 SOAPの場合、フォルトはペイロードに加えて、コードとサブコードを持つ。 フォルトをインタフェース・レベルで定義することで、共通コードとサブコードを、それらと関連らセルことができる。よって、それらのフォルトを利用する全てのオペレーションにまたがる一貫性を保証することになる。

fault要素は、親のinterface要素内で一意でなければならない、必須のname属性を持つ。この属性は、オペレーション宣言から参照されることを許す。 任意のelement属性は、フォルト・メッセージの内容、つまりペイロードのスキーマを示すために使える。 その値は、typesセクションで定義したグローバル要素のQNameであるべきである。 他の型システムがフォルト・メッセージのスキーマを定義するために使われるときは、そのスキーマをフォルトと関連されられるように、WSDL 2.0属性拡張メカニズムによって、追加属性の定義が必要になるかもしれないことに注意して欲しい。

2.4.4 インタフェース・オペレーション (Interface Operations)

先ほど示したように、operation要素は、包含インタフェースによってサポートされるオペレーションを示すために使われる。 それは、Webサービスとの単純なやりとりを抽象的に記述するために、メッセージ・スキーマとメッセージ交換パターン(MEP)を関連付ける。

                                        
<description ...>
        ...
        <interface  name="reservationInterface">
                ...
                <operation name="opCheckAvailability" ... >
                
                <operation name="opLogInquiry" 
                                pattern="http://www.w3.org/ns/wsdl/out-only">
                        <output messageLabel="Out" element="ghns:customerData" />
                </operation>

        </interface>
        ...
</description>

2.5.1 Syntax Summary for Bindings

Since bindings are specified using extensions to the WSDL 2.0 language (i.e., binding extensions are not in the WSDL 2.0 namespace), the XML for expressing a binding will consist of a mixture of elements and attributes from WSDL 2.0 namespace and from the binding extension's namespace, using WSDL 2.0's open content model.

Here is a syntax summary for binding, simplified by omitting optional documentation elements. Bear in mind that this syntax summary only shows the elements and attributes defined within the WSDL 2.0 namespace. When an actual binding is defined, elements and attributes from the namespace of the desired binding extension will also be intermingled as required by that particular binding extension.

<description targetNamespace="xs:anyURI" >
  . . .
  <binding name="xs:NCName" interface="xs:QName"? >

    <fault ref="xs:QName" >  </fault>*

    <operation ref="xs:QName" >
      <input messageLabel="xs:NCName"? > </input>*
      <output messageLabel="xs:NCName"? > </output>*
      <infault ref="xs:QName" messageLabel="xs:NCName"? > </infault>*
      <outfault ref="xs:QName" messageLabel="xs:NCName"? > </outfault>*
    </operation>*

  </binding>*
  . . .
</description>

The binding syntax parallels the syntax of interface: each interface construct has a binding counterpart. Despite this syntactic similarity, they are indeed different constructs, since they are in different symbol spaces and are designed for different purposes.

2.5.2 Reusable Bindings

A binding can either be reusable (applicable to any interface) or non-reusable (specified for a particular interface). Non-reusable bindings may be specified at the granularity of the interface (assuming the binding extension provides suitable defaulting rules), or on a per-operation basis if needed. A non-reusable binding was demonstrated in 2.1.5 Defining a Binding.

To define a reusable binding, the binding element simply omits the interface attribute and omits specifying any operation-specific and fault-specific binding details. Endpoints can later refer to a reusable binding in the same manner as for a non-reusable binding. Thus, a reusable binding becomes associated with a particular interface when it is referenced from an endpoint, because an endpoint is part of a service, and the service specifies a particular interface that it implements. Since a reusable binding does not specify an interface, reusable bindings cannot specify operation-specific details. Therefore, reusable bindings can only be defined using binding extensions that have suitable defaulting rules, such that the binding information only needs to be explicitly supplied at the interface level.

2.5.3 Binding Faults

A binding fault associates a concrete message format with an abstract fault of an interface. It describes how faults that occur within a message exchange of an operation will be formatted, since the fault does not occur by itself. Rather, a fault occurs as part of a message exchange specified by an interface operation and its binding counterpart, the binding operation.

A binding fault has one required ref attribute which is a reference, by QName, to an interface fault. It identifies the abstract interface fault for which binding information is being specified. Be aware that the value of ref attribute of all the faults under a binding must be unique. That is, one cannot define multiple bindings for the same interface fault within a given binding.

2.5.4 Binding Operations

A binding operation describes a concrete binding of an interface operation to a concrete message format. An interface operation is uniquely identified by the WSDL 2.0 target namespace of the interface and the name of the operation within that interface, via the required ref attribute of binding operation. As with faults, for each operation within a binding, the value of the ref attribute must be unique.

2.5.5 The SOAP Binding Extension

The WSDL 2.0 SOAP Binding Extension (see WSDL 2.0 Part 2 [WSDL 2.0 Adjuncts]) was primarily designed to support the features of SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework]. However, for backwards compatibility, it also provides some support for SOAP 1.1 [SOAP 1.1].

An example using the WSDL 2.0 SOAP binding extension was already presented in 2.1.5 Defining a Binding, but some additional points are worth mentioning:

• Because the same binding extension is used for both SOAP 1.2 and SOAP 1.1, a wsoap:version attribute is provided to allow you to indicate which version of SOAP you want. If this attribute is not specified, it defaults to SOAP 1.2.

• The WSDL 2.0 SOAP binding extension defines a set of default rules, so that bindings can be specified at the interface level or at the operation level (or both), with the operation level taking precedence. However, it does not define default binding rules for faults. Thus, if a given interface defines any faults, then corresponding binding information must be explicitly provided for each such fault.

• If HTTP is used as the underlying protocol, then the binding can (and should) control whether each operation will use HTTP GET or POST. (See 2.5.7 HTTP GET Versus POST: Which to Use?.)

Here is an example that illustrates both a SOAP 1.2 binding (as seen before) and a SOAP 1.1 binding.

<?xml version="1.0" encoding="utf-8" ?> 
<description 
  xmlns="http://www.w3.org/ns/wsdl"
  targetNamespace="http://greath.example.com/2004/wsdl/resSvc" 
  xmlns:tns="http://greath.example.com/2004/wsdl/resSvc"
  xmlns:ghns="http://greath.example.com/2004/schemas/resSvc"
  xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
  xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">

 ....

  <!-- SOAP 1.2 Binding -->
  <binding name="reservationSOAPBinding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/ns/wsdl/soap"
    wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">

    <operation ref="tns:opCheckAvailability" 
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
  
    <fault ref="tns:invalidDataFault" 
      wsoap:code="soap:Sender"/>

  </binding>
  
  <!-- SOAP 1.1 Binding -->
  <binding name="reservationSOAP11Binding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/ns/wsdl/soap"
    wsoap:version="1.1"
    wsoap:protocol="http://www.w3.org/2006/01/soap11/bindings/HTTP/">
  
    <operation ref="tns:opCheckAvailability"/>
  
    <fault ref="tns:invalidDataFault" 
      wsoap:code="soap11:Client"/>

  </binding>


  <service name="reservationService" 
    interface="tns:reservationInterface">

    <!-- SOAP 1.2 End Point -->
    <endpoint name="reservationEndpoint" 
      binding="tns:reservationSOAPBinding"
      address="http://greath.example.com/2004/reservation"/>

    <!-- SOAP 1.1 End Point -->
    <endpoint name="reservationEndpoint2"
      binding="tns:reservationSOAP11Binding"
      address="http://greath.example.com/2004/reservation"/>
  
  </service>  
</description>

2.5.6 The HTTP Binding Extension

In addition to the WSDL 2.0 SOAP binding extension described above, WSDL 2.0 Part 2 [WSDL 2.0 Adjuncts] defines a binding extension for HTTP 1.1 [IETF RFC 2616] and HTTPS [IETF RFC 2818], so that these protocols can be used natively to send and receive messages, without first encoding them in SOAP.

The HTTP binding extension provides many features to control:

• Which HTTP operation will be used. (GET, PUT, POST, DELETE, and other HTTP operations are supported.)

• Input, output and fault serialization

• Transfer codings

• Authentication requirements

• Cookies

• HTTP over TLS (https)

As with the WSDL 2.0 SOAP binding extension, the HTTP binding extension also provides defaulting rules to permit binding information to be specified at the interface level and used by default for each operation in the affected interface, however, defaulting rules are not provided for binding faults.

Here is an example of using the HTTP binding extension to check hotel room availability at GreatH.

<?xml version="1.0" encoding="utf-8" ?> 
<description xmlns="http://www.w3.org/ns/wsdl"
      . . .
      xmlns:whttp="http://www.w3.org/ns/wsdl/http" >

  . . .
  <binding name="reservationHTTPBinding"
      interface="tns:reservationInterface"
      type="http://www.w3.org/ns/wsdl/http"
      whttp:methodDefault="GET">

    <operation ref="tns:opCheckAvailability"
      whttp:location="{checkInDate}"  />
  </binding>

  <service name="reservationService"
    interface="tns:reservationInterface">

    <!-- HTTP 1.1 GET End Point -->
    <endpoint name="reservationEndpoint"
      binding="tns:reservationHTTPBinding"
      address="http://greath.example.com/2004/checkAvailability/"/>

  </service>
  . . .
</description>

. . .
<operation ref="tns:opCheckAvailability"
    whttp:location="bycheckInDate/{checkInDate/}"  >
. . .

2.5.7 HTTP GET Versus POST: Which to Use?

When a binding using HTTP is specified for an operation, the WSDL 2.0 author must decide which HTTP method is appropriate to use -- usually a choice between GET and POST. In the context of the Web as a whole (rather than specifically Web services), the W3C Technical Architecture Group (TAG) has addressed the question of when it is appropriate to use GET, versus when to use POST, in a finding entitled URIs, Addressability, and the use of HTTP GET and POST ([W3C TAG Finding: Use of HTTP GET]). From the abstract:

". . . designers should adopt [GET] for safe operations such as simple queries. POST is appropriate for other types of applications where a user request has the potential to change the state of the resource (or of related resources). The finding explains how to choose between HTTP GET and POST for an application taking into account architectural, security, and practical considerations."

Recall that the concept of a safe operation was discussed in 2.4.4.1 Operation Attributes. (Briefly, a safe operation is one that does not cause the invoker to incur new obligations.) Although the wsdlx:safe attribute of an interface operation indicates that the abstract operation is safe, it does not automatically cause GET to be used at the HTTP level when the binding is specified. The choice of GET or POST is determined at the binding level:

• If the WSDL 2.0 SOAP binding extension is used (2.5.5 The SOAP Binding Extension), with HTTP as the underlying transport protocol, then GET may be specified by setting:

  wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"

  on the binding element (to indicate the use of HTTP as the underlying protocol); and

  wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response/"

  on the binding operation element, which causes GET to be used by default.

• If the WSDL 2.0 HTTP binding extension is used directly (2.5.6 The HTTP Binding Extension), GET may be specified by setting either:

  whttp:methodDefault="GET"

  on the binding element; or

  whttp:method="GET"

  on the binding operation element, which overrides whttp:methodDefault if set on the binding element; or

  wsdlx:safe="true"

  on the bound interface operation . When the above two items are not explicitly set, and when the bound interface operation is marked safe, the HTTP Binding will by default set the method to GET.

For example, in the GreatH interface definition shown in 例2-4, the wsdlx:safe attribute is set to "true". The HTTP binding definition in 例2-14 may take advantage of that and be simplified as below and still have the http method set to GET by default:

<?xml version="1.0" encoding="utf-8" ?>  

<binding name="reservationHTTPBinding"

      interface="tns:reservationInterface"

      type="http://www.w3.org/ns/wsdl/http" >

    <operation ref="tns:opCheckAvailability"

        whttp:location="{checkInDate}"/>

  </binding>

3.2.1 Schemas in Imported Documents

In this example, we consider some GreatH Hotel Web services that retrieve and update reservation details. The retrieval Web service is defined in the retrieveDetails.wsdl WSDL 2.0 document, along with a schema for the message format. The updating Web service is defined in the updateDetails.wsdl WSDL 2.0 document which imports the first document and refers to both WSDL 2.0 and schema definitions contained in the imported document.

例3-3 shows the definition of the retrieval Web service in the http://greath.example.com/2004/services/retrieveDetails namespace. This WSDL 2.0 document also contains an inline schema that describes the reservation detail in the http://greath.example.com/2004/schemas/reservationDetails namespace. This schema is visible to the retrieveDetailsInterface interface definition which refers to it in the retrieve operation's output message.

                                                        <?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">

        <documentation>
                This document describes the GreatH Retrieve Reservation Details
                Web service.
        </documentation>

        <types>
                <xs:schema xmlns="http://www.w3.org/2001/XMLSchema"
                        targetNamespace="http://greath.example.com/2004/schemas/reservationDetails">

                        <xs:element name="reservationDetails">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="confirmationNumber"
                                                        type="string" />
                                                <xs:element name="checkInDate" type="date" />
                                                <xs:element name="checkOutDate" type="date" />
                                                <xs:element name="roomType" type="string" />
                                                <xs:element name="smoking" type="boolean" />
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:schema>
        </types>

        <interface name="retrieveDetailsInterface">

                <operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="#none" />
                        <output messageLabel="Out"
                                element="wdetails:reservationDetails" />
                </operation>

        </interface>

</description>
                                                

例3-4 shows the definition of the updating Web service in the http://greath.example.com/2004/services/updateDetails namespace. The updateDetailsInterface interface extends the retrieveDetailsInterface interface. However, the retrieveDetailsInterface belongs to the http://greath.example.com/2004/services/retrieveDetails namespace, so updateDetails.wsdl must import retrieveDetails.wsdl to make that namespace visible.

The updateDetailsInterface interface also uses the reservationDetails element definition that is contained in the inline schema of the imported retrieveDetails.wsdl document. However, this schema is not automatically visible within the updateDetails.wsdl document. To make it visible, the updateDetails.wsdl document must import the namespace of the inline schema within the types element using the XML schema import element.

In this example, the schemaLocation attribute of the import element has been omitted. The schemaLocation attribute is a hint to the WSDL 2.0 processor that tells it where to look for the imported schema namespace. However, the WSDL 2.0 processor has already processed the retrieveDetails.wsdl document which contains the imported namespace in an inline schema so it should not need any hints. However, this behavior depends on the implementation of the processor and so cannot be relied on.

Although the WSDL 2.0 document may validly omit the schemaLocation attribute, it is a best practice to either provide a reliable value for it or move the inline schema into a separate document, say reservationDetails.xsd, and directly import it in the types element of both retrieveDetails.wsdl and updateDetails.wsdl. In general, schemas that are expected to be referenced from more than one WSDL 2.0 document should be defined in a separate schema document rather than be inlined.

<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/updateDetails"
        xmlns:tns="http://greath.example.com/2004/services/updateetails"
        xmlns:retrieve="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">

        <documentation>
                This document describes the GreatH Update Reservation Details
                Web service.
        </documentation>

        <import
                namespace="http://greath.example.com/2004/services/retrieveDetails"
                location="retrieveDetails.wsdl" />

        <types>
                <xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationDetails" />
        </types>

        <interface name="updateDetailsInterface"
                extends="retrieve:retrieveDetailsInterface">

                <operation name="update"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In"
                                element="details:reservationDetails" />
                        <output messageLabel="Out"
                                element="details:reservationDetails" />
                </operation>

        </interface>

</description>

3.2.2 Multiple Inline Schemas in One Document

A WSDL 2.0 document may define multiple inline schemas in its types element. The two or more schemas may have the same target namespace provided that they do not define the same elements or types. It is an error to define the same element or type more than once, even if the definitions are identical.

Each namespace of an inline schema becomes visible to the Web service definitions. However, the namespaces are not automatically visible to the other inline schemas. Each inline schema must explicitly import any other namespace it references. The schemaLocation attribute is not required in this case since the WSDL 2.0 processor knows the location of each schema by virtue of having processed the enclosing WSDL 2.0 document.

To illustrate this, consider 例3-5 which contains two inline schemas. The http://greath.example.com/2004/schemas/reservationItems namespace contains some elements for items that appear in the reservation details. The http://greath.example.com/2004/schemas/reservationDetails namespace contains the reservationDetails element which refers to the item elements. The schema for the http://greath.example.com/2004/schemas/reservationDetails namespace contains an import element that imports the http://greath.example.com/2004/schemas/reservationItems namespace. No schemaLocation attribute is required for this import since the schema is defined inline in the importing document.

<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">

        <documentation>
                This document describes the GreatH Retrieve Reservation Details
                Web service.
        </documentation>

        <types>

                <xs:schema targetNamespace="http://greath.example.com/2004/schemas/reservationItems">

                        <xs:element name="confirmationNumber" type="string" />
                        <xs:element name="checkInDate" type="date" />
                        <xs:element name="checkOutDate" type="date" />
                        <xs:element name="roomType" type="string" />
                        <xs:element name="smoking" type="boolean" />

                </xs:schema>

                <xs:schema targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
                        xmlns:items="http://greath.example.com/2004/schemas/reservationItems">

                        <xs:import
                                namespace="http://greath.example.com/2004/schemas/reservationItems" />

                        <xs:element name="reservationDetails">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element ref="items:confirmationNumber" />
                                                <xs:element ref="items:checkInDate" />
                                                <xs:element ref="items:checkOutDate" />
                                                <xs:element ref="items:roomType" />
                                                <xs:element ref="items:smoking" />
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:schema>

        </types>

        <interface name="retrieveDetailsInterface">

                <operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="#none" />
                        <output messageLabel="Out"
                                element="wdetails:reservationDetails" />
                </operation>

        </interface>

</description>

3.2.3 The schemaLocation Attribute

In the preceding examples, schemas were defined inline in WSDL 2.0 documents. This section discusses the correct way to specify a schemaLocation attribute on a schema import element to provide a processor with a hint for locating these schemas.

例3-4 shows how one WSDL 2.0 document imports a schema defined in another, i.e. 例3-3. Similarly, 例3-5 shows how one schema in a WSDL 2.0 document imports another schema defined in the same document. In both of these examples, the schemaLocation attribute was omitted since the WSDL 2.0 processor was assumed to know how to locate the imported schemas because they were part of the WSDL 2.0 documents being processed. The schemaLocation attribute can be used to give the processor a URI reference that explicitly locates the schemas. A URI reference is a URI plus an optional fragment identifier that indicates part of the resource. For schemas, the fragment should identify the schema element. The simplest way to accomplish this is to use the id attribute, however XPointer (see [XPointer Framework]) can also be used.

<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">

        <documentation>
                This document describes the GreatH Retrieve Reservation Details
                Web service.
        </documentation>

        <types>

                <xs:schema id="items"
                        targetNamespace="http://greath.example.com/2004/schemas/reservationItems">

                        <xs:element name="confirmationNumber" type="string" />
                        <xs:element name="checkInDate" type="date" />
                        <xs:element name="checkOutDate" type="date" />
                        <xs:element name="roomType" type="string" />
                        <xs:element name="smoking" type="boolean" />

                </xs:schema>

                <xs:schema id="details"
                        targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
                        xmlns:items="http://greath.example.com/2004/schemas/reservationItems">

                        <xs:import
                                namespace="http://greath.example.com/2004/schemas/reservationItems"
                                schemaLocation="#items" />

                        <xs:element name="reservationDetails">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element ref="items:confirmationNumber" />
                                                <xs:element ref="items:checkInDate" />
                                                <xs:element ref="items:checkOutDate" />
                                                <xs:element ref="items:roomType" />
                                                <xs:element ref="items:smoking" />
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:schema>

        </types>

        <interface name="retrieveDetailsInterface">

                <operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="#none" />
                        <output messageLabel="Out"
                                element="wdetails:reservationDetails" />
                </operation>

        </interface>

</description>

4.1.1 Optional Versus Required Extensions

Extensions can either be required or optional.

An optional extension is one that the client may either engage or ignore, entirely at its discretion, and is signaled by wsdl:required="false" or the absence of the wsdl:required attribute (because it defaults to false). Thus, a WSDL 2.0 processor, acting on behalf of the client, that encounters an unknown optional extension can safely ignore it and continue to process the WSDL 2.0 document. However, it is important to stress that optional extensions are only optional to the client -- not the service. A service must support all optional and required extensions that it advertises in its WSDL 2.0 document.

A required extension is one that must be supported and engaged by the client in order for the interaction to proceed properly, and is signaled by wsdl:required="true". If a WSDL 2.0 processor, acting on behalf of the client, encounters a required extension that it does not recognize or does not support, then it cannot safely continue to process the WSDL 2.0 document. In most practical cases, this is likely to mean that the processor will require manual intervention to deal with the extension. For example, a client developer might manually provide an implementation for the required extension to the WSDL 2.0 processor.

4.2.1 Confirmed Challenge

This pattern consists of two or more messages in order as follows:

1. A message:

   • indicated by a Message Label component whose message label is "Request" and direction is "in"

   • received from some node N1

2. A message:

   • indicated by a Message Label component whose message label is "Challenge" and direction is "out"

   • sent to some node N2 (which may be the same node as N1)

3. An optional message:

   • indicated by a Message Label component whose message label is "Confirmation" and direction is "in"

   • received from node N2

4. An optional message:

   • indicated by a Message Label component whose message label is "Response" and direction is "out"

   • sent to node N2

This pattern uses the rule Message Triggers Fault.

An operation using this message exchange pattern has a pattern property with the value "http://www.example.com/webservices/meps/confirmed-challenge".

Once the MEP had been defined (and the email binding specification appropriately modified to indicate that this was a supported MEP), the service was redefined and redeployed. Only the changed operations are shown in the excerpt below.

<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/ns/wsdl"
      targetNamespace="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
      xmlns:tns="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
      xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
      xmlns:email="http://www.example.com/webservices/email" >

   . . .

    <interface name="weatherInterface">
        <operation name="opSubscribeWeather"
                   pattern="http://www.example.com/webservices/meps/confirmed-challenge">
            <input messageLabel="Request" element=". . ." />
            <output messageLabel="Challenge" element=". . ." />
            <input messageLabel="Confirmation" element=". . ." />
            <output messageLabel="Response" element=". . ." />
        </operation>
        <operation name="opUnsubscribeWeather"
                   pattern="http://www.example.com/webservices/meps/confirmed-challenge">
            <output messageLabel="Challenge" element=". . ." />
            <output messageLabel="Response" element=". . ." />
            <input messageLabel="Confirmation" element=". . ." />
            <input messageLabel="Request" element=". . ." />
        </operation>
        . . .
    </interface>

    . . .

</description>

Note: in the second example, the input and output examples are not in the sequence in which they occur in the pattern; this illustrates that the sequence is not significant. Note, however, that for this pattern, the messageLabel attribute is required on every input and output element.

5.2.1 Compatible Evolution

In compatible evolution, designers are expected to limit changes to those that are either backward or forward compatible, or both:

Backward compatible

The receiver behaves correctly if it receives a message in an older version of the interaction language.

Forward compatible

The receiver behaves correctly if it receives a message in a newer version of the interaction language.

Since Web services and their clients both send and receive messages, these concepts can apply to both parties. However, since WSDL 2.0 is service-centric, we will focus on the case of service evolution.

There are three critical areas in which a service described in WSDL 2.0 my evolve:

• The service now also supports additional binding. In compatible evolution, this should be a safe addition, given that adding a new binding should not impact any existing interactions using another transport.

• An interface supports new operations. Again, in compatible evolution this is usually safe, given that adding an additional operation to an abstract interface should not impact any existing interactions.

• The message bodies may include additional data. How the message contents may change within a description depends to a large extent upon the type system being used to describe the message contents. RelaxNG [RELAX NG] has good support for describing vocabularies that ignore unknown XML, as does OWL/RDF. XML Schema 1.0 has limited support for extending the description of a message via the xs:any and xs:anyAttribute constructs. XML Schema 1.1 has been chartered to provide "changes necessary to provide better support for versioning of schemas", and it is anticipated that this may include improved support for more "open content" and therefore better support for compatible evolution of messages.

• The protocol used to exchange messages may provide mechanisms for exchanging data outside of the message body. In the case of SOAP, the WSDL 2.0 binding provides the ability to describe application data to be exchanged as headers. The SOAP processing model has a very good extensibility model with unknown headers being ignored by a receiver by default. There is also a mechanism whereby headers which are required as a part of an incompatible change may be marked with a 'mustUnderstand' flag. Passing additional items as headers may be the only way to compatibly evolve messages with fixed bodies.

5.2.2 Big Bang

The big bang approach to versioning is the simplest to currently represent in WSDL 2.0. In this approach, any change to a WSDL 2.0 document implies a change to the document's namespace, a change to the interface implies a new interface namespace and a change to the message contents is communicated using a new message namespace. This approach has particular benefits where an agent may quickly tell if a service has changed by simply comparing the namespace value.

5.2.3 Evolving a Service

Compatible changes are far more easily managed than incompatible ones:

• With a compatible change the service need only support the latest version of a service. A client may continue to use a service adjusting to new version of the interface description at a time of its choosing.

• With an incompatible change, the client receives a new version of the interface description and is expected to adjust to the new interface before old interface is terminated. Either the service will need to continue to support both versions of the interface during the hand over period, or the service and the clients are coordinated to change at the same time. An alternative is for the client to continue until it encounters an error, at which point it uses the new version of the interface.

5.2.4 Combined Approaches

It is feasible to combine the "compatible evolution" and "big bang" approaches in a variety of different ways. For example, the namespace could be changed when message descriptions are changed, but the namespace could stay the same when new operations are added.

While the big bang approach is currently the easiest to implement in WSDL 2.0, it can lead to a large number of cloned interfaces that become difficult to manage, thus making the compatible approach preferable to many for widely distributed systems. In the end, the choice of a versioning strategy for Web services described in WSDL 2.0 is left as an exercise to the reader.

5.2.5 Examples of Versioning and Extending a Service

<xs:complexType name="tCheckAvailability">     
    <xs:sequence>      
      <xs:element  name="checkInDate" type="xs:date"/>      
      <xs:element  name="checkOutDate" type="xs:date"/>      
      <xs:element  name="roomType" type="xs:string"/>
      <xs:element  name="numberOfGuests" type="xs:integer" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax"/>
    </xs:sequence>
</xs:complexType>     
        

<xs:element name="NumberOfGuests" type="tNumberOfGuests"/>
<xs:complexType name="tNumberOfGuests">     
    <xs:sequence>      
        <xs:element  name="numberOfGuests" type="xs:integer" minOccurs="0"/>
    </xs:sequence>
</xs:complexType>

<binding name="reservationSOAPBinding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/ns/wsdl/soap"
    wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">

    <operation ref="tns:opCheckAvailability">
       <input>
         <wsoap:header element="tns:NumberOfGuests"/>
       </input>
    </operation>
...
</binding>
    

<xs:complexType name="tCheckAvailabilityV2">     
    <xs:sequence>      
    <xs:element  name="checkInDate" type="xs:date"/>      
    <xs:element  name="checkOutDate" type="xs:date"/>      
    <xs:element  name="roomType" type="xs:string"/>
    <xs:element  name="numberOfGuests" type="xs:integer"/>
    <xs:any namespace="##other" processContents="lax"/>
    </xs:sequence>
</xs:complexType>     
            

<interface name="reservationWithConfirmation" extends="cc:creditCardFaults">
    ... 
    <operation name="makeReservation">
        <input messageLabel="In" element="ghns:makeReservation" />
        <output messageLabel="Out" element="ghns:makeReservationResponse" />
        <outfault ref="invalidDataFault" messageLabel="Out" />
        <outfault ref="cc:cancelledCreditCard" messageLabel="Out" />
        <outfault ref="cc:expiredCreditCard" messageLabel="Out" />
        <outfault ref="cc:invalidCreditCardNumber" messageLabel="Out" />
        <outfault ref="cc:invalidExpirationDate" messageLabel="Out" />
    </operation>
    <operation name="confirmReservation">
        <input messageLabel="In" element="ghns:makeReservationResponse" />
        <output messageLabel="Out" element="ghns:confirmReservationResponse" />
        <outfault ref="expiredReservation" messageLabel="Out" />
    </operation>
</interface>
            

<binding name="reservationSOAPBinding" 
        interface="tns:reservationInterface"
        type="http://www.w3.org/ns/wsdl/soap"
        wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
    <operation ref="tns:makeReservation"
        wsoap:action="tns:makeReservationV2"/>
    . . .
            

<xs:element name="ghns2:makeReservation" type="ghns:tmakeReservation"/>

<interface . . .>

   <operation name="makeReservation">

       <input messageLabel="In" element="ghns2:makeReservation" />

</interface>
    

5.3.1 The Reservation Details Web Service

When designing a Web application it is natural to give each important concept a URI. In the GreatH hotel reservation system, the important concepts are reservations, so we begin our design by assigning a URI to each reservation. Since each reservation has a unique confirmation number, e.g OMX736, we create a URI for each reservation by appending the confirmation number to a base URI, e.g. http://greath.example.com/2004/reservation/OMX736. This URI will be the endpoint address for a Reservation Details Web service that can retrieve and update the state of a reservation. 例5-7 shows the format of the reservation detail.

<?xml version="1.0" encoding="UTF-8"?>
<reservationDetails
        xmlns="http://greath.example.com/2004/schemas/reservationDetails">

        <confirmationNumber>OMX736</confirmationNumber>
        <checkInDate>2005-06-01</checkInDate>
        <checkOutDate>2005-06-03</checkOutDate>
        <roomType>single</roomType>
        <smoking>false</smoking>

</reservationDetails>

The Reservation Details Web service provides operations for retrieving and updating the detail for a reservation. 例5-8 shows the description for this Web service. Note that there is no service element in this description since the set of reservations is dynamic. Instead, the endpoints for the reservations will be returned by querying the Reservation List Web service.

<?xml version="1.0" encoding="utf-8" ?>
<description 
        xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/reservationDetails"
        xmlns:tns="http://greath.example.com/2004/services/reservationDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">

        <documentation>
                This document describes the GreatH Reservation Details Web
                services. Use these services to retrieve or update reservation
                details. Each reservation has its own service and endpoint. To
                obtain the reference for a reservation service, make a request to
                the GreatH Reservation List Web service. See
                reservationList.wsdl for a description of the Reservation List
                Web service.
        </documentation>

        <types>
                <xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationDetails"
                        schemaLocation="reservationDetails.xsd" />
        </types>

        <interface name="reservationDetailsInterface">

                <operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="#none" />
                        <output messageLabel="Out"
                                element="wdetails:reservationDetails" />
                </operation>

                <operation name="update"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In"
                                element="wdetails:reservationDetails" />
                        <output messageLabel="Out"
                                element="wdetails:reservationDetails" />
                </operation>

        </interface>

        <binding name="reservationDetailsSOAPBinding"
                interface="tns:reservationDetailsInterface"
                type="http://www.w3.org/ns/wsdl/soap"
                wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">

                <operation ref="tns:retrieve"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />

                <operation ref="tns:update"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />

        </binding>

</description>

例5-9 shows the XML schema elements that are used in this Web service.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:tns="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wdetails="http://greath.example.com/2004/services/reservationDetails"
        xmlns:wsdli="http://www.w3.org/ns/wsdl-instance"
        xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions"
        wsdli:wsdlLocation="http://greath.example.com/2004/services/reservationDetails reservationDetails.wsdl">

        <element name="confirmationNumber" type="string" />

        <element name="checkInDate" type="date" />

        <element name="checkOutDate" type="date" />

        <element name="reservationDetails">
                <complexType>
                        <sequence>
                                <element ref="tns:confirmationNumber" />
                                <element ref="tns:checkInDate" />
                                <element ref="tns:checkOutDate" />
                                <element name="roomType" type="string" />
                                <element name="smoking" type="boolean" />
                        </sequence>
                </complexType>
        </element>

        <simpleType name="reservationDetailsSOAPEndpointType" wsdlx:binding="wdetails:reservationDetailsSOAPBinding">
                <restriction base="anyURI"/>
        </simpleType>

        <element name="reservationDetailsSOAPEndpoint" type="tns:reservationDetailsSOAPEndpointType" />

        <element name="reservationDetailsService">
                <annotation>
                        <documentation>
                                This element contains references to the Reservation
                                Details Web Service endpoints for this reservation.
                        </documentation>
                </annotation>
                <complexType>
                        <sequence>
                                <element name="soap" type="tns:reservationDetailsSOAPEndpointType"/>
                                <element name="secure-soap" type="tns:reservationDetailsSOAPEndpointType"/>
                        </sequence>
                </complexType>
        </element>

</schema>

This XML schema contains the usual definitions for the elements that appear in the messages of the Web service. For example, the reservationDetails element is used in the messages of the retrieve and update operations. In addition, the schema defines the simple type reservationDetailsSOAPEndpointType which is based on xs:anyURI and has the annotation wsdlx:binding = "wdetails:reservationDetailsSOAPBinding" which means that the URI is the address of a Reservation Details Web service endpoint that implements the wdetails:reservationDetailsSOAPBinding binding. Note that the wsdli:wsdlLocation attribute is used to define the location of the WSDL 2.0 document that defines the wdetails:reservationDetailsSOAPBinding binding. This annotated simple type is used to define the reservationDetailsSOAPEndpoint element which will be used in the Reservation List service.

5.3.2 The Reservation List Web Service

Since the set of reservations changes as reservations are made and cancelled, the Reservation Detail endpoints are not described in a fixed WSDL 2.0 document. Instead they are returned as references to endpoints in response to requests made on a Reservation List Web service. The endpoint address for the Reservation List service will be http://greath.example.com/2004/reservationList.

例5-10 shows the format of the response from the Reservation List service.

<?xml version="1.0" encoding="UTF-8"?>
<reservationList
        xmlns="http://greath.example.com/2004/schemas/reservationList"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails">

        <reservation>
                <details:confirmationNumber>HSG635</details:confirmationNumber>
                <details:checkInDate>2005-06-27</details:checkInDate>
                <details:checkOutDate>2005-06-28</details:checkOutDate>
                <details:reservationDetailsSOAPEndpoint>
                        http://greath.example.com/2004/reservation/HSG635
                </details:reservationDetailsSOAPEndpoint>
        </reservation>

        <reservation>
                <details:confirmationNumber>OMX736</details:confirmationNumber>
                <details:checkInDate>2005-06-01</details:checkInDate>
                <details:checkOutDate>2005-06-03</details:checkOutDate>
                <details:reservationDetailsSOAPEndpoint>
                        http://greath.example.com/2004/reservation/OMX736
                </details:reservationDetailsSOAPEndpoint>
        </reservation>

        <reservation>
                <details:confirmationNumber>WUH663</details:confirmationNumber>
                <details:checkInDate>2005-06-11</details:checkInDate>
                <details:checkOutDate>2005-06-15</details:checkOutDate>
                <details:reservationDetailsSOAPEndpoint>
                        http://greath.example.com/2004/reservation/WUH663
                </details:reservationDetailsSOAPEndpoint>
        </reservation>

</reservationList>

Here, the <details:reservationDetailsSOAPEndpoint> elements contain references to the Reservation Details Web service endpoints for the reservations HSG635, OMX736, and WUH663.

例5-11 shows the description of the Reservation List Web service. Note that it contains operations to retrieve the entire list and to query for a list of reservations by confirmation number, check-in date, and check-out date. In each case, the operation returns a list of reservations.

<?xml version="1.0" encoding="utf-8" ?>
<description 
        xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/reservationList"
        xmlns:tns="http://greath.example.com/2004/services/reservationList"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:list="http://greath.example.com/2004/schemas/reservationList"
        xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">

        <documentation>
                This document describes the GreatH Reservation List Web
                services. Use this service to retrieve lists of reservations
                based on a variety of search criteria.
        </documentation>

        <types>
                <xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationDetails"
                        schemaLocation="reservationDetails.xsd" />
                <xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationList"
                        schemaLocation="reservationList.xsd" />
        </types>

        <interface name="reservationListInterface">

                <operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="#none" />
                        <output messageLabel="Out" element="list:reservationList" />
                </operation>

                <operation name="retrieveByConfirmationNumber"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In"
                                element="details:confirmationNumber" />
                        <output messageLabel="Out" element="list:reservationList" />
                </operation>

                <operation name="retrieveByCheckInDate"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="details:checkInDate" />
                        <output messageLabel="Out" element="list:reservationList" />
                </operation>

                <operation name="retrieveByCheckOutDate"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
                        <input messageLabel="In" element="details:checkOutDate" />
                        <output messageLabel="Out" element="list:reservationList" />
                </operation>

        </interface>

        <binding name="reservationListSOAPBinding"
                interface="tns:reservationListInterface"
                type="http://www.w3.org/ns/wsdl/soap"
                wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">

                <operation ref="tns:retrieve"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />

                <operation ref="tns:retrieveByConfirmationNumber"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />

                <operation ref="tns:retrieveByCheckInDate"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />

                <operation ref="tns:retrieveByCheckOutDate"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />

        </binding>

        <service name="reservationListService"
                interface="tns:reservationListInterface">

                <endpoint name="reservationListEndpoint"
                        binding="tns:reservationListSOAPBinding"
                        address="http://greath.example.com/2004/reservationList" />

        </service>

</description>

例5-12 shows the schema for the messages used in the Reservation List Web service.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        targetNamespace="http://greath.example.com/2004/schemas/reservationList"
        xmlns:tns="http://greath.example.com/2004/schemas/reservationList"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wsdli="http://www.w3.org/ns/wsdl-instance">

        <import
                namespace="http://www.w3.org/ns/wsdl-instance" />

        <import
                namespace="http://greath.example.com/2004/schemas/reservationDetails"
                schemaLocation="reservationDetails.xsd" />

        <element name="reservation">
                <annotation>
                        <documentation>
                                A reservation contains the confirmation number, check-in
                                and check-out dates, and a reference to a Reservation
                                Details Web service.
                        </documentation>
                </annotation>
                <complexType>
                        <sequence>
                                <element ref="details:confirmationNumber" />
                                <element ref="details:checkInDate" />
                                <element ref="details:checkOutDate" />
                                <element ref="details:reservationDetailsSOAPEndpoint" />
                        </sequence>
                </complexType>
        </element>

        <element name="reservationList">
                <annotation>
                        <documentation>
                                A reservation list contains a sequence of zero or more
                                reservations.
                        </documentation>
                </annotation>
                <complexType>
                        <sequence>
                                <element ref="tns:reservation" minOccurs="0"
                                        maxOccurs="unbounded">
                                </element>
                        </sequence>
                        <attribute ref="wsdli:wsdlLocation" />
                </complexType>
        </element>

</schema>

In the preceding example, there was a single endpoint associated with each Reservation Detail Web service. Suppose GreatH hotel decided to provide a second, secure endpoint. In this case, references to services would be used to collect together the endpoints for each reservation. The reservationDetails.xsd schema defines the reservationDetailsService element for this purpose. It contains the nested elements soap and secure-soap which are each of type reservationDetailsSOAPEndpointType and therefore contain the address of an endpoint that implements the wdetails:reservationDetailsSOAPBinding binding.

Example 5-13 shows an example of a message that contains a reference to the service for reservation HGS635. Note that the service contains two endpoints, one of which provides secure access to the Reservation Details Web service.

<?xml version="1.0" encoding="UTF-8"?>
<details:reservationDetailsService
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"

        <details:soap>
                http://greath.example.com/2004/reservation/HSG635
        </details:soap>

        <details:secure-soap>
                https://greath.example.com/2004/reservation/HSG635
        </details:secure-soap>
                        
</details:reservationDetailsService>

5.3.3 Reservation Details Web Service Using HTTP Transfer

This section presents a variation on the example in 5.3.1 The Reservation Details Web Service . It illustrates the use of HTTP transfer operations, GET and PUT, to retrieve and update GreatH hotel reservation details using the Representational State Transfer (REST) architectural style described by Roy Fielding [REST] . REST is a distillation of the architectural properties that Dr. Fielding identified as being vital to the Web's robustness and enormous scalability.

Since each reservation in our example will have a distinct URI, the Reservation Details Web service can be offered using HTTP GET and HTTP PUT. The binding would be modified as follows:

. . .
<binding name="reservationDetailsHTTPBinding"
        type="http://www.w3.org/ns/wsdl/http"
    interface="tns:reservationDetailsInterface" >

        <operation ref="tns:retrieve"
            whttp:method="GET" />

        <operation ref="tns:update"
            whttp:method="PUT" />

</binding>
. . .

As with the example in 5.3.1 The Reservation Details Web Service , service and endpoint elements are not provided because the Reservation List Web service provides the endpoints.

5.3.4 Reservation List Web Service Using HTTP GET

This section continues the REST-style example of 5.3.3 Reservation Details Web Service Using HTTP Transfer by modifying the example of 5.3.2 The Reservation List Web Service to use HTTP GET.

The SOAP version of the Reservation List Web service above offers four different search operations. These can also be expressed as various parameters in a URI used by HTTP GET:

. . .
<binding name="reservationListHTTPBinding"
        type="http://www.w3.org/ns/wsdl/http"
    interface="tns:reservationListInterface"
    whttp:methodDefault="GET">

  <operation ref="tns:retrieve"
      whttp:location="" />

  <operation ref="tns:retrieveByConfirmationNumber"
      whttp:location="reservationList/ConfirmationNumber/{confirmationNumber/}" />

  <operation ref="tns:retrieveByCheckInDate"
      whttp:location="reservationList/CheckInDate/{checkInDate/}" />

  <operation ref="tns:retrieveByCheckOutDate"
      whttp:location="reservationList/CheckOutDate/{checkOutDate/}" />
</binding>
. . .
<service . . . >

  <endpoint name="reservationListEndpoint"
    binding="tns:reservationListHTTPBinding"
    address="http://greath.example.com/2004/reservationList" />
. . .
</service>
. . .

A retrieval by Confirmation Number URI would look like: http://greath.example.com/2004/reservationList/ConfirmationNumber/HSG635 .

Alternatively, a single query type may be provided. This query type is a sequence of optional items. Any items in the sequence are serialized into the URI query string. A query sequence for any of ConfirmationNumber, checkInDate, checkOutDate would look like this:

<element name="reservationQuery">
  <annotation>
    <documentation>
      A reservation contains the confirmation number, check-in
      and check-out dates, and a reference to a Reservation
      Details Web service.
    </documentation>
  </annotation>
  <complexType>
    <sequence>
      <element ref="details:confirmationNumber" minOccurs="0"/>
      <element ref="details:checkInDate" minOccurs="0"/>/>
      <element ref="details:checkOutDate" minOccurs="0"/>/>
    </sequence>
    </sequence>
  </complexType>
</element>

The WSDL 2.0 service that offers this type serialized as a parameter would look like this:

. . .
<interface name="reservationListInterfaceWithQuery">

  <operation name="retrieveByReservationQuery"
                pattern="http://www.w3.org/ns/wsdl/in-out">
    <input messageLabel="In"
        element="details:ReservationQuery" />
    <output messageLabel="Out"
        element="list:reservationList" />
  </operation>

</interface>

<binding name="reservationListQueryHTTPBinding"
        type="http://www.w3.org/ns/wsdl/http"
    interface="tns:reservationListInterfaceWithQuery"
    whttp:methodDefault="GET">

  <operation ref="tns:retrieveByReservationQuery"
      whttp:location="reservationList/{ReservationQuery}}" />

</binding>

. . .
  <endpoint name="reservationListEndpoint"
      binding="tns:reservationListHTTPBinding"
      address="http://greath.example.com/2004/reservationList" />
. . .

Various URIs would be: http://greath.example.com/2004/reservationList/ReservationQuery?confirmationNumber=HSG635 http://greath.example.com/2004/reservationList/ReservationQuery?checkInDate=06-06-05 .

It is important to observe that using the URI serialization can result in very flexible queries and few operations. The previous discrete SOAP operations are collapsed into one "parameterized" operation.

5.5.1 WSDL 2.0のためのRDF表現 (RDF Representation of WSDL 2.0)

WSDL 2.0: Mapping to RDF [WSDL 2.0 RDF Mapping]は、いかにしてWSDL 2.0構造が、個々のリソースを超越してリソースのクラス（OWLで説明されているオントロジーで記述される）とアサーションを使ってRDFで表現され得るかを記述している。 RDFが複数のリソースとそれらの間の関係を使ってナレッジを表わすように、我々はWSDL 2.0コンセプトをこのモデルに還元する必要がある。 このことは次のようにして実施される。

1. まず、全てのWSDL 2.0内のコンポネント（インタフェース、オペレーション、バインディング、サービス、エンドポイントなどと拡張も含む）は、Appendix C IRI-References for WSDL 2.0 Components of [WSDL 2.0 Core]によって作成された適切なURIsで識別されるリソースに還元される。

2. 更に、これらはりソースとして提示される：

   1. XM LSchemaから集められた要素宣言（また同様に、他のタイプのシステムから集められた他のコンポネント）

   2. メッセージ内容モデル

   3. メッセージ交換パターン（MEPを識別するURIはりソースのURIである）

   4. オペレーション・スタイル（MEPsと同様に、オペレーション・スタイルのURIはリソースのURIである）

3. 上に挙げた全てのリソースは、適切な型をrdf:typeステートメントで与えられる（例えば、インタフェースはInterfaceクラスに属し、そのインタフェース内のオペレーションはInterfaceOperationクラスに属する）。

4. WSDL 2.0内の全ての関係（OperationがInterfaceへ所属しており、与えられたオペレーション型を持っていることのような）は、operationとoperationStyleのような適切なプロパティを使ってRDFステートメントに還元される。

5.6.1 XML名前空間とSchemaロケーション (XML Namespaces and Schema Locations)

XM LSchemaのターゲット名前空間と対応するスキーマのロケーションをもつXMLインスタンスのxmlns属性の値を等価に考えることは普遍的な誤解である。 例え名前空間がURIsで、URIsがロケーションかもしれなくて、そのロケーションからスキーマを取得することが可能かもしれなくても、このことは、取得されたスキーマが、名前空間と関連付けられる唯一つのスキーマであることを意味しはしない。 特定の名前空間に関連付けられた複数のスキーマが存在可能だし、特定の処理コンテキストの中でどれを使うか決定するのは、XML処理系に任せられている。 WSDL 2.0仕様では、ここにimportメカニズムによって処理コンテキストを提供し、このメカニズムは類似したコンセプトでのためにXML Schemaの用語に基づいている。

5.6.2 相対URIs (Relative URIs)

この文書全体を通して、WSDL 2.0とXSDの例では、完全修飾URIsが存在する。 幾つかの場合では、完全修飾URIsは、単に、参照コンセプトを説明するために使われた。 しかしながら、相対URIsの利用は多くの場合に許され、正当化される。 相対URIsの処理に関する情報については、RFC3986を参照。

5.6.3 一時URIsの生成 (Generating Temporary URIs)

一般的には、WSDL 2.0文書が他の人たちに使われるために公開されるとき、グローバルに一意的なURIsだけを含んでいるべきである。 このことは、通常は、発行者の制御下にあるドメイン名配下のものを割り当てることで実施される。 例えば、W3Cでは、その基本ドメイン名w3.org配下の名前空間URIsを割り当てている。

しかしながら、時には、開発期間中の利用のために、実体に対する一時URIを作成し、全ての時間軸でグローバルに一意なURIにはしないが、そのバージョンの実体（スキーマ、WSDL 2.0文書など）を意味させたいことがある。 予約済みトップレベルDNS名 [IETF RFC 2606]は、このタイプの振る舞いのために使うために予約された幾つかのURIベースの名前を指定している。 例えば、ベースURI "http://example.org/"は、実体に対するいかなる一意的な関連付けも持たない一時URIを組み立てるために使うことができる。 これが意味するのは、二人の人、もしくは複数のプログラムが、二つの全く異なるスキーマのために、一時URI "http://example.org/userSchema"を同時に選択することができるということである。 これらのURIsを利用するスコープが交わらない限りにおいて、それらは十分に一意であるだろう。 しかしながら、安定的でフィックスされたエントリのためのベースとして"http://example.org/"を使うことはお勧めしない。