Re: i154: are roles invariant?

This was my take as well. I thought that the
point was you cannot have a node that acts in
a given role only for selected blocks that are
targetted at that role.

e.g.
	<a actor="foo">
	<b actor="foo">

either the node "processes" both a and b or nothing
depending upon whether it assumes the role of "foo".

This is somewhat complicated by the fact that "to process"
a message as per the SOAP process model, the node that
assumes the role of "foo" in the case above, should it
be an intermediary could forward on a message that
had either a or b (or both!) to a subsequent node as long as the
spec for a and/or b included the provision that the processing
of said block could include the reinsertion of an identical
block...

The processing is invariant with respect to a given
role, either the SOAP node acts in a given role for
the processing of a given message or it does not, period.

I don't think that we have anything to say about how
a node chooses to implement so long as, from the perspective
of an external observer, the SOAP processing rules/model
have been applied as specified.

Cheers,

Chris

Yves Lafon wrote:

> On Thu, 29 Nov 2001, Jean-Jacques Moreau wrote:
> 
> 
>>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
>>
> 
> My reading on the paragraph of the spec was more invariant wrt a specific
> role, ie: you can't stop acting as a role, and not invariant as the set of
> roles assumed by the processor prior processing the message.
> The second part saying "an encoding role may be 'encode as identity' on
> one message and 'encode as base64' for another message".
> As the specs seems unclear, it should be more explicit (either way,
> invariant for one role during processing, or for the set of roles).
> 
> 
>>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?
>>
> 
> It can be important if the node starts to decipher a blob then find out
> that it must act on it using a new role, this role being hidden for
> security reason.
> 
>

Received on Thursday, 29 November 2001 22:17:27 UTC