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

Re: multiple MEPs per binding

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 29 Mar 2006 09:43:04 -0500
To: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Cc: Christopher B Ferris <chrisfer@us.ibm.com>, Mark Baker <distobj@acm.org>, xml-dist-app@w3.org
Message-ID: <OFBA1F631F.F5508121-ON85257140.0050D515-85257140.0050D95F@lotus.com>

Looks like we agree on all points.  Thanks.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
03/29/2006 02:43 AM
        To:     noah_mendelsohn@us.ibm.com
        cc:     Mark Baker <distobj@acm.org>, Christopher B Ferris 
<chrisfer@us.ibm.com>, xml-dist-app@w3.org
        Subject:        Re: multiple MEPs per binding

Noah, no disagreement, I concur with your long-time expressed position 
that we should keep SOAP independent from mechanisms like WSDL. I too 
have handcrafted SOAP messages without looking at WSDL files. I think we 
should not neglect, though, that there are cool mechanisms out there 
that allow you to make a simple SOAP call by just pointing at a mere 
WSDL file. It's a powerful mechanism in practice, one which I do hope 
WSDL 2.0 brings out (soon!) to SOAP 1.2.

But architecturally, I agree, let's keep SOAP independent.

My apologies for the rather long delay in responding to this thread. I'm 
now only lurking out here here and there.


noah_mendelsohn@us.ibm.com wrote:
> Mark Baker writes:
>> On 3/7/06, Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr> 
>>> Noah Mendelsohn wrote:
>>>> * Always, or almost always, if a binding supports more than
>> one MEP, then the one in use will have to be discoverable from 
>> information in the non-envelope part of the transmission.
>>> .. or out-of-band!
>> Eek!  I hope not.  8-O That would mean that two byte-for-byte
>> identical messages might have different meaning dependent upon what
>> service receives it.  Amoungst other things, that would rule out many
>> asynchronous cases where, if the WSDL changes between the time the
>> message is sent and received, then communication becomes ambiguous.
>> If it's important to the meaning of the message, it should be in the
>> message IMO.
> I strongly agree with Mark on this.   It's very important on the Web and 

> in other flexible networks that individual messages be reasonably 
> self-describing.  IMO, the role of WSDL is to give advance information 
> a way of documenting contracts in advance >for those who wish to have 
> advance knowledge<.  In general, it is undesirable to rely on such out 
> band information in determining what the protocol is.   Some judgement 
> required in all this, but as  general rules of thumb I have tried to 
> follow over the years:
> * WSDL should not be required to use SOAP properly, or to successfully 
> implement a given use of SOAP.
> * Even if one end of the connection benefits from having WSDL for 
> its code, the other end should not necessarily require it.  For example, 

> you can easily imagine a large scale enterprise that offers services to 
> wide range of communicating partners.  The large enterprise uses WSDL to 

> define its interfaces, and to help generate its code.  It offers the 
> for those partners who wish to use it in preparing their code.  On the 
> other hand, if some PERL or PHP programmer wants to just get the SOAP 
> message, look at it, and respond to it, they should be able to just read 

> the SOAP and HTTP specs, and follow their noses from their.  I.e.  HTTP 
> well tell you things like the WebMethod and the media type 
> application/soap+xml, which will determine that SOAP is in use and which 

> SOAP MEP to use.  Once you know that, you know to use the SOAP 
> model on the message, and therefore that you need to understand the 
> of the header, the contents of the body, etc.  No WSDL required.
> Noah
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
Received on Wednesday, 29 March 2006 14:43:18 UTC

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