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 In this post, I'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)
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>.
• 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>.
Kitchens Online Use Case
To illustrate some of the BPEL features, we will use the example of Kitchens Online, a fictitious Internet-based kitchen-remodeling solution. Kitchens Online provides a Web site where customers can select appliances and cabinets and schedule delivery and installation. Kitchens Online doesn't carry any stock and sources the different components from various vendors; however it still wants to keep inventory information as up-to-date as possible. Complicating matters, the vendors Kitchens Online's suppliers don't always have automated inventory systems - in many instances, a person needs to check manually whether a given item is available. When a customer places an order, Kitchens Online tries to reserve all the needed components from its vendors. If it can't reserve a piece, the customer is notified and can then change or cancel the order.
To illustrate some of the BPEL features, we will use the example of Kitchens Online, a fictitious Internet-based kitchen-remodeling solution. Kitchens Online provides a Web site where customers can select appliances and cabinets and schedule delivery and installation. Kitchens Online doesn't carry any stock and sources the different components from various vendors; however it still wants to keep inventory information as up-to-date as possible. Complicating matters, the vendors Kitchens Online's suppliers don't always have automated inventory systems - in many instances, a person needs to check manually whether a given item is available. When a customer places an order, Kitchens Online tries to reserve all the needed components from its vendors. If it can't reserve a piece, the customer is notified and can then change or cancel the order.
This example highlights the following advanced requirements:
- Dynamic Parallelism - handling of different components (line items) of an Order in parallel
- Change handling (out-of-band events) - a delivery schedule may change while an Order is in process
- Compensation - reversing credit card charges and releasing reserved inventory when a component is out-of-stock
Since this article is focused on the BPEL 2.0 standard, and BPEL is an XML language, we'll examine the BPEL "source code" in XML format. Of course most developers won't hand-code BPEL in the XML format - they'll use visual tools built on top of the standard. Several vendors and open source implementations of such tools exist, including some that enable developers to switch back and forth between a visual model of a BPEL process and the underlying BPEL source. Here we'll examine the underlying XML source, so get ready!
Dynamic Parallelism
The Kitchens Online requirement to process the multiple items of an Order in parallel is a very common pattern. The <flow> activity introduced in BPEL 1.1 supported parallelism, but only when the number of parallel branches was known at design time. Here, an Order may have a variable number of items and therefore the number of parallel branches won't be known until runtime. What's needed is the equivalent of a typical programming language "for" loop where all the iterations of the loop are executed in parallel.
The Kitchens Online requirement to process the multiple items of an Order in parallel is a very common pattern. The <flow> activity introduced in BPEL 1.1 supported parallelism, but only when the number of parallel branches was known at design time. Here, an Order may have a variable number of items and therefore the number of parallel branches won't be known until runtime. What's needed is the equivalent of a typical programming language "for" loop where all the iterations of the loop are executed in parallel.
To address this pattern, BPEL 2.0 introduces the <forEach> activity. As the name indicates, this activity causes the enclosed scope to iterate between the <startCounterValue> and <finalCounterValue> inclusive (i.e., N+1 times, where N is the difference between the two). The <forEach> activity has an attribute parallel that when set to yes causes all the branches to be executed in parallel and a counterName attribute that specifies an integer variable that will hold the counter value for each particular iteration (1 for the first iteration in the example below, 2 for the second, etc.).
Learned a lot of new things from your post ,It's amazing blog
ReplyDeleteOracle SOA Online Course Bangalore