BPEL: Future Directions

People have written tons of articles for BPEL, but I think it is good to write about the future directions of BPEL. Business Process Execution Language as the name suggests provide guidelines to orchestrate the business processes. BPEL 2.0 is the current specification but most of the SOA suits implements BPEL 1.1 specification. To make you aware about the changes from BPEL 1.1 to BPEL 2.0 I would like to compare these two specifications.

BPEL 1.1 vs. BPEL 2.0

BPEL 1.1 having a basic set of activities and lacking many features to build real life applications. BPEL 1.1 specification does not have inbuilt support for human task, sub processes, strong data manipulation, ACID transactions, modularization and reuse. The vendors providing implementation for BPEL specification implemented their own extensions for the missing features. The problem starts here, usage of vendor proprietary extensions it is very hard to manage portability and interoperability.

In BPEL 2.0 spec the specification team did a great job to improve the BPEL. They introduced the following changes:

• Improved data access.

• Improved data manipulation.

• Improve fault catching model.

• Added <terminationHandler> to scopes. Termination handlers provide the ability for scopes to control the forced termination to some extent. It is akin to the shutdown hooks of Java. We can create custom termination handlers or can rely on the default termination handler that would be implemented by the BPEL engines.
  

• New activities:

• <rethrow> - is used to throw the fault again that was originally caught by the immediately enclosing fault handler.

• <forEach> - Iterates its child scope activity exactly N+1 times where N equals the <finalCounterValue> minus the <startCounterValue>. It can be executed in sequential or parallel manner. If the attribute parallel="yes", then the N+1 instances of the enclosed <scope> activity SHOULD occur in parallel.

• <repeatUntil> - Iterates child activities until the specified <condition> becomes true. The <condition> is tested after the child activity completes. It is used to execute the child activity at least once. It is akin to do while loop of Java.

• <extensionActivity> - Used to introduce a new activity type to extend BPEL.

• <validate> - It is used to validate the values of variables against their associated XML and WSDL data definition.

• Syntactical changes, such as,

• From <switch> to <if>-<elseif>-<else>

• From <terminate> to <exit>

• Differentiate different cases of <compensate> by calling them <compensate> and <compensateScope>

See the following for what’s new in WS-BPEL 2.0
http://www.oasis-open.org/committees/download.php/20266/whats_new_in_bpel_2.0.ppt

Expectations from posterity:

Although BPEL 2.0 specification is more matured than BPEL 1.1, but it does not address all the issues BPEL 1.1 specification had. The new specification is not backward compatible so it requires migration of all the artifacts developed using BPEL 1.1 specification. Changes in syntax, data manipulation, compensation handling and new message access style, would make the migration a little bit hard and time consuming.

I feel in the next BPEL release the specification team should consider the following:

Human Task - BPEL specification should have human workflow features. We cannot say the specification complete without the support of human workflows.

Modularization and Reuse - BPEL specification should have support for modularization and reuse. Developers should be able to create process fragment and can use as and when required. These process fragments should be manageable, any changes in these fragment should not require changes at all the places these fragment have been used.

Certification for the BPEL engines - The specification authority should certify the BPEL engines for BPEL specification compliance.

Backward compatibility - Specification team should give a second thought to issues incurred due to syntactical changes and should define a policy for the BPEL engine vendors to support the old BPEL specifications.