Re: Action item for issue i021

Given that [destination] MIH is mandatory when using WSA, how does one 
look at WSDL and figure what the value of that property is? Other 
properties, specifically, [reply endpoint], [fault endpoint], [action], 
[message id], [relationship] and [source endpoint] are either set by the 
invoker of the service specified in WSDL or the WSDL specifically says 
what the value is (for example the [action] property can be specified by 
the WSDL). Similarly, [reference parameters] value is something that the 
invoker of the service does not know.
It seems to me that we have to provide a way for [destination] to be 
specified in WSDL and explore whether optinally allowing [reference 
parameter] specification in the service/port/endpoint elements.

More specific comments inlined.

-Anish
--

Francisco Curbera wrote:
> 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.
> 

[this was discussed a little bit during last week's concall, but I'm not 
sure if there was a conclusion on this]

It is also very useful to not modify existing bindings and include this 
marker in a wsdl11:port. This allows multiple (or even same) services to 
use the same interface/binding and provide different ports with or 
without WSA engaged.

> 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.

[this was discussed a little bit during last week's concall, but I'm not 
sure if there was a conclusion on this]

wsdl:required='true' is used to mark something as mandatory in WSDL. It 
is the WSDL creator that decides what, if anything, is mandatory for 
invoking the service(s). Therefore it seems like whether 
wsdl:required='true' or not should be left to the WSDL document/service 
creator. This has the advantage that I can create just one 
service/binding for clients that understand WSA and clients that don't, 
by including the wsaw:UsingAddressing marker with wsdl:required='false'.

> 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 Monday, 4 April 2005 18:33:17 UTC