The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
qFAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: June 03, 2009
WS-BPEL for People (BPEL4People)

The Web Services Business Process Execution Language Version 2.0 (WS-BPEL) specification was published as an approved OASIS Standard in April 2007. References for WS-BPEL are presented in a separate document. WS-BPEL provides a language for the specification of Executable and Abstract business processes, extending the Web Services interaction model to support business transactions. However, the FAQ document published by the OASIS Web Services Business Process Execution Language Technical Committee recognizes that "BPEL was not designed for human workflow."

A document WS-BPEL Extension for People — BPEL4People was published as a Joint White Paper by IBM and SAP in July 2005. It describes business scenarios where users are involved in business processes and defines appropriate extensions to WS-BPEL to address these.

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. 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 IBM/SAP 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. The authors indicated an intent to submit the specifications to OASIS for standardization in the near future.

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. The proposed BPEL4People Technical Committee would define: (1) extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions, and (2) a model of human interactions that are service-enabled. This work will be carried out through continued refinement of the Version 1.0 documents released in June 2007, consistent with the WS-BPEL Extension for People — BPEL4People Joint White Paper published by IBM and SAP in July 2005. In particular, the new TC work will focus upon: (1) Defining the specification of a WS-BPEL extension enabling the definition of human interactions ("human tasks") as part of a WS-BPEL process; (2) Defining the specification of a model enabling the definition of human tasks that are exposed as Web services; (3) Defining a programming interface enabling human task client applications to work with human tasks.

Bibliographic Information

  • WS-BPEL Extension for People (BPEL4People) Version 1.0. June 2007. 52 pages. Copyright © 2007 Active Endpoints Inc., Adobe Systems Inc., BEA Systems Inc., International Business Machines Corporation, Oracle Inc., and SAP AG. By: Ashish Agrawal (Adobe), Mike Amend (BEA), Manoj Das (Oracle), Mark Ford (Active Endpoints), Chris Keller (Active Endpoints), Matthias Kloppmann (IBM), Dieter König (IBM), Frank Leymann (IBM), Ralf Müller (Oracle), Gerhard Pfau (IBM), Karsten Plösser (SAP), Ravi Rangaswamy (Oracle), Alan Rickayzen (SAP), Michael Rowley (BEA), Patrick Schmidt (SAP), Ivana Trickovic (SAP), Alex Yiu (Oracle), Matthias Zeller (Adobe).

    Available from IBM, Active Endpoints, SAP, and Adobe.

  • Web Services Human Task (WS-HumanTask) Version 1.0. June 2007. 133 pages. Copyright © 2007 Active Endpoints Inc., Adobe Systems Inc., BEA Systems Inc., International Business Machines Corporation, Oracle Inc., and SAP AG. By: Ashish Agrawal (Adobe), Mike Amend (BEA), Manoj Das (Oracle), Mark Ford (Active Endpoints), Chris Keller (Active Endpoints), Matthias Kloppmann (IBM), Dieter König (IBM), Frank Leymann (IBM), Ralf Müller (Oracle), Gerhard Pfau (IBM), Karsten Plösser (SAP), Ravi Rangaswamy (Oracle), Alan Rickayzen (SAP), Michael Rowley (BEA), Patrick Schmidt (SAP), Ivana Trickovic (SAP), Alex Yiu (Oracle), Matthias Zeller (Adobe).

    Available from IBM, Active Endpoints, SAP, and Adobe.

  • Earlier: WS-BPEL Extension for People — BPEL4People. A Joint White Paper by IBM and SAP. July 2005. 18 pages. Copyright (c) SAP AG and International Business Machines Corp 2005. Authors (alphabetically): Matthias Kloppmann (IBM), Dieter Koenig (IBM), Frank Leymann (IBM), Gerhard Pfau (IBM), Alan Rickayzen (SAP), Claus von Riegen (SAP), Patrick Schmidt (SAP), Ivana Trickovic (SAP). See the overview

  • Earlier: WS-BPEL 2.0 Extensions for Sub-Processes. A Joint White Paper by IBM and SAP. Copyright IBM, SAP AG. 13-October-2005. 17 pages. By Matthias Kloppmann (IBM), Dieter König (IBM), Frank Leymann (IBM), Gerhard Pfau (IBM), Alan Rickayzen (SAP), Claus von Riegen (SAP), Patrick Schmidt (SAP) and Ivana Trickovic (SAP). "Designing complex and large business processes requires a language that supports modularization and reuse in a portable, interoperable manner. This paper outlines an extension to WS-BPEL that allows for the definition of sub-processes that can be reused within the same or across multiple WS-BPEL processes. The paper describes different invocation scenarios and introduces a coordination protocol to be used for interoperable invocation of sub-processes across infrastructures from different vendors."

