RE: [ws-caf] Multiple contexts

["Jim Webber" <Jim.Webber@newcastle.ac.uk>]

Hello Guy,

> Since it is the ALS that extends the context, and there is 
> only one ALS per activity, security and transactions would 
> have to have _different_ contexts (probably nested for the 
> reason outlined below?)... 

Sorry I think I mislead you there - I meant that the context document is
extensible rather than the lifecycle aspects.

> What I meant: if there are different top-level contexts for 
> the same activity, then how can they reach the same 
> completion state (Success or fail)? 
> In other words, is there some rule that says that different 
> CTX services will reach the same completion state if they are 
> for the same activity (and yet not nested in each other)? 

OK - this is different to my understanding that a context defines its
activity. If you have multiple top-level contexts then you need
something to choreograph them (like a process or an application).
Whether that choreography is itself modelled as an external activity is
an application-specific choice.

> I assume that this should be the case, since the activity is 
> defined by means of a context, and therefore the completion 
> state of an activity would correspond to the completion state 
> of some context? 

Yes - the completion state of the context should be representative of
the completion state of the activity. To my mind they are the same
scope.

> The alternative would be to say that there is one top-level 
> context that defines the activity (and its completion state) 
> and there are different nested contexts, such as one for 
> transactions and one for security. 
> This would imply that a transaction context could be a child 
> of a security context. 

The implication does not necessarily follow. I can have transactional
activities as part of my application, and I can have secure activities
and there may be some overlap between these two sets (i.e. secure
transactional activities) but the structuring is left to the application
to decide.

The general case I think would not be to nest these (unless the problem
domain clearly called for it).

Jim
--
http://jim.webber.name