Wednesday, December 26, 2007

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.

6 comments:

Unknown said...

Nice blog on BPEL,
This is a request, kindly explain the usability of BPEL using any example.

snoop said...

Nice blog,

i will like to know if it is possible to use SAML, WS-Policy and SW-Security within a BPEL Process to invoke a secure Web Service

thanks

snoop said...

Nice blog,

i will like to know if it is possible to use SAML, WS-Policy and SW-Security within a BPEL Process to invoke a secure Web Service

thanks

Dharmendra said...

Yes, it is possible to use SAML, WS-Security tokens withing a BPEL process. Although its not available out of the box, we can pass these tokens as custom soap headers. I will address manipulating SOAP headers in Oracle BPEL in my next post.

sasitamil said...

I found your blog while searching for the updates, I am happy to be here. Very useful content and also easily understandable providing..
Believe me I did wrote an post about tutorials for beginners with reference of your blog. 




Selenium training in bangalore
Selenium training in Chennai
Selenium training in Bangalore
Selenium training in Pune
Selenium Online training

eTechno Soft Solutions said...

Thanks for sharing this Information. The information you Provided is much useful.

Best SAP Training in Bangalore for SAP, we provide the sap training project with trainers having more than 5 Years of sap training experience, we also provide 100% placement support.