Resources from the Specification Authors

  • Active Endpoints: ActiveBPEL for People: Human Task and Workflow Integration for SOA-based BPM

    ActiveBPEL for People [Open Source Engine Project] "provides all the capabilities needed to create, test, deploy and manage human-centric business systems. By leveraging the full power of ActiveBPEL's loosely-coupled SOA foundation, organizations are assured that their workflow applications are highly interoperable and adaptable to business changes. Further, Active Endpoints' longstanding commitment to investment protection assures customers that they can build workflow applications today with the confidence that those applications will have an automated migration path to future SOA standards such as BPEL4People and WS-HumanTask. ActiveBPEL for People is an add-on module to the ActiveBPEL server and uses ActiveBPEL Designer for complete design, test, deployment and debugging. Relying on standards is the optimal way to build out SOA implementations that will be flexible, scalable and durable over time. Active Endpoints leveraged the WS-BPEL standard to develop tools, servers and services for quickly and easily integrating human tasks into any BPEL process..." See also eWEEK "Active Endpoints Delivers BPEL4People Tool."

  • Adobe Systems Incorporated: BPEL4People Overview.

    "Adobe and a group of leading technology vendors, including Active Endpoints, BEA Systems, IBM, Oracle, and SAP AG, have published BPEL4People, which proposes how human interactions can be integrated in the Web Services Business Process Execution Language (WS-BPEL) 2.0, which was approved by Organization for the Advancement of Structured Information Standards (OASIS) in April 2007. BPEL4People extends the capabilities of WS-BPEL to support a broad range of human interaction patterns, allowing for more complete modeling of business processes within the BPEL language...

    The creation and publication of these new specifications is a recognition of the importance of human interactions in real-world business processes, which lies at the heart of the Adobe LiveCycle Enterprise Suite... The Adobe LiveCycle ES platform provides comprehensive support for complex, human-centric business processes and offers a global in-box for task participants called LiveCycle Workspace ES. LiveCycle Workspace ES is an intuitive Adobe Flex-based interface that you can use to initiate new processes; sort, manage, and respond to assignments; escalate, delegate, and prioritize tasks; and search for existing processes.... Support for the BPEL4People specifications is in the Adobe LiveCycle ES product roadmap... Adobe participates in a number of industry initiatives (OASIS, OMG, and WFMC) to provide a set of interoperable standards in the area of business process management. The BPEL4People specifications complement the existing standards to support a broad range of human interaction patterns that were not described in previous specifications... Developers can use Flex and the BPEL4People specifications to build standards-based, rich, immersive applications that leverage a common model for human interactions, including human tasks and notifications, which simplifies the design of task-aware applications... Learn more about Adobe's support for human-centric business processes.

  • BEA Systems: announcement and BPEL4People overview.

    Jesper Joergensen noted that "BEA is uniquely positioned as the only vendor that fully supports both sets of technologies [XPDM/BPM - WS/SOA] and we are not promoting any one of them over the other. The process engine inside AquaLogic BPM Suite can run both XPDL 2.0 and BPEL 2.0 processes (in version 6.0 to be released very soon. Version 5.7 currently supports XPDL 1.1 and BPEL 1.1). The modeling environment supports modeling of both BPEL processes and "full-blown" business processes using XPDL for serialization... So we should expect both process styles to be deployed across the organization. At BEA we are supporting this future demand by having a process engine that supports both XPDL and BPEL as execution formats and a modeling environment that supports BPEL design and BPMN process modeling. Picking just one standard to support is a luxury that vendors cannot afford. While no one is interested in standards proliferation, it's rare to see a single standard dominate any technology area until it reaches full maturity. This is not the case for BPM either..."

  • IBM: WS-BPEL Extension for People.

    As presented in Human-based Web services (IBM developerWorks), "the transparent encapsulation of a human task as a Web service is not always desirable... Consider a more complex process where two different people need to approve a request (known as the four eyes principle or separation of duties). Such tasks need explicit representation as human tasks, not opaque Web services, because the rule used to select the second approver necessarily excludes the first approver. The BPEL4People extension for the Business Process Execution Language for Web services provides the extensions needed to extend business processes with embedded human tasks. It also addresses scenarios where human tasks are rendered as opaque stand-alone Web services that can be invoked from a BPEL process or a program written in Java, for example... Human-based Web services provide the ability to transparently include people as the service implementations in arbitrary service-oriented applications. Human tasks, as introduced with WebSphere Process Server, provide the infrastructure for human-based Web services. They are based on the staff functions known from classical human workflow systems, with their functionality extended to include sophisticated escalation and notification capabilities, as well as the ability to specify WebSphere Portal-based user interfaces for human tasks..."

  • Oracle: Oracle and the announcement.

    BPEL was designed for interactions between services that are modeled as Web services. This means that it doesn't say anything about human interactions and manual workflow steps. However, because BPEL has rich support for asynchronous services, it is possible to implement a human workflow service that makes people and manual steps look like any other asynchronous service from the perspective of the process. The advantage to this approach is that the BPEL process can stay 100% standard and yet both manual and automated systems interactions can be orchestrated easily. This approach is one that Oracle has taken with Oracle BPEL Process Manager's Human Workflow services. With this approach, user interactions can range from simple scenarios, such as a manual approval step in a process, to a complex scenario, where data must be entered by the user before the process can continue. There is now an active standardization effort underway, called BPEL4People, which aims to standardize this methodology for incorporating human tasks into BPEL processes..."

  • SAP AG: WS-BPEL Extension for People (BPEL4People), including the podcast on BPEL4People and WS-HumanTask.

    Acording to Alan Rickayzen, "we decided to split the specs into two. It is a tricky thing to do because you have to keep an eagle eye out for dependencies and sometimes go out of your way to find a good solution which would have been easy if it was all combined into one — but the advantages of doing this are huge. Tasks crop up in just about any software you deal with, approvals, help-desk tickets, request for information, carry out a repair... With this brace of specifications you plug the tasks into the processes instead of replicating the tasks into the process infrastructure which is what previously a lot of workflow software forced you to do... The paradigm is not new for SAP. In fact, since the early days it's been the applications building their own tasks with their own user interfaces with an underlying mechanism linked to the organization management (that's logical — a person is linked to a job- and the job description is a set of task descriptions) and these were plugged into the workflow as and when needed. The same methodology is used in SAP NetWeaver and other SAP products, too... WS-HumanTask differentiates between rendering of task meta data done by task list clients and task execution which is launched by task list client. The rendering of the tasks meta data (subject line, description of what has to be done, notification text) is part of the WS-HumanTask specification. So the user can be presented with this information using one user interface irrespective of how many different task infrastructures deliver the tasks... Because WS-HumanTask allows you to specify a UI rendering if you want, this means you can define this in such a way that the task list client can use this rendering description instead of invoking the task infrastructure (bingo) you have enabled your task for offline processing and a familiar UI for the user that isolates users from the different software below the surface. In fact, WS-HumanTask is flexible enough for you to delegate the rendering to the task list client even when no UI rendering is specified as part of the task infrastructure. We use this technique in SAP's universal worklist and Duet so that simple approvals appear identical to the end user, irrespective of the source of the approval..."

BPEL4People References: Short List

[TBD]

Excerpts from the Specifications

BPEL4People (2007) is comprised of two specifications including:

  • WS-BPEL Extension for People, which layers features on top of WS-BPEL to describe human tasks as activities that may be incorporated as first-class components in WS-BPEL process definitions.
  • Web Services Human Task, which introduces the definition of stand-alone human tasks, including the properties, behavior and operations used to manipulate them. Capabilities provided by Web Services Human Task may be utilized by Web services-based applications beyond WS-BPEL processes.

Excerpt from WS-BPEL Extension for People

The BPEL specification [itself] focuses on business processes the activities of which are assumed to be interactions with Web services, without any further prerequisite behavior. But the spectrum of activities that make up general purpose business processes is much broader. People often participate in the execution of business processes introducing new aspects such as interaction between the process and user interface, and taking into account human behavior.

The WS-BPEL Extension for People specification introduces a set of elements which extend the standard BPEL elements and enable the modeling of human interactions, which may range from simple approvals to complex scenarios such as separation of duties, and interactions involving ad-hoc data. The specification introduces the people activity as a new type of basic activity which enables the specification of human interaction in processes in a more direct way. The implementation of a people activity could be an inline task or a standalone human task defined in the WS-HumanTask specification. The syntax and state diagram of the people activity, and the coordination protocol that allows interacting with human tasks in a more integrated way is described. The specification also introduces XPath extension functions needed to access the process context...

Section 3.1 "Generic Human Roles": Process-related generic human roles define what a person or a group of people resulting from a people assignment can do with the process instance. The process-related human roles complement the set of generic human roles specified in WS-HumanTask. There are three process-related generic human roles: Process initiator, Process stakeholders, and Business administrators.

Process initiator is the person associated with triggering the process instance at its creation time. The initiator is typically determined by the infrastructure automatically. This can be overriden by specifying a people assignment for process initiator. Compliant implementations MUST ensure that at runtime at least one person is associated with this role.

Process stakeholders are people who can influence the progress of a process instance, for example, by adding ad-hoc attachments, forwarding a task, or simply observing the progress of the process instance. The scope of a process stakeholder is broader than the actual BPEL4People specification outlines. The process stakeholder is associated with a process instance. If no process stakeholders are specified, the process initiator becomes the process stakeholder. Compliant implementations must ensure that at runtime at least one person is associated with this role.

