Page 300 -

296 M. Adams

Fig. 11.2 Worklet Service external architecture

“Rules,” and “Event Logs” comprise the Worklet Repository. The service uses the
repository to store rule sets, worklet specifications for uploading to the engine, and
generated process and audit logs. The YAWL Editor is used to create new worklet
specifications, and may be invoked from the Rules Editor (cf. Sect. 11.10). The
Rules Editor is used to create new or augment existing rule sets, making use of cer-
tain selection logs to do so, and may communicate with the Worklet Service via a
JSP/Servlet interface to override worklet selections following rule set additions (see
Sect. 11.10.2). 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
specification, but with an “.xrs” extension (signifying an “XML Rule Set”). All rule
set files are stored in the rules folder of the Worklet Repository. Listing 11.1 shows
an excerpt from a rules file for a Casualty Treatment process.
Figure 11.3 shows a representation of the internal architecture of the Worklet
Service. The obvious hub of the service is the WorkletService class, which admin-
istrates the execution of the service and handles interactions with the Engine via
Interfaces A and B.
For each work item that is checked out of the engine, the service creates a
CheckedOutItem object. In the Engine, each work item is a “parent” of one or more
child items – one if it is an atomic task, or a number of child items in the case of
a multiple instance atomic task. Thus, the role of each CheckedOutItem object is