Page 226 -

7 The Architecture 219
The choice of a RESTful architectural style, with messages exchanged in Plain
Old XML (POX) over HTTP, makes the YAWL System simple to program against.
An alternative SOAP-based Web services style would have introduced additional
complexity which, while enabling additional infrastructure-level functionality to be
exploited, was not found to be strictly necessary in the context of the YAWL System.
A potential drawback of the adopted architecture is that it ties the YAWL System to
the HTTP protocol. The ubiquity of HTTP, however, compensates for this potential
drawback. In addition, the YAWL WS-Invoker enables SOAP-based services to be
invoked during the performance of designated tasks.
The interfaces provided by the YAWL System’s services are described in its
technical documentation. In particular, XML Schemas for a number of the YAWL
services are provided with the system. A more complete and machine-processable
specification of these interfaces could be achieved using WSDL, especially given
that WSDL 2.0 supports the description of RESTful services. It is expected that
such specifications will be added in future releases of the system.
The overview of the YAWL System provided in this chapter sets the ground for
more in-depth descriptions of specific parts of the system given in Chaps. 8–12.

Exercises

Exercise 1. The choice of a RESTful architectural style for the YAWL environ-
ment did not come without certain trade-offs between its features and those of other
network-based software architectures. Research REST and the available alternative
architectures in terms of the features and capabilities each offers. Discuss why you
think the RESTful architectural style was chosen for the YAWL environment, with
particular reference to the following:
(a) Does it make it easier to create and manage communication between custom
services and the engine?
(b) Does it impose any limitations on the environment?
Exercise 2. YAWL uses a number of interfaces to interact with external services
and applications.
(a) Compare the YAWL interfaces with those defined in the Workflow Reference
Model. How closely do the functions of the YAWL interfaces map to those
proposed by the reference model?
(b) Why does YAWL not have a direct implementation of the reference model’s
Interface 3? How is the functionality of Interface 3 implemented in YAWL?
(c) Which YAWL interface is used:

(i) To load a specification?
(ii) To “check-out” a work item?
(iii) To query the process logs?
(iv) To start a case instance?
(v) To detect a runtime exception?