The number of commercial tools for workflow and business process management that have emerged over the past two decades is considerable. In the past, lack of standardization led to a situation where each of these tools implemented a different language. As shown by the tool evaluations undertaken using the workflow patterns, many of these languages suffered from clear limitations in terms of their expressiveness and suitability to capture nontrivial business processes. By now, industry consolidation has rendered most of these languages obsolete. In parallel, standardization efforts initiated by tool vendors have led to the definition of two standard languages for capturing business processes, namely the Business Process Modeling Notation (BPMN) and the Web Services Business Process Execution Language (WS-BPEL or BPEL for short). BPMN is a business processmodeling notation intended to facilitate communication between domain analysts and to support decision-making based on techniques such as cost analysis, scenario analysis, and simulation. BPMN models are not meant to be directly executable, although they may serve as input to software development projects. A comparison between BPMN and YAWL and a method for mapping BPMN diagrams into YAWL nets are given in Chap. 13. Meanwhile, BPEL is a language for defining executable business processes. In this respect, it can be seen as competing in the same space as YAWL. Yet, the original motivation and design of YAWL are very different from those of BPEL, and this fact transpires in profound differences between these two languages. BPEL is intended to support the definition of a class of business processes known as Web service orchestrations. In a Web service orchestration, one service (the orchestrator) interacts with a number of other services. The focus of BPEL is therefore on capturing interactions between a given process and a set of partners (represented as Web services). The logic of the interactions is described as a composition of communication actions (send, receive, send/receive, etc.). These communication actions are interrelated by control-flow dependencies expressed through constructs corresponding to parallel, sequential, and conditional execution, event, and exception handling.
Springer Berlin/Heidelberg, 2010. 385-400 p.