The YAWL Worklet Service is an e ective approach to facilitating dynamic exibility and exception handling in work ow processes. Recent additions to the Service extend its capabilities through a programming interface that provides easier access to rules storage and evaluation, and an event server that noti es listening servers and applications when exceptions are detected, which together serve enhance the functionality and accessibility of the Service's features and expand its usability to new potential domains.
Since its introduction, the YAWL Worklet Service has proven to be an e ective
approach to facilitating dynamic exibility and exception handling in otherwise
static process instances [
Now, recent additions to the service provide new methods of interaction that
extend its capabilities through the introduction of an application programming
interface (API) that allows external custom services and applications to interact
with it directly, and an event server that allows listener services to be noti ed
when a worklet is selected or an exception raised during a process execution.
Of particular interest are the ways in which the service can now be more easily
introduced into learning situations.
The WorkletGatewayClient is a client side class that can be used by custom
services [
An instance of WorkletGatewayClient can be used by custom services and applications to rst create a session with the Worklet Service, then use the returned session handle in subsequent API method calls. Any service or application registered with the YAWL Engine is trusted by the Worklet Service, and so the same credentials can used to establish the connection (see Listing 1.4 for an example of how to connect and use the API). 3
Since the primary aim of the Worklet Service is to support processes enacted by the YAWL engine, each rule set is typically uniquely identi ed for a particular speci cation by its YSpecificationID object. However, to generalise RDR support for other custom services and applications, rule sets can now also be uniquely identi ed by any unique string value. Thus, for each client method there are variations to support the fact that either a speci cation identi er or a generalised name may be used to identify rules.
Listing 1.1. Examples of using the Worklet Gateway Client `get' methods p u b l i c v o i d example throws I O E x c e p t i o n f
Y S p e c i f i c a t i o n I D s p e c I D = new Y S p e c i f i c a t i o n I D ( n u l l , " 0 . 1 " ,
" s o m e S p e c i f i c a t i o n " ) ; S t r i n g processName = " someProcess " ; RdrMarshal m a r s h a l = new RdrMarshal ( ) ; W o r k l e t G a t e w a y C l i e n t c l i e n t = new W o r k l e t G a t e w a y C l i e n t ( ) ; S t r i n g h a n d l e = c l i e n t . c o n n e c t ( " admin " , "YAWL" ) ; // g e t a Rule Set S t r i n g ruleSetXML = c l i e n t . g e t R d r S e t ( specID , h a n d l e ) ; i f ( ! s u c c e s s f u l ( ruleSetXML ) ) throw new I O E x c e p t i o n ( ruleSetXML ) ; RdrSet r u l e S e t = m a r s h a l . u n m a r s h a l S e t ( ruleSetXML ) ; // g e t a Rule Tree S t r i n g ruleTreeXML = c l i e n t . g e t R d r T r e e ( processName , n u l l ,
RuleType . C a s e P r e c o n s t r a i n t , h a n d l e ) ; i f ( ! s u c c e s s f u l ( ruleTreeXML ) ) throw new I O E x c e p t i o n ( ruleTreeXML ) ; RdrTree r u l e T r e e 1 = m a r s h a l . u n m a r s h a l T r e e ( ruleTreeXML ) ; ruleTreeXML = c l i e n t . g e t R d r T r e e ( specID , " T r e a t " , RuleType . I t e m S e l e c t i o n , h a n d l e ) ; i f ( ! s u c c e s s f u l ( ruleTreeXML ) ) throw new I O E x c e p t i o n ( ruleTreeXML ) ; RdrTree r u l e T r e e 2 = m a r s h a l . u n m a r s h a l T r e e ( ruleTreeXML ) ; // g e t a Rule Node S t r i n g ruleNodeXML = c l i e n t . getNode ( specID , n u l l ,
RuleType . C a s e P r e c o n s t r a i n t , 1 , h a n d l e ) ; i f ( ! s u c c e s s f u l ( ruleNodeXML ) ) throw new I O E x c e p t i o n ( ruleNodeXML ) ; RdrNode node1 = m a r s h a l . unmarshalNode ( ruleNodeXML ) ; ruleNodeXML = c l i e n t . getNode ( processName , " A r c h i v e " ,
RuleType . I t e m S e l e c t i o n , 4 , h a n d l e ) ; i f ( ! s u c c e s s f u l ( ruleNodeXML ) ) throw new I O E x c e p t i o n ( ruleNodeXML ) ; RdrNode node2 = m a r s h a l . unmarshalNode ( ruleNodeXML ) ; Get Methods Firstly, there are a number of get methods, which can be used to retrieve an individual rule node, a rule tree (a set of connected nodes for a particular rule type and task id), or an entire rule set (the set of rule trees for a particular speci cation or process). Each of the get methods, and in fact all of the client methods, return a String value representing a successful result or an appropriate error message. A successful result for a get method contains an XML String representation of the object retrieved, which can be unmarshalled into the appropriate object using the RdrMarshal class, as shown in the examples in Listing 1.1.
Evaluation Methods The rule sets maintained by the Worklet Service can be evaluated against a given data set via the client API at any time. Like the get methods, there are variations that accept a speci cation identi er or a generalised name, and if evaluating an item-level rule tree, a task id. There are three possible results when a rule set is evaluated: 1. No rule tree exists for the given speci cation id or process name, and/or task id, and rule type (as required). An error message to that e ect is returned. 2. A rule tree exists for the given parameters, but none of its nodes' conditions were satis ed. An error message to that e ect is returned. 3. A rule tree exists for the given parameters, and the conditions of at least one its nodes were satis ed. An RdrConclusion object is returned.
For a rule set associated with a YAWL speci cation, an RdrConclusion object represents a set of primitives, each comprising an action and a target, and provides methods for iterating through the primitives set. Of course, if the Worklet Service is being used merely as an RDR store/evaluator, and thus there is no intention to have the rules evaluated by the Worklet Service in relation to a YAWL process instance, then the conclusion of a rule node may contain any data of relevance to an external service or application. For example, the conclusion of an ItemSelection rule node contains one primitive, with an action of `select' and a target naming the worklet to select. The conclusion of an exception rule type may contain any number of primitives (see the Worklet Service chapter of the YAWL User Manual for more information). An example of an evaluate method call is shown in Listing 1.2.
Adding a Rule Node RDR are structured in such a way that rule nodes can be added at any time, but never deleted, since deleting a node would `break' the tree's internal structure. The client API provides a method to add a rule node to a rule set for a speci cation or process, with similar variations to those mentioned above for the di erent rule types. An example of adding a node is shown in Listing 1.3.
Listing 1.3. Example using the Worklet Gateway Client to add a new Rule Node p u b l i c v o i d example throws I O E x c e p t i o n f
Y S p e c i f i c a t i o n I D s p e c I D = new Y S p e c i f i c a t i o n I D ( n u l l , " 0 . 1 " ,
" s o m e S p e c i f i c a t i o n " ) ; RdrMarshal m a r s h a l = new RdrMarshal ( ) ; W o r k l e t G a t e w a y C l i e n t c l i e n t = new W o r k l e t G a t e w a y C l i e n t ( ) ; S t r i n g h a n d l e = c l i e n t . c o n n e c t ( " admin " , "YAWL" ) ; // add a Rule Node S t r i n g c o r n e r S t r = "<data><Age>40</Age><F r a c t u r e >t r u e </F r a c t u r e ></data>" ; Element e C o r n e r s t o n e = JDOMUtil . s t r i n g T o E l e m e n t ( c o r n e r S t r ) ; R d r C o n c l u s i o n c o n c l u s i o n = new R d r C o n c l u s i o n ( ) ; c o n c l u s i o n . a d d P r i m i t i v e ( E x l e t A c t i o n . Suspend , E x l e t T a r g e t . Case ) ; c o n c l u s i o n . a d d C o m p e n s a t i o n P r i m i t i v e ( " myWorklet " ) ; c o n c l u s i o n . a d d P r i m i t i v e ( E x l e t A c t i o n . Continue , E x l e t T a r g e t . Case ) ; RdrNode node = new RdrNode ( "Age=>75" , c o n c l u s i o n , e C o r n e r s t o n e ) ; S t r i n g newNodeXML = c l i e n t . addNode ( specID , " T r e a t " ,
RuleType . I t e m P r e C o n s t r a i n t , node , h a n d l e ) ; i f ( ! s u c c e s s f u l ( newNodeXML ) ) throw new I O E x c e p t i o n ( newNodeXML ) ; node = m a r s h a l . unmarshalNode ( newNodeXML ) ;
When adding a rule node, values for condition, conclusion and cornerstone are all that is required, as shown in line 15 of Listing 1.3. The Worklet Service will determine the appropriate location in its rule tree for the new node2. The cornerstone data is particularly important when adding a node to an existing tree, as it is used to determine the proper location of the node. If no rule set currently exists for the speci cation id or process name given, then one is created. Further, if no rule tree currently exists for the speci cation id or process name, and rule type (and task id if required) given, then one is created, and the node is added as the rst node in the tree (after the root node).
User-de ned Functions The condition de ned for each rule node is an expression that must evaluate to a nal boolean (true/false) value. Expressions can be formed using the usual numeric, comparison and logical operators, and operands consisting of literal values, and/or the values referenced by the name of case and/or workitem data variables. Alternately, an XQuery expression may be used, which is useful if you need to query case or workitem data stored as a complex data type.
In addition, conditional expressions support the use of user-de ned functions
that are de ned to evaluate the available data in a particular way, and in turn
may be inserted into complex, conjunctive expressions. These functions can pass
arguments consisting of literal values, and case or workitem data variable names,
2 Interested readers can nd details of how the Service determines the location of a
new rule within the tree on pages 59{60 of [
For work item level rules, a special data structure, called this, can be passed as an argument to a user-de ned function (e.g. myFunc(this)). The structure is assigned an XML string representing the complete work item record, so that speci cation and task descriptors, and state and timing values may be accessed within the user-de ned function. 4
Each time the Worklet Service selects a worklet for a work item, or raises an exception for a work item or case, details of the event are announced to registered listener classes. Listeners can use these event announcements to perform additional processing as required, and make it possible to create exception handling service chains.
An abstract class called WorkletEventListener is the base class for all worklet listeners. This class is a HttpServlet that handles all of the mechanics involved in receiving noti cations from the Worklet Service and transforming them into ve abstract method calls that are to be implemented by extending classes: { caseLevelExceptionEvent is called each time a case level exception is raised, and passes descriptors for case-level data, the type of exception raised, and the RdrNode that evaluated to true and so triggered the raising of the exception. { itemLevelExceptionEvent is called each time a item level exception is raised, and passes descriptors as above in addition to the work item record that was the `subject' of the exception being raised. { selectionEvent is called each time a worklet selection occurs, i.e. when a worklet is substituted for a work item, passing descriptors for case-level data, the work item that the worklet was selected for, and the rule node that evaluated to true and so triggered the selection. { constraintSuccessEvent is called each time a case or work item that has pre- or post-constraint rules de ned has had those rules evaluated and the case or work item passes the constraints (i.e. no rules were satis ed and so no exception was raised). { shutdown is called when the Worklet Service is shutting down, and allows implementers to take any necessary action.
Once the listener class implementation is complete, the extra servlet de nition section needs to be added to the web.xml of the implementing (listener) service, and then at runtime the listener is to be registered with the Worklet Service, as shown in Listing 1.4. 3 See the YAWL User and Technical Manuals for details on the de nition of userde ned functions
Listing 1.4. Registering a listener with the Worklet Service p u b l i c boolean r e g i s t e r W o r k l e t L i s t e n e r ( ) f
W o r k l e t G a t e w a y C l i e n t c l i e n t = new W o r k l e t G a t e w a y C l i e n t ( ) ; t r y f
S t r i n g u r l = " h t t p : / / l o c a l h o s t : 8 0 8 0 / m y S e r v i c e / w o r k l e t l i s t e n e r " ; S t r i n g h a n d l e = c l i e n t . c o n n e c t ( " admin " , "YAWL" ) ; r e t u r n s u c c e s s f u l ( c l i e n t . a d d L i s t e n e r ( u r l , h a n d l e ) ) ; g catch ( I O E x c e p t i o n i o e ) f
l o g . e r r o r ( " F a i l e d to r e g i s t e r l i s t e n e r : " + i o e . getMessage ( ) ) ; g r e t u r n f a l s e ; 5
The additions to the Worklet Service outlined above allow it to be more easily integrated into new and existing projects. Since rules can now be easily added and evaluated directly via the API, there is no longer the requirement to use the Windows-based Rules Editor for that purpose, and therefore it is no longer necessary to undertake the learning curve associated with using the Rules Editor before the bene ts provided by the Service can be realised. In addition, the ability to de ne and evaluate rules sets for environments external to YAWL process executions broadens the application of the Service's functionality to much wider domains. Finally, the ability for external applications and services to be noti ed when an exception or worklet selection has occurred during a process execution, and when a case or work item has passed a constraint evaluation, opens the Service up to new areas of functional support, particularly to the facilitation of exception handling service chains.
An example of a novel use of these extensions can be seen in the development
of blended work ow, which integrates two speci cations for the same work ow
process, one structured (YAWL) and one ad-hoc (goal-based), allowing users to
switch between two views of the same process instance [