we could distinct bewteen the owner of a task (the one that has the responsibility) and the assignee (the one that is supposed to make the next progress for the task).

distinction use case: manager gets a task and delegates to secretary to perform fill in some of the task form details. the manager wants to keep full control. the secretary is only allowed to fill in the form, but not submit the task. when the secretary is done, he/she reassigns the task back to the manager.

is this usefull ? did you miss this feature in jbpm 3 ?

it does introduce some complexity in the sense that in the api, we have to distinct between owner and assignee in the assignment related interfaces.

"KrisVerlaenen" wrote:Tom, what about working together on a shared task component with the Drools team? Our human task component already supports use cases like this (and many more).

Kris

i had a quick look at the drools task component before. model looked too simplistic for the use cases that we have. and it also didn't look appropriate to support the human interaction management features that we also want to incorporate. and it would be harder to make the drools task component fit into our architecture.

on the other hand, what would be the requirements for drools to collaborate with our task component ?

we have pluggable task lifecycle to allow for the human task lifecycle as well as a much simpler default lifecycle.

we also have hierarchical subtasks, comments and roles

i've also integrated jbpm with the jboss identity component. so all of our task component will be based on that integration as well.

I once had such an IRL use case: if the task assignee gets sick, it should be done by someone else. If that person gets back before the task is finished, it is put back to the assignee.

for that use case i have the roletype 'replaced-assignee'

/** a person that was assigned to a task, but got replaced because of
* absence or another reason. This way, a trace can be left in case
* This person returns and wants to take back his tasks that got
* reassigned. */
String ROLETYPE_REPLACED_ASSIGNEE = "replaced-assignee";

Model looks too simplistic? It's based on the WS-HumanTask spec, it would be a kinda strong statement saying they didn't do a good job? ;) What kind of human interaction management features are you talking about? And the Drools component is just a Java POJO service, or you can use the WS front-end ... how much easier to integrate can it be?

we also have hierarchical subtasks, comments and roles

You really took a look at the code? You can't have missed this then, we support all of these (and again, many more).

But I have another one. In many of the processes in the companiy I worked for, it is required to send out an xml message to the party that performed a task which lead to this specific task. e.g.:

- You ask me (or someone if the systems decides who it gets assigned to) to repair a car- I accept to do it, or reject it

In case there is no other wait-state in between (one task directly leads to the next task after a 'signal'), you can set some variable on the next task with the role/actor/... value of this former task. When other waitstates are in between (e.g. an external service has to be called async) it does not work. So I added my own tag to the task in the processdefinition without customizing the taskInstance (I just read the xml from the process archive). This tag is a reference to the swimlane that had the previous task. It is kind of like a business transaction then in ebBP.

1) Supporting WS-HumanTask would be a interesting improvement for jbpm! But I also agree with Tom, that it doesn't fit in any case, so having a pluggable life cycle is the best option. And to model that lifecycle with jpdl itself would be a natural fit in the jbpm infrastructure I guess.

And yes, I faced that requirements at least a couple of times, some customers did really advanced human task management ;-)

2.) Having a joined Human Task Management component of jbpm and drools would be a very good thing! I think it doesn't make too much sense to develop that twice in JBoss. And it would be much better to have one user interface as well (for every component creating Human Tasks in the JBoss SOA ;-)).And having two components always provokes the question why the both implementations are there.But maybe this involves politics which team is responsible for it?

And personally I don't know the Drools Human Task Management component yet, so I cannot really judge how good it fits for the jbpm requirements. And I get the feeling that Human task Management is more in the direction of BPM than BRM, so I see jBPM responsible for it. And Drools shouldn't even need persistence in the most common use cases for a Rule Engine, different to jbpm.

i think for most use cases their lifecycle model is actually overly complex. that's why we made our lifecycle pluggable.

First it was too simplistic and now it's too complex? ;)

The basic simple life cycle is: - someone creates a task for an actor - actor that needs to execute the task starts the task when he starts executing it - actor completes the task once he's done Doesn't sound that complex to me?

