- From: Mark Baker <distobj@acm.org>
- Date: Tue, 6 Dec 2005 19:00:31 -0500
- To: "paul.downey@bt.com" <paul.downey@bt.com>
- Cc: john.kemp@nokia.com, dmh@tibco.com, conor.p.cahill@intel.com, umit.yalcinalp@sap.com, public-ws-addressing@w3.org
On 12/6/05, paul.downey@bt.com <paul.downey@bt.com> wrote: > > > > > 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). > > John, can you please point to the SOAP HTTP protocol binding that works this > way, or maybe write it in terms of which HTTP methods are used, and > responses sent back, John's presumably referring to the Liberty PAOS stuff; http://www.projectliberty.org/specs/liberty-paos-v1.1.pdf > I'm having real difficulty in understanding this in > terms of RFC 2616. You're not supposed to. 8-) Unlike the SOAP 1.2 default binding, it disrespects HTTP's application semantics, despite claims to the contrary; "This binding of SOAP to HTTP is intended to make appropriate use of HTTP as an application protocol" If they'd just followed SMTP's lead with TURN/ETRN, or even just used HTTP CONNECT, all would be well. Alas. Mark.
Received on Wednesday, 7 December 2005 00:00:37 UTC