Page 297 -

11 The Worklet Service 293
(downtime, remodeling, testing, and so on); in certain circumstances the entire
process must be aborted.
Alternately, an attempt might be made to include every possible twist and turn
into the process model so that when such events occur, there is a branch in the
process to take care of it. But this approach often leads to very complex models
where much of the original business logic is obscured, and does not avoid the same
problems arising when the next unexpected exception occurs.
The Exception Service addresses these problems by allowing designers to define
exception handling processes (called exlets) for parent workflow instances, to be
invoked when certain events occur and thereby allowing execution of the par-
ent process to continue unhindered. It has been designed so that the enactment
engine, besides providing notifications at certain points in the life-cycle of a pro-
cess instance, needs no knowledge of an exception occurring or of any invocation
of handling processes – all exception checking and handling is provided by the
service. Additionally, exlets for unexpected exceptions may be added at runtime,
and such handling methods automatically become an implicit part of the process
specification for all current and future instances of the process, which provides for
continuous evolution of the process while avoiding any need to modify the original
process definition.
The Exception Service uses the same repertoire and dynamic rules approach as
the Selection Service. An extensible repertoire of exlets is maintained by the service
for each type of potential exception within each workflow specification. Each time
the service is notified of an exception event, either actual or potential (i.e., a con-
straint check), the service first determines whether an exception has in fact occurred,
and if so, where a rule tree for that exception type has been defined makes a choice
from the repertoire based on the type of exception and the data attributes and values
associated with the work item/case, using a set of rules to select the most appropriate
exlet to execute.
Any number of exlets can form the repertoire of an individual task or case. An
exlet may be a member of one or more repertoires, that is, it may be reused for
several distinct tasks or cases within and across process specifications. Like the
selection service, the exception handling repertoire for a task or case can be added
to at any time, as can the rules base used, including while the parent process is
executing.
The Selection and Exception subservices can be used in combination within
particular case instances to achieve dynamic flexibility and exception handling
simultaneously. The Worklet Service is extremely adaptable and multifaceted, and
allows a designer to provide tailor-made solutions to runtime process exceptions and
requirements for flexibility.

11.3 Service Oriented Architecture

The Worklet Service has been implemented as a YAWL Custom Service. However,
the deployment of the Worklet Service is in no way limited to the YAWL environ-
ment, but may be ported to other environments (e.g., BPEL engines) by making the