Business administrators are people allowed to perform administrative actions on the business process, such as resolving missed deadlines. A business administrator, in contrast to a process stakeholder, has an interest in all process instances of a particular process type, and not just one. If no business administrators are specified, the process stakeholders become the business administrators. Compliant implementations must ensure that at runtime at least one person is associated with this role.

Language design: The BPEL4People extension is defined in a way that it is layered on top of BPEL so that its features can be composed with BPEL features whenever needed. All elements and attributes introduced in this extension are made available to both BPEL executable processes and abstract processes. The extension introduces a set of elements and attributes to cover different complex human interaction patterns, such as separation of duties, which are not defined as first-class elements...

Excerpt from Web Services Human Task

Human tasks, or briefly tasks enable the integration of human beings in service-oriented applications. This document provides a notation, state diagram and API for human tasks, as well as a coordination protocol that allows interaction with human tasks in a more service-oriented fashion and at the same time controls tasks' autonomy. The document is called Web Services Human Task...

Human tasks are services implemented by people. They allow the integration of humans in service-oriented applications. A human task has two interfaces. One interface exposes the service offered by the task, like a translation service or an approval service. The second interface allows people to deal with tasks, for example to query for human tasks waiting for them, and to work on these tasks.

A human task has people assigned to it. These assignments define who should be allowed to play a certain role on that task. Human tasks may also specify how task metadata should be rendered on different devices or applications making them portable and interoperable with different types of software. Human tasks can be defined to react on timeouts, triggering an apropriate escalation action.

This also holds true for notifications. Notifications are a special type of human task that allows the sending of information about noteworthy business events to people. Notifications are always oneway, i.e., they are delivered in a fire-and-forget manner: The sender pushes out notifications to people without waiting for these people to acknowledge their receipt...

The goal of this specification is to enable portability and interoperability:

  • Portability — The ability to take human tasks and notifications created in one vendor's environment and use them in another vendor's environment.
  • Interoperability — The capability for multiple components (task infrastructure, task list clients and applications or processes with human interactions) to interact using well-defined messages and protocols. This enables combining components from different vendors allowing seamless execution.

The WS-HumanTask language introduces a grammar for describing human tasks and notifications. Both design time aspects, such as task properties and notification properties, and runtime aspects, such as task states and events triggering transitions between states are covered by the language. Finally, it introduces a programming interface which can be used by applications involved in the life cycle of a task to query task properties, execute the task, or complete the task. This interface helps to achieve interoperability between these applications and the task infrastructure when they come from different vendors.

WS-HumanTask utilizes the following specifications: WSDL 1.1; XML Schema 1.0; XPath 1.0; WS-Addressing 1.0; WS-Coordination 1.1; WS-Policy 1.5...

OASIS BPEL4People TC: Issues, SourceForge SVN, CVS Server, ChatRoom, Subcommittees, Documents, Archives

The OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee was chartered to define: (1) extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions and (2) a model of human interactions that are service-enabled.

BPEL4People Specification Milestones

Highlights of specification development (reverse chronological order):

