Re: Response envelope optional vs. response optional

Anish:  thanks for your thoughtful reply.  I think this is very helpful in 
moving us forward:

Anish Karamarkar writes:

> This makes the name of the SOAP MEP a misnomer. As DavidH calls
> it: a cheese sandwich with no bread.  The request-response MEP 
> consists of a Request SOAP env and a Response SOAP env.  Either
> we have to rename the SOAP MEP or specify how the Response SOAP
> env may be delivered (using a different HTTP connection) when 
> the 202/204 status is used.

I mildly disagree.  As I mentioned in my earlier note, the crucial 
characteristic of this pattern is that there >is< a mandatory response. 
The client invariably waits for a response, and always gets one.  The only 
question is whether that response carries an envelope.  I think it's a 
meat and veggie sandwich in which the meat can be left out to suit the 
taste of vegetarians. 

Still, if we want to adopt the design and change the name to something 
else reasonable that would be OK I think. For the reason above, I don't 
think I'd want to call it Request/Optional-Response, though I might live 
with that too if pressed.

> Either we have to rename the SOAP MEP or specify how the 
> Response SOAP env may be delivered (using a different HTTP 
> connection) when the 202/204 status is used.

I would disagree very strongly with talking about the subsequent delivery 
of the SOAP Response in the cases where a 202/204 was returned.  My view 
is that, with this pattern, there is no obligation to do anything further 
at all after the 202/204, at least not at the SOAP level.  If some higher 
level pattern chooses to deliver other SOAP messages as a result of this 
interaction, so be it.  My intent was that this SOAP MEP also be usable in 
cases where a single SOAP envelope was to be sent over HTTP, a 202/204 
returned, and nothing further happens. 

I think it's very important that we not be tempted into mixing higher 
level messaging patterns into the SOAP MEPs.  The SOAP MEPs are a contract 
that helps to make bindings interchangeable, IMO.  If two bindings 
implement the same SOAP MEP(s), then the chances are good that you can 
switch from one to the other.  So, if a non-HTTP transport implemented the 
binding we're discussing, it too would be usable to deliver a message with 
a wsa:ReplyTo.  In neither case would we be discussing how the actual 
reply is to be delivered, as that is covered at a higher level by WSA.

So, I don't want to talk about the higher level response.  If that means 
renaming the binding then that's OK with me, but I'm not convinced it's 
necessary.  Doing so may or may not make it a bit harder to take this 
through the W3C process quickly.  In particular Req/Resp is a normative 
part of SOAP 1.2, so other specs and implementations may in principle 
refer to it by name.  If we change the name, then I think that's an 
incompatibility of a sort, albeit a minor one operationally.  My vote for 
now would be to keep the name.

Thanks!
Noah

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








Anish Karmarkar <Anish.Karmarkar@oracle.com>
12/20/05 05:45 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     xml-dist-app@w3.org
        Subject:        Re: Response envelope optional vs. response 
optional


noah_mendelsohn@us.ibm.com wrote:
> I think I'm coming close to a position on MEPs that I can personally 
> support, and perhaps that IBM will formally endorse.
> 
> In considering this discussion, it's slowly occurred to me that there is 
a 
> crucial difference between making the response envelope optional, and 
> making the whole response optional.   In the former case, you get an 
> explicit confirmation from server back to client that there will in fact 

> be no envelope.  In the case that the response as a whole is optional, 
or 
> in one way, the client never hears back "ok, we're done".   This 
> difference is important.  When you have a connection-oriented 
> request/response underlying protocol such as HTTP, it's essential that 
the 
> responding application at some explicit point in time either send a 
> response or otherwise terminate the connection;  in the case of HTTP in 
> particular we will likely do this by deciding to send a 202, though 
Chris 
> suggests that 204 may be useful at times.  With a true one way, you 
> wouldn't even know where to send that indication.
> 

+1

> With that background, here's the position that currently seems most 
> attractive to me:
> 
> * Modify the current request/response binding to state that the 
inclusion 
> of an envelope in the response is optional (but not that the response as 
a 
> whole is optional, in the sense discussed above.)
> 
> * Modify the HTTP binding to make clear which status codes (presumably 
202 
> and maybe 204) map to the "no envelope response".
> 


This makes the name of the SOAP MEP a misnomer. As DavidH calls it: a 
cheese sandwich with no bread.
The Request-response MEP consists of a Request SOAP env and a Response 
SOAP env.
Either we have to rename the SOAP MEP or specify how the Response SOAP 
env may be delivered (using a different HTTP connection) when the 
202/204 status is used.

> * We take the mention of 202 in the current HTTP binding and the 
> widespread implementation of it as evidence that the original 
> recommendation was contradictory.  Per W3C process, this allows us to 
> issue an erratum compatible with any legal reading, and we can 
reasonably 
> say that this proposal fits that model.  The likely result of this would 

> be to publish something like a SOAP 1.2 second edition.
> 
> That's it.  Maybe or maybe not we later add a true one way MEP, in which 
a 
> response is never allowed.  That's implementable over HTTP, but it's not 
a 
> good match to the case where a response may sometime be sent.  If 
there's 
> even a chance that a response will be sent, then you need to pick an 
> explicit time to say "no, I'm not sending one after all".
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
>

Received on Wednesday, 21 December 2005 14:21:46 UTC