|Read more about this book|
(For more resources on BPEL see here.)
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 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.
|Read more about this book|
(For more resources on BPEL, see here.)
The most important BPEL extensions, which IBM has introduced, are the following:
- Some additional BPEL activities, such as snippets, data maps, and generalized flows
- Human task activities for human interaction
- Support for additional BPEL properties, such as versioning using wpc:validFrom time stamps, timeouts, and so on
- Extensions for manually setting or controlling the transactional boundaries in a business process
The following table shows the most important extensions:
Another important extension is that WID, by default, uses Java as the expression language instead of XPath. Because the BPEL specification allows the use of other expression languages, this is not a problem. However, we should be aware of it.
WID also introduces some additional properties for BPEL activities such as description, documentation, display name, custom properties, and enable persistence and queries of business-relevant data. For the <process> activity, the following additional properties are available: auto-delete, autonomy (specifies whether a process runs as a peer or as a child of the invoking process), compensation sphere, valid from, and ignore missing data.
For example, on the next listing we can see some additional properties for the <process> tag. We can see, that these additional properties address error handling (continueOnError), type of BPEL processes, such as long-running processes or microflows (executionMode), validity (validFrom), and also display name (displayName):
There are also some extension activities available for specific activities: scopes can be flagged as non-compensable, expiration setting on the <invoke> activity, query properties on variables, usage of data type variables in messaging activities like <invoke>,<receive>, <reply>, <onEvent>, and <onMessage>.
We can select whether we wish to use the IBM-specific extensions or not. If we intend to execute the BPEL processes on the WebSphere Process Server, the extensions bring some additional functionality. We have to be aware that porting these BPELs to some other server will require some modifications. If we do not use the IBM-specific extensions, then only standard BPEL is used, which enables portability. We select whether to use extensions on the dialog box when creating a new process. Please notice that we can select this for long-running processes only. Microflows always use extensions.
|Read more about this book|
(For more resources on BPEL, see here.)
A BPEL process almost never exists alone. Usually it is connected with related services or other BPEL processes. In BPEL, we define these relations through partner links. However, WID provides an SCA (Service Component Architecture)-compliant approach, where we define the relations between service components graphically using the assembly diagram.
SCA emphasizes the decoupling of service implementation and of service assembly from the details of the access methods used to invoke services. SCA components operate at a business level. SCA defines two major steps in building SOA applications:
- The implementation of service components. Service components can be implemented in BPEL, Java, or other technology (such as adapter, legacy system, and so on).
- The assembly of service components through the wiring of service references to services.
The following screenshot shows a BPEL process InsuranceSelectionProcess. The BPEL process is wired to two services, InsuranceA and InsuranceB:
Imports and exports
In addition to wires, the assembly diagram also provides the possibility to generate exports and imports.
Exports and imports enable us to access components from other modules.
An export is an approach used to publish an interface of a component (for example, a service or a BPEL process) to make it accessible from outside this module. The InsuranceSelectionProcess from the previous example could be made accessible to clients outside the module. To achieve this, we would generate an export of the InsuranceSelectionPT interface. This is the interface of the InsuranceSelectionProcess BPEL process. An export has the same interface as the component on which we have made the export.
An import is a representation of the component from some other module. The component that we export in one module can be imported into another module and put on the assembly diagram as an import. We use imports exactly the same way as local components. This consistency provides a uniform assembly model for all components, regardless of their locations or implementations.
The example for the InsuranceSelectionProcess (shown in the previous screenshot) could also be developed in a way where both services, InsuranceA and InsuranceB, would be part of different modules. Then, they would need to be imported (using imports). Finally, the process itself could be made available through the web services SOAP protocol. For this, an export has been generated. The export is shown in the following screenshot.
Import and export bindings
Imports and exports require bindings. Bindings specify which transport protocol we will use for communication between the service component (provider) and service consumer (client). Bindings for imports and exports have different purposes.
An export binding describes how the service will be made available to service consumers (clients) outside the module. If an export in a module assembly does not have any binding, when deployed, SCA binding is assumed.
An import binding describes how an external service is bound to an import component. For an import that is generated from an export, the binding type of the import will be specified for you.
There are different types of bindings available:
- Web service
- Messaging (JMS, MQ JMS, generic JMS, and MQ)
- Enterprise JavaBeans
These bindings can be accessed from the following menu:
Web service binding makes the service available through SOAP. Several versions of the SOAP protocol are supported:
- SOAP 1.2 over HTTP using the JAX-WS programming model
- SOAP 1.1 over HTTP using the JAX-WS programming model
- SOAP 1.1. over HTTP using the older JAX-RPC programming model (also supports RPC-encoded messages)
- SOAP 1.1 over JMS (Java Message Service)
As we all know that SOAP is not the most efficient communication protocol, WebSphere also supports SCA binding. SCA binding provides the most efficient communication between service components in different modules. If modules are running on the same server, an SCA binding is the easiest and fastest to use. The same is also true for modules deployed in the same cluster. The SCA modules cannot be used if we would like to access a service from outside, for example from some other platform (.NET, for example). In this case, we can generate two exports for the same service.
A service component can have more than one binding. A usual approach is to generate an SCA and a web service binding.
Message bindings are used to enable interaction over a message-oriented middleware. The standard messaging system in Java is JMS. In addition to JMS, WebSphere also supports custom bindings for MQSeries. The following bindings are supported:
- Generic JMS binding
- JMS binding
- MQSeries (MQ) binding
- MQSeries JMS (MQ JMS) binding
Please do not confuse the JMS binding with the SOAP 1.1 over JMS binding. Although both bindings use JMS, the SOAP binding uses the SOAP protocol underneath, while JMS binding uses a proprietary protocol.
Another useful binding is the HTTP binding. HTTP bindings allow accessing the service through the HTTP GET, POST, PUT, DELETE, and other methods. This can be very useful, for example, for accessing a service from a web-based user interface (HTML form).
Enterprise JavaBeans binding allows a service component to communicate with EJBs using the RMI-IIOP protocol. Services behave similar to stateless session beans. This protocol also allows interoperability with CORBA (Common Object Request Broker Architecture).
In addition to bindings, WebSphere also provides a rich set of adapters. Adapters allow easy access to some commercial and existing systems such as CICS, IMS, SAP, Oracle E-Business Suite, PeopleSoft, JD Edwards, and many more. Adapters also provide access to email, FTP, or flat files.
In the above article we have covered:
- Long-running processes and microflows
- Overview of BPEL activities
- BPEL extensions
- Assembly diagram
- Business Processes with BPEL
- Human Interactions in BPEL
- Web Services, SOA, and WS-BPEL Technologies
- BPEL Process Monitoring
- Business Process Orchestration for SOA