WS-BPEL4People on its way to OASIS
WS-BPEL4People is comprised of 2 complementing specs. This first is WS-BPEL extension for people which defines layers to deal with human interactions and tasks on top of WS-BPEL -or as the spec's abstract describes it:
Web Services Business Process Execution Language, version 2.0 (WS-BPEL 2.0 orThe second spec introduced is WS-Human Task which defines interfaces to allow introducing people tasks as services in an SOA independently of WS-BPEL. The idea is that non-human services will have a consistent and standard way to interact with humans. The spec defines the goals as follows:
BPEL for brevity) introduces a model for business processes based on Web services.
A BPEL process orchestrates interactions among different Web services. The
language encompasses features needed to describe complex control flows, including
error handling and compensation behavior. In practice, however many business
process scenarios require human interactions. A process definition should incorporate
people as another type of participants, because humans may also take part in
business processes and can influence the process execution.
This specification introduces a BPEL extension to address human interactions in BPEL
as a first-class citizen. It defines a new type of basic activity which uses human tasks
as an implementation, and allows specifying tasks local to a process or use tasks
defined outside of the process definition. This extension is based on the WS-
Human tasks, or briefly tasks enable the integration of human beings in service-The vendors plan is to submit both specs to Oasis and approve them as yet another WS-* standard.
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 (abbreviated to WS-
HumanTask for the rest of this document).
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.
Microsoft's John Evdemon who was one of the chairs of the Oasis committee that approved WS-BPEL 2.0 hopes that before the specs will be approved as standards
...they can fix some of the issues (such as people resolution) and come up with a name.that doesn't sound like a punchline. :)On the other hand SAP's Alan Rickayzen is excited about the new standards . On his blog you can see a diagram of the components of the two standards as well as a pod-cast explaining them briefly.
What do you think - do we need another WS-* standard? does the new standards fall under what Jon Udell calls WS-Justright?
Commoditising human workflow is a good next step for the standards bodies at it enables best practice to be shared independently of the vendors and helps to move the debate on to solving the next set of problems by commoditising some of the current integration and data porting challenges.