1 2 Previous Next 17 Replies Latest reply on Feb 8, 2010 7:41 PM by nick.bauman Go to original post
      • 15. Re: Upgrade from JBPM3 to JBPM4 woes

        Ronald,

        What does make me wonder though is how you asses the risk of something different but existint (jbpm 3 vs 4) in relation to something none existing

         

        I might have not made this clear, but we're going to stay on JBPM3 for now. If we revisit upgrading we won't limit our options to JBPM4

        And migrating from jBPM3 to another BPM solution almost certainly as difficult as migrating to jBPM4

        Totally agree,

        So I am truly honestly, openly interested in the ++/+/0/-/-- lists/ Balanced scrore card/SWOT-analysis leading to this without wanting to lure you back :-)

         

        Okay, that's a fair request.

         

        What we were looking for moving to JBPM4:


        1.Better handling of subprocesses / superstates. Right now with JBPM3 we can only have subprocesses behave in a “fire and forget” fashion because any other type of subprocess assumes access to a persistent store, which we do not want. No wait state / prompt can occur in a subprocess. We were hoping this restriction would be lifted in JBPM4.


        2.Better Spring integration. JBPM3 has limited Spring integration.


        3.Keeping up with the rest of the JBPM world. Staying up to date on 3rd party systems means we get the benefits of increasing stability and openness to innovation over time.


        What we found:


        The Good

         

        1.The interfaces are based on a service facade and the process definitions are pieced together of Composites, making the FSM better modeled. In theory it also means that handling sub processes might be simpler.

         

        2.A process definition conversion tool exists. It's considered experimental bu it's purported to convert JBPM3 to JBPM4 process definition XML files.

         

        3.Actions can be scripted with dynamic languages instead of Java.

         

        4.Many different idioms for the FSM have been added, such as Swimlanes and Tasks.

         

        The Bad


        1.No binary compatibility exists between JBPM3 and 4. Not even the process definitions are compatible because JBPM4 is a complete rewrite.

         

        2.The process definition conversion tool doesn't work. When running the conversion tool over one of our process definition it appears to assume that if any GraphElement exists that does not have an action element, it's invalid when clearly this is a perfectly valid GraphElement.

         

        It throws an exception: invalid process xml: Could not convert a node without action element. It also assumes that any action handlers or exception handlers are on your classpath before it converts them.

         

        3.Significant additions to our current target platform would be required. These additions imply a potential ripple effect on other subsystems and integration with our SCADA control system.

         

        4.Spring integration seems still a back art. It may even require Hibernate integration: something we need to avoid. We have not been able to find good examples of how the Spring integration works in v4.


        5.The design of JBPM4 is oriented toward a service facade which makes it less clear how we control process definitions. JBPM3 is a simple Finite State Machine with some decent GUI designers.


        • 16. Re: Upgrade from JBPM3 to JBPM4 woes
          kukeltje

          Hey, thanks, really, really appreciate this kind of feedback. Let me comment on your remarks.

           

          1 and 2

          The binary compatibility was deemed impossible almost from the beginning. All this is related to the introduction of the PVM. There were a lot of brainstorm sessions to see if it would be possible. The amount of time that had to be put into achieving this would unfortunately be way to high.  For later versions (5, 6 etc), backwardscompatibility is achieved by the way the process is stored. So the choice was made not to go down this road but at least put some effort in process conversion. Here to the 80-20 rule was applied and everyone was aware that manual effort had to be put in to this. There are still changes added to the conversion tool, so if you guys have done some things which improve it (even if you are not going to use jBPM 4) we'd appreciate the feedback (~contribution )

           

          3

          Well, yes, happens every now and then to us to. But the only way to prevent this is to code *everything* in plain java and/or only use libraries that do not depend on *anything* else but a plain jre.  :-)

           

          4

          Spring support was initially contributed by 'external people' (but close to the project) and extended by people within the project. Regarding the integration itself, noone thinks it is complete. Things need to be done, but then again, as can be seen in some posts, there are users that are aware of this, but rather 'invent' workarounds instead of helping out. I know this is often a difficult choice in projects, but it is one of my biggest frustrations, believe me.... btw, have you seen http://www.inze.be/andries/2009/06/28/documentation-spring-jbpm-integration/ I'm no spring adept (do not opose it either, just never seemed to have the need for it, jumping on the seam bandwagon)

           

          5

          Doesn't 5 contradict the 1 in the 'good' department to a large extend? jBPM is still very flexible and extensible. Some people have a hard time switching. They were probably the ones that were very into jBPM 3. I know I had this problem myself. The services in jBPM 4 use commands 'internally' but adding commands yourself is not that difficult. Within commands you have full access to the database model so you can still do anything you want. The GPD for 4 is not as advanced as the one for 3, I think I agree with that. There are not a lot of other designers afaik, so that makes me wonder why you use 'GUI Designers' (plural). A nice webbased BPMN2 designer is currently under development at Signavio and if e.g. eclipse comes with a BPMN2 editor as well, I'm sure that will be leveraged. So A great future ahead if I may say so, brighter then the 3 universe...

           

          Think I should make this into a specific document (this forum allows promoting threads to documents... nice) since it touches on core things.

           

          Whatever choice you guys and gilrs eventually make, thanks for the constructive feedback.

           

          Cheers,

           

          Ronald

          • 17. Re: Upgrade from JBPM3 to JBPM4 woes

            Ronald,

             

            This is great information. I really appreciate your taking the time to go into this point by point. A true mark of craftsmaship and a passion for understanding other people's system problems.

             

            When we do finally migrate, I will certainly be starting with the process conversion tool and i'll contribute it back.

             

            I'm fully aware of Andries Inzé's information on Spring integration with v4. I think I have a copy of it etched into my brain by now. What's left of it

             

            Yes, 5 and 1 does contradict! Sometimes the greatest strength is the greatest weakness at the same time. I'm not trying to be obtuse or mystical by saying that, either. I'm sincere: great tools embrace a philosophy or world-view. If you're not ready to "change your mind", maybe you shouldn't be using the tool!

             

            If you have any more questions or want to assign any "homework", I'll try and see what I can do.

             

            Cheers,

             

            Nick

            1 2 Previous Next