A Comparison of Workflow Metamodels

ion Organization Figure 1: Work ow Concepts An organizational model is an abstraction of organizations. A work ow (instance) is a process combined with an organization, and assigns the tasks in the process to actors in the organization. A work ow model combines a process model and an organizational model. A work ow metamodel is a representational language in which to express work ow models. 2.2 Major Types of Work ow Metamodels Since the process model is central to the work ow model, we identify four categories of work ow metamodel based primarily on their process metamodels. Task ow Task is the fundamental element in the process metamodel of taskow based work ow metamodel. It emphasizes the analysis of all the potential sequences of tasks in the speci cation phase. During model execution, an instance of the work ow decides which sequence to follow on the basis of static speci cation and dynamic running context. In the graphical representation of process model, typically a directed acyclic graph (DAG), tasks show up as the nodes, state information as conditions attached to the edges. State transition A state abstracts the context information at a particular time when a system is running. A state transition occurs when a particular event or activity happens. The behaviors of a work ow are represented as a sequence of state transitions. In the process model DAG, states show up as a node, and tasks or events as conditions attached to an edge. Relationship capturing Relationship-capturing based metamodel is founded at the view that the work ow brings all the tasks together on the basis of certain relationship. The process model is built by means of capturing this particular relationship. Example relationships can be triggers 2 [Joosten, 1994] or enabling or disabling conditions. The elements are typically tasks, so in certain respects these resemble the task ow metamodels. Communication based These approaches identify the communications among the various actors. They must also involve tasks, of course, but they present the tasks as occurring in the context of the relationships and communications of the actors, not independently. 2.3 Key Dimensions of Metamodels We propose a list of evaluation dimensions for work ow metamodels. We omit concerns such as ease of use and compatibility with programming languages that are not related to metamodels. The abbreviations in parentheses are used in Table 1. Granularity Granularity indicates the abstraction level of the basic element examined by a metamodel. A task represents a meaningful business action that is. A task might have a ne structure among its constituent tasks [Leymann & Roller, 1994]. Coarse granularity simpli es speci cation and increases exibility, whereas ne granularity simpli es execution. Control Flow (Control) Most metamodels support the basic (sequence, branch, and loop) structures in order to be programatically complete. Some add constructs for synchronization, parallel programming (e.g., fork and join). Some also add constructs to better support concurrency [Chan & Vonk, 1997]. Data Flow (Data) Data ow represents potential paths followed by information exchange. Some metamodels provide a separate representation for data ow; others merge it into control ow with control ow; still others merge it but annotate it explicitly. Organizational Model (Org) An organizational model consists of three parts: role description, role relationships or groups, and an actor assignment policy [Bu ler, 1994]. A model should provide the users with the capability to customize actor types. The structure of role groups can be described in terms of relational, hierarchical, and network models. Assignment policy accomplishes the mapping between logical roles and physical actors. Role Binding (Rol) Role binding is an important technique to enable dynamic actor assignment by loosening the coupling between roles and actors. An actor can adopt the responsibility of a role by binding corresponding run-time support. During execution, an actor can simultaneously claim di erent roles; a role can simultaneously be embodied by di erent actors. Role binding sometime includes support for role delegation, which betters the load balance by means of necessarily delegating part of responsibilities taken by a busy role to others. Exception Handling (Exc) An exception refers to the situation where unexpected behaviors occur during the system execution. Exception handling concerns how to respond properly to exceptions when preserving the legality of system states in case any exception happens. There are two major kinds of exceptions in work ow systems: execution exception and organizational exception. 3 An execution exception occurs when the system runs out of normal control ow; an organizational exception is caused by illegal changes in the organizational structure. A common structure of the speci cation of exceptions is made of a condition-reaction pair: when the condition is veri ed, the corresponding reaction is executed [Casati et al., 1997]. Another rule-based formulation uses nonmonotonic reasoning to handle exceptions [Singh & Huhns, 1994]. Transaction Support (Trn) A transaction is de ned as a set of operations that satisfy ACID properties, namely, atomicity, consistency, isolation, and durability [Gray & Reuter, 1993]. It is crucial to enforce the satisfaction of ACID properties for all the transactions in order to preserve consistency all the time. However, traditional transaction support, like 2-phase lock protocol, are not suitable for heterogeneous environments. Despite this, a good work ow metamodel should provide some support for structuring tasks and guaranteeing some of the properties of their joint execution. Commitment Support (Com) Several subtle forms of commitment can arise in work ows. These can be speci c to di erent actors, and re ect the organizational structure of the work ow. An actor may commit to another to notify him of any changes he e ects, without committing to inform everybody. The challenge is to build new support mechanism to attain more exibility compared to traditional support while maintaining the robustness of work ow systems. 3 SHIIP Example One of the SHIIP scenario involves a shipyard Foreman requesting a con guration group to recon gure or upgrade a prefabricated combinational part [SHIIP, 1997]. We adapt this scenario to better support our goal of comparing di erent approaches. We de ne the scenario as follows: 1. Foreman lls out a report for recon guration and submits to Con guration Group 2. Manager of Con guration Group checks the report. Manager may accept or reject the report. For instance, if she nds that the problem could be xed by means of modifying the old installation procedure, Manager would return the report to Foreman with helpful comments. 3. If the report is returned, the process terminates. Otherwise, it proceeds. 4. Manager makes a nancial budget to estimate the cost of performing the recon guration. After the budget is forwarded to Account O ce, Manager awaits the decision from Account O ce. 5. If the budget fails to pass in Account O ce, the process terminates. Otherwise, it proceeds. 6. Manager delegates a Design Team to work out a design scheme for the requested recon guration. 7. Manager, along with Foreman, checks the scheme from Design Team. If the scheme is not satisfactory, it is returned to Design Team with helpful comments for redesign. Otherwise, it proceeds. 4 8. Manager sends out the approved scheme to Fabricator asking for fabrication. 9. Fabricator identify the parts needed to carry out the fabrication. For those parts unavailable in stock, Fabricator sends out a order form to Supplier. 10. Fabricator proceeds to fabricate when all the parts are available. The nished combinational part is forwarded to Con guration Group. 11. Manager, along with Design Team, checks the fabricated part from Fabricator. If the part exactly embodies their design scheme, the part is delivered to Foreman. Otherwise, the part is returned to Fabricator with helpful comments to request refabrication. 12. Foreman accepts the recon gured part and applies it to the project he is working on. The above scenario describes the normal execution sequence. However, some unexpected situations might happen in the real world. For the purpose of illustration, we consider three exceptions: An exception will occur when a Manager actor does not exist to receive the request from Foreman. Manager checks the format of the report when he receives a recon guration request from Foreman. If some required items|e.g., the part number to be recon gured|are missing, an exception procedure would be initiated to ask for a corrected report. When the parts delivered by the Supplier are not what Fabricator expected, an exception procedure would be initiated to have the parts exchanged for correct ones. The dividing line between normal execution and exceptions is not absolute. We can integrate an exception handler as a part of normal sequence. For instance, we can add the procedure as a routine for Fabricator to check the parts from Supplier and request a resupply if necessary. However, the separation of handling unexpected situations, which do not happen often, helps us to focus on the central control ow and modularize requirement capture. 4 Applying the Metamodels We choose several representative metamodels as the subjects with which we proceed our evaluation. These metamodels cover the categories described in section 2.2 and are well-known. We introduce each metamodel brie y. To save space, we only represent snippets of the above scenario|mostly about the design subprocess of step 7|in each metamodel. 4.1 FlowMark FlowMark is a product developed by IBM corporation [Leymann & Roller, 1994]. The metamodel of FlowMark is taskow based. It includes the following syntactic elements: activity, control connector, transition condition, container, data connector, exit condition, synchr