ARTICLE IN PRESS

Information Systems 30 (2005) 245275

YAWL: yet another workow language

W.M.P. van der Aalsta,b,*, A.H.M. ter Hofstedeb
Department of Technology Management, Eindhoven University of Technology, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands b Centre for Information Technology Innovation, Queensland University of Technology, P.O. Box 2434, Brisbane Qld 4001, Australia Received 20 December 2002; received in revised form 4 September 2003; accepted 5 February 2004
a

Abstract Based on a rigorous analysis of existing workow management systems and workow languages, a new workow language is proposed: yet another workow language (YAWL). To identify the differences between the various languages, we have collected a fairly complete set of workow patterns. Based on these patterns we have evaluated several workow products and detected considerable differences in their ability to capture control ows for non-trivial workow processes. Languages based on Petri nets perform better when it comes to state-based workow patterns. However, some patterns (e.g. involving multiple instances, complex synchronisations or non-local withdrawals) are not easy to map onto (high-level) Petri nets. This inspired us to develop a new language by taking Petri nets as a starting point and adding mechanisms to allow for a more direct and intuitive support of the workow patterns identied. This paper motivates the need for such a language, species the semantics of the language, and shows that soundness can be veried in a compositional way. Although YAWL is intended as a complete workow language, the focus of this paper is limited to the control-ow perspective. r 2004 Elsevier Ltd. All rights reserved.
Keywords: YAWL; Workow languages; Petri nets; Workow management; Workow patterns

1. Introduction Despite the efforts of the workow management coalition (WfMC [1,2]), workow management systems use a large variety of languages and concepts based on different paradigms. Most of the products available use a proprietary language
*Corresponding author. Department of Information and Technology, Faculty of Technology and Management, Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, Netherlands. Tel.: +31-40-247-4295; fax: +31-40243-2612. E-mail addresses: w.m.p.v.d.aalst@tm.tue.nl (W.M.P. van der Aalst), a.terhofstede@qut.edu.au (A.H.M. ter Hofstede).

rather than a tool-independent language. Some workow management systems are based on Petri nets but typically add both product specic extensions and restrictions [35]. Other systems use a completely different mechanism. For example, IBMs MQSeries Workow uses both active and passive threads rather than token passing [6]. The differences between the various tools are striking. One of the reasons attributed to the lack of consensus of what constitutes a workow specication is the variety of ways in which business processes are otherwise described. The absence of a universal organisational theory, and standard business process modelling concepts,

0306-4379/$ - see front matter r 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.is.2004.02.002

ARTICLE IN PRESS
246 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

it is contended, explains and ultimately justies the major differences in workow languagesfostering up a horses for courses diversity in workow languages. What is more, the comparison of different workow products winds up being more of a dissemination of products and less of a critique of workow language capabilities [7]. Workow specications can be understood, in a broad sense, from a number of different perspectives (see [4,8]). The control-ow perspective (or process) perspective describes tasks and their execution ordering through different constructors, which permit ow of execution control, e.g., sequence, choice, parallelism and join synchronisation. Tasks in elementary form are atomic units of work, and in compound form modularise an execution order of a set of tasks. The data perspective deals with business and processing data. This perspective is layered on top of the control perspective. Business documents and other objects which ow between activities, and local variables of the workow, qualify in effect preand post-conditions of task execution. The resource perspective provides an organisational structure anchor to the workow in the form of human and device roles responsible for executing tasks. The operational perspective describes the elementary actions executed by tasks, where the actions map into underlying applications. Typically, (references to) business and workow data are passed into and out of applications through activity-to-application interfaces, allowing manipulation of the data within applications. The focus of this paper is on the control-ow perspective. Clearly, this provides an essential insight into a workow specications effectiveness. The data ow perspective rests on it, while the organisational and operational perspectives are ancillary. If workow specications are to be extended to meet newer processing requirements, control ow constructors require a fundamental insight and analysis. Currently, most workow languages support the basic constructs of sequence, iteration, splits (AND and XOR) and joins (AND and XOR)see [1,4]. However, the interpretation of even these basic constructs is not uniform and it is often unclear how more complex requirements could be supported. Indeed, vendors

afford the opportunity to recommend implementation level hacks. The result is that neither the current capabilities of workow languages nor insight into more complex requirements of business processes is advanced [7]. We indicate requirements for workow languages through workow patterns [7,9]. As described in [10], a pattern is the abstraction from a concrete form which keeps recurring in specic non-arbitrary contexts. Gamma et al. [11] rst catalogued systematically some 23 design patterns which describe the smallest recurring interactions in object-oriented systems. The design patterns, as such, provided independence from the implementation technology and at the same time independence from the essential requirements of the domain that they were attempting to address (see also e.g. [12]). We have collected a comprehensive set of workow patterns to compare the functionality of 15 workow management systems (COSA, ! Visual Workow, Forte Conductor, Lotus Domino Workow, Meteor, Mobile, MQSeries/Workow, Staffware, Verve Workow, I-Flow, InConcert, Changengine, SAP R/3 Workow, Eastman, and FLOWer). The result of this evaluation reveals that (1) the expressive power of contemporary systems leaves much to be desired and (2) the systems support different patterns. Note that we do not use the term expressiveness in the traditional or formal sense. If one abstracts from capacity constraints, any workow language is Turing complete. Therefore, it makes no sense to compare these languages using formal notions of expressiveness. Instead we use a more intuitive notion of expressiveness which takes the modelling effort into account. This more intuitive notion is often referred to as suitability. See [13] for a discussion on the distinction between formal expressiveness and suitability. In the remainder, we will use the term suitability. In this paper, we cannot repeat the detailed arguments given in [7]. Some readers may argue that the patterns are selected subjectively. We partly agree. Since we are not aiming at formal expressiveness but at suitability, we cannot formally prove the need for each of the patterns. However, in [7] the patterns are motivated in

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 247

detail. Moreover, the patterns are based on functionality present in todays tools and frequently used by workow designers when available. (Note that products typically support half of the patterns but there is no consensus on which half.) Several vendors extended their workow products based on the patterns (cf. BizAgi, FLOWer, Pectra, Staffware, etc.) and some open source initiatives have been inspired by the patterns (cf. jBpm, Werkow). Our patterns site [9] is currently visited about 200 times on an average working day, thus showing the interest of both academics and practitioners in this work. The patterns research shows that the suitability of the available workow management systems leaves much to be desired. This observation triggered the question: How about high-level Petri nets as a workow language? Petri nets have been around since the 1960s [14] and have been extended with colour [15,16] and time [17] to improve expressiveness. Petri nets where tokens carry data (i.e., are coloured) are often referred to as high-level Petri nets and are supported by tools such as Design/CPN (University of Aarhus, http://www.daimi.au.dk/designCPN/), CPN Tools (University of Aarhus, http://www.daimi.au.dk/CPNTools/), and ExSpect (EUT/D&T Bakkenist, http://www.exspect.com/). Note that these tools and the corresponding languages also allow for time and mechanisms to hierarchically structure complex models. Therefore, we use the term high-level Petri nets to refer to Petri nets extended with colour, time and hierarchy. There are at least three good reasons for using Petri net-based workow languages [3]: 1. Formal semantics despite the graphical nature. 2. State-based instead of (just) event-based. 3. Abundance of analysis techniques. Unfortunately, a straightforward application of high-level Petri nets does not yield the desired result. There seem to be three problems relevant for modelling workow processes: 1. High-level Petri nets support coloured tokens, i.e., a token can have a value. Although it is possible to use this to identify multiple

instances of a subprocess, there is no specic support for patterns involving multiple instances and the burden of keeping track, splitting, and joining of instances is carried by the designer. 2. Sometimes two ows need to be joined while it is not clear whether synchronisation is needed, i.e., if both ows are active an AND-join is needed otherwise an XOR-join. Such advanced synchronisation patterns are difcult to model in terms of a high-level Petri net because the ring rule only supports two types of joins: the AND-join (transition) or the XOR-join (place). 3. The ring of a transition is always local, i.e., enabling is only based on the tokens in the input places and ring is only affecting the input and output places. However, some events in the workow may have an effect which is not local, e.g., because of an error tokens need to be removed from various places without knowing where the tokens reside. Everyone who has modelled such a cancellation pattern (e.g., a global timeout mechanism) in terms of Petri nets knows that it is cumbersome to model a so-called vacuum cleaner removing tokens from selected parts of the net. In this paper, we discuss the problems when supporting the workow patterns with high-level Petri nets. Based on this we describe yet another workow language (YAWL). YAWL is based on Petri nets but extended with additional features to facilitate the modelling of complex workows.

2. Requirements Since 1999, we have been working on collecting a comprehensive set of workow patterns [7]. The results have been made available through the Workow patterns WWW site [9]. The patterns range from very simple patterns such as sequential routing (Pattern 1) to complex patterns involving complex synchronisations such as the discriminator pattern (Pattern 9). In this paper, we restrict

ARTICLE IN PRESS
248 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

ourselves to the 20 most relevant patterns. These patterns can be classied into six categories: 1. Basic control-ow patterns. These are the basic constructs present in most workow languages to model sequential, parallel and conditional routing. 2. Advanced branching and synchronisation patterns. These patterns transcend the basic patterns to allow for more advanced types of splitting and joining behaviour. An example is the synchronising merge (Pattern 7) which behaves like an AND-join or XOR-join (or in case of more than two ows as a combination of AND- and XOR-joins) depending on the context. 3. Structural patterns. In programming languages a block structure which clearly identies entry and exit points is quite natural. In graphical languages allowing for parallelism such a requirement is often considered to be too restrictive. Therefore, we have identied patterns that allow for a less rigid structure. 4. Patterns involving multiple instances. Within the context of a single case (i.e., workow instance) sometimes parts of the process need

to be instantiated multiple times, e.g., within the context of an insurance claim, multiple witness statements need to be processed. 5. State-based patterns. Typical workow systems focus only on activities and events and not on states. This limits the expressiveness of the workow language because it is not possible to have state dependent patterns such as the Milestone pattern (Pattern 18). 6. Cancellation patterns. The occurrence of an event (e.g., a customer cancelling an order) may lead to the cancellation of activities. In some scenarios such events can even cause the withdrawal of the whole case. Fig. 1 shows an overview of the 20 patterns grouped into the six categories. A detailed discussion of these patterns is outside the scope of this paper. The interested reader is referred to [7,9]. We have used these patterns to evaluate 15 workow systems: COSA (Ley GmbH, [18]), ! Visual Workow (Filenet, [19]), Forte Conductor (SUN, [20]), Lotus Domino Workow (IBM/ Lotus, [21]), Meteor (UGA/LSDIS, [22]), Mobile (UEN, [8]), MQSeries/Workow (IBM, [23]), Staffware (Staffware PLC, [24]), Verve Workow

Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Structural Patterns Pattern 10 (Arbitrary Cycles) Pattern 11 (Implicit Termination)

Advanced Branching and Synchronization Patterns Pattern 6 (Multi - choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi - merge) Pattern 9 (Discriminator)

Cancellation Patterns Pattern 19 (Cancel Activity) Pattern 20 (Cancel Case)

Patterns involving Multiple Instances State -based Patterns Pattern 16 (Deferred Choice) Pattern 17 (Interleaved Parallel Routing) Pattern 18 (Milestone) Pattern 12 (Multiple Instances Without Synchronization) Pattern 13 (Multiple Instances With a Priori Design Time Knowledge) Pattern 14 (Multiple Instances With a Priori Runtime Knowledge) Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge)

Fig. 1. Overview of the 20 workow patterns described in [7].

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 249

