WS-BPEL 2.0 from OASIS - How it has progressed since BPEL 1.1

[IvanaTrickovic]

Episode 3 in the BPEL podcast series. This podcast is the third in a series of podcasts on BPEL. In the first two podcasts we gave an overview of what BPEL is used for, how it completes the SOA picture and explained important and unique concepts behind BPEL. This podcast is primarily intended for those who want to learn what is new in WS-BPEL 2.0 (public review draft) compared to BPEL4WS 1.1, which was initially submitted to OASIS and used as input for the work on version 2.0, and what new vocabulary is available for the business process expert or engineer. This is the complete series with new episodes following in the coming weeks:

1. BPEL in a Nutshell
2. BPEL Glossary for Developers
3. WS-BPEL 2.0 from OASIS - How it has progressed since BPEL 1.1
4. BPEL4People White Paper Overview
5. BPEL-SPE - Explanation of the joint SAP/IBM sub-processes white paper

But - if you have other suggestions our ears are tuned-to-the-max so let us know what you want after you've listened to this update on WS-BPEL 2.0. To find out about the other standards that SAP supports please check the standards pages in SDN. Alan & Ivana *new 20.06.2007 we've added this transcript* Reasonable accurate transcript: WS-BPEL 2.0 from OASIS – How it has progressed since BPEL4WS 1.1 This is the third in the series of podcasts aimed at preparing you for the latest developments taking place in BPEL. In the first two podcasts we gave an overview of what BPEL is used for, how it completes the SOA picture and explained important and unique concepts behind BPEL. Today’s podcast explains what is new in WS-BPEL 2.0 compared to BPEL4WS 1.1, which was initially submitted to OASIS and used as input for the work on version 2.0. Because BPEL4WS 1.1 is such a mouthful, we’ll just abbreviate that to BPEL 1.1 for this podcast. We learnt a lot of BPEL vocabulary and this time when we discuss the changes to the bpel capabilities and vocabulary, bearn in mind that much of it will be embedded directly in the graphical NetWeaver BPEL process modeler. Nevertheless, in a meeting discussing bpel processes, being able to use a term such as “foreach” saves a lot of rambling around trying to describe a scenario which is captured in one word. You’ve saved about ten minutes of everyone’s time. Ivana, First off - what were the business drivers for version 2.0? It must be acknowledged that version 1.1 gained lots of traction and I would say that the work on version 2.0 would not be half so successful without so broad adoption of version 1.1 by companies like SAP as well as the open source community. But it has been seen that ambiguities and gaps in version 1.1 must be resolved. And companies using it were eager to get their own extensions adopted into the standard. So why take BPEL to OASIS when it has already established itself as a standard. To understand this you need to look at the early history of BPEL. By merging their own proprietary xml-based process languages IBM and Microsoft swiftly created a technically sound standard that the IBM or Microsoft customers around the world could benefit from. Once the dust settled, it was a no-brainer for SAP and others to join and to support the specification in their own software platforms, such as SAP NetWeaver. But even though the licensing agreements for software using this specifications were unrestrictive, it is clear that a good standard benefits from the innovation brought in via other smaller software vendors or academic institutions. The specification was taken to Oasis to make it an open standard – that is a standard that everyone can contribute, to. The downside of adding democracy to the BPEL development process is that version 2.0 has taken two years to take it to the public review phase – where everyone can inspect and verify it before the final vote. However, the advantage of this democracy is more innovation and the creation of a truly open standard. Fine, so what the current status of BPEL 2.0 is? *at the the time the recording took place the specifications hadn't been approved but now they have been approved and released as expected.* The work on version 2.0 has been carried out by the OASIS WS-BPEL Technical Committee and is expected to be completed early next year. The first public review was completed 4 weeks ago. The Technical Committee addressed a number of comments received during the public review, some of which have been considered as substantial. Therefore the second public review must be conducted. After the second review it is expected that the committee specification will be submitted to the OASIS membership for OASIS standard approval. Version 2.0 will include a number of new features and improvements compared to BPEL 1.1. But the scope did remain the same. Version 2.0 is a more mature version of BPEL 1.1. Nevertheless, it will not introduce some key features, such as more direct data manipulation capabilities beyond XSLT-like functions and there will be no support for modularization and reuse so vendor-specific extensions might emerge to cover this. Now the term "process" is used loosely in a variety of ways to describe different things. What kind of processes can be expressed using BPEL 2.0? The technical committee identified that there is a spectrum of processes BPEL should cover. The spectrum ranges from snippets of BPEL code (also known as templates) to fully specified business processes (called executable processes). So, the Technical Committee decided to provide grammar needed for all these different flavors of processes. The specification introduces a grammar for executable processes, and a grammar for abstract or partially specified processes. In addition, the specification introduces two profiles of abstract processes - a profile for the observable behavior of Web services and a profile for templates. Both these profiles allow to define partially specified business processes and each of the profiles defines how to get an executable completion from a partially specified BPEL process. In version 1.1 we have had only two types of business processes: executable processes and abstract processes for observable behavior of Web services, but it has been seen that many people used there abstract processes for very different scenarios. Now, version 2.0 provides two profiles for the two most important scenarios for abstract processes and in addition allows defining other vendor-specific abstract process profiles. From the language architecture point of view this is an interesting change. Ivana, there are new types of activities that have been introduced in release 2.0. Forgive me for stealing some of your thunder, but my favorite is the forEach because this is something we’ve had in SAP Business Workflow since the very begining. I can remember showing this to the Americas user group in the early days and one of the audience got up and said “hey alan you’ve just saved our development team two weeks of programming. Yes, small word – big impact. The forEach forEach executes multiple instances of the same set of activities either in serial or in parallel. The number of instances is not defined at design time but at runtime, and is based on the value of a process variable. It is also possible to complete the execution of the activity prematurely if specified completion condition evaluates to true so in real business scenarios, where you don’t know for example how many items will end up in a shopping cart, it’s an absolute blessing. In addition, BPEL 2.0 version introduces a other new activities types:

