Page 29 -

14 W. van der Aalst et al.

Fig. 1.7 Performing the task Settle Bill

The simple example illustrates that in the YAWL environment, as in virtually
all BPM environments, there is a distinction between build time and runtime. Mod-
els are constructed in the build time component, the Editor (discussed in detail in
Chap. 8), and subsequently deployed in the runtime environment. The runtime envi-
ronment itself can consist of a number of components, but at its core are the Engine
(discussed in detail in Chap. 9) and the Resource Service (discussed in detail in
Chap. 10). The Engine deals with the control-flow logic and workflow data, while
the Resource Service is concerned with the routing of work items to appropriate
resources. A simplified overview of the YAWL architecture is presented in Fig. 1.8
(a detailed discussion of the YAWL architecture can be found in Chap.7).

1.8 Positioning of YAWL

YAWL has a number of features that position it uniquely in the crowded field of
BPM. The language could be developed without the pressures of vested interests
and a sole focus on providing comprehensive support for the Workflow Patterns
was possible. In contrast to BPMN, comprehensive control-flow patterns sup-
port was achieved through the introduction of a minimal set of constructs, rather
than a construct-per-pattern approach. More recently, comprehensive support for
the resource patterns was realized in YAWL, both the language and the support
environment.
Another distinguishing feature of YAWL is the fact that it has a formal founda-
tion, that is, both a precisely defined syntax and a precisely defined semantics. In the
latest version of YAWL, the (abstract) syntax has been defined through the use of set