Page 298 -

294 M. Adams
necessary associations in the service interface. As such, the implementation may
also be seen as a case study in service-oriented computing whereby dynamic flexi-
bility and exception handling in workflows, orthogonal to the underlying workflow
language, is provided.
As detailed in Chap.7, Custom YAWL Services interact with the Engine through
XML/HTTP messages via certain interface endpoints, some located on the Engine
side and others on the service side. Specifically, custom services may elect to be
notified by the engine when certain events occur in the life-cycle of nominated pro-
cess instantiations (i.e., when a work item becomes enabled, when a work item is
canceled, when a case completes or is canceled), to signal the creation and comple-
tion of process instances and work items, or to notify certain events or changes in
the status of existing work items and cases.
For example, on receiving notification from the engine of a work item-enabled
event, a Custom Service may elect to “check out” the work item from the engine.
On doing so, the engine marks the work item as executing and effectively passes
operational control for the work item to the Custom Service. When the custom ser-
vice has finished processing the work item, it will check it back in to the engine,
at which point the engine will mark the work item as completed, and proceed with
the process execution. It is this interaction that is the fundamental enabler of the
Worklet Selection Service.
Three interfaces of the Engine are used by the Worklet Service (cf. Fig. 11.2):

Interface A provides endpoints for process definition, administration, and moni-
toring – the Worklet Service uses Interface A to upload worklet specifications to
the engine
Interface B provides endpoints for client and invoked applications and workflow
interoperability – used by the Worklet Service for connecting to the engine, to
start and cancel case instances, and to check work items in and out of the engine
after interrogating their associated data
Interface X (“X” for “eXception”), which has been designed to allow the engine
to notify custom services of certain events and checkpoints during the execution
of each process instance where process exceptions either may have occurred or
should be tested for. Thus, Interface X provides the Worklet Service with the
necessary triggers to dynamically capture and handle process exceptions.

The logical layout of Interface X can be seen schematically in Fig. 11.1, which
shows that a Custom Service (in this case, the Exception Service) implements the
InterfaceXService (Java) interface, which defines seven methods to be instantiated
that enable the handling of notifications that are sent from the EngineSideClient
object to the ServiceSideServer object. The Custom Service may use the methods
of the ServiceSideClient object to call complementary methods in the Engine-
SideServer object, thus enabling inter-service communication, using XML over
HTTP. The ExceptionGateway (Java) interface describes the methods that the
engine side client must implement to provide the necessary notifications to the
Custom Service.