RE: An analysis of mustUnderstand and related issues

>Henrik suggests that SOAP V1.1 mandates, at a given actor: "Either the
>whole message succeeds or the whole message fails."   I do not 
>think the
>SOAP specification makes this guarantee, but perhaps it comes 
>close to ensuring enough to solve Glen's problem.

I think it at least comes very close if not goes all the way. In section
2 it says as part of the processing model, step 2 (note the *all*):

	"Verify that all mandatory parts identified in
	step 1 are supported by the application for this
	message (see section 4.2.3) and process them
	accordingly."

And further in section 4.2.3:

	"If a header element is tagged with a SOAP
	mustUnderstand attribute with a value of "1",
	the recipient of that header entry either MUST
	obey the semantics (as conveyed by the fully
	qualified name of the element) and process
	correctly to those semantics, or MUST fail
	processing the message (see section 4.4)."

And here it says "fail the message". Note that this is exactly the same
as HTTP does and I believe most other application layer protocols. One
has to deal with the whole incoming message in order to figure out what
to do.

>I read this as somewhat ambiguous.  Step 1 seems to be 
>vacuously satisfied, except insofar as it prepares one for 
>step 2. It doesn't really impose an order on anything. 

In my mind it goes father and really says: look at the actor attribute
and pick all the parts of the message that are intended for you. Then
take this set and move on to step 2. It is correct that it doesn't
enforce an ordering because it refers to "all parts" of the message as a
whole.

>   Step 
>2 can be read as either: "Verify that everything mandatory is 
>supported and then start processing" or "Verify/process, 
>verify/process."  I infer that Henrik reads it as the former.  
>I can say that interpretation never occurred to me, but it is 
>plausible.  At the very least, this should go on the 
>clarification list. See below for my analysis of the pros and 
>cons and implications for the Glen question.

Some of the experience of the SOAP model obviously comes from previous
work on mandatory extensions in HTTP. What SOAP does it that it moves
from a more traditional mechanism where we have one mandatory part (for
example the HTTP request method) to potentially a set of mandatory parts
defined by the sender as well as the receiver.

In its purest form this means that you cannot "unmarshal" a message
based on a single part but rather you have to parse it. This is one of
the reasons why SOAP has the notion that all headers are supposed to be
equal from a processing point of view. Whether they are equal from a
"message path" point of view is a different question.

>One other complication which I think needs clarification in 
>the SOAP specification is that, as Henrik and I have both 
>noted, the same processing software can have more than one 
>actor name (e.g. "http://...." & "next").  Any rules that 
>refer to the responsibility of an actor must clearly indicate 
>whether each distinct actor name is handled separately, or 
>whether the actor is free to take on as many identities as it 
>considers appropriate, and to apply rules to all matched 
>header entries in bulk.  In the particular case above, if some 
>header entries are explicitly addressed to an intermediary, 
>and others are addressed to 'next', must all be checked for 
>mustUnderstand before any processing is attempted?

My initial intent (which of course can be discussed) was that a SOAP
processor would a) know its own name and b) know the use of SOAP's
"virtual addresses" like "next hop" and "the end" to be able filter the
message for parts intended for it either explicitly or implicitly.

>In any case, I don't think the SOAP specification comes close 
>to guaranteeing that "Either the whole message succeeds or the 
>whole message fails."  Even if I "understand" all the MU's 
>there can be all sorts of failures as I work my way through 
>them.  I certainly don't see anything above as requiring 
>rollback of such partial processing, and I do not believe that 
>it would in general be practical in lightweight SOAP implementations.

I agree that we cannot or should not say anything about roll-back or
whatever else mechanism is needed for SOAP implementations. This would
in my mind a) cross the boundary between a wire protocol and
implementation and b) cross the boundary between SOAP core and what SOAP
carries.

In general, without some semantic knowledge about a module, it is hard
to say how it should behave in the case of an error. However, for many
typical cases, I think the side effects are likely either to be
negligible in which case roll-back doesn't matter or severe enough so
that roll-back will have to be implemented anyways because of the any
number of things that can go wrong besides the SOAP processing.

Let me discuss your proposal in a new mail :)

Thanks for your time putting this together!

Henrik

Received on Thursday, 31 May 2001 14:47:40 UTC