Re: i154: are roles invariant?

  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.

"Jean-Jacques Moreau" <> on 11/29/2001 10:23:59 AM

To:   "" <>, Noah
      Mendelsohn/CAM/Lotus@Lotus, Doug Davis/Raleigh/IBM@IBMUS, Yves Lafon
      <>, Marc Hadley <>
Subject:  i154: are roles invariant?

This is a follow up of the discussion that just occurred at the

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>.
      <X actor="next" mU="true">...</Y>
      <PlayTheFollowingRole actor="next" mU="true">meAsWell</X>
      <Y actor="meAsWell" mU="true">...</Z>

Is it important for us to support such changing roles?


Received on Thursday, 29 November 2001 16:04:22 UTC