Page 217 -

210 M. Adams et al.
data interchange formats. In addition to the core Engine, the Workflow Reference
Model identifies five major component types and their interfaces:
Interface 1 is for Process Definition Import and Export, through which process
definitions are loaded into, or unloaded from, the engine
Interface 2 is the Client Application interface, through which work items are
passed from the engine to an application (e.g., a worklist) for processing, and
passed back to the engine when processing is complete
Interface 3 is the Invoked Application interface, through which the engine may
directly activate an external application to process a work item
Interface 4 provides interoperability with other workflow enactment engines
Interface 5 is for Administration and Monitoring, through which an external
administrative tool may administrate processes running in the engine, and the
engine may pass administrative information to such tools
Unlike the YAWL System, the WRM is not structured as a service-oriented
architecture. Instead, the WRM is a more abstract description of a core enactment
engine and an interoperating set of components, which could be implemented using
a variety of architectures. The YAWL System provides a specific embodiment of
the WRM interfaces in the setting of a service-oriented architecture. Also, in many
respects, the YAWL interface extends and deviates from the WRM interfaces. Thus,
it cannot be said that the YAWL System complies with the WRM. It is merely
inspired by the WRM, but significantly differs from it in many respects.
The relations between the core services of the YAWL System and their interfaces
are captured in Fig. 7.3 and discussed one-by-one below.

7.3.1 Engine

Process specifications are loaded into the Engine and stored in a repository, from
where they may be instantiated to produce cases. The Engine manages the execu-
tion of cases by progressing each case according to its current state and control-flow
description, and by performing the specified data mappings between the case and
its tasks as required. In doing so, at each stage of a process, the Engine deter-
mines which work items should be offered for processing, and which events should
be announced to the environment. Each task in a process instance is associated at
design time with at least one YAWL Service (either explicitly or, if not specified, is
implicitly associated with the Resource Service).
An overarching design principle of the YAWL System was that the Enactment
Engine should be completely agnostic with regards to the services interacting with
it; that is, totally unaware of the operations of external services, so that each could be
served in a generic way. From an engine perspective, each service is a “black-box”
that avails itself to process data served by the engine through its interfaces. Thus, the
Engine needs no knowledge of its external environment. This principle is in contrast
to traditional workflow systems where, for example, the worklist handler is treated