WebServices dot org

Do We Need This Animal Called 'BPEL4People'?

Process workflows are like the rivers that dot the planet; each one has its own unique sources and tributary streams, terrains to be travailed, and eventually emptying out somewhere, be it an ocean, bay, larger river, or lake. But there are also plenty of waterfalls, dams and locks on the way. Workflows are as unique as the companies that create them, and all have their own points where humans intercede.

Web services guru David Chappell (the consultant, not the Sonic Software David Chappell), points out that that BPEL is fine for developers that are looking to link XML Web services, but may not be as effective for business users within the enterprise at large, who are working with all sorts of local objects, legacy systems and data types. "Business processes commonly involve people," Chappell said. "BPEL was designed for system-to-system interactions, not interactions that involve human beings. Accordingly, it doesn't define mechanisms focused on interacting with people."

Responding to such concerns, IBM and SAP put forth an extension to BPEL called BPEL4People, intended to be "layered on top of BPEL as specification" describing a proposed extension to BPEL, intended to cover a "broad range of scenarios that involves people within business processes."

White paper available here .

As the IBM-SAP white paper explains it, "during the lifetime of a long-running business process, conditions that require human involvement can occur. An example of this would be if a process is stuck because no one has been assigned to perform a particular task. Another example would be if a process waits for input from human participants or Web services, and the input must be collected within a certain number of hours. If the timeout occurs, a user must be notified to decide how the process should proceed."

As BPEL exists today, getting a process "unstuck" would "require undoing parts of the business process. But if the business process has already run for multiple days, invoking partner operations, collecting results, and so on, compensation may not be desirable, since this wastes resources and efforts already spent." Thus an administrator will have to manually intervene to take the corrective action to get the process moving again.

BPEL needs to incorporate a "special kind of implementation of an activity - a communication step which may be called 'people activity.'" The paper defines people activities, simply, as "tasks performed by users," noting "there are scenarios where it is desirable to define which people are eligible to start a certain business process."

The BPEL4People proposal covers five key scenarios that presumably cover most of the types of interactions that occur within business process workflows. These consist of people activities, people initiating processes, people managing long-running processes, transition between human and automatic services, and advanced interaction patterns, such as the 4-eyes principle (commonly used in banking), escalation, and chained execution.

Bruce Silver, principal of Bruce Silver Associates, has been tracking the progress of BPEL4People, and thinks there may be a simpler way to close any gaps that BPEL leaves in the process flow.

The big issue with BPEL4People, Silver observes, is that "straight BPEL 2.0 engines won't be able to implement" BPEL4People's people activity. Currently, he explains, "virtually all BPEL-based BPMSs [Business process management solutions] handle human workflow today without a special activity type. Instead, they typically provide a task management service - an out-of-the-box Web service that manages human tasks - plus a Web application, typically called a Worklist, through which participants view, claim, and perform their assigned tasks. Standard BPEL calls human tasks by invoking the task management service. This service, external to the BPEL, performs task role resolution and state management, and monitors deadlines and escalation logic. When the task is complete (or failed), the task management service calls back the process with the results."

IBM and SAP decided not to go the external service route for BPEL 2.0 on philosophical grounds - human tasks are not 'first-class' participants in a business process mediated through an external service - as well as practical grounds, Silver explains. "When BPMS becomes pervasive, tasks will be supplied by application software vendors, and must be able to work with both standard BPMS engines and the application vendor's own workflow application. The variety of ways in which human tasks integrate with BPEL processes is at the heart of the BPEL4People challenge."

Silver states, however, that the current BPEL4People proposal is too "sweeping," as it calls for support of five inline and standalone task interaction models as part of a process flow. "Standardizing the portType and basic features of the task management service (both its process and Worklist interfaces) would be a more practical approach, perhaps adding something along the lines of a lifecycle state coordination protocol," he said.

IBM and SAP definitely hit the mark in identifying where weaknesses in BPEL may exist. We are only in the early stages of automating business process management, and have only begun linking business processes to SOA. Processes get touched many times, and sometimes are required to be by law or regulation. BPEL promises to speed up much of our workflows, but the points requiring human interaction may negate efficiency and speed gains. The question is whether BPEL4People - or other approaches - can compensate for the human equation.