(Versata, [25]), I-Flow (Fujitsu, [26]), InConcert (TIBCO, [27]), Changengine (HP, [28]), SAP R/3 Workow (SAP, [29]), Eastman (Eastman, [30]), and FLOWer (Pallas Athena, [31]). In [7,9] it is reported in what way each of these systems supports each of the patterns. For each product pattern combination, we checked whether it is possible to realise the workow pattern with the tool. Most of the products only offer direct support for about half of the patterns. This does not imply that it is impossible to realise the patterns. In many cases, the designer can resort to coding or spaghetti-like diagrams (i.e., diagrams with many arcs to enumerate all possible combinations). Clearly, this makes such systems less suitable for workow support. Some of the patterns can be realised by constructing them using other patterns. For example, Pattern 6 (multi-choice) can be constructed from a combination of Pattern 4 (exclusive choice) and Pattern 2 (parallel split). The resulting diagram may be considerably larger, but it is fairly simple to realise. However, the more advanced synchronisation patterns, patterns involving a dynamic number of multiple instances, and the state-based patterns are more difcult, if not impossible, to realise if not present. While the results reported in [7] mainly refer to suitability, the results in [13,32,33] consider formal expressiveness. In this work several idealised classes of workow languages have been analysed in terms of their expressive power. For example, MQSeries/Workow (IBM, [23]) is an example of a language belonging to the so-called class of synchronising workow models. Synchronising workow models can be thought of as propagating true and false tokens. If an activity receives a true token, it will execute. If it receives a false token, it will simply pass it on. Branches of choices not chosen propagate false tokens, while branches that are chosen propagate true tokens. Synchronisation points await tokens from all incoming branches and, depending on their type, either (1) propagate a true token if it has received at least one true token, and a false token otherwise, or (2) propagate a true token if it has received only true tokens, and a false token otherwise. Synchronising workow models offer direct support for Pattern 7

(synchronising merge) but have problems dealing with loops. A detailed discussion of the formal expressiveness is beyond the scope of this paper. However, it is important to note that there are striking differences between languages and many of the more advanced constructs cannot be realised by the basic control-ow patterns. The lessons learned by both evaluating contemporary systems using a set of workow patterns and a detailed analysis of the fundamental control-ow mechanisms provide a solid basis for YAWL. The remainder of this paper is organised as follows. In Section 3, we analyse the suitability of Petri nets as a workow language. Based on this and the lessons learned, we present the controlow perspective of a new workow language named YAWL in Section 4. We give a formal denition, provide formal semantics, and introduce a correctness notion. Using this correctness notion we will show that it can be veried in a compositional way. To conclude the paper, we relate YAWL to existing approaches, summarise the main results, and discuss future plans.

3. Limitations of Petri Nets as a control-ow language for workows Given the fact that workow management systems have problems dealing with workow patterns it is interesting to see whether established process modelling techniques such as Petri nets can cope with these patterns. The table listed in the appendix shows an evaluation of high-level Petri nets with respect to the patterns. (Ignore the column under YAWL for the time being.) We use the term high-level Petri nets to refer to Petri nets extended with colour (i.e., data), time, and hierarchy [4]. Examples of such languages are the coloured Petri nets as described in [16], the combination of Petri nets and Z specication described in [34], and many more. These languages are used by tools such as Design/CPN (University of Aarhus, http://www.daimi.au.dk/designCPN/) and ExSpect (EUT/D&T Bakkenist, http://www. exspect.com/). Although these languages and tools have differences when it comes to for example the language for data transformations (e.g., arc

ARTICLE IN PRESS
250 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

inscriptions) there is a clear common denominator. When we refer to high-level Petri nets we refer to this common denominator. To avoid confusion we use the terminology as dened in [16] as much as possible. Compared to existing languages high-level Petri nets are quite expressive when it comes to supporting the workow patterns. Recall that we use the term expressiveness not in the formal sense. High-level Petri nets are Turing complete, and therefore, can do anything we can dene in terms of an algorithm. However, this does not imply that the modelling effort is acceptable. Highlevel nets, in contrast to many workow languages, have no problems dealing with state-based patterns. This is a direct consequence of the fact that Petri nets use places to represent states explicitly. Although high-level Petri nets outperform most of the existing languages when it comes to modelling the control ow, the result is not completely satisfactory. As indicated in the introduction we see serious limitations when it comes to (1) patterns involving multiple instances, (2) advanced synchronisation patterns, and (3) cancellation patterns. In the remainder of this section we discuss these limitations in more detail. 3.1. Patterns involving multiple instances Suppose that in the context of a workow for processing insurance claims there is a subprocess for processing witness statements. Each insurance claim may involve zero or more witness statements. Clearly the number of witness statements is not known at design time. In fact, while a witness statement is being processed other witnesses may pop up. This means that within one case a part of the process needs to be instantiated a variable number of times and the number of instances required is only known at run time. The required pattern to model this situation is Pattern 15 (multiple instances without a priori runtime knowledge). Another example of this pattern is the process of handling journal submissions. For processing journal submissions multiple reviews are needed. The editor of the journal may decide to ask a variable number of reviewers depending on the nature of the paper, e.g., if it is controversial,

more reviewers are selected. While the reviewing takes place, the editor may decide to involve more reviewers. For example, if reviewers are not responsive, have brief or conicting reviews, then the editor may add an additional reviewer. Other examples of multiple instances include orders involving multiple items (e.g., a customer orders three books from an electronic bookstore), a subcontracting process with multiple quotations, etc. It is possible to model a variable number of instances executed in parallel using a high-level Petri net. However, the designer of such a model has to keep track of two things: (1) case identities and (2) the number of instances still running. At the same time multiple cases are being processed. Suppose x and y are two active cases. Whenever, there is an AND-join only tokens referring to the same case can be synchronised. If inside x part of the process is instantiated n times, then there are n child cases x:1yx:n: If for y the same part is also instantiated multiple times, say m; then there are m child cases y:1yy:m: Inside the part which is instantiated multiple times there may again be parallelism and there may be multiple tokens referring to one child case. For a normal AND-join only tokens referring to the same child case can be synchronised. However, at the end of the part which is instantiated multiple times all child cases having the same parent should be synchronised, i.e., case x can only continue if for each child case x:1yx:n the part has been processed. In this synchronisation child cases x:1yx:n and child cases y:1yy:m should be clearly separated. To complicate matters the construct of multiple instances may be nested resulting in childchild cases such as x.5.3 which should be synchronised in the right way. Clearly, a good workow language does not put the burden of keeping track of these instances and synchronising them at the right level on the workow designer. Besides keeping track of identities and synchronising them at the right level, it is important to know how many child cases need to be synchronised. This is of particular relevance if the number of instances can change while the instances are being processed (e.g., a witness which points out

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 251

another witness causing an additional witness statement). In a high-level Petri net this can be handled by introducing a counter keeping track of the number of active instances. If there are no active instances left, the child cases can be synchronised. Clearly, it is also not acceptable to put the burden of modelling such a counter on the workow designer. 3.2. Advanced synchronisation patterns Consider the workow process of booking a business trip. A business trip may involve the booking of ights, the booking of hotels, the booking of a rental car, etc. Suppose that the booking of ights, hotels, and cars can occur in parallel and that each of these elements is optional. This means that one trip may involve only a ight, another trip may involve a ight and a rental car, and it is even possible to have a hotel and a rental car (i.e., no ight). The process of booking each of these elements has a separate description which may be rather complex. Somewhere in the process, these optional ows need to be synchronised, e.g., activities related to payment are only executed after all booking elements (i.e., ight, hotel, and car) have been processed. The problem is that it is not clear which subows need to be synchronised. For a trip not involving a ight, one should not wait for the completion of booking the ight. However, for a business trip involving all three elements, all ows should be synchronised. The situation where there is sometimes no synchronisation (XOR-join), sometimes full synchronisation (AND-join), and sometimes only partial synchronisation (OR-join) needed is referred to as Pattern 7 (synchronising merge). It is interesting to note that the synchronising merge is directly supported by InConcert, Eastman, Domino Workow, and MQSeries Workow. In each of these systems, the designer does not have to specify the type of join; this is automatically handled by the system. In a high-level Petri net each construct is either an AND-join (transition) or an XOR-join (place). Nevertheless, it is possible to model the synchronising merge in various ways. First of all, it is possible to pass information from the split node to

the join node. For example, if the business trip involves a ight and a hotel, the join node is informed that it should only synchronise the ows corresponding to these two elements. This can be done by putting a token in the input place of the synchronisation transition corresponding to the element car rental. Secondly, it is possible to activate each branch using a Boolean token. If the value of the token is true, everything along the branch is executed. If the value is false, the token is passed through the branch but all activities on it are skipped. Thirdly, it is possible to build a completely new scheduler in terms of high-level Petri nets. This scheduler interprets workow processes and uses the following synchronisation rule: Fire a transition t if at least one of the input places of t is marked and from the current marking it is not possible to put more tokens on any of the other input places of t: In this last solution, the problem is lifted to another level. Clearly, none of the three solutions is satisfactory. The workow designer has to add additional logic to the workow design (case 1), has to extend the model to accommodate true and false tokens (case 2), or has to model a scheduler and lift the model to another level (case 3). It is interesting to see how the problem of the synchronising merge has been handled in existing systems and literature. In the context of MQSeries Workow the technique of dead-path elimination is used [6,23]. This means that initially each input arc is in state unevaluated. As long as one of the input arcs is in this state, the activity is not enabled. The state of an input arc is changed to true the moment the preceding activity is executed. However, to avoid deadlocks the input arc is set to false the moment it becomes clear that it will not re. By propagating these false signals, no deadlock is possible and the resulting semantics matches Pattern 7. The solution used in MQSeries Workow is similar to having true and false tokens (case 2 described above). The idea of having true and false tokens to address complex synchronisations was already raised in [35]. However, the bipolar synchronisation schemes presented in [35] are primarily aimed at avoiding constructs such as the synchronising merge, i.e., the nodes are pure AND/XOR-splits/joins and partial

ARTICLE IN PRESS
252 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

synchronisation is not supported nor investigated. In the context of event-driven process chains (EPCs, cf. [36]) the problem of dealing with the synchronising merge also pops up. The EPC model allows for the so-called 3-connectors (i.e., ORjoins which only synchronise the ows that are active). The semantics of these 3-connectors have been often debated [3741]. In [37] the explicit modelling is advocated (case 1). Dehnert and Rittgen [38] advocate the use of a weak correctness notion (relaxed soundness) and an intelligent scheduler (case 3). Langner et al. [39] propose an approach based on Boolean tokens (case 2). Rump [41] proposes an intelligent scheduler to decide whether an 3-connector should synchronise or not (case 3). In [40] three different join semantics are proposed for the 3-connector: (1) wait for all to come (corresponds to the synchronising merge, Pattern 7), (2) wait for rst to come and ignore others (corresponds to the discriminator, Pattern 9), and (3) never wait, execute every time (corresponds to the multi merge, Pattern 8). The extensive literature on the synchronisation problems in EPCs and workow systems illustrates that patterns like the synchronising merge are relevant and far from trivial. 3.3. Cancellation patterns Most workow modelling languages, including high-level nets, have local rules directly relating the input of an activity to output. For most situations such local rules sufce. However, for some events local rules can be quite problematic. Consider for example the processing of Customs declarations. While a Customs declaration is being processed, the person who led the declaration can still supply additional information and notify Customs of changes (e.g., a container was wrecked, and therefore, there will be less cargo than indicated on the rst declaration). These changes may lead to the withdrawal of a case from specic parts of the process or even the whole process. Such cancellations are not as simple as they seem when for example high-level Petri nets are used. The reason is that the change or additional declaration can come at any time (within a given time frame) and may affect running and/or scheduled activities.

Given the local nature of Petri net transitions, such changes are difcult to handle. If it is not known where in the process the tokens reside when the change or additional declaration is received, it is not trivial to remove these tokens. Inhibitor arcs allow for testing whether a place contains a token. However, quite some bookkeeping is required to remove tokens from an arbitrary set of places. Consider for example 10 parallel branches with 10 places each. To remove 10 tokens (one in each parallel branch) one has to consider 1010 possible states. Modelling a vacuum cleaner, i.e., a construct to remove the 10 tokens, is possible but results in a spaghetti-like diagram. Therefore it is difcult to deal with cancellation patterns such as cancel activity (Pattern 19) and cancel case (Pattern 20) and anything in-between. In this section, we have discussed limitations of high-level Petri nets when it comes to (1) patterns involving multiple instances, (2) advanced synchronisation patterns, and (3) cancellation patterns. Again, we would like to stress that high-level Petri nets are able to express such routing patterns. However, the modelling effort is considerable, and although the patterns are needed frequently, the burden of keeping track of things is left to the workow designer.

4. YAWL: yet another workow language In the preceding sections, we have demonstrated that contemporary workow management systems are less suitable and that high-level Petri nets, although providing a good starting point, do not solve all of these problems. This triggered the development of the language named yet another workow language (YAWL). The goal of this joint effort between Eindhoven University of Technology and Queensland University of Technology is to overcome the limitations mentioned in the previous section. The starting point will be Petri nets extended with constructs to address the multiple instances, advanced synchronisation, and cancellation patterns. In this section, we dene the language and provide operational semantics.

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 253

