- 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