[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bpel4people] BPEL4People TC - 11/26 Draft Agenda
| Dear Dave, Thank you for the agenda of the TC meeting. Due to my time zone, I won't be able to join the meeting at this time. My apology. On December 10, although I am on annual leave, I am in LA and hopefully I may be able to join in. Also, thank you for adding my comments to the agenda. Further to my earlier comments, here are two concrete examples for two of the agenda items on open issues. Please forgive me to submit it here, since I will be absent in the meeting. (1) Clarification of Human Task life-cycle - a suggestion Depending on what the Human Task would be, the service supplies the user interface to the Task. After the Human Task is crated, WS-C hand-shake takes place, and apparently the "start" request will be issued by the Task List Client at some point to the WS-C. This has not been elaborated. What is the format of this message? The standard has not defined it. This message is then to be passed to the Task implementation presumably. This is out-of-scope but probably should be mentioned as the possible link between the WS-C and the Task implementation on the service. Presumably, then, there is a return message, which will start the ball rolling. What is the format and what information does it have to contain. In my opinion, this return message must return the nature of the User Interface the service is to provide. At minimum, it should indicate (a) the nature of the UI, (2) how to call the UI (since the return message does not return the UI itself if it is an application - not a simple XML, such as XMLForm or a single HTML Form). If this is convincing enough and other members agree, probably a small working party should work on the concrete proposal? (2) Human Resource allocation problem (the Subtask proposal) I am not convinced that Subtasks, Parent Task, Children Task and Routing Policy is the way to go. That conflicts with BPEL and I don't think that that would be our interest. For example, in IMS Learning Design, this is done as an overlay on a workflow. That is, the People Assignment is not bound by Activities. Currently the BPEL4Peole 1.0 has People Assignment construct per Human Task. In my opinion, this is the problem and the restriction. One way to solve this it not to embed People Assignment constructs to any Tasks. The proposed Parallel and Serial Human Assignment construct still does it because it is still thinking it as these as Human Task constructs. Liberating Human Assignment from Human Task definitions is one way to achieve it and I think that that gives more clarity and flexibility we require. Practically, probably the People Assignment construct should be separate from BPEL definition and People Activity or Human Task definitions, but defined in some other part of the Process and can refer to People Activities (or Tasks) by reference IDs. This is seen in other workflow languages. As it has been proposed, we need new constructs to allow people working as a group together on a Task or sequentially or in parallel. However, in my opinion, we do not need Parallel or Sequential notations. We can use Activity- or Task IDs to form relationships. For example, we can say: (with Logical Group, Literal or Dynamic people references) Roles A, B, and C will do People Activity A. (This means they work together). Role A will do People Activities A, B, and C. (BPEL can have them as Parallel branches). This is the parallel construct. People A will do People Activities A, B, and C. (BPEL can have them as a Serial construct). This is the serial construct. Since the Human Task defines the nature of the Task and not a Process-oriented construct, I suggest that we assign people to People Activities (unless People Activity can have more than 1 Human Tasks - that is possible but probably it should be avoided). This is more in-line with Swim Lane idea seen in BPMN or XPDL. Finally, this brings a question about the concept of Human Task, if it depends on the Task posting ad Task List mechanism. Perhaps the Task posting should be primarily related to the People Assignment problem, rather than the definition of the Tasks the People Activities should perform. (Although the latter is what will be presented to the user when he/she wants to decide to claim it or not). In effect, this highlights the 4 different sides of the problem. People Assignment definition at the Process design time, Task posting at runtime (related to the People Assignment), and People Activity construct for Process transitional unit definition, and Human Activity definitions for the People Activities. I hope that I am making sense. Best regards, 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 26/11/2008, at 3:51 AM, Dave Ings wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]