News Stay informed about the latest enterprise technology news and product updates.

BPEL4People aims to bridge gap between humans and SOA

Newly published BPEL4People specifications, now headed for OASIS, aim at bridging the gap between SOA-based business processes and the humans that interact with them.

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 specification adds the ability to request a people activity within an SOA-based business process.
Michael Bechauf
Vice President of Industry StandardsSAP

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.

BPEL4People consists of two specifications, explained Michael Bechauf, vice president of industry standards at SAP. WS-BPEL Extension for People layers features on top of the recently approved OASIS WS-BPEL 2.0 standard and describes human tasks as activities that may be incorporated as first-class components in WS-BPEL process definitions. The companion specification, Web Services Human Task, introduces the definition of stand-alone human tasks, including the properties, behavior and operations used to manipulate them. The two specifications are designed so they can either be used together or independently, Bechauf said.

"BPEL4People specification defines a way to integrate tasks that need to be executed by a human user with an SOA-based business process," he said. "It introduces the notion of people activity and that of a task that needs to be executed as part of that activity. To date, the BPEL 2.0 standard only defines basic activity types that are related to SOA, which is invoking Web services or receiving a message. The BPEL4People specification adds the ability to request a people activity within an SOA-based business process."

The need to link software-driven business processes to the people who interact with the computer systems was a requirement those working on the original BPEL specification and heard from businesses from the beginning, said Diane Jordan, program manager in emerging Internet standards at IBM and co-chair of the OASIS BPEL technical committee.

BPEL4People provides a standard way for SOA-based business processes to communicate with people through alerts and reminders that can be sent to a desktop or even a cell phone, she explained. The specifications monitor work queues and also covers events such as reassignment of tasks when an employee is out sick or otherwise unable to continue working on it, she added.

"For example, we frequently receive an e-mail asking for an approval and I frequently need reminders to get back to that e-mail. This specification allows for modeling that kind of process and enabling the process to trigger reminders."

With six vendors in the SOA space already supporting the specification and its imminent movement into the OASIS standardization process, BPEL4People will provide a consistent way for developers to describe interactive people processes in heterogeneous environments and SOA implementations that involve multiple organizations, Jordan said.

For more information
Check out our BPEL Learning Guide

SOA, Web services and BPEL converge at AT&T subsidiary

The goal of BPEL4People is to avoid the need to model and code one-off programs to handle the wide variety of possible human interactions with a business process.

Jordan offered an example of how BPEL4People might work for an electric company in helping them manage the system and human interactions involved in resolving a power outage.

"For example, you have sensors on equipment that detect failures," Jordan said. "You can automatically start an incident report, keep customer service people informed of the status so they can talk to the customers. You can even generate a work order. But at some point the company will want a human being to look at that work order and decide if there is anything special about it before allowing the process to proceed. An operations specialist may want to look at it and decide if they want to deploy the company's repair people or pull in a contractor based on the volume of incidents that have occurred."

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.