RE: Issue 59 alternate proposal

Marc, 

I have one clarifying question since I need to read this again more
carefully.  

Our proposal specifically defined how the request-response would use two
distinct HTTP connections, 202, etc.  I think this is crucial to specify
somewhere as this behaviour is probably the only concrete agreement that
we got as a result of the Async TF and the interaction diagrams are now
part of the test suite documents, etc. 

I did not see in your proposal where this behaviour would be specified
since your target is to specify the Async mechanism in a protocol
independent way. I definitely want to see the protocol specific
behaviour that we can standardize and agree on. In my opinion, leaving
it as part of the test suite but not putting it in the spec would be a
grave mistake. 

I am wondering whether you are suggesting that we should leave this
completely out of scope or integrate it part of the specification, as we
have done it in our proposal, define the semantics for SOAP 1.x/HTTP
(covering the wire requirements for ii, and iii in particular). Since
your proposal did not specify the sections in the WSDL binding it would
change, I could not assess this whether this is intentional or not or
whether you were intending to add SOAP 1.x/HTTP specific behaviour to
clarify how Async element would specificly work in the context of SOAP
1.x/HTTP binding.  

As I have said many times before, I am not opposing extensibility, but I
would have a very big problem with losing the definition for the wire
level requirement. 

Thanks. 

--umit

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Marc Hadley
> Sent: Tuesday, Nov 01, 2005 2:46 PM
> To: public-ws-addressing@w3.org
> Subject: Issue 59 alternate proposal
> 
> In fulfillment of my action item from this weeks telcon, below is an  
> alternate proposal for issue 59 that is not SOAP/HTTP specific and  
> supports alternate bindings for async responses. Most of the  
> requirements and considerations detailed in the prior proposal[2]  
> still apply and for brevity I have not duplicated them here.
> 
> Marc.
> 
> [1] http://www.w3.org/2002/ws/addr/wd-issues/#i059
> [2] http://www.w3.org/mid/ 
> 2BA6015847F82645A9BB31C7F9D6416556A801@uspale20.pal.sap.corp
> 
> ---8<---
> 
> The wsaw:UsingAddressing element is extended with a boolean 
> attribute  
> called "asyncOnly". When false, the endpoint can support either  
> synchronous or asynchronous usage; when true the endpoint can only  
> support asynchronous use. The default value of asyncOnly is false.  
> Asynchronous capabilities are declared using a new wsaw:Async 
> element  
> as described below.
> 
> A new element, wsaw:Async, is used to declare asynchronous  
> capabilities. The element is empty with a single optional attribute  
> called 'binding'. The binding attribute is of type xs:QName and is  
> used to refer to a WSDL binding of the same interface/port type to a  
> protocol. Omission of the  attribute is equivalent to its inclusion  
> with a value that refers to the same binding for which the  
> asynchronous capabilities are being declared.
> 
> Some examples (for ease of comparison, I only include examples that  
> show UsingAddressing in a WSDL 2.0 binding but the intent is that  
> this could also be used in an endpoint, operation or the WSDL 1.1  
> equivalents):
> 
> (i) A sync-only binding
> 
> <binding name="reservationSOAPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/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>
> 
> (ii) A sync/async binding where the operation responses can 
> either be  
> sent over the HTTP response or using a separate HTTP request
> 
> <binding name="reservationSOAPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/08/wsdl/soap12"
>      wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>    <wsaw:UsingAddressing wsdl:required="true">
>      <wsaw:Async/>
>    </wsaw:UsingAddressing>
>    <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>
> 
> (iii) An async-only binding where the operation response is always  
> sent over a separate HTTP connection
> 
> <binding name="reservationSOAPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/08/wsdl/soap12"
>      wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>    <wsaw:UsingAddressing asyncOnly="true" wsdl:required="true">
>      <wsaw:Async/>
>    </wsaw:UsingAddressing>
>    <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>
> 
> (vi) An async-only SOAP/HTTP binding where the operation responses  
> are sent in an email. I made up the http://www.w3.org/2003/05/soap/ 
> bindings/SMTP protocol identifier as an example.
> 
> <binding name="reservationSOAPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/08/wsdl/soap12"
>      wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>    <wsaw:UsingAddressing asyncOnly="true" wsdl:required="true">
>      <wsaw:Async binding="tns:reservationSOAPSMTPBinding"/>
>    </wsaw:UsingAddressing>
>    <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="reservationSOAPSMTPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/08/wsdl/soap12"
>      wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/SMTP">
>    <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>
> 
> (v) A sync/async SOAP/HTTP binding where the operation responses can  
> either be sent over the HTTP response, using a separate HTTP 
> request,  
> or in an email. I made up the 
> http://www.w3.org/2003/05/soap/bindings/ 
> SMTP protocol identifier as an example.
> 
> <binding name="reservationSOAPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/08/wsdl/soap12"
>      wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
>    <wsaw:UsingAddressing wsdl:required="true">
>      <wsaw:Async/>
>      <wsaw:Async binding="tns:reservationSOAPSMTPBinding"/>
>    </wsaw:UsingAddressing>
>    <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="reservationSOAPSMTPBinding"
>      interface="tns:reservationInterface"
>      type="http://www.w3.org/2005/08/wsdl/soap12"
>      wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/SMTP">
>    <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>
> 
> The above covers declaration of asynchronous support at the endpoint  
> or binding granularity. It may also be desirable to support such  
> declaration at the operation level though I'm not convinced that it  
> makes sense to extend such granularity to the UsingAddressing 
> element  
> itself. To declare async support at the operation level I'd propose  
> to allow the UsingAddressing element to be used at the WSDL 
> operation  
> level with the following semantics:
> 
> (a) The value of the UsingAddressing/@asyncOnly specified at the  
> binding or port level is overidden by the value of the  
> UsingAddressing/@asyncOnly specified at the operation level
> (b) The child wsaw:Async elements of the UsingAddressing 
> specified at  
> the operation level are added to the child wsaw:Async 
> elements of the  
> UsingAddressing specified at the binding or port level.
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
> 
>

Received on Wednesday, 2 November 2005 02:23:17 UTC