Re: Response envelope optional vs. response optional

I don't completely agree that this outlines the possibilities going
forward.  There are (at least) three sorts of transports to consider:

   1. Ones that act like HTTP, in which I would include ... HTTP
   2. Ones that act like UDP, in which I would include UDP and most
      pub/sub protocols, and maybe IM protocols and email.  These can be
      further differentiated by how much WSA-like functionality they
      include natively (e.g., email has WSA built in, except for Action)
   3. Ones that act like TCP, in that they are reliable and duplex, but
      not inherently synchronous.  This would include TCP itself and
      maybe BEEP.

This might not be the right analysis, but it's clear to me that HTTP is
not the only game in town, and to some extent it's one-of-a-kind.

We want to try to capture as much of the properties of these transports
as is useful.  IMHO, this entails /at least two /SOAP MEPs:

   1. request-optional response, which is essentially what we've been
      discussing.  In this MEP, the sender sends a SOAP message and one
      of the following outcomes happens:
         1. A SOAP message comes back
         2. A SOAP fault comes back
         3. A failure occurs
         4. Nothing SOAPy comes back, but the MEP completes successfully
            -- this is the new part, and the reason for suggesting the
            change to "optional response"
   2. fire-and-forget, in which the sender sends a SOAP message, the
      receiver may or may not receive it, and the sender has no idea
      what happened at the receiving end, but either side /may/ become
      aware of a failure.  As I've pointed out elsewhere (and which
      should come as no surprise), the first MEP can be defined in terms
      of this second.

We can declare a partial victory by defining (1), but in my opinion,
cannot declare total victory, in particular cannot claim to fully
support asynchronous messaging as required by WSA, without also taking
on (2).

Marc Hadley wrote:

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