ALS-configuration identifier

As we've seen   up to  
this    point, there  are  different  types  
of
activities,  and   each type is  a    
function of  the   ALSs that are
registered with that 
specific  activity. So, when creating an activity
and it's  
associated context, there's a requirement   to say "create 
a
context for a specific type of  activity". That's essentially what 
the
ALS-configuration identifier is,  and with hindsight  I don't 
know why
we didn't just explicitly say that begin was  parameterised 
with the type that'll
go into the context.

 

This can be   accomplished in  a 
couple of   ways.  One  would be,  
as
described  above, to parameterise   begin.  That 
assumes that a  given
context/activity service  can provide  
contexts for multiple different
types   of activity.   
The  other  way  would  be  to  have a   
single
context/activity service per activity type (so the paramaterisation 
is
essentially   implicit).    Either 
option   may  make  sense   from 
an
implementation perspective,  and we did wonder 
whether  we  need to define
this at all.  It could be an  
addressing issue: does a  service manage
multiple "sessions" or only one 
- that could be  hidden by the service
implementation. What we're saying 
is that how you, as the creator of an activity,

locate the right activity service/context service 
is always going to be outside the scope

of the specification in one way or 
another.

 

Mark.

 

----
Mark Little,
Chief Architect, 
Transactions,
Arjuna Technologies Ltd.
 
www.arjuna.com