5 Replies Latest reply on Jan 7, 2008 10:23 AM by mvaldes

    interfaces proposal

    Tom Baeyens Master

      here's an interfaces changing proposal that i have been chewing on for a while. below are the ideas as far as i can take them without starting to code. later this week i'll give it a try to see if/what issues arise while coding it.


      NodeBehaviour

      * method execute would be renamed to enter. this removes the confusion that comes from the almost similarity with the Action execute method. now, those two have the same name, but not the same signature.

      * method signal would be moved to its own interface in StateBehaviour

      StateBehaviour

      * signal. this interface would only have to be implemented by nodes that can behave as wait states.

      Propagator

      * gets a propagate method.

      This interface will allow to separate the logic from the node apart from the propagation. For example: an email node. after the email is sent, we currently require that a) there is exactly one outgoing transition or b) that the email node is contained in a composite node.

      A propagator would be optional on a node. So in case there is a propagator, it would implement the behaviour that is now hard coded in the proceed. These are the 4 basic propagator behaviours that i can see and which make sense after every node type with functional behavirour (aka non automatic activity)

      1) take the default transition
      2) take the first transition for which the condition evaluates to true
      3) take all the transitions for which the condition evaluates to true
      4) proceed to the parent

      This would allow analysts/developers to specify the behaviour separately from the propagation.

      Maybe a similar concept might also make sense in front the node. E.g. to synchronize incoming paths of execution before the node is entered. But at a first glance, that looks more fixed. So let's leave that thought for later and lets focus first on the Propagator and the separation of the signal into its own StateBehaviour interface.

      Action

      keeps the execute method as is.

        • 1. Re: interfaces proposal
          mvaldes Novice

          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
            Tom Baeyens Master

             

            "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
              mvaldes Novice

              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
                Tom Baeyens Master

                 

                "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
                  mvaldes Novice

                  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