2006-05-29 diff-marked version: Web Services Addressing 1.0 - WSDL Binding

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [ IETF RFC 2119 ].

When describing abstract data models, this specification uses the notational convention used by the XML Infoset [ XML Information Set ]. Specifically, abstract property names always appear in square brackets (e.g., [some property]).

When describing concrete XML schemas [ XML Schema Structures , XML Schema Datatypes ], this specification uses the notational convention of WS-Security [ WS-Security ]. Specifically, each member of an element's [children] or [attributes] property is described using an XPath-like notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates the presence of an element wildcard (<xs:any/>). The use of @{any} indicates the presence of an attribute wildcard (<xs:anyAttribute/>).

1.2 Namespaces

This specification uses a number of namespace prefixes throughout; they are listed in Table 1-1 . Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [ XML Namespaces ]).

The working group intends to update the value of the Web Services Addressing 1.0 - WSDL Binding namespace URI each time a new version of this document is published until such time that the document reaches Candidate Recommendation status. Once it has reached Candidate Recommendation status, the working group intends to maintain the value of the Web Services Addressing 1.0 - WSDL Binding namespace URI that was assigned in the Candidate Recommendation unless significant changes are made that impact the implementation of the specification.

WS-Addressing is defined in terms of the XML Information Set [ XML Information Set ]. WS-Addressing may can be used with SOAP [ SOAP 1.2 Part 1: Messaging Framework ,SOAP 1.1 ] as described in Web Services Addressing 1.0 - SOAP Binding[ WS-Addressing-SOAP WS-Addressing SOAP Binding ]. The examples in this specification use an XML 1.0 [ XML 1.0 ] representation but this is not a requirement.

All information items defined by this specification are identified by the XML namespace URI [ XML Namespaces ] "http://www.w3.org/2006/02/addressing/wsdl". "http://www.w3.org/2006/05/addressing/wsdl". A normative XML Schema [ XML Schema Structures , XML Schema Datatypes ] document can be obtained by dereferencing the XML namespace URI.

2.1 Referencing WSDL Metadata from an EPR

The WSDL binding of Web Services Addressing introduces the following element and attribute information items for referencing WSDL metadata from an EPR's metadata section:

wsaw:InterfaceName (0..1)

A QName identifying a description of the sequences of messages that a service sends and/or receives. This corresponds to a WSDL 2.0 interface or, for backwards compatibility, a WSDL 1.1 port type. When this element is included in an EPR, the EPR is considered to be specific to the interface or port type it identifies.

wsaw:ServiceName (0..1)

A QName that identifies the set of endpoints at which a particular Web service is deployed. The set of endpoints is represented by a service in WSDL 2.0 or, for backwards compatibility, a WSDL 1.1 service.

wsaw:ServiceName/@EndpointName (0..1)

An NCName that identifies one endpoint amongst the set identified by deleted text: by the service name above. An endpoint is represented by an endpoint in WSDL 2.0 or, for backwards compatibility, a port in WSDL 1.1. When this attribute is specified, the EPR is considered to be specific to the endpoint or port it identifies.

The element information items defined above are used in an EPR's metadata section. The following shows an example endpoint reference. This references the interface named "fabrikam:Inventory" "ghns:reservationInterface" at the endpoint IRI "http://example.com/www.fabrikam/acct". "http://greath.example.com/2004/reservation". Note the use of the WSDL[ WSDL 2.0 ] wsdlLocation attribute.

<wsa:EndpointReference
    xmlns:wsa="http://www.w3.org/2005/08/addressing"


    xmlns:fabrikam="http://example.com/fabrikam">
  <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>



    xmlns:ghns="http://greath.example.com/2004/wsdl/resSvc">
  <wsa:Address>http://greath.example.com/2004/reservation</wsa:Address>


  <wsa:Metadata
      xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance"


      wsdli:wsdlLocation="http://example.com/fabrikam http://example.com/fabrikam.wsdl">
    <wsaw:InterfaceName>fabrikam:Inventory</wsaw:InterfaceName>



      wsdli:wsdlLocation="http://greath.example.com/2004/wsdl/resSvc http://greath.example.com/2004/reservation.wsdl">
    <wsaw:InterfaceName>ghns:reservationInterface</wsaw:InterfaceName>


  </wsa:Metadata>
</wsa:EndpointReference>

2.2 Embedding WSDL Metadata in an EPR

