Re: Action item - Part 2: SOAP request-response, response, request-optional-response ...

Noah,

On 1/18/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
> Mark Baker writes:
>
> > I don't agree.  A SOAP/HTTP (as an example) node need only know
> > the "MEP" insofar as it knows the semantics of HTTP and
> > therefore the semantics of "request", "response", and their
> > relationship on the wire.
>
> No, I don't think that's the whole story.  In the case that HTTP is used
> to implement a SOAP binding, and in particular to transmit entities of
> media type application/soap+xml, the SOAP specifications can further
> refine the expecations for use of HTTP.  For example, it's the SOAP
> specification that says to use a status code of 500 in the case of a
> mustUnderstand fault at the receiver.  The existence and general use of
> 500 is in the HTTP specification;  the fact that mU in particular is a
> source of such errors comes from the SOAP recommendation, and properly so.
>  Similarly, the SOAP spec, along with the header and body specifications
> to which it delegates, can determine what will be sent in responses with
> status code 200.  Again, this must be a specialization of the rules for
> HTTP, in the sense that it must properly use the mechanisms of HTTP.
>
> I think a SOAP intermediary can be expected to know the entire stack of
> pertinent specs, not just HTTP.  If it sees a SOAP request go out using
> HTTP, it can reasonably assume the SOAP semantics for any envelopes it
> sees flowing back with the response.  For example, it can have knowledge
> of the specific semantics of SOAP faults, and how they relate to the
> corresponding requests.

I agree with everything you wrote there.  It just all seems orthogonal
to the MEP.

To your last point, the way that the SOAP/HTTP intermediary you
describe knows how the semantics of a SOAP fault relates to a request,
is because the HTTP spec tells it so, at least insofar as the
intermediary is able to know *which* request the fault is for (which
is the MEPish bit, AFAICT).

But about your original (quoted by Rich) point, "Indeed, I'd say that
the intermediary is responsible for ensuring that the 2nd hop binding
can faithfully implment the MEP used by the first hop", that's not
even the case for application protocols, as the job of some (proxy)
intermediaries is precisely to mediate between differents "MEPs" (in
the generic sense of the word).  For example, years ago I built a
HTTP/SMTP proxy which accepted an inbound HTTP POST (e.g. "POST
mailto:distobj@acm.org HTTP/1.1"), and turned it into an outbound SMTP
message ("RCPT TO: distobj@acm.org ...").  It returned an HTTP 202
response to the client, because that's the closest response semantic
HTTP has to SMTP 250.  But the proxy, conceivably, could have been
written to block (the client) on the reception of an inbound SMTP
message to the SMTP-side of the proxy) such that the contents of that
SMTP message was returned in the HTTP response to the client.  Adding
SOAP to that scenario, with either the non-blocking/202 or
blocking/200 response, wouldn't change anything from a MEP POV,
AFAICT.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Thursday, 19 January 2006 20:50:28 UTC