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: Re: [bpel4people] BP-79: Interoperability between task parents and task processors from different vendors


Hi all,

I found the proposal for the routing and composite human tasks PPT as an attachment to F2F. It is very detailed and a lot of work and thoughts went into it.


----------------------------------------------------------
General considerations:

In general, I am a bit cautious about bringing in routing, composite and data flow pattern issues into human tasks.

IMHO, routing belongs to BPEL.

IMHO, people assignment and data flow logics belong outside human tasks. They should still use b4p or htd namespaces, and they are extensions of BPEL.

This way, we can more freely wire up the people claiming Tasks and actual users routed to various sub-tasks, data routed with separate logics from the definitions within the Human Tasks. BPEL is a workflow language, so this is more consistent with the work, as well.

Currently, the proposed routing logic inside Human Tasks has presented no justification why they have to be inside Human Tasks and must duplicate the logics that the BPEL is good at and has already some constructs. (Only as far as I can see. This may have been done in the past).

If there is any special reason why the routing logics must be done inside Human Task, I have not seen Use Case or reason.



----------------------------------------------------------
Some Use Cases:

Composite or Sub-tasks means there is some relationship between the Parent Task and Children. That is, we should be able to use the Parent Task and treat it like a blackbox as far as the BPEL flow outside it is concerned. The current proposal does not satisfy this. Whatever inside the Parent Task is exposed to the system and demands it to do some work without giving any benefit of why it is a composite Task.

One example is that if a composite Task has 5 parallel Sub-Tasks inside it that require the same user, then it should not ask for the user for the Sub-Tasks.

On the other hand, if the Sub-Tasks require all deferent users, then the Parent Task must ask for 5 users, not when the Child Tasks are to be executed - unless this is a late-assignment requirement.

If the people assignment is done outside the Tasks, this can be easily constructed, including the case where the people assignment is done separately at the Parent Task and Child Tasks.

In a normal sense of composite service, one can think of different kind of Composite Human Task. The Parent Task must present a composite of UIs to the end user from different Web Services, each of which provide pieces of UIs.

In a normal sense of parallel Task, one can think of one person doing parallel works together with multiple UIs or a composite UI. Not many people doing the same Task in parallel in isolation.

Also, in a normal sense of parallel, it could mean parallel split but not necessary doing the same Task. Each branches may require different people doing different Tasks.

Also, we can think of some Tasks defining multiple Roles that must be assigned, and each Role working separately or concertedly working on the same Task at the same time or in succession or in isolation or at different time. (How the Roles get assigned is another matter).

The current Composite Task proposal should be able to model flexible potential Task requirements.



----------------------------------------------------------
Group and a Task:

IMHO, BPEL and B4P/WS-HT have limitation in its thinking that a person cannot assign a Group to a Task (assign a Group on behalf of the Group and the Group members get notifications automatically later). Currently, if you assign a Group to a Task, the Task offered will be seen on the Task List by all the members but only one person gets to be the Actual Owner.

To assign a Group of people to a Task, we had to use BPEL for-each construct to loop around the Task definition with different people offered the Task repeatedly at each iteration.

The current proposed Routing Task or Composite Task can offer a Task to a Group in a similar sense, if a Group was assigned to a Parent Task and then if it specified an automatic people assignment to a parallel Sub-Task construct.

However, both does not allow a Group assigned to a single Task and doing the Task together. An example is a Chat service. Unlike a Voting type of Web Service as a Task, the Chat Service must be able to model that it is used at the same time and all Group members must access the same instance. In reality, however, of course, in the backend, the separate connections are correlated by sharing a same session ID. But the point is that this kind of how it is actually done should be hidden from the model at the Process level.


----------------------------------------------------------
My request:


Can some one give me a feedback? Or, do you suggest that these should be raised as Issues formerly? (Not to the TC but to the alternate Routing/Subtask working group?)



----------------------------------------------------------
My proposal:

Maybe the B4P and WS-HT 1.1 should be delivered without the complex Task specification?


----------------------------------------------------------
p.s.

It would be good to place the PPT of the work in progress in some place on the TC web site (maybe committee only area?). It may be already there, so I'm sorry for my ignorance if that is the case.



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
--------------------------------------------------------------------------
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 11/03/2009, at 9:15 AM, Yoichi Takayama wrote:

Thanks, Dieter.

I was following the minutes of the alternative meetings but could not figure out what the model was.

I will re-check the F2F meeting presentation, although I have to find it first.

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
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 11/03/2009, at 12:46 AM, Dieter Koenig1 wrote:

Yoichi, the current state of the spec does not preempt any resolution for
issues BP-28 - BP-34, which is work in progress and may introduce new task
types if needed. As a result, BP-79 is a duplicate - this is really just a
formal point. The state of the routing patterns discussion can be seen in
the F2F presentation and the minutes from the bi-weekly working sessions in
the OASIS mail archive.

Kind Regards

Dieter König

Senior Technical Staff Member, WebSphere Process Server Architect
IBM Software Group, Application and Integration Middleware Software
WSS Business Process Solutions


smime.p7s



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