WSDL 2.0 or, for backwards compatibility, 1.1 definitions can be embedded in the metadata section of an EPR to provide a consuming application with WSDL information that applies to the referenced endpoint. To do so, the creator of an EPR MAY include a WSDL 2.0 description element (or a WSDL 1.1 definitions element) in the metadata property of the EPR. The semantics of the embedded WSDL is as defined by the WSDL 2.0 or 1.1 specifications.

In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint. The alternatives are provided by the different endpoints of the embedded service. In the case of WSDL 1.1, additional ports may can be conveyed by the WSDL 1.1 service definition which are not alternative access channels to the endpoint. In that case, if the InterfaceName or ServiceName elements are also included in the metadata section of the EPR, only the ports with the same interface as that specified are to be considered alternative access channels.

If the ServiceName element appears in the EPR’s [metadata] and an embedded WSDL service component is also provided inside a descriptions or definitions component, then the ServiceName SHOULD match the name of (one or more of) the WSDL service(s) included therein; the endpoint (port) name SHOULD match as well if present. The behavior of an EPR consumer when the ServiceName doesn’t match an embedded description is undefined.

<wsa:EndpointReference
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    


  <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>



  <wsa:Address>http://greath.example.com/2004/reservation</wsa:Address>


  <wsa:Metadata
      xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance"


      wsdli:wsdlLocation="http://example.com/fabrikam http://example.com/fabrikam.wsdl">



      wsdli:wsdlLocation="http://greath.example.com/2004/wsdl/resSvc http://greath.example.com/2004/reservation.wsdl">


    <wsdl20:description  


        targetNamespace="http://example.com/fabrikam"
        xmlns:fabrikam="http://example.com/fabrikam"
        xmlns:abc="http://www.abccorp.com/"



        targetNamespace="http://greath.example.com/2004/wsdl/resSvc"
        xmlns:tns="http://greath.example.com/2004/wsdl/resSvc"
        xmlns:ghns="http://greath.example.com/2004/wsdl/resSvc"


        xmlns:wsdl20="http://www.w3.org/2006/01/wsdl">


      <wsdl20:import namespace="http://example.com/fabrikam/"
          location="http://example.com/fabrikam/fabrikam.wsdl/"/>
      <wsdl20:import namespace="http://www.abccorp.com/" 
          location="http://www.abccorp.com/abc.wsdl"/>
      <wsdl20:service name="InventoryService" 
          interface="fabrikam:Inventory">
        <wsdl20:endpoint name="ep1" binding="abc:soap-http-binding" 
            address="http://example.com/fabrikam/acct"/>
        <wsdl20:endpoint name="ep2" binding="abc:iiop" 
            address="..."/>
        <wsdl20:endpoint name="ep3" 
            binding="abc:soap-http-binding" 
            address="http://alt.example.com/fabrikam/acct"/>



      <wsdl20:import namespace="http://greath.example.com/2004/wsdl/resSvc"
          location="http://greath.example.com/2004/reservation.wsdl"/>
      <wsdl20:service name="reservationService" 
          interface="tns:reservationInterface">
        <wsdl20:endpoint name="reservationEndpoint" 
          binding="tns:reservationSOAPBinding"
          address ="http://greath.example.com/2004/reservation"/>


      </wsdl20:service>
    </wsdl20:description>
  </wsa:Metadata>
</wsa:EndpointReference>

<wsa:EndpointReference
    xmlns:wsa="http://www.w3.org/2005/08/addressing">


  <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>



  <wsa:Address>http://greath.example.com/2004/reservation</wsa:Address>


  <wsa:Metadata>


    <wsdl11:definitions targetNamespace="http://example.com/fabrikam"
        xmlns:fabrikam="http://example.com/fabrikam"
        xmlns:abc="http://www.abccorp.com/"



    <wsdl11:definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc"
        xmlns:ghns="http://greath.example.com/2004/wsdl/resSvc"


        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
deleted text: 

        xmlns:iiop="http://www.iiop.org/"


        xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/">


      <wsdl11:import namespace="http://example.com/fabrikam"  
          location="http://example.com/fabrikam/fabrikam.wsdl"/>
      <wsdl11:import namespace="http://www.abccorp.com/" 
          location="http://www.abccorp.com/abc.wsdl"/>
      <wsdl11:service name="InventoryService">
        <wsdl11:port name="ep1" binding="abc:soap-http-binding"> 
          <soap:address location="http://example.com/fabrikam/acct"/>
        </wsdl11:port>
        <wsdl11:port name="ep2" binding="abc:iiop"> 
          <iiop:address location="..."/>



      <wsdl11:import namespace="http://greath.example.com/2004/wsdl/resSvc"  
          location="http://greath.example.com/2004/reservation.wsdl"/>
      <wsdl11:service name="reservationService">
        <wsdl11:port name="ep1" binding="ghns:reservationSOAPBinding"> 
          <soap:address location="http://greath.example.com/2004/reservation"/>


        </wsdl11:port>
      </wsdl11:service>
    </wsdl11:definitions>
  </wsa:Metadata>
