Page 147 -

136 M. Adams
Assess Claim is selected and assigned to a worker’s worklist for action. The worker
may decide that the generic Assess Claim task is not appropriate for this particular
case, because this claimant resides in an identified storm-damaged location. Thus,
the worker rejects the Assess Claim worklet via a button on their inbox. On doing
so, the system refers the rejection to an administrator who is presented with the set
of case data for Assess Claim (i.e., its cornerstone case), and the set of current case
data.
The administrator then compares the two sets of case data to establish which
relevant aspects of the current case differ from Assess Claim’s cornerstone. Note
that while many of the values of the two cases may differ, only those that relate
directly to the need to handle this case differently are selected (e.g., the location of
the claimant and the date the damage occurred). After identifying the differences,
the administrator is presented with a list of possible worklet choices, if available,
that may suit this particular context. The administrator may choose an appropriate
worklet to invoke in this instance, or, if none suit, define a new worklet for the
current instance. In either case, the identified differences form the conditional part
of a new rule, which is added to the RDR tree for this task using the rule addition
algorithm described earlier.
The principles derived from Activity Theory state that all work activities are
mediated by rules, tools, and division of labor. Translating that to an organiza-
tional work environment, rules refer to business rules, policies and practices; tools
to resources and their limitations (physical, financial, staff training, experience and
capabilities, and so on); and division of labor to organizational hierarchies, struc-
tures, roles, lines of supervision, etc. Of course, these constraints apply to the
creation of a new worklet, just as they would in any workflow management sys-
tem. This means that the authority to create new worklets and add rules to rule
sets would rest with the appropriate people in an organization, and the authority to
reject inappropriate worklets would reside within the duties of a worker charged
with performing the task – the “subdomain expert.” Of course, spurious rejection of
worklets would be managed in the same way as any other instances of misconduct
in the workplace.
In all future instantiations of a specification, the new worklet defined following
a rejection would be chosen for that task if the same contextual conditions occur in
a new instance’s case data. Over time, the RDR rule tree for the task grows towards
specificity as refinements are added (cf. Fig. 4.1).

4.7 Service Interface

To enable the Worklet Service to serve the YAWL enactment engine, a number
of events and methods must be provided by an interface between them. Being a
web-service (cf. Chap. 7), the Worklet Service has been designed to enable remote
deployment (i.e., deployed on a web server in a location remote to the YAWL
Engine) and to allow a single instance of the service to concurrently manage the