Re: i154: are roles invariant?

Hello,

Disclaimer: the following is given from an implementation pov...

FWIW the implementation here actually provides for this... a 
header block processor may modify the role played by the SOAP 
node (via an API call, by changing the value of actor URI 
associated with the node) during processing.

So in the scenario you give, a result of processing 
<PlayTheFollowingRole> would be that the header processor 
makes the API call and the role thus changed. At that point the 
header blocks targeted at the new actor URI become available for 
processing. In this way it becomes possible for a node to play 
multiple roles in a dynamic way, based on the results of header 
block processing.

I'm not claiming that this is a good idea, but certain problems can 
be solved this way. Enforcing MU rules in such a case becomes 
complicated, of course. If roles were made invariant, one could 
provide for multiple roles statically assigned I suppose, and maybe 
that would be good enough for most purposes.

RC

> 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 Thursday, 29 November 2001 12:44:52 UTC