Page 275 -
P. 275
10 The Resource Service 271
Even though there is necessarily a certain volume of data passed from the engine
to the service and back again, one of the fundamental design goals of the service
was to minimize data passing to the greatest possible extent. One way it has been
minimized is through the utilization of various data caches on the service side – see
Sect. 10.4.2 for more details.
In addition to the engine interfaces, the Resource Service provides three inter-
faces of its own:
Interface O is the Organizational Model Interface, providing the means to use
organizational data held in external data sources, rather than the default inter-
nal YAWL Org Model. Any type of external data format may be used; an
abstract DataSource class is provided, which must be extended by each client
to map the external org data into the format required by the service, called a
ResourceDataSet – essentially a set of five maps, each a mapping of unique iden-
tifier – populated YAWL resource object pairs (i.e., Participant, Role, Position,
OrgGroup, and Capability).
Interface R is the Resourcing Interface, which externalizes the organizational
data managed by the service via a set of API methods, thus providing custom
services (and particularly the YAWL Process Editor) with a means of accessing
the YAWL default org model contents and codelet list (all data are exposed as
read-only through this interface).
Interface W is the Workqueue Interface, which externalizes the mechanisms of
the internal worklist handler, allowing external applications and custom services
the means to provide alternate worklist visualizations, rather than the default
worklist forms provided with the service. This interface supports and exposes
the full set of resource patterns handled by the service.
The Process Repository is a data store (i.e., local disk or URL) holding the set
of process specifications created via the Editor, from where they may be loaded
through the service’s administration tools into the Engine. The Event Logs is a data
store (again, local disk or URL) where a process log is written containing all resourc-
ing decisions made for each work item handled by the service. The service supports
administrators and users via a number of web forms.
10.4.2 Internal Architecture
Figure 10.5 is a representation of the internal structure of the Resource Service and
shows its primary components and the major relationships between them. At the
core of the service is the Resource Coordinator, which is the hub for all traffic into
and out of the service via all six interfaces, and is responsible for communication
between, and coordination of, all of the composite parts of the internal service.
To minimize data traffic across the interfaces (described in Sect. 10.4.1), the ser-
vice makes extensive use of data caching. First, when the service starts, the entire
organizational data model is loaded into memory-cached data structures, which