The Business Process Execution Language for Web Services (BPEL4WS, usually shortened to BPEL, which rhymes with "people") is, as its name suggests, a language for the definition and execution of business processes. Though it is not the only standard process language, BPEL is the most popular, and it's beginning to saturate the process space.

IBM, Microsoft, and BEA wrote the BPEL specification and subsequently handed it over to the WSBPEL technical committee of the OASIS organization (of which they are members) for standardization. The conceptual roots of BPEL coincide exactly with earlier BPM initiatives of each of the three companies: IBM's WSFL, Microsoft's XLANG, and BEA's Process Definition for Java (PD4J). WSFL is based on Petri nets and XLANG uses concepts of the pi calculus; BPEL, consequently, is a mixture of these two theories. PD4J is the basis for the Java extension to BPEL, known as BPELJ (see Figure 1).

BPELJ
"Pure" BPEL emphasizes "programming in the large," or the activity of defining the big steps of a process in a clean XML form; however, a process that is meant to actually run and be useful invariably has countless little steps, which are better implemented as lines of code than as activities in a process. Functions such as processing input, building output, interfacing with in-house systems, making decisions, and calculating dates either drive or are driven by the process, but are often too complex to encode as part of the process flow.

"Programming in the small" is essential to the development of real-world processes, but is hard to accomplish with pure BPEL. The best pure BPEL can offer is Web services: if a piece of logic is hard, develop it as a Web service and call it from the process with an invoke activity. This approach works, but it is grossly inappropriate. First, the reason for BPEL's emphasis on Web services is the goal of communicating processes. Partners call each other as services, but must a partner call pieces of itself as services? Second, the performance overhead of calling a service is obviously a showstopper; the process needs fast local access to the small logic components, as if they were an extension of the BPEL machine.

With these factors in mind, IBM and BEA have written a white paper that presents a standard Java extension of BPEL called BPEL for Java (BPELJ) (see the first entry in the References section). A BPELJ process, depicted in Figure 1, has chunks of embedded Java code, as well as invocations of separate plain old Java objects (POJOs), Enterprise Java Beans (EJBs), or other Java components. Though it still interfaces with its partner process through Web services, the process internally leverages Java to perform much of the hard work.

BPELJ is an obvious technology choice for companies that intend to deploy their processes on J2EE platforms such as BEA Weblogic and IBM WebSphere. The platform is already Java-enabled, so it is best to use Java capabilities in the construction of the process. Luckily, BEA and IBM are building to BPELJ.

Note: Current BPELJ vendor implementations are difficult to find. Two BPEL toolkits - the Oracle BPEL Process Manager 2.2 and IBM's WebSphere Application Developer Integration Edition 5.1.1 - have Java extensions, but they are proprietary. BEA is planning to develop a reference implementation of BPELJ and possibly release it as open source. Expect major Java application server vendors like BEA, IBM, and Oracle to be the earliest adopters and to evolve the language.

A Glimpse of BPELJ
Listing 1 demonstrates some of the core features of BPELJ. The red-colored parts are BPELJ-specific. The process receives a claim by a Web service request from a client application, then processes it using an EJB, and finally, if the claim is successful, publishes the request to a JMS topic for consumption by interested subscribers. The process extends core BPEL by defining partner links for Java components (lines 16-19), declaring Java variables (lines 25-26), using the invoke activity to call Java components (lines 37-40 and 51-53), using Java expressions to make decisions that affect flow (line 45), and embedding a snippet of Java code (lines 46-50). BPELJ features not included in this example include Java correlation, Java exception handling, and XML-Java binding.

Warning: Some of these changes are not supported by BPEL 1.1! The Java snippet in lines 46-50, for example, is illegal because BPEL does not support the addition of new activity types. Similarly, the input and output elements (lines 38-39) are not permitted in invoke and receive activities, and the condition (line 45) in the switch activity should be an attribute rather than a child element of case. In their joint whitepaper, BEA and IBM admit these incompatibilities and even suggest alternative approaches that are supported. For example, the snippet could be overloaded in the empty activity. The alternatives are onerous and unintuitive, which explains why the authors chose to cheat. BPELJ won't be ready for prime time until these issues are resolved.

BPELJ Source Code
The source code of a pure BPEL process is a set of XML files containing WSDL and BPEL process definitions. BPELJ source code can be either XML files with embedded Java code or Java source files annotated with XML. The former approach is the one adopted in the examples above; likewise, most of the samples in the BPELJ specification are XML with embedded Java.

The latter approach, documented in the BPELJ specification as a viable alternative, makes sense only if the number of lines of Java code is close to the number of lines of XML. Listing 2 shows a Java source file (MyProcessImpl.java) containing a comment in lines 1-15 that defines the BPEL process XML. The source file implements the class MyProcessImpl; the source code begins on line 16. Lines 17-20 implement a method that is called in the process on line 10.

A well-designed BPELJ process should be mostly pure BPEL with a smattering of Java. (Analogously, a well-designed Java Server Page is mostly markup with minimal embedded Java.) Significant Java processing can be factored out to special Java partner link types, whose source code resides in traditional Java source files, separate from the process. Consequently, XML-driven BPELJ is preferable to Java-driven BPELJ.

Note: BPELJ is conceptually similar to Process Definition for Java (PD4J) (JSR 207, www.jcp.org/en/jsr/detail?id=207), a specification proposed by BEA to the Java Community Process (JSR 207) for mixing XML and Java for process definition. PD4J is the design model for BEA's WebLogic Integration 8.1. BEA, along with IBM, authored BPELJ (also submitted to JSR 207), and is building to it for its Version 9 release of WebLogic Integration. PD4J favors the Java-with-annotated-XML approach, so perhaps WebLogic Integration 9 will adopt annotated Java as its development model.

Other Language Implementations
BPELJ is the first language extension of BPEL, extending BPEL's capabilities on Java platforms. The same approach is suitable for other programming languages, notably those that figure prominently into Microsoft's .NET platform, such as C#. Expect to see such implementations soon, as BPEL increases in popularity.

Summary
The main points of this article are as follows:

• BPEL was originally written by IBM, Microsoft, and BEA, but has been handed over to OASIS for standardization. BPEL is based on IBM's WSFL and Microsoft's XLANG.
• BPELJ introduces Java extensions to "pure" BPEL, such as the ability to define Java process variable, evaluate dates and conditions with Java code, and embed code snippets. Other powerful features include Java partner links (enabling invoke calls to local Java classes in addition to pure BPEL's partner Web services) and correlation based on Java classes.
• BPELJ source code can be XML with embedded Java or Java with annotated XML. The former approach is arguably better from a design perspective. The latter approach is influenced by BEA's PD4J model, used in WebLogic Integration 8.

This article has been excerpted from the book Essential Business Process Modeling by Michael Havey.

References