Section 5.4. BPELJ

5.4. BPELJ

"Pure" BPEL, examined previously, emphasizes "programming in the large," or the activity of defining the big steps of a process in a clean XML form. But a process that is

BPEL WISH LIST

As comprehensive as BPEL is, it can still be improved. The following standard enhancements would make BPEL more powerful and easier to code:

foreach

Include an activity that can iterate over a data set. (An example of iterating over a repeating XML element using a while loop and XPath is presented in the section "Implementing foreach." earlier in this chapter.)

XML creation and update

Enhance the assign activity to support the construction of XML elements or documents. For example, build a reply message using data from a request message.

Lightweight subprocesses or macros

Provide a mechanism to factor out a chunk of code into a modular piece, and provide the ability to call that piece with parameters in a lightweight fashion.

More sophisticated correlation

In addition to basic correlation set matching, allow a message listener activity (receive, pick, eventHandler) to filter on an arbitrary Boolean condition written in XPath or XQuery. In the example at the beginning of this chapter, the kill claim event handler triggers only if the kill message has the same claim ID as the original claim request. Supporting more complex queries would be desirable; for example, allowing the kill only if the claim amount is less than $1,000; the claim has been active for less than two business days; and the claim is not currently in escalation, activation, or rejection states.

Business calendars

Provide a standard way to reference business calendars in the calculation of timeout conditions in wait and onAlarm activities (e.g., have the process wait five business days for a particular event to occur).

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 calls 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).^[5] A BPELJ process, depicted in Figure 5-9, 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.

^[5] M. Blow, Y. Goland, M. Kloppman, F. Leymann, G. Phau, D. Roller, M. Rowley, "BPELj: BPEL for Java," http://www-106.ibm.com/developerworks/webservices/library/wl-bpelj, March 2004.

Figure 5-9. The "J" in BPELJ

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 toolkitsthe Oracle BPEL Process Manager 2.2 and IBM's WebSphere Application Developer Integration Edition 5.1.1have Java extensions (Oracle's is used in an example in Chapter 10), 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.

5.4.1. A Glimpse of BPELJ

Example 5-3 demonstrates some of the core features of BPELJ. The bold italicized parts are BPELJ-specific.

Example 5-3. BPELJ insurance automated claim

 1    <!- - Process attributes: 2          - expressionLanguage is Java by default. Can be overriden to, 3            say, XPath at the element level 4          - Java code embedded in process goes in to the Java package "com.mike.claim" 5          - The BPELJ namespace is referenced below. 6    <process name="InsuranceClaim" 7       suppressJoinFailure="yes" 8       expressionLanguage="http://jcp.org/java" 9       bpelj:package="com.mike.claim" 10       targetNamespace="http://mike.com/claim" 11       xmlns:tns="mike.com/claim" 12       xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" 13       xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" 14       xmlns:bpelj="http://schemas.xmlsoap.org/ws/2003/03/business-process/java"> 15 16       <!-- Three partner links: one a web service client interface, the others 17            Java internal stuff --> 18       <partnerLinks> 19          <partnerLink name="client" partnerLinkType="tns:Claim" 20             myRole="ClaimProvider"/> 21          <partnerLink name="claimProcessor" 22             partnerLinkType="bpelj:com.mike.claim.ClaimProcessorEJB"> 23          <partnerLink name="jmsPublisher" 24             partnerLinkType="bpelj:javax.jms.TopicPublisher"> 25       </partnerLinks> 26 27       <!-- Two variables, one an XML, the other Java --> 28       <variables> 29          <variable name="input" messageType="tns:ClaimsMessage"/> 30          <variable name="jmsMessage" messageType="bpelj:javax.jms.TextMessage"/> 31          <variable name="claimOK" messageType="bpelj:java.lang.Boolean "/> 32       </variables> 33 34       <sequence name="main"> 35        <!-- process starts by receiving a claim through the client web service --> 36          <receive name="receiveClaim" partnerLink="client" portType="tns:Claim" 37             operation="initiate" createInstance="yes"> 38             <output part="input" variable="input/> 39          </receive> 40 41          <!-- now invoke the Java claims processor as a partner link! --> 42          <invoke name="processClaim" partnerLink="claimProcessor" operation="execute"> 43             <input part="input" variable="input"/> 44             <output variable="claimOK"/> 45          </invoke> 46 47          <!-- if claim is ok, publish the original input on a JMS topic --> 48          <switch name="pubIfOK"> 49             <case> 50                <condition>claimOK</condition> 51                <bpelj:snippet name="createJMSMessage"> 52                   <!-- Use partner link topic publisher to allocate a JMS message 53                        and populate it with the claim input message. 54                        Note "p_jmsPublisher" is the way to reference the partner 55                        link "jmsPublisher" in BPELJ --> 56                   <bpelj:code> 57                      jmsMessage=p_jmsPublisher.getSession(  ).createTextMessage(input); 58                   </bpelj:code> 59                </bpelj:snippet> 60                <invoke name="PubClaim" partnerLink="jmsPublisher" operation="publish" 61                   <input part="message" variable="jmsMessage"/> 62                </invoke> 63             </case> 64             <otherwise> 65                <empty/> <!-- do nothing in this case --> 66             </otherwise> 67          </switch> 68 69       </sequence> 70    </process> 

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 was 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.

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.

5.4.2. 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. Example 5-4 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.

Example 5-4. BPELJ sample

 1    /** 2     * @bpelj:process process:: 3     * <process name="MyProcess"> 4     *  <variables> 5     *   <variable name="x" type="bpelj:Integer"/> 6     *  </variables> 7     *   . . . 8     *  <bpelj:snippet> 9     *   <bpelj:code> 10     *    x = self.getRandomValue (  ); 11     *   </bpelj:code> 12     *  </bpelj:snippet> 13     *  . . . 14     * </process> 15     **/ 16    public class MyProcessImpl implements Serializable 17    { 18       Integer getRandomValue(  ) 19       { 20          return new Integer(myRand.nextInt(  )); 21       } 22    } 

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),^[5] 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.

^[5] JSR 207, http://www.jcp.org/en/jsr/detail?id=207.

5.4.3. 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.