YAWL: زبان دیگر جریان کاری که رتبه بندی نشده

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.

Despite the efforts of the workflow management coalition (WfMC [1] and [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] and [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] and [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] and [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] and [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] and [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.

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 straightforward specification of these patterns. YAWL can be considered a very powerful workflow language, built upon experiences with languages supported by contemporary workflow management systems. While not a commercial language itself it encompasses these languages (from a control-flow patterns perspective), and, in addition, has a formal semantics. Such an approach is in contrast with e.g. WfMC's 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, workflow languages should not be confused with programming languages. In a programming language it is easy to add a macro. The graphical nature of workflow languages and the interactions at runtime (workflows are reactive), complicate the use of a simple macro facility. The definition of YAWL presented in this paper only supports the control-flow 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 specified in [71]) is built-in. Other directions for future research include extending YAWL with transaction capabilities and developing advanced analysis techniques (e.g., invariants). 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 workflow products, workflow 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.