</wsd:EndpointReference>

3.1 UsingAddressing Extension Element

WS-Addressing defines an empty global element, wsaw:UsingAddressing, that may can be used to indicate that an endpoint conforms to the WS-Addressing specification. The wsdl:required attribute MAY be used to indicate whether WS-Addressing Message Addressing Properties are required in messages received from service requesters. Table 3-1 outlines the requirements on messages sent from an endpoint based on the contents of any preceding input message and how the use of addressing is indicated in the WSDL.

If WS-A is engaged, use of the message addressing properties MUST be fully compliant with this specification; in particular, senders MUST use all message addressing properties mandated by the Web Services Addressing 1.0 - Core[ WS-Addressing-Core WS-Addressing Core ], applicable WS-Addressing protocol bindings (e.g. Web Services Addressing 1.0 - SOAP Binding[ <a href= "#WSADDR-SOAP"> WS-Addressing-SOAP WS-Addressing SOAP Binding ]), and this specification, and MUST follow all applicable WS-Addressing normative requirements.

The wsaw:UsingAddressing element SHOULD appear as a child of the wsdl:binding element. Alternatively, the wsaw:UsingAddressing element MAY instead be included as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to indicate compliance with WS-Addressing for a specific endpoint only.

The inclusion of the wsaw:UsingAddressing element indicates that the applicable WS-Addressing specifications are supported and allows use of anonymous or non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP binding, the wsaw:UsingAddressing marker identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[ <a href= "#WSADDR-SOAP"> WS-Addressing-SOAP WS-Addressing SOAP Binding ].The presence of this element may can extend the semantics of the endpoint's WSDL binding.

<binding name="reservationSOAPBinding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/2006/01/wsdl/soap"
    wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
  <wsaw:UsingAddressing wsdl:required="true" />
  <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>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">



<binding name="reservationSOAPBinding"
                        type="tns:reservationInterface">


  <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
  <wsaw:UsingAddressing wsdl:required="true" />


  <operation name="GetLastTradePrice">
    <soap:operation soapaction="http://example.com/GetLastTradePrice" />



  <operation name="opCheckAvailability">
    <soap:operation soapaction="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability" />


    <input> 
      <soap:body use="literal" />
    </input> 
    <output>
      <soap:body use="literal" />
    </output>
  </operation>
</binding>

3.2 Anonymous Element

WS-Addressing defines a wsaw:Anonymous element that may is only deleted text: be used in conjunction with wsaw:UsingAddressing (or its equivalent wsoap:module) wsoap:module, see section 3.3 WSDL SOAP Module ) element. The usage of wsaw:Anonymous element is associated with the usage constraints specified for the wsaw:UsingAddressing element. Hence, it MUST NOT contain the wsdl:required attribute.

The inclusion of wsaw:Anonymous without inclusion of A WSDL or policy based service description that includes the wsaw:UsingAddressing has but no deleted text: normative meaning and is only informational. In other words, the inclusion of wsaw:Anonymous element in WSDL alone does not imply marker makes no assertion regarding a requirement on clients to or a constraint in the use Message Addressing Properties of the anonymous URI in EPRs contained in messages it sends sent to the service. A client, however, MAY include Message Addressing Properties in the messages it sends, either endpoint. In this cases, endpoint service descriptions have to rely on its own initiative or additional metadata, such as described WSDL bindings or additional policy assertions, to indicate any requirements or restrictions on the use of the anonymous URI by other elements clients. However, in the absence of additional metadata, clients of the endpoint MAY assume that the service contract, regardless endpoint follows the behavior indicated by the 'optional' value of the presence wsaw:Anonymous marker. An endpoint SHOULD send a wsa:OnlyAnonymousAddressSupported or deleted text: absence of a wsaw:UsingAddressing element. wsa:OnlyNonAnonymousAddressSupported fault back to the client if a message received includes a response epr with an [address] that is unsupported by the endpoint.

