i agree with addition of a property called root to execution.
i didn't get
Even more, would be great to differentiate between root execution creation ChildExecutions in the PVM APIs
I was suggesting to add a new class called Instance and to change the current newExecution() method in Process API by newInstance(). Previous method will return an Instance rather than an Execution ?
Instance objects could have additional attributes to Execution and so it would be helpful to make the difference between Root and ChildExecutions:
i.e current BPEL and XPDL Executions are extending ExecutionImpl and adding new attributes. Those classes are used to represent both root and child executions when childExecution will probably do not need added attributes.
The point is to have a dedicated class to represent Root executions (Instance) different than ChildExecutions.
i'm not against adding an instance class if it inherits from execution. but... i didn't see any arguments yet why we should do that.
if a process language needs that change, the distinction between BpelInstance and BpelExecution can still be achieved with the current api. Just a matter of overriding the Proces.newInstance and execution.createExecution.
does it introduce any more problems then that ?
it would be nice to keep it simpler for the simple cases. then users wouldn't have to learn the distinction between instance and execution if they never use concurrent paths of execution.
This is not a technical issue but more a conceptual concern.
I'm concerning on how to have a maximum number of users happy with the PVM APIs... and so I think there is still a difference between Instance concept (from an end user point of view) than Execution (from a developers prespective), may be this differentiation is more on the languages extensions APIs than in the PVM side ?
I'm concerning on how to have a maximum number of users happy with the PVM APIs...
me too :-)
and so I think there is still a difference between Instance concept (from an end user point of view) than Execution (from a developers prespective)
there is a difference. i agree. though
i don't think this difference relates to user point of view vs developer point of view
the current execution still allows you to differentiate process executions (=instances) from paths of execution (=executions). you can just look up the root execution. every execution that doesn't have a parent is an instance.
as i understand good API design, simple things should be simple and it's not that big of a problem if advanced things are a bit more difficult to achieve with an API. if we introduce a differentiation between instance and execution, we violate the first part of that equation. cause then users or developers will have to learn that difference. even if they only work with workflows that have a single main path of execution.
that said. in summary, i only have a minimal argumtation why i don't want to introduce the instance yet. so i'm looking for the arguments in your point. what would be the reasons why an instance would need to be introduced ?
so far i only understood your 'with a separate instance class, the model better matches with the real situation'. to which my answer is: only if you have workflows with concurrent paths of execution.
may be this differentiation is more on the languages extensions APIs than in the PVM side ?
to find that out, we must have use cases for why we want to split execution and instance. then we'll know whether we do it best on the language side versus the pvm level.