why separate 'node' and 'decision' elements?

[bobmunger]

why are the funtions of these elements separated?

node transitions that are driven by logic would make modelling simpler.

it seems like the purpose of a 'action handler' should be different from a 'decision handler'. in java.jbpm.test tests, 'action handler' code sometimes drives transitions. obviously this is because there is no other alternative.

the differing definition of 'transition' at the root scope and the decision scope seems random. the inability to drive node transitions by logic (or requiring a node to transition to a decision to implement transitions with logic) creates model complexity.

a node should have an 'action handler' and a 'decision handler' and it's transitions should allow logic.

[koen.aers]

A decision is just a particular implementation of a node. Nodes define the major extension point in jBPM. The process definition language can be extended by defining new node types with not yet available behaviour. This behaviour will mostly be related to executing the graph, but can also include some other executions. The nodes in the graph provide the high level view for a business analist. Technical people provide technical details attaching actions with action handlers to particular events such as going over transitions or entering/leaving nodes. They don't have to modify the graph in doing so and this keeps the business analists happy.
So summarizing... if your business analists would like a node that executes some stuff and then takes a decision, you can define it for them ;-)

Regards,
Koen[/url]

[bobmunger]

when you say 'The process definition language can be extended by defining new node types with not yet available behaviour', do you mean actually extending node to create a new type that has a corresponding new element in jpdl or do you mean extending it via the node action class and the xs:any metadata that can be passed to it?

[kukeltje]

The latter. Extending it (wel rather making it user extendible) with real new elements is on the '
investigate sometime' list but not with a high priority

[bobmunger]

okay. i understand.

i would suggest that forcing a branch to a decision point before allowing guarded transitions described in metadata is a serious limitation.

i would also suggest that a new jPDL 'node' called a 'activity' that supported both a 'ActionHandler' delegate (to handle typical MVC user actions) and a 'DecisionHandler' delegate (to handle rules describing flow), as well as 'to' transitions driven by beanscript metadata (as in 'decision' elemeent), would lead to cleaner modelling and closer allignment with UML activity diagrams.

an additional benefit would be less impedance with WfMC xPDL.