| Hi
We actually handle multi-user Human Tasks in our workflow system.
That is, although individual instances of those people are created (which is a single instance per person), there is only one runtime instance of the Task is created. Although those people hold individual data record instances (multiple) for the Task, still the Task is created as only one instance.
This is different from routing and also the Task cannot be divided into some subsequent steps as Tasks, with regard to the Process engine (and for the Task engine). Any subsequence steps are the Task's doing. When people arrives at the Task, they can arrive as a group or individually when they choose.
So, we were happy with the definition of only 1 owner in case of BPEL4People, which does not handle such multi-user Task at present, which avoids the confusion. On the other hand, we actually desired that in the future this would be expanded to consider multi-user owned Task.
The example of such Task is an intermittent or real-time interactive human activity between the people who are assigned to it. There is no internal structure like sub-workflow inside therefore it cannot be broken down to Sub-Tasks. This also complicates routing (of multiple-progresses - since each may choose different routing).
So, what terms we use for the Owner must be carefully defined for this reason.
In my opinion, it should not matter how many Owners are assigned to a Task. The Task engine and the Tasks should handle it. However, the Task itself may advise the Task Processor as to whether it is meant to be a single Owner Task or Multi-Owner Task, if that helps for Task advertisement etc.
Yoichi -------------------------------------------------------------------------- Yoichi Takayama, PhD Senior Research Fellow RAMP Project MELCOE (Macquarie E-Learning Centre of Excellence) MACQUARIE UNIVERSITY
Phone: +61 (0)2 9850 9073 Fax: +61 (0)2 9850 6527 -------------------------------------------------------------------------- MACQUARIE UNIVERSITY: CRICOS Provider No 00002J
This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or Macquarie University. On 24/02/2009, at 2:33 AM, Alireza Farhoush wrote: I am following up on the discussion we had during our last meeting. I have outlined below a change (2/3) to the WS-HumanTask Specification Version 1.1 document that I proposed. Regards, Alireza Farhoush TARGET: WS-HumanTask Specification Version 1.1 CD02 DESCRIPTION: In Section 3.1 ‘Generic Human Roles’, in the 6th paragraph, a statement reads: “A task managed by a WS-HumanTask Processor must have exactly one actual owner.” Although the routing pattern has not been finalized, it does raise an issue regarding the above statement. In routing patterns, conceptually, multiple people might be invited to work on the same task, although, in most implementations, a new instance of the task is created and there is therefore only one owner per instance. Perhaps some clarification about single ownership of a task should be added to accommodate the semantics of routing tasks (once approved).
|