• rethrow which allows to rethrow the original fault with the initial fault value caught by the nearest enclosing fault handler
• repeatUntil which is used to repeated the enclosed activity until the specified boolean condition evaluates to true. This activity could be seen as a macro, because the while activity was already available in version 1.1.
• Also, some activities have been renamed: activity switch is renamed into if-then-else, and activity terminate is renamed into exit.

Could you describe some of the other major changes, where we should take a closer look? The scopes model has been clarified and some new capabilities have been introduced, such as termination handlers. The compensation model is based now on new scope snapshot semantics. In addition, instead of allowing processes to catch standard faults, it is possible to specify using exitOnStandardFault that the process instance must *terminate* immediately when such a fault is thrown. Also it is possible to trigger time-based events periodically Some parts of the specification are clarified to remove ambiguity, like the fault handling during compensation and the impact of scope isolation on control links. In the case of Web services activities, there was a possible conflict between receive and reply activities, when there are multiple simultaneously incomplete receive activities which require a reply activity to complete. For that, a new attribute messageExchange is introduces which could be understood as an internal correlation of receive and reply activities. Also, it is allowed for these activities to specify XML schema variables instead of variables based on WSDL message types. Also, the BPEL 1.1 extension mechanism has been extended. The BPEL elements are made explicitly extensible, including assign activity and conditions. In case of conditions, it is allowed to use other expression languages even on the level of a single condition element. In 2.0 it is possible to specify which extensions are must be understood and which are optional. Version 2.0 also introduces a new activity type extensionActivity which is an explicit extension point and should be used for vendor specific activity types. Version 2.0 introduces support for documentation if the form of the documentation element. It is also mandated to import, using the import element all WSDL and XSD elements used in the BPEL process. Last but not least, a number of bugs have also been also fixed. A few elements available in version 1.1 are not available in 2.0, such as partners as they were covering parts outside of the BPEL scope. So, Ivana, you’ve described some of new elements and a lot of the tidying up which took place. Now this is a very rude question: Are there parts of the specification which in your opinion still need to be polished? Data manipulation capabilities are definitely one part which needed to be improved to make BPEL easier to use in practice. BPEL 2.0 includes a number of improvements. For example: 

• It provides infoset representation of BPEL process variables
• XPath expressions are simplified by leveraging XPath variable syntax to access variable data
• It is allowed to use XSD complex-type variable
• It is possible to define variable initialization as part of the variable declaration
• Copy assignments are clarified
• And the language introduces an XPath function to perform an XSLT transformation.
• In addition, in some scenarios it may happen that a usage of an assign operation produces invalid XML data which cannot be always checked at design time. Therefore, a new activity validate has been introduced to specify when XML data should be validated

Although the language provides a way to construct more complex XML documents, using the XPath function based on XSLT transformations, the language still misses to provide a more direct way for handling XML data. It should not be a surprise to see vendor-specific extensions for supporting data manipulation capabilities (such as appending data) in more direct way. How will SAP customers profit from implementing 2.0? SAP uses BPEL for exposing integration processes of the SAP Exchange Infrastructure. So, executable processes are of main interest to SAP. We extended version 1.1 with a few SAP-specific extensions which are now incorporated in version 2.0 and will become part of the standard. This means, there will be less SAP proprietary extensions. Also the abstract profile for templates can be used ín Exchange Infrastructure process templates. Does version 2.0 meet completely expectations of the community? Still there will be BPEL engines with extensions covering some features currently not included in BPEL 2.0, such as the concept of sub-processes and user interactions. So there is still some work to be done. Thank you Ivana, that concludes this podcast – the next podcast will talk about prospect of the future work, particularly BPEL4People. Thank you for listening, and enjoy the rest of your day.