Condition Input condition Output condition

Atomic task Composite task Multiple instances of an atomic task Multiple instances of a composite task

AND-split task XOR-split task OR-split task

AND-join task XOR-join task OR-join task

...
4.1. Denition

remove tokens

Fig. 2. Symbols used in YAWL.

Fig. 2 shows the modelling elements of YAWL. YAWL extends the class of workow nets described in [4,42] with multiple instances, composite tasks, OR-joins, removal of tokens, and directly connected transitions. YAWL is inspired by Petri nets but is not just a macro package built on top of high-level Petri nets: it is a completely new language with independent semantics.1 A workow specication in YAWL is a set of extended workow nets (EWF-nets) which form a hierarchy, i.e., there is a tree-like structure. Tasks2 are either atomic tasks or composite tasks. Each composite task refers to a unique EWF-net at a lower level in the hierarchy. Atomic tasks form the leaves of the tree-like structure. There is one EWFnet without a composite task referring to it. This EWF-net is named the top level workow and forms the root of the tree-like structure.
1 Note that YAWL can be mapped onto high-level Petri nets. However, this mapping is far from trivial and YAWL can also be mapped to any other Turing complete language. Therefore, we would like to emphasise that the semantics of YAWL is independent from high-level Petri nets. 2 Note that in YAWL we use the term task rather than activity to remain consistent with earlier work on workow nets [4,42].

Each EWF-net consists of tasks (either composite or atomic) and conditions which can be interpreted as places. Each EWF-net has one unique input condition and one unique output condition (see Fig. 2). In contrast to Petri nets, it is possible to connect transition-like objects like composite and atomic tasks directly to each other without using a place-like object (i.e., conditions) in-between. For the semantics this construct can be interpreted as a hidden condition, i.e., an implicit condition is added for every direct connection. Each task (either composite or atomic) can have multiple instances as indicated in Fig. 2. It is possible to specify a lower bound and an upper bound for the number of instances created after initiating the task. Moreover, it is possible to indicate that the task terminates the moment a certain threshold of instances has completed. The moment this threshold is reached, all running instances are terminated and the task completes. If no threshold is specied, the task completes once all instances have completed. Finally, there is a fourth parameter indicating whether the number of instances is xed after creating the initial instances. The value of the parameter is static if after creation no instances can be added and dynamic if it is possible to add additional instances while there are still instances being processed. Note that by extending Petri-nets with a construct having these four parameters (lower bound, upper bound, threshold, and static/dynamic), we directly support all patterns involving multiple instances (cf. Section 3.1), and in addition, the discriminator pattern (Pattern 9) under the assumption of multiple instances of the same task. In fact, we also support the more general n-out-of-m join [7]. We adopt the notation described in [4,42] for AND/XOR-splits/joins as shown in Fig. 2. Moreover, we introduce OR-splits and OR-joins corresponding, respectively, to Pattern 6 (multi choice) and Pattern 7 (synchronising merge), cf. Section 3.2. Finally, we introduce a notation to remove tokens from places irrespective of how many tokens there are. As Fig. 2 shows this is denoted by dashed rounded rectangles and lines. The

ARTICLE IN PRESS
254 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

enabling of the task does not depend on the tokens within the dashed area. However, the moment the task executes all tokens in this area are removed. Clearly, this extension is useful for the cancellation patterns, cf. Section 3.3. Independently, this extension was also proposed in [43] for the purpose of modelling dynamic workows. A workow specication is composed of one or more extended workow nets (EWF-nets). Therefore, we rst formalise the notion of an EWF-net. Denition 1 (EWF-net). An extended workow net (EWF-net) N is a tuple C; i; o; T; F ; split; join; rem; nofi such that
* * * * *

C is a set of conditions, iAC is the input condition, oAC is the output condition, T is a set of tasks, F DC\fog T,T C\fig,T T is the ow relation, every node in the graph C,T; F is on a directed path from i to o; split : T-fAND; XOR; ORg species the split behaviour of each task, join : T-fAND; XOR; ORg species the join behaviour of each task, rem : PTQT,C\fi; og species the additional tokens to be removed by emptying a part of the workow, and nofi : TQN Ninf Ninf fdynamic; staticg species the multiplicity of each task (minimum, maximum, threshold for continuation, and dynamic/static creation of instances).

The tuple C; T; F corresponds to a classical Petri net [44] where C (the set of conditions) corresponds to places, T (the set of tasks) corresponds to transitions, and F is the ow relation. There are however two differences. First of all, there are two special conditions/places: i and o: Secondly, the ow relation also allows for direct connections between tasks/transitions. Note that the idea to have a special input condition/place i and a special output condition/place o has been adopted from the class of workow nets [4,42]. The four functions split; join; rem; and nofi specify the properties of each task. The rst two functions

(i.e., split and join) are used to specify whether a task is an AND/OR/XOR-split/join. The third function rem is a partial function specifying which parts of the net should be emptied. Emptying a part of an EWF-net is like removing tokens from a selected set of places.3 Note that the range of rem includes tasks. PT,C\fi; og is the set of all sets including conditions in C\fi; og and tasks in T: Removing tokens from a task corresponds to aborting the execution of that task. However, if a task is a composite task, its removal implies the removal of all tokens it contains.4 nofi is a partial function specifying the attributes related to multiple instances. Whenever we introduce an EWF-net N we assume C; i; o; T; F ; split; join; rem; and nofi dened as N C; i; o; T; F ; split; join; rem; nofi: If ambiguity is possible, we use subscripts, i.e., CN ; iN ; oN ; TN ; FN ; splitN ; joinN ; remN ; and nofiN : We use p1 nofit to refer to the minimal number of instances initiated, p2 nofit to refer to the maximal number of instances initiated, p3 nofit is the threshold value (to terminate before all instances have completed), and p4 nofit indicates whether it is possible to add instances while handling the other instances. For convenience, we extend the functions rem and nofi in the following way. If tAT\domrem; then remt |: If tAT\domnofi; then p1 nofit 1; p2 nofit 1; p3 nofit N; p4 nofit static: This allows us to treat these partial functions as total functions in the remainder (unless we explicitly inspect their domains). Now we dene a workow specication.5 Recall that a workow specication is composed of EWFnets such that they form a tree-like hierarchy.
Note that we did not formalise the token concept in the context of YAWL. This is just a reference to tokens as they are used to represent states in a Petri net. This reference should support readers familiar with Petri nets. Other readers should just think of tokens as objects indicating the partial state of a process. We will formalise the concept of a state in Section 4.3. 4 Note that in an EWF-net there are no composite tasks. Composite tasks are created by relating EWF-nets using the map function as shown in Denition 2. 5 Note that Denition 2 only refers to the control-ow perspective. Therefore, it should not be considered as a full specication of the workow, e.g., data and organisational aspects are missing.
3

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 255

Denition 2. A workow specication S is a tuple Q; top; T } ; map such that

* * * *

[1,10,inf,static]

Q is a set of EWF-nets, topAQ is the top level workow, T } ,NAQ TN is the set of all tasks, 8N1 ;N2 AQ N1 aN2 ) CN1 ,TN1 -CN2 ,TN2 |; i.e., no name clashes, map : T } QQ\ftopg is a surjective injective function which maps each composite task onto an EWF net, and the relation fN1 ; N2 AQ Q j (tAdommapN1 mapN1 t N2 g is a tree.

(a)

register_ witnesses

process_ witness_ statements

archive

[1,inf,inf,dynamic]

(b)

register_ witnesses

process_ witness_ statements [1,10,3,static]

archive

Q is a non-empty set of EWF-nets with a special EWF-net top. Composite tasks are mapped onto EWF-nets such that the set of EWF-nets forms a tree-like structure with top as root node. T } is the set of all tasks. Tasks in the domain of map are composite tasks which are mapped onto EWFnets. Throughout this paper, we will assume that there are no name clashes, e.g., names of conditions differ from names of tasks and there is no overlap in names of conditions and tasks originating from different EWF-nets. If there are name clashes, tasks/conditions are simply renamed. To illustrate the denitions in this section, we apply YAWL to some of the examples used in the previous section. Example (Patterns involving multiple instances). Fig. 3 shows three workow specications dealing with multiple witness statements in parallel. The rst workow specication (a), starts between 1 and 10 instances of the composite task process witness statements after completing the initial task register witnesses. When all instances have completed, task archive is executed. The second workow specication shown in Fig. 3(b), starts an arbitrary number of instances of the composite task and even allows for the creation of new instances. The third workow specication (c) starts between 1 and 10 instances of the composite task process witness statement but nishes if all have completed or at least three have completed. The three examples illustrate that YAWL allows for a direct specication of multiple instances with a priori runtime knowledge (Pattern 14), multiple

(c)

register_ witnesses

process_ witness_ statements

archive

Fig. 3. Some examples illustrating the way YAWL deals with multiple instances. (a) A workow processing between 1 and 10 witness statements without the possibility to add witnesses after registration (Pattern 14), (b) A workow processing an arbitrary number of witnesses with the possibility to add new witnesses on the y (Pattern 15), (c) A workow processing between 1 and 10 witness statements with a threshold of 3 witnesses (extension of Pattern 9).

instances without a priori runtime knowledge (Pattern 15), and the discriminator (Pattern 9). Example (Advanced synchronisation patterns). As explained in Section 3.2, an OR-join can be interpreted in many ways. Fig. 4 shows three possible interpretations using the booking of a business trip as an example. The rst workow specication (a) starts with an OR-split register which enables tasks ight, hotel and/or car. Task pay is executed for each time one of the three tasks (i.e., ight, hotel, and car) completes. This construct corresponds to the multi merge (Pattern 8). The second workow specication shown in Fig. 4(b) is similar but combines the individual payments into one payment. Therefore, it waits until each of the tasks enabled by register completes. Note that if only a ight is booked, there is no synchronisation. However, if the trip contains two or even three elements, task pay is delayed until all have completed. This construct

ARTICLE IN PRESS
256 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275
cancel_activity
flight

register

hotel

pay

(a)

car

activity

(a)
flight

register

hotel

pay

(b)

car

(b)
Fig. 5. Some examples illustrating the way YAWL deals with cancellation patterns. (a) Cancel activity (Pattern 19), (b) Cancel case (Pattern 20).

flight

register

hotel

pay

(c)

car

Fig. 4. Some examples illustrating the way YAWL deals with advanced synchronisation patterns. (a) Task pay is executed each time one of the three preceding tasks completes (Pattern 8), (b) Task pay is executed only once, i.e., after all started tasks have completed (Pattern 7), (c) Task pay is executed only once, i.e., after the rst task has completed (Pattern 9).

corresponds to the synchronising merge (Pattern 7). The third workow specication (c) enables all three tasks (i.e., ight, hotel, and car) but pays after the rst task is completed. After the payment all running tasks are cancelled. Although this construct makes no sense in this context it has been added to illustrate how the discriminator can be supported (Pattern 9) assuming that all running threads are cancelled the moment the rst one completes. Example (Cancellation patterns). Fig. 5 illustrates the way YAWL supports the two cancellation patterns (patterns 19 and 20). The rst workow specication (a) shows the cancel activity pattern

which removes all tokens from the input conditions of task activity. In the second workow specication (b) there is a task removing all tokens and putting a token in the output condition thus realising the Cancel case pattern. The examples given in this section illustrate that YAWL solves many of the problems indicated in Section 3. The table in the appendix shows that YAWL supports 19 of the 20 patterns used to evaluate contemporary workow systems. Implicit termination (i.e., multiple output conditions) is not supported to force the designer to think about termination properties of the workow. It would be fairly easy to extend YAWL with this pattern (simply connect all output conditions with an ORjoin having a new and unique output condition). However, implicit termination also hides design errors because it is not possible to detect deadlocks. Therefore, there is no support for this pattern. To conclude this section, we consider some more examples and discuss the role of constructs involving time. Fig. 6 shows three fragments of a process where as a result of the booking of a ight, a hotel, and/or a car, task pay and/or task cancel are/is executed. The rst workow specication (a)

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 257

starts with an AND-split register which enables tasks ight, hotel and/or car. The latter three tasks can have a positive or a negative outcome. Task pay can only be executed if all three booking tasks have a positive result. Task cancel can only occur if at least one of the booking tasks failed and the others have been completed. Note that in Fig. 6(a) task cancel has to wait even if it is clear that there will never a payment. Moreover, tokens can get stuck in-between the three middle tasks (ight, hotel and car) and pay. The second workow

