Re: Fw: multiple MEPs per binding

Anish Karamarkar writes:

> 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)?

Not sure.  I'm forgetting the HTTP rules on extra headers.  There may be 
no issue.
 
> >  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?

Well, we decided to do ROR not as a new MEP, but on the theory that the 
original req/res was ambiguous and that we would clarify it.  As far as I 
know, there is only one MEP, but with clarified requirements as to whether 
there need be an envelope, and a clarified HTTP binding that more 
carefully explains the use of status code 202.  Right?  I'm told lots of 
implementations already take that interpretation, particularly if they are 
WSA-aware.

> 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.

I don't think we need to go there right now.  As I said above, I think all 
we've done is (somewhat post facto) clarified our intentions regarding the 
original SOAP 1.2 Request/Response.  My interpretation is that the term 
ROR is just one we're using among ourselves to refer to the clarified 
semantics.

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

Received on Friday, 14 April 2006 03:21:09 UTC