FW: a question about mustunderstand.

Hi folks. 

Some offline conversation between noah and myself that might clarify some
confusion 
(primarily on my part - but others might also have interpreted things the
same way).  

-----Original Message-----
From: Kasi, Jay 
Sent: Friday, May 18, 2001 2:58 PM
To: 'Noah_Mendelsohn@lotus.com'
Subject: RE: a question about mustunderstand.


Hi noah. 

Yes. You are right. The chain of inferences breaks at one point if you
carefully examine 
the SOAP specification. There is a missing statement in the specification
that is in your
analysis (which I read carefully) but not in the specification. Look at your
statement
(last SOAP reference and conclusion). 

My references are the following SOAP statements. 

Section 4 ----> 

3. Body (see section 4.3) 
   - The element name is "Body". 
   - The element MUST be present in a SOAP message and MUST be an immediate
child 
     element of a SOAP Envelope element. It MUST directly follow the SOAP
Header 
     element if present. Otherwise it MUST be the first immediate child
element 
     of the SOAP Envelope element.  

CONCLUSION 1: The BODY MUST BE PRESENT. 

Section 4.2.2 ---->

Not all parts of a SOAP message may be intended for the ultimate destination
of the SOAP message but, instead, may be intended for one or more of the
intermediaries on the message path. The role of a recipient of a header
element is similar to that of accepting a contract in that it cannot be
extended beyond the recipient. That is, a recipient receiving a header
element MUST NOT forward that header element to the next application in the
SOAP message path. The recipient MAY insert a similar header element but in
that case, the contract is between that application and the recipient of
that header element.

CONCLUSION 2: THIS TEXT DOES NOT ADDRESS THE CASE EXPLICITLY WHERE THE ACTOR
SPECIFICATION 
              IS INVALID OR DOES NO EXIST. THEREFORE IT IS LOGICAL TO ASSUME
THAT IN THIS
              CASE, THIS HEADER ELEMENT WOULD BE FORWARDED TO THE ENDPOINT.

Section 4.2.2 -----> 

Omitting the SOAP actor attribute indicates that the recipient is the
ultimate destination of the SOAP message.

CONCLUSION 3: THIS INDICATES THERE IS A WAY TO TARGET A HEADER ELEMENT TO
THE ENDPOINT. 
              (unanimous actor)

Section 4.3.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).

CONCLUSION 4: THE ENDPOINT IS THE RECIPIENT WHEN THE ACTOR IS OMITTED. IF
MUSTUNDERSTAND=1
              THE ENDPOINT HAS TO FAULT IF IT DID NOT FOR ANY REASON PROCESS
THE MESSAGE. 

section 4.2.3 ----> 

Tagging elements in this manner assures that this change in semantics will
not be silently (and, presumably, erroneously) ignored by those who may not
fully understand it.

CONCLUSION 5: THIS IMPLIES THAT THE INTENT OF SOAP WHEN A HEADER ELEMENT
WITH
              MUSTUNDERSTAND = 1 IS NOT PROCESSED BECAUSE OF AN INVALID OR
NONEXISTENT 
              ACTOR IS A FAULT RETURNED. 

section 4.3.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".
The default actor is indicated by not using the actor attribute (see section
4.2.2).

CONCLUSION 6: THE ENDPOINT HAS TO PROCESS THE BODY OR FAULT. 

YOUR ANALYSIS -----> 

SOAP implements a model in which various headers may or may not be processed
at various points along the message path, but no explicitly named point
(I.e. explicit actor) may be further along the path than the point at which
header(s) handled by the default actor are processed.  In this respect, SOAP
implements a model in which the ordering of processing of explicitly
targeted messages is indeterminate with respect to each other,  and all
headers with the default actor are known to be processed after all
explicitly targeted messages.   

CONCLUSION 7: THE ENDPOINT HAS TO FAULT SINCE IT CANNOT PROCESS THE BODY
BECAUSE THERE IS 
              A EXPLICITLY TARGETED MESSAGE THAT WAS NOT PROCESSED. 
   
-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: Friday, May 18, 2001 1:53 PM
To: Kasi, Jay
Subject: RE: a question about mustunderstand.


