Re: Response envelope optional vs. response optional
David Hull <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
Mark Baker wrote: >Anish, > >On 12/21/05, Anish Karmarkar <[email protected]> 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. > > This seems open to interpretation. If you define "SOAP response" as "a SOAP envelope", then it's not immediately obvious how this is so. If you define SOAP response as "a SOAP envelope or something else", then this is clearly true, but it's not clear what value it adds. The distinction being made is between HTTP responses that contain SOAP envelopes and those that don't. Both are clearly possible on the wire. Whether that distinction is semantically relevant other than on the wire is a separate issue. I would prefer to talk about that issue rather than what a "SOAP response" is or isn't, though of course I realize that agreeing on a common definition of "SOAP response" ought to aid that discussion. > > >>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 > > >