-
1. Re: interfaces proposal
Tom,
If I well remember there are some BPEL statements implementations in which automatic activities (so the ones that you proposed to do not implement the signal interface) must be signaled from another excutions (probably things related to links in Flows ?)
Is the intent of "propagators" to handle this kind of behaviours ?
I'm, for sure, concerned also on the impact of those changes into both XPDL and BPEL extensions (I think could have a big impact !). Is this indeed offering us a more powerful mechanism or is just refactoring ?... seems more as the second one for me...
regards,
Miguel Valdes
BTW, Charles, Guillaume please correct me if i'm wrong with the previous example... -
2. Re: interfaces proposal
"mvaldes" wrote:
If I well remember there are some BPEL statements implementations in which automatic activities (so the ones that you proposed to do not implement the signal interface) must be signaled from another excutions (probably things related to links in Flows ?)
Is the intent of "propagators" to handle this kind of behaviours ?
no that is different. this has nothing to do with the threading model for bpel. or did you refer to something else ?"mvaldes" wrote:
I'm, for sure, concerned also on the impact of those changes into both XPDL and BPEL extensions (I think could have a big impact !). Is this indeed offering us a more powerful mechanism or is just refactoring ?... seems more as the second one for me...
i think the impact is limited. it's one method renaming (nodebehaviour's execute method would be renamed to enter) and one interface split (nodebehaviour would be split into nodebehaviour and state behaviour).
the responsibility and usage of these methods would not change.
the propagator would be an addition that would not affect any of the existing code.
it's not just a refactoring. it would add the principle as explained in the XPDL V2 spec on figure 7-1 on page 52. the propagation of the node would be decoupled from the activity body. -
3. Re: interfaces proposal
Ok I got it. For the NodeBehaviour changes I still thinking that is more a refactor (method name change + interfaces split) but anyway could be indeed easy to change...
On the propagators side now I see the benefit (mainly in terms of code cleaning in Node implementations + model improvement -> separation between implementation and propagation).
However I think some code (node implementations) could be impacted. For instance, in our current XPDL Fork node implementations we are creating child executions and then calling directly "take" method with the next transition to take.
Is the idea now to either keep this code as it is or either use one of the default propagators if match with our propagation behaviour or either to define and set a new propagator ?
regards,
Miguel Valdes -
4. Re: interfaces proposal
"mvaldes" wrote:
However I think some code (node implementations) could be impacted. For instance, in our current XPDL Fork node implementations we are creating child executions and then calling directly "take" method with the next transition to take.
Is the idea now to either keep this code as it is or either use one of the default propagators if match with our propagation behaviour or either to define and set a new propagator ?
those should be kept as is.
a propagator would serve 2 purposes
1) for non-control-flow with only functional behaviour, it would be a way on decoupling the functional body of the activity from the propagation. so that e.g. you could combine sending an email with a decision in one node. this is what analysts could draw when you tell them "first you need to send an email and then depending on this condition you should one of 3 different things..."
2) better support for propagation in the process languages. now we have the proceed that will take a transition if there is one and try to propagate to the parent node if there is one.
With a propagator, the languages could install the exact behaviour that is required into the node. The proceed would then check for the propagator if there is one. In BPEL for example, during parsing we could install a propagator on the nodes that only propagates to the parent node after completion. That would avoid the unnecessary check for an outgoing transition as it is done now in the proceed method. -
5. Re: interfaces proposal
Hi Tom,
Looking again to the propagator concept with Marc we just realized that it could be really useful when having XPDL definitions in which the same activity is defined as having multiple behaviours: i.e an activity defined as Join XOR, manual and Split.
This definition is sometimes an alternative to three different activities Join XOR connected to a manual one which is connected to a split.
Since today, in the Bonita XPDL extension both definitions are mapped to the second option as PVM nodes which results on three node implementations.
I think would be useful (as defined in the XPDL specification) to map the first definition as only one activity which body is "manual" and having Split as a propagator...
Just a thought...
regards;
Miguel Valdes