Elsevier

Information Systems

Volume 30, Issue 4, June 2005, Pages 245-275
Information Systems

YAWL: yet another workflow language

https://doi.org/10.1016/j.is.2004.02.002Get rights and content

Abstract

Based on a rigorous analysis of existing workflow management systems and workflow languages, a new workflow language is proposed: yet another workflow language (YAWL). To identify the differences between the various languages, we have collected a fairly complete set of workflow patterns. Based on these patterns we have evaluated several workflow products and detected considerable differences in their ability to capture control flows for non-trivial workflow processes. Languages based on Petri nets perform better when it comes to state-based workflow 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 workflow patterns identified. This paper motivates the need for such a language, specifies the semantics of the language, and shows that soundness can be verified in a compositional way. Although YAWL is intended as a complete workflow language, the focus of this paper is limited to the control-flow perspective.

Introduction

Despite the efforts of the workflow management coalition (WfMC [1], [2]), workflow management systems use a large variety of languages and concepts based on different paradigms. Most of the products available use a proprietary language rather than a tool-independent language. Some workflow management systems are based on Petri nets but typically add both product specific extensions and restrictions [3], [4], [5]. Other systems use a completely different mechanism. For example, IBM's MQSeries Workflow 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 workflow specification 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, it is contended, explains and ultimately justifies the major differences in workflow languages—fostering up a “horses for courses” diversity in workflow languages. What is more, the comparison of different workflow products winds up being more of a dissemination of products and less of a critique of workflow language capabilities [7].

Workflow specifications can be understood, in a broad sense, from a number of different perspectives (see [4], [8]). The control-flow perspective (or process) perspective describes tasks and their execution ordering through different constructors, which permit flow 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 flow between activities, and local variables of the workflow, qualify in effect pre- and post-conditions of task execution. The resource perspective provides an organisational structure anchor to the workflow 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 workflow 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-flow perspective. Clearly, this provides an essential insight into a workflow specification's effectiveness. The data flow perspective rests on it, while the organisational and operational perspectives are ancillary. If workflow specifications are to be extended to meet newer processing requirements, control flow constructors require a fundamental insight and analysis. Currently, most workflow 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 workflow languages nor insight into more complex requirements of business processes is advanced [7].

We indicate requirements for workflow languages through workflow patterns [7], [9]. As described in [10], a “pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts”. Gamma et al. [11] first 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 workflow patterns to compare the functionality of 15 workflow management systems (COSA, Visual Workflow, Forté Conductor, Lotus Domino Workflow, Meteor, Mobile, MQSeries/Work-flow, Staffware, Verve Workflow, I-Flow, InConcert, Changengine, SAP R/3 Workflow, 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 workflow 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 detail. Moreover, the patterns are based on functionality present in today's tools and frequently used by workflow designers when available. (Note that products typically support half of the patterns but there is no consensus on which half.) Several vendors extended their workflow products based on the patterns (cf. BizAgi, FLOWer, Pectra, Staffware, etc.) and some open source initiatives have been inspired by the patterns (cf. jBpm, Werkflow). 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 workflow management systems leaves much to be desired. This observation triggered the question: How about high-level Petri nets as a workflow 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 workflow 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 workflow 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 specific 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 flows need to be joined while it is not clear whether synchronisation is needed, i.e., if both flows are active an AND-join is needed otherwise an XOR-join. Such advanced synchronisation patterns are difficult to model in terms of a high-level Petri net because the firing rule only supports two types of joins: the AND-join (transition) or the XOR-join (place).

  • 3.

    The firing of a transition is always local, i.e., enabling is only based on the tokens in the input places and firing is only affecting the input and output places. However, some events in the workflow 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 workflow patterns with high-level Petri nets. Based on this we describe yet another workflow language (YAWL). YAWL is based on Petri nets but extended with additional features to facilitate the modelling of complex workflows.

Section snippets

Requirements

Since 1999, we have been working on collecting a comprehensive set of workflow patterns [7]. The results have been made available through the “Workflow 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 ourselves to the 20 most relevant patterns. These patterns can be classified into six categories:

  • 1.

    Basic

Limitations of Petri Nets as a control-flow language for workflows

Given the fact that workflow management systems have problems dealing with workflow 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].

YAWL: yet another workflow language

In the preceding sections, we have demonstrated that contemporary workflow 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 workflow 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

Analysis

YAWL is more suitable than (high-level) Petri nets in the sense that there is direct support for several patterns that are difficult 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 workflow specification S

Related work

In this section, some workflow 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 flow perspective. The results are summarised in Table 1. It should be noted that a pattern-based analysis of 13 commercial workflow offerings can be found in [7]. For an analysis of UML activity diagrams 1.4 in

