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 ;-)
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?
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
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.