OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bpel4people message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [bpel4people] NEW ISSUE: B4P spec doesn't address task routing patternsand policies

TARGET: WS-HT, General


1. WS-HT should support common patterns for assigning people. In the 
current WS-HT spec, people assignments are singular in notion. The 
assignment to potential owners of a task can either be done through 
logical people groups, literals or an expression.

However there is no mechanism to specify that a group of people might 
work on a task in parallel or in a well-defined sequence or in any 
combination of them, the so-called 'task routing pattern'.

In the current model, task routing patterns have to be modeled in the 
business process itself. However that makes it hard to manage the task 
in its entire context.

2. WS-HT should support a standard set of 'task routing policies' that 
would allow the task modeler to apply certain policies on task routing. 
The policies include early routing completion, skipping modeled routing 
patterns and error assignment

For example, assume that a task is assigned to a group of people to work 
on the task in parallel. One might want to complete all routing as soon 
as a certain condition on the task payload evaluates to true.

· Support for single routing pattern
· Support for sequential routing pattern
· Support for parallel routing pattern
· Support for early completion
· Support for skip condition
· Support for error assignee


1. Provide a mechanism for people assignments to support common task 
routing patterns for Single, Sequence, Parallel and any combination of 
them. This is to enable collaborative work on tasks in a well-defined order.

2. Define a set of standard task routing policies that would allow the 
task modeler to set the state of a task according to policies evaluated 
at runtime.

Detailed proposals are available as part of the associated issues.


<xsd:element name="potentialOwners"

<!-- MODIFIED: Potential Owners to include chain and groupVote -->
<xsd:complexType name="tPotentialOwners">
<xsd:extension base="tExtensibleElements">
<xsd:choice maxOccurs=”unbounded”>
<xsd:element name="single" type="tSingle"/>
<xsd:element name="sequential" type="tSequential"/>
<xsd:element name="parallel" type="tParallel"/>

<!-- All the other types here are discussed in detail in related issues 
doc -->

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]