Chapter 7: Introduction to BPEL

Overview

Business Process Execution Language (BPEL) is an XML-based language for creating a process, which is a set of logical steps (called activities) that guide a workflow like the following one:

1. Accept a request for an insurance quote.

2. If the submitted details are appropriate, calculate the quote and include it in the response.

3. Otherwise, say "No" and include a justification.

A BPEL process fulfills a workflow primarily by accessing one service after another. Each of those services is called a partner service.

Each BPEL activity is equivalent to a function call in a programming language or to a box in a flowchart. The receive activity waits for an inbound message, for example, and the invoke activity transmits an outbound message. Activities are categorized as either basic or structured. Basic activities (such as receive and invoke) do discrete tasks. Structured activities (such as if and while) specify an order or condition that affects the circumstance for running a set of other, embedded activities, which may be basic, structured, or both.

The running time for a BPEL process can be far longer than in other kinds of software. An insurance-claims process, for example, might wait to receive additional data from a specific customer for as long as the claim is active, even for years.

Listing 7.1 shows an excerpt from the BPEL process ProcessQuote.

Listing 7.1: Excerpt from BPEL process ProcessQuote

 <process name= "ProcessQuote">    <!- omitted namespaces, as well as         imports of WSDL  and XSD definitions ->    <partnerLinks>       <partnerLink name="ProcessQuote"          partnerLinkType="ProcessQuotePLT" myRole="ProcessQuoteRole" />       <partnerLink name="mainframeQuoteMgr"          partnerLinkType="PartnerLinkPLT" partnerRole="partnerRole" />    </partnerLinks003E    <variables>       <variable name="quoteRequest"                 messageType="placeQuoteRequestMsg" />       <variable name="highlightQuote"                 messageType="placeQuoteResponseMsg" />       <variable name="buildQuoteReq"                 messageType="buildQuoteRequestMsg" />       <variable name="newHighlightQuote"                 messageType="buildQuoteResponseMsg" />    </variables>    <sequence>       <receive name="processQuoteRequest" createInstance="yes"                operation="placeQuote" partnerLink="ProcessQuote"                portType="ProcessQuote" variable="quoteRequest">       </receive>       <assign name="AssignQuoteReq">          <copy>             <from variable="quoteRequest" part="placeQuoteParameters">                <query>/quoteInformation</query>             </from>             <to variable="buildQuoteReq" part="buildQuoteParameters">                <query>/customerQuoteInfo</query>             </to>          </copy>       </assign>       <invoke name="CalculateQuote" inputVariable="buildQuoteReq"               operation="buildQuote" outputVariable="newHighlightQuote"               partnerLink="mainframeQuoteMgr" portType="QuoteManagement" />          <assign name="AssignQuoteRes">          <copy>             <from variable="newHighlightQuote" part="buildQuoteResult">                <query>/quote</query>             </from>             <to variable="highlightQuote" part="placeQuoteResult" >                <query>/quote</query>             </to>          </copy>       </assign>       <reply name="processQuoteResponse"              operation="placeQuote" partnerLink="ProcessQuote"              portType="ProcessQuote" variable="highlightQuote" />    </sequence> </process> 

This excerpt

1. Creates partner links, which give details on the relationship between the BPEL process and each partner service

2. assigns variables, which are memory areas that are each described by a Web Services Description Language (WSDL) message but could have been described by an XML Schema element or type

3. receives a quote request

4. uses XPath syntax to copy data from the received message to a variable that is used for invoking another service

5. invokes the other service, which calculates and returns a quote

6. copies the quote details to another variable and in this way formats the response message

7. replies to the invoker, which may have been a Web application or a service

We'll not describe every detail, just yet.

In general, activities may

• run in a preset sequence

• run in a loop

• run on condition that a Boolean expression evaluates to true

• run immediately or wait for some period of time, even years

• run in response to an event that occurs after the process starts (specifically, in response to an inbound message, a calendar date and clock time, or the passing of time)

• run in an order that differs for different instances of the same process

That last option implies concurrency, which is a kind of processing in which several activities are issued more or less at the same time. A process may enable the receipt of messages from different services, for example, without requiring that one receipt precede another. Or a process may invoke several services without requiring that one invocation precede another. The general rule is that a service may fulfill several parallel streams (often called branches), each of which is a series of activities, with different streams running at once.

BPEL also has mechanisms for

• fault handling, as needed to respond to business errors (such as a request for an excessive credit line) and to technical errors (such as a network failure)

• compensation, as needed to reverse an action (such as a product purchase) that succeeded but was later found to be undesirable

• correlation, as needed to direct a message to the correct instance of a BPEL process

Two kinds of BPEL processes are possible. A BPEL executable process is itself a Web service and acts as the hub in a service orchestration. The software that runs an executable process is called a BPEL engine. One executable process can invoke another, with the effect of connecting one orchestration to another, as Figure 7.1 illustrates.

Figure 7.1: Connected orchestrations

A BPEL abstract process is similar to a BPEL executable process but includes a subset of the information. The abstract process is a description of business logic and can be used for the following purposes:

• to specify the behavior of one business unit or partner in a collaboration with others.

• to provide a design guide for programmers in your company and in partnering companies.

• to be an input to commercial software that creates skeletal code for a service implementation. The output may be in Java or some other language.

A BPEL abstract process can include all the content of a BPEL executable process, but omits implementation details in most cases.

When you create a BPEL process, you use two additional kinds of language. A query language lets you search for values that are embedded in an XML structure such as a message. An expression language lets you calculate numeric and datetime values, manipulate strings, and make comparisons. By default, BPEL uses XPath 1.0 in all cases. If your BPEL engine also lets you use an alternative language (such as Java) to create expressions, you can use XPath or the alternative at different points in the same process.

BPEL does not directly support file or database access and was not designed for extensive computation or string handling. However, the function doXslTransform lets you transform data from one XML structure to another. You might use the function to reorganize data received from one service, making the data appropriate for transmission to a second service. You also might use doXslTransform to reorganize data for internal use, either for easy comparison (for example, to place product details into a single table after receiving data from multiple suppliers) or for easy calculation (for example, to sum prices after receiving details about different input materials).

The next sections provide an overview of BPEL executable processes, and a subsequent chapter highlights event handlers and selected activities. Our comments reflect the WS-BPEL 2.0 specification, which was written under the guidance of the Organization for the Advancement of Structured Information Standards (OASIS). The specification is at http://www.oasis-open.org/committees/documents.php?wg_abbrev=wsbpel.

The following proposals for extending BPEL are under review by several companies:

• BPEL4People proposes a way to model human interactions as services: http://www.ibm.com/developerworks/webservices/library/specification/ws-bpel4people.

• BPEL Extensions for Sub-Processes proposes use of modular code in BPEL processes: http://www.ibm.com/developerworks/webservices/library/specification/ws-bpelsubproc.

• BPELJ proposes a use of Java in BPEL processes, as well as access of Java Enterprise Edition code from BPEL processes: http://www.ibm.com/developerworks/library/specification/ws-bpelj.