Kudos to Alejandro
by Thomas Diesler
Hi Alejandro,
kudos to your work!
I am very impressed and delighted to see that despite the incredible
amount of good work you've been doing over the last weeks, you actually
managed to keep the code base in pristine condition.
http://jbpm.dyndns.org:8280/hudson/job/jBPM3-Container-Matrix/changes
well done
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 2 months
[Design of JBoss jBPM] - Re: process definition as a resource
by heiko.braun@jboss.com
I am very much in favor of what you call "Persistent Process Resource", which basically means just storing execution state and history in the DB.
Anything else, and most importantly, all class resources should be retrieved through the classloader. This already answers your question regarding the clustering: Leave it to the deployment/classloading framework of the AS.
But in general we should aim at the plain non clustered AS integration first
and then worry about clustering when we need it. But you easily relay questions like this if you leverage the AS infrastructure too a large degree.
I do actually have uncommitted AS integration code on my disk, that installs the process engine as a service and adds the corresponding deployers so tat you can drop *.par archives intio the deploy folder. Quiet similiar to what Bernd described in his Blog, just for AS 5.
I would say, to begin with we should aim at
1) Persistent Process Resource as execution mode inside the AS
2) Add a service and deployer
3) Fix the classloading (classloader registry, reassociation upon reboot)
4) Deal with diferent versioning strategies upn deployment and server boot.
We need to get this sorted before diving into clustering topics.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210594#4210594
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210594
17 years, 2 months
[Design of JBoss jBPM] - task and swimlane roles
by tom.baeyens@jboss.com
heiko,
i'm splitting the user and group roles. does this look ok to you ?
public enum RoleType {
|
| USER,
|
| GROUP
|
| }
In TaskService:
/** add a role to a given task.
| * @param roleType identifies if this is a user role or a group role
| * @param refId identifies the user or group
| * @param role specifies the role that the user or group fullfills for this task. */
| void addTaskRole(long taskDbid, String refId, RoleType roleType, String role);
|
| /** get roles related to a given task.
| * @param roleType if not null it will filter the roles
| * @param role if not null it will filter the roles */
| List<UserRole> getTaskRoles(long taskDbid, RoleType roleType, String role);
|
| /** removes a role to a given task. Nothing happens (no exception) if
| * the role does not exist.
| * @param roleType identifies if this is a user role or a group role
| * @param refId identifies the user or group
| * @param role specifies the role that the user or group fullfills for this task. */
| void removeTaskRole(long taskDbid, String refId, RoleType roleType, String userRoleType);
|
then the same methods for associating roles with swimlanes
void addSwimlaneRole(long taskDbid, String refId, RoleType roleType, String role);
| List<UserRole> getSwimlaneRoles(long taskDbid, RoleType roleType, String role);
| void removeSwimlaneRole(long taskDbid, String refId, RoleType roleType, String userRoleType);
does this make sense in the context of the discussions we had about it ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210593#4210593
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210593
17 years, 2 months
[Design of JBoss jBPM] - Re: process definition as a resource
by kukeltje
"tom.baeyens(a)jboss.com" wrote : jbpm users typically deploy the process to the db and then store the instances in the DB as well.
|
I think most do not realy do this 'on purpose'. It's how it works.
"tom.baeyens(a)jboss.com" wrote :
| another aspect that becomes more complicated in 'persistent process resource' execution mode is deployment in a clustered environment. when using the DB to store process definitions, this is the single entry point accessible from all nodes. but how would we deploy a resource to all nodes in a cluster ? and how would the process definitions be cached in memory ?
|
Uhhmm.... JBoss Cache?
Funny is that I kind of semi use jBPM in this resource way. I extend the processdefinition with my own xml tags for which I do not develop a specific jpdl parser or whatever. Runtime, I read the xml nodes with xpath from the processdefinition in the processarchive (will show this in the presentation also on the community day)
I'll think about the other thinks though. Not fully grasp all differences yet, but that might be because it is to late (04:00 am)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210560#4210560
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210560
17 years, 2 months
[Design of JBoss jBPM] - Re: task assignee vs owner
by kukeltje
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's
Bernd 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)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210481#4210481
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210481
17 years, 2 months
[Design of JBoss jBPM] - Re: task assignee vs owner
by camunda
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 ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210477#4210477
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210477
17 years, 2 months
[Design of JBoss jBPM] - Re: task assignee vs owner
by KrisVerlaenen
anonymous wrote : anonymous wrote : +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.
Bernd, while we have tried to take into account that the life cycle might need to be pluggable in our design, we didn't really put a lot of focus on it, hence we don't have examples or documentation on how to change it. But I guess you could take a look at the implementation of our TaskServiceSession. Generic documenation on our human task service (work in progress) can be found here:
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/t....
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.
Kris
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210445#4210445
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210445
17 years, 2 months
[Design of JBoss jBPM] - Re: task assignee vs owner
by KrisVerlaenen
anonymous wrote : 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.
Kris
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210437#4210437
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210437
17 years, 2 months
[Design of JBoss jBPM] - Re: task assignee vs owner
by camunda
Hi Kris,
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....
Cheers
Bernd
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210427#4210427
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210427
17 years, 2 months