The wsaw:Anonymous element MAY element, if present, MUST have one of three distinct values that indicate three different levels of support for handling anonymous addresses in EPRs. In the following text, the term response endpoint EPR refers to the [reply endpoint] and [fault endpoint] message addressing properties collectively.

• "optional": This value indicates that a response endpoint EPR in a request message MAY contain an anonymous URI as an address.

  deleted text: <p> This is the default value, omission of a wsaw:Anonymous element is equivalent to inclusion with this value. </p>

• "required":This value indicates that all response endpoint EPRs in a request message MUST always use anonymous URI as an address.

  If a response endpoint EPR does not contain the anonymous URI as an address value, then a predefined InvalidAddressingHeader fault defined in Web Services Addressing 1.0 - SOAP Binding [ WS-Addressing-SOAP WS-Addressing SOAP Binding ] MUST be generated.

• "prohibited":This value indicates that any response EPRs in a request message MUST NOT use anonymous URI as an address.

  If a response endpoint EPR contains the anonymous URI as an address value, then a predefined InvalidAddressingHeader fault defined in Web Services Addressing 1.0 - SOAP Binding [ WS-Addressing-SOAP WS-Addressing SOAP Binding ] MUST be generated.

This element MAY appear as a child of an operation element in a binding element in WSDL 1.1, or as a binding operation extension element in WSDL 2.0.

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">



<binding name="reservationSOAPBinding" type="tns:reservationInterface">


  <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
  <wsaw:UsingAddressing wsdl:required="true" />


  <operation name="GetLastTradePrice">
    <soap:operation soapaction="http://example.com/GetLastTradePrice" />



  <operation name="opCheckAvailability">
    <soap:operation soapaction="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability" />


    <input>
      <soap:body use="literal" />
    </input>
    <output>
      <soap:body use="literal" />
    </output>
    <wsaw:Anonymous>required</wsaw:Anonymous>
  </operation>
deleted text: 

  <operation name="someOther">...</operation>


</binding>

3.3 WSDL SOAP Module

In WSDL 2.0, the wsoap:module construct may a SOAP Module component can be used to declare the use of the WS-Addressing 1.0 Module for the SOAP binding. The meaning of the use of such a wsoap:module declaration SOAP Module component is semantically equivalent to wsaw:UsingAddressing the {addressing} property defined in this case. section 3.1.1 WSDL 2.0 Component Model Changes . Note that this module is not only meaningful when used on WSDL constructs components where wsaw:UsingAddressing the {addressing} property is not allowed. allowed, i.e. as a member of the {soap modules} property of a Binding component.

The WS-Addressing 1.0 SOAP Module is described in Web Services Addressing 1.0 - SOAP Binding[ WS-Addressing-SOAP WS-Addressing SOAP Binding ] and is identified with the following URI: http://www.w3.org/2005/08/addressing/module

<binding name="reservationSOAPBinding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/2006/01/wsdl/soap"
    wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
  <wsoap:module uri="http://www.w3.org/2005/08/addressing/module" required="true" />
  <operation ref="tns:opCheckAvailability"
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response">
    <wsaw:Anonymous>required</wsaw:Anonymous>
  </operation>
  <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender" />
</binding>

4.1 Destination Extending WSDL Endpoints with an EPR

In A wsdl20:endpoint or wsdl11:port element MAY be extended using a child wsa:EndpointReference element. When extended this way, the absence [address] property of deleted text: additional runtime information, the child EPR MUST match the {address} property of the endpoint component (WSDL 2.0) or the address value provided by the relevant port extension (WSDL 1.1). For example, in a SOAP 1.1 port described using WSDL 1.1, the location attribute of a soap11:address element (if present) would have the same value as the wsa:Address child element of the wsa:EndpointReference element.

4.2 Destination

The value of the [destination] message addressing property for a message sent to an endpoint MUST match typically matches the value of the {address} property of the endpoint component (WSDL 2.0) or the address value (if any) provided by the relevant port extension (WSDL 1.1). For a SOAP 1.1 port described using WSDL 1.1, the value is provided by the location attribute of the soap11:address extension element. For an endpoint or port extended with an EPR (see 4.1 Extending WSDL Endpoints with an EPR ), the value is provided by the [address] property of the EPR.

Additional runtime information could override the value of the [destination] message addressing property for messages sent to an endpoint, e.g. a runtime exchange might result in a redirection to a different EPR. Note that WS-Addressing does not define any normative mechanism for such redirection.

4.3 Reference Parameters

