WS-BPEL-Lifecycle of Business Process Instances

WS-BPEL

Operations are message exchanges. WSDL Web Services define a stateless model and an unordered set of operations.

However, among other features, a language used to define business processes has to at a minimum provide for the following:

• The ability to define rules for ordering operations,
• The ability to sequence a set of operations,
• Support to build a stateful business process,
• The ability to support long-running business interactions,
• A well-defined business process instance lifecycle,
• Provide support for concurrency, and
• Support choreography with external entities.

WS-BPEL is one such language that meets all the above mentioned criteria for a language used to define business processes. Since WSDL Web Services are stateless, messages that are exchanged in long-running business interactions need to be correlated to the right business process instance. As we discussed in an earlier blog entry, BPEL provides facilities that can correlate business-application specific data with business process instances.

Business process Instance:Business Process::Object:Class

A business process is a template definition to create new business process instances just as a class is a template definition to create new object instances . To quote an analogy, a business process instance is to its business process the same as an object is to its class definition.

As soon as a business process is defined using BPEL and is deployed, it is possible to create multiple instances of that business process which can run concurrently and completely independent of each other. In this blog entry, let us discuss how such business process instances are created and destroyed.

Programming languages like C++ and Java provide the new keyword to create an object of a class, and C++ provides the delete keyword for object destruction (in Java, object destruction is implicitly handled by the Garbage Collector at runtime). Contrastingly, in BPEL, creation and deletion of business process instances is implicitly handled by the BPEL Engine at runtime.

BPEL uses WSDL defined web services to communicate with partners.

Creation of a business process Instance:

At runtime, the BPEL Engine waits for a client partner to invoke a business process using the activity. A business process can also be waiting on a activity for the initial incoming message. The or activities have a createInstance attribute. If the activity ( or activity) has the createInstance element set to yes, the BPEL Engine creates a new business process instance. The business process can then perform other logic, or invoke several operations on other partners, or could also wait on partners to invoke callback operations. Once an instance is created using the createInstance attribute, any other activity in the same business process instance loses its ability to create new business process instances.

Destruction of a business process Instance:

A business process instance is implicitly destroyed by the BPEL Engine when either a normal termination occurs because its last activity completes successfully, or an abnormal termination occurs either because it encounters a activity, or a fault is encountered from which the instance cannot recover.

A web service client can start more than one interaction with a business process. For each new client invocation with a business process, a new business process instance is implicitly created as long as the createInstance attribute in the initial activity is set to yes as the following skeletal listing illustrates.

 ...
<sequence>
  <receive name="ReceiveFromCustomer" 
           createInstance="yes" 
           partnerLink="Customer" 
           operation="fileClaim" 
           portType="ns2:IFileClaim" 
           variable="FileClaimInput"/>
...

In cases where more than one activity needs to be enabled concurrently, correlation sets are used as was described in this blog entry. The following skeletal listing of the follower of a correlation gets the property values for their correlation sets from incoming messages. These subsequent steps match the data in the correlation set with the initialized data. A activity is triggered only if the data in the incoming message matches the values in the correlation set. An or activity must send out data that matches the data in the correlation set.

 ...
<invoke name="InvokeAddNewAdjustmentJob" 
        partnerLink="Adjuster" 
        operation="addNewAdjustmentJob" 
        portType="ns4:Adjuster" 
        inputVariable="AddNewAdjustmentJobInput"/>
        
<receive name="ReceiveSubmitAdjustment" 
         partnerLink="AdjusterCallback" 
         operation="submitAdjustment" 
         portType="ns2:IAdjusterCallback" 
         variable="SubmitAdjustmentInput" 
         createInstance="no">
    <correlations>
        <correlation set="claimNumber"/>
    </correlations>
</receive>
...

Note: All examples use the Insurance Claim Scenario described in this blog entry.