[Design of JBoss jBPM] - Re: execution transitions, data flow and other associations
by tom.baeyens@jboss.com
Koen,
"koen.aers(a)jboss.com" wrote : I think that message flow and associations are typical constructs that are used by a business analist. I am not sure they are that important to the execution.
|
They are valuable modelling constructs. But we have to define wether they mean anything at runtime and if so, we have to create a logical story for those other link types.
"koen.aers(a)jboss.com" wrote : Of course if message flows are added to the GPD at some point in time and the GPD is to operate on the same model as the runtime engine, it would make sense to add these capabilities to the core model.
|
The model used by the GPD is second to the real issue here. First we have to define if other link types make sense, second we have to get a crystal clear picture of what the other link types mean at design time and at runtime (if they have any runtime implications at all). Only after that story, we'll see if and how the GPD model is going to cope with this.
"koen.aers(a)jboss.com" wrote : As for the question what a message flow would mean in jPDL, I think it could be used to somehow limit the visibility of the variables contained in this flow to all the nodes that are connected by the flow.
If you have a document that has to be passed from one node to another and the analyst wants to model this graphically, the main thing is that the document is produced (entered) in one activity and consumed (available) in the other activity. I don't think that we should be considering to limit the visibility of all other variables in the process.
The runtime impact of data-links then becomes quite thin. It only specifies that the data item is required input in the source activity... But the runtime is not why we would add this. We would add this for the business user to be able to create better models.
Would you think that such a construct is usefull for business users ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982913#3982913
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982913
18 years, 2 months
[Design of JBoss jBPM] - Re: execution transitions, data flow and other associations
by tom.baeyens@jboss.com
brittm: i'm not yet convinced about the shared processes as a general concept to pursue in jpdl. the implications are far reaching and i'm not yet sure this is a common use case.
one thing that might help you already a little bit is that in jbpm 4 we will be componentizing the node implementations. so that you can build complete node packages, including jPDL-parsing, hibernate persistence, actionHandler based implementation, designer form, icon, ... That way it will become more feasible to develop your own custom node and really integrate it into the current runtime and toolset.
maybe the shared subprocesses could become part of jbpm as a kind of advanced or add-on node package, not part of the default configuration.
About links: i think they are something different. Each link is a named boolean that connects two concurrent paths of execution. Then, the target activity has an boolean expression as a function of the arriving links. The activity will only be executed if the link expression resolves to true. But Alex will know better.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982908#3982908
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982908
18 years, 2 months
[Design of JBossCache] - Possible optimization of CachedSetImpl
by genman
I was thinking that, instead of using a simple integer tag for each POJO in a Set, that you could incorporate the hash code (or part of it) along with a counter for objects that happened to have the same hash code, but not equal.
For example, the Set.contains() method could be written as:
| public boolean contains(Object o)
| {
| int hash = o.hashCode();
| Collection<Object> children = node.getChildrenNames();
| for (int i = 0; i < children.size(); i++) {
| Long key = new Long((long)hash | ((long)i << 32));
| Object o2 = ...get(key);
| if (o2 == null)
| return false;
| if (o.equals(o2))
| return true;
| }
| return false;
| }
|
Worst-case performance is O(N), best is O(1).
Set.remove() would mean more complication; you'd have to actually shift entries around to fix gaps, if there were any.
I could contribute this as a patch if it made sense.
One thing I wonder though is, does it hurt to use Integer in an FQN instead of a String? I didn't see any problems during tests... Long.toString() would be fine I guess but less efficient.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982872#3982872
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982872
18 years, 2 months