Page 212 -
P. 212
Chapter 7
The Architecture
Michael Adams, Marlon Dumas, and Marcello La Rosa
7.1 Architectural and Implementation Considerations
The YAWL System is structured as a service-oriented architecture. It is composed of
an extensible set of YAWL Services (see, for example Chaps. 10–12), each of which
is deployed at a certain endpoint and offers one or multiple interfaces. Some of these
services are user-facing, meaning that they offer interfaces to end users, while others
offer interfaces to applications or other services.
Among the different styles of service-oriented architectures, the YAWL System
adopts the Representational State Transfer (REST) style. In line with the principles
of REST (or RESTful) architectures, YAWL services provide access to resources,
each with a Unique Resource Identifier (URI). For example, each workflow specifi-
cation is exposed by the Engine as a resource, and when an instance of a workflow
specification (i.e., a case) is created, this case is also represented as a resource.
Also, in line with the principles of RESTful architectures, YAWL services inter-
act with one another using the basic operations defined by the HyperText Transfer
Protocol (HTTP). Specifically, YAWL services interact by means of HTTP’s GET
and POST operations: GET being used to obtain information about a given resource,
and POST being used to create resources and to update existing resources. Messages
exchanged through these operations are encoded using the eXtensible Markup Lan-
guage (XML) and (with some exceptions) conform to predefined XML schemas.
Messages may contain references to resources, which are concretely represented as
Uniform Resource Locators (URLs).
RESTful architectures are conceptually simple and universal. Indeed, HTTP
is a mature and pervasive web protocol and XML is supported by libraries and
frameworks available for almost every contemporary programming environment.
1
Here, the term resource is used to designate an information resource accessible over the Web.
Later in the chapter, the term is used in a different setting to denote human actors or software
applications that perform tasks during the execution of a workflow.
M. Adams (B )
Queensland University of Technology, Brisbane, Australia
A.H.M. ter Hofstede et al. (eds.), Modern Business Process Automation, 205
DOI 10.1007/978-3-642-03121-2 7, c Springer-Verlag Berlin Heidelberg 2010

