Page 251 -

9 The Runtime Environment 245
net, and creates enabled task instances (for atomic tasks) or new “child” net runners
(for composite tasks) for all those tasks enabled for the current net marking. The net
runner notifies the Engine of these enablings, which in turn announces the tasks via
Interface B to the appropriate custom services. Net runners are also persisted.
All “live” atomic task instances (i.e., work items) are cached in the Work Item
Repository, which orders work items into “families” for each task (a task may have
a number of work items created for it). The repository also groups items by their
status (enabled, fired, executing, etc.), their parent net runner, and their case instance
for access by a number of Engine components. Work items are removed from the
repository when a case completes, and all work items in the repository are persisted
across server sessions.
The Case Monitor tracks the status of all current process instances, caching their
details for easy access by custom services and external applications via Interface B.
The monitor maintains details of each case, including time started and execution
times, details of the complete set of all work items created for each process, and
details of all data modifications for each data parameter of each work item, which
it delivers on demand as XML data, so that the current state of all processes in the
entire Engine may be examined.
Any timers that have been defined for tasks are managed by the Timer Coor-
dinator. A timer can be defined for a task at design time, may be initialized either
when a work item of the task is enabled or when it begins execution (cf. Sect. 9.5),
and will expire either after a period of time has elapsed or at a precise moment, as
specified. There is one Timer Coordinator within the Engine that manages all timers
for all tasks – conceptually it is a timer with a dynamic table of work items and their
expiry times; when an expiry time is reached, the timer takes the appropriate action
to skip the work item (if enabled) or complete the work item (if executing), then
removes the work item from its dynamic table. Timer entries are persisted.
All custom services that require communication with the Engine must first be
registered with the Engine via Interface A – the default worklist handler of the
Resource Service contains a web form to facilitate this (Fig. 9.3). The Service Reg-
ister maintains the list of currently registered services. An error will occur if a
Custom Service has been nominated at design time to handle a task and that Custom
Service is not registered with the Engine when the task is enabled at runtime.
Additionally, all custom services that require communication with the Engine
must create a session with (i.e., logon to) the Engine at runtime. These sessions are
maintained by the Session Manager, which on receiving a logon request from a
service will first check that the service is correctly registered (via the Service Regis-
ter), then validate the logon credentials for the service via those stored, and if valid,
will record and return a “session handle” (or key) for the session. The service will
then pass this session handle with all interface requests; the Engine will respond to
the request only after first verifying that the session handle is both valid and active.
A session handle will by default expire after 60 minutes of inactivity, although the
period can be changed via a configuration file.
The Persistence Engine manages runtime object persistence (see Sect. 9.6 for
more details). All runtime requests to persist objects, and to retrieve objects from