- From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- Date: Wed, 5 Feb 2003 16:42:23 -0800
- To: <noah_mendelsohn@us.ibm.com>
- Cc: <xml-dist-app@w3.org>
> -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: Wednesday, February 05, 2003 2:27 PM > To: Jeffrey Schlimmer > Cc: xml-dist-app@w3.org > Subject: RE: What is a SOAP Message > > Jeffrey Schlimmer asks: > > >> What is the processing model for this definition of "message"? > > I don't have time to dig up all the references, but I think the SOAP > recommendation is reasonably clear. A node receiving the message must > reconstruct the Envelope infoset and do the processing described in Part 1 > chapter 2, >> as augmented by any features <<. Agreed. "Features" annotate the Envelope Infoset, and the SOAP processing (e.g., mustUnderstand, role-based processing, intermediate behavior) applies to the Envelope Infoset. > I suspect that the crux of your question is: what about all that other > stuff like attachments? Should it be relayed by intermediaries, signed, > etc? Yes. And what subset of that stuff must be understood by the receiver? Which intermediate is it targeted at? > As far as the SOAP spec is concerned, all that stuff is extension > features. In the case of attachments, there should be features describing > their processing, and relating it if necessary to the SOAP processing > model. If attachment "features" annotate the Envelope Infoset, then the processing of those "features" can leverage the SOAP processing model and compose well with other "features". Great! If they do not, then someone needs to define how they address the same issues that the SOAP processing model does. Not to mention the engineering effort, introducing a new processing model raises the real risk that the new "feature" won't compose with independently-developed "features". > The whole point is that SOAP includes very little in the core, so > if you define extensions that go beyond what the SOAP processing model > covers, you should expect to have to write a specification that says what > to do. Agreed. Header (and body) blocks are terrific extensibility points that have the advantage that they use the existing SOAP processing model. > This is not new, IMO. Consider the WebMethod feature. It indicates that > there is information (I.e. GET/POST indication) that is carried outside of > the envelope. Agreed. Some bindings will carry information outside the XML 1.0 serialization. > Where do we specify what to do with that? The feature > indicates, at least informally, that these verbs describe the operation to > be performed by a receiving node. Agreed. How does the receiving SOAP node get access to this information? Is it included in the Envelope Infoset that the SOAP node processes? Or is it made available through some other, out-of-band means? > Like many features, it relies on a > protocol binding to give a concrete implementation of those semantics. In > the case of WebMethod, the HTTP binding does this by specifying the > on-the-wire representation (as the HTTP method) and the processing > semantics. Agreed. This is the mapping from the Envelope Infoset to a wire format, in this case, part XML 1.0 and part HTTP. Generally, it is easier to get the Envelope Infoset across hops that may be using different bindings if everything is within the XML 1.0 (wherever else it may be), but if this binding is focused on the last-hop case, then it probably doesn't matter. > As far as I can tell SOAP works fine, and is staying quite true to its > model of providing a relatively minimal but extensible framework in the > core. Agreed. > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------
Received on Wednesday, 5 February 2003 19:42:55 UTC