RE: What is a SOAP Message

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