Page 215 -

208 M. Adams et al.
For resourcing purposes, work items can be defined as manual or automated.
Manual work items are performed directly by a human worker, while automated
6
work items are routed to a software application for automated processing. Man-
ual work items are routed to the resource manager, while automated work items
are routed to the codelet manager. The distribution of manual work items to orga-
nizational participants is governed by a resource-based access control mechanism
handled via the resource manager. This service resolves the task–resource associ-
ations by identifying a set of participants to whom a work item should be offered
for execution. This information is transferred to the worklist service, which handles
interactions with the end user. All operations performed by the human resources
participating in a workflow case are stored in the execution logs (e.g., allocation
and starting time of a work item). Furthermore, the resource manager offers access
to system administrators to create and modify the organizational model via the
Administration console (e.g., to add or remove a participant or to assign roles to
participants).
The worklist handler is responsible for offering and allocating manual work
items to users and transferring the associated business data through a Web form.
This service provides a dashboard through which each user can query the set of
work items being offered to them, can allocate a specific work item to themselves
(thus locking it), start a work item, or complete it. When a work item is started
(or “checked out”), the worklist handler generates a Web form, allowing users to
view and enter data related to the work item. When a work item is completed (or
“checked in”), the worklist handler submits to the Engine any data gathered during
the execution of the work item.
As communication with the worklist handler (and other services of the YAWL
System) is via XML over HTTP, it is not difficult to build customized Web applica-
tions on top of the worklist handler to expose work lists and work items to the end
user. The system is shipped with a default renderer that generates Web forms with
a basic layout. Alternatively, the forms connector can be combined to the worklist
handler to allow the connection of manual work items to custom-made Web forms
(e.g., JSP or ASP forms). The path of a manual work item through the involved
services is illustrated in Fig. 7.2.
Automated tasks are handled by codelet executions. A codelet is essentially a
Java class that complies to a predefined Java interface, and is programmed against
other predefined Java interfaces for controlling a work item and accessing work item
data. The codelet service is a special type of service to which the Engine delegates
the execution of codelets. The codelet model offers the expressiveness and versatil-
ity of a programming language, and is therefore suitable for the implementation of
operations that involve complex data manipulations.
A task, whether manual or automated, may additionally be linked to the Worklet
Service for its execution. This service allows users to dynamically change a running

6
Note that the distinction between manual and automated work items is only meaningful for a task
handled by the Resource Service – it is ignored for those work items that are associated with other
services.