General: News, Blogs, Commentary

  • [April 28, 2008] "InfoQ Interviews BPEL4People Representatives." By Mark Little. From InfoQueue (April 24, 2008). In this interview, held at the time of the first OASIS BPEL4People technical meeting, InfoQ spoke with several of the authors of the BPEL4People and WS-HumanTask specifications. Three of the authors were asked about the history of the specifications, how they see them fitting within BPM and whether they will divide the community as much as BPEL has so far. Manoj Das is Director of BPM Product Management at Oracle; his focus is on BPMN, BPEL, Workflow, and Business Rules. Dave Ings is a Program Director in the IBM Software Standards group, and is currently the chair of the OASIS BPEL4People technical committee. Ivana Trickovic is a standards architect in SAP's Industry Standards Group. Since before it was first announced that BPEL4People/WS-HumanTask were heading for a standards body, there has been a lot of interest around this new attempt to provide a standard in BPM. BPEL (aka WS-BPEL) has continued to split the workflow community, so isn't this the same fate for BPEL4People? WS-BPEL is primarily concerned with defining Web services-based executable processes. The primary goal of BPEL4People was to extend BPEL to support human user interactions as part of a BPEL process. BPEL4People is an extension layered on top of BPEL. While BPEL provides all the mechanisms needed to orchestrate people interactions, it does not differentiate between people activities and system activities. What we find is that people activities have many particular characteristics, which are mentioned in the earlier response; while these can be addressed in BPEL, it would be a lot more complicated. In many ways, an analogy is trying to do object-oriented programming with C. By addressing the important aspect of people interactions in a powerful and intuitive manner, BPEL4People will pave the way for BPEL to become the lingua franca for BPM. Typically, business processes require human involvement, e.g. to comply with some regulations it is necessary to implement the 4-eyes principle. For these kinds of business processes a more direct integration of different human interaction patterns in WS-BPEL is needed. BPEL4People addresses exactly that... The donation of BPEL4People to OASIS marks an important milestone in the development of BPM standards. We think the next big step for BPM standards is to provide a similar level of standardization for modeling notation. Towards this goal several of the BPEL4People authors are actively participating in the Business Process Modeling Notation (BPMN) 2.0 work at the Object Management Group... The next major piece of work is in the area of process notation, including its alignment with BPEL and BPEL4People. First class support for common human workflow patterns may also emerge... Parallel with the BPEL4People standardization activity we would like to make sure this extension of BPEL and the related OMG work on Business Process Modeling Notation (BPMN) are aligned so that human interactions can be modeled with BPMN as well...

  • [March 25, 2008] "Workflow Resource Patterns as a Tool to Support OASIS BPEL4People Standardization Efforts." By Nick Russell and Wil M.P. van der Aalst (Department of Technology Management, Eindhoven University of Technology, GPO Box 513, NL5600 MB Eindhoven,The Netherlands). From BPTrends (March 2008). 26 pages. "On 14 January 2008, OASIS announced the formation of the WS-BPEL Extension for People (BPEL4People) Technical Committee, a group charged with defining "1. extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions, and 2. a model of human interactions that are service-enabled". This announcement builds on the earlier assertion by OASIS that 'BPEL was not designed for human workflow', and it lays down a process for enhancing WS-BPEL 2.0 with capabilities that recognize the importance of human resources and their interactions in the context of business processes. This is an important advance in the BPEL standards family, which to date has largely focused on the orchestration of automated web services... It is ironic, given the level of commercial input into the overall development of the BPEL standard, that it had two major omissions: (1) a lack of recognition that business processes are generally hierarchical in form (resulting in the omission of the notion of subprocesses) and (2) a lack of consideration that business processes generally have some form of human involvement... As part of the standardization process, these proposals are still open to comment in order to ensure that they meet with general acceptance before being finalized as standards. However, one of the difficulties with evaluating new standards initiatives is in finding a suitable conceptual basis against which their capabilities can be examined and benchmarked. In order to assist with this activity, this paper proposes the use of the workflow resource patterns, as a means of evaluating the BPEL4People and WS-HumanTask proposals. The resource patterns provide a comprehensive description of the various factors that are relevant to human resource management and work distribution in business processes. They offer a means of examining the capabilities of the two proposals from a conceptual standpoint in a way that is independent of specific technological and implementation considerations. Through this examination, we hope to determine where the strengths and weaknesses of these proposals lie and what opportunities there may be for further improvement. The resource patterns were developed as part of the Workflow Patterns Initiative, an ongoing research project that was conceived with the goal of identifying the core architectural constructs inherent in workflow technology. The original objective was to delineate the fundamental requirements that arise during business process modeling on a recurring basis and describe them in an imperative way. A patterns-based approach was taken to describe these requirements as it offered both a language-independent and technology-independent means of expressing their core characteristics in a form that was sufficiently generic to allow for its application to a wide variety of offerings. To date, 126 patterns have been identified in the control-flow, data, and resource, perspectives, and they have been used for a wide variety of purposes, including evaluation of PAISs, tool selection, process design, education, and training. The workflow patterns have been enthusiastically received by both industry practitioners and academics alike. The original Workflow Patterns paper has been cited by over 150 academic publications, and the workflow patterns website has been visited more than 100,000 times... [See http://www.workflowpatterns.com/.] We examine the intention and coverage provided by the BPEL4People and WSHumanTask proposals from various perspectives, starting with their intention and relationship with related proposals and standards and then examining their informational and state-based characteristics on a comparative basis against those described by the workflow resource patterns... We hope that the observations and recommendations [...] will assist the OASIS BPEL4People standardization efforts. We are convinced that an analytical approach based on the workflow/resource patterns can aid discussions and remove ambiguities..." [source/full URI]

  • [March 24, 2008] "BPEL4People and WS-HumanTask Get Reference Implementation." By Rich Seeley. From SearchSOA.com (March 24, 2008). "BPEL4People and WS-HumanTask (WS-HT), while still specifications in the OASIS standardization process, can now be used in service-oriented architecture (SOA) development, said Mike Pellegrini, principal architect at Active Endpoints Inc. He has incorporated both specifications in this month's release of his company's visual orchestration systems (VOS) product, ActiveVOS 5.0, which provides graphic tools for design, development, testing, deployment and maintenance of SOA applications... This past week, Pellegrini demonstrated how BPEL4People and WS-HT can be used in the orchestration of a loan processing application. The demo showed a business process application where for routine loans a filter can automate the assessment of whether an applicant is a good or bad risk. However, when the applicant's credit history is a gray area, a loan officer must review the application and sign-off on its approval or denial. That is where BPEL4People and WS-HT come into play. Using those two specifications, the hand off from the automated process to the loan officer is tracked by the BPEL-based application, Pellegrini said. As he showed a view of this process through his visual orchestration tool, he explained: "It has been routed through the WS-HT specification task definition. It is routed to a task management system. Now, the system is just tapping it's fingers waiting for the human to finish." Pellegrini said this amounted to "a sort of reference implementation for WS-HT in-box APIs that allows us to get a list of the tasks at hand and the completed tasks." While the task is not generally a long-running endeavor, the specifications do allow for that fact that humans aren't usually as fast at completing tasks as computers are. In the demo, there is allowance for the task to be saved if the loan officer cannot complete it in a day, so he can finish it the next day..." See also the announcement.

  • [March 05, 2008] "BPEL4People Transferred to OASIS." By Ivana Trickovic. SAP Blog. March 05, 2008. "OASIS recently issued a call for participation for the OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee and two specifications (BPEL4People and WS-HumanTask) published last year by SAP and other technology vendors will be contributed to OASIS. What are benefits of this new standardization effort? The WS-BPEL 2.0 specification, which was adopted as an OASIS standard in April 2007, is primarily designed for types of processes that are automated and composed of reusable (Web) services. However, typical business processes require human involvement, e.g. to comply with some regulations it is necessary to implement the 4-eyes principle. For these kinds of business processes a more direct integration of different human interaction patterns in WS-BPEL is needed. The BPEL4People Technical Committee is chartered to address this need. In addition, there are scenarios which do not include WS-BPEL processes but require support for human interactions. So, in order to have a unified view across human tasks involved in WS-BPEL processes and those involved in other SOA-based applications a task model independent of WS-BPEL is needed. The outcome of the BPEL4People TC will include a task model as well... Why is BPEL4People important? By unifying service-based interactions and human interactions the modeling of business processes will be simplified. Moreover, standards-based integration of human interactions within business applications will enable interoperability, with both process infrastructures used to implement business processes and task clients used by business people to perform human tasks. It is also worth to mention that, similar to WS-BPEL, this new standardization effort will not consider a graphical notation, but is expected that existing standards, e.g. OMG BPMN, can be used and extended to support modeling of BPEL4People-like business processes...

  • [February 20, 2008] "BPEL4People Advances Toward The Mainstream." By Joe McKendrick. From ZDNet Blog 'Capitalizing on service-oriented architecture'. February 20, 2008. "BPEL (Business Process Execution Language) is too machine-oriented, catering to applications talking to other applications, they say. Most business processes need the human touch somewhere along the line. Consider these un-automatable scenarios: A process may need an executive's approval to proceed any further. Work may flow like a river, but it also encounters plenty of waterfalls, dams and locks on the way points at which humans may need to jump in to keep things moving. Workflows are as unique as the companies that create them, and all have their own points where humans intercede. That's why OASIS announced it is forming a technical committee to explore how the proposed BPEL4People standard (WS-BPEL Extension for People) could rectify this. This is a step toward becoming an OASIS standard, and work will commence on both both BPEL4People and WS-Human Task. WS-HumanTask was created by Adobe, Active Endpoints, BEA, IBM, Oracle and SAP. But, ultimately, can BPEL4People finally bring SOA closer to the business processes its supposed to support? Just as BPEL has taken its knocks over the years, there are conflicting viewpoints on whether BPEL4People can effectively do the job... The BPEL4People-BPMN discussion needs to continue. The bottom line is that we need ways to help bring BPM and SOA closer together, which is the next challenge facing implementations in both areas. The important thing is that vendors and industry experts are obviously recognizing that this is an important piece of the puzzle that needs to be addressed..."

  • [February 20, 2008] "OASIS BPEL4People: Beating a Dead Horse." By Fred Cummins. EDS' Next Big Thing Blog. February 20, 2008"OASIS recently announced formation of a new technical committee for BPEL4People. WS-BPEL 2.0 (or BPEL for short), the current version, does not address participation of people in business processes. This is one indication that BPEL isn't designed for business users. It's designed for programmers, and BPEL4People won't change that. A true business process language must be designed to represent business processes that make sense for the business and can be, in some cases, implemented manually, as well with a BPMS (Business Process Management System). A business process language also must support SOA (Service Oriented Architecture)... BPEL may be acceptable for specification of processes that are internal to computer systems, but the design of BPEL forces a structure on business processes that is unnatural for business people. A business process designed by business users must be either constrained or transformed for a BPEL implementation. Today, if a transformed process is presented back to the business users, they probably won't recognize it, even if it is presented in a graphical form rather than the standard XML representation (BPEL doesn't have a standard graphical representation). In addition, BPEL does not address invocation of independent sub-processes or choreography. These are fundamental requirements for SOA. Use of independent sub-processes allows a business process to use a sub-process that is independently developed and shared with other processes-potentially a shared service. A choreography specification defines an exchange protocol between two or more business entities engaged in a business transaction. Choreography is defined by ebXML BP (also from OASIS) or by WS-CDL (from W3C), but there is no defined relationship between BPEL and either of these choreography languages. When business entities agree on a choreography, it is important that they have support for designing their internal processes to complement the intended choreography. BPMN (Business Process Modeling Notation from OMG) was specifically designed for graphical representation of business processes for business people, and it has been widely adopted by the industry. BPMN already has tasks for people and support for independent sub-processes..."

  • [February 14, 2008] Announcement 2008-02-14: "OASIS Members Form New Committee to Advance BPEL4People. Active Endpoints, Adobe, BEA, IBM, Oracle, Red Hat, SAP, Sun Microsystems, Software AG, and Others Collaborate on Extension for Web Services Business Process Execution Language for Human Interactions." — "OASIS, the international open standards consortium, has formed a new technical committee to extend the Web Services Business Processes Execution Language (WS-BPEL) to support human interactions. The new OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee will expand the capabilities of WS-BPEL to support a broad range of human interaction patterns, allowing for additional modeling of business processes within the language. WS-BPEL 2.0, which was approved as an OASIS Standard in 2007, introduced a model to support automated business processes based on Web services. The standard is now widely used for orchestrating machine-to-machine interactions. 'WS-BPEL was not designed for human workflow,' noted Jeff Mischkinsky of Oracle, convenor of the OASIS BPEL4People Technical Committee. 'Nevertheless, we realize that many business processes comprise a broad range of activities where people are directly involved. Whether performing tasks, reviewing actions, approving steps, or entering data, people are a key part of many workflow scenarios.' BPEL4People will define a new type of basic activity that will allow human tasks, including their properties and behavior, to be defined, as well as the operations used to manipulate those tasks. A BPEL4People coordination protocol will control autonomy and life cycle of service-enabled human tasks in an interoperable manner... OASIS members will build on version 1.0 of the BPEL4People and WS-HumanTask specifications, which will be contributed to the Committee by Adobe, Active Endpoints, BEA, IBM, Oracle and SAP."

  • [February 14, 2008] ActiveBPEL Community Edition Supports WS-Human Task and BPEL4People. Announcement. 2008-02-14. "Active Endpoints Ships First Open-Source System to Include People in Composite Applications. New BPEL4People and WS-Human Task Specifications to Eliminate Proprietary Workflow, Speed Delivery of Services-Based Applications". — "Active Endpoints, Inc., inventor of visual orchestration systems (VOS), has announced the availability of Milestone 1 of ActiveBPEL Community Edition 5.0 Server. The ActiveBPEL engine comprehensively implements both the BPEL4WS 1.1 specification and the WSBPEL 2.0 standard. The engine supports the full complement of BPEL activities, event handling, exception handling and scope/compensation management. ActiveBPEL 5.0 represents the world's first release of an open-source implementation of both BPEL4People and WS-Human Task. These specifications allow human interactions to be included in services-based applications. By incorporating human tasks in composite applications, WS-Human Task and BPEL4People expand project teams' flexibility and efficiency in delivering standards-based solutions. With BPEL4People and WS-Human Task, application developers no longer have to cede control of business logic to proprietary workflow engines. Instead, these specifications allow human interaction to become a core, natural and open part of creating, deploying, testing and maintaining standards-based applications. For project teams struggling with the complexity of integrating closed workflow systems into composite applications, BPEL4People is a breakthrough specification and makes WS-BPEL itself an even more compelling alternative to overweight, piece-parts approaches to creating composite applications. Active Endpoints is an author of both the WS-Human Task and BPEL4People specifications. As a co-submitter of these specifications to OASIS, the company will play an active role in improving these through its participation in the OASIS WS-BPEL Extension for People Technical Committee. By releasing ActiveBPEL 5.0 Milestone 1 to the open source community, the company hopes to gain experience in the implementation of these specifications in order to permit Active Endpoints to more quickly promote the specifications as OASIS standards. Rapid finalization of these specifications will deliver major productivity to project teams interested in modernizing applications using standards-based technologies..."

  • [February 04, 2008] "OASIS Call for Participation in BPEL4People." By John Evdemon (Co-chair, OASIS Web Services Business Process Execution Language [WSBPEL] TC). In Loosely Coupled Thinking (MSDN Blogs). February 04, 2008. "...The full CFP follows the announcement from OASIS... I'll be watching from the sidelines this time. Some clarifications: (1) WS-HumanTask has no dependency on BPEL. BPEL simply consumes WS-HumanTask. (2) BPEL4People focuses on System to Human (S2H) and Human to System (H2S) interactions. Human to Human (H2H) is considered out of scope — these types of interactions cannot be supported with a language such as BPEL. None of the BPM languages are actually capable of this — see Keith Harrison-Broninski's work on Human Interaction Management for more on this topic. (3) The last time I looked at it, WS-HumanTask consisted of two contracts [see image]... I'll comment on this from time to time in the future...

  • [February 04, 2008] "Process Component Models: The Next Generation in Workflow?" By Tom Baeyens. From InfoQueue (February 04, 2008). This article arguments that the gap between the analysis and the implementation of business processes is far bigger then the marketing of today's workflow tools might suggest... BPEL4People specifies how human tasks can be included in a BPEL process. BPEL4People uses the BPEL extension mechanism to add human tasks as activities to a BPEL process. The specification defines a message exchange protocol between the BPEL engine and a task component. BPEL4People introduces the notion of a people link. Task assignment is the selection of a person or group that will be responsible for a task. BPEL4People specifies how people or groups can be described. But both the runtime evaluation of the selection as well as the structure of the identity information is outside the scope of the specification... BPEL4People is often seen as the fix to add workflow capabilities to BPEL and thereby making make BPEL a better fit for BPM. This is not really the case. When an analyst models activities, they will boil down to human tasks or processing a system. BPEL still forces that the communication between those activities is done through XML based process variables. If a developer needs to add a translation with XSLT, this is a new activity that still pops up in the diagram, even in case the business analyst is not interested in that technical detail. The layout of the graphical activities in the diagram of a BPEL process still remains too tightly coupled with web services and XML technologies to keep the analysis diagram in tact while making the process executable..."

  • [February 01, 2008] "WS-TakeOutTheTrash." By Paul Madsen. From ConnectID Blog: 'Small pieces loosely joined. Sounds like a description of my life.' "WS-HumanTask has been submitted to a new TC in OASIS. The TC will focus on defining human interactions ('human tasks') as part of a WS-BPEL process, enabling these definitions to be exposed as web services. My wife is preparing submissions to the TC for follow-up specs: 'WS-HowManyTimesDoIHaveToTellYouToPutYour%$#*&ClothesInTheHamper' and 'WS-SoISupposeThatWallWillJustPaintItself?'..."

  • [October 17, 2007] "Business Process Standards, Part 1: An Introduction." By Marc Fasbinder (Consulting I/T Specialist, WebSphere Software Technical Sales, IBM). From IBM developerWorks (October 17, 2007). "This article discusses three important standards for business processes: WS-BPEL, XPDL and BPMN. It reviews the background and purpose of these standards, and describes how they interrelate. A business process is usually defined as a series of activities and logic that form a repeatable pattern. Some processes are very dynamic or ad hoc, never running the same way twice. Others are very well-defined and run exactly the same way every time. Typically, companies will want to apply business process automation where it adds the most value: to a highly repeatable process with high business value. Processes such as insurance claims handling, loan processing or provisioning tend to fall into this category. Automating business processes of this type saves companies time and money. Running these processes the same way each time ensures quality, as well as regulatory compliance through audit log tracking... The WS-BPEL 2.0 standard does not address the business problem of how people can act as part of a business process. However, a proposed extension to WS-BPEL called BPEL4People defines an approach for extending WS-BPEL to support scenarios where people are required as part of the business process. Another aspect of BPEL4People is WS-HumanTask, which defines how a task for a person can be invoked as a Web service..."

  • [September 25, 2007] "BPEL4People: The Architecture." By Andrew Doble. Blog. "As I explained in my last post ['SOA: The Human Angle', 2007-07-21], the new BPEL4People draft standards are intended to integrate people into those business processes that are being controlled by a 'requesting application'. I think it's pretty safe to assume that in most SOA implementations this would be a process engine running BPEL. The draft spec itself is split into two parts. The first (WS-BPEL Extension for People) explains how BPEL can be extended with specific process constructs to deal with human interactions and lists a number of ways (called constellations) that the management of these tasks can be implemented. From an architectural point of view the most interesting one is when the task infrastructure is decoupled from the process infrastructure and a separate spec (WS-Human Task) has also been released to cover this... How does this all go together? Let's start off at the simpler end. The basic assumption is that people provide services by acting on tasks which have been assigned to them. To see and handle the tasks which have been assigned to them is done using a task client. This is not specified by the specification, but it is a relatively safe bet that will take the form of a user interface with some kind of task list which the user can interact with... The user interface interacts with a task management component which stores the tasks assigned to the users. Again, it's pretty likely that the task manager will be a central component that can hold the tasks for a number of users each of who has their own user interface. The spec defines the services which the task manager component exposes to a user interface. I've grouped them into three categories: (1) Life Cycle, i.e., claiming a task (i.e. saying you'll do it), starting, suspending and stopping tasks etc. (2) Query, i.e. finding tasks based on certain criteria. The most important one here is getMyTasks. (3) Administration services such as explicitly nominating someone to a task To do this the task manager needs to access some information regarding the people. The spec assumes a people directory with an interface for queries, but doesn't actually fix what this looks like...

  • [July 2, 2007] "'BPM folks' vs. 'WS-Folks': Where Does BEA Belong?" By Jesper Joergensen. From Jesper Joergensen's Blog. "Inspired by the recent announcements on BPEL4People, Tony Baer observes that the industry is split between 'WS-Folks' who supports BPEL and BPEL4People and 'BPM folks' who supports XPDL and others. He casts IBM, SAP, Oracle, BEA, Adobe and Active Endpoints (the current backers of BPEL4People) as WS-Folks who represent the IT side while the traditional BPM companies (Lombardi, Savvion etc.) are 'BPM folks' who represent the business analyst side... In the past BPM projects have often been isolated 'one-offs' where a company makes a technology choice based on a single project / problem. But going forward companies will increasingly be considering BPM technologies from a strategic perspective. Processes will be running in several different systems and in some cases the BPEL style will be more appropriate than the end-to-end process style associated with BPMN, XPDL and BPDM. So we should expect both process styles to be deployed across the organization. At BEA we are supporting this future demand by having a process engine that supports both XPDL and BPEL as execution formats and a modeling environment that supports BPEL design and BPMN process modeling. Picking just one standard to support is a luxury that vendors cannot afford..."

  • [June 29, 2007] "Tony Baer on BPEL4People." By Tony Baer (President, onStrategies). From ebiz (June 29, 2007) "This week, IBM, joined by SAP, Oracle, BEA, Adobe, and Active Endpoints formally proposed a pair of specs for submission to Oasis, the web standards body, which would make human workflow a first class citizen in an SOA environment (for now, we'll call this group the WS-folks). There was little surprise to the announcement, except for the fact that Oracle dropped its former opposition to the scheme. The new proposal boils down to two specs: an extension of BPEL that adds human workflow as one of its orchestration steps, and a new proposed spec, WS-Human Task, where the actual workflow would be described. Backers claim that, by separating out human tasks, that they can stand alone and be invoked without having to go through a BPEL orchestration. That would enable you to decouple the task from the actual application or user interface, making it that much more reusable. This all sounds fine and dandy except for one thing — the classic BPM folks are still not among the signatories... Or as one colleague put it, the BPM folks are from Venus and the WS-folks from Mars... The WS-folks have proposed a couple new specs to add support of manual tasks, filling a major gap in SOA. The first is an extension of BPEL called BPEL4People that inserts a human task to an orchestration, and the second is a separate spec called WS-HumanTask which provides the semantics for describing the tasks. It's prompted plenty of discussion, which my colleague Joe McKendrick summarized quite well..."

  • [June 29, 2007] "BPEL4People and Human Interactions." By Keith Harrison-Broninski. From ebiz (June 29, 2007). "... mainstream BPM languages, including graphical notations like BPMN, are based on carrying out steps in a pre-defined sequence — and this is not what happens when humans work together. Turning to BPEL4People, it claims to support patterns for 'human interactions'. However, in terms of the above division, these are human interactions in 'task-driven' processes. In other words, what the specification authors mean by 'human interactions' is interactions between humans and systems (H2S) — not interactions between humans and humans (H2H)... BPEL4People is related to Human Interaction Management (HIM), in that both deal with humans, but the two approaches are complementary rather than competitive. In fact, they are often closely tied together... Lots of things that happen in organizations simply do not match in any way the underlying 'parallel flowchart' paradigm of a language like BPEL, no matter how you extend it... Today's attempts to bundle H2H process support into workflow systems or office applications are confusing apples with oranges, since they are attempting to impose on H2H interactions the wrong metaphor. Humans trying to collaborate find it not only unhelpful but actually abhorrent to view their interactions with each other as a set of pre-defined steps carried out in sequence, and will either ignore, work around or subvert such bastardized pseudo-solutions. They know there is a lot more involved: notions of responsibility, accountability, goal-directed communication, privacy, rework, prioritization, consensus, authority, and a lot more besides..."

  • [June 25, 2007] "Yo! BPEL4People Specifications Released — and WS-HumanTask too!" By Alan Rickayzen (SAP). Blog. "Business Process Management has that gaping hole called human-integration not just plugged with a stopper but plugged with a standardized funnel to just about every type of software involving human interaction... In a nutshell: The BPEL4People specifications put down in writing exactly which XML messages flow through your enterprise to enable human interaction in processes in a standardized (cross-vendor) way. The specifications deliver the promise setup two years ago in SAP and IBM's BPEL4People whitepaper. All the proposed constellations are supported. Virtually all definition aspects; tasks, notifications, escalations, who may perform a task, who may not... and operations; query, forwarding, nominating, attachments, are supported, too. But it's been split into two for super-charged modularity: (1) The BPEL4People socket to enable human activities to be plugged into processes; (2) The WS-HumanTask plug to attach tasks/todos to processes, inboxes, or even hard-coded composites requiring task-like interaction... It covers interoperability where previously the focus of BPEL had been portability..."

  • [June 25, 2007] "BPEL4People Aims to Bridge Gap Between Humans and SOA. BPEL4People Standard for SOA-based Business Processes Heads to OASIS." By Rich Seeley. From SearchWebServices.com (June 25, 2007). "Recognizing that service-oriented architecture (SOA) business processes involve people too, a group of vendors today published specifications aimed at extending the Business Process Execution Language (BPEL) 2.0 standard to include human interaction. The BPEL4People specifications will be submitted to the OASIS standards body in the fall, but are ready for developers and architects to download today from the Web sites of the participating vendors, said Ed Cobb, vice president for emerging technologies and standards at BEA Systems Inc. The other vendors supporting the specifications are IBM, Oracle, SAP AG, Adobe Systems Inc. and Active Endpoints Inc.

  • [June 25, 2007] "BPEL4People Humanizes SOA." By Eric Knorr. From InfoWorld (June 25, 2007). "The gap between BPM (business process management) and SOA just narrowed a bit today with the joint announcement of a new Web services specification, BPEL4People... People have a way of inserting themselves in long, complicated processes, and BPEL4People gives developers new ways of modeling behavior so apps don't break when someone takes a vacation. Part of the BPEL4People spec is Web Services Human Task, which actually provides a means to define human behavior as activities (not all human behavior, we hope). Those activiies will be consumable by BPEL apps and, according to the spec's authors, other apps as well. Presumably, BPM offerings from the participating vendors (and others) will support BPEL4People, so that process models developed in BPM products will be more than pretty pictures developers use as a guide for building apps -- they may actually connect to services in an SOA, shortening development cycles considerably. But all this will take awhile. BPEL4People's authors plan to submit the spec to OASIS in the 'near future,' so years may elapse before the fully blessed spec makes it into commercial products..."

  • [May 7, 2007] "Business Process Management 101: The Basics of BPM and How to Choose the Right Suite." By Tulu Tanrikorur (May 7, 2007). "The FO-BPM solutions (with roots in human-centric workflow products) provide capabilities for person-to-person processes in which "work items" are created and routed along with any attached documents. A partial list of vendors that provide FO-BPM capabilities would include TIBCO, FileNet, IBM, PegaSystems, Global360, Oracle, DST Systems, BEA (with recently acquired Fuego) , Computer Associates, Ultimus, Savvion and MetaStorm, among others. Front-office-oriented BPM systems typically let you design forms, define data fields, customize process templates, set up access control lists, configure integration capabilities and manage deadlines. Since back-office-oriented BPM solutions aren't intended to support human-centric workflow (and therefore don't require form capabilities), they focus instead on features such as back-end process composition, data/message transformation and automatic creation of service interfaces to ease implementation... There is currently a lack of strong support for a standard way of working with processes that involve human-interactions, even though there are recommendations to address them. BPEL currently does not handle person-to-person processes, so an extension has been proposed called "BPEL4People." Similar capabilities can also be found in XPDL..."

  • [May 01, 2007] Worklist Manager SE (WLMSE) - A related technology. "Worklist Manager SE (WLMSE) is a JBI based engine, which provides task management and human intervention in a business process.Worklist Manager SE uses a simple task definition language to define the tasks related functionality like task assignment to user/groups, escalation, timeout etc." Why a separate Worklist Manager SE? Following are some of the reasons: (1) BPEL does not provide human interaction; (2) Extending BPEL with new custom extension is cumbersome and makes BPEL complex, non portable; (3) Clear separation of human interaction/task related functionality into a separate component; (4) A simple language to define tasks functionality. Simple Task Notification support in WLMSE: "A notification needs to be supported on different types of protocols. Example: send an email when task is created using SMTP binding. send an instant message using XMPP binding. send an sms message using SIP binding. The main idea is to make notification logic not bound to a transport in WLMSE.WLMSE would not need to know what transport is used to send a message. WLMSE would just need to specify what is the end point address where a notification needs to be sent and a binding would use it to send notification. This allows WLMSE to be able send message using various bindings..." See the presentation.

  • [April 30, 2007] "The BPEL4People Spec Extension." By Erik R. Pieczkowski. From network computing (April 30, 2007). "A proposed optional extension to BPEL 2.0, BPEL4People promises to address a big gap in the spec by standardizing human tasks in a BPEL process. But can it gain acceptance among vendors? [...] 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... 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..."

  • [April 11, 2007] "SOA and Human Interaction." By Johan den Haan. From The Enterprise Architect: Building an Agile Enterprise. "The de facto standard for web services orchestration seems to be BPEL. This standard, however, doesn't specifically cover user interactions. This leaves us with the question: what is the right way to include human interaction in a BPEL process? [...] Just using a Workflow Service means no standardization at all. Each vendor defines its own Workflow Service depending on the specific needs. BPEL4People on the other hand standardizes a lot, but not everything. Some gaps have to be filled in, but it provides a solid base. However, I do not like the fact that BPEL4People extends the existing BPEL standard with new activities and task definitions. BPEL provides a nice orchestration standard on an abstract level. Including links to specialized services (like the people link) instead of only links to 'abstract services' weakens the abstraction and opens doors for all kind of other extensions. I think a better approach would be to use the foundations of BPEL4People to standardize the interface of a Workflow Service..."

  • [March 20, 2007] BPEL4People: Extending WS-BPEL for People. By Ta'id Holmes [WWW]. Masters Thesis. Carried out at the Information Systems Institute Distributed Systems Group, Vienna University of Technology, under the guidance of Univ.Prof. Mag. Dr. Schahram Dustdar. March 20, 2007. 70 pages. Matr.Nr. 9625914. "BPEL, an XML based language, formally describes business processes and business interaction protocols. While WS-BPEL processes support automated process integration, there is a need to support human tasks, which naturally comes with new requirements. BPEL4People is a joint project of IBM and SAP that describes scenarios where users are involved in business processes, and defines appropriate extensions to WS-BPEL, exclusively using web service interfaces for maximum interoperability. Integration of human tasks into BPEL processes is achieved by defining a people activity, that encapsulates a human task, as a concrete implementation of a BPEL activity. This thesis proposes a concrete specification of BPEL4People that defines syntax and semantics that complies with the WS-BPEL specification. Finally, a generic BPEL4People system is realised that can to be coupled with a BPEL engine in order to integrate human tasks into business processes." See also the poster [cache], and SourceForge BPEL4People Project: "This project proposes a concrete BPEL4People syntax that complies with the WS-BPEL specification and realises a system that can be coupled with a BPEL engine in order to integrate human tasks into business processes." See the BPEL4People Research Prototype.

  • [February 14, 2007] "BPEL4People White Paper Overview [via podcast and transcript]." "This 10 minute 55 second podcast from gives you a short introduction to BPEL4People, the joint white paper from SAP and IBM proposing an extension to BPEL to cover human integration in processes. It touches on the following themes: (1) Basic BPEL4People terminology; (2) Differences and similarities between traditional workflow and BPEL; (3) Ways in which users play a role in executable processes; (4) Constellations covered by the BPEL4People white paper; (5) The standardization process itself; (6) Work-arounds to enable humans to perform tasks in standard BPEL processes... [As to] the principle terms in BPEl4People: 'It's pretty straight forward really. People activities. These are the human equivalent of invoking a service in BPEL. Tasks, are the equivalent of the services. These are associated with items of work associated with human participants — someone doing the work. The process won't continue until the task is completed or at least reaches a final state. Notifications on the other hand are items of information sent to participants. Like tasks, there are multilingual aspects associated with the notification because they're intended for a human recipient. But unlike tasks, they don't hold up a process in anyway. It's an important distinction. Generic Human roles are also described in the paper. These generic roles relate to the way a person interacts with the process, tasks and notifications, one example being the determination of who actually receives a particular task — this role is the potential owner. The process stakeholder is another example of a generic role. Someone who has an interest in seeing that particular process instance through to conclusion, irrespective of the services and tasks invoked along the way... A very important aspect is the non-disruptive transition between automatic services and human execution. It's a simple statement but the enablement is non-trivial. Particularly, as the specification is adding semantics to BPEL and expanding it's range. If you look at these constellations you'll see that there are aspects of BPEL4People which apply above and below the line. In other words to different types of software..."

  • [May 05, 2006] "Getting Started with Process Definition Languages." By David Burdette. SDN Contribution. "Orchestration Definition Languages such as WS-BPEL, BPEL4People and UML define the sequence and conditions in which the processes within a business are executed. Orchestration Definition Languages are important to SAP as they are used to specify composite applications created from Enterprise Services. Typically internal business processes in a business involve the execution of several sub-processes involving multiple systems both within, and often, outside the business. They may also involve human user interaction. Orchestration Definition Languages are used to define the sequence and conditions in which the processes and human user interactions within a business are executed. For example it could define that the processing of an order involves, credit authorization, stock availability checks, delivery scheduling, etc. WS-BPEL Extension for People (BPEL4People) developed by SAP and IBM, is layered on top of WS-BPEL to support human user interactions..."

  • [April 12, 2006] "BPEL Processes and Human Workflow: Using BPEL in business processes that require human interaction." By Matjaz Juric and Doug H. Todd. From SOA Web Services Journal (April 12, 2006). "Several vendors today have created workflow services that leverage the rich BPEL support for asynchronous services. In this fashion, people and manual tasks become just another asynchronous service from the perspective of the orchestrating process and the BPEL processes stay 100% standard. We now see the next generation of workflow specifications emerging around BPEL with the objective of standardizing the explicit inclusion of human tasks in BPEL processes. This proposal is called BPEL4People and was originally put forth by IBM and SAP in July 2005. Other companies, such as Oracle, have also indicated that they intend to participate in and support this effort. The most important extensions introduced in BPEL4People are people activities and people links. People activity is a new BPEL activity used to define user interactions; in other words, tasks that a user has to perform. For each people activity, the BPEL server must create work items and distribute them to users eligible to execute them. People activities can have input and output variables and can specify deadlines. To specify the implementation of people activities, BPEL4People introduced tasks. Tasks specify actions that users must perform. Tasks can have descriptions, priorities, deadlines, and other properties. To represent tasks to users, we need a client application that provides a user interface and interacts with tasks: it can query available tasks, claim and revoke them, and complete or fail them. To associate people activities and the related tasks with users or groups of users, BPEL4People introduced people links. People links are somewhat similar to partner links; they associate users with one or more people activities. People links are usually associated with generic human roles, such as process initiator, process stakeholders, owners, and administrators. The actual users who are associated with people activities can be determined at design time, deployment time, or runtime. BPEL4People anticipates the use of directories such as LDAP to select users; however, it doesn't define the query language used to select users. Rather, it foresees the use of LDAP filters, SQL, XQuery, or other methods..."

  • [February 28, 2006] "BPEL4People Revisited." By Bruce Silver. From BPMInstitute.org (February 28, 2006). "Last summer IBM and SAP proposed something called BPEL4People, an optional extension to BPEL 2.0 that would at last standardize human tasks in a BPEL process. They published a couple white papers on the subject, put out a press release, and then went silent. Essentially nothing has been heard from them since. Recently I began to hear references to BPEL4People again, and I went back to re-read the white papers. They're nowhere close to a spec, but essentially description of a workflow "model" followed by an outline of how that model, in 5 different use cases, will be implemented in the ultimate BPEL4People specification. The first part basically recites the core concepts of traditional workflow software — activities and tasks, roles and role resolution, deadlines and escalation, worklists and task claiming — familiar to any bank, insurance company, utility, or government agency who has implemented workflow since the late 1980s. The second part asserts that grafting workflow functionality onto BPEL 2.0 really demands addition of a new activity type (a People activity) to the language. Adding a new activity type is a big deal, since straight BPEL 2.0 engines won't be able to implement it. Besides, virtually all BPEL-based BPMSs 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..."

  • [October 21, 2005] "SOA programming model for implementing Web services, Part 8: Human-based Web Services." By Matthias Kloppmann, Stefan Liesche, Gerhard Pfau, and Marcia Stockton. From IBM developerWorks (October 21, 2005). "The involvement of people in service compositions is a relatively new facet of Service-Oriented Architecture (SOA), expanding the ways software can model how humans work and interact in a business. This article describes functions offered by the Human Task Manager of IBM WebSphere Process Server and their use in a portal... Total automation of business processes, while desirable, in practice is unachievable, because certain activities requiring human judgment or human expertise — such as the manual handling of exceptional situations or the approval of requests — are always performed by people. In the context of the overall business process, a human task is a service like any other task, except that it is realized by a human activity (instead of a program) and performed by a person (instead of a computer). Thus, within the SOA programming model, human activities can be realized as Web services. When invoked, the service notifies an individual of a task to do and passes the input data in an appropriate form. After the task is completed and there is a result, the service returns to its caller, passing the result as output data. That the result actually involved work by a person may be completely transparent to the caller. The scenario employs asynchronous invocation to support long-running services; a remote procedure call (RPC)-style synchronous invocation is not suitable for human tasks (or any other long-running service)... The transparent encapsulation of a human task as a Web service is not always desirable. Consider a more complex process where two different people need to approve a request (known as the four eyes principle or separation of duties). Such tasks need explicit representation as human tasks, not opaque Web services, because the rule used to select the second approver necessarily excludes the first approver. The BPEL4People extension for the Business Process Execution Language for Web services provides the extensions needed to extend business processes with embedded human tasks. It also addresses scenarios where human tasks are rendered as opaque stand-alone Web services that can be invoked from a BPEL process or a program written in Java, for example... The Human Tasks concept has gained industry recognition, and its standardization is ongoing. A joint paper published by IBM and SAP suggests future directions for the standardization of human tasks. It describes an extension to the upcoming WS-BPEL standard that includes human tasks to involve people with business processes...."

  • [August 25, 2005] "BPEL4People: How People Interact with Business Processes." By Ivana Trickovic (SAP AG). "This article explains briefly the need for an extension to the Web Services Business Process Execution Language (WS-BPEL) that supports designing of how people interact with business processes. It should help readers understand why SAP and IBM have worked jointly on a proposal for user interactions in WS-BPEL... 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...
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/bpel4people.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org