And if you really want to change the life cycle (out of the scope of the WS-HT spec), you can do as well in our component (we use MVEL configuration to define possible state transitions and their effect).

You're always welcome to take our task component, leverage it and help to build any use cases that it might not yet support.

I'm talking about collaboration, not this one-way you can use and improve whatever we have. Do we want to work an a shared human task component or not, and if so, what are the requirements / restrictions? Then we can decide what would be the best way to move forward?

And I get the feeling that Human task Management is more in the direction of BPM than BRM, so I see jBPM responsible for it. And Drools shouldn't even need persistence in the most common use cases for a Rule Engine, different to jbpm.

I've proposed the idea of an independent JBoss Human Task component about half a year ago, that's why I'm a little disappointed jBPM is now seems to be moving towards adding their custom implementation without discussing the alternatives.

I know about DroolsFlow and such but to be honest: I am still a bit scared about some of the stuff integrated in Drools today ;-) But maybe this is just because of the lack of time to have a deeper look into the source code.

In my opinion: Drools = BRM + CEP -> Yes, cool! But BPM? I think there is a lot of stuff around in BPM which makes it a sperate topic which should be targeted by a BPM software (like BPMN -> technical Model mapping, Simulation, BAM & Reporting, Persistence with the different kind of flavours, ...).

With the Human Task Component I agree with you that effort should not be duplicated! But I don't see the value of drools developing the second BPM solution as well. And I really would like to see "one JBoss answer" to this, meaning a clear distinction when to use Drools and when to use jbpm. And how to combine.

Kris wrote:

Do we want to work an a shared human task component or not, and if so, what are the requirements / restrictions? Then we can decide what would be the best way to move forward?

+1 for the shared task component supporting WS-HT (but not being tied to it, means having a pluggable life cycle). Kris, is there an easy example using your task component and how to change life cycle?

Kris wrote:

I'm talking about collaboration

Would make sense to me, but I still think exactly one project (or lets say one project manager) must be responsible to enable this.

Hopefully this doesn't get to political? But it is indeed a topic which is in my mind for some time already, as being someone who likes both projects very much in their respective fields! So I would like to see some progress in this area....

+1 for the shared task component supporting WS-HT (but not being tied to it, means having a pluggable life cycle). Kris, is there an easy example using your task component and how to change life cycle?

Either you go for WS-HT or you don't. But it doesn't make sense to rip it apart and customize bits and pieces. You'd loose the benefit of the specification in the first place.

In my opinion: Drools = BRM + CEP -> Yes, cool! But BPM? I think there is a lot of stuff around in BPM which makes it a sperate topic which should be targeted by a BPM software (like BPMN -> technical Model mapping, Simulation, BAM & Reporting, Persistence with the different kind of flavours, ...).

I disagree !

I agree on the fact that rules and processes are based on different paradigms (constraint evaluation vs state charts). And in that sense they could be considered separate topics. But in reality, if you try to model a business problem, you are confronted with logic that could best be represented using a business process and other logic where you would like to use rules. So in that sense it makes sense to integrate them.

And why would concepts like simulation, BAM and reporting, persistence,etc. only be applicable to BPM? They matter for BRM as well, hence the need for a unified platform ! And that's why Drools supports _integrated_ simulation, reporting, persistence, etc.

+1 for the shared task component supporting WS-HT (but not being tied to it, means having a pluggable life cycle). Kris, is there an easy example using your task component and how to change life cycle?

Either you go for WS-HT or you don't. But it doesn't make sense to rip it apart and customize bits and pieces. You'd loose the benefit of the specification in the first place.

I don't think that you should either go for WS-HT or not at all, as the implementation is fully pluggable (meaning that the process engine should be able to work with different implementations). It just means that by default you could follow the WS-HT spec, but in cases where people want to change it, you could provide the hooks that enable them to do that. But then they are responsible.