BPEL Adoption
While the formal standardization of BPEL is nearing completion at OASIS, it has already gained significant market traction. Platform vendors such as Oracle are shipping commercial BPEL engines today and a Google search shows at least four available open source BPEL implementations. Eclipse has a project in progress to add comprehensive support for the authoring and editing of BPEL processes. And we are personally aware of thousands of production BPEL processes deployed by hundreds of customers. Finally, many companies now support BPEL as an interchange format. For example, modeling tool vendors including IDS Scheer and others support the generation of BPEL from their process modeling and analysis tools, which can then be shared directly with developers.

Since the BPEL 2.0 standard has yet to be released, most of the commercial and customer implementations of BPEL are based on the 1.1 specification. All of this enthusiasm around BPEL 1.1 leads to two natural questions:

1) What improvements can be expected in BPEL 2.0?
2) What migration effort will be required for current implementations to move to BPEL 2.0?

WS-BPEL 2.0
WS-BPEL 2.0, commonly known as BPEL 2.0, is the evolution of BPEL 1.1 as a public OASIS standard and is currently available as a draft for public review. In fact, by the time this article is published, standardization of WS-BPEL 2.0 may be complete. Some of the salient changes in BPEL 2.0 from BPEL 1.1 are:

• Improved data access - Data access has been improved in BPEL 2.0. Variable XPath binding makes BPEL variable data available in greatly simplified XPath expressions (where a $variable syntax can be used without requiring use of bpws:getVariableData). The example shown below illustrates how much simpler and more readable the BPEL 2.0 syntax is. BPEL 2.0 also adds support for variables based on XSD complex types.
• Improved data manipulation - BPEL 2.0 enables complex XML transformations in BPEL processes by introducing bpel:doXslTransform(). Other improvements include inline variable initialization and making the assign activity extensible. (Figure 2)
• New activities - BPEL 2.0 introduces some new activities, the most significant of which is forEach that executes a series of activities a variable number of times, either serially or in parallel. Early implementations of parallel forEach have been available for several years in the Oracle BPEL Process Manager as the flowN activity and were contributed to the OASIS discussion, which resulted in the new forEach activity. Other new BPEL 2.0 activities include repeatUntil, which repeats activities until a specified condition is true, and extensionActivity, which improves the ability of BPEL implementations to provide new activities.
• Enriched Fault Handling - BPEL 2.0 adds finer-grained controls in the catch construct and a rethrow activity. Some advanced fault-handling features have also been introduced such as a termination handler. (Figure 3)
• Advanced Message Operations - The most common example in this category is that BPEL 2.0 allows local partner links, another area where existing implementations can already be found. Note that having local partner links is a requirement in many cases, but is specifically needed in the forEach example above. If you want to be able to invoke many services in parallel with parallel forEach, you would need to create a separate partner link locally in each loop iteration and BPEL 2.0 explicitly allows this. (Figure 4)
• Syntax Improvements - Many changes in BPEL 2.0 are syntactical in nature; examples include changes from 'switch' to 'if-elseif-else' from 'terminate' to 'exit' and differentiating between cases of 'compensate' by calling them 'compensate' and 'compensateScope.'
• Clarifications - A number of changes in BPEL 2.0 clarify ambiguities in the 1.1 spec. Most of these have been driven by vendors with current BPEL implementations.

Migration from BPEL 1.1 to 2.0
As mentioned, many organizations are in production with processes built around the BPEL 1.1 specification and this group, including companies starting BPEL development today, is very interested in the effort that will be required to migrate from version 1.1 to 2.0. We see three factors that suggest this upgrade will be smooth and non-intrusive for most companies:

• Backward Compatibility - BPEL 1.1 and 2.0 syntaxes are mostly complementary. This enables vendors to provide backward-compatible support for BPEL 1.1 constructs along with BPEL 2.0 implementations.
• Syntactic Transforms - Many of the differences between BPEL 1.1 and 2.0 are purely syntactic. This allows XSLT transforms and other tools to automate much of the migration work. We can have a high degree of confidence in this because the BPEL 1.1 specification has been out for several years and the 2.0 standard has changed very little over the past year.
• Shared Pain - Finally, where tools can't do all the work and some manual migration is required, the large numbers of customers with this same need will encourage a broad set of best practices documents and examples to be made available.

Longer-Term: Process Model 'Round Tripping'
Involving business stakeholders in the analysis and modeling of business processes usually leads to fewer development iterations and a closer match between implementation and business requirements. This is a very common desire and in many cases the driver for adopting BPM. While BPEL vendors provide easy-to-use graphical tools for creating and editing BPEL processes, the very fact that BPEL processes are so detailed as to be executable makes these tools too complex for most business users. Instead, business users need to be able to specify higher-level process blueprints that can then be filled in by developers to make them executable.

Business Process Modeling Notation (BPMN) is a standard from OAG to address the above requirement. Using BPMN as a standard notation, business users may create process blueprints and share them with developers and other stakeholders. BPMN maps in a straightforward fashion to BPEL and developers can work on the BPEL view of the process to make it executable. It is possible for vendor tools to maintain round-tripping by anchoring the BPEL to the BPMN blueprint, though this requires extensions to one or both standards, in their current forms. This is an area in which we are actively working and have publicly demonstrated a common meta-model format that can be shared between a high level process modeling tool and an implementation level developer tool. By maintaining the high-level analyst annotations in the runtime BPEL code, we believe that the nirvana of full round-tripping between business analyst tools and developer tools can be achieved. In fact, the support for maintaining the high-level process model at runtime has already been leveraged by our Peoplesoft group for what they call a "you-are-here-list" that shows end users the runtime state of a business process based on the high-level process states defined by business analysts. (Figure 5)

Conclusion
Process orchestration is already a key component of integration, SOA, and BPM. BPEL 1.1 is a mature process orchestration language widely supported by vendors and is successfully addressing process orchestration requirements at many production customer sites today.

We believe customers who adopt BPEL and related standards for their BPM and SOA architectures will gain the following benefits:

• Comprehensive functionality
• Knowledge portability
• Toolset extensibility and "hot-pluggable" products
• Interoperability
• Vendor portability

In the very near future, WS-BPEL 2.0 will further mature the BPEL standard while providing a clean migration path for current BPEL implementations. Longer-term standards such as BPEL4People and BPMN will work closely and cleanly with BPEL to complete the puzzle and will help increase the market adoption of BPM by mainstream enterprises.