Thank you.  In your note you say:

>>  and it cannot process it (and therefore has to 
>> fault) if there is an unconsumed
>> mustunderstand block to a specific actor.  

Several people have asserted this, but I don't see the part of the 
specification that leads you to say this.  Honestly, it may be something 
obvious that I'm missing, but I don't see it.  Can you give me a reference 
to the section and text?  Many thanks.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







"Kasi, Jay" <jay.kasi@commerceone.com>
05/17/01 03:53 PM

 
        To:     "'Noah_Mendelsohn@lotus.com'" <Noah_Mendelsohn@lotus.com>
        cc: 
        Subject:        RE: a question about mustunderstand.


Hi Noah. 

Thanks for your response. The only concern I have about your 
caching example is that the way I understand SOAP, the endpoint MUST 
process
the body and other blocks to the ananomous actor LAST (in unspecified 
order)
and it cannot process it (and therefore has to fault) if there is an
unconsumed
mustunderstand block to a specific actor. I suspect that your 
interpretation
of 
SOAP is not as I read it. I will defer to your interpretation. 

thanks
jay kasi

-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: Thursday, May 17, 2001 11:36 AM
To: Kasi, Jay
Subject: Re: a question about mustunderstand.


>> hi noah.
>> 
>> your writeup was truely excellent.
>> 
Thank you.

>> however there is one point that was not clear. why is this
>> interpretation of soap wrong?  i am not sure i understood your
>> response when i brought it up at the f2f.
>> 
>> 1. there is always a block to an unspecified actor with
>> mustunderstand = 1.  this has to
>>    be processed last by the endpoint. an example is the soap body
>> that is equivalent to
>>    a header block to an unspecified actor with mustunderstand =
>> 1. 
There is always a <Body>.  As you say, it is always mustUnderstand,
and always destined for the anonymous actor which is indeed known to 
follow all other actors.  However, your summary is not quite right.
There can be other header blocks destined for the same anonymous
actor.  SOAP V1 .1 does not say anything about whether the body
is processed before or after such other header blocks.

>> 2. this implies the body cannot be processed by the endpoint
>> if any mustunderstand block
>>    to a specific actor was ignored. the endpoint obviously has to
>> fault. 
I am sorry, but where do you see that the SOAP specification
says that?  IF a block reaches the intended actor, then
mustUnderstand must be processed.  If it misses such an actor
entirely, then no error occurs and SOAP does not call for any.
SOAP requires no checking at the endpoint for mustUnderstand
blocks that have survived.

Let me give you a practical example of where this can occur.
You add to a message a header block addressed to a
"cache manager" actor, mark it "mustUnderstand"
and use a child element that indicates that the
message cannot be cached.

The meaning is:  IF you happen to reach a cache
manager, don't cache this message.  It does
NOT mean "you must reach a cache manager".

The whole reason for my analysis is that many
readers of the soap specification are making 
the same assumption you are: "surely if
something is important enough to require
mustUnderstand then it is a mistake for it
not to happen at all."  I hope the example 
above shows why that is not true.


3. therefore, all mustunderstand will be processed if no
>> fault is generated. 
I hope I have explained why this is not true.
Furthermore, doing the check for missed headers
only at the end is probably not what you want.
If I have in order:

A. Start transaction
B. Update bank account
C. Log result

It is not safe to catch a failure to do
step A only at the end.  You must catch
it before doing step B.  That is why
my proposal claims that do do what
you seem to want, some notion of
overall ordering is needed (I propose
a partial order) and checking for 
missed operations must be done at every
step along the way.  This is definitely
much more than mustUnderstand gives you. 

>>4. therefore mustunderstand in soap is not
>> completely broken.
>> 
I never said it was, but I don't think it
is intended to solve the problem you're
talking about.  At best, it solves a 
different and much smaller problem
(see cache manager example above).

>> the ordering issue however is another dimension, multiple faults
>> in a single response is also another dimension, so is
>> compensation actions if some things were done and others were
>> not.
>> 
Well, I've tried to show why ordering is directly
related to what you want (see the A,B,C example).
I agree that the other issues are at best indirectly
related.  Thank you!

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Friday, 18 May 2001 19:52:34 UTC