SOA World: BPEL Coming to People
Increasing the market adoption of BPM by mainstream enterprises
Dec. 13, 2008 06:15 AM
WS-HumanTask defines human tasks, including their properties, behavior, and set of operations needed to manipulate them. Although WS-HumanTask is a sister specification to WS-BPEL4People and is expected to be widely used in conjunction with BPEL, it is designed to be a standalone specification, enabling invocation of tasks from any business process (BPEL or otherwise), as well as from any Web Services client. (Note that throughout this article, we use task as shorthand for WS-HumanTask task.)
BPEL4People uses BPEL's extension mechanisms to layer human interaction capabilities on top of BPEL. At the core of these extensions is People Activity, which enables a task to be invoked from a BPEL process. Other extensions bind people assignments to people directories, assign task properties, and manipulate tasks in BPEL processes.
Figure 1 shows the logical architecture of the BPEL4People specifications. A BPEL process invokes a People Activity (task). A WS-HumanTask engine manages the lifecycle of the task and provides interfaces to the client application for operating on the task. This separation of the process and the task engine allows both to be deployed, managed, and scaled independently. It also enables the use of a unified task engine working with multiple BPEL and other process engines, possibly from different vendors. WS-BPEL4People also enables inclusion of the task definition inline in the BPEL process.
Delegation and Nomination
The BPEL4People specifications enable the definition of constraints on delegation. A task definition can specify that it can be delegated to anyone, to only potential owners as determined by assignment, to a specific set of people or named groups, or to no one. By default, tasks can be delegated to anyone.
As mentioned earlier, task stakeholders can assign task instances at runtime. This, in conjunction with the fact that a task can be created without an owner being assigned, enables a pattern commonly known as nomination in which business users overseeing the process nominate users to perform a task on an instance-by-instance basis.
Timeouts and Escalations
The BPEL4People specifications allow multiple deadlines to be associated with a task. These deadlines can be start deadlines or completion deadlines. Both deadlines can be specified as a duration (period of time), or a deadline (point in time), and are calculated from the time the task is created. Expressions can be used to compute the deadlines at runtime, enabling both context-based deadlines (for example, deadlines based on order amounts or a customer's premium status) and the integration of a business calendar (for example, to compute the number of calendar days that correspond to three working days).
One or more escalations, with associated conditions, can be associated with a deadline. An escalation is triggered if the point of time specified as a deadline has been reached or the duration has elapsed, and the associated condition evaluates to true. Escalations can use notifications to inform people of the status of the task or reassign the task to different users or groups.
Deadlines and escalations are illustrated in Figure 2.
All tasks start in the Created state. A task remains in the Created state until it is activated (if scheduled activation is used) and has potential owners. If there are no potential owners, the task remains in the Created state until the business owner has performed nomination.
Once activated, a task moves into the Ready state if it has multiple potential owners (for example, when it is assigned to a group or a queue) or into the Reserved state if there is only a single potential owner. Tasks in the Ready state move into the Reserved state when one of the potential owners claims it.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week