Page 299 -

11 The Worklet Service 295

Exception Interface X
Gateway Service

Engine Service
Side Client Side Server
YAWL Custom
Engine Service
Engine Service
Side Server Side Client

Engine Side Service Side

Fig. 11.1 Interface X architecture

While the implementation of the Exception Service was the catalyst for the cre-
ation of Interface X, one of the overriding design objectives was that the interface
should be structured for generic application, that is, it can be applied by a variety
of services that wish to make use of checkpoint and/or event notifications during
process executions. For example, in addition to exception handling, the interface’s
methods provide the tools to custom services to enable ad-hoc or permanent adap-
tations to process schemas, such as redoing, skipping, replacing, and looping of
tasks.
As it only makes sense to have one Custom Service acting as an exception
handling service at any one time, services that implement Interface X have two
distinct states: enabled and disabled. When enabled, the engine generates notifica-
tions for every process instance it executes, that is, the engine makes no decisions
about whether a particular process should generate the notifications or not. Thus it
is the responsibility of the designer of the Custom Service to determine how best
to deal with (or indeed ignore) the notifications. When the service is disabled, the
engine generates no notifications across the interface. Enabling and disabling an
Interface X Custom Service is achieved via parameter setting in a configuration file
(cf. Sect. 11.5).

11.4 Worklet Service Architecture

This section describes the technical attributes and structure of the Worklet Service.
The service is constructed as a web service and so consists of a number of J2EE
classes and servlet pages, organized in a series of Java packages.
A schematic of the external architecture of YAWL, showing the relation of the
Worklet Service within it, is shown in Fig. 11.2. The entities “Worklet Specs,”