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

BPEL4People adds human factor to SOA

Vendors' specifications for extending WS-BPEL 2.0 to include human activities in service-oriented architecture (SOA) environments are headed for OASIS.

Vendors active in creating Web Services Business Process Execution Language (WS-BPEL) 2.0, which became an OASIS standard this past spring, are now working on two specifications that extend it to include human activities.

When you have a people activity, BPEL4People is going to create a task and it's going to associate that task making a WS-HT API call into an inbox.
Mike Pellegrini
Principal ArchitectActive Endpoints

Active Endpoints Inc., Adobe Systems Inc., BEA Systems Inc., IBM, Oracle Corp. and SAP AG are developing BPEL4People and WS-HumanTask (WS-HT) to integrate the work business people do into Web services and service-oriented architecture (SOA) applications. The group published a first draft of BPEL4People at the beginning of the summer and plans an update in the fall. The ultimate goal is to put the specifications into the OASIS standardization process, said Mike Pellegrini, principal architect at Active Endpoints, the BPEL products vendor.

A criticism of BPEL was that it didn't include human tasks, and the vendors recognized the need to create a people extension, he said.

The BPEL4People concept arrived two years ago in a white paper, WS-BPEL Extension for People – BPEL4People, IBM and SAP AG produced and published. As an extension to WS-BPEL it waited on the final approval of that standard.

This March, as WS-BPEL 2.0 neared its final stages, work began on fleshing out the specification outlined in that paper, Pellegrini said. The first draft of that work was released to the public earlier this summer. That draft also included the companion WS-HumanTask specification.

Pellegrini explained how the two specifications work together with WS-HT providing the infrastructure layer for BPEL4People.

"BPEL4People has a direct dependency on WS-HT," he said. "The BPEL4People specification was created to model people as first-class citizens in the BPEL process definition. What you'd be able to visually see in your process is a specific activity called a 'people activity.' That people activity is like a standard activity where you invoke a Web service. But it has some additional context associated to it."

A people activity might be a credit manager approving a credit application after Web services handled the credit check. BPEL4People will handle assigning the task and arranging reminders if it is not completed, as well as possibly escalating it to notify a department head if the task isn't getting done in the expected time frame.

Under those processes, WS-HT provides the APIs and runtime for BPEL4People, Pellegrini explained.

"When you have a people activity, BPEL4People is going to create a task and it's going to associate that task making a WS-HT API call into an inbox. What WS-HT does is provide the runtime infrastructure for a work queue. It provides a standard definition of what a task looks like, a standard way for how a task gets created and a standard set of APIs for how it interacts."

Developers will be able to user WS-HT to create inboxes with a standard API that can be accessed by a BPEL4People task.

"What you'll probably end up seeing is people in the BPEL space will begin creating standardized inboxes," he explained. "And because the APIs are consistent, they can start aggregating tasks throughout many different environments where work gets done in many different spots."

For more information
Burton: beyond BPEL orchestration, SOA needs choreography

Check out our BPEL Learning Guide

The WS-HT standard is needed because currently vendors create APIs for inboxes in a proprietary way, so it is difficult to integrate tasks from systems based on different vendor platforms even though they follow the WS-BPEL standard. Integration will be facilitated by having all the vendors and developers working in the BPEL space use standard APIs, Pelligrini said.

"I might be able to create a 168 portlet, for example, that aggregates all the different tasks from all the WS-HT inboxes leveraging the standardized Web services API that's available," he explained. "Then you can go to inbox one and get all its tasks, go to inbox two and get all its tasks, and recognize them in a standard user interface as a unified inbox."

Pelligrini would not predict how long it will take for BPEL4People and WS-HT to move from the vendors' specification drafts to a final OASIS standard. Although he did say he hoped it would not take the four years it took for WS-BPEL 2.0 to be finalized.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.