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

Re: Fw: multiple MEPs per binding

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 05 Apr 2006 00:34:20 -0700
Message-ID: <443372FC.8060208@oracle.com>
To: noah_mendelsohn@us.ibm.com
CC: xml-dist-app@w3.org

noah_mendelsohn@us.ibm.com wrote:
> 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.)

Would this be any different than how HTTP proxies handle SOAPAction http 
header (in SOAP 1.1)?
	
>  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. 
> 

Right, SOAP-response MEP (uses GET) or a one-way MEP (won't be supported 
by our HTTP binding) is not a problem, but we have two MEPs req-res and 
ROR that use POST. How does a receiver figure out which MEP was intended 
by the sender?

> 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 Wednesday, 5 April 2006 07:35:07 UTC

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