1 2 Previous Next 15 Replies Latest reply on Feb 8, 2008 12:30 PM by kukeltje

    switching default from wait to proceed

    tom.baeyens

      In NodeBehaviours, currently the default is wait. Meaning that if you don't call proceed, the execution will wait.

      I remember that I had a few occasions where I saw that the default could be changed to proceed. In that case, the execution would proceed after the execute or signal was invoked unless a new wait() method was called. Up to now, i didn't find enough motivation to actually make the switch.

      The only motivation so far was the overloaded execute method on Actions and NodeBehaviours. I previously opted for renaming the Action method to run to prevent a name clash there.

      Now I think I might have found a real motivation: Exception handlers.

      When an exception handler handles an exception, the execution is supposed to proceed after the delegation method that was invoked. Suppose now that we have an automatic activity like sending an email. The call to execution.proceed() will be at the end after the email sending code. Now suppose that sending the email throws an exception that is handled by an exception handler. Then the problem is that the execution.proceed of the automatic activity is not executed. So after the handling the exception, the execution will enter a wait state.

      Come to think of it, changing the default only partially resolves the problem. If we change the default to proceed, we might have an analogue situation with wait states, where an exception might skip the invocation of execution.wait.

      The solution is that NodeBehaviour implementors will have to put try-finally blocks around code that potentially throws an exception. In the finally block, they can call execution.wait().

      In conclusion, switching the default from waiting to proceeding will have 2 main benefits:

      1) The action.run method can be renamed to execute again. Automatic activities can just implement both Action and NodeBehaviour and only implement the execute method.

      2) The extra difficulty of coding a try-finally will only be for node behaviours that are wait states. I think those are the ones that users will typically not write themselves. If we keep waiting as the default like it is now, we will put that burdon on the automatic activity implementors.

      I'll let it sink in some more.

      All thoughts are appreciated.

        • 1. Re: switching default from wait to proceed
          kukeltje

          weren't these almost the same reasons to change the default behaviour from wait in jBPM jpdl 3.1 to proceed in 3.2 (or was it 3.0 and 3.1?)

          At least to me they sound valid and well thought trough.

          • 2. Re: switching default from wait to proceed
            aguizar

            (1) is sound and makes developing code that runs as either action or node behavior straightforward.

            For (2), the problem is that almost any code that does interesting things is subject to exceptions. Any robust wait state implementation will have to put the try/finally block in place. In fact, the same is true for the current default.

            If the call to wait() was only an indication about what to do next, then node behaviors could invoke it at the very beginning and avoid the try/finally block. If I understand the AtomicOperation mechanism correctly, this is already the case. Or would wait() work differently?

            • 3. Re: switching default from wait to proceed

              Tom,

              I see your point but I don't think that changing the default is justified anyway.

              Users will not code automatic activities behaviours but actions. Actions does not allow to change the state of execution (i.e execution.proceed is not allowed from actions) and so try/catch blocks will not be mandatory in this use case (so users will not be impacted).

              For NodeBehaviours (the one to be implemented by extensions developers) I agree with Alejandro that adding try/catch blocks is not really a constraint for a developer.

              I like the default behaviour of the PVM in which wait state is the default :-)

              regards,
              Miguel Valdes

              • 4. Re: switching default from wait to proceed
                tom.baeyens

                 

                "alex.guizar@jboss.com" wrote:
                For (2), the problem is that almost any code that does interesting things is subject to exceptions. Any robust wait state implementation will have to put the try/finally block in place. In fact, the same is true for the current default.

                If the call to wait() was only an indication about what to do next, then node behaviors could invoke it at the very beginning and avoid the try/finally block. If I understand the AtomicOperation mechanism correctly, this is already the case. Or would wait() work differently?


                exactly. i thought of an invocation at the beginning as well. but that would be *so* counter intuitive. it completely depends on the way we translate propagation of the execution into a loop of atomic operations. at this point, users don't have to know the atomic operations and i would like to keep it that way.

                the two alternatives are very analogue. the non-default propagation of execution will have to be in a finally block.

                a) if wait is the default (as it is now) then a proceed (or any other propagation of execution) will have to be put in a finally block

                b) if proceed is the default, then invocations of wait will have to be put in a finally block

                my reasoning for proposing this change was the following: if we take option b, then we serve better the automatic actions. i believe that our users will want to integrate more automatic pieces of code into the process versus wait states. and option b makes it easier to code the automatic activities, since they don't require a finally block.


                • 5. Re: switching default from wait to proceed
                  tom.baeyens

                   

                  "mvaldes" wrote:
                  Users will not code automatic activities behaviours but actions. Actions does not allow to change the state of execution (i.e execution.proceed is not allowed from actions) and so try/catch blocks will not be mandatory in this use case (so users will not be impacted).


                  not sure if i got your point. i'll rephrase my point then you can do the same. we should be able to find each other after a while :-)

                  my expectation is that for most actions, it will make sense to use them as node behaviours as well.

                  e.g. if you have things like sending an email, generating an image/pdf, updating a db with SQL, ... all those automatic activities both make sense as node behaviour and as action.

                  by changing the default from wait to proceed, it is implied that all actions can be executed as-is as node behaviours.

                  (NodeBehaviour could even extend the Action interface)

                  "mvaldes" wrote:
                  For NodeBehaviours (the one to be implemented by extensions developers) I agree with Alejandro that adding try/catch blocks is not really a constraint for a developer.


                  i agree with that too. a try-finally for complex use cases is not too much of an overhead. but both of the options have only 1 default. the other options of propagating the execution will have to be put in a finally block. so imo, it is a matter of finding the right default. the default that matches the most and simplest cases. automatic activities (actions that can be executed as nodebehaviours without wait state) are the most in number and simplest.

                  does that make sense ? do you still see things different ?

                  • 6. Re: switching default from wait to proceed

                     

                    "tom.baeyens@jboss.com" wrote:

                    my expectation is that for most actions, it will make sense to use them as node behaviours as well.


                    Again, I think actions and Node Behaviours are not intended for the same audience.
                    NodeBehaviours are for language extension developers (and so part of the default set of nodes proposed by a language) and actions for users of those extensions (adding logic to a particular business process).

                    Concentually are different so I don't think that is useful to share code between (even if you can).

                    So I would not consider this point as an item to chose what is the default in the PVM (wait or proceed)

                    That said I will not see any benefit on changing the default.

                    Another option would be to do not have default at all. This will require to either specify wait or proceed otherwise to raise an error.

                    Just to conclude, I think having wait as default is good to illustrate how the PVM is useful when working with Java (everybody knows that working with waitstates is hard with plain Java) !

                    regards,
                    Miguel Valdes

                    • 7. Re: switching default from wait to proceed
                      kukeltje

                       

                      Again, I think actions and Node Behaviours are not intended for the same audience.
                      They are, but imo the mail node is already in the grey area. One could use a node with automatic transition and an action on the node enter or so... same as for the esb node (why not an ftp node, ws node, put-file-in-directoy node) etc...

                      Concentually are different so I don't think that is useful to share code between (even if you can).
                      to some extend you can if you look at the examples above

                      Another option would be to do not have default at all. This will require to either specify wait or proceed otherwise to raise an error


                      Interesting... difficult to check however at runtime... although it would show up design/test time

                      And I totally agree with the last statement. Although some people think they can develop their own fullblown homegrown wfs within 2 weeks

                      • 8. Re: switching default from wait to proceed
                        kukeltje

                         

                        They are,


                        Of course I meant "they are not"

                        • 9. Re: switching default from wait to proceed
                          aguizar

                          I agree with Ronald. In fact one good motive for the change is the upcoming fiesta of automatic actions for integration, including ws-invoke, esb-invoke, jms-send. Sometimes you want them to show up in the process diagram, if you are using the PVM as a process manager in the EAI sense. You do NOT want them to show up if you are using the PVM for workflow.

                          However, whether they show up or not, they do the same work. By making proceed the default, we can use the above actions indistinctly as node behaviors. And, more importantly, so can users.

                          I do agree that having wait as the default is more intuitive. In any situation when you want to wait and see, you just sit off and do nothing. So it is a tradeoff.

                          • 10. Re: switching default from wait to proceed
                            kukeltje

                             

                            "fiesta of automatic actions for integration"


                            Should be a title of a blog entry...

                            • 11. Re: switching default from wait to proceed

                               

                              "kukeltje" wrote:
                              They are, but imo the mail node is already in the grey area. One could use a node with automatic transition and an action on the node enter or so... same as for the esb node (why not an ftp node, ws node, put-file-in-directoy node) etc...


                              It depends on the use case. I'm mostly concern on providing the right extensions to the end users (XPDL, BPEL...). That is to be compliant to the standard and to provide a facade/commands mechanism to end users allowing them to leverage the workflow/bpm product.

                              From this perspective, actions will allow end users, to add logic that was not provided as a node implementation. Those users will only know about actions interface not NodeBehaviours.

                              For other use cases, i.e an extensible framework in which new nodes implementations can be added to the initial set of nodes provided out of the box, make sense to share actions and NodeBehaviours as Alejandro pointed out.


                              "fiesta of automatic actions for integration"


                              Nice, this is the latino's style :-)

                              regards,
                              Miguel Valdes

                              • 12. Re: switching default from wait to proceed
                                tom.baeyens

                                So I think we were all in conclusion that changing the default from wait to proceed is a good idea.

                                Here's the change that I did:

                                I renamed the Action run method to execute.
                                I renamed Action to Activity.
                                I renamed NodeBehaviour to ExternalActivity.
                                I removed the execute method from ExternalActivity since it is inherited from Activity.
                                I removed the proceed() method from the Execution interface (not from the ExecutionImpl implementation)
                                I added method waitForSignal() to the Execution. (wait was already taken by the stupid, stupid, stupid, STUPID, ***STUPID*** guy that decided to put threadsynchronization methods on the Object)
                                The default changed from waiting to proceeding.

                                Activities now have 1 execute method. They can be placed in events and they can be used as node behaviour. Property Node.behaviour is an Activity. In case an activity is placed as node behaviour

                                ExternalActivities are activities for which the propagation of the control flow is outside the process execution. E.g. human task, wait state,... In that case, you need to implement ExternalActivity, which adds the signal methods to the Activity.

                                After doing the change, I already had to update some implementations in the test suite and it really gave a much better feeling to the API. At least, that was my first impression.

                                The full test suite works. But now I'll be updating the javadocs and docbook docs for quite a while. Not sure I'll get that done today. Next week is JBossWorld, so this might take a week before the javadocs and docbook docs are all up to date.

                                • 13. Re: switching default from wait to proceed

                                   

                                  "tom.baeyens@jboss.com" wrote:
                                  So I think we were all in conclusion that changing the default from wait to proceed is a good idea.


                                  Not really, I thought my position was clear. I don't think that allowing to use actions and node behaviours indistinctly is a good enought reason to change the default.

                                  Moreover, this change will have a big impact in both BPEL and XPDL current implementations so I will definitely not apply those changes in the meantime.

                                  In conclusion, I'm not happy with this move.

                                  regards,
                                  Miguel Valdes

                                  • 14. Re: switching default from wait to proceed
                                    tom.baeyens

                                    from

                                    Just to conclude, I think having wait as default is good to illustrate how the PVM is useful when working with Java (everybody knows that working with waitstates is hard with plain Java) !


                                    i thought you were in agreement.

                                    the only thing i got where you didn't agree that there was value in using actions as-is for node implementations. but i didn't see that you considered it bad.

                                    it took me less then 3 hours to do the refactoring + refactor the whole test suite, which includes the bpel sequence and bpel flow (with links). with the tips below, i think the updates will be quite ok.

                                    apart from that, the more i'm working with it, the more i realize that this was a very good update. the previous default (wait state) was inspired on the implementation. whereas the current default (proceed) is inspired from the Activity-implementor's point of view. It makes explaining about activities and external activities so much easier.

                                    also, if you implement an automatic activity, you actually don't need to implement the getSignals and signal method, which you were forced to in the previous approach.

                                    and last (the cause), it fits the exception handlers better. now, when you have an automatic activity that throws and exception that is handled by an exception handler, the proceed will be the default so the process continues. This means that you can code automatic activities without having to put a try-finally block inside.

                                    To minimize the work you have to do on your codebase, here's how i think you can speed it up:

                                    1) export a version of the pvm of yesterday into your eclipse
                                    2) link the bpel and xpdl projects to that eclipse project
                                    3) apply the refactorings:

                                    * Start with this one: remove the proceed() method from the Execution interface (not from the ExecutionImpl implementation) . Compilation errors will give you an indication where you have to update the changed default.
                                    * renamed the Action run method to execute.
                                    * renamed Action to Activity.
                                    * renamed NodeBehaviour to ExternalActivity.
                                    * removed the execute method from ExternalActivity since it is inherited from Activity.
                                    * add method waitForSignal() to the Execution.

                                    4) remove the exported pvm project and use the pvm project from trunk
                                    5) finish the rest by hand

                                    1 2 Previous Next