Re: Response envelope optional vs. response optional

Noah,

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.

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

Received on Wednesday, 4 January 2006 06:47:31 UTC