bonita-style concurrency

[tom.baeyens]

- I'm currently working on a more complex sample in which I would like to implement part of the Bonita's behaviour when having parallel path of execution. For that I guess there is a need to go further on the Execution implementation in order to support multiple executions paths. What is your feeling on that ? In the todo.txt file you mention that it would be better to handle an execution stack rather than nested executions....

Miguel

[tom.baeyens]

i was working on this type of concurrency. but got interrupted for two weeks.

i'm about to release 3.1.4 and then i'm fully focussed on the pvm again. continuing this will be my first goal.

the idea i had to implement it was as follows:

change the executions in Execution from a Map to a List. a corresponding transient Map can be generated lazily from the List. the advantage of this is that you don't need to come up with names for all your paths of execution.

a distinction would be made between 2 situations:

1) one single path of execution. As long as there is one single path of execution, there is 1 execution object pointing to the current node.

2) multiple concurrent paths of execution. Multiple concurrent paths of execution are all represented as children of the root execution. So only 1 level deep. In that case, the root execution itself does not point to a specific node anymore, but just serves as a container for concurrent executions.

so a fork first looks up the root execution. in case there was no concurrency yet, it is the execution that arrived in the fork node. otherwise, it's the parent of the execution that arrives in the fork. once the root is obtained, a new child execution is created for each leaving transition.

when an execution arrives at a join, we must make sure that the last taken transition is stored in the transition member field of the execution. then the join can check if the complete list of concurrent executions and filter out the ones that are positioned in that join. then the join can check if there is an execution for every arriving transition. if that is the case, then the join triggers.

[mvaldes]

I understand, I was also really busy working on the Bonita v3 so time now to switch over the PVM :-)

I remember our last discussion about the way in which this kind of execution can be implemented.
Please let me know about how this work is going on, I'm really excited about plugin this new Execution implementation in the Approval Workflow sample I started.

In the meantime I will focus on the variables definition and propagation issues between the model (process) and instances (execution)

regards,
Miguel Valdes

[tom.baeyens]

next week i'm probably able to dive into the execution code. in the meantime i'm always available for questions.

[mvaldes]

Tom, others,

From the last meeting insights about the PVM execution model, I decided to work on a simple unit test which leverages both Split and Join behaviours used in Bonita.
I have just commited this file (BonitaConcurrencyTest.java)

To do so, I added a new boolean attribute into the Transition.java file that will record whether or not a particular transition was executed (this is the way I managed to implement the Join behaviour).

In this sample I created multiple path of execution from the root execution in order to implement a Split node. Those paths of execution are removed afterwards when the Join node is executed.

Please let me know what you think about...

regards,
Miguel

Tempranillo Style

[tom.baeyens]

The problem with your approach is that there is just 1 transition object for all the executions.

So your isDone boolean should be modelled as part of the execution datastructure, not the process definition datastructure.

One way to do it is leverage the transition member variable in the execution.

When an execution arrives in a tempran... euh... i mean, bonita style and-join node, the transition member field of that execution should be set to the transition it took to arrive in the and-join node.

If i have some time later on, i'll try to refactor it. But that won't be this week.

[mvaldes]

You are right Tom, I was indeed mixing both PVM basics and the current Bonita execution mechanism...

I will try to change that this week.

BTW, We will probably also start working on the XPDL basic support, meaning basic XPDL parsing, creation of basic nodes...

Regards,

Miguel Valdes

[mvaldes]

I have just updated and commited changes related to the Bonita concurrency execution.

Those changes includes the replacement of the isDone attribute (in Transition class) by the lastTakenTransition member in the Execution one.
This is the only way I found to evaluate already taken transitions when a And-join node is executed.

Two basic test cases are included in the BonitaConcurrency class: a simple And_Split - And_Join execution and a nested And_Split - And_Join.

Related to that, I added/updated some other methods to the Execution class (removeExecutions, createExecution...)

I have also added the addEvent and createEvent methods to ProcessElement class. Those method will be inherited by PVM classes involved in actions/event execution (Node, transition, process...).

I'm currently adding the Split and Join behaviours to the first XPDL parsing developed by Marc. I guess I will have something working early this week.

Regards,
Miguel Valdes