The BPEL4People Spec Extension

Within the arena of web services business processes, the upcoming WS-BPEL 2.0 standard focuses on orchestrating activities of multiple Web services. Missing from this specification is a distinction between services provided by applications and other interactions, such as those by humans.

Human interaction within a business process represents a fundamental paradigm shift in the definition and management of long-lived business processes. A likely proposed extension to BPEL (Business Process Execution Language) 2.0--BPEL4People--describes how to support "people activities" within the scope of the existing BPEL standards.

With BPEL4People, processes and tasks can coordinate their state, so that one can terminate the other, or at least request termination. Conventional or proprietary approaches, like Oracle's BPEL Process Manager, which uses a task manager service, do not allow for this.There is a clear need for standardization of human interaction in BPEL. BPEL4People is a potential solution, but right now it's nothing more than a white paper and far from a clear specification. If BPEL4People is to become an open specification, it must be submitted to OASIS for approval by the BPEL Technical Committee.

BPEL Foundation

On January 31, the WS-BPEL 2.0 specification reached Committee Specification status, which is one step before the OASIS BPEL Technical Committee gives final approval. Once that happens, the industry will have an open BPEL standard that is clear and precise; then it can focus on activities that were left out of WS-BPEL 2.0.

The OASIS BPEL Technical Committee intentionally left human interaction off its charter, which focused on refining and clarifying the existing scope of the specification. Attempting to address the topic would have meant postponing the finalization of the already late WS-BPEL specification. To fill the gap, SAP and IBM addressed the issue of human interaction with the BPEL4People white paper; now that WS-BPEL 2.0 is near completion, it's anticipated that the OASIS Technical Committee will define the standards for human interaction.

Although BPEL4People is only a white paper, it shows a great deal of promise and will likely mature into an actual OASIS spec. Don't expect vendors, however, to implement the proposed extensions just yet.

Human interactions in business processes range from the simple, such as a manual approval, to the complex, where users perform data entry. An example of a manual approval is the process for a new account request. A supervisor or administrator, or both, may need to approve the request prior to account creation. The supervisor may approve the request before it is routed to the admin, or perhaps both users can approve the request in parallel. A more complex process is one in which users may be required to enter data or change the state of running processes, such as initiate, suspend or resolve exceptions to a process. These interactions can prove to be the determining factor in whether a process succeeds or fails.

Clearly, human interaction can quickly complicate a business process. Most BPM systems associate tasks to roles and roles to users. Typically, this is done using a task-management service, which might have a Web-based front end for participants to view, claim and perform their assigned tasks. There is no standard for how human interaction should work across various BPM systems.

Continue Reading This Story...

Up With People

It makes sense that BPEL can serve as a platform for standardized human interaction. Although BPEL 2.0 doesn't directly address human interaction, it is appropriate for human workflows.Vendors providing BPEL implementations account for the lack of human workflow support by leveraging the asynchronous services that BPEL supports. In this approach, human tasks are represented as services that can be managed in standard fashion by the BPEL engine.

The BPEL4People white paper introduces two important extensions: people activity and people links. A people activity is a basic activity performed by a human being, rather than implemented by software. A people link maps a task to a human role, which is then resolved to specific users and groups at runtime. As seen in the figure below, BPEL4People anticipates the ways business processes and human tasks interact. The actor of a people activity is determined by a people link, used to represent the various groups who participate in the execution of the process.

The implementations of people activities by BPEL4People are specified as tasks--indivisible units of work performed by a human being. Task descriptions can be divided into multiple parts, so that a one-line summary displays in a task list, and a more detailed description displays when the user selects the task. Tasks also may have priority, deadline and user-interface properties. A user's assigned tasks belong to a worklist for which the priority attribute specifies the order in which the user should complete the task. The time before the user claims or completes a task can be represented as a deadline. If deadlines are missed, a person can intervene in the process and decide what action should be taken.

BPEL4People proposes that human tasks be first-class process components where processes and tasks can coordinate states, so either can request termination of the other. When a process specifies a people activity, it's explicitly clear that it will be performed by a human.Vendor support for BPEL4People is uncertain. While Oracle has pledged its allegiance, and IBM and SAP are sure supporters, it's unknown if the rest of the industry will follow suit. BPEL4People only discusses an approach to deal with human interaction; it doesn't specify a syntax of the new activities mentioned above, but if it becomes a specification, it will include a detailed syntax.

The industry needs a standard approach for governing human tasks. BPEL promises portability in business processes, but the points requiring human interaction may negate this effort. With BPEL 2.0 nearly complete, much effort and focus should be directed to BPEL4People. n

Erik R. Pieczkowski is an enterprise architect for Synegen, a Chicago-based consultancy. Write to him at [email protected].