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