Re: Response envelope optional vs. response optional

+1.  I think I agree with David's summary and his conclusion.  As to what 
to name the MEP:  I'm somewhat convinced on the merits that the best name 
would have been "Request/Optional-Resonse".  That said, I don't currently 
think we want both Req/Resp and Req/OptResp.   We already have an MEP 
named Req/Resp and other specs can refer to it normatively.  What they get 
works in practice (I.e. in released implementations) pretty close to what 
we're now discussing as Req/OptResp.  Taking all that together, I'm still 
tempted to stick with the Req/Resp name, though I understand Anish's 
hesitancy.

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








David Hull <dmh@tibco.com>
01/04/2006 11:34 AM
 
        To:     Marc Hadley <Marc.Hadley@Sun.COM>
        cc:     Anish Karmarkar <Anish.Karmarkar@oracle.com>, 
noah_mendelsohn@us.ibm.com, Mark Baker <distobj@acm.org>, 
xml-dist-app@w3.org
        Subject:        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.

Received on Wednesday, 4 January 2006 16:49:44 UTC