ALS-configuration identifier

["Mark Little" <mark.little@arjuna.com>]

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