8 Replies Latest reply on Aug 13, 2007 11:08 AM by mvaldes

    i'm refactoring child node execution a bit

    tom.baeyens

      hang tight...


      in the mean time, it would be good if you could come up with different use cases for concurrency

      Use case 1: Executing a nested node in the same path of execution. E.g. sequence and many other activities in BPEL. Potentially, a variant of this could be that another node is executed in the process that is not a nested node of the current node. E.g. if the process would have a global exception handler node defined or something like that.

      For this, i think we need something like completion operations. For node, you can specify what needs to be done when that node just completes without specifying a next atomic operation.

      Alternatively, a nested node stack could be included in the execution.

      In both cases, when a child node completes, a signal should be sent to the parent (or original) node with the same execution

      Use case 2: Executing a concurrent nested. like in BPEL Flow

      In this case, a new execution needs to be created and a child node must be executed. When the child node finished, the parent node must be notified with a signal.

      This can also be done with a completion operation. Although i'm not sure if in the BPEL case the concurrent nodes will all complete. What if one of the concurrent paths of executions is cancelled or has an failure ?

      Somehow the parent node must be signalled, the child execution must be ended.

      Instead of using completion operations, we could also use the following approach:

      When a node completes, there are no completion operations and there is no default transition over which the execution can be propagated, the execution could end itself.

      When an execution ends that has a parent, it will notify that parent by e.g. calling a executionEnded method. The execution can then provide a signal 'executionEnded' to the current node.

      Those are my current thoughts... i'll chew on them some more.

        • 1. Re: i'm refactoring child node execution a bit
          tom.baeyens

          On which pvm classes are you guys working ?

          This might become a significant refactoring in the ExecutionImpl class. So merging might become difficult.

          Also i'm considering to move the atomic operation implementation classes to top level classes and moving all the process langauge implementation API's to org.jbpm.pvm.impl

          • 2. Re: i'm refactoring child node execution a bit

             

            On which pvm classes are you guys working ?


            Currently only on the get/create/remove child executions methods + related unit tests but I guess that would be easy to merge


            in the mean time, it would be good if you could come up with different use cases for concurrency


            Basically we were thinking on the following ones:

            1.- Transitions based execution with child executions (simple splits and joins). We have already set up some test on that on the unit test called ChildExecutions.java

            2.- Nested nodes executions with concurrent executions (i.e simple FLOW)

            3.- Transitions based executions mixed with nested nodes (both simple and concurrency use cases). This use case was described here http://jboss.com/index.html?module=bb&op=viewtopic&t=115092

            4.- Nested nodes executions with transitions inside. This is a tricky one, I don't know yet if useful (also described in the previous link)

            5.- Nested node in the same path of execution + variant of this in which there is another node to the process to be executed (the one you proposed)

            In all those use cases we should definetly take a decision on whether completion operations are useful and so should be leveraged or whether to use the executionEnded (or a kind of propagateToParent method as used in the lightning version) or even what about using the last one in both cases ?

            regards,
            Miguel Valdes

            • 3. Re: i'm refactoring child node execution a bit
              tom.baeyens

              just committed the nested node execution refactoring.

              i removed the completion operations and leveraged the list of ExecutionScope's for that.

              SequenceTest and ConcurrentChildTest are working

              i still have a few problems to chew on.

              i had to remove the locking (the problem that charles had in the first place). in theory this should work. so i'll further investigate that.

              also operations on different executions don't run in the same while loop of atomic operations. not sure if that is necessary. if we could do it, it would be better, but i don't see an easy way to do it. also, only in the Flow implementation of the ConcurrentChildExecution that would matter and that implementation shouldn't have side effects.

              I'm happy with most of how the Flow implementation looks. Only the return values in the signal might be a bit unclear.

              • 4. Re: i'm refactoring child node execution a bit
                tom.baeyens

                 

                "mvaldes" wrote:

                1.- Transitions based execution with child executions (simple splits and joins). We have already set up some test on that on the unit test called ChildExecutions.java

                2.- Nested nodes executions with concurrent executions (i.e simple FLOW)

                3.- Transitions based executions mixed with nested nodes (both simple and concurrency use cases). This use case was described here http://jboss.com/index.html?module=bb&op=viewtopic&t=115092

                4.- Nested nodes executions with transitions inside. This is a tricky one, I don't know yet if useful (also described in the previous link)

                5.- Nested node in the same path of execution + variant of this in which there is another node to the process to be executed (the one you proposed)


                3 and 4 are not necessary i think.

                probably it's the easiest if i just complete the initial test suite. then once the basics are running, we can further expand the test suite together.

                we can work together on the list of basic tests that should be produced. here's my proposal for prioritization.

                1) AutomaticActivityTest: 3 automatic nodes connected with transitions.

                2) WaitStateTest: 3 wait state nodes connected with transitions.

                3) SequenceTest:
                * 3 automatic nodes nested in a sequence node.
                * 3 wait state nodes nested in a sequence node.

                4) Action test:
                * node enter action
                * node leave action
                * transition action

                5) Decision test
                * automatic decision
                * external decision during a wait state (signal corresponds to the transition that needs to be taken)

                6) Concurrency
                * nested node concurrency (3 concurrent nodes in one Flow)
                - 3 concurrent automatic nodes in 1 flow
                - 3 concurrent wait states in 1 flow
                * transition based concurrency based on incoming transitions (bonita)
                - 3 concurrent automatic nodes between a fork and a join
                - 3 concurrent wait states between a fork and a join
                * transition based concurrency based on execution sibblings (jpdl)
                - 3 concurrent automatic nodes between a fork and a join
                - 3 concurrent wait states between a fork and a join

                concurrency variations:
                - concurrency in a loop
                - nested concurrency

                1-4 are done. 5 is TODO but trivial. 6 is still to do.

                what do you think of the prioritization in 6 ? am i missing a lot of basic scenarios ?

                • 5. Re: i'm refactoring child node execution a bit

                  I agree those are the basics ones for the three initial targeted languages: XPDL, BPEL and JPDL

                  Some of the unit tests in 6 can also be adapted from the existing ones which leverages two nodes rather than three.

                  I still thinking that would be great to be able to mix nested and transitions based executions but I think we could postpone those ones.

                  Charles, something you want add there as a first unit tests series ?

                  regards,
                  Miguel Valdes

                  • 6. Re: i'm refactoring child node execution a bit
                    csouillard

                    Maybe we can add the following

                    1 flow with 3 children (c1, c2, c3)
                    c1 is a sequence having 2 children : 1 automatic and 1 waitState
                    c2 is a flow having 2 children : 1 automatic and 1 waitState
                    c3 is sequence having 1 child (c4)
                    c4 is a flow having 2 children : 1 automatic and 1 waitState

                    With this test we have most of the cases of concurrency.
                    Thoughts ?

                    Charles

                    • 7. Re: i'm refactoring child node execution a bit
                      tom.baeyens

                      after the initial basic testing, i would like to see a whole series of those kinds of combination tests.

                      preferrably with some sort of strategy on which combinations we'll test. the strategy on which combinations we'll make should partly be based on the knowledge of the implementation. as we can expect the weak points of our implementation. but partly, the combinations should be systematic.

                      we'll need good judgement in this.

                      • 8. Re: i'm refactoring child node execution a bit

                         

                        "tom.baeyens@jboss.com" wrote:


                        1) AutomaticActivityTest: 3 automatic nodes connected with transitions.

                        2) WaitStateTest: 3 wait state nodes connected with transitions.

                        3) SequenceTest:
                        * 3 automatic nodes nested in a sequence node.
                        * 3 wait state nodes nested in a sequence node.

                        4) Action test:
                        * node enter action
                        * node leave action
                        * transition action

                        5) Decision test
                        * automatic decision
                        * external decision during a wait state (signal corresponds to the transition that needs to be taken)

                        6) Concurrency
                        * nested node concurrency (3 concurrent nodes in one Flow)
                        - 3 concurrent automatic nodes in 1 flow
                        - 3 concurrent wait states in 1 flow
                        * transition based concurrency based on incoming transitions (bonita)
                        - 3 concurrent automatic nodes between a fork and a join
                        - 3 concurrent wait states between a fork and a join
                        * transition based concurrency based on execution sibblings (jpdl)
                        - 3 concurrent automatic nodes between a fork and a join
                        - 3 concurrent wait states between a fork and a join

                        concurrency variations:
                        - concurrency in a loop
                        - nested concurrency

                        1-4 are done. 5 is TODO but trivial. 6 is still to do.

                        what do you think of the prioritization in 6 ? am i missing a lot of basic scenarios ?


                        Looking into this TODO list I noticed that most of those use cases are done, isn't it ?

                        If you are done with that, we would like to propose you to work (on our side) on the following ones:

                        - Nested concurrency (i.e nested flows)
                        - Adding/removing child executions (including updates in ExecutionImpl.java)
                        - Unstructured split-join behaviours based on incoming transitions
                        - Transition based with nested node concurrency (again I think that could be useful)
                        - Two phase execution for waitstates (the Bonita like's manual activities execution: start vs terminate operations)
                        - Anticipating execution

                        ...

                        Thoughts ?

                        regards,
                        Miguel Valdes