-
1. Re: an alternative impl for nested node execution
tom.baeyens Aug 24, 2007 11:57 AM (in response to tom.baeyens)NestedExecutionScope has been removed. In the pvm tests, there is no need for subclassing the execution.
-
2. Re: an alternative impl for nested node execution
aguizar Aug 24, 2007 1:54 PM (in response to tom.baeyens)If the BpelExecution overwrites the proceed method, it can handle it's own way of propagating the execution. E.g. always go back to the parent (with a signal? special method?) when a node is executed. The completed node has to be provided to the parent in some way or another.
No need for a special method. We can use a "child completed" signal. The bpelExecution will still be pointing to the completed node. -
3. Re: an alternative impl for nested node execution
tom.baeyens Aug 25, 2007 3:45 AM (in response to tom.baeyens)indeed, this is the current implementation:
/** @see ExecutionController#proceed() */ public void proceed() { // in graph based process langauges we assume that a // default transition is available if (node.getDefaultTransition()!=null) { takeDefaultTransition(); // in block structured process languages we assume that // there is no default transition and that there is a // parent node of the current node } else { Node parentNode = node.getParent(); // if there is a parent node if (parentNode!=null) { moveTo(parentNode); // and signal it performAtomicOperation(new SignalNode(this, null)); } else { // When we don't know how to proceed, i don't know if it's best to // throw new JbpmException("don't know how to proceed"); // or to end the execution. Because of convenience for testing, // I opted to end the execution. end(); } } }
the default signal (null) is given to the parent as the 'child completed' signal
most of the difficult bpel nodes now have an example implementation in the pvm test suite. only the pick is not there. don't know if that is a difficult one to solve, but i think not. -
4. Re: an alternative impl for nested node execution
mvaldes Aug 28, 2007 3:34 AM (in response to tom.baeyens)Good job Tom !
The new implementation looks definitely nice. I notice that the new moveTo method is also used for both nested node execution and transitions wait states, cool !
We will make a try of this new version with both XPDL and BPEL current extentions to check whether there is any side effect...
regards,
Miguel Valdes -
5. Re: an alternative impl for nested node execution
tom.baeyens Aug 28, 2007 4:16 AM (in response to tom.baeyens)the moveTo is now only used to update the previous node and previous transition
we could/should consider to expose a move method. that way, we can first create a log trace and then call the moveTo method. this would allow external clients to just reposition the execution in some other node. but how to start execution then... how does the user specify wether the node should be executed or wether the execution should wait in the new node till a signal comes. that's what i still don't have a good overview on. so i didn't go into that direction now.