5 Replies Latest reply on Aug 28, 2007 4:16 AM by tom.baeyens

    an alternative impl for nested node execution

    tom.baeyens

      the current implementation of nested node execution uses NestedExecutionScope. At runtime, in a blockstructured language like BPEL, this will result in a lot of NestedExecutionScope's being persisted. So I wondered if other engines would have the same problem. Of course not, they use the knowledge of the process to proceed.

      We can do exactly the same. 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.

        • 1. Re: an alternative impl for nested node execution
          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

             

            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

              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

                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

                  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.