- From: John Kemp <john.kemp@nokia.com>
- Date: Tue, 06 Dec 2005 15:42:22 -0500
- To: ext David Hull <dmh@tibco.com>
- CC: "Cahill, Conor P" <conor.p.cahill@intel.com>, "ext Yalcinalp, Umit" <umit.yalcinalp@sap.com>, public-ws-addressing@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ext David Hull wrote: > 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. And request messages might flow in both directions... > > 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. Right. There's also the reverse HTTP case, where a SOAP request message is sent in the HTTP response, and a SOAP response is then sent in response to that SOAP request on a new HTTP channel, causing a response to the initial SOAP request to be sent over the new HTTP response channel. It's not clear to me that this is exactly polling behaviour. It does, however, involve an asynchronous response to the initial message (according to the WS-A definition of asynchronous). - - JohnK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlfeumNJiOOM57NMRAkesAJ425dGs9v6NYiq12MQo+k1s7BvB6QCcCA4J CmLXC2yPqTwVgX3eagJlIk4= =2Zi7 -----END PGP SIGNATURE-----
Received on Tuesday, 6 December 2005 20:43:24 UTC