-
1. Re: task and swimlane roles
tom.baeyens Feb 17, 2009 4:40 AM (in response to tom.baeyens)i'll take this rout for this iteration. let's evaluate after the release.
-
2. Re: task and swimlane roles
heiko.braun Feb 17, 2009 5:05 AM (in response to tom.baeyens)Although I understand what you describe I always stumble across the word "Role". It seems to be abused in this context. "User,Group and Role" are commonly used in conjunction and have a particular meaning. Now when I read RoleType==User it get's really confusing to me.
I need to think about a different proposal, but I hope it explains why I have difficulties with the current naming.
But besides that just a few comments:
* We could simplify the API by joining RoleType and role into one entity:RoleAssociation: { type; role; } void addTaskRole(long taskDbid, String refId, RoleAssociation assoc);
* I am missing the finders, i.e. TaskService.getTaskForRole(...) -
3. Re: task and swimlane roles
heiko.braun Feb 17, 2009 5:05 AM (in response to tom.baeyens)BTW, what's the refId?
-
4. Re: task and swimlane roles
heiko.braun Feb 17, 2009 5:09 AM (in response to tom.baeyens)To further explain the unification of type and role into one entity, look t the example below:
As isTaskService.addTaskRole(73, "123-CallHome", RoleType.USER, "Heiko");
Could beTaskService.addTaskRole(73, "123-CallHome", new UserAssociation("Heiko"));
withclass UserAssocation extends/implements RoleAssociation { type = RoleType.USER; role; }
-
5. Re: task and swimlane roles
tom.baeyens Feb 17, 2009 5:33 AM (in response to tom.baeyens)so the 2 options are:
long taskDbid = ...; taskService.addTaskRole(taskDbid, IdentityType.USER, "johndoe", Role.ROLENAME_CANDIDATE_USER);
orlong taskDbid = ...; taskService.addTaskRole(taskDbid, new User("johndoe"), Role.ROLENAME_CANDIDATE_USER);
wherepublic 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 ? -
6. Re: task and swimlane roles
heiko.braun Feb 17, 2009 6:24 AM (in response to tom.baeyens)Recent chat between tom and heiko
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 -
7. Re: task and swimlane roles
heiko.braun Feb 17, 2009 6:25 AM (in response to tom.baeyens)Another example
TaskService.addParticipant(taskDbid, new User("3rd party"), Participation.FINAL_RECEIPIENT);
-
8. Re: task and swimlane roles
heiko.braun Feb 17, 2009 6:26 AM (in response to tom.baeyens)Participation.CANDIDATE would be a pretty generic one. maybe it's enough to get started.
-
9. Re: task and swimlane roles
camunda Feb 18, 2009 2:15 AM (in response to tom.baeyens)Heiko wrote:
Although I understand what you describe I always stumble across the word "Role". It seems to be abused in this context. "User,Group and Role" are commonly used in conjunction and have a particular meaning. Now when I read RoleType==User it get's really confusing to me.
Why not keeping the term "actor" which did the job well in jbpm3? And doesn't lead to the confusion Heiko described... -
10. Re: task and swimlane roles
tom.baeyens Feb 18, 2009 2:42 AM (in response to tom.baeyens)actor actually relates to what we now call an IdentityRef: a reference to a user or a group (this is now typed: UserRef and GroupRef inherit from IdentityRef)
basically the participant is a generalization of the pooled actors in jbpm 3. pooled actors were candidates. now we have other forms of participantion as well: candidate, owner, viewer, client, and so on. -
11. Re: task and swimlane roles
kukeltje Feb 18, 2009 9:20 AM (in response to tom.baeyens)I will come up with a more detailed response later, but why not
take terminology from
http://www.workflowpatterns.com/patterns/resource/resource_modelling.php
or maybe from ws-ht?
Creating our own terminology is imo not the way to go.