flight

pay

register

hotel

(a)

car

cancel

flight

pay

register

hotel

(b)

car

cancel

flight

decide

pay

register

hotel

(c)

car

cancel

Fig. 6. Some more examples illustrating the more subtle behaviour of YAWL. (a) Task pay is executed if all three bookings succeed, otherwise cancel is executed after all booking attempts have completed, (b) Task pay is executed if all three bookings succeed, if one of the bookings falls all other bookings are cancelled by task cancel, (c) Task cancel is executed if one of the bookings falls. Task decide will only be executed if no more bookings can succeed, and then decides whether to pay or wait for cancellation.

specication (b) improves this by making task cancel an XOR-join rather than an OR-join and removing all tokens from the relevant part of the process after cancellation. Fig. 6(c) shows an even more sophisticated control ow. Unlike the rst two specications, the tasks ight, hotel and/or car are optional. Therefore, task pay can no longer be represented by an AND-join since not all three input tasks have to be executed. To solve this problem an additional task is introduced: decide. Task decide occurs only if all bookings that were enabled by register have been completed. Cancel may occur if one of the bookings failed. Note that both decide and cancel may be enabled at the same time. If cancel occurs before decide, there is no need to make a decision because one of the results was negative anyway. If decide occurs before cancel, it will decide to pay if all bookings were completed successfully. If one of the bookings failed, it should wait for the cancellation and therefore one of the output arcs of decide is also an input arc. This way the payment subprocess is xed so that it can be cancelled. Fig. 6 does not model any compensation, i.e., to cancel a booking it is often not sufcient to stop the control ow but one needs to initiate additional tasks to compensate previous steps in the process. It should be obvious that such aspects can be modelled by YAWL.6 Thus far, we did not consider the role of time and events. Clearly a workow language should be able to receive events and model timed constructs such as time-outs. Given the expressive power of YAWL we do not need to add explicit routing constructs for catching events and time-outs. We simply offer tasks which can handle these things. For example, we can offer various types of timed tasks, i.e., tasks that do nothing but wait for some specied time, and event tasks, i.e., tasks that do nothing other than waiting for an event to occur. For notational convenience we will label event tasks with the letter E and timed tasks with the letter T. To clarify this consider Fig. 7. In each of the four examples, task pay is an event task
Another approach would be to extend YAWL with transactional features (cf. Section 6). For the moment, we choose not to do so.
6

ARTICLE IN PRESS
258 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

which indicates that it is an automatic task triggered by the occurrence of some event (e.g., the arrival of a message). Task time out is a timed task, i.e., an automatic task that only waits for some time to complete. Since this is simply a task and not part of the YAWL language, there may be several predened tasks offering such a service. The delay (i.e., the time the task takes to complete) may be absolute (Wait until the due date of the

E
pay send_bill

T
time_out

(a)

E
pay send_bill

T
time_out

(b)

E
pay send_bill

T
time_out cancel_order

(c)

E
pay send_bill

T
time_out send_reminder cancel_order

(d)
Fig. 7. Some more examples illustrating that YAWL can deal with constructs involving time and external events without offering dedicated constructs. (a) Task time out is a timed activity, if it nishes before task pay is completed it cancels the payment subprocess, (b) The payment process is only cancelled if the time-out occurs before task pay is started, (c) As in (a) but now the payment cancels the cancellation subprocess, (d) Instead of immediately cancelling the payment process when the time-out completes, a prespecied number of reminders is sent before cancelling the order.

order.) or relative (Wait for 1 week from now.) and may depend on data or external conditions. In all four examples, there is a race between the payment and the time-out which starts after sending the bill. Fig. 7(a) shows the situation where task time out cancels the payment process when it completes. Note that even if the payment is being processed, the top branch may be cancelled. Also note that the condition between send bill and pay is shown explicitly. This way it is possible to clearly indicate that also waiting payments are withdrawn when time out completes. Fig. 7(b) shows the situation where task time out only cancels the payment process when it did not start yet. In Fig. 7(a) and (b) the time-out process does not need to be cancelled after processing the payment because if the time-out occurs after payment there is nothing to cancel. However, if the task time out does not just withdraw tokens but also represents some real work or triggers other tasks to further handle the cancellation process, then task pay needs to cancel the cancellation process as is shown in Fig. 7(c). Task cancel order is a task initiated after the time-out occurred to compensate the effect of not receiving the payment within the prespecied time. When task pay completes it cancels the whole lower branch. Note that time out has an explicit input condition to indicate that if, for some reason, the task was not started when the payment is completed, the cancellation process is still cancelled properly. Fig. 7(d) shows an extension of (c) where before cancellation a couple of reminders are sent to the customer. Task send reminder is an XOR-split which, based on the number of reminders already sent, decides to go for another reminder or cancel the payment process. Note that this way it is possible to model things like: If the customer does not pay after one week, a reminder is sent. This is repeated four times or until the customer pays. If the customer did not pay after four reminders, the order is cancelled. The four examples shown in Fig. 7 demonstrate that YAWL does not need specic constructs for patterns involving time and/or events. They also illustrate the ability of YAWL to specify complex workow processes with challenging control-ow requirements.

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 259

4.2. Notation Before describing the formal semantics of YAWL, we introduce some useful notations. To navigate through an EWF-net it is useful to dene the pre and post-set of a node (i.e., either a condition or task). To simplify things we add an implicit condition ct1 ;t2 between two tasks t1 ; t2 if there is a direct connection from t1 to t2 : For this purpose we dene the extended set of conditions C ext and the extended ow relation F ext : Denition 3. Let N C; i; o; T; F ; split; join; rem; nofi be an EWF-net. C ext C,fct1 ;t2 j t1 ; t2 AF -T Tg and F ext F \T T, ft1 ; ct1 ; t2 j t1 ; t2 A F -T Tg , fct1 ; t2 ; t2 j t1 ; t2 AF -T Tg: Moreover, auxiliary functions  ;  : C ext ,T-PC ext ,T are dened that assign to each node its pre- and post-set, respectively. For any node xAC ext ,T; x fy j y; xAF ext g and x fy j x; yAF ext g: Note that the preset and postset functions depend on the context, i.e., the EWF-net the function applies to. Denition 4. Whenever we introduce a workow specication S Q; top; T } ; map; we assume T A ; T C ; T SI ; T MI ; C } to be dened as follows:
*

A workow specication denes a tree-like structure. To navigate through this structure we dene the function unfold: Given a set of nodes (i.e., tasks and conditions), unfold returns these nodes and all child nodes. Denition 5. Let S Q; top; T } ; map be a workow specication. We dene the function unfold : PT } ,C } -PT } ,C } as follows. For X DT } ,C } : unfoldX 8 | > > > > > fxg,unfoldX \fxg > < > > > fxg,unfoldX \fxg > > > : ext ,Tmapx ,Cmapx if X |; if xAX C } ,T A ; if xAX -T C :

T A ftAT } j tedommapg is the set of atomic tasks, T C ftAT } j tAdommapg is the set of composite tasks, T SI ftAT } j 8NAQ tedomnofiN g is the set of single instance tasks, T MI ftAT } j (NAQ tAdomnofiN g is the set of (potentially) multiple instance tasks, and S ext C } NAQ CN is the extended set of all conditions.

Note that the unfoldX returns each node in X and all nodes contained by the nodes in X : For atomic tasks and conditions, no unfolding is needed. For composite tasks, all nodes contained by these tasks are included in the result, i.e., unfoldX recursively traverses all composite tasks in X : Fig. 8 shows an example of a workow specication to illustrate the notations. T A fA; B; E; F ; G; H; I; Jg is the set of atomic tasks and T C fC; Dg is the set of composite tasks. T SI fA; B; C; E; F ; G; H; I; Jg and T MI fDg; i.e., D is the only task (potentially) having multiple instances. Apart from input and output conditions, there are only two explicit conditions (c1 and c2 ). All other conditions in the set C } are implicit, e.g., cA;B is an implicit condition corresponding to the arc connecting A and B: unfoldfB; c2 ; Dg fB; c2 ; D; i2 ; I; J; o2 ; cI;J g; i.e., if D is unfolded and all tasks and conditions (including the implicit ones) contained by D are added. 4.3. Semantics Denition 2 denes, in mathematical terms, the syntax of a workow specication. Based on this denition it is straightforward to give a concrete workow language, e.g. in terms of

If ambiguity is possible, we use subscripts, i.e., } A C SI MI TS ; TS ; TS ; TS ; and CS : Within the context of a single workow specication we will omit these subscripts. Moreover, since the domains of the functions splitN ; joinN ; remN ; and nofiN do not overlap for different NAQ we can omit the subscripts.

ARTICLE IN PRESS
260 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

B itop A D otop

c1

c2

F i1 E G H o1

i2

o2

Fig. 8. An example.

XML. However, Denition 2 does not give any semantics. Thus far we have only given intuitive descriptions of the dynamic behaviour of a workow specication S: In the remainder of this section, we will provide a formal semantics. We will do this in three steps. First, we introduce some preliminaries (bags and identiers). Then we dene the state space corresponding to a workow specication S: Finally, we specify the state transitions possible.

4.3.1. Preliminaries The denition of the state space corresponding to a workow specication is inspired by the concept of tokens in coloured Petri nets. The state space consists of a collection of tokens having a value. Since, we abstract from data in this paper, it sufces that each token has an identity. To deal with multiple tokens in the same place having the same identity, we need to resort to bags. Moreover, we need to structure the set of case identiers to relate child instances to parent instances. The latter is needed to deal with multiple instances.

In this paper, bags are dened as nite multi-sets of elements from some alphabet A: A bag over alphabet A can be considered as a function from A to the natural numbers N such that only a nite number of elements from A are assigned a nonzero function value. For some bag X over alphabet A and aAA; X a denotes the number of occurrences of a in X ; often called the cardinality of a in X : The set of all bags over A is denoted BA: For the explicit enumeration of a bag, a notation similar to the notation for sets is used, but using square brackets instead of curly brackets and using superscripts to denote the cardinality of the elements. For example, a2 ; b; c3 denotes the bag with two elements a; one b; and three elements c; the bag a2 j Pa contains two elements a for every a such that Pa holds, where P is some predicate on symbols of the alphabet under consideration. To denote individual elements of a bag, the same symbol A is used as for sets: For any bag X over alphabet A and element aAA; aAX if and only if X a > 0: The sum of two bags X and Y ; denoted X 2Y ; is dened as an j aAA4n X a Y a: The difference of X and Y ; denoted X Y ; is

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 261

dened as an j aAA4n maxX a Y a; 0: P sizeX aAA X a is the size of the bag. The binding of sum and difference is left-associative. The restriction of X to some domain DDA; denoted X " is dened as aX a j aAD: RestricjD; tion binds stronger than sum and difference. The notion of subbags is dened as expected: Bag X is a subbag of Y ; denoted X DY ; if and only if, for all aAA; X apY a: X CY ; if and only if, X DY and for some aAA; X aoY a: Note that any nite set of elements from A also denotes a unique bag over A; namely the function yielding 1 for every element in the set and 0 otherwise. Therefore, nite sets can also be used as bags. If X is a bag over A and Y is a nite subset of A; then X Y ; X 2Y ; Y X ; and Y 2X yield bags over A: Moreover, X DY and Y DX are dened in a straightforward manner. Less straightforward is the way we deal with case identiers. Each case (i.e., workow instance) needs to have a unique identier. Moreover, parts of the process may be instantiated multiple times. These sub-instances should again have unique identiers, etc. To handle these issues, we assume an innite set I extended with parentchild relationships. Denition 6. I is an innite set of case identiers. We dene the following functions on I:
*

