- From: David Hull <dmh@tibco.com>
- Date: Wed, 21 Dec 2005 11:32:53 -0500
- To: noah_mendelsohn@us.ibm.com
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, xml-dist-app@w3.org
- Message-id: <43A983B5.8050508@tibco.com>
My issue here is that "response" is ambiguous. The current SOAP MEP language only talks explicitly (as I understand it), about a /SOAP/ request and a /SOAP/ response. Under the extension/clarification/erratum, we're now talking about recognizing a no-envelope response. If you just look at SOAP traffic (which makes most sense to me), then this is SOAP request and optional SOAP response. If you think of a response as something coming back, then this is SOAP request and a SOAP or no-envelope response. I'm much less comfortable with this. By that logic, "response only" is actually request-response as well: A non-envelope request (the GET) and a SOAP response. The "cheese sandwich with no bread" issue is slightly different. I don't like the idea of defining a generic "request optional-response" MEP and binding it to a one-way transport, where we know there will never be a response. 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. > >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 16:33:11 UTC