RE: Issue 130: Asynch request/response HTTP binding needed

whilst i agree that the term 'async' is overloaded, and there is 
no such thing as "an async MEP", there are MEPs which will be
implemented on transports which don't group messages into a single
conversation.

So by ignoring processing models and concentrating on the routing 
and grouping of messages exchanged, i still think we have a fairly 
tractable problem:

   1) we need a mechanism to identify the "addressing" mechanism
      in place - (we have extensions/F&Ps)

   2) we need a means of grouping operations into a high-level
      MEP - (we have DaveO's and Sanjiva's proposals to work with).

i was encouraged by yesterday's call coming away with the 
possibility of WSDL 2.0 saying *something* about our use-cases
but wonder if either proposal will satisfy Jonathan's common
use-case:

   a high-level MEP uses one or more bindings: 
   e.g. i buy a book over one operation using SOAP/HTTP, 
   response returns as a callback to a second operation
   using SOAP/SMTP. 

Paul



-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Jeff Mischkinsky
Sent: 25 June 2004 05:30
To: Sanjiva Weerawarana; Tom Jordahl; 'Jonathan Marsh'; 'Web Services
Description'
Subject: Re: Issue 130: Asynch request/response HTTP binding needed



At 06:30 PM 6/23/2004, Sanjiva Weerawarana wrote:

>Same here; there is nothing called an "asynch" pattern IMO.

I tend to agree and don't believe we should even be defining one. I've seen 
this discussion, what about billion times or so, in every forum which sets 
out discuss distributed application processing.

In my book, the discussion never seems to end because it winds up 
conflating different concepts/issues. Asynch is a programming language 
issue. Has to do with whether your thread blocks or not when the action 
that initiates the pattern is made, usually the initial request. A separate 
issue is whether a response/ack comes back on the same "channel" or not, to 
the same thread, process, node, whatever. A separate issue is whether the 
receiver and the sender have to be "connected".

Pick every combination and someone has implemented it. And I suspect all 
the different combinations have been called asynch.

One has to have a very carefully defined layered model, with well defined 
abstraction layers, and not confuse the layers in order to sort this out.

I suspect DaveO is wanting to support disconnected sender/receiver and 
allow for the response to a request to come back somewhere else. Even then 
you have to decide if the request is delivered via callback (which some 
call events), or whether some entity is responsible for polling to get it. 
Blocking is somewhat independent.

cheers,
   jeff

Received on Friday, 25 June 2004 07:29:39 UTC