Each identier has an innite number of child instances. These child instances are ordered and non-overlapping, i.e., childi; n is the nth child of i and for any i; jAI and n; mAN: childi; n childj; m implies i j and n m: Based on child the functions children and children provide the set of direct children and the set of all descendants, respectively. Note that iAchildren i and iechildreni for any iAI: It is possible to construct I and the corresponding functions as is shown in Chapter 11 of [34]. An example of an encoding of I is I N (sequences of natural numbers) and childi; n i:n where iAN and nAN\f0g: 62.231.77 is an element of such a set I; child62:231:77; 9 62:231:77:9; children62:231:77 f62:231:77:1; 62:231:77:2; yg; and children 62:231:77 f62:231:77; 62:231:77:1; 62:231:77:2; y; 62:231:77:1:1; 62:231:77:1:2; yg: Note that such encoding is similar to IP addresses on the Internet. Using the notation for bags and the denition of I we can dene the state space of a workow specication. 4.3.2. State space We will use the set of case identiers I to distinguish cases. Moreover, because of parallelism, a single case can be in multiple conditions and/or tasks. Therefore, we represent a state as a bag of objects where each object is represented by a location and an identity. Readers familiar with (coloured) Petri nets can think of these objects as (coloured) tokens. Readers not familiar with Petri nets can think of these objects as substates or threads of control. In the remainder, we will use the term token.8 For reasons of simplicity we will assume that each task has four states: exect (for a task (instance) being executed), mi at (for a task (instance) being active), mi et (for a task being entered, i.e., task instances which have been created but not yet being executed), and mi ct (for a task (instance) that has completed). The states mi at ; mi et ; and mi ct have been added to deal with multiple instances. If there would not be
In spite of the use of Petri-net terminology, it is important to note that we do not use standard Petri-net semantics, e.g., the ring rule is modied considerably.
8

child : I N\f0g-I: childi; n is the nth child of i: children : I-PI: jAchildreni if and only if j is a child of i; i.e., childreni fchildi; n j nAN\f0gg: children : I-PI is the reexive transitive closure of children, i.e., children i ,nAN childrenn i; where children0 i fig and childrenn1 i childrenchildrenn i:7

Function child is dened such that for any i; jAI and n; mAN: childi; n childj; m implies i j and n m:

Note that we have applied the function children to a set of identiers rather than a single element. This extended use, however, is straightforward.

ARTICLE IN PRESS
262 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

multiple instances, the state exect would have been sufcient. State mi et keeps track of task instances that have been created but still are waiting to be executed. State mi ct keeps track of task instances that have been completed. Task instances move from mi et ; to exect ; to mi ct : For any token residing in any of these three states there is a corresponding token in state mi at to keep track of all instances. Denition 7. A workow state s of a specication S Q; top; T } ; map is a multiset over Q} I where Q} C } ,,tAT } fexect ; mi at ; mi et ; mi ct g; i.e., sABQ} I: A workow state s is a bag of tokens where each token is represented by a pair consisting of a condition from Q} and an identier from I; i.e., sABQ} I: For a token x; iAs; x denotes the location of the token and i denotes the identity of the token. Location x is either (1) an implicit or explicit condition (xAQ} ) or (2) a task state of some task tAT } (xAfexect ; mi at ; mi et ; mi ct g). When dening the state transitions it will become clear that reachable workow states will satisfy the invariant that the number of tokens in mi at equals the sum of tokens in exect ; mi et ; and mi ct ; i.e., the number of active instances equals the number of executing, entered, and completed instances. Note that in the workow state we do not distinguish between atomic and composite tasks. We could have omitted task states for composite tasks. For reasons of simplicity, we did not do so. For similar reasons, we do not distinguish between tasks having a single instance and tasks (potentially) having multiple instances. We could have omitted mi at ; mi et ; and mi ct for each tAT SI : However, this would have complicated things without changing the semantics. Instead, we assume that for tAT SI : p1 nofit 1; p2 nofit 1; p3 nofit N; p4 nofit static: To query workow states (or parts of workow states), we dene three projection functions. Denition 8. Let sABQ} I be a workow state and xAQ} : ids fi j y; iAsg; ids; x

entert

mi_at

exitt

add mi_et exect startt completet mi_ct

Fig. 9. Illustration of the semantics of an atomic task t:

P in j iAI4nAN4n x;iAs sx; i; and P n } y j yAQ 4nAN4n iAI j y;iAs sy; i:

qs

ids returns the set of all identities appearing in state s: ids; x returns a bag of identities appearing in location x in state s: qs returns a bag of locations marked in state s by some token. 4.3.3. State transitions To complete the semantics of a workow specication, we need to specify all possible state transitions. The state space combined with the transition relation denes a transition system. Fig. 9 shows all possible transitions for an atomic task t using a Petri-net-like notation.9 There are ve types of transitions: enter, start, complete, exit, and add. Each of these transitions is relative to some task t: Fig. 9 also shows the four task states mi at ; exect ; mi et ; and mi ct : The decomposition of an atomic task into ve transitions is independent of the hierarchical structure of the model. Therefore, Fig. 9 should not be confused with the YAWL diagrams shown before. It should only be considered as a roadmap for reading the subsequent denitions. Transition enter occurs when it is time to execute task t: If joint XOR; it sufces if one
Although some of the terminology (e.g. token and transition) is borrowed from Petri nets, the diagram should not be read as a normal Petri net, e.g., enter produces a variable number of tokens and exit consumes a variable number of tokens as indicated by the thick arcs.
9

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 263

of the conditions in the preset of t holds a token. If joint AND; each of the input conditions needs to hold a token corresponding to the same case/ instance (i.e., all input tokens need to have the same identity). If joint OR; the number of input tokens is in-between the number of tokens needed for the XOR- and AND-join. (We will come back to this later.) As in an ordinary Petri net, transition enter removes the tokens that enabled the task. The number of tokens produced depends on the number of instances that needs to be created. If tAT SI ; two tokens are produced: one for mi at and one for mi et : If more instances need to be created, more tokens are produced. However, the number of tokens produced for mi at always matches the number of tokens produced for mi et : Similarly, the identities match. Transition start occurs when the execution of the task starts. This transition is enabled for each token in mi et : When this transition res it consumes a token from mi et and produces a token for exect : Transition complete occurs when the execution is completed. When this transition res it consumes a token from exect and produces a token for mi ct : Transition exit occurs when all instances corresponding to the same parent have completed. This transition is not like an ordinary Petri-net transition in the sense that the number of tokens consumed depends on the number of instances created. In addition, this transition removes tokens from selected parts of the specication as indicated by remt: The number of tokens produced depends on splitt: Transition add is only relevant for tasks t with tAT MI and p4 nofit dynamic: As long as the maximum number is not reached, the transition can create new instances by adding a token to mi et : The transition removes all tokens having the same parent from mi at and returns these tokens to mi at including an additional token corresponding to the new child instance. This may seem to be a complicated way of adding a single token. However, it is done this way to make sure that the token gets the right identier. Fig. 9 only considers atomic tasks. If t is a composite task, there is a corresponding subnet

entert

mi_at

exitt

add mi_et exect startt completet mi_ct

map(t)

imap(t)

omap(t)

Fig. 10. Illustration of the semantics of a composite task t:

mapt: Fig. 10 illustrates how the composite task t is connected through the input and output conditions (imapt and omapt ) to the subnet mapt: At the semantical level each composite task is decomposed into the structure shown in Fig. 10. If tAT C ; then start produces an additional token for the input condition of the corresponding subnet. Moreover, if tAT C ; then complete can only re if the output condition of the corresponding subnet holds a token with the right identity (i.e., the identities of the tokens in exect and omapt match). Again, we would like to stress that Fig. 10 is not a YAWL model, it is only used to illustrate the semantics which will be dened in this section. Workow designers using YAWL do not need to see this internal behaviour. Moreover, it is important to note that although YAWL borrows some of the concepts of Petri nets it is not some extension built on top of high-level Petri nets. It is a completely new language having independent semantics as will be shown in the remainder. The following denitions formalise the set of transitions possible in a given state by specifying the so-called binding relations. The rst binding relation is bindingenter : bindingenter t; i; c; p; s is a Boolean expression which evaluates to true if enter can occur for task t; case/instance i; in state s; while consuming the bag of tokens c and producing the bag of tokens p:

ARTICLE IN PRESS
264 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

Denition 9. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingenter t; i; c; p; s yields true if and only if an nAN exists such that all of the following conditions hold:
*

Denition 10. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingstart t; i; c; p; s yields true if and only if all of the following conditions hold:
*

Tokens to be consumed are present in the state cDs; Tokens are consumed from the input conditions of the task involved and at most one token can be consumed from each condition of the preset qcDt; n tokens are created both for the active task state and the entered task state of the task involved p mi at ; j j j childi; k41pkpn2 mi et ; j j j childi; k41pkpn;

Tokens to be consumed are present in the state cDs;

Just one token is consumed which was in the entered task state of the task involved c mi et ; i;

* *

A token is produced for the input condition of the corresponding decomposition (if existing) and a token is produced for the executing task state of the task involved p exect ; i2imapt ; i j tAT C :

The number n of tokens created is not less than the lower bound and not more than the upper bound specied for the task involved p1 nofitpnpp2 nofit; Tokens to be produced were not already in the state, i.e., a task is instantiated only once for a given identier s-p |; Tokens to be consumed all refer to the same identity fig idc;
*

The counterpart of bindingstart is bindingcomplete : Denition 11. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingcomplete t; i; c; p; s yields true if and only if all of the following conditions hold:
*

Tokens to be consumed are present in the state: cDs; For a token to be able to complete, it has to be in the executing task state of the task involved and its decomposition (if present) needs to be nished c exect ; i2omapt ; i j tAT C ;

For AND-join behaviour, all input conditions need to have tokens joint AND ) qc t; For OR-join behaviour, at least one input condition needs to have tokens joint OR ) qca|; For XOR-join behaviour, one token from one input condition is consumed joint XOR ) qc is a singleton:

Completing implies producing a token for the completed task state of the task involved p mi ct ; i:

Similarly, the other binding relations are given and bindingt; i; c; p; s is the overall binding relation. The next binding relation is bindingstart :

Next, we dene the binding relation for the exit transition. This is done in two steps. bindingexit t; i; c; p; s (Denition 12) does not take the removal of additional tokens into account, i.e., remt is ignored. However, bindingrem t; i; c; p; s exit

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 265

(Denition 13) extends bindingexit t; i; c; p; s to remove these additional tokens. Denition 12. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingexit t; i; c; p; s yields true if and only if all of the following conditions hold:
*

For XOR-split behaviour, a token is produced for exactly one of the output conditions of the task involved splitt XOR ) qp is a singleton:

Tokens to be consumed are present in the state cDs; Tokens are produced only for output conditions of the task involved and at most one token can be produced for each condition in the postset qpDt; Tokens to be consumed are children of the instance considered, and they occur in both the active task state and the completed task state of the task involved (and tokens in other task states are not affected) cD2fmi at ; j; mi ct ; j j jAchildrenig; If a token is consumed from the active task state then its corresponding token is removed from the completed task state and vice versa idc; mi at idc; mi ct ; All children of the identier involved have completed or at least as many as required by the threshold of the task involved have completed ids c; mi at -childreni |3 sizeidc; mi ct Xp3 nofit;

Denition 13. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingrem t; i; c; p; s yields exit true if and only if a c0 ABQ} I exists with bindingexit t; i; c0 ; p; s such that c c0 2x; jAs c0 j jAchildren i4 (t0 Aunfoldremt,ftg-T } xAfexect0 ; mi at0 ; mi et0 ; mi ct0 g 3xAunfoldremt,ftg-C } : I.e., from all conditions part of task t (and its descendants, if it has a decomposition) and part of its removal set (and descendants of elements thereof) tokens are removed that correspond to children of identier i: Note that in case the threshold for continuation was reached, executing the exit part of the task involved implies cancellation of all child instances (if existing) which have not yet completed. Denition 14. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingadd t; i; c; p; s yields true if and only if an nAN exists such that all of the following conditions hold:
*

Tokens to be consumed are present in the state cDs;

The only tokens produced are those with the identier involved fig idp; For AND-split behaviour, tokens are produced for all output conditions of the task involved splitt AND ) qp t; For OR-split behaviour, tokens are produced for some of the output conditions of the task involved

The tokens to be consumed are children of the identier involved present in the active task state of the task involved c mi at ; j j j childi; k41pkpn;

All children of the identier involved present in the active task state of the task involved are consumed ids c; mi at -childreni |;

splitt OR ) qpa|;

It is still possible to create an extra token without violating the upper bound specied for

ARTICLE IN PRESS
266 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

the task involved nop2 nofit;

*

The task involved should allow for the creation of extra tokens while handling the other tokens p4 nofit dynamic; An extra token is added to the active task state and to the entered task state of the task involved p c2mi at ; childi; n 1; mi et ; childi; n 1:

