W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

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

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>
Message-ID: <OF2A51C208.8DB38E25-ON852570FB.00019D49-852570FB.00023577@lotus.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT