Page 302 -

298 M. Adams

to YAWL
Engine via 1 * 1 * HandlerRunner
Interface X ExceptionService CaseMonitor
exception
service

to JSPs 1 *
WorkletGateway CaseMap WorkletRecord
1
to Rules *
Editor
1 * CheckedOutItem 1 * CheckedOutChildItem
to YAWL
Engine via 1 1 *
Interfaces * AdminTaskManager AdministrationTask
A & B WorkletService
1 * 1 * 1 *
RdrSet RdrTree RdrNode
1
1 1 1
EventLogger
ConditionEvaluator
1 1 selection
1 1
1 1
DBManager WorkletEvent service RdrConditionException
Fig. 11.3 Internal architecture of the Worklet Service

11.5 Service Installation and Configuration

Like other YAWL Custom Services, the Worklet Service is a Java-based web service
and so must be hosted within a servlet container. By default, an installation of the
open-source servlet container Apache Tomcat is used to host the YAWL environ-
ment, and as a consequence the Worklet Service is also hosted on Tomcat. Further,
as the Worklet Service is distributed as part of the YAWL installation, it resides
within the same host (again by default).
However, as it is a totally discrete service, the Worklet Service may be installed
on and hosted by any local or remote server running a servlet container. In fact,
it is possible for one instance of the Worklet Service to manage the selection and
exception handling requirements of a number of YAWL engines across domains
simultaneously (or potentially other types of enactment engines that conform to the
interface).
The Worklet Service is distributed as a Java web archive (or .war file), which
includes compiled versions of all of the classes of the service, ancillary classes, the
Worklet Repository (with samples), and the Rules Editor. The service is installed by
placing the war file in the appropriate applications folder of the servlet container.
Each web service, including the Engine, makes use of a configuration file (in
Tomcat terminology, a “deployment descriptor”), which sets the parameters for the