W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: Binding example discussion

From: christopher ferris <chris.ferris@east.sun.com>
Date: Wed, 18 Jul 2001 14:25:22 -0400
Message-ID: <3B55D492.6B0F3566@east.Sun.COM>
To: Mark Baker <distobj@acm.org>
CC: Marc Hadley <marc.hadley@Sun.COM>, Mark Nottingham <mnot@akamai.com>, XML Distributed Applications List <xml-dist-app@w3.org>

Please see below.



Mark Baker wrote:
> 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?

That would suit me, but I don't think that's what Mark N was saying. The
use of the term "may" in Mark N's description of correlation is quite
incompatible with your "must".

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

I'm sure you meant 202 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

I'm not so certain that the correlation has been broken. If a 202 Accepted carried
a SOAP envelope within the entity body of the response, it should be correlated
with the request. It just isn't the ultimate response because Accepted means that
the request message hasn't been processed by the application, just accepted by the server.

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

Agreed. However, in the case of SOAP-RPC, or more precisely, the request/response
MEP, the binding specification would need to say something to the effect that 
a 202 Accepted status code MUST NOT be returned. 

I could conceive of use of the 202 Accepted status response for one-way message
exchanges, to infer that the message has been received, but not processed and
a 204 No Content status response as meaning received AND processed.

> >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 14:25:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC