Re: Action item for issue i021

So, subsequest to our discussion on the call today, I can understand how 
the wsaw namespace URI itself can (implicitly) serve to identify the 
core spec. But this IMO assumes that the Core WS-Addressing 
specification and WSDL binding specification are versioned in lock-step 
and the core sepc URI in that spec is updated. Specifically the point #2 
below.  Can the WSDL binding, core and other binding specifications 
version independently in future? Or do we expect issue a new revision of 
WS-A WSDL binding specification (that simply updates the corespec 
reference (namespace)) even when there are no changes otherwise to the 
WSDL binding spec?   That seems like a dependency that can be violated 
easily...

------- Original Message --------
Subject: 	Re: Action item for issue i021
Resent-Date: 	Mon, 04 Apr 2005 19:49:32 +0000
Resent-From: 	public-ws-addressing@w3.org
Date: 	Mon, 04 Apr 2005 12:46:48 -0700
From: 	Prasad Yendluri <pyendluri@webmethods.com>
To: 	Francisco Curbera <curbera@us.ibm.com>
CC: 	public-ws-addressing@w3.org


Hi,

I am trying to understand the impact of (future) versioning of 
WS-Addressing specification itself on the solution proposed by this 
proposal.
It is quite likely that we will need to deal with different versions of 
WS-Addressing as we are with WSDL (1.1 vs 2.0) at this point, so I would 
like that aspect to be addressed now.

Given the WSAW namespace is defined in the WS-Addressing WSDL binding 
specification, I see two levels of versioning:

1.  Versioning of the WS-Addressing specification (as a whole)
2.  Versioning of WS-Addressing WSDL binding specification alone, 
independent of the core (and vice versa).

Now how does one specify which version of WSAddressing specification one 
is using?

I mean the addition of the 
<wsaw:UsingAddressing wsdl:required="true"/>
property on the binding extension / component does not give one enough 
information on the specific version of WS-Addressing. Also I am not sure 
how robust the use of wsaw namespace would be when the WSDL binding, 
core and other binding specifications version independently in future. 
Or do we not expect the latter to happen at all?

Prasad

-------- Original Message --------
Subject: 	Action item for issue i021
Resent-Date: 	Mon, 28 Mar 2005 19:44:29 +0000
Resent-From: 	public-ws-addressing@w3.org
Date: 	Mon, 28 Mar 2005 14:43:40 -0500
From: 	Francisco Curbera <curbera@us.ibm.com>
To: 	public-ws-addressing@w3.org


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