Contents
[Update 2008-01-14] In January 2008, OASIS announced that consortium members had submitted a charter proposal for a new WS-BPEL Extension for People (BPEL4People) Technical Committee. Companies sponsoring the proposal include Active Endpoints, Adobe, BEA, IBM, Oracle, SAP, Software AG, and Sun Microsystems.
Update 2007-06: In June 2007, a group of six technology vendors, including Active Endpoints, Adobe, BEA Systems, IBM, Oracle, and SAP AG, announced the publication of "BPEL4People" specifications which define an approach for integrating human interactions using Web Services Business Process Execution Language (WS-BPEL) 2.0. In July 2005, IBM and SAP jointly issued a white paper "WS-BPEL Extension for People — BPEL4People." It describes scenarios where users are involved in business processes, and motivates and outlines appropriate extensions to WS-BPEL to address these scenarios. BPEL4People as released in 2007-06 is comprised of two specifications: WS-BPEL Extension for People (BPEL4People) Version 1.0 and Web Services Human Task (WS-HumanTask) Version 1.0. These two specifications take the ideas outlined in the white paper and together provide a concrete realization of them. BPEL4People extends the capabilities of WS-BPEL to support a broad range of human interaction patterns, allowing for expanded modeling of business processes within the WS-BPEL language. See "BPEL4People Specifications Integrate Human Interactions Into Business Process."
[August 26, 2005] An informal specification describing a proposed extension to the Web Services Business Process Execution Language (WS-BPEL) has been released by IBM and SAP AG in the form of a white paper WS-BPEL Extension for People — BPEL4People. The paper describes business scenarios where users are involved in business processes and defines appropriate extensions to WS-BPEL to address these.
The joint authors from IBM and SAP maintain that in order to support a broad range of scenarios that involves people within business processes, a WS-BPEL extension is required. BPEL4People "is defined in a way that it is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed"; additional BPEL extensions may be also be introduced which may use the BPEL4People extensions introduced in the white paper.
According to the paper Abstract, "Human user interactions are currently not covered by the Web Services Business Processes Execution Language (WS-BPEL), which is primarily designed to support automated business processes based on Web services. In practice, however, many business process scenarios require user interaction. The spectrum of activities that make up general purpose business processes is much broader than simply activities of which can be assumed to be interactions with Web services with no additional prerequisite behavior. People often participate in the execution of business processes introducing new aspects, such as human interaction patterns. Workflow tools already cater for the orchestration of user interactions."
For example, "people can be involved in business processes as a special kind of implementation of an activity — a communication step which may be called people activity. In some scenarios it is desirable to define which people are eligible to start a certain business process. During the lifetime of a long-running business process, conditions that require human involvement can occur; a process may be stuck because no one has been assigned to perform a particular task. In addition to simple task selection and execution actions, there are more complex patterns in the way humans interact with the process instances, and these need to be handled by BPEL4People. Sometimes it is not clear who should perform the task in hand. Escalation takes place if a task does not meet its modeled time constraints. If this occurs, a notification is sent to one or several people specified as escalation recipients using a people assignment definition."
A companion article authored by Ivana Trickovic (SAP) provides additional rationale for creating the BPEL4People extension: "Currently there is no standard that spans both the service orchestration and user interactions. Rather then developing a new specification that particularly covers user interactions, SAP and IBM determined that it is most suitable to extend the existing BPEL specification, or more precisely, version 2.0... The BPEL4People extension is layered on top of the BPEL language so that its features can be composed with the BPEL core features. It is envisaged that additional BPEL extensions may be introduced that may in turn use the BPEL4People extension. In this way it can be avoided to build a monolithic specification that would contain numerous features and rather be pursued a more modular approach by building separate extensions on top of the BPEL core features. This will allow implementations to support the core features and only those extensions that are needed with respect to the business case... The charter of the OASIS technical committee, which ultimately defines the scope of the work agreed by all members of the technical committee, does not mention this topic. Extending the charter would mean postponing the finalization of the work on the WS-BPEL specification."
Section 2 of the paper discusses scenarios, and the underlying concepts are explained in section 3. Section 4 discusses the features required to extend BPEL to support user interactions. It also considers the aspects of standalone human tasks that do not necessarily belong to BPEL processes. A summary of the work on BPEL4People is provided in section 5. A document Glossary and References are provided.
The "Features" section of the document describes six key features that need to be supported by BPEL4People extensions. People Integration involves Generic Human Roles, People Links, and People Resolution. People activities and processes have well-defined generic human roles defining what a person or a group of people resulting from a people query can do with them: for example, process initiator, process stakeholder, potential owner, business administrator. The group of people associated with a generic human role is determined by a people link. In order to determine the actual individuals associated with a people link, a query against an organizational directory is used, and this query is bound to the people link. People resolution is the act of identifying the people responsible for a particular generic human role."
People Activities, according to the proposed design, require a new BPEL activity which is not implemented by a piece of software, but realized by an action performed by a human being. Therefore, the actor of a people activity is determined by a people link; a people activity can be associated with different groups of people, one for each generic human role. A BPEL engine must process people activities differently from activities invoking Web services. When a people activity is initiated by a BPEL engine, the engine creates work items ('to-dos') for this activity and distributes them to all people eligible to perform it."
The IBM/SAP white paper also defines Tasks in terms of their key characteristics: their properties, operations offered for task client applications, task states, and the interplay of tasks and people activities. BPEL4People adds additional context information to the standard BPEL process — information about users participating in the process and ad-hoc attachments as well as the means to access this information.
As co-authors of the paper, IBM and SAP indicate plans to issue a formal specification of BPEL4People that defines the syntax and semantics precisely. The current prose specification is characterized as a "preliminary document" that may be changed substantially over time, containing information that represents the current view of IBM and SAP on the issues discussed as of the date of publication, but "should not be interpreted as a commitment on the part of IBM and SAP."
"There are compelling scenarios showing the need for more flexibility in fully automated processes which
assumes involvement of people. The WS-BPEL Extension for People — BPEL4People white paper published by SAP and IBM, describes how the BPEL language needs to be extended in principle to cover user
interactions with business processes. The value of the proposal is that it can be used as a basis for a solution that covers different flavours of processes ranging from fully automated processes to processes supporting different user interactions patterns, including ad-hoc collaborations...
Approach: Currently there is no standard that spans both the service orchestration and user interactions. Rather then developing a new specification that particularly covers user interactions, SAP and IBM determined that it is most suitable to extend the existing BPEL specification (more precisely version 2.0). Although the work on this version is still in progress, it is not expected that the BPEL core features will be changed dramatically.
The BPEL4People extension is layered on top of the BPEL language so that its features can be composed
with the BPEL core features. It is envisaged that additional BPEL extensions may be introduced that may in
turn use the BPEL4People extension. In this way it can be avoided to build a monolithic specification that
would contain numerous features and rather be pursued a more modular approach by building separate
extensions on top of the BPEL core features. This will allow implementations to support the core features and
only those extensions that are needed with respect to the business case.
The reader may wonder why this work has not been done within the OASIS WS-BPEL Technical Committee. The main reason is that the charter of this technical committee, which ultimately defines the scope of the work agreed by all members of the technical committee, does not mention this topic. Extending the charter would mean postponing the finalization of the work on the WS-BPEL specification.
The white paper is a first step towards synergy between traditional workflow technology and the business process management technology. SAP NetWeaver supports BPEL, as well as processes involving user interactions. BPEL4People fills the missing gap for SAP NetWeaver and SAP's customers in that it suggests a common model for designing both service orchestration and user interactions..." [see details in the full text]
The Web Services Business Process Execution Language Version 2.0 document defines a notation for specifying business process behavior based
on Web Services. This notation is called Web Services Business Process
Execution Language.. Processes in WS-BPEL export and import functionality by using Web Service
interfaces exclusively.
Business processes can be described in two ways. Executable business processes
model actual behavior of a participant in a business interaction. Business
protocols, in contrast, use process descriptions that specify the mutually visible
message exchange behavior of each of the parties involved in the protocol,
without revealing their internal behavior. The process descriptions for business
protocols are called abstract processes. WS-BPEL is meant to be used to model
the behavior of both executable and abstract processes.
WS-BPEL provides a language for the formal specification of business processes
and business interaction protocols. By doing so, it extends the Web Services
interaction model and enables it to support business transactions. WS-BPEL
defines an interoperable integration model that should facilitate the expansion of
automated process integration in both the intra-corporate and the business-tobusiness
spaces...
WS-BPEL uses a notion of message properties , which are a type of variable property, to
identify protocol-relevant data embedded in messages. Properties can be viewed as
"transparent" data relevant to public aspects as opposed to the "opaque" data that
internal/private functions use. Transparent data affects the public business protocol in a
direct way, whereas opaque data is significant primarily to back-end systems and affects
the business protocol only by creating nondeterminism because the way it affects
decisions is opaque. We take it as a principle that any data that is used to affect the
behavior of a business protocol must be transparent and hence viewed as a property.
The implicit effect of opaque data manifests itself through nondeterminism in the
behavior of services involved in business protocols. Consider the example of a
purchasing protocol. The seller has a service that receives a purchase order and responds
with either acceptance or rejection based on a number of criteria, including availability of
the goods and the credit of the buyer. Obviously, the decision processes are opaque, but
the fact of the decision must be reflected as behavior alternatives in the external business
protocol. In other words, the protocol requires something like an if activity in the
behavior of the seller's service but the selection of the branch taken is nondeterministic.
Such nondeterminism can be modeled by allowing the assignment of a nondeterministic
or opaque value to a message property, typically from an enumerated set of possibilities.
The property can then be used in defining conditional behavior that captures behavioral
alternatives without revealing actual decision processes. WS-BPEL explicitly allows the
use of nondeterministic data values to make it possible to capture the essence of public
behavior while hiding private aspects...
The basic concepts of WS-BPEL can be applied in one of two ways. A WS-BPEL
process can define a business protocol role, using the notion of abstract process. For
example, in a supply-chain protocol, the buyer and the seller are two distinct roles, each
with its own abstract process. Their relationship is typically modeled as a partner link.
Abstract processes use all the concepts of WS-BPEL but approach data handling in a way
that reflects the level of abstraction required to describe public aspects of the business
protocol. Specifically, abstract processes handle only protocol-relevant data. WS-BPEL
provides a way to identify protocol-relevant data as message properties. In addition,
abstract processes use nondeterministic data values to hide private aspects of behavior.
It is also possible to use WS-BPEL to define an executable business process. The logic
and state of the process determine the nature and sequence of the Web Service
interactions conducted at each business partner, and thus the interaction protocols. While
a WS-BPEL process definition is not required to be complete from a private implementation point of view, the language effectively defines a portable execution
format for business processes that rely exclusively on Web Service resources and XML
data. Moreover, such processes execute and interact with their partners in a consistent
way regardless of the supporting platform or programming model used by the
implementation of the hosting environment.
Even where private implementation aspects use platform-dependent functionality, which
is likely in many if not most realistic cases, the continuity of the basic conceptual model
between abstract and executable processes in WS-BPEL makes it possible to export and
import the public aspects embodied in business protocols as process or role templates
while maintaining the intent and structure of the protocols. This is arguably the most
attractive prospect for the use of WS-BPEL from the viewpoint of unlocking the potential
of Web Services because it allows the development of tools and other technologies that
greatly increase the level of automation and thereby lower the cost in establishing crossenterprise
automated business processes...
WS-BPEL defines a model and a grammar for describing the behavior of a business
process based on interactions between the process and its partners. The interaction with
each partner occurs through Web Service interfaces, and the structure of the relationship
at the interface level is encapsulated in what we call a partner link. The WS-BPEL
process defines how multiple service interactions with these partners are coordinated to
achieve a business goal, as well as the state and the logic necessary for this coordination.
WS-BPEL also introduces systematic mechanisms for dealing with business exceptions
and processing faults. Finally, WS-BPEL introduces a mechanism to define how
individual or composite activities within a process are to be compensated in cases where
exceptions occur or a partner requests reversal.
WS-BPEL is layered on top of several XML specifications: WSDL 1.1, XML Schema
1.0, and XPath1.0. WSDL messages and XML Schema type definitions provide the data
model used by WS-BPEL processes. XPath provides support for data manipulation. All
external resources and partners are represented as WSDL services. WS-BPEL provides
extensibility to accommodate future versions of these standards, specifically the XPath
and related standards used in XML computation..." [from the August 23, 2005 Version 2.0 Working Draft]
