WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7
Define, model, implement, and monitor real-world BPEL 2.0 business processes with SOA-powered BPM
- Develop BPEL and SOA composite solutions with IBM’s WebSphere SOA platform
- Automate business processes with WS-BPEL 2.0 and develop SOA composite applications efficiently
- Detailed explanation of advanced topics, such as security, transactions, human workflow, dynamic processes, fault handling, and more—enabling you to work smarter
Introduction
IBM provides comprehensive support for SOA through various products within the WebSphere product line. In this article, we will look at the most important products that provide support for BPEL. These will be:
- WebSphere Integration Developer, which is used for the development of BPEL processes (and several other SOA artifacts, such as services)
- Websphere Process Server, which is used for the execution of BPEL processes (and other SOA artifacts)
In this article, we use WebSphere Integration Developer 7.0 and WebSphere Process Server 7.0.
Let us now have a look at the BPEL support in WebSphere Integration Developer (WID). WID provides comprehensive support for BPEL and includes activities as specified by the BPEL specification. WID also provides some IBM-specific extensions for BPEL, which we will discuss later in this section.
First, we will look at long-running processes and microflows.
Long-running processes and microflows
We can use BPEL to orchestrate services. Such orchestrations can range from relatively simple integration scenarios, where a BPEL process invokes several services within the enterprise, to complex processes, where several services from different enterprises are invoked together with human tasks. Human tasks in BPEL processes allow us to include human interactions.
From the performance and transactional perspective, a process server can treat these two kinds of BPEL processes in a different way. Relatively simple BPEL processes that contain synchronous invocation of services only and execute in a relatively short time can be executed within a single transaction. A process server does not have to persist such processes.
Persisting a process means that the process server saves the states of activities, including the values of variables, to the persistent storage (database). We can look at the process flow as it has been executed and monitor the state of variables. This is sometimes called dehydration.
BPEL processes that include more complex, asynchronous invocations and also human tasks cannot be executed in a relatively short time. In special cases, such processes can take hours, days, weeks, or even months to execute. Such processes should be persisted and cannot be executed within a single transaction.
IBM WebSphere Process Server treats short-running and long-running processes differently. The developer has to decide at the time of development what type of process it will use. There are two options:
- Long-running processes
- Microflows
Microflows are best suited for short BPEL processes that contain a short series of activities that should be executed very quickly in the runtime environment. Microflows are not interruptible. They are contained within a single ACID (Atomicity, Consistency, Isolation, and Durability) transaction. Therefore, the microflow should not wait for external input (such as callback from a service using <receive> or >pick<). Microflows also cannot contain human tasks. The process server does not persist the state of microflows.
Long-running processes are best suited for BPEL processes that contain many activities and include parallel flows, external inputs, or human tasks. Long-running processes execute within several ACID transactions. Therefore, we have to set transaction boundaries. We will talk more about transaction boundaries later in this section. Also, please do not confuse ACID transactions and compensating transactions. A long-running process will use several ACID transactions; however, it will be able to compensate activities using the BPEL compensation handlers.
-
- Usually we select the type of the process when we create a new BPEL process in WID. We select a New Business Process. Then we define the name of the process, as shown in the following screenshot:
- Next, we select Long-running process or Microflow:
Here we also select whether we want to use the WebSphere BPEL extensions. We will discuss more about the WebSphere extensions later in this article.
Overview of BPEL activities
We develop BPEL processes in WID using a graphical development interface, where we drag-and-drop the various BPEL activities from the palette on the left-hand side to the main process flow:
The BPEL activities in WID are structured into the following groups:
- Basic Actions: Invoke, assign, receive, receive choice, reply, wait, empty action, snippet, data map
- Structures: scope, parallel activities, sequence, choice, while loop, repeat until loop, for each, generalized flow
- Faults: compensate, throw, rethrow, terminate
- Human Workflow: human tasks, collaboration scope
On the left, we can see familiar BPEL activities, such as Invoke, Assign, Receive, and so on. After dragging-and-dropping them to the process, we have to define several properties. We use the Properties tab:
We can set several different properties; some of them are a part of the BPEL language, and some of them part of the WebSphere execution environment.
Although WID in most cases uses the standard BPEL naming for activities, there are some cases where the naming differs. We list the differences in the following table:
Instead of using the graphical business process editor, we can always switch to the raw XML view of the BPEL process. In this case, we will see that behind the scenes the BPEL code is generated.