When a wsa:EndpointReference element is present in a wsdl20:endpoint or a wsdl11:port element (see 4.1 Extending WSDL Endpoints with an EPR ), the value of the [reference parameters] message addressing property for a message sent to an endpoint MUST include the contents of the wsa:ReferenceParameters element, if one exists within that EPR.

4.2 4.4 Action

WS-Addressing defines two mechanisms to associate a value of the [action] property with input, output and fault elements within a WSDL description: explicit and defaulting. Explicit association is described in section 4.2.1 4.4.1 Explicit Association ; action defaulting (where a unique value for the [action] property is automatically generated) is described in section 4.2.4 4.4.4 Default Action Pattern for WSDL 1.1 for WSDL 1.1 and section 4.2.2 4.4.2 Default Action Pattern for WSDL 2.0 for WSDL 2.0.

Ensuring that there is sufficient information within a message to distinguish which WSDL operation it is associated with is specified as a best practice in WSDL 2.0 WSDL 2.0 . The [action] property provides a mechanism to fulfill that best practice.

<definitions targetNamespace="http://example.com/stockquote" ...>



<description targetNamespace="http://greath.example.com/2004/schemas/resSvc" ...>


  ...


  <interface name="StockQuoteInterface">
    <operation name="GetLastTradePrice" pattern="http://www.w3.org/2006/01/wsdl/in-out">
      <input element="tns:GetTradePricesInput" messageLabel="In"
            wsaw:Action="http://example.com/GetQuote"/>
      <output element="tns:GetTradePricesOutput" messageLabel="Out"
            wsaw:Action="http://example.com/Quote"/>



  <interface name="reservationInterface">
    <operation name="opCheckAvailability" pattern="http://www.w3.org/2006/01/wsdl/in-out">
      <input element="tns:checkAvailability" messageLabel="In"
            wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability"/>
      <output element="tns:checkAvailabilityResponse" messageLabel="Out"
            wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailabilityResponse"/>


    </operation>
  </interface>
  ...


</definitions>



</description>

<definitions targetNamespace="http://example.com/stockquote" ...>



<definitions targetNamespace="http://greath.example.com/2004/schemas/resSvc" ...>


  ...


  <portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
      <input message="tns:GetTradePricesInput"
            wsaw:Action="http://example.com/GetQuote"/>
      <output message="tns:GetTradePricesOutput"
            wsaw:Action="http://example.com/Quote"/>



  <portType name="reservationInterface">
    <operation name="opCheckAvailability">
      <input message="tns:checkAvailability"
            wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability"/>
      <output message="tns:checkAvailabilityResponse"
            wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailabilityResponse"/>


    </operation>
  </portType>
  ...
</definitions>
      

[target namespace][delimiter][interface name][delimiter][operation name][direction token]

[target namespace][delimiter][interface name][delimiter][fault name]

<definitions targetNamespace="http://example.com/stockquote" ...>



<definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc" ...>


  ...


  <interface name="StockQuoteInterface">
    <operation name="GetLastTradePrice" pattern="http://www.w3.org/2006/01/wsdl/in-out">
      <input element="tns:GetTradePricesInput" messageLabel="in" name="GetQuote"/>
      <output element="tns:GetTradePricesOutput" messageLabel="out" name="Quote"/>



  <interface name="reservationInterface">
    <operation name="opCheckAvailability" pattern="http://www.w3.org/2006/01/wsdl/in-out">
      <input element="tns:checkAvailability" messageLabel="in" name="CheckAvailability"/>
      <output element="tns:checkAvailabilityResponse" messageLabel="out" name="Availability"/>


    </operation>


  </portType>



  </interface>


  ...
</definitions>
      

[target namespace][delimiter][port type name][delimiter][input|output name]

[target namespace][delimiter][port type name][delimiter][operation name][delimiter]Fault[delimiter][fault name]

<definitions targetNamespace="http://example.com/stockquote" ...>



<definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc" ...>


  ...


  <portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
      <input message="tns:GetTradePricesInput" name="GetQuote"/>
      <output message="tns:GetTradePricesOutput" name="Quote"/>
          <fault message="tns:ErrorMessage" name="Error"/>



  <portType name="reservationInterface">
    <operation name="opCheckAvailability">
      <input message="tns:checkAvailability" name="CheckAvailability"/>
      <output message="tns:checkAvailabilityResponse" name="Availability"/>
          <fault message="tns:InvalidDate" name="InvalidDate"/>


    </operation>
  </portType>
  ...
