- From: Mark Baker <distobj@acm.org>
- Date: Wed, 18 Jul 2001 13:52:12 -0400
- To: Marc Hadley <marc.hadley@sun.com>, Mark Nottingham <mnot@akamai.com>
- CC: XML Distributed Applications List <xml-dist-app@w3.org>
Hi Marc, 7/18/2001 7:22:20 AM, Marc Hadley <marc.hadley@sun.com> wrote: >Mark Nottingham wrote: >> >> There has been some discussion amongst the binding TF regarding >> example bindings, to help us discover requirements for defining a >> binding. As part of this, I generated a candiate for a HTTP binding >> definition. >> >The candidate HTTP binding contains the following text: > >"correlation - HTTP provides implicit corellation between its request >and response messages; SOAP applications may choose to infer corellation >between the SOAP envelope transfered by the HTTP request and the SOAP >envelope returned with the associated HTTP response." > >I'm not sure that this is really rigorous enough to allow interop. What >if the SOAP receiver (HTTP server) decides not to infer correlation and >the SOAP sender (HTTP client) decides to infer correlation. If we say that both ends must infer correlation (which I think is what Mark's saying), then that's ok, right? > Unless we >have a means to allow the client and server to agree on on whether the >response is correlated to the request then we have to specify it one way >or the other - no ? I believe that correlation of request with response is one of the "features" that you get when you use HTTP. I don't believe a SOAP/HTTP binding should do anything to change that. There is one issue on this topic that may require some work on our part though; supporting an HTTP 203 (Accepted) response code. Should a SOAP message be POSTed over HTTP and the server responds with a 203, the correlation between request and response has now been broken. Do we want/need to say anything about how an application can determine correlation when the response is returned through some other means? At a minimum I think we should say that other mechanisms can be used on top of SOAP (say, a transaction header block), but that the HTTP binding does not define such a mechanism. >This comes back to the need in a binding for an unambiguous >specification of connection/channel/endpoint usage/management that I >called for in the recent binding TF con call. Requiring request/response correlation over HTTP would simplify this dramatically. MB
Received on Wednesday, 18 July 2001 13:52:13 UTC