5 Replies Latest reply on Oct 23, 2008 6:37 PM by Ronald van Kuijk

    Future of jBPM???

    Keith Nielsen Newbie

      I have been researching both jBPM and Drools for sometime now and am wondering what the future holds for jBPM. This is based on my research of Drools 5, which is bringing what I would consider more BPM constructs into the core engine, things such as Wait States, Human Tasks, etc. One of the main things I don't see yet is the whole persistence and support of long running processes. My question is will the trend with Drools continue, eventually consuming jBPM?

      I must say that my perception is that Drools is more active which makes me wonder if I should go with Drools hoping that it builds out more BPM features going forward.

      Also, will jBPM 3.5 or 4.0 move to Eclipse 3.4 from a tooling perspective?

      Thanks

        • 1. Re: Future of jBPM???
          Joram Barrez Master

          jBPM has wait states,human tasks, etc. for a very long long time now. In fact the concept of 'long running processes' is based upon this 'waiting'.

          I can assure you that the jBPM designers are constantly trying to build a better product. The last months were invested in reserch & design fo building jBPM, so that's why one would get the perception of idleness. But don't worry, we will al see signs of these investments in the coming months.

          • 2. Re: Future of jBPM???
            Koen Aers Master

             

            "keith" wrote:
            Also, will jBPM 3.5 or 4.0 move to Eclipse 3.4 from a tooling perspective?

            The latest release (3.1.4) of the GPD has been build and tested on Eclipse 3.4. Did you experience any problem with it?

            • 3. Re: Future of jBPM???
              Tom Baeyens Master

              jBPM is going full speed. We are addressing crucial productization issues under the hood. Like optimizing persistence, how do you bind the process persistence into your transaction (whatever Java environment you're running on), how to extract the communalities between different forms of BPM in a Process Virtual Machine library. That has taken some time and now this work will be available soon.

              I regret that the drools guys put so much effort in duplication. We have had a couple of meetings on this topic. But we couldn't come to a joint PVM strategy yet. Hopefully that will still happen.

              • 4. Re: Future of jBPM???
                Kris Verlaenen Master

                 

                I regret that the drools guys put so much effort in duplication. We have had a couple of meetings on this topic. But we couldn't come to a joint PVM strategy yet. Hopefully that will still happen.


                The Drools team has always been asking for collaboration with the jBPM team from the start. We presented specific recommendations on how to improve the design of a the current jBPM PVM model in several areas, more than a year ago. We also suggested broadening the scope to make it not process-centric but knowledge-centric, allowing unification and a tight integration (and still loosely-coupled as well of course) between rules and processes.

                What you call duplication (and we consider improvement !) was the only option to move forward at that point. The Drools team will continue to actively add new exciting features to the Drools Flow engine. We believe that at this point we already offer most of the features supported by the jBPM engine (and much more), using a superior design.

                But we hope the jBPM team would reconsider collaborating with us and we are still open for any type of discussion and collaboration, as it'll allow us to combine our strengths and resources in the most efficient way ...

                One of the main things I don't see [in Drools Flow] yet is the whole persistence and support of long running processes.


                Drools Flow does offer persistence of your runtime process state, by providing JPA-based persistence of process instances, adding support for long-living processes as well.

                Kris

                • 5. Re: Future of jBPM???
                  Ronald van Kuijk Master

                  Wow... I'm flabbergasted. Really, I am