Page 281 -

10 The Resource Service 277
the standard. In such cases, a Custom Form may be user-defined and associated with
a task at design time by specifying a URL to the form. At runtime for such a task,
the Resource Service will package up the work item and its data and send it to the
custom form to populate its fields, and then will display it. On submission of the
form by the user, the work item data is extracted from the form by the service and
passed back to the work item in the same manner as dynamic forms. Custom forms
may be built using any web-based technology, such as JSF, Javascript, .NET, PHP,
or any other environment that can receive data, use it to populate form fields, update
the data with user inputs, and pass control back to the calling service.
A Worklist Controller component maintains the references to work items within
each work queue for each participant, and responds with the appropriate work item
list when requested by the Forms Manager. The work queues managed by the Con-
troller are updated after each occurrence of a user or system action affecting them
by the Resource Coordinator. The Worklist Controller in turn queries the Privileges
Manager to ensure only those actions for which a participant is authorized are
enabled on worklist forms. The Privileges Manager handles both User privileges
(sourced from the Organizational Data for each participant) and Task privileges
(sourced from the Resource Map for each task) – discussed in detail in Sect. 10.6.
The Org Model Administrator is responsible for loading and maintaining the
organizational model and its incorporated data, whether from the internal YAWL
Organizational Model database tables or from an external data source via Inter-
face O. It also manages the updating of data via the Org Data Management and User
Management forms (cf. Sect. 10.3.2), and provides internal table access to external
sources for objects that are not loaded via Interface O.
The Resource Map Parser is invoked when the service is notified of an enabled
work item, and is used to parse the resourcing specification XML (Fig. 10.1) into
a ResourceMap object (if it is not already in cache), and then carries out the ini-
tial resource distribution (cf. Sect. 10.5). ResourceMap objects also store secondary
resourcing information and participate in later user-triggered resourcing changes.
Each task definition has its own discrete Resource Map. As part of the initial dis-
tribution, the parser may make use of various filters, constraints, and allocation
strategies as defined at design-time – each of these are also “pluggable,” so that user-
organizations can add their own particular methodologies to the way work items are
resourced.
The Codelet Invoker is responsible for the execution of codelets. Codelets may
be thought of as non-human resources for executing tasks, and each is literally a
Java class, implementing a generic interface, that performs a certain action. A task
is associated with a codelet at design time using the Editor; the task must first be
marked as automated (automated tasks are those that do not require human resourc-
ing). It is not mandatory for an automated task to be associated with a codelet – data
transformations may also be performed via the XQuery predicates of a task’s output
data parameters.
Codelets are “pluggable” – new codelets may be easily added to the codelet
repertoire, and are immediately available to be associated with tasks in the Edi-
tor (the Editor retrieves the list of available codelets though Interface R). A number