Download Implementing Activity Structures Process Modeling On Top Of The

23
6.2. Shuffle Expression Runtime Support
The ASL run-time support is in the form of an activity structure manager. This module is linked into the
MARVEL kernel. Its main job is to intercept every command corresponding to a rule and add the client’s
activity structure object, if any, at the end of the argument list. It finds the client’s structure object by the
rather inefficient mechanism of searching through the structure objects in the objectbase until it finds one
whose myclient field matches CurrentClient. This approach works because there is no more than one
structure object at a time per client.
This approach was taken to minimize changes to MARVEL. A more efficient approach might be to extend
the internal context description with administrator-defined fields, which could be specified in MSL in the
form of attributes declared for a new built-in CONTEXT class. If it were also possible to assign links in
the effects of rules, then each client’s context description could be linked directly to its corresponding
activity structure, and thus search would be avoided.
In any case, if there is no structure object activated for the current client, the command will be passed
through as is to the rule processor. This allows activity structure definitions to be mixed and matched
with standard MARVEL rules, and in fact MARVEL rules might even have the same names and parameter
signatures as the rules generated for the activity structure definitions. This works with the current
MARVEL rule overloading support because of the implicit parameter.
There is one significant extension to MARVEL that we do plan for immediate implementation: Originally,
the overloading process returned the single rule that best matches the actual parameters according to
inheritance and subtyping. This has been changed to return all equally close matching rules in a list. In
the main rule processing loop, the condition of the first rule on the list is evaluated, including backward
chaining if one or more predicates are not marked no_chain (or no_backward). But if the condition
cannot be satisfied, then instead of halting at this point the evaluation repeats with the next rule in the list,
and so on.
This change allows multiple rules with the same name and arguments, but different conditions. This new
facility provides a nice means for differentiating multiple occurrences of the identical activity in different
places within an activity structure, where different condition and effects are needed to govern control
flow. An example was shown in the previous section, with "A1; A1".
To complete this change, the MARVEL loader was modified to no longer disallow such rules, which were
previously considered to be ‘‘conflicting’’. (An earlier facility to automatically ‘‘merge’’ the conditions
and effects of multiple rules with the same name, parameters and activities had been removed long ago.)
The MARVEL kernel automatically associates a clientID with each client. This clientID is used within the
server to determine the session context (e.g., its in-progress rule chain). Unfortunately, clientID’s can
currently be reused, through distinct server processes executing at different times for the same MARVEL
objectbase.
This becomes a problem since the ACTIVATE rule involves persistent storage of clientID’s in the
myclient attribute of structure objects. An incidental reuse of a clientID could accidently associate the
corresponding client within an activity structure previously activated by another client, now defunct, that
happened to have the same clientID. The original client might have been explicitly exited, or might have
crashed. Thus it is necessary to guarantee unique clientID’s (for the same MARVEL objectbase) over all
time. This can be done by making the clientID counter persistent, saved within the objectbase directory,