RE: i154: are roles invariant?

Hi Doug,

I think you have it exactly right... 

The means by which a SOAP node determines the set of roles it plays with
repect to a given message is (explicitly) unstated in editors copy Part 1
Section 2.2 [1]. So that could include the content of the message.

The set of roles that the node acts in MUST (appear to) be invariant during
the processing of an individual SOAP message - also section 2.2. The
parenthesised "appear to" is my addition on recognition of the wording in
Section 2.5:

"Note however that nothing in this specification should be taken to prevent
the use of optimistic concurrency, roll back, or other techniques that might
provide increased flexibility in processing order as long as all SOAP
messages, SOAP faults and application-level side effects are equivalent to
those that would be obtained by direct implementation of the following rules
in the order shown below."

Although the pieces might be a little scattered, I do think its all there in
the (draft)spec.

Stuart
[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: 29 November 2001 21:04
> To: Jean-Jacques Moreau
> Cc: xml-dist-app@w3.org; Noah Mendelsohn; Yves Lafon; Marc Hadley
> Subject: Re: i154: are roles invariant?
> 
> 
> Jean-Jacques,
>   I agree - this is the type of situation I was envisioning,
> one where the list of roles being played changes *after*
> the "processing" started.  I do believe that the spec
> allows for this as long as you are also able to fully
> support the processing model.  By that I mean, once those
> new roles are determined you MUST go back and redo the MU
> checking and if an MU fault is thrown any work that might
> have been done MUST be undone.  Thus giving the appearance
> that all MU checking (for all roles) was done before any
> processing began.  If your SOAP node can not do this then
> you should not have accepted the contract of the
> "PlayTheFollowingRole" header and should have generated
> an MU fault for it.
>   What I don't think the spec says clearly enough is that
> this is supported - and as of now the resolution to this
> (which is i154) is that I've proposed text for the primer
> to help elaborate on this point.
> -Dug
> 
> 
> "Jean-Jacques Moreau" <moreau@crf.canon.fr> on 11/29/2001 10:23:59 AM
> 
> To:   "xml-dist-app@w3.org" <xml-dist-app@w3.org>, Noah
>       Mendelsohn/CAM/Lotus@Lotus, Doug 
> Davis/Raleigh/IBM@IBMUS, Yves Lafon
>       <ylafon@w3.org>, Marc Hadley <marc.hadley@sun.com>
> cc:
> Subject:  i154: are roles invariant?
> 
> 
> 
> This is a follow up of the discussion that just occurred at the
> f2f.
> 
> Consider the message below. A simple inspection of the message is
> enough for a node to determine it should process blocks <X> and
> <PlayTheFollowingRole>, and only these two blocks. Processing
> then starts. However, during the evaluation of
> <PlayTheFollowingRole>, the node also discovers that it must play
> the role "meAsWell". If it assumes this new role, it breaks the
> invariant (on roles - i154); if it does not, it breaks the
> contract represented by <PlayTheFollowingRole>.
>   <envelope>
>     <header>
>       <X actor="next" mU="true">...</Y>
>       <PlayTheFollowingRole actor="next" mU="true">meAsWell</X>
>       <Y actor="meAsWell" mU="true">...</Z>
>     </header>
>   </envelope>
> 
> Is it important for us to support such changing roles?
> 
> Jean-Jacques.
> 
> 
>

Received on Monday, 3 December 2001 08:31:19 UTC