Page 277 -

10 The Resource Service 273
Other objects are passed from the engine to the service at runtime, and immedi-
ately stored in caches, so that the internal caches of the engine are not relied upon
for regular updates and synchronizations. The cached objects include:

Work items: Whenever the service receives notification from the engine of an
enabled (manual) work item via Interface B, the work item is immediately added
to the Work item Cache. In this way, the service is always aware of the set of
“live” work items at any particular time, rather than having to repeatedly poll
the engine for this information (which for large sets of work items would place
unnecessary load on the engine). When a work item is started, the (parent) work
item in the cache is replaced with the child (or children) work items resulting
from the start process. When a work item completes, it is removed from the
cache. This cache is persisted so that it is reloaded when the service restarts;
when the engine restarts, the service’s work item cache is synchronized against
the engine’s own caches – this synchronization process may also be manually
triggered via a button on the Administration Queues form, if desired. All work
items in all work queues are actually references to work items in the cache (i.e.,
only one copy of each work item ever exists), which also minimizes the size of
objects and data structures created by the service.
Specifications: For each specification that is loaded via the Case Management
form, a copy is placed in the Specifications Cache. Some specification data,
particularly schemas of user-defined data types, are required for dynamic form
generation. If a work item is received from the engine that belongs to a specifica-
tion that is not in the service’s cache (i.e., it has been loaded via another Custom
Service or the engine has been restarted), a copy is retrieved from the engine via
Interface B. The specification cache is not persisted, as a noncached specification
can be retrieved by a once-only request from the engine.
Task Metadata: Information describing a task (e.g., input and output parame-
ters and their various descriptors, and data schemas describing the entire data
structure of the work item) are also required for dynamic forms generation, and
thus are cached to avoid requests across the interface each time a work item’s
dynamic form is displayed. Task metadata is cached for all tasks not associated
with another Custom Service, for all versions of all specifications for which a
case instance is currently executing.
Resource Maps: A resource map is an object that is created from a task’s
resourcing specification, and is used to perform the distribution of a task’s work
items to resources at runtime. The design time resourcing parameters for each
task are stored in the specification file, as XML (see Listing 10.1). When a work
item is enabled at runtime, the service retrieves the resource map for it from the
cache, and uses it to distribute the work item. If the resource map is not currently
contained in the cache, the XML parameters for the task are retrieved and parsed
by the Resource Map Parser into a resource map object and placed in the cache
(see below). Thus, there is a resource map for each task in each version of each
specification for which a work item has been enabled.