The BPEL4WS 1.1 specification was submitted to OASIS back in 2004 and after three years of work by one of the largest technical committees at OASIS, WS-BPEL 2.0 finally became an OASIS standard on April 12, 2007. While adoption of the BPEL language has not been gated by the 2.0 standard or the OASIS stamp of approval - there are thousands of successful BPEL projects and deployments today - the formal publication of the standard is an important milestone and will further accelerate BPEL's adoption and vendor support.
A lot has been already written about the new features in WS-BPEL 2.0 on various blogs, Web sites, and magazine articles, including the article "BPEL Grows Up". In this article, we'll drill down into the next level of detail regarding the new features in WS-BPEL 2.0 using concrete examples wherever possible. Throughout this article, we abbreviate BPEL4WS 1.1 as BPEL 1.1 and WS-BPEL 2.0 as BPEL 2.0.
BPEL 2.0 Overview
At a high level BPEL is an XML language that provides a rich set of activities to describe an executable business process. The processes and activities can be synchronous or asynchronous, short-lived or long-running; BPEL provides a sophisticated language for defining the process flow, system interactions, data manipulation, exception handling, compensation rules, etc. First, we will briefly summarize the important features of the BPEL standard, explicitly calling out what is new or changed in BPEL 2.0: (Figure 1)
• Service interaction activities: A BPEL process is automatically a Web Service and receives inputs via <receive> or <pick> activities. A process can send back a synchronous Web Service response using <reply>. The <invoke> activity is available to invoke an external service, as described below, but also to respond asynchronously to a client.
• Event handling constructs: A process can get input requests at non-deterministic points during process execution with <eventHandlers> using <onEvent> for messages (new in BPEL - replaces <onMessage> from BPEL 1.1) or <onAlarm> for time-triggered events. <wait> can wait for a specified time or until a deadline is reached and <receive> can wait for events at pre-determined points in the process.
• Back-end system interactions: Interactions with external services are represented as <partnerLinks>. Asynchronous conversational interactions can be correlated using <correlationSet> or the WS-Addressing standard. A process maintains its state using <variables> that can be defined at global or local scope. BPEL 2.0 makes it easier to map process variables to WSDL message variables. It also provides the new <messageExchange> activity to distinguish instances of similar conversations (request/response pairs).
• Data manipulation activities: BPEL 2.0 adds a new simplified XPath notation ($variableName) replacing the getVariableData() function. Besides the existing <assign> activity to map data between variables, BPEL 2.0 provides a doXSLTransform() function to natively support XSL Transformations. A <validate> activity has been added for schema validations. These additions have already been time tested, having been implemented as extensions in vendor implementations of BPEL for quite some time now.
• Process structural flow related activities: BPEL includes basic structural activities similar to other workflow or programming languages for sequencing, iteration, and branching. BPEL 1.1 supported <sequence> for sequential execution, <flow> for parallel branches, and <while> for looping. BPEL 2.0 adds <if> / <else>, <repeatUntil> and <forEach> for richer flow control syntax. In particular, the new <forEach> construct now supports dynamic parallelism (executing N activities in parallel, when the value N is not known until execution time). This was not supported in BPEL 1.1 except through vendor extensions.
• Exception handling and recovery constructs: Exceptions, represented as faults, are propagated using <throw>, and BPEL 2.0 adds <rethrow> to provide more explicit control over exception management patterns. In <faultHandlers>, faults can be detected using <catch> and <catchAll>. A process can undo completed work through <compensationHandlers> and the <compensate> activity; BPEL 2.0 adds <compensateScope> to clarify the syntax of BPEL 1.1's overloading of the <compensate> activity. BPEL 2.0 also adds <terminationHandlers> to enable processes to specify the logic to be invoked just prior to the termination of a process.
• Extensibility: BPEL 2.0 adds <extensionAssignOperation> to extend the standard <assign> activity; it also provides <extensionActivity> to add new activity types. This is another area where the 2.0 standard now explicitly covers things that vendor implementations were already doing. BPEL 2.0 also now supports <import> and <documentation>.
Read the complete article by Khanderao Kand, Manoj Das, Alex Yiu; SOA World Magazine.