Conclusion

Through the analysis of a number of languages supported by workflow management systems a number of patterns was distilled in previous work. While all these patterns can be realised in high-level Petri nets, some of these patterns can only be realised in a rather indirect way requiring a lot of specification effort. The language YAWL was designed, based on Petri nets as to preserve their strengths for the specification of control-flow dependencies in workflows, with extensions that allowed for

Acknowledgements

The authors would like to thank Alistair Barros, Marlon Dumas, Bartek Kiepuszewski, and Petia Wohed for their collaborative work on the workflow 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

References (71)

  • H.J. Genrich et al.

    A theory of bipolar synchronization schemes

    Theoret. Comput. Sci.

    (1984)
  • W.M.P. van der Aalst

    Formalization and verification of event-driven process chains

    Inform. Software Technol.

    (1999)
  • P. Lawrence (Ed.), Workflow Handbook 1997, Workflow Management Coalition, Wiley, New York,...
  • L. Fischer (Ed.), Workflow Handbook 2001, Workflow Management Coalition, Future Strategies, Lighthouse Point, FL,...
  • W.M.P. van der Aalst

    Three good reasons for using a Petri-net-based workflow management system

  • W.M.P. van der Aalst, K.M. van Hee, Workflow Management: Models, Methods, and Systems, MIT Press, Cambridge, MA,...
  • C.A. Ellis et al.

    Modelling and enactment of workflow systems

  • F. Leymann et al.

    Production Workflow: Concepts and Techniques

    (1999)
  • W.M.P. van der Aalst et al.

    Workflow patterns

    Distrib. Parallel Databases

    (2003)
  • S. Jablonski et al.

    Workflow Management: Modeling Concepts, Architecture, and Implementation

    (1996)
  • Workflow Patterns Home Page....
  • D. Riehle et al.

    Understanding and using patterns in software development

    Theory Practice Object Systems

    (1996)
  • E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software,...
  • M. Fowler

    Analysis Patterns: Reusable Object Models

    (1997)
  • B. Kiepuszewski, Expressiveness and suitability of languages for control flow modelling in workflows, Ph.D. Thesis,...
  • C.A. Petri, Kommunikation mit Automaten, Ph.D. Thesis, Fakultät für Mathematik und Physik, Technische Hochschule...
  • K. Jensen

    Coloured Petri nets: a high level language for system design and analysis

  • K. Jensen, Coloured Petri nets, Basic concepts, analysis methods and practical use, Vol. 1, EATCS Monographs on...
  • M. Ajmone Marsan et al.

    Modelling with Generalized Stochastic Petri Nets

    (1995)
  • Software-Ley, COSA 3.0 User Manual, Software-Ley GmbH, Pullheim, Germany,...
  • FileNet, Visual WorkFlo Design Guide, FileNet Corporation, Costa Mesa, CA, USA,...
  • Forté, Forté Conductor Process Development Guide, Forté Software, Inc., Oakland, CA, USA,...
  • S.P. Nielsen, C. Easthope, P. Gosselink, K. Gutsze, J. Roele, Using Lotus Domino Workflow 2.0, Redbook SG24-5963-00,...
  • A. Sheth, K. Kochut, J. Miller, Large scale distributed information systems (LSDIS) laboratory, METEOR project page,...
  • IBM, IBM MQSeries Workflow—Getting Started With Buildtime, IBM Deutschland Entwicklung GmbH, Boeblingen, Germany,...
  • Staffware, Staffware 2000/GWD User Manual, Staffware plc, Berkshire, United Kingdom,...
  • Verve, Verve Component Workflow Engine Concepts, Verve, Inc., San Francisco, CA, USA,...
  • Fujitsu, i-Flow Developers Guide, Fujitsu Software Corporation, San Jose, CA, USA,...
  • Tibco, TIB/InConcert Process Designer User's Guide, Tibco Software Inc., Palo Alto, CA, USA,...
  • HP, HP Changengine Process Design Guide, Hewlett-Packard Company, Palo Alto, CA, USA,...
  • SAP. WF SAP Business Workflow, SAP AG, Walldorf, Germany,...
  • Eastman Software, RouteBuilder Tool User's Guide, Eastman Software, Inc., Billerica, MA, USA,...
  • P. Athena

    Flower User Manual

    (2002)
  • B. Kiepuszewski et al.

    Fundamentals of control flow in workflows

    Acta Inform.

    (2003)
  • B. Kiepuszewski, A.H.M. ter Hofstede, C. Bussler, On structured workflow modelling, in: B. Wangler, L. Bergman (Eds.),...
  • Cited by (1069)

    View all citing articles on Scopus
    View full text