Business Process Execution Language (BPEL)

Building a Business Process
by Matjaz B. Juric

A BPEL process specifies the exact order in which participating Web services should be invoked, either sequentially or in parallel. With BPEL, you can express conditional behaviors. For example, an invocation of a Web service can depend on the value of a previous invocation. You can also construct loops, declare variables, copy and assign values, define fault handlers, and so on. By combining all these constructs, you can define complex business processes in an algorithmic manner. In fact, because business processes are essentially graphs of activities, it might be useful to express them using Unified Modeling Language (UML) activity diagrams.

In a typical scenario, the BPEL business process receives a request. To fulfill it, the process invokes the involved Web services and then responds to the original caller. Because the BPEL process communicates with other Web services, it relies heavily on the WSDL description of the Web services invoked by the composite Web service.

Let's take an example. A BPEL process consists of steps; each step is called an "activity." BPEL supports primitive as well as structure activities. Primitive activities represent basic constructs and are used for common tasks, such as the following:

• Invoking other Web services, using <invoke>
• Waiting for the client to invoke the business process by sending a message, using <receive> (receiving a request)
• Generating a response for synchronous operations, using <reply>
• Manipulating data variables, using <assign>
• Indicating faults and exceptions, using <throw>
• Waiting for some time, using <wait>
• Terminating the entire process, using <terminate>
  

We can then combine these and other primitive activities to define complex algorithms that specify exactly the steps of business processes. To combine primitive activities, BPEL supports several structure activities. The most important are

• Sequence (<sequence>), which allows us definition of a set of activities that will be invoked in an ordered sequence
• Flow (<flow>) for defining a set of activities that will be invoked in parallel
• Case-switch construct (<switch>) for implementing branches
• While (<while>) for defining loops
• The ability to select one of several alternative paths, using <pick>

Each BPEL process will also define partner links, using <partnerLink>, and declare variables, using <variable>.

To understand how business processes are described with BPEL, you will define an oversimplified business process for employee travel arrangements: The client invokes the business process, specifying the name of the employee, the destination, the departure date, and the return date. The BPEL business process first checks the employee travel status, assuming that a Web service exists through which such checks can be made. Then the BPEL process will check the price for the flight ticket with two airlines: American Airlines and Delta Airlines. Again assume that both airline companies provide a Web service through which such checks can be made. Finally, the BPEL process will select the lower price and return the travel plan to the client.

Then, we will build an asynchronous BPEL process. We will assume that the Web service for checking the employee travel status is synchronous. This is reasonable because such data can be obtained immediately and returned to the caller. To acquire the plane ticket prices we use asynchronous invocations. Again, this is a reasonable approach, because it might take a little longer to confirm the plane travel schedule. We assume that both airlines offer a Web service and that both Web services are identical (i.e. provide equal port types and operations) to simplify our example.

In real-world scenarios, you will usually not have the choice about the Web services but will have to use whatever services are provided by your partners. If you have the luxury of designing the Web services and BPEL process at the same time, you will want to consider which interface is better. Usually you'll use asynchronous services for long-lasting operations and synchronous services for operations that return a result in a relatively short time. If you use asynchronous Web services, the BPEL process is usually asynchronous as well.

When you define a business process in BPEL, you essentially define a new Web service that is a composite of existing services. The interface of the new BPEL composite Web service uses a set of port types through which it provides operations like any other Web service. To invoke a business process described in BPEL, you have to invoke the resulting composite Web service. Figure 3 shows a schematic view of our process.

In developing the sample BPEL process, you will go through the following steps:

• Get familiar with the involved Web services
• Define the WSDL for the BPEL process
• Define partner link types
• Develop the BPEL process:
  • Define partner links
  • Declare variables
  • Write the process logic definition.
    

Next Page "Step 1: Inventory the Involved Web Services"