W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

Re: Action Item

From: David Hull <dmh@tibco.com>
Date: Wed, 07 Dec 2005 00:49:37 -0500
To: "Rogers, Tony" <Tony.Rogers@ca.com>
Cc: "Cahill, Conor P" <conor.p.cahill@intel.com>, John Kemp <john.kemp@nokia.com>, "ext Yalcinalp, Umit" <umit.yalcinalp@sap.com>, public-ws-addressing@w3.org
Message-id: <439677F1.9080802@tibco.com>
Rogers, Tony wrote:

> I'd think that almost any async pattern would allow messages to be
> returned out-of-order, with the only exception being one where there
> cannot be more than one outstanding request (and I'd consider that
> "pseudo-synchronous").

Exactly.  "Potentially out of order" is a reasonable defining property
for "asynchronous", while "callback address", "duplex channel" and
"polling" (a duplex channel if you squint at it) are mechanisms for
supporting asynchronicity.

>  
> Tony Rogers
> tony.rogers@ca.com <blocked::mailto:tony.rogers@ca.com>
>  
>
> ------------------------------------------------------------------------
> *From:* public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
> *Sent:* Wednesday, 7 December 2005 7:22
> *To:* Cahill, Conor P
> *Cc:* John Kemp; ext Yalcinalp, Umit; public-ws-addressing@w3.org
> *Subject:* Re: Action Item
>
> Cahill, Conor P wrote:
>
>> 
>>
>>  
>>
>>>When submitting a message for potentially asynchronous 
>>>processing, it would seem that the response message must come 
>>>back on a different channel than that used to submit the request.
>>>    
>>>
>>
>>I'm not sure this is the case.  There are many situations where
>>the client and server can maintain a permanent connection pipeline
>>to asynchronously send messages back and forth where the server 
>>is not able to separately connect to the client (most instant
>>messaging services work this way).
>>
>>Conor
>>
>>
>>  
>>
> A polling protocol should probably provide for 0 .. * messages coming
> back on each poll (e.g., send request one, poll, no response, send
> request two, poll again, get both responses).  Given this, one might
> consider the combination of request messages flowing one way and poll
> responses flowing the other as a sort of virtual channel, split across
> multiple connections.
>
> It occurs to me that I'm bringing in yet another notion of
> asynchronicity here, namely that response messages may not arrive in
> the same order as their corresponding requests.  This is a more
> general definition, in that it can be realized by the "non-anonymous
> callback EPR" pattern, by the polling pattern and by something
> connection-oriented but duplex like an IM protocol.
>
Received on Wednesday, 7 December 2005 05:51:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT