Page 221 -

214 M. Adams et al.
Resource Service, a human resource is referred to as a Participant. Each participant
may perform one or more Roles, hold one or more Positions (each of which belongs
to an Org Group), and possess a number of Capabilities. Workflow tasks that require
resourcing at runtime have their resourcing requirements specified at design time
concomitantly with the design of the process control-flow and data perspectives,
using the Editor.
In addition to communicating with the Engine through Interfaces A and B, the
Resource Service exposes functionality through three interfaces of its own:
Interface O provides an interface to organizational data sources. In addition to
providing a default organizational data model, which may be populated post-
installation, this interface allows preexisting organizational data sources to be
directly “plugged in” to the service. The interface is generic enough to allow
the use of not only organizational data existing in other relational database sys-
tems, but also other types of data sources, such as LDAP servers, web services,
spreadsheets, or even plain text files, requiring only a thin translation layer to be
implemented
Interface R provides access to the organizational data by authorized external
clients (such as, but not limited to, the Editor). This interface provides sets of
both human resource and codelet descriptors
Interface W exposes the entire worklist routing functionality to allow external,
specialized worklists to be developed and implemented. Such worklists may be
used in conjunction with, or completely replace, the default worklist handler
To access the Resource Service via Interfaces R and W, a session must first
be established with the service in a similar fashion to sessions established with
the Engine. The Resource Service maintains its own session tokens with external
clients.
At runtime, the Resource Service receives EnabledWorkItemEvent notifications
from the Engine via Interface B for all enabled work items that are not specifically
registered with another YAWL Service. For manual tasks, the service then retrieves
the resourcing specification (defined at design time) for the task from which the
work item was created. Based on that specification, it will determine the initial dis-
tribution set of participants, and then apply all the defined filters, constraints, and
allocation strategies to that set before distributing the work item to the appropriate
participant(s). For automated tasks, the service retrieves a reference to the specified
codelet (if any) and then executes it using the work item’s data as inputs.
The sets of filters, constraints, allocation strategies, and codelets available to a
designer for a task are each “pluggable,” that is, they can be easily extended so that
developers can add new members to the set of each by implementing the appropriate
(Java) interface and adding the new class to the Resource Service’s repository. Such
additions are immediately available to designers via Interface R.
The Resource Service is described in detail in Chap. 10.