Re: Response envelope optional vs. response optional

On Jan 4, 2006, at 1:47 AM, Anish Karmarkar wrote:
>
> I don't disagree that SOAP MEPs are contracts implemented by a SOAP  
> binding to a particular transport or transports and do not span  
> more than one binding or more than one instance of a binding.
>
> What I was pushing back on was allowing a 202 (with no entity body)  
> in HTTP, and still saying that it implements a SOAP req-res MEP  
> (since there is no SOAP response envelope coming back). It can be  
> called SOAP req-optional-response or a SOAP-request MEP, but  
> calling it a SOAP req-res MEP doesn't seem right.
>
> It seems to me that we should either:
> 1) create a new SOAP req-optional-res MEP and create a HTTP binding  
> that supports this (along with SOAP-response and SOAP req-res MEPs  
> for backward compatibility) OR
> 2) create a new SOAP one-way (or SOAP-Request MEP) and create a  
> HTTP binding that supports this (along with SOAP-response and SOAP  
> req-res MEPs)
> 3) get rid of SOAP MEPs (as suggested in option 5) and specify how  
> SOAP messages are carried in a transport OR
> 4) specify how a SOAP req-res can be bound to 2 HTTP connections  
> using 202 (this would not use more than one-binding as we would  
> specify this in a single binding, i.e., the MEP would not span more  
> than one binding) OR
> 5) create protocol-level MEPs as suggested by DaveO.
>
Thanks Anish, I share your reservations about 202 (with no entity  
body) not being SOAP Request/Response (as currently defined) and  
you've summed up the options going forward nicely.

One aspect I'd like to draw out is the separation between SOAP MEPs  
and the HTTP binding which sometimes seem to get a little mixed up in  
discussions. I think its quite reasonable for us to define a binding  
that can support more SOAP MEPs than are currently specified:  
relaxing the constraint on requiring a SOAP envelope in the HTTP  
response would do exactly that as it allows both one-way and optional  
response as well as supporting the existing request/response and  
response SOAP MEPs.

Marc.

> > * Higher level specifications, such as WSDL and/or WSA can
> > use the SOAP
> > level MEPs as building blocks to enable patterns that may be
> > correlated
> > across multiple bindings, or multiple invocations of the same  
> binding.
>
> Higher-level specs such as WSDL have not reused SOAP MEPs, instead  
> have defined WSDL MEPs which are different from SOAP MEPs. This is  
> one of the reasons why I don't think SOAP MEPs are that useful.
>
> > That's like saying that to order an airline ticket I'll first do a
> > round
> > trip to select a date, then another to provide my credit card.  We
> > don't
> > say that HTTP has some odd notion of double request response.  We  
> note
> > that the higher level pattern is built of repeated uses of HTTP's
> > simple
> > r/r pattern.
> >
> > * SOAP MEPs allow us to document that two or more bindings implement
> > similar contracts, and are thus likely to be usable in similar
> > situations,
> > sometimes even transparently to the application.
>
> Perhaps. But I can always use multiple instances of a binding or  
> multiple bindings to achieve the same result in say WSDL or higher  
> level descriptions/MEPs. Throw in WSA and/or WSRM and things change  
> a bit.
> For example, it is possible to support soap req-res MEP using SMTP,  
> but SMTP being a one-way transport won't support the 'anon' EPR  
> that HTTP can. Which means that it is not easy to swap HTTP with  
> SMTP and still use the 'anon' EPR (for say WSRM's acksTO). I.e.,  
> such a swap is not transparent to the application. Pl. note that I  
> have not looked at the Jabber binding to see how they use SOAP MEPs.
>
> -Anish
> --
>
> > WSDL and WSA MEPs do
> > the
> > same thing for patterns that involve multiple bindings or uses of
> > bindings.
>
>
> noah_mendelsohn@us.ibm.com wrote:
>> Anish:  I think you're not emphasizing as much as I am that a SOAP  
>> MEPs are contracts implemented by a SOAP binding to a transports  
>> nothing more.  They are not responsible for answering every  
>> question you might have about which SOAP envelopes are related to  
>> which other SOAP envelopes;  the answer that question only insofar  
>> as a particular transport binding cares.   By definition, a SOAP  
>> MEP never involves more than one binding or more than one use of a  
>> single binding.  An MEP is a feature of a binding.
>> Now, let's take an example where you send over HTTP a SOAP request  
>> with a wsa:ReplyTo.  We use my proposed MEP and get back a 202.   
>> In my terms, the MEP is done.  Note that the ReplyTo may cause a  
>> message to be sent over JMS, Jabber, or something completely  
>> unrelated to the HTTP binding for which we had an MEP.   So, that  
>> later reply will necessarily be using a different SOAP MEP, I.e.  
>> the one implemented by the SOAP transport used to for reply delivery.
>> My view is:
>> * A SOAP MEP is a contract with a particular transport binding.
>> * Higher level specifications, such as WSDL and/or WSA can use the  
>> SOAP level MEPs as building blocks to enable patterns that may be  
>> correlated across multiple bindings, or multiple invocations of  
>> the same binding. That's like saying that to order an airline  
>> ticket I'll first do a round trip to select a date, then another  
>> to provide my credit card.  We don't say that HTTP has some odd  
>> notion of double request response.  We note that the higher level  
>> pattern is built of repeated uses of HTTP's simple r/r pattern.
>> * SOAP MEPs allow us to document that two or more bindings  
>> implement similar contracts, and are thus likely to be usable in  
>> similar situations, sometimes even transparently to the  
>> application.  WSDL and WSA MEPs do the same thing for patterns  
>> that involve multiple bindings or uses of bindings.
>> Noah
>> --------------------------------------
>> Noah Mendelsohn IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>> Mark Baker <distobj@acm.org>
>> Sent by: xml-dist-app-request@w3.org
>> 12/21/2005 01:13 PM
>>          To:     Anish Karmarkar <Anish.Karmarkar@oracle.com>
>>         cc:     xml-dist-app@w3.org, (bcc: Noah Mendelsohn/ 
>> Cambridge/IBM)
>>         Subject:        Re: Response envelope optional vs.  
>> response optional
>> Anish,
>> On 12/21/05, Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote:
>>> My understanding about SOAP MEP is that: it talks about SOAP  
>>> messages. A
>>> SOAP req-res MEP consists of one SOAP req and one SOAP res. In  
>>> the case
>>> of 202/204, there is no SOAP response although there is HTTP  
>>> response.
>> An HTTP response is a SOAP response.
>>> Hence my discomfort about the name (SOAP req-res MEP with no SOAP  
>>> res).
>>> Alternately, specifying how the SOAP response is sent over a  
>>> different
>>> HTTP connection is not going into higher-level messaging pattern. It
>>> would be merely specifying how the response part of the req-res  
>>> SOAP MEP
>>> is sent (I'm not sure if this is the best way to go, but I don't  
>>> think
>>> it is going into higher-level MEPs).
>> I'd suggest that any other "response" would be handled as part of a
>> separate message exchange.
>> Mark.
>> --
>> Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
>> Coactus; Web-inspired integration strategies  http://www.coactus.com
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.