RE: An analysis of mustUnderstand and related issues

Thanks for putting this together - it contains many good things. Here
are some comments:

Noah: "SOAP does refer to a message path, which appears to be post facto
the ordered locations and processing (there is vagueness here) that
actually were visited in processing the message.  There is at least an
attempt to associate special behavior with the "end" of the path, where
headers with no actor are processed.  The details of all this need to be
stated more precisely."

What SOAP really defines is a distributed processing model - it doesn't
define a message path because it doesn't say where to send messages. In
retrospect, it would have been better to use a term like processing
model rather than message path model.

Noah: "SOAP very clearly indicates situations in which a fault must be
generated, but only sometimes is it clear whether and how and to whom to
deliver the fault. Some of that looseness is intentional, but more
clarity is needed in the explanation.  I take a crack at this below.
Furthermore, as we begin to apply headers to richer functions which may
themselves fail, we need to be sure that fault handling is suitable and
carefully documented."

The division between what a SOAP fault is and where SOAP fault messages
are delivered is between the core SOAP protocol and any protocol binding
or module defining message exchange patterns. As I have hinted at
before, I see the RPC convention as primarily a protocol binding
(possibly with modules compensating for lacking features in the
underlying protocol). 

It is only in the case of the HTTP binding and the RPC convention that
SOAP talks about what to do with faults: return them in some manner to
the initial sender. The reason is that SOAP fundamentally is a one-way
message which doesn't allow us to say much more about fault messages.
However, when using a particular protocol binding we may get a message
exchange pattern that lends itself towards saying what to do with a SOAP
fault.

Noah: "The proposal has been made that the existing mustUnderstand
facility in SOAP is indeed a building block which allows us to layer
support for ordered delivery, and for checking the order of processing,
as a separate module on top of the core XML protocol.  On the other
hand, mustUnderstand applies to new headers, but not to enhancements
modeled as attributes on existing headers.  The question of whether we
can do the new facilities as a clean module therefore boils down, in
part, to the question of whether the new facilities can be effectively
and conveniently modeled as new headers in the message is exchanged by
applications."

I think there are two questions here: Whether mandatory extensibility
(or evolvability as I call it) is needed at all and if so then how to
encode it. The former I think definitely is the case (see also [2]) and
it has to be introduced from day one - it can't be retrofitted.

With respect to SOAP and in particular given the section 5 SOAP
encoding, SOAP takes the approach on attributes that they are for
"bean-counting". However, it is indeed possible to use attributes for
specific purposes. The SOAP Dsig spec [1] uses attributes in a
"manifest" style. One can imagine doing a caching module in the same
manner although this doesn't mean that it works for all features in
general.

Noah: "Although the SOAP specification says [1]: ": A body entry is
semantically equivalent to a header entry intended for the default actor
and with a SOAP mustUnderstand attribute with a value of "1".""

From a processing point of view, the text is correct - a body entry is
not processed by the SOAP processor any differently than a header entry
with default actor and mustUnderstand. However, I agree that there are
many cases where there is a difference in how the body entries might be
used compared to header entries.

This is I believe not in contradiction with what you say but I think we
have to be careful separating the basic SOAP processing model from
conventions on how to use SOAP. 

Noah: "Although SOAP messages are fundamentally one-way, the HTTP
binding serves as an example of the possibility for transport bindings
to introduce higher level message patterns such as request/response.
Presumably, other bindings could also support a request response model,
but the SOAP specification does not mandate any particular relation
between request/responses implemented by HTTP for example and SMTP (I
think it should)."

One can imagine message exchange patterns be introduced by modules as
well as bindings. I think the more general point is that SOAP doesn't
mandate any mapping between multiple bindings. For example, SOAP says
nothing about what happens if one has a UDP binding on one leg and an
HTTP binding on another leg.

If we started to provide such guidelines, however, it would mean that we
would have to define the exact set of services that we wanted SOAP to
provide rather than the current situation where SOAP from a protocol
point of view doesn't do anything and the only requirement to the
binding is that it can carry a complete SOAP message.

The problem that I see with this approach is that we as an example have
to define what request/response means. In the specific case of HTTP it
is easy, but HTTP is a specific application protocol with a specific
purpose in mind. What are the general QoS properties for
request/response - in fact - what *is* a response? Is this mail a
response or is it another, independent message? Does it matter that the
response goes to a third party or is it then not a response anymore? Is
a response sent a year later still a response? Are intermediaries
required to provide a reverse path for the response? What if I have a
chat protocol - are messages there responses or are they part of a
dialog? What if I have a bidirectional communications channel like TCP
but *don't* want messages sent back at me? Without knowing a lot about
what is going on it is hard to tell what the right solutions are.

We can make decisions about all these questions with a specific set of
scenarios in mind but at least to me it doesn't seem to be in harmony
with the flexibility we have in SOAP elsewhere and I would strongly
favor not having to go there for the core SOAP spec (nor do I believe
this is really what the spec tries to say :)

It is perfectly valid for a module to define a message path that allows
messages to be sent back to the initial sender but I cannot see the
benefit of doing it in the core spec.

The benefit of the current model is that we allow people to extend SOAP
in ways that enable them to build the semantics they need. As a
hypothetical example, one could imagine a perfect underlying protocol
that provided access control, security, privacy, guaranteed delivery,
support for multiple message exchange patterns etc. In that case, we
wouldn't have to use the SOAP extensibility model for all this. However,
in cases where this is not available, it is nice to be able to extend
the protocol with these features.

Noah: "Interestingly, the the request/response model is explicitly
exploited in a transport independent way by the RPC specification in
chapter 7.  The specification does not state, but strongly implies that
RPC responses will indeed be returned to the originator of the request,
and that the transport binding will be responsible for doing the
necessary addressing.  Certainly the HTTP binding does this."

If one looks at the RPC convention (at least with respect to the message
exchange pattern) as a protocol binding that defines a binding to a
"virtual" RPC protocol then I think we have a coherent model. Because we
support nested bindings, it so happens that the RPC binding can be
nested with HTTP which happens to provide req/res. However, one can
imagine the RPC convention (or "binding") being used with other bindings
as well. A simple example of nested bindings is the MIME
multipart/related binding where one can imagine a "binding stack" that
looks like

	"RPC (req/res)" over "MIME multipart" over "HTTP"

Regarding the proposal, I think it is interesting and certainly covers
many useful cases. Is there any reason why this would have to be part of
the core spec and not, say, a header like SOAP Dsig? That would allow
other "dependency" modules to be added later on to incorporate logic
processing etc. How would your proposal work with such future modules?

Henrik

[1] http://www.w3.org/TR/SOAP-dsig/
[2] http://www.w3.org/DesignIssues/Mandatory.html

Received on Monday, 14 May 2001 17:39:05 UTC