Re: Response envelope optional vs. response optional

noah_mendelsohn@us.ibm.com wrote:
> 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. 
> 

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

> 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 17:02:45 UTC