YAWL
From Wikipedia, the free encyclopedia
This article is about the workflow system. For the sailing craft, see yawl.
YAWL (Yet Another Workflow Language) is a workflow language based on the Workflow patterns. The language is supported by a software system that includes an execution engine, a graphical editor and a worklist handler. The system is available as an Open source software under the LGPL license.
Production-level uses of the YAWL system include a deployment by first:utility and first:telecom in the UK to automate front-end service processes, and by the Australian film television and radio school to coordinate film shooting processes. The YAWL system has also been used for teaching in more than 20 universities.[1]
Contents |
[edit] Features
- Comprehensive support for the workflow patterns.
- Support for advanced resource allocation policies, including four-eyes principle and chained execution.
- Support for dynamic adaptation of workflow models through the notion of worklets.
- Sophisticated workflow model validation features (e.g. deadlock detection at design-time).
- XML-based model for data definition and manipulation based on XML Schema, XPath and XQuery.
- XML-based interfaces for monitoring and controlling workflow instances and for accessing execution logs.
- XML-based plug-in interfaces for connecting third-party web services with the system, including third-party worklist/task handlers.
- Automated form generation from XML schema.
[edit] History
The language and its supporting system were originally developed by researchers at Eindhoven University of Technology and Queensland University of Technology. Subsequently, several organizations such as InterContinental Hotels Group, first:telecom and ATOS Worldline have contributed to the initiative.
The original drivers behind YAWL were to define a workflow language that would support all (or most) of the Workflow Patterns and that would have a formal semantics. Observing that Petri nets came close to supporting most of the Workflow Patterns, the designers of YAWL decided to take Petri nets as a starting point and to extend this formalism with three main constructs, namely or-join, cancellation sets, and multi-instance activities. These three concepts are aimed at supporting five of the Workflow Patterns that were not directly supported in Petri nets, namely synchronizing merge, discriminator, N-out-of-M join, multiple instance with no a priori runtime knowledge and cancel case. In addition, YAWL adds some syntactical elements to Petri nets in order to intuitively capture other workflow patterns such as simple choice (xor-split), simple merge (xor-join), and multiple choice (or-split). During the design of the language, it turned out that some of the extensions that were added to Petri nets were difficult or even impossible to re-encode back into plain Petri nets. As a result, the original formal semantics of YAWL is defined as a Labelled transition system and not in terms of Petri nets. The fact that YAWL is based on a formal semantics has enabled the implementation of several techniques for analyzing YAWL processes. In particular, the YAWL system includes a static analysis tool called WofYAWL.
[edit] YAWL x BPEL
YAWL is sometimes seen as an alternative to BPEL. A major advantage of BPEL is that it is driven by a standardization committee supported by several IT industry players. As a result, BPEL is supported by a significant number of tools (both proprietary and open-source) while YAWL has a single implementation at present. Also, several researchers have captured the formal semantics of subsets of BPEL in terms of various formalisms, including Petri nets, Process algebra and Finite state machine. This has paved the way for the development of static analysis tools for BPEL that can compete with the static analysis capabilities provided by the YAWL system. On the other hand, it has been noted that standard BPEL fails to support human tasks, that is, tasks that are allocated to human actors and that require these actors to complete actions, possibly involving a physical performance. A number of BPEL engines already provide extensions to BPEL for human tasks, but these extensions are yet to be standardized. In contrast, YAWL provides a unified interface for worklist services based on Web services standards. This interface allows developers to build their own worklist service to support human tasks according to their needs. In addition, the YAWL system comes with a default worklist service that supports several types of human task allocation and handling. Another advantage of YAWL is its support for the Workflow Patterns, although the gap between YAWL and BPEL in this respect may be reduced by new constructs that are included in BPEL version 2.0.