illustration purposes: The transition rules are quite different from the standard ring rule in a (coloured) Petri net. Using bindingt; i; c; p; s we can dene a partial transition relation excluding OR-joins. Denition 16. Let S Q; top; T } ; map be a specication and s1 and s2 two workow states of S: s1 :s2 if and only if there are tAT } ; iAI; c; pABQ} I such that bindingt; i; c; p; s1 and s2 s1 c2p: : denes a partial transition relation on the states of workow specication. The reexive transitive closure of : is denoted : and Rpartial s fs0 ABQ} I j s : s0 g is the set of states reachable from state s without enabling any OR-joins (all in the context of some workow specication). Thus far, we excluded OR-joins from the transition relation because the OR-join implies a partial synchronisation. Whether there are enough tokens for such partial synchronisation cannot be decided locally (see Section 3.2). The required functionality is specied by Pattern 7 (Synchronising merge, [7,9]) and can be described as follows: an OR-join requires at least one token and waits until it is not possible to add any relevant tokens to the set of input conditions. This informal requirement is formalised in the following denition. Denition 17. Let S Q; top; T } ; map be a specication and s1 and s2 two workow states of S: s1 Os2 if and only if s1 :s2 or each of the following conditions is satised:
*

Note that n tokens are removed from mi at and n 1 are returned to this task state. This way the result is one additional token in the active task state. The same token is added to the entered task state mi et : Now we can dene the binding relation bindingt; i; c; p; s: Note that this relation excludes OR-joins. OR-joins will be incorporated later. Denition 15. Let S Q; top; T } ; map be a specication and tAT } ; iAI; c; p; sABQ} I: The Boolean function bindingt; i; c; p; s yields true if and only if any of the following conditions holds:
*

The enter part of a task is enabled, but the task does not have OR-join behaviour bindingenter t; i; c; p; s4jointaOR; The start part of a task is enabled bindingstart t; i; c; p; s; The complete part of a task is enabled bindingcomplete t; i; c; p; s; The exit part of a task is enabled bindingrem t; i; c; p; s; exit The add part of a task is enabled bindingadd t; i; c; p; s:

There are tAT } ; iAI; c; pABQ} I such that joint OR; bindingenter t; i; c; p; s1 ; and s2 s1 c2p: For each sARpartial s1 ; there is no c0 ABQ} I such that bindingenter t; i; c0 ; p; s and c0 > c:

Based on the explanations given before, the denitions of most bindings are straightforward. As indicated before, bindingrem t; i; c; p; s extends exit bindingexit t; i; c; p; s and the overall binding relation bindingt; i; c; p; s excludes OR-joins. It is important to note that Fig. 10 is just added for

O is the transition relation which also takes OR-joins into account. O includes all state transitions in : and adds transitions of type enter if the number of consumed tokens cannot be increased by postponing the occurrence of the ORjoin.

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 267

The reexive transitive closure of O is denoted O and Rs fs0 ABQ} I j s O s0 g is the set of states reachable from state s: If ambiguity is possible, we will add subscripts, i.e., OS ; O S ; and RS : The state space BQ} I and transition relaS tion OS dene a transition system BQ} S I; OS for S: It is also possible to dene a labelled transition system by taking the bindings into account. For example, label a transition corresponding to bindingstart t; i; c; p; s as startt;i : Such a labelled transition system can be augmented with different notions of equivalence, e.g., branching bisimilarity [45]. It is also possible to abstract from certain actions by renaming them to t (silent action). For example, it may be useful to abstract from exitt in the semantics. The choice of a good equivalence relation for workow management is a topic in itself [13]. Therefore, we restrict ourselves to giving the transition system BQ} S I; OS : Interesting initial states for BQ} I; OS are S itop ; i j iAX where X DI such that for all i; jAX : children i-children j | if iaj: These initial states correspond to states with a number of cases marking the initial condition for the top-level workow. The requirement on X is needed to avoid interacting cases, i.e., tokens of different cases should not get mixed.

S has no dead tasks iff for any tAT there is a state sARitop ; i such that exect Aqs: S has proper completion iff for any state sARitop ; i: if sXotop ; i; then s otop ; i: S is sound iff S has the option to complete, has no dead tasks, and has proper completion. The denition of the option to complete, absence of dead tasks, proper completion, and soundness are straightforward translations of the properties given in [4,42] for WF-nets to workow specications. The four properties can be extended to initial states with n cases in the initial state. However, for interesting initial states this makes no difference. Let sX itop ; i j iAX where X DI such that X a| and for all i; jAX : children i-children j | if iaj: S has the option to complete iff for any state sARsX : otop ; j j jAX ARs: S has no dead tasks iff for any tAT there is a state sARsX such that exect Aqs: S has proper completion iff for any state sARsX : if sXotop ; j j jAX ; then s otop ; j j jAX : One could also dene a notion of n-soundness where n sizeX : However, a workow specication S is sound if and only if it is nsound. This property can be veried using the argument that tokens of different cases cannot get mixed when starting in sX : The notion of soundness for workow specication can also be used to dene soundness of EWFnets. Denition 19. Let N C; i; o; T; F ; split; join; rem; nofi be an EWF-net. S fNg; N; T; | is the corresponding workow specication consisting of just this EWF-net. N has the option to complete, has no dead tasks, and has proper completion if and only if S has the option to complete, has no dead tasks, and has proper completion, respectively. N is sound if and only if S is sound. In this section, we have dened the YAWL language and its semantics. In Section 4.1, we dened the syntax of a workow specication in mathematical terms. In Section 4.3, we dened the semantics of a workow specication by providing a transition system. Finally, in Section 4.4, we

4.4. Soundness Denition 17 species the semantics of any workow specication as dened in Denition 2. However, some workows may be less desirable. For example, it is possible to specify workows that may deadlock, are unable to terminate, or have dead parts. Therefore, we dene a notion of soundness. For the denition of soundness we assume an initial state with one case marking the initial condition of the top-level workow. Denition 18. Let S Q; top; T } ; map be a specication with initial state itop ; i for some iAI: S has the option to complete iff for any state sARitop ; i: otop ; iARs:

ARTICLE IN PRESS
268 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

dened soundness for both workow specications and EWF-nets as the basic notion of correctness. Although YAWL is based on Petri nets, the language really extends (coloured) Petri nets as was shown in this section. The advantages of YAWL over Petri nets are that it is easy to deal with patterns involving multiple instances, advanced synchronisation patterns, and cancellation patterns as was shown in this section.

