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"). 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 01:41:30 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT