RE: Async req-res: addendum to marc's proposal

Anish, 

You are absolutely right. All the proposals have to do with "duplex" nature
of the channel i.e. full duplex vs. half duplex. The thing we are adding is
that our forward and reverse channels are distinct and that creates a need
for some kind of correlation across distinct channels.

It is not async as in asynchronous in time. For asynchronous we need some
kind of a buffered channel in which to store the request/response until the
receiver is back online or ready. 

Vikas


-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Anish Karmarkar
Sent: Sunday, November 06, 2005 8:18 PM
To: public-ws-addressing@w3.org 
Subject: Async req-res: addendum to marc's proposal


What we are talking about in the various proposals for issue i059 is 
about changing bindings for a req-res operation to allow:
1) the request and response to be sent out over different HTTP-connections
2) WSDL authors to specify bindings to req-res operations that allow the 
request and response to use different WSDL Binding(s).

None of this is about "async" from a client programmer POV. They are 
about bindings. Bindings specify how the message is serialized, and 
bound to the transport including whether different connections are used 
to send the request and response. For example, an SMTP binding will 
inherently using multiple connections. As another example, I'm free to 
write a single binding for a req-res operation which says the the 
request is sent over HTTP and the response over SMTP.

There is another requirement for 'async' which is at the abstract WSDL 
level. Programing models and client-side APIs are generated by tools 
using the portType/interface information. Having a 'async' marker in the 
portType/interface as a hint to the WSDL processor is quite important 
from a client POV -- since most tools generate client-side APIs from the 
abstract WSDL. Pl. note that such a marker is only a hint, which says 
that the response will very likely take a long time. This is not to say 
that async apis cannot be layered over sync transport or vice versa. 
This isn't about the binding/transport, it is about providing a hint to 
the WSDL processor. I.e., one can use an async portType level maker and 
use the default SOAP/HTTP binding that uses a single connection. On the 
flip side one is also not prevented from using an non-async req-res 
abstract operation from being bound to an async SMTP binding. Such a 
marker allows the WSDL processor, if it chooses to do so, to generate 
client-side APIs/programming model that takes into account that the 
request and response is separated potentially by a large time interval.

I would therefore like to propose an addendum to Marc's proposal [1] -- 
we allow an attribute called wsaw:Async of type xs:boolean (restricted 
to the value 'true') on the wsdl11:portType, 
wsdl11:portType/wsdl1:operation, wsdl20:interface, 
wsdl20:interface/wsdl20:operation element. The presence of this 
attribute is a hint to the WSDL processor that the response and request 
MAY be separated by a large time interval.

-Anish
--

[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0003.html

Received on Monday, 7 November 2005 05:49:39 UTC