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
WS-HumanTask defines human tasks, including their properties, behavior, and set of operations needed to manipulate them. Although WS-HumanTask is a sister specification to WS-BPEL4People and is expected to be widely used in conjunction with BPEL, it is designed to be a standalone specification, enabling invocation of tasks from any business process (BPEL or otherwise), as well as from any Web Services client. (Note that throughout this article, we use task as shorthand for WS-HumanTask task.)
BPEL4People uses BPEL's extension mechanisms to layer human interaction capabilities on top of BPEL. At the core of these extensions is People Activity, which enables a task to be invoked from a BPEL process. Other extensions bind people assignments to people directories, assign task properties, and manipulate tasks in BPEL processes.
Figure 1 shows the logical architecture of the BPEL4People specifications. A BPEL process invokes a People Activity (task). A WS-HumanTask engine manages the lifecycle of the task and provides interfaces to the client application for operating on the task. This separation of the process and the task engine allows both to be deployed, managed, and scaled independently. It also enables the use of a unified task engine working with multiple BPEL and other process engines, possibly from different vendors. WS-BPEL4People also enables inclusion of the task definition inline in the BPEL process.
People Roles
A key aspect of human interactions in a process is the definition of who is responsible for doing what. The BPEL4People specifications go beyond the notion of a task performer and include the following human roles:
- Actual owner: The actual owner of a task is the person doing the task. The actual owner can perform actions associated with the task as well as forward, suspend, and resume a task.Potential owners: The concept of potential owners is useful when multiple people - usually members of a named group - work on shared tasks. A potential owner becomes the actual owner by claiming the task.
- Excluded owners: When a task is assigned to a defined group of people, some users can be explicitly excluded from being a potential owner. This is particularly useful when having to ensure that the person reviewing a task is not the person performing it (the 4-eyes principle).
- Task initiator: A task initiator is the person initiating the task or the business process. The initiator can track the status of the task; collaboration with the initiator can also be needed to close the task.
- Task stakeholders and business administrators: Task stakeholders and business administrators are ultimately responsible for the oversight and the performance of the task. They can participate in the performance of the task, for example, by adding attachments or forwarding the tasks. They can also perform business administration functions such as suspending tasks or resolving missed deadlines. Task stakeholders are only assigned to a specific task instance; business administrators are assigned to all instances of a task type.
- Notification recipients: Anyone included on a notification list is classified as a notification recipient.
Assignments
To assign actual people to these various roles, the BPEL4People specifications support the static binding, late binding, and dynamic binding of people to roles. Assignments are made via:
- Literals: In its simplest form, people are literally assigned to roles using user identifier(s) and group name(s). This form of assignment is most common when tasks are assigned to named groups (or work queues).
- Logical people group: A logical people group represents a person or set of persons, or one or more named groups. A logical people group is bound to actual people and groups at deployment using a query, with zero or more query parameters, against a people/identity directory. This form of assignment is useful in scenarios such as skill-based assignment.
- Expressions: Expressions can be used in both a task definition and in the invoking BPEL process to assign people to roles. This form of assignment is most common when an assignment depends on the actual performer of a previous task, as when implementing the 4-eyes principle.
Delegation and Nomination
BPEL4People specifications support the assignment of task instances at runtime, particularly two common workflow patterns: delegation and nomination.
The BPEL4People specifications enable the definition of constraints on delegation. A task definition can specify that it can be delegated to anyone, to only potential owners as determined by assignment, to a specific set of people or named groups, or to no one. By default, tasks can be delegated to anyone.
As mentioned earlier, task stakeholders can assign task instances at runtime. This, in conjunction with the fact that a task can be created without an owner being assigned, enables a pattern commonly known as nomination in which business users overseeing the process nominate users to perform a task on an instance-by-instance basis.
Notifications
Notifications inform people of noteworthy events, call their attention to an action they need to take, or advise them of a change in status. The BPEL4People specifications treat notifications as a special case of human tasks; most of the task discussions in this article also apply to notifications. There are a few differences between notifications and tasks, for example, notifications are essentially one-way - the progress of the caller isn't blocked for the notification the way it is for a task. Notifications can be sent to multiple recipients and can be managed by one or many business administrators; the other roles do not apply to notifications. Notifications also don't have attachments, comments, or deadlines (these concepts, as applied to tasks, are discussed later in this article).
Timeouts and Escalations
A key benefit and requirement of managing human activities using a process or task engine is the ability to manage the timely performance of tasks and associated escalations.
The BPEL4People specifications allow multiple deadlines to be associated with a task. These deadlines can be start deadlines or completion deadlines. Both deadlines can be specified as a duration (period of time), or a deadline (point in time), and are calculated from the time the task is created. Expressions can be used to compute the deadlines at runtime, enabling both context-based deadlines (for example, deadlines based on order amounts or a customer's premium status) and the integration of a business calendar (for example, to compute the number of calendar days that correspond to three working days).
One or more escalations, with associated conditions, can be associated with a deadline. An escalation is triggered if the point of time specified as a deadline has been reached or the duration has elapsed, and the associated condition evaluates to true. Escalations can use notifications to inform people of the status of the task or reassign the task to different users or groups.
Deadlines and escalations are illustrated in Figure 2.
Task Lifecycle
To understand these task concepts as a complete picture, it helps to visualize the various task states and transitions. Figure 3 shows a simplified view of a task's lifecycle.
All tasks start in the Created state. A task remains in the Created state until it is activated (if scheduled activation is used) and has potential owners. If there are no potential owners, the task remains in the Created state until the business owner has performed nomination.
Once activated, a task moves into the Ready state if it has multiple potential owners (for example, when it is assigned to a group or a queue) or into the Reserved state if there is only a single potential owner. Tasks in the Ready state move into the Reserved state when one of the potential owners claims it.
Once the actual owner starts working on the task, it transitions into the In Progress state. Upon successful completion, it transitions into the Completed state.
A task in the Reserved or In Progress state can be released by the owners, moving it back to the Ready state, where it waits for another potential owner to claim it. A task in the In Progress state can be stopped by the owner, which moves it back into the Reserved state.
Tasks in an active state - Ready, Reserved, or In Progress - can also be delegated and forwarded by actual owners, potential owners, and business administrators. This transitions the task to the Ready or Reserved state, as appropriate. Business data associated with the task is maintained, including any updates.
The BPEL4People specifications allow some tasks to be skipped. A task, if skipped, moves into the Obsolete end state. Tasks can also be terminated, usually by the surrounding business process; terminated tasks also move to the Obsolete state. The BPEL4People specifications also allow any active task to be suspended and resumed. Suspended tasks resume to the state in which they were suspended.
Task Presentation and User Interaction
While the presentation of tasks via a client application or other mechanisms such as e-mail is outside the scope of the BPEL4People specifications, the specifications do include enough definition that enables a standard interface for task presentation.
Presentation elements in a task define how information about tasks is made available in a human-readable way. They include a name (a short title of a task), a subject (a longer text describing the task, and a description (a long description of the task, which can be in HTML). Both the subject and the description can be parameterized. Values for the presentation elements can be specified for multiple languages. Listing 1 illustrates the concept of presentation elements with an example.
A task definition can include rendering elements, which provide an extensible mechanism for specifying UI renderings for tasks.
The BPEL4People specifications also support attachments and comments, which are stored in the task operation data along with information on when they were added and by whom. Attachments and comments can also be shared between tasks and enclosing BPEL processes, as well as between different tasks.
The BPEL4People specifications also define standard programming interfaces that a task list client application can use to work against any WS-HumanTask-compliant implementation.
An Example: Help Desk
Listings 2 and 3 illustrate the concepts discussed in this article using a help desk scenario. The Help Desk BPEL process invokes three human activities: Resolve Ticket (task), Approve Resolution (task), and Notify User (notification).
The use of logical personnel groups to perform skill-based assignments is illustrated in Resolve Ticket task, which also illustrates the concept of potential owners (all service agents with matching skills) and business owner (the service center manager). The 4-eyes principle is illustrated in the invocation of the Approve Resolution task in which we exclude the performer of the Resolve Ticket from potential owners. The Resolve Ticket task also illustrates the use of deadlines and presentation elements.
What's Next
People often ask whether the BPEL4People specifications will cause changes to the BPEL specification itself. We do not anticipate such an impact. BPEL was designed with extensibility in mind, and the BPEL4People specifications comply with BPEL's extensibility mechanisms.
According to the OASIS BPEL4People Technical Committee charter, the standardization should take about 18 months. During this period, it's reasonable to expect that the standard will not only become more rigorous but also include more functionality. Two enhancements that we hope will make it to the final standard are patterns and policies. We'd like to see support for common routing patterns (such as management chain approvals and group votes) in a simple, intuitive, and declarative fashion. Likewise, support for policies such as automatic skip and exception handling would be a welcome addition.
While it's reasonable to expect that meaningful implementations of BPEL4People will be available only when the specification approaches the finish line, there are vendors, including Oracle, that essentially implement very similar concepts in a very similar architecture. In fact, the BPEL4People specifications were created by leveraging customer scenarios and requirements learned from support of such implementations.
Also, within the broader umbrella of related standards in the business process management (BPM) area, the next frontier is standardization of notation and its alignment with BPEL and BPEL4People. Significant efforts are underway at the Object Management Group to define a Business Process Modeling Notation (BPMN) 2.0 specification.
Summary
The field of Business Process Management (BPM) is experiencing renewed effort, propelled by the success of BPEL as a standard and its adoption by mainstream vendors and enterprises. BPEL skills, training, and resources are now widely available and the move away from proprietary skills and technologies is driving a lower total cost of ownership (TCO).
The BPEL4People specifications address BPEL's lack of explicit support for human interactions and remove one of the very few objections to BPEL. The BPEL4People architecture, which separates the task engine from the process engine, also significantly reduces customer risk, because many customers can have multiple process engines but prefer to have a unified task list application.
BPEL4People, along with BPMN, will complete the BPEL story for process management. We believe it will significantly increase the market adoption of BPM by mainstream enterprises.
References
- WS-BPEL Extension for People, Version 1.0.
- Web Services Human Task (WS-HumanTask), Version 1.0.
- OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee.
- InfoQ Interviews BPEL4People Representatives.
- A Close Look at BPEL 2.0.
- BPEL's Growing Up.
- BPEL Processes and Human Workflow.