Page 219 -

212 M. Adams et al.
Interface X (for eXception), which does not correspond to the WRM, but pro-
vides endpoints for the detection and handling of runtime process-level excep-
tions

The decision to combine the WRM interfaces 2, 3, and 4 into one YAWL
Interface (B) was taken to ensure that the Engine remained agnostic to its exter-
nal services; rather than requiring separate interfaces for invoked applications and
interoperability, this decision delegates management of the interaction of those com-
ponent types to a YAWL Service. The result is that all communications between the
Engine and such components are handled through a single, generic interface that
provides an additional abstraction layer between the Engine and other services, as
opposed to requiring particular interfaces for particular services. For example, the
Web Service Invoker Service acts as an abstraction layer between the engine and
external web services (such as delegating a booking task to an online travel agency).
Without this layer, the engine would have to provide specific interfaces for all the
different types of web services and intercommunication protocols available.
Interfaces B and X also provide for the notification of certain events that occur
during the life-cycle of a process instance. Interface B notifies all registered services
of the following events (Interface X is discussed in Sect. 7.3.4):

EnabledWorkItemEvent: this event is fired when a work item becomes enabled,
that is, ready to be executed. A service that receives notification of an enabled
work item event has the option to check-out the work item (via an interface
method), thus taking responsibility for its processing (e.g., displaying its data
on a worklist form for editing or passing its data as input to an application). On
checkout, the engine marks the work item as executing. When the service com-
pletes its processing of the work item, it checks it back in to the engine (again via
an interface method), the engine maps the updated data (if any) back to its parent
net, marks the work item as completed, and then enables the next task or tasks in
the control-flow.
CanceledWorkItemEvent: this event fires when an enabled or executing work
item is canceled (via a cancelation region or exception handler, or withdrawn
when a nonselected member of a deferred choice set). A service that receives
notification of a canceled work item event may need to undertake remedial action
for the work item if it has previously checked it out (e.g., to remove it from a
worklist, or cancel an application running on its behalf).
CompletedCaseEvent: this event fires when a process instance completes and
is useful to services that started the case so that any finalize actions can be
performed.
TimerExpiryEvent: this event occurs when a timed work item reaches its dead-
line.
Note that a service receiving notifications may choose to ignore them, for exam-
ple, a service may have no interest in a CompletedCaseEvent if the case was
launched by another service.