Re: [bpel4people] Feedback on Routing Pattern proposal

I am about to join the BPEL4People TC and maybe not well versed with the pretext or context of the problem, however, this is my thoughts.

I was also thinking about the same problem, too, in terms of the Use Case you have mentioned in BPEP4People White Paper long ago.

The Use Case is:

When a person is supposed to do consecutive Activities (Tasks), the person can do those Activities without going back to the Task List to claim those Tasks Activities.

This is not impossible in BPEL4People 1.0 specification but it requires the Task Manager to check user identity before and after Tasks and do short circuit the Task List step, and present consecutive Tasks to the end user somewhat seamlessly.

The problem lies with the fat that the Task boundary and the Activity boundary are the same in the BPEL4People 1.0.

I have been a system architect for a human workflow system and it has used people assignment before Processes begin. Each Task inside the Processes may be assigned with different people, but this does not require Task List to be involved during the execution of Processes.

I was thinking that perhaps the Task boundaries and Activity boundaries in BPEL4People required something similar, i.e. PeopleActivity and HumanTask should not be the same unit.

The proposed idea of Subtask is related to this problem and I have some doubts.

I can see that the idea has some problem, because in BPEL4People the Process/Subprocess and Tasks were well demarcated. The former handled the routing and the latter did not.

Although I can see the motivation about the Subtask concept, with Subtask concept we are bringing in the functional aspects of BPEL (routing capabilities) into Tasks. For example, BPEL construct already has Parallel routing. Duplicating it inside Human Tasks is probably not ideal.

In general workflow patterns, this is a resource assignment problem, not the routing problem.

i.e. workflow is made up of Activities, some of which may be automatic services or system function (such as routing elements etc) and others human Activities. If we can set Task boundaries regardless of PeopleActivity, this workflow works without the concept of Subtask.

For example, Process may contain People Activities A, B and C.

We may be able to set the Task boundaries for User A to do Activities A and C, and User B to do Activity B and C (in collaboration with User A).

This is similar to the BPMN concept of Swim Lanes.

The current BPEL4People v 1.0 idea of Human Task does not allow this. If we are going to take the path of drastically changing v 1.0 with Subtask kind of idea, we should rethink this in the light of Swim Lanes and how we do it in BPEL4People.

This is actually not a bad idea, since modeling Business Processes inherently involves thinking of human users taking up some roles in Processes and resulting BPMN models almost always involves Swim Lanes. Since BPEL did not need this, we did not have this type of concept or construct with it, but I think that BPEL4People definitely needs one.

Does it make sense?

Also, BPEL allows Sub-processes. Maybe the Subtask should be modelled around it for modularity? Or, is it a different concept altogether? Which way do you think is natural?

There are two solutions:

(A) Make the Process flow (control flow) as Human Flow as a whole or parts (I think that this is the Subtask idea. It is mixing the main control flow with human Task flows)

(B) Human assignments (Tasks) is an overlay for the main control flow, i.e. Resource Assignment pattern problem for the main control flow.

I prefer (B) in terms of the clarity to the language. As I said, we do not have to duplicated elements already existing in BPEL in BPEL4People in a different form.

( I have not touched upon the Subtasks getting the data/roles from the main Task)

Thanks,

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

www.mq.edu.au

www.melcoe.mq.edu.au/projects/RAMP/

--------------------------------------------------------------------------

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 19/11/2008, at 9:08 PM, Matthias Kloppmann wrote:

Dear all,

we suggest to structure the routing pattern discussion around the following topics, which build on each other:

1. General Subtask concept -- parent-child relationship, coupling of life-cycle, coordination, state diagrams, ...
This is independent from the concrete routing pattern discussion, but is used as a basis for routing patterns.

2. Routing patterns proper -- pre-defined patterns, extension points, terminology, nesting model, early completion, ...
This builds on subtasks.

3. Data handling: result combination/aggregation, input distribution, completion condition, ...
Need to define boundary between pre-defined handling (e.g., for outcomes) and extension points.

4. Considerations concerning organizational model, e.g., management chain
According to our interpretation of the B4P charter, issues concerning the organizational model are out of scope of the TC work. The concrete scenario using a management chain can be addressed with existing means -- see comments in doc.

The attached document contains our concrete comments to the Oracle proposal.

We'll come up with refined proposals for the different topic areas, based on Oracle's proposal and our joint discussions, over the next couple of days.

Viele Grüße/Kind regards,
-Dieter, Frank, Gerhard, Matthias

<BP-28-RevisedProposal (comments IBM).doc>

bpel4people message