After long reflections, i'm going to start introducing the notion of activity instances like this:
Now, an execution has a list of variable maps called execution scopes. this will be refactored into it's own base class ExecutionScope.
ExecutionScopes will have a VariableMap
ExecutionScopes will be concrete. E.g. when a separate variable scope needs to be created for a concurrent path of execution.
ExecutionScope will be the base class for
* ActivityInstance (part of pvm)
* SubProcessInstance (extends ActivityInstance, part of pvm)
* TaskInstance (extends ActivityInstance, part of jpdl or xpdl) *
* ServiceInvocationInstance (extends ActivityInstance, part of jpdl or xpdl)
Activities will be responsible for creating ActivityInstances and this is optional
ActivityInstances can optionally lock the execution
A list of TimerDefinitions will be added to the Node. A timer requires an ActivityInstance that locks the execution. When an activity creates an ActivityInstance, the plain pvm execution will create Timers for the TimerDefinition's that are declared on the node. When the node is left, those timers will be cancelled.
ActivityInstances will be partially extensible. It will be mapped with a table-per-class hierarchy. Process languages can add subclasses and map fields to existing columns, but they can't introduce new columns, as that would break PVM schema stability.
Good move Tom,
We already added those concepts in both XPDL and BPEL extensions: ActivityInstance, SubprocessInstance, TaskInstance...
Definitely a good thing to have them at PVM level