5. Analysis YAWL is more suitable than (high-level) Petri nets in the sense that there is direct support for several patterns that are difcult to deal with using (coloured) Petri nets. Petri nets are known for the wide variety of available analysis techniques and tools. Therefore, it is interesting to see which results can be transferred from Petri nets to YAWL. In this section, we will not address this question in detail. Instead, we give an interesting compositionality result. A workow specication S is composed of a set of EWF-nets Q and soundness has been dened for both workow specications and EWF-nets. Therefore, it is interesting to investigate whether soundness of each EWF-net in Q implies soundness of the workow specication S: The following theorem shows that this is indeed the case, as long as we do not allow nested ORjoins. Theorem 1. Let S Q; top; T } ; map be a specication without OR-joins (i.e., jointaOR for any tAT } ). S is sound if each NAQ is sound. Proof. Let each NAQ be sound. We need to prove that S is sound by showing that S has the option to complete, has no dead tasks, and has proper completion. To do this, we use the fact that relation H fN1 ; N2 AQ Q j (tAdommapN1 mapN1 t N2 g is a tree. For each NAQ: Nk fN 0 AQ j N; N 0 AHg; i.e., Nk is the set of EWF-nets having N as a direct parent node in the tree structure. Nk fN 0 AQ j N; N 0 AH g is the transitive variant, i.e., all descendents of N including N:

For each NAQ; we dene SN as the specication composed of EWF-nets Nk and top element N: It is easy to see that this is a specication satisfying all the requirements stated in Denition 2. Using induction we will show that SN is sound. First, we consider all leaf nodes. For each leaf node N: SN is sound because S fNg; N; T; | and N is sound (cf. Denition 19). Next, we consider all nodes whose direct descendents have been shown to be sound, i.e., consider nodes N such that for each N 0 ANk: SN 0 is proven to be sound. In the remainder of this proof, we show that for such an N; SN is sound. SN has the option to complete because the only way to block the top level net is through blocking a completet transition for some composite task t mapped onto some EWF-net N 0 : However, this is not possible because SN 0 is sound. Moreover, there cannot be any tokens left in SN 0 because the moment a token is put onto oN 0 ; SN 0 has no other tokens corresponding to the same instance. SN has no dead tasks because each task t in N can be enabled. As a result any of the tasks in SN 0 can be activated if t is mapped onto some EWF-net N 0 : SN has proper completion for similar reasons as it has the option to complete. As a result SN is sound because SN has the option to complete, has no dead tasks, and has proper completion. Note that the requirement that there are no OR-joins is essential here, because the presence of an OR-join at the lower level can change the behaviour of an OR-join at the higher level. The induction step can be repeated until N top and thus we can prove that Stop S is sound. & This theorem shows that the correctness of a YAWL workow specication can be veried in a compositional way as long as there are no ORjoins. Clearly, multiple OR-joins can destroy compositionality because the presence of an ORjoin at the lower level can change the behaviour of an OR-join at the higher level. : denes a partial transition relation excluding OR-joins. An interesting question would be if : could be modied such that Theorem 1 also holds for specication with multiple OR-joins, e.g., only exclude

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 269

OR-joins which are in a cycle. This is not trivial as is shown in [46]. Theorem 1 has been included in this paper to demonstrate that the formal semantics of YAWL allow for the development of analysis methods and supporting theories. The goal is to transfer as many results from the Petri-net domain to YAWL as possible. Given the expressiveness of YAWL, these results are directly applicable to a range of existing workow languages. For example, we expect that for restricted YAWL specications we can use invariants comparable to place and transition invariants in Petri nets [16,44,47].

6. Related work In this section, some workow languages used in the literature will be analysed in terms of their support for the patterns as presented in [7]. The aim is to provide some insight into the relative strength of YAWL with respect to these approaches in terms of support for the control ow perspective. The results are summarised in Table 1. It should be noted that a pattern-based analysis of 13 commercial workow offerings can be found in [7]. For an analysis of UML activity diagrams 1.4 in terms of (some of) the patterns, we refer to [48]. BPEL4WS, a proposed standard for web service composition, has been analysed in [49], while another such proposed standard, BPML, has been analysed in [50]. WfMCs XPDL [51] is assessed in terms of the patterns in the appendix. Note that the appendix also provides a general explanation of how to correctly interpret the various ratings. The approach described in ADEPTex [52] takes structured models as a starting point, hence splits and joins can be matched, and loops have a unique entry and a unique exit (hence arbitrary loops are not supported, and neither is implicit termination). In this structured context, the discriminator is supported through parallel branching with nal selection. The deferred choice is supported as decisions may be made by users in which case all possible options are offered and once one option is selected, the other options are withdrawn. One can use soft synchronisa-

tion to capture the synchronising merge. It should be noted that the corresponding edge and the edge corresponding to strict synchronisation can be used between different parallel branches, hence the approach goes beyond approaches that are fully structured. Apart from the deferred choice, other state-based patterns are not supported. In addition, there is no support for cancellation and multiple active instances of the same activity within the same case. Apart from the basic control ow patterns, OPENow [53] supports the multi-choice and multiple instances with a priori design time knowledge (note though that this pattern always receives a + rating if parallelism/synchronisation is supported). Interestingly, it also supports the notion of recursive decomposition: Genesis tasks can also be utilised to specify workow applications that contain recursive executions, that is a task structure whose execution will potentially cause the execution of its own structure as one of its sub-tasks. [53]. There is no pattern corresponding to recursive decomposition. EPCs [36] allow for arbitrary cycles, implicit termination, multi-choice, and the synchronising merge, but do not support multiple active instances of the same activity within the same case, the discriminator, the multi-merge, cancellation, and the state-based patterns. One could argue that the multi-choice is not supported because the ORsplit connector typically does not have an explicit specication. However, this also holds for some of the other constructs and is directly caused by the fact that it is typically used in an informal manner. As indicated in the discussion in Section 3.2 the semantics of the OR-join is also under-specied, and thus the support for the synchronising merge may also be debated. In the Mentor project [5456] state and activity charts are used for workow specication. These languages were proposed in the context of the STATEMATE system described in [62]. The evaluation given here is based on this reference. Since state charts are dened in terms of classical automata, the notion of being in a state more than once at a given point in time (which would correspond to having multiple tokens in the same place in a Petri net) is not supported. As a result,

ARTICLE IN PRESS
270 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275

Table 1 Main results of evaluating workow languages used in the literature using the workow patterns [7,9]
Pattern Product ADEPTflex [52] OPENow [53] EPC [36] Mentor [5456] CTR [57,58] Meteor [22] Mobile [8] WASA [59] Exotica [60] CFs [61] 1 (seq) 2 (par-spl) 3 (synch) 4 (ex-ch) 5 (simple-m) 6 (m-choice) 7 (sync-m) 8 (multi-m) 9 (disc) 10 (arb-c) 11 (impl-t) 12 (mi-no-s) 13 (mi-dt) 14 (mi-rt) 15 (mi-no) 16 (def-c) 17 (int-par) 18 (milest) 19 (can-a) 20 (can-c) + + + + + i ii ii + + + + + + + + i i + + + + + + + + + + + + + + + + + + + +/ + + + + + + + + + + + + + + + + + + +/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + iii + + + + + + +

(i) Support for this pattern could not be deduced from the paper, (ii) Only in a structured context, (iii) If the Bundle concept of FlowMark is used this should change into a +.

there is inherently no support for multiple active instances of the same activity within the same case, nor for the multi-merge. Also, there is no support for arbitrary cycles. Specically, when a transition crosses the boundary of a concurrent region in a state chart, the semantics is that all the states in that region and in its sibling regions are exited if this transition is taken. Hence it is not possible to express arbitrary cycles crossing concurrent regions with the same semantics as in YAWL. State charts must have a single nal state hence there is no support for implicit termination. Additionally, there are no constructs corresponding to the multichoice, the synchronising merge, and interleaved parallel routing. Finally, the milestone pattern receives a +/ as in the condition part of an ECA rule one can test whether the execution is in a given state through the predicate in. It should be remarked that state charts offer an operator called History, which allows resumption of the state of execution that existed prior to a cancellation event.

This feature does not have a corresponding pattern. Concurrent Transaction Logic [63] (CTR) is used in [57,58] for workow specication. Apart from the basic control ow patterns, CTR supports the multi-choice, the synchronising merge, multiple instances with a priori design time knowledge, and the deferred choice. CTR goes beyond fully structured approaches when it comes to parallel structures as messaging can be used to achieve synchronisation between parallel branches (see [63, Example 2.2]). The evaluations of Meteor and Mobile are taken from [7]. Note that in [7] it is remarked that Mobile is extensible and that hence the evaluation restricts itself to the standard functionality offered. In terms of support for the workow patterns, WASA [59,64,65] corresponds to MQ/Series Workow (which is evaluated in [7]). Contrary to MQ/Series Workow, iteration in WASA is supported through recursion: ... a workow

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 271

schema i can appear as a sub-workow schema of itself ... [59] (page 50). As stated before, there is no pattern corresponding to this feature. Note that the focus of WASA is not on expressiveness but on supporting workow change. The Exotica Research Project is described in [60] where it is stated that ... we have focused on a particular commercial product, FlowMark, IBMs workow product .... As remarked in [7], the Bundle construct is supported by FlowMark, but not by MQSeries/Workow version 3.1. If this feature was used in Exotica, this would mean that in Table 1, support for multiple instances with a priori runtime knowledge, would change from a to a +. The WASA and Exotica research projects illustrate that several research prototypes have been inuenced by the IBM product FlowMark and its successors MQSeries Workow and WebSphere MQ Workow. See [6] for more details. It is also interesting to see that FlowMark-specic concepts such as Death Path Elimination have been adopted in web service composition languages such as WSFL and BPEL4WS. Communicating owcharts (CFs) [61] support the basic control ow patterns, implicit termination, and multiple instances with a priori design time knowledge, but none of the other workow patterns. The Vortex approach described in [66] does not really amend itself to a pattern-based analysis, as all control ow dependencies are captured through the data perspective. A lot of work has been done in the area of transactional aspects of workows, see e.g. [67 70]. It seems that transactional aspects play a role at a different level than typical control ow aspects, though the separation between the two is not always clear-cut (consider e.g. the cancellation patterns). The relation between YAWL and transactional concepts needs to be researched.

7. Conclusion Through the analysis of a number of languages supported by workow management systems a number of patterns was distilled in previous work.

While all these patterns can be realised in highlevel Petri nets, some of these patterns can only be realised in a rather indirect way requiring a lot of specication effort. The language YAWL was designed, based on Petri nets as to preserve their strengths for the specication of control-ow dependencies in workows, with extensions that allowed for straightforward specication of these patterns. YAWL can be considered a very powerful workow language, built upon experiences with languages supported by contemporary workow management systems. While not a commercial language itself it encompasses these languages (from a control-ow patterns perspective), and, in addition, has a formal semantics. Such an approach is in contrast with e.g. WfMCs XPDL [51] which takes commonalities between various languages as a starting point and does not have formal semantics. Its design hopefully allows YAWL to be used for the purposes of the study of expressiveness and interoperability issues. It is important to note that there is a trade-off between the number of constructs in a language and the patterns supported, i.e., in language design the main goal is to keep the language simple but expressive. Although YAWL is more expressive, it does not use an excessive number of constructs. Moreover, workow languages should not be confused with programming languages. In a programming language it is easy to add a macro. The graphical nature of workow languages and the interactions at runtime (workows are reactive), complicate the use of a simple macro facility. The denition of YAWL presented in this paper only supports the control-ow perspective. However, the relations with the other perspectives (e.g., the data and the resource perspectives) are relevant and are being investigated. At this point in time, YAWL has been extended with the data perspective. For YAWL to be more applicable in the area of web services and Enterprise Application Integration (EAI) it is also desirable that support for communication patterns (e.g. the ones specied in [71]) is built-in. Other directions for future research include extending YAWL with transaction capabilities and developing advanced analysis techniques (e.g., invariants).

ARTICLE IN PRESS
272 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 Table 2 Pattern 1 (seq) 2 (par-spl) 3 (synch) 4 (ex-ch) 5 (simple-m) 6 (m-choice) 7 (sync-m) 8 (multi-m) 9 (disc) 10 (arb-c) 11 (impl-t) 12 (mi-no-s) 13 (mi-dt) 14 (mi-rt) 15 (mi-no) 16 (def-c) 17 (int-par) 18 (milest) 19 (can-a) 20 (can-c) XPDL + + + + + + + + + + + High-level Petri nets + + + + + + i + ii + iii + + v vi + + + =vii viii YAWL + + + + + + + + + + iv + + + + + + + + +

We invite the reader to use the current version of YAWL. The latest version can be downloaded from http://www.citi.qut.edu.au/yawl. Note that YAWL is an open-source initiative. Therefore, we also welcome additions to the software. Disclaimer. We, the authors and the associated institutions, assume no legal liability or responsibility for the accuracy and completeness of any information about workow products, workow languages, and standards contained in this paper. However, we made all possible efforts to ensure that the results presented are, to the best of our knowledge, up-to-date and correct.

Acknowledgements The authors would like to thank Alistair Barros, Marlon Dumas, Bartek Kiepuszewski, and Petia Wohed for their collaborative work on the workow patterns. We would also like to thank Marlon Dumas for his remarks in relation to the evaluation of state charts. Moreover, we would particularly like to thank Lachlan Aldred for implementing the YAWL engine and commenting on earlier versions of the paper. We thank Lindsay Bradford for his work on the development of a design tool for YAWL, which is currently being implemented. We also thank Eric Verbeek for pointing out that Theorem 1 does not hold for nested OR-joins. Finally, we would like to thank the reviewers for their valuable suggestions.

Appendix A. A comparison of high-level Petri nets and YAWL using the patterns Table 2 shown in this appendix indicates for each pattern whether high-level Petri nets and/or YAWL offer direct support (indicated by a +), partial direct support (indicated by a +/), or no direct support (indicated by a ). For comparison, we also included the WfMCs XPDL [51]. It is important to correctly interpret the +, +/, and . A + is only given if the language offers a feature that allows for a direct realisation of the pattern without any restrictions, without the need for coding inside or outside the

(i) The synchronising merge is not supported because the designer has to keep track of the number of parallel threads and decide to merge or synchronise ows (cf. Section 3.2). (ii) The discriminator is not supported because the designer needs to keep track of the number of threads running and the number of threads completed and has to reset the construct explicitly by removing all tokens corresponding to the iteration (cf. Section 3.2). (iii) Implicit termination is not supported because the designer has to keep track of running threads to decide whether the case is completed. (iv) Implicit termination is not supported because the designer is forced to identify one unique nal node. Most models with multiple end nodes can be transformed into a net with a unique end node (simply use a synchronising merge). This has not been added to YAWL to force the designer to think about successful completion of the case. This requirement allows for the detection of unsuccessful completion (e.g., deadlocks). (v) Multiple instances with synchronisation are not supported by high-level Petri nets (cf. Section 3.1). (vi) Also not supported, cf. Section 3.1. (vii) Cancel activity is only partially supported since one can remove tokens from the input place of a transition but additional bookkeeping is required if there are multiple input places and these places may be empty (cf. Section 3.3). (viii) Cancel activity is not supported because one needs to model a vacuum clearer to remove tokens which may of may not reside in specic places (cf. Section 3.3).

tool, and without the need to unfold the construct into other constructs. If the language offers a feature that allows for a direct realisation of the pattern but also imposes restrictions, it is rated with +/. If the language only offers constructs

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 273

to realise the pattern indirectly (through coding, unfolding using other constructs, etc.) or does not support the construct at all, it is rated . For more details on the rating on the basis of patterns we refer to [7] where 15 workow products are rated using the same principle.

References
[1] P. Lawrence (Ed.), Workow Handbook 1997, Workow Management Coalition, Wiley, New York, 1997. [2] L. Fischer (Ed.), Workow Handbook 2001, Workow Management Coalition, Future Strategies, Lighthouse Point, FL, 2001. [3] W.M.P. van der Aalst, Three good reasons for using a Petri-net-based workow management system, in: T. Wakayama, S. Kannapan, C.M. Khoong, S. Navathe, J. Yates (Eds.), Information and Process Integration in Enterprises: Rethinking Documents, The Kluwer International Series in Engineering and Computer Science, Vol. 428, Kluwer Academic Publishers, Boston, MA, 1998, pp. 161182 (Chapter 10). [4] W.M.P. van der Aalst, K.M. van Hee, Workow Management: Models, Methods, and Systems, MIT Press, Cambridge, MA, 2002. [5] C.A. Ellis, G.J. Nutt, Modelling and enactment of workow systems, in: M.A. Marsan (Ed.), Application and Theory of Petri Nets 1993, Lecture Notes in Computer Science, Vol. 691, Springer, Berlin, 1993, pp. 116. [6] F. Leymann, D. Roller, Production Workow: Concepts and Techniques, Prentice-Hall PTR, Upper Saddle River, New Jersey, USA, 1999. [7] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barros, Workow patterns, Distrib. Parallel Databases 14 (1) (2003) 551. [8] S. Jablonski, C. Bussler, Workow Management: Modeling Concepts, Architecture, and Implementation, International Thomson Computer Press, London, UK, 1996. [9] Workow Patterns Home Page. http://www.workowpatterns.com. . [10] D. Riehle, H. Zullighoven, Understanding and using patterns in software development, Theory Practice Object Systems 2 (1) (1996) 313. [11] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Professional Computing Series, Addison Wesley, Reading, MA, USA, 1995. [12] M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading, MA, 1997. [13] B. Kiepuszewski, Expressiveness and suitability of languages for control ow modelling in workows, Ph.D. Thesis, Queensland University of Technology, Brisbane, Australia, 2003, Available via http://www.workowpatterns.com.

[14] C.A. Petri, Kommunikation mit Automaten, Ph.D. Thesis, Fakult. t fur Mathematik und Physik, Technische a . Hochschule Darmstadt, Darmstadt, Germany, 1962. [15] K. Jensen, Coloured Petri nets: a high level language for system design and analysis, in: G. Rozenberg (Ed.), Advances in Petri Nets 1990, Lecture Notes in Computer Science, Vol. 483, Springer, Berlin, 1990, pp. 342416. [16] K. Jensen, Coloured Petri nets, Basic concepts, analysis methods and practical use, Vol. 1, EATCS Monographs on Theoretical Computer Science, Springer, Berlin, 1997. [17] M. Ajmone Marsan, G. Balbo, G. Conte, et al., Modelling with Generalized Stochastic Petri Nets, in: Wiley Series in Parallel Computing, Wiley, New York, 1995. [18] Software-Ley, COSA 3.0 User Manual, Software-Ley GmbH, Pullheim, Germany, 1999. [19] FileNet, Visual WorkFlo Design Guide, FileNet Corporation, Costa Mesa, CA, USA, 1997. [20] Fort! , Fort! Conductor Process Development Guide, e e Fort! Software, Inc., Oakland, CA, USA, 1998. e [21] S.P. Nielsen, C. Easthope, P. Gosselink, K. Gutsze, J. Roele, Using Lotus Domino Workow 2.0, Redbook SG24-5963-00, IBM, Poughkeepsie, USA, 2000. [22] A. Sheth, K. Kochut, J. Miller, Large scale distributed information systems (LSDIS) laboratory, METEOR project page, http://lsdis.cs.uga.edu/proj/meteor/meteor.html. [23] IBM, IBM MQSeries WorkowGetting Started With Buildtime, IBM Deutschland Entwicklung GmbH, Boeblingen, Germany, 1999. [24] Staffware, Staffware 2000/GWD User Manual, Staffware plc, Berkshire, United Kingdom, 2000. [25] Verve, Verve Component Workow Engine Concepts, Verve, Inc., San Francisco, CA, USA, 2000. [26] Fujitsu, i-Flow Developers Guide, Fujitsu Software Corporation, San Jose, CA, USA, 1999. [27] Tibco, TIB/InConcert Process Designer Users Guide, Tibco Software Inc., Palo Alto, CA, USA, 2000. [28] HP, HP Changengine Process Design Guide, HewlettPackard Company, Palo Alto, CA, USA, 2000. [29] SAP. WF SAP Business Workow, SAP AG, Walldorf, Germany, 1997. [30] Eastman Software, RouteBuilder Tool Users Guide, Eastman Software, Inc., Billerica, MA, USA, 1998. [31] P. Athena, Flower User Manual, Pallas Athena BV, Apeldoorn, The Netherlands, 2002. [32] B. Kiepuszewski, A.H.M. ter Hofstede, W.M.P. van der Aalst, Fundamentals of control ow in workows, Acta Inform. 39 (3) (2003) 143209. [33] B. Kiepuszewski, A.H.M. ter Hofstede, C. Bussler, On structured workow modelling, in: B. Wangler, L. Bergman (Eds.), Proceedings of the 12th International Conference on Advanced Information Systems Engineering (CAiSE00), Lecture Notes in Computer Science, Vol. 1789, Stockholm, Sweden, Springer, Berlin, June 2000, pp. 431445. [34] K.M. van Hee, Information System Engineering: A Formal Approach, Cambridge University Press, Cambridge, 1994.

ARTICLE IN PRESS
274 W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 Lecture Notes in Computer Science, Vol. 2185, Springer, Berlin, Toronto, Canada, October 2001, pp. 7690. P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, Analysis of web services composition languages: the case of BPEL4WS, in: I.Y. Song, S.W. Liddle, T.W. Ling, P. Scheuermann (Eds.), 22nd International Conference on Conceptual Modeling (ER 2003), Lecture Notes in Computer Science, Vol. 2813, Springer, Berlin, 2003, pp. 200215. W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, P. Wohed, Pattern-based analysis of BPML (and WSCI), QUT Technical Report, FIT-TR-2002-05, Queensland University of Technology, Brisbane, Australia, 2002. WFMC, Workow management coalition workow standard: workow process denition interfaceXML process denition language (XPDL) (WFMC-TC-1025), Technical Report, Workow Management Coalition, Lighthouse Point, FL, USA, 2002. M. Reichert, P. Dadam, ADEPTex: supporting dynamic changes of workow without loosing control, J. Intel. Inform. Syst. 10 (2) (1998) 93129. J.J. Halliday, S.K. Shrivastava, S.M. Wheater, Flexible workow management in the OPENow system, in: Fourth International Enterprise Distributed Object Computing Conference (EDOC 2001), 47 September 2001, Seattle, WA, Proceedings, IEEE Computer Society, Silver Spring, MD, 2001, pp. 8292. D. Wodtke, J. Weissenfels, G. Weikum, A.K. Dittrich, The mentor project: steps toward enterprise-wide workow management, in: Proceedings of the Twelfth International Conference on Data Engineering, February 26March 1, 1996, New Orleans, LA. IEEE Computer Society, Silverspring, MD, 1996. P. Muth, J. Weissenfels, M. Gillmann, G. Weikum, Workow history management in virtual enterprises using a light-weight workow management system, in: Proceedings of the Ninth International Workshop on Research Issues on Data Engineering: Information Technology for Virtual Enterprises, 2324 March, 1999, Sydney, Australia, 1999, pp. 148155. P. Muth, J. Weissenfels, M. Gillmann, G. Weikum, Integrating light-weight workow management systems within existing business environments, in: Proceedings of the 15th International Conference on Data Engineering, 2326 March 1999, Sydney, Australia, IEEE Computer Society, Silver Spring, MD, 1999, pp. 286293. H. Davulcu, M. Kifer, C.R. Ramakrishnan, I.V. Ramakrishnan, Logic based modeling and analysis of workows (extended abstract), in: Proceedings of the Seventeenth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, June 13, 1998, Seattle, Washington, ACM Press, New York, 1998, pp. 2533. P. Senkul, M. Kifer, I.H. Toroslu, A logical framework for scheduling workows under resource allocation constraints, in: Proceedings of the 28th International Conference on Very Large Data Bases, Hong Kong, China, 2002, pp. 694705.

[35] H.J. Genrich, P.S. Thiagarajan, A theory of bipolar synchronization schemes, Theoret. Comput. Sci. 30 (3) (1984) 241318. [36] G. Keller, M. Nuttgens, A.W. Scheer, Semantische . Processmodellierung auf der Grundlage Ereignisgesteuer. ter Processketten (EPK), Veroffentlichungen des Instituts fur Wirtschaftsinformatik, Heft 89 (in German), Univer. sity of Saarland, Saarbr. ucken, 1992. [37] W.M.P. van der Aalst, Formalization and verication of event-driven process chains, Inform. Software Technol. 41 (10) (1999) 639650. [38] J. Dehnert, P. Rittgen, Relaxed soundness of business processes, in: K.R. Dittrich, A. Geppert, M.C. Norrie (Eds.), Proceedings of the 13th International Conference on Advanced Information Systems Engineering (CAiSE01), Lecture Notes in Computer Science, Vol. 2068, Springer, Berlin, 2001, pp. 157170. [39] P. Langner, C. Schneider, J. Wehler, Petri net based certication of event driven process chains, in: J. Desel, M. Silva (Eds.), Application and Theory of Petri Nets 1998, Lecture Notes in Computer Science, Vol. 1420, Springer, Berlin, 1998, pp. 286305. [40] P. Rittgen, Modied EPCs and their formal semantics, Technical Report 99/19, University of Koblenz-Landau, Koblenz, Germany, 1999. [41] F. Rump, Gesch. ftsprozessmanagement auf der Basis a ereignisgesteuerter Prozessketten, Reihe Wirtschaftsinformatik, Teubner Verlag, Germany, 1999. [42] W.M.P. van der Aalst, The application of Petri nets to workow management, J. Circuit. Syst. Comput. 8 (1) (1998) 2166. [43] P. Chrzastowski-Wachtel, A top-down Petri net based approach for dynamic workow modeling, in: W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske (Eds.), International Conference on Business Process Management (BPM 2003), Lecture Notes in Computer Science, Vol. 2678, Springer, Berlin, 2003, pp. 336353. [44] W. Reisig, G. Rozenberg (Eds.), Lectures on Petri Nets I: Basic Models, Lecture Notes in Computer Science, Vol. 1491, Springer, Berlin, 1998. [45] R.J. van Glabbeek, W.P. Weijland, Branching time and abstraction in bisimulation semantics, ACM 43 (3) (1996) 555600. [46] W.M.P. van der Aalst, J. Desel, E. Kindler, On the semantics of EPCs: a vicious circle, in: M. Nuttgens, F.J. . Rump (Eds.), Proceedings of the EPK 2002: Business Process Management using EPCs, Trier, Germany, November 2002, Gesellschaft fur Informatik, Bonn, . pp. 7180. [47] J. Desel, J. Esparza, Free choice Petri nets, in: Cambridge Tracts in Theoretical Computer Science, Vol. 40, Cambridge University Press, Cambridge, UK, 1995. [48] M. Dumas, A.H.M. ter Hofstede, UML activity diagrams as a workow specication language, in: M. Gogolla, C. Kobryn (Eds.), Proceedings of the Fourth International Conference on the Unied Modeling Language (UML01),

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

ARTICLE IN PRESS
W.M.P. van der Aalst, A.H.M. ter Hofstede / Information Systems 30 (2005) 245275 [59] M. Weske, Formal foundation, conceptual design, and prototypical implementation of workow management systems, Habilitations Thesis, University of Munster, . Germany, 2000. . [60] C. Mohan, G. Alonso, R. Gunthor, M. Kamath, Exotica: . a research perspective on workow management systems, IEEE Data Eng. Bull. 18 (1) (1995) 1926. [61] G. Dong, R. Hull, B. Kumar, J. Su, G. Zhou, A framework for optimizing distributed workow executions, in: R. Connor, A. Mendelzon (Eds.), Research Issues in Structured and Semistructured Database Programming: Seventh International Workshop on Database Programming Languages, DBPL99, Kinloch Rannoch, UK, September 1999, Revised Papers, Lecture Notes in Computer Science, Vol. 1949, Springer, Heidelberg, Germany, 2000, pp. 152167. [62] D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-Trauring, M. Trakhtenbrot, STATEMATE: a working environment for the development of complex reactive systems, IEEE Trans. Software Eng. 16 (4) (1990) 403414. [63] A.J. Bonner, M. Kifer, Concurrency and communication in transaction logic, in: M.J. Maher (Ed.), Proceedings of the Joint International Conference and Symposium on Logic Programming, September 26, 1996, Bonn, Germany, MIT Press, Cambridge, MA, 1996, pp. 142156. [64] G. Vossen, M. Weske, The WASA2 object-oriented workow management system, in: A. Delis, C. Faloutsos, S. Ghandeharizadeh (Eds.), SIGMOD 1999, Proceedings ACM SIGMOD International Conference on Management of Data, June 13, 1999, Philadelphia, PA, USA, ACM Press, New York, 1999, pp. 587589. [65] M. Weske, Formal foundation and conceptual design of dynamic adaptations in a workow management system, in: R. Sprague (Ed.), Proceedings of the 34th Annual 275

[66]

[67]

[68]

[69]

[70]

[71]

Hawaii International Conference on System Science (HICSS-34), IEEE Computer Society Press, Los Alamitos, CA, 2001. R. Hull, F. Llirbat, E. Simon, J. Su, G. Dong, B. Kumar, G. Zhou, Declarative workows that support easy modication and dynamic browsing, in: G. Georgakopoulos, W. Prinz, A.L. Wolf (Eds.), Work Activities Coordination and Collaboration (WACC99), San Francisco, ACM press, New York, February 1999, pp. 6978. G. Alonso, D. Agrawal, A. El Abbadi, M. Kamath, R. . Gunthor, C. Mohan, Advanced Transaction Models in . Workow Contexts, in: Proceedings of the 12th International Conference on Data Engineering, February 26 March 1, 1996, New Orleans, LA, IEEE Computer Society, Silver Spring, MD, 1996. I. Houston, M.C. Little, I. Robinson, S.K. Shrivastava, S.M. Wheater, The CORBA activity service framework for supporting extended transactions, in: R. Guerraoui (Ed.), Middleware 2001: IFIP/ACM International Conference on Distributed Systems Platforms, Heidelberg, Germany, November 1216, 2001, Proceedings, Lecture Notes in Computer Science, Vol. 2218, Springer, Berlin, 2001, pp. 197215. G. Vossen, Transactional workows (tutorial), in: F. Bry, R. Ramakrishnan, K. Ramamohanarao (Eds.), Proceedings of the Fifth International Conference on Deductive and Object-Oriented Databases (DOOD97), Lecture Notes in Computer Science, Vol. 1341, Springer, Berlin, 1997, pp. 2025. G. Weikum, G. Vossen, Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery, Morgan Kaufmann Publishers, San Francisco, CA, 2002. W.A. Ruh, F.X. Maginnis, W.J. Brown, Enterprise Application Integration: A Wiley Tech Brief, Wiley, New York, 2001.