BPEL is not the only language for business process execution. Before we start discussing the technical aspects of BPEL, let us overview the relation of BPEL to other languages. Recently, several orchestration and choreography languages have been proposed. The most important orchestration languages include:
The most important choreography languages include:
In addition to orchestration and choreography languages, which have primarily been designed to provide machine executable representations of business processes, we also have to mention the business process modeling notations. These are used to define business process models and are essential for BPM (Business Process Management). The most popular and well-known is the BPMN (Business Process Modeling Notation). BPMN is becoming an important part of SOA.
The following figure shows a timeline of the mentioned languages, as they have been developed:
 |
We have already mentioned that BPEL represents a convergence of XLANG and WSFL and it shares and further develops the concepts of those languages. In the following sections we will briefly describe these languages.
XLANG has been one of the early orchestration languages. It has been developed with the objective of achieving clear separation between processes and implementations. It is a Microsoft proprietary language and not fully documented. It has been used in Microsoft BizTalk. XLANG and its successor XLANG/s can be viewed as messaging languages with some of the expression capabilities of C#. However, code is not portable between XLANG/s and C#.
XLANG/s specifies high-level constructs that are used to define and execute business processes. The semantics embodied in XLANG/s are a reflection of those defined in BPEL. Although XLANG is thought of as a predecessor of BPEL, Microsoft continues to use XLANG/s in their BizTalk Server. Instead of moving to BPEL in BizTalk, Microsoft provides a conversion between XLANG/s and BPEL.
WSFL is also one of the early XML-based orchestration languages. It has been developed by IBM to be a part of the Web Services technology stack. WSFL supports two types of service compositions. First is the flow model, which specifies the exact interactions between services (a process). Such a flow model is executable. The second type is the global model, which specifies the overall interaction of services and is abstract. This is very similar to BPEL-executable and abstract processes.
As we have already mentioned, WSFL has, together with XLANG, provided a basis for BPEL. Unlike Microsoft, IBM has moved to BPEL as their main language for service composition and provides full support for BPEL in their various products, such as in IBM WebSphere Process Server.
BPML has been developed by BPMI.org (Business Process Management Initiative). Intalio has played an important role, and has been the initiator of BPML. BPML is a meta-language for modeling business processes and provides an abstract execution model for describing collaborations and transactions. It defines a formal model for expressing abstract and executable processes, and supports:
Data management
Conformity
Exception handling
Operation semantics
BPML can describe a process in a specific language, defined on top of the extensible BPML scheme. Business processes are defined as groups of flows (control flows, data flows, and event flows). Formatting features, security rules, and transactional contexts can also be defined. BPML offers support for synchronous and asynchronous distributed transactions and can be used for the process components of existing applications.
Comparing BPML to BPEL shows that both share similar roots in Web Services and leverage other Web Services specifications, particularly WS-Security, WS-Coordination, and WS-Transactions. BPML, however, supports modeling more complex business processes through its support for advanced semantics such as nested processes and complex compensated transactions. BPML can therefore be regarded as a superset of BPEL. The extensions of BPEL with business rules, task management, human interactions, and so on are defined in BPXL (Business Process eXtension Layers).
The fact that both BPEL and BPML share the same idioms and have similar syntax has resulted in BPML being discontinued in favor of BPEL. BPEL has over the years gained much broader support by software vendors than BPML.
Electronic Business using eXtensible Markup Language (ebXML) is a framework that provides a set of technologies, BPSS being one of them. ebXML has been developed under the initiative of OASIS and UN/CEFACT and consists of the following technologies:
Messaging: Uses SOAP with attachments for communication between partners.
Registry and repository: Similar to UDDI registry, but offers additional functionality through the repository.
Core components: Used for construction of business documents.
CPP (Collaboration Protocol Profile): Used to express a partner profile.
CPA (Collaboration Protocol Agreement): Used to express an agreement between partners.
BPSS covers the same domain as BPEL. The BPSS approach to process specification follows the choreography pattern and is therefore comparable to abstract BPEL processes. In addition to specifying the process logic, BPSS also specifies the communication protocol details.
BPSS is designed around the concept of business transactions, which is, however, not fully conformant with the Web Services Transactions specifications. A BPSS business transaction is used to describe the message exchange between two abstract roles the sender and the responder. Each message consists of an XML document and optional attachments, which can be XML or binary. For each responding message, we specify whether it is a positive or negative message. Each message is associated with a business transaction protocol. Collaboration in BPSS can be bilateral or multi-party and is described by the business transaction protocol.
We can see that BPSS is not a direct alternative to BPEL and is used in environments where ebXML is applied. For more information on ebXML, refer to the following books:
ebXML: Concepts and Application by Brian Gibb and Suresh Damodaran, John Wiley & Sons
ebXML: The New Global Standard for Doing Business over the Internet by Alan Kotok and David RR Webber, SAMS
ebXML Simplified: A Guide to the New Standard for Global E‑Commerce by Eric Chiu, John Wiley & Sons
YAWL has been developed by Eindhoven University of Technology and Queensland University of Technology. Subsequently, several companies have contributed to the language. The objective of YAWL has been to develop a language that would support workflow patterns with a formal specification. YAWL is based on Petri nets. The formal semantics of YAWL enables the static analysis of the language, which is supported by a tool. The language itself is supported by software that is developed as open source under an LGPL. It includes the execution engine, graphical editor, and an application for human tasks.
Similar to BPEL, YAWL is an executable language for processes (workflows). The main advantage of YAWL is its support for workflow patterns. The major difference is how both languages have been developed. BPEL has been driven by a standardization committee under OASIS and has gained large industry support. Today, most major vendors provide support for BPEL. YAWL on the other hand, has only one implementation. More on YAWL can be found on http://www.yawl-system.com/.
WSCL has been developed by HP. In contrast to previously mentioned languages, WSCL has focused on the choreography aspect rather than on the orchestration. It has been designed to describe business-level conversations or public processes, supported by corresponding services. WSCL specifies the XML documents being exchanged, and the allowed sequencing of these document exchanges. WSCL is not a direct alternative to BPEL, as it does not support executable process orchestrations, as BPEL does. It is somehow similar to BPEL abstract processes.
HP has submitted WSCL to W3C, where it has become a W3C Note in 2002. Since then it has not gained much support from software vendors, therefore WSCL does not play an important role in SOA. The WSCL specification is accessible at http://www.w3.org/TR/wscl10/.
WSCI version 1.0 has been developed by Sun, BEA, SAP, and Intalio. WSCI is a choreography language for describing the flow of messages exchanged by Web Services in the context of a process. It allows us to describe the observable behavior of a web service in a message exchange. WSCI also describes the collective message exchange among interacting Web Services, providing a global and message-oriented view of a process involving multiple Web Services.
In WSCI, message exchange is described from the viewpoint of each web service. Each exchange can be qualified by message correlations, transaction descriptions, and location capabilities. WSCI therefore describes the observable behavior of Web Services. However, WSCI does not address the definition of the processes driving the message exchange. It also does not address the definition of the internal behavior of each web service.
Since WSCI follows the choreography pattern and does not address defining executable business processes, it compares directly only to BPEL abstract processes. WSCI has a cleaner interface, which makes it a little easier to learn than BPEL. The WSCI specification has also been submitted to W3C, which has published it as a W3C Note. Further, W3C has formed a WS-Choreography working group, which will address the choreography of Web Services, but has only released the requirements specification so far.
WSCI has not gained industry support comparable to BPEL. The industry consensus seems to support BPEL. The WSCI specification is accessible at http://www.w3.org/TR/wsci/.
WS-CDL is a language for specifying the choreography of collaborating services. It targets the composition of interoperable collaborations between services. With WS-CDL we can specify the peer-to-peer collaboration of Web Services through the definition of their observable behavior. We can define sets of rules that define how, and in what order, different services should act together. Such specification provides a flexible systemic view of the process.
WS-CDL is positioned as a complementary language to BPEL (and other business process languages). While BPEL focuses on the behavior specification of a specific business partner, WS-CDL focuses on the description of message interchanges between business partners. WS-CDL provides the global model needed by BPEL processes to ensure that the behavior of endpoints is consistent across all cooperating services.
A business partner can use the WS-CDL choreography specification to verify if their internal processes have their outside behavior defined in a way that will allow them to participate in choreography. WS-CDL choreography specifications can be used to generate public interfaces, for example, specified using BPEL abstract processes. WS-CDL specifications are also useful at runtime to verify the execution of message exchange between business partners.
As WS-CDL is a complementary language to BPEL we cannot make a direct comparison. However, WS-CDL differs considerably from BPEL. With WS-CDL we define the message flows exchanged by all partners, while with BPEL we focus on message flow and the behavior of a specific partner that is, on the internal behavior of a business process. The WS-CDL description of message flows is done from a general perspective, while BPEL specifies message exchange from the point of view of a specific partner. A BPEL process specifies activities that are executed. WS-CDL specifies reactive rules, which are used by all participants of a collaboration.
At the time of writing, WS-CDL has been a W3C Candidate Recommendation, dated 9 November 2005. Since then WS-CDL has not gained much industry support, as no major vendor supports it. At the time of writing, only two small vendors provided tools. The WS-CDL specification is accessible at http://www.w3.org/TR/ws-cdl-10/.
BPMN is a graphical notation for specifying business processes. It is the most comprehensive notation for process modeling so far. BPMN has initially been developed by BPMI. In 2005, BPMI merged with OMG (Object Management Group). The current version of BPMN is 1.2. BPMN version 2.0 is currently a work in progress.
We use BPMN to draw business process diagrams. Such diagrams present the activities and tasks of a process and their relations. The diagram uses flowchart concepts to represent the logic of business processes.
BPMN is a graphical-visual language and uses a set of graphical elements. Activities are represented as rectangles and decisions are diamonds. BPMN successfully joins the simplicity of the diagrams with the expressive power, which allows BPMN to be used for complex processes and specification of details.
To model the diagrams, BPMN defines four categories of elements:
Flow objects, which are activities, events, and gateways. Activities can be tasks or subprocesses. Events can be triggers or results. Three types of events are supported start, intermediate, and end. Gateways control the divergence of sequential flows into concurrent flows and their convergence back to sequential flow.
Connecting objects are used to connect together flow objects. Connectors are sequence flows, message flows, and associations.
Swim lanes are used to organize activities into visual categories in order to illustrate different responsibilities or functional capabilities. Pools and lanes can be used for swim lanes.
Artifacts are used to add specific context to the business processes that are modeled. Data objects are used to show how data is produced or required by the process. Groups are used to group together similar activities or other elements. Annotations are used to add text information to the diagram. We can also define custom artifacts.
BPMN can be used to model parts of processes or whole processes. Processes can be modeled at different levels of fidelity. BPMN is equally suitable for internal (private) business processes and for public (collaborative) business-to-business processes.
The most important goals when designing BPMN have been:
To develop a notation that will be useful and understandable at all levels of BPM. In business process modeling, different people are involved, from business users, business analysts, process owners, to the technical architects and developers. The goal of BPMN has been to provide a graphical that, which is simple to understand, but powerful enough to model business processes into the required details.
The semantic gap between the business process models and the information technology (application software) has been quite large with existing technologies. There has been no clear definition of how one relates to the other. The goal of BPMN has been to enable automatic transformation into the executable code into BPEL and vice-versa. Therefore, BPMN has been designed specifically to provide such transformation.
Particularly because of the ability to automatically transform BPMN process models in executable BPEL processes, BPMN today plays an important role in SOA development. Modeling of a business process using BPMN is usually the first step. After the model is complete, such a process is transformed into BPEL to be executed on a process server. Today several tools for major vendors such as Oracle and IBM provide such automatic transformation, usually in both directions, which enables round-tripping between model (BPMN) and executable process representation (BPEL).
For more information on BPMN, refer to the following:
Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant, Packt Publishing
BPMN Specification,