- 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 UTC