jPDL specifies the execution flow of a process in terms of a directed graph of nodes. It includes a set of node types that intend to cover most routing scenarios. Furthermore, its flexibility allows including custom routing logic when facing an eccentric process scenario. In contrast, BPEL has a fixed set of structured activities represented by XML elements. They are nested together to model a particular execution path. Among them we can find control structures present in most programming languages like sequence, while and switch.

A more advanced structured activity worth mentioning is flow. It describes parallel paths of execution. Most importantly, it can declare links, which are control dependencies between its enclosed activities. Links allow for modeling directed graph flows, join conditions for synchronizing activities and even make it possible to detect dead paths of execution.

Below, a simplified version of the jBAY auction process coded in BPEL:

<process name="auction" targetNamespace="http://www.jBAY.com"
      xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">
  ...
  <sequence>

  <!-- Seller registers a sale offering and bids from the clients are received. -->
  <!-- The highest bid is taken. -->
  ...
  <flow>
  
     <sequence name="shippingSequence">
       <invoke name="sendItem" operation="shipItem" partnerLink="shipper"/>
       <receive name="receiveItem" operation="confirmDelivery" partnerLink="shipper"/>
      </sequence>

     <sequence name="billingSequence">
       <receive name="receiveMoney" operation="notifyDeposit" partnerLink="bank"/>
       <invoke name="sendMoney" operation="depositMoney" partnerLink="bank"/>
     </sequence>

   </flow>

  </sequence>

</process>

The receive and invoke elements nested in the structured elements of the jBAY process are basic activities. They perform the actual work. The receiveMoney and receiveItem activities act as wait states. In jPDL, any node that interrupts the execution path is a wait state, whereas in BPEL this behavior is given by the receive, wait and pick activities. In general, the execution of a process is only interrupted to wait for either an alarm to go off or a message to arrive.

jPDL's variable context is based on POJOs. Process data can be manipulated by inserting BeanShell code in a script node or invoking the methods of class ContextInstance inside action handlers. BPEL's variable context is made up by XML constructs. You can manipulate data within the assign activity using XPath expressions and in the receive and invoke activities, where message content is received either by an external call or by the return value of a service invocation.

Clients of a jPDL definition are expected to start or resume process instances through the jBPM API. Methods such as ProcessDefinition. createProcessInstance and Token. signal allow client code to interact directly with an executing process.

BPEL takes a different approach. Instead of defining its own APIs, it accommodates custom web service interfaces with which clients interact. These interfaces describe meaningful business operations and hide the fact that clients are actually "talking" to an orchestrator. In the next figure, the participants of the jBAY process interact with the auction endpoint. The orchestrator remains opaque.

Figure 2.1. Participants of the auction process

The service operations are connected to the process definition through inbound message activities. They mark entry points inside a process definition. When a client invokes their corresponding operation they respond in one of two ways:

jPDL processes use action handlers to invoke external services. Calls to Java component can be coded in an action handler and executed later inside a process. In BPEL, this behavior is achieved using the invoke activity.

Some business processes involve frequent interactions with heterogeneous systems or partners. In these cases interoperability is essential, and XML is the obvious data transfer format. If you run into a similar scenario, we encourage you to choose BPEL. Manipulating XML documents with Java or any other non-XML language is tedious, verbose and error-prone. BPEL alleviates much of this pain through the following features:

If this is not your case and you are mostly coordinating Java components, use jPDL. You will find it easier to use and you will be able to model practically any imaginable scenario by leveraging jPDL's workflow-rich features.