Page 172 -
P. 172
162 M. Adams and N. Russell
YAWL
Editor
Worklet
X
Worklet Specs
YAWL Service
A
engine Selection
Rules
B Exception Rules
Editor
Logs
YAWL
worklist
user
Fig. 5.7 External architecture of the worklet service
for uploading to the engine, and generated process and audit logs. The YAWL Edi-
tor is used to create new worklet specifications, and may be invoked from the Rules
Editor, which is used to create new or augment existing rule sets, making use of cer-
tain selection logs to do so, and to graphically define exlets, and may communicate
with the Worklet Service via a JSP/Servlet interface to override worklet/exlet selec-
tions following rule set additions. The service also provides servlet pages that allow
users to directly communicate with the service to raise external exceptions and to
create and carry out administration tasks.
Any YAWL specification may have an associated rule set. The rule set for each
specification is stored as XML data in a disk file that has the same name as the spec-
ification’s identifier, but with an “.xrs” extension (signifying an “XML Rule Set”).
Each YAWL specification has a single rule-set file for all selection and exception
rules defined for it. All rule set files are stored in the rules folder of the Worklet
Repository.
To enable the Worklet Service to serve the YAWL workflow enactment engine, a
number of events and methods must be provided by an interface between them,
some originating from the service side and others from the engine side. Some
require a response, while others do not require any acknowledgment (such as event
notifications that do not necessarily require action).
The first four methods described for the selection interface in Chap. 4 are also
used by the exception handling procedure. In addition, the exception interface
requires a further set of events and methods. The enactment engine must notify
the service for the following events: