Action item for issue i021

I took an action item to put forward some concrete spec text around the
proposal below. Here it is:

- Add a new Section 5 "WS-Addressing in WSDL bindings" with the following
text in it:

WSDL 1.1 and 2.0 Web service descriptions for endpoints that follow the
WS-Addressing specification, requiring WS-Addressing message information
headers in messages received from service requesters and encoding them in
messages returned to them, MUST indicate this requirement using the
<wsaws:UsingAddressing> extensibility element defined in this
specification. The wsdl:required=true MUST always be present in this
extensibility element.

Wen used in a WSDL service description, the <wsaws:UsingAddressing> element
SHOULD appear in the WSDL binding component of the service endpoint.  The
WS-Addressing extensibility marker MAY appear within any of the elements of
a WSDL binding: <wsdl:binding>, <wsdl:operation>, <wsdl:input>,
<wsdl:output>, <wsdl:fault> with semantics defined by the usual scoping
rules. The <wsaws:UsingAddressing> element MAY be instead included in the
<wsdl:endpoint> (or <wsdl:port> in the case of WSDL 1.1) when an endpoint
intends to indicate compliance with WS-Addressing when using an already
defined WSDL binding.

The inclusion of the <wsaws:UsingAddressing> element indicates that the
WS-Addressing specification is supported within the constraints of the WSDL
binding being used, that is, uses of the WS-Addressing specification that
may violate or are inconsistent with the semantics of the endpoint's WSDL
binding are not supported unless explicitly stated by some other mechanism.
In the case when the WSDL SOAP/HTTP synchronous binding for request
response operations the presence of the <wsaws:UsingAddressing> element in
the binding or endpoint (port) components of the endpoint description does
not change the binding semantics with respect to the requirement that
response message be sent over the same HTTP channel over which the request
was receive. This implies in particular that the wsa:replyTo header in the
request MUST NOT contain an address with a value different from the
anonymous IRI when the SOAP/HTTP binding is in use.

WSDL 1.1 example:

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
        <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"/>
           <input>
               <soap:body use="literal"/>
           </input>
           <output>
               <soap:body use="literal"/>
           </output>
        </operation>
</binding>

WSDL 2.0 example:

<binding name="reservationSOAPBinding"
          interface="tns:reservationInterface"
          type="http://www.w3.org/2004/08/wsdl/soap12"
          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>


----- Forwarded by Francisco Curbera/Watson/IBM on 04/18/2005 03:05 PM
-----
                                                                                                                                               
                      Francisco                                                                                                                
                      Curbera/Watson/IBM@IBMUS        To:       public-ws-addressing@w3.org                                                    
                      Sent by:                        cc:                                                                                      
                      public-ws-addressing-req        Subject:  Action item for issue i021                                                     
                      uest@w3.org                                                                                                              
                                                                                                                                               
                                                                                                                                               
                      03/28/2005 02:43 PM                                                                                                      
                                                                                                                                               





The following is a minimal proposal for representing the use of WSA in a
WSDL service description. This fullfils an AI I took long ago, apologies
for the long delay.

The approach is as follows: introduce a marker to be used in both WSDL 1.1
and WSDL 2.0 bindings to indicate the fact that a service uses and requires
clients to use WSA message information headers in every service invocation.
I think it is generally accepted that this indication belongs in the WSDL
binding, since one could possibly want to deploy the same interface with
different protocols bindings in some of which WSA usage may not be common,
including pre-WSA "legacy" SOAP bindings.

A key issue about the semantics of this marker is that it assumes no change
on the behavior of the WSDL MEP and WSDL binding on which it is applied
EXCEPT for the fact that WSA MIHs will be present in accordance to the WSA
WSDL binding spec. That is, the WSA WSDL binding marker is simply
"additive" to existing semantics. The reasons for making this clear at this
time is that there are important behavioral implications of the presence of
WSA headers that may conflict with the semantics of a WSDL binding; the
interaction between the two is essentially in the scope of the asynch TF
discussions and its resolution should not be precluded by the introduction
of this marker. It is thus the case that when the marker proposed here is
present in a WSDL binding, all WSA implied behaviors that are inconsistent
with the semantics of the MEP/binding are explicitly not allowed (by the
service so described). The best example of this is the possible presence in
an HTTP request of a replyTo EPR with an address that is not the anonymous
URI. Assuming that the WSDL binding specifies a traditional HTTP
synchronous interaction, non-anonymous replyTo URIs are considered a
violation of the WSDL binding contract since this one mandates (as of
today) that the response be sent back over the open HTTP channel.

I propose the marker be defined in the WSAW namespace introduced by the
WSDL binding document.

<wsaw:UsingAddressing wsdl:required="true"/>

Some notes:

1. The wsdl:required=true is mandatory when the UsingAddressing element is
used.
2. The marker element may appear within any of the binding elements:
<wsdl:binding>, <wsdl:operation>, <wsdl:input>, <wsdl:output>, <wsdl:fault>
with semantics defined by the usual scoping rules.

WSDL 1.1 example:

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
        <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"/>
           <input>
               <soap:body use="literal"/>
           </input>
           <output>
               <soap:body use="literal"/>
           </output>
        </operation>
</binding>

WSDL 2.0 example:

<binding name="reservationSOAPBinding"
          interface="tns:reservationInterface"
          type="http://www.w3.org/2004/08/wsdl/soap12"
          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>


Paco

Received on Tuesday, 19 April 2005 14:44:45 UTC