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

Fw: multiple MEPs per binding

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 4 Apr 2006 16:50:49 -0400
To: xml-dist-app@w3.org
Message-ID: <OF38488949.567F82AC-ON85257146.005EF866-85257146.007284B4@lotus.com>

Anish originally sent his message privately, and then copied the list.  I 
compounded the mistake by first replying to his private copy.   Here's my 
response to him.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------




----- Forwarded by Noah Mendelsohn/Cambridge/IBM on 04/04/2006 01:17 PM 
-----


Noah Mendelsohn
04/04/2006 10:19 AM

        To:     Anish Karmarkar <Anish.Karmarkar@oracle.com>
        cc: 
        Subject:        Re: multiple MEPs per binding


Anish Karamarar writes:

> the compatibility/interop issues can be handled by requiring that 
> only the new MEPs (ROR/FAF) include the HTTP header (the older MEPs 
> may include it as well, but will not be required to).

Indeed, though it seems like one more level of complexity, and perhaps one 

more reason that existing HTTP implementations might not interact well 
with SOAP.  For example, I don't remember offhand what typical HTTP 
proxies will do with headers such as this (I'm flying at the moment and 
don't have the RFC handy.)  So, I'm a bit reluctant to introduce this 
complexity without a compelling reason, but maybe there is one.  For now 
it looks to me like we have 3 potential MEPs to be widely deployed, I.e. 
the two that are in SOAP 1.2 and already supported by the HTTP binding, 
and the one-way.  The former are already well distinguished by GET/POST, 
and as you know I still think it would be a misuse of HTTP to support a 
one way, unless the binding required a non-envelope response under the 
covers anyway. 

The strange thing is that with request/optional response, you could layer 
what appears to be a one-way on top of it.  In other words, have the 
binding itself know about req/opt-resp, and on top of that build a 
convention that says "in this mode, there is never an envelope in the 
response, and indeed the application API will never show you the response. 

 The only artifact of the response is that under the covers we'll wait for 

it before closing the socket.  I'm a bit nervous about having MEP's built 
out of other MEPs, but I think it would work in principle.  You basically 
have an MEP (one way with under the covers acknowledgement) that can be 
bound to any binding that supports request/opt-resp.   Not sure what's 
best here.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Tuesday, 4 April 2006 20:51:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC