Business systems and 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 Web Services Business Process Execution Language (WS-BPEL) standard. Most real-world processes involve some human interaction, for example, for approvals or exception handling. While WS-BPEL addresses the industry's need for rich and standard service orchestration semantics, it does not cover human interaction with processes. Efforts are underway to address this gap in WS-BPEL with a set of specifications commonly referred to as BPEL4People. In this article, we provide an overview of the BPEL4People standards and explore how this standards area will emerge over the next few years.

BPEL and People
BPEL is a standard owned by OASIS that provides rich and comprehensive orchestration semantics. At a high level, BPEL is a language that provides a rich set of activities and execution semantics to describe an executable business process. The processes and activities can be synchronous or asynchronous, short-lived or long-running. Many articles have been written on BPEL including "BPEL's Growing Up" and "A Close Look at BPEL 2.0," respectively, in the March 2007 and October 2007 issues of this magazine.

Typical business processes involve a mix of system and human interactions. People can be needed to make some decisions and approvals, perform tasks that are inherently manual (such as talk to a customer) or have not yet been automated, and manage exceptions in a process. People also need to be notified of interesting state changes and exceptions in a process.

BPEL's rich support for asynchronous services enables calls to an external workflow engine just as to any other asynchronous service. This architecture was detailed in an April 12, 2006 Web Services Journal article, "BPEL Processes and Human Workflow." However, there are certain aspects of human interactions that are unique. For example, a process must specify which task needs to be performed, as well as who the stakeholders are (and their interests), the expectations around performance of the task, and what should happen if the task is not performed within specified deadlines. Although BPEL can facilitate human interactions, its failure to fully grasp such interactions and their associated characteristics leads to two problems. First, every implementation achieves these goals by using proprietary extensions. Second, a lack of specific human interaction features makes the modeling of such interactions less intuitive and more verbose than it needs to be.

BPEL4People and WS-HumanTask Overview
In April 2007, BPEL finally became an OASIS standard. With standardization in place, it was time to start the process to standardize human interaction with BPEL. In June 2007, a group of six vendors - Active Endpoints, Adobe, BEA, IBM, Oracle, and SAP - published a set of two complementary proposed specifications, "WS-BPEL Extension for People" and "Web Services Human Task (WS-HumanTask)," together known as BPEL4People. In February 2008, the OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee was formed and started working on the two specifications.

The goals of these specifications are to enable both portability and interoperability by providing a standard definition of:

• BPEL extensions that define human interactions in BPEL processes
• Models that define human tasks
• Programmable interfaces that allow client applications to work with human tasks