Re: Issue 59 alternate proposal

I definitely intended for the HTTP specifics to be included, it just  
didn't seem worth duplicating that part of your proposal in my  
proposal. That's what I meant by:

> Most of the requirements and considerations detailed in the prior  
> proposal[2] still apply and for brevity I have not duplicated them  
> here.

I guess I could have been a little more explicit about that.

Marc.

On Nov 1, 2005, at 9:24 PM, Yalcinalp, Umit wrote:
>
> 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.
>>
>>
>>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.