</definitions>
      

<definitions targetNamespace="http://example.com/stockquote" ...>



<definitions targetNamespace="http://greath.example.com/2004/wsdl/resSvc" ...>


  ...


  <portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
      <input message="tns:GetTradePricesInput"/>
      <output message="tns:GetTradePricesOutput"/>



  <portType name="reservationInterface">
    <operation name="opCheckAvailability">
      <input message="tns:checkAvailability"/>
      <output message="tns:checkAvailabilityResponse"/>


    </operation>
  </portType>
  ...
</definitions>
      

5.1 WSDL 1.1 Message Exchange Patterns

For backwards compatibility, this section describes which of the core message properties are mandatory deleted text: or optional for messages in the various MEPs defined by WSDL 1.1.

5.2 WSDL 2.0 Message Exchange Patterns

This section describes which of the core message properties are mandatory deleted text: or optional for messages in the various MEPs defined by WSDL 2.0 [ WSDL 2.0 Adjuncts ].

7.1 Normative

[WS-Addressing-Core] [WS-Addressing Core]

<a href= "http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/"> Web Services Addressing 1.0 - Core , M. Gudgin, M. Hadley, and T. Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the WS-Addressing Core Recommendation is http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. The latest version of WS-Addressing Core is available at http://www.w3.org/TR/ws-addr-core.

[WS-Addressing-SOAP] [WS-Addressing SOAP Binding]

<a href= "http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/"> Web Services Addressing 1.0 - SOAP Binding , M. Gudgin, M. Hadley, and T. Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the WS-Addressing Core Recommendation is http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509. The latest version of WS-Addressing SOAP Binding is available at http://www.w3.org/TR/ws-addr-soap.

[WSDL 2.0]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language , R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide Web Consortium, 6 January 2006. This version of the WSDL 2.0 specification is http://www.w3.org/TR/2006/CR-wsdl20-20060106/. The latest version of WSDL 2.0 is available at http://www.w3.org/TR/wsdl20.

[WSDL 2.0 Adjuncts]

Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts , R. Chinnici, H. Haas, A. Lewis, J. J. Moreau, D. Orchard, S. Weerawarana, Editors. World Wide Web Consortium, 6 January 2006. This version of the WSDL 2.0 Adjuncts specification is http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/. The latest version of WSDL 2.0 Adjuncts is available at http://www.w3.org/TR/wsdl20-adjuncts.

[IETF RFC 2119]

Key words for use in RFCs to Indicate Requirement Levels , S. Bradner, Author. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.

[RFC 3987]

M. Duerst, M. Suignard, "Internationalized Resource Identifiers (IRIs)", January 2005. (See http://www.ietf.org/rfc/rfc3987.txt .)

[XML 1.0]

Extensible Markup Language (XML) 1.0 (Third Edition) , T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 4 February 2004. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2004/REC-xml-20040204. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.

[XML Namespaces]

Namespaces in XML , T. Bray, D. Hollander, and A. Layman, Editors. World Wide Web Consortium, 14 January 1999. This version of the XML Information Set Recommendation is http://www.w3.org/TR/1999/REC-xml-names-19990114. The latest version of Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.

[XML Information Set]

XML Information Set (Second Edition) , J. Cowan and R. Tobin, Editors. World Wide Web Consortium, 4 February 2004. This version of the XML Information Set Recommendation is http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The latest version of XML Information Set is available at http://www.w3.org/TR/xml-infoset.

[XML Schema Structures]

XML Schema Part 1: Structures Second Edition , H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.

[XML Schema Datatypes]

XML Schema Part 2: Datatypes Second Edition , P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.

[SOAP 1.2 Part 1: Messaging Framework]

SOAP Version 1.2 Part 1: Messaging Framework , M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web Consortium, 24 June 2003. This version of the "SOAP Version 1.2 Part 1: Messaging Framework" Recommendation is http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. The latest version of "SOAP Version 1.2 Part 1: Messaging Framework" is available at http://www.w3.org/TR/soap12-part1/.

[SOAP 1.1]

Simple Object Access Protocol (SOAP) 1.1 ,D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H Frystyk Nielsen, S. Thatte, D. Winer, Editors. W3C Member Submission, 8 May 2000.

[WSDL 1.1]

E. Christensen, et al, Web Services Description Language (WSDL) 1.1 , March 2001.

7.2 Informative

[WS-Security]

OASIS, Web Services Security: SOAP Message Security , March 2004.