-
15. Re: task assignee vs owner
Heiko wrote:
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 do not agree.Kris wrote:
I don't think that you should either go for WS-HT or not at all
My opinion too! To support WS-HT is a good thing if you need a task component which supports WS-HT or if you want to use that as central HT component in your SOA.
But a lot of use cases face different requirements and there you need to adapt task lifecycle for your needs (but break WS-HT).Kris wrote:
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.
I agree on that. This is why integrating jbpm and drools is a very good idea! But I would keep seperation of concers, so state chart in jbpm and rules in Drools.
Ehm, and sorry Tom for somehow hijacking this thread ;-) -
16. Re: task assignee vs owner
I agree with Kris and Bernd regarding the WS-HT usage and plugability
Although I'm also partly with Tom that if you can write almost 1MB of specs about 'task management' it is complex. Secondly (and there may be 'workarounds') I dislike the WS-* nature of it. Makes it way to complex imo. I want xsd's not wsdl'sBernd wrote:
Kris wrote:
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.
I agree on that. This is why integrating jbpm and drools is a very good idea! But I would keep seperation of concers, so state chart in jbpm and rules in Drools.
Yes, integrate them in the SOA platform, not in one project. But politics.....I've never had a problem integrating jBPM and Drools in one application. I did not use either of their deployment methods and just bundled them in versions of applications. Works great (multiple versioned webapps related to processes/rules is a much more complex problem) -
17. Re: task assignee vs owner
I believe a task component would probably be one of the easiest component to collaborate on (as it can be completely decoupled from the internals of the execution engine). We have expressed our interest in collaboration on this over half a hour ago and I have repeated this numerous times. What disappoints me is that the you guys now apparently decided to start creating something entirely custom without any communication whatsoever.
Kris -
18. Re: task assignee vs owner
It's not like that. We will evaluate the WS-HT proposal again, but we cannot change the roadmap from one day to the next. Something we can collaborate on in the meantime is the SPI between the process engine and the actual task management component. Ideally it would be possible to replace one implementation with another at some later point in time.
All the task component properties (i.e. pluggable lifecycle, user/roles, attachments, forms, timers) can evolve independently from that SPI in place. -
19. Re: task assignee vs owner
"KrisVerlaenen" wrote:
I believe a task component would probably be one of the easiest component to collaborate on (as it can be completely decoupled from the internals of the execution engine). We have expressed our interest in collaboration on this over half a hour ago and I have repeated this numerous times. What disappoints me is that the you guys now apparently decided to start creating something entirely custom without any communication whatsoever.
Kris
i don't see it the same way.
we had a task component in jbpm 3 and we are building an improved version for jbpm 4.
in the meantime, i saw that you have also build a task component as well.
first of all, our time constraints don't allow us to endeavour on a unified task component. it takes *a lot* of time to understand each others goals, implementation, merge and work like that. we simply don't have the time to go through that process at this stage. i assume that you are aware of this as you also point us to your code without working with us on our project. no offence intended, just pinpointing that the hard part is the merging of ideas and requirements into a single unified implementation.
also, i don't think it is good to spend energy on building a "unified" task component for 2 engines which should have be one in the first place.
we don't have time enough to consider the merge-components strategy. but you are welcome to join our development efforts if you're interested. -
20. Re: task assignee vs owner
Hello, This is my first post on the forum.
I have been following this thread with interest as this is an area we are currently looking to implement against the jBPM 4 release.
The requirement that we face is that task assignment is a nested workflow process. . Conditional behaviour surrounding who gets allocated the task and what happens to the task due to inactivity / incompleteness are requirements that at we are wanting to address over the next couple of months.
Our objective is to support dynamic workflow allocation across organisational boundaries. In terms of achieving this we have a requirement to support a two stage assignment process whereby tasks are assigned firstly to an organisation and then to an individual within that organisation. The assignments can in some cases be conditional on the approval of the assignee [organisation/ individual].
An excellent article on the sorts of general requirements that a jBPM task allocation module / plug-in should support can be found here http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2007/BPM-07-10.pdf
If we can be of assistance let me know.
Rgs
Shaun