[Design of JBoss jBPM] - Re: task and swimlane roles
by heiko.braun＠jboss.com
Recent chat between tom and heiko
anonymous wrote :
| Tom
| ----------------
| or can that property of the stakeholder be called role ?
|
| then we do not have the same confusion as we had before
|
| Heiko Braun
| ----------------
| right, we are looking fot the property of a stakeholder
|
| that's what I call the verb
|
| a user or group may be a stakeholder
|
| but it doesn't specify their involvement
|
| Tom Baeyens
| ----------------
| what about just keeping the term role for that property ?
|
| Heiko Braun
| ----------------
| participant and participation is not too bad
|
| USER johndoe PARTCIPATES as CANDIATE
|
| i like this:
|
| taskService.addParticipant(taskDbid, new User("johndoe"), Participation.CANDIDATE);
|
| Tom Baeyens
| ----------------
| yes
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210644#4210644
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210644
16 years
jBPM performance test coverage
by Thomas Diesler
Hi Trevor,
https://jira.jboss.org/jira/browse/JBPM-2043
the system performance tests in the SOA platform do not seem to be
isolated enough to be usable by the project - at least not as they are.
Performance tests that work at a larger integration level are actually a
good thing to have and I am glad that they exist and show results.
Now the question arises who owns and maintains those tests? IMHO, the
project should actually not be the owner (we currently don't have SVN
access anyway). As I understand it, SOA QA engineering owns these tests,
which is how it should be.
The jBPM project also needs to do some performance testing for every
release. This test coverage is currently missing AFAIK and is subject of
JBPM-2043.
To resolve the current issue quickly, I propose to work close with the
owner of those SOA performance tests to create equivalent tests in the
jBPM tests suite such that we can reproduce what you are seeing. These
jBPM performance tests need to be isolated from the ESB context.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years
[Design of JBoss jBPM] - Re: task and swimlane roles
by tom.baeyens＠jboss.com
so the 2 options are:
long taskDbid = ...;
|
| taskService.addTaskRole(taskDbid, IdentityType.USER, "johndoe", Role.ROLENAME_CANDIDATE_USER);
|
or
long taskDbid = ...;
|
| taskService.addTaskRole(taskDbid, new User("johndoe"), Role.ROLENAME_CANDIDATE_USER);
|
where
public interface Identity {
| getId();
| }
|
| public class User implements Identity {
| public User(String userId) {...}
| ...
| }
|
| public class Group implements Identity {
| public Group(String groupId) {...}
| ...
| }
both are acceptable to me. but working with objects in a session facade can lead to confusion. so i am leaning a bit more towards first option with identityType = IdentityType.USER and identityId = "johndoe"
WDYT ?
do these 2 options reflect the choice correctly ? or do you see other diffs as well ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210628#4210628
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210628
16 years
[Design of JBoss jBPM] - Re: process definition as a resource
by heiko.braun＠jboss.com
anonymous wrote :
| so if we assume that versioning is done by the client in the process file, then this would really fit the jboss deployer architecture. (finally !)
|
yes, that's what bernd did with the AS 4 deployer as well. let's start with explicit versioning inside the process description, at least for AS deployments. It sounds reasonable to me.
anonymous wrote :
| if a user deploys a new version of a process...
|
we'd need to be more precise here. I can actually see three use cases:
1) a changed pdl file, but classes remain the same
2) same pdl, but classes changed
3) changed pdl and classes changed
IMO 1) and 3) should lead to a new version of that process, i.e. demanding an explicit version increment in the pdl, whereas 2) simply associated a different resource set to with process (i think bernd called it patching/bug fixes)
In general all those cases where the pdl is changed, we can encounter two situations: the user explicitly changed the version within the pdl or he didn't. IMO the later case indicates "replacement" of a process definition.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210626#4210626
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210626
16 years
[Design of JBoss jBPM] - Re: process definition as a resource
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote : 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.
|
downside is that this would not support process versioning as we're used to. (at least not without hacks) maybe we should consider support this as a separate execution mode.
so if we assume that versioning is done by the client in the process file, then this would really fit the jboss deployer architecture. (finally !)
"heiko.braun(a)jboss.com" wrote : But in general we should aim at the plain non clustered AS integration first
| and then worry about clustering when we need it. You can easily relay questions like this if you leverage the AS infrastructure too a large degree.
|
if possible, we should look at the DB for clustering. if we stick with that, they our clustering works in any environment. so those type of solutions are preferrable.
but on top of that, we can always look at how we can improve jboss specific clustering. (like described above)
"heiko.braun(a)jboss.com" wrote : 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 that you can drop *.par archives into the deploy folder. Quiet similiar to what Bernd described in his Blog, just for AS 5.
|
loading versioned classes lead to real complex solutions. and i'm not sure if those tricky things are justified.
if a user deploys a new version of a process, it's always possible to update the classnames that are referenced and append _V2 or something to the classname. users can always reference new classes by pointing to different classnames. and then we don't have to come up with the very complex classloading to load similarly named classes in different process definition scopes.
"heiko.braun(a)jboss.com" wrote : 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 different versioning strategies upn deployment and server boot.
|
| We need to get this sorted before diving into clustering topics.
you're forgetting the basic BPM Suite use case: if you want the process versioning to work on every platform to give a non-coding-only-poin-and-click demo, then you need the dynamic persistent use case. so that should be 0) and for the next efforts, i indeed agree with your list
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210608#4210608
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210608
16 years