Page 266 -

262 M. Adams
Using the YAWL Editor, a process designer, concomitantly with the design of
the process control-flow and data perspectives, is able to designate how each task
will be resourced at runtime. First, a decision will be made for each task whether
to have it handled at runtime by a specified Custom Service, in which case that
service is responsible for its successful performance, or whether it will by default
be handled by the Resource Service. Each task coupled with the Resource Service
may be designated as a manual (the default) or an automated task (and whether a
task is manual or automated is only of relevance to the Resource Service). A manual
task is a task that will be performed by a human resource; an automated task by
definition does not require human resourcing, but instead may execute a specified
codelet when it enables at runtime. The Resource Service receives notification from
the engine of all task enablings (via Interface B, as per other Interface B services)
for all manual tasks not associated with other custom services and for all automated
tasks (i.e., the Resource Service handles all automated tasks).
In YAWL, a human resource is referred to as a Participant. Each participant
may perform zero or more Roles, hold zero or more Positions (each of which may
belong to an Org Group), and possess zero or more Capabilities. For a manual
task, a designer may provide details of a distribution set of resources to which the
task should be offered at runtime. A distribution set may consist of the union of
zero or more individual participants, zero or more roles, and zero or more dynamic
variables (which at runtime will be supplied with details of participants and/or roles
to which the task should be offered, thereby supporting the late binding of resources
to tasks). The resultant distribution set may be further filtered by specifying that only
those participants with certain capabilities, occupying certain positions and/or being
members of certain org groups, be included.
A designer may also specify certain constraints to apply, for example, that a cer-
tain work item must not be performed by the same participant who completed an
earlier specified work item in a process (called the Four Eyes Principle or Separa-
tion of Duties), or that if a participant who is a member of the distribution set of a
work item is the same participant who completed a particular previous work item
in the process, then they must also be allocated the new work item (called Retain
Familiar).

Tasks vs. Work Items

A YAWL process specification will contain a number of task definitions,
which may be considered to be descriptions of a piece of work that forms part
of the overall process. Thus, control-flow, data, and resourcing specifications
are all defined with reference to tasks at design time.
At runtime, each task acts as a template or contract for the instantiation of
one or more work items. That is, a work item is a runtime instance derived
from a task definition. An analogy might be: a task is to a work item as a
blueprint is to a house constructed from that blueprint.