Business Process Execution Language (BPEL) is a non-proprietary, XML-based language developed by a group of major vendors including IBM, BEA, and Microsoft. Its function is to describe how Web Services interact with one another to form workflow systems that implement business processes. As a model and grammar for describing this behavior, it lets you implement complex processes by creating and wiring together different activities such as invoking a service, manipulating data, throwing faults, or terminating processes. With BPEL you can take a structured top-down approach to implementing a Service-Oriented Architecture (SOA).

The BPEL specification, like most first editions, is rather basic. While extremely powerful and flexible, it also had to gain agreement from all of its many contributors, and so it lacks some important features that make it more practical. Here is where IBM has distinguished itself by creating a useful set of extensions to the specification that increases BPEL's utility at least fivefold, making it immediately practical. They correspondingly enhanced the tooling to enable the highly effective development of BPEL-based business processes and services choreography.

Mostly likely, if you've been using BPEL with IBM's tools, you've taken many of the BPEL extensions for granted. This article offers an overview of these extensions, illustrates their use, and discusses the impact they have on service choreography. By the end of this article, one should have a better understanding of which elements are actually BPEL extensions - as opposed to regular elements of the specification - why they were made, what they were intended for, and how to take advantage of them.

Types of Extensions
BPEL extensions can be separated into two general groups, new entities and their entity extensions; and new attributes for existing entities and their attribute extensions. While there are only two extensions in the former group, there are a slew in the latter. Both types offer profound flexibility and convenience in designing processes, and without them it would be extremely awkward - if not impossible - to implement some of the capabilities they provide.

Entity Extensions
JAVA SNIPPET
As the name implies, a Java snippet allows a piece of Java code to be included in a process (see Figure 1). It doesn't make it into the BPEL specification because it's language-specific and including it would violate BPEL's goal of remaining completely language- and vendor-agnostic.

Java expressions, which are similar to Java snippets except that they aren't entities on their own, are useful in letting us include Java code that does work such as performing calculations and providing logic for other BPEL constructs like while, switch, and wait activities as well as links and joins.

It's important to note that Java snippets also provide a performance benefit by enabling the execution of local Java-based components that might otherwise have to be invoked in a high-overhead fashion such as a Web Service using a SOAP call (see Figure 2). However you have to consider that although there's a performance gain when the overhead of a SOAP invocation is removed, a component called directly through a Java snippet doesn't follow the same Web Service invocation semantics as the other service components of a BPEL process. This creates inconsistency that can lead to a higher maintenance cost later if the component eventually becomes remote to the process, exposed as a SOAP/HTTP service, etc., and can no longer be called through a Java snippet.

Another option that provides the same benefit is the Web Services Invocation Framework (WSIF). WSIF lets you invoke a Web Service regardless of the technology used to invoke the service. As long as the service can be described by WSDL, it can be accessed through WSIF, even if it's not actually invoked through a SOAP call. This means the service could be called through some other means, such as RMI/IIOP or even a local method call. IBM tools and software, such as WebSphere Studio Integration Edition and WebSphere Business Integration Server Foundation, provide built-in WSIF support.

STAFF ACTIVITY
A Staff Activity is an extension of an activity that provides a means to incorporate human interaction into a BPEL process (see Figure 3). No matter how much we automate our world, there will always be a need for human intervention and human interaction is often the norm in a business process. You can build a sleek, super-automated business process that runs on its own 99% of the time, but there are still times when human intervention and judgment are required.

For example, suppose a business process is built to automate loan approval workflow for a bank. A request for a loan can come with associated documentation, such as the customer's personal financial information, that will have to be verified. At this point a bank representative has to examine the documentation by hand and decide where to route the business process based on his analysis.

Here is where the Staff Activity fits in. One important limitation to note is that only an interruptible process can include a staff activity as one of its elements because the activity implies interruption. The process can then asynchronously interact with a human as illustrated in the loan example.

The Staff Activity serves a very important function that will be required in many business processes. Perhaps it should have been in the original BPEL specification. Perhaps it will be included in the next version.

Attribute Extensions
Autonomy Attribute: Reuse has long been a goal in the industry and it's considered a winning situation when it's achieved. Reusing an existing process, when done correctly, can pay benefits many times over. Fortunately it's very easy with BPEL processes and can be realized simply by having one process invoke another by using the invoke activity. However, it's important to understand the options available when doing this and to use them correctly.