IT architectures have evolved to include process orchestration as a fundamental layer due in no small part to the emergence and widespread adoption of the WS-BPEL standard. WS-BPEL, also known as Business Process Execution Language or just BPEL, is a standard owned by OASIS that provides rich and comprehensive orchestration semantics. This article will provide a brief overview of how BPEL came to be what it is today and then focus on the latest developments in the BPEL standard and where we believe this standards area will go over the next few years. In particular some of the key areas for growth in this space include the standardization of human workflow support and better integration with process modeling and analysis tools and standards.
A Brief History of BPEL
Much of BPEL's broad adoption and acceptance comes from its ancestry. Historically, BPEL emerged when IBM and Microsoft joined forces and merged their proprietary workflow languages, WSFL and XLANG, respectively, into a next-generation business process language specification that at the time was called BPEL4WS (Business Process Execution Language for Web Services). BPEL4WS 1.0, known as the "license plate standard," was first publicly released in August 2002 by IBM, BEA, Microsoft, SAP, and Siebel Systems (BEA, SAP, and Siebel joined the initiative just before the publication of the specification.) Though BPEL was a new specification at the time, even then it was relatively mature due to its underpinnings, having been built on workflow languages that had been production tested over several years. This has benefited BPEL greatly, making it much more mature than its age would otherwise indicate. In fact, an educational institution in the Netherlands has published a site with an academic analysis of the comparative richness of workflow languages that demonstrates that while BPEL isn't perfect, it's better than any of its predecessors at implementing different workflow patterns. (see http://is.tm.tue.nl/research/patterns/standards.htm)
What BPEL Is Today
After BPEL4WS 1.0, a minor 1.1 upgrade was released in May 2003 and was submitted officially to OASIS. A WS-BPEL technical committee was assembled that is now one of OASIS' largest technical committees. From there, the standardization process slowed evolution significantly (as often happens...) and since then, OASIS has been working to release WS-BPEL 2.0. As such, most of the public implementations today of BPEL tools are based on the BPEL 1.1 specification. However, as BPEL 2.0 is very close to being finalized, several vendors including Oracle have implemented varying degrees of BPEL 2.0 functionality in currently shipping products.
In any case, BPEL has become deeply entrenched in the enterprise IT toolkit. We now see developers get excited about working on BPEL projects because it keeps their skills up-to-date. To get a sense of the current adoption of the BPEL standard, a search on a job search site, SimplyHired.com, for job postings with BPEL in their description yields hundreds of current job postings for BPEL-related positions (www.simplyhired.com/index.php?ds=sr&q=BPEL ).
Where We Are Going
People who are looking to point out weaknesses in the BPEL standard often comment that it does not include support for human workflow tasks. This is true, of course, even with the BPEL 2.0 standard. However BPEL does have rich support for asynchronous services and so one approach is to build a human workflow service engine that BPEL processes can then call out to. With this architecture, human tasks and manual steps can be incorporated in 100% standard BPEL process flows, just like any other asynchronous service. This architecture was detailed in a Web Services Journal article "BPEL Processes and Human Workflow" dated April 12, 2006 by Matjaz Juric and Doug H. Todd (http://webservices.sys-con.com/read/204417.htm). This approach has been adopted by several vendors including Oracle; we believe this provides a very clean architecture while the standardization process catches up in this area.
Going forward, we're already seeing the next generation of standards around BPEL being discussed. For example, the "BPEL4People" effort was first announced in late 2005 and is intended to standardize an approach similar to the one described above for incorporating human workflow tasks in BPEL processes. Besides being one of our favorite standards acronyms, BPEL4People is an important area of work since most business processes span both systems and humans. It also answers the question once and for all as to whether BPEL is properly pronounced "bepple," "bee-pull," or "bee-pell." (Answer - it must rhyme nicely with "people".)
Another area we see evolving is tighter integration between a process implementation language like BPEL and standards like BPMN that describe a business process modeling notation - a business analyst-friendly visual representation of a process. Since BPEL says nothing about the visual representation of a process and BPMN says nothing about the save format, they would seem like a perfect match. In practice, there are still some gaps to be filled, but in general we believe that tighter coupling between the standards (and tools) for business analysts and process developers will be a fantastic development for the IT world at large.
In the next sections we look in more detail at these growth areas that will expand the reach of business process standards and help BPEL achieve its full potential.
Process Orchestration
Business processes span services, applications, and human activities; these processes need to be orchestrated in an agile fashion with end-to-end control, visibility, and rich exception management. Process orchestration is the heart of Business Process Management enabling creation of executable business processes from services and human activities. Process Orchestration requirements include:
- Sequencing, including serial, parallel, and other control flow patterns
- Exception handling including error conditions, transactions, and compensation
- Data flow and transformation
- Event handling including timers and other out-of-band events (Figure 1)
BPEL today addresses these requirements in a mature fashion. Some of the salient features of BPEL include:
- Rich sequencing semantics including parallel and asynchronous processing
- A compensation-based long-running transaction model
- Rich scoped fault-handling capabilities
- Asynchronous event handling allowing time-based alerts as well as out-of-band events like a status request or cancellation event
- A Web service-based model for process decomposition and assembly: each BPEL process exposes a Web Services interface and can be easily composed into other higher-level compound flows
- Standard use of XML and XPath for data access and manipulation
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.