- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 18 Jan 2006 19:24:06 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: mbaker@gmail.com, Rich Salz <rsalz@datapower.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
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.
In other respects, I agree with your response to Rich. Thanks.
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Mark Baker <distobj@acm.org>
Sent by: mbaker@gmail.com
01/18/2006 06:58 PM
To: Rich Salz <rsalz@datapower.com>
cc: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>,
"xml-dist-app@w3.org" <xml-dist-app@w3.org>
Subject: Re: Action item - Part 2: SOAP request-response,
response, request-optional-response ...
On 1/18/06, Rich Salz <rsalz@datapower.com> wrote:
>
> > 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.
>
> I'm inclined to agree with this, I just don't know how the intermediary
> knows the MEP. Short of making SOAP (or at least non-default MEPs)
depend
> on WSDL, then the messages themselves must be tagged, right?
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.
I think we sometimes forget that MEPs are simply tools to aid in the
construction of bindings. Insofar as they've been used successfully
to define bindings, they're useful. But they are not part of the
contract between nodes, nor should they be IMO, because any attempt to
make them so would certainly trump the semantics of any underlying
application protocol.
I believe the message should be king.
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 00:24:30 UTC