12 Replies Latest reply on Mar 9, 2012 7:25 AM by swiderski.maciej

    jBPM 5.x and OSGI integration/porting

    mduk

      All,

        Anyone has had luck with OSGI'fying drools/jbpm. Any pointers will be appreciated.

        • 1. Re: jBPM 5.x and OSGI integration/porting
          salaboy21

          as far as I know drools-core, drools-compiler, knowledge-api, and some projects inside jbpm and droolsjbpm-integration are already OSGI bundles.

          Cheers

          1 of 1 people found this helpful
          • 2. Re: jBPM 5.x and OSGI integration/porting
            mduk

            Thanks Mauricio - I'm trying to get human-task to work. This requires OSGI'fied seam etc. I'm OSGI'fying one dependency at a time at this point. I thought I should ask just in case someone has already walked the same path. I actually wonder if jBPM5.x maybe works in JBossOSGI?

            • 3. Re: jBPM 5.x and OSGI integration/porting
              swiderski.maciej

              Currently I (together with a friend) am working on jBPM and Drools platform that is based on JBoss AS 7 which means JBoss Modules and JBoss OSGi. Currently we are at concept study phase that is almost over and implementation has started. We plan to have PoC version of it in around one month.

               

              If you are interested I can provide you with an abstract introduction to the project and of course we always welcome contributors - project is open source

               

              Cheers

              1 of 1 people found this helpful
              • 4. Re: jBPM 5.x and OSGI integration/porting
                salaboy21

                I'm also interested in that project , if you can send the details we can help!

                • 5. Re: jBPM 5.x and OSGI integration/porting
                  mduk

                  Maciej,

                     I'd love to help with the effort. Please forward me the introduction so that I can figure out how I can best contribute. We have been porting Drools/jBPM around Eclipse RT/Spring DM 3.x. It makes sense to also attempt porting towards JBoss AS 7.

                   

                  Regards,

                  -Mdu

                  • 6. Re: jBPM 5.x and OSGI integration/porting
                    swiderski.maciej

                    Mauricio, Mdu, great to see that you are interested. Let me start with short introduction to the project we currently work on. Idea behind is to deliver out of the box flexible platform like architecture for jBPM and Drools as an alternative the the default deployment approach. At the moment here are the main high level requirements for the project:

                    • ability to version you logic executed by engine (it is all the java code that your processes, rules and events rely on)
                    • ability to version your processes, recommended is to utilize repository as default but they can be packaged together with logic and versioned with the same principles
                    • ability to version runtime environment, meaning that you can execute on the same server processes, rules, events that utilizes different version of the jBPM and Drools, most important in upgrade scenario when moving to the latest version to use the new features and fixed components/functionality
                    • isolalation of engine from the client, client does not have to be aware of versioning on the engine side but at the same time utilize its power
                    • application server agnostic although JBoss AS 7 is the reference and first and foremost implementation

                     

                    I will try to give you overview of what we are up to. There are several core elements of the platform:

                    • runtime components - jbpm, drools and its dependency libraries (packaged as JBoss Module with OSGi descriptors to make it available for OSGi bundles)
                    • platform components - apis and implementation of the platform that provide comprehensive functionality to glue all components together (packaged as JBoss Modules with OSGi descriptors, same as runtime components)
                    • custom bundle - this is where custom logic code is and where configuration for ExecutionEngine (this is the main type that clients will interact with), it can have as well process and rules definitions embedded (pure OSGi bundle)
                    • client apps - enterprise applications that utilize power of execution engine independent of its underlying configuration and versioning schema (war, ear, etc)

                     

                    Short info about of components relationship:

                    • runtime components will correspond to official version of the projects (5.2 for jBPM for instance)
                    • platform components will have apis that are independently versioned and are considered as very stable and should not change frequently - at least that is the plan; implementation of apis is bound to runtime components to allow bundles to use particular version of runtime.
                    • custom bundles are versioned as regular software artifacts that developers decide on
                    • client applications are versioned as regular artifacts that developers decide on

                     

                    Life cycle of the components:

                    • on application server startup Jboss Modules are started and its OSGI bundle activators will be invoked
                      • for runtime components there are no bundle activators
                      • for platform implementation bundle activator registers its execution engine builder in OSGi service registry so custom bundles can look it up and builds its execution engine bound to particular version of platform and runtime
                      • custom bundle, bundle activator will look up execution engine builder to build the engine and registers it in OSGi service registry for client applications with number of properties to distinguish it from other engine, for instance version number, or valid time
                      • client application will be bound only to platform api and knowledge-api and dynamically look up execution engine from OSGi registry using resolvers (another platform artifact) responsible to find proper execution engine for given request

                     

                    ok, that would be very brief description of what we are doing right now, in couple of days I can send you link to the repository where we are contributing as soon as some main interfaces will be defined. Let me know your comments and would be great to hear your requirements so we can think about them before finalizing conceptual phase.

                     

                    P.S.

                    If you are interested to see this working (not exactly this but what delivers similar result) I can send you a private message with link to basic PoC we have done at the beginning of this project.

                     

                    Cheers

                    • 7. Re: jBPM 5.x and OSGI integration/porting
                      mduk

                      Maciej,

                        Thanks for the overview. A PoC would definitely help in wrapping my head around all the requirements. I do have a few simple questions in the meantime:

                      1. How does this fit in with JBossOSGi initiative/roadmap?

                      2. The runtime and platform being worked on - how does it compare/contrast to other ongoing efforts such as Eclipse RT/Spring DM?

                      3. I do understand conceptually the above - but is it possible to also articulate the gap/pains/challenges this effort is filling/addressing in the Java OSGi space so that there are guiding principles around which the platform requirements are hinged?

                       

                      Regards,

                      -Mdu

                      • 8. Re: jBPM 5.x and OSGI integration/porting
                        swiderski.maciej

                        Mdu, the main goal is to have it OSGi runtime independent as much as possible since we target other application servers too. We try to be as OSGi spec compliant as we can and if it comes to JBoss OSGi we use it as reference runtime that delivers enterprise OSGi (not completely yet). So we are quite dependent on its roadmap, for instance JPA integration is one of really important parts we are waiting for. Currently we found some workarounds to make our platform to meet requirements but to have it flexible as expected we do require following:

                        • JPA integration
                        • DI like blue print or similar
                        • optionally WAB (web application bundles) to have clients completely OSGi'fied

                         

                         

                        Mdu Keswa wrote:

                        2. The runtime and platform being worked on - how does it compare/contrast to other ongoing efforts such as Eclipse RT/Spring DM?

                        I do not see it as a competitor of mentioned platforms. What we try to deliver with as we call it "platform" is dynamic ecosystem for BPM, BRM, CEP in one box that is ready for both business needs and IT needs. As business needs I mean agility in applying changes to your business artifacts (processes, rules, events, etc) without affecting already running instances (or at least minimize the risk of affecting them). As for IT needs it is never-ending story with upgrades, especially important in open source world where releases are more often and what is even more important to me, you (as user of the project) can decide to build it yourself (with some extra features or bug fixes) before official release. The platform is aiming at simplifying that and allowing both parties to operate on its full speed In general, as it rely in OSGi it should be possible (with some tweaks) to host it on Eclipse RT/Spring DM - I believe...

                         

                         

                        Mdu Keswa wrote:

                        3. I do understand conceptually the above - but is it possible to also articulate the gap/pains/challenges this effort is filling/addressing in the Java OSGi space so that there are guiding principles around which the platform requirements are hinged?

                         

                        A good one

                        This is very wide topic but I will try to put some thoughts here as they may cause other questions and further discussion. In fact the main challenge is to make the design truly modular and OSGi really enforces that. I believe we have past this and have quite clean and simple architecture, but I do think it will evolve once we start some playarounds in more advanced setup (clustering, distributed caches, etc). One of the gap (in fact we have not yet spent too much time on it) is human task server. As we work on the platform having multitenancy in mind we did not decide on how to host task server on the platform. Of course it will rely on OSGi delivering services through service registry (so all dynamics and versioning will be secured) but how to expose it to its counterparts (process engine and its sessions) is still not fixed.

                         

                        I hope I provided you with some answers and if you have any other I am more than happy to continue this discussion as I do believe it will make users and developers of jBPM and Drools life much easier. In addition our business users will appreciate it even more

                         

                        Cheers

                        • 9. Re: jBPM 5.x and OSGI integration/porting
                          mduk

                          Maciej: your answers helped a lot. I believe this is beginning a FAQ if you dont have one already. I agree that the value proposition is a great one, as well. Let me know what the next steps are and how I can possibly be involved as a developer. In terms of my own wishlist, it'd be great if we can consider a pageflow solution as part of this effort down the road. We have researched pageflow engines/solutions such as seam and spring webflow to figure out how BPMN processes can have a natural fit with pageflow and task driven UI interactions. One potential solution is to augment current support of BPMN sophisticated forms (or lack there of). I feel that this is such an unfortunate gap. jBPM/BPMN provides us with all this potential business platform flexibility and we turn around and hardcode UI's around human/user tasks.

                           

                          BTW, what's the code name for the project?

                           

                          Regards,

                          -Mdu

                          • 10. Re: jBPM 5.x and OSGI integration/porting
                            swiderski.maciej

                            Sure, we can consider this as a first FAQ as there is no other at the moment. I am in process of setting up a project in github with a structure and some main interfaces for the platform. Once I have this I can send you location of it and if you like you can contribute there

                             

                            I think it could be used for controlling the page flow as well, since that will be exposed as services to applications running on the container so app could be utilizing it in any manner. Our plan is to have some kind of dashboard that will be single point of interaction with user tasks and set of dedicated widgets that brings particular functionality as forms (based on OSGi too, so it could be as flexible as processes in terms of adding new/updated forms and more advanced views for user tasks). Of course that brings a need for integration directly with human task server which in my opinion is completely fine.

                             

                            code name for the project is jbpm-enterprise as I do believe it could be a nice addition to the core components of jBPM and Drools.

                             

                            Cheers

                            • 11. Re: jBPM 5.x and OSGI integration/porting
                              thingtrack

                              We are developing during a year a platform called konekti that use: OSGI Container Eclipse Virgo, Eclipse Gemini JPA, Spring 3.0.0 and JBmp 5.2 like backend, and GWT + Vaadin Ajax like Frontend. I just integrate JBMP 5.1 with drools 5.3 inside the OSGi container and every is fine, we can pass our services inside the JBmp and execute the process and rules. I have a problem because i would like to integrate also the JBMP and drools bundles to persist the process in mysql database. If I install the jbpm-persistence-jpa-5.1.0.Final.jar with all the dependencies i obtain this error:

                               

                              [2012-03-05 17:05:33.007] system-artifacts         <DE0003E> Install failed for bundle 'org.jbpm.flow-persistence-jpa' version '5.1.0.Final'.
                              [2012-03-05 17:05:33.009] system-artifacts         <DE0500E> Unable to install application from URI 'file:/opt/virgo-tomcat-server-3.0.0.RELEASE/./repository/usr/jbpm-persistence-jpa-5.1.0.Final.jar'. Cannot satisfy constraints for bundle 'org.jbpm.flow-persistence-jpa' version '5.1.0.Final'. Cannot resolve: org.jbpm.flow-persistence-jpa
                              Resolver report:
                                  Uses violation: <Import-Package: org.hibernate.annotations; version="0.0.0"> in bundle <org.jbpm.flow-persistence-jpa_5.1.0.Final[1330963520857]>
                                       Resolver reported uses conflict for import

                              . org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'org.jbpm.flow-persistence-jpa' at version '5.1.0.Final': Cannot resolve: org.jbpm.flow-persistence-jpa

                              Resolver report:
                                  Uses violation: <Import-Package: org.hibernate.annotations; version="0.0.0"> in bundle <org.jbpm.flow-persistence-jpa_5.1.0.Final[1330963520857]>
                                       Resolver reported uses conflict for import

                               

                              at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:45)

                               

                              I don't have any track to investigate ;(, i don't know what is the problem because the hibernate annotations are deploy correctly. Anybody knows what is the problem? or where to obtain any clue?

                               

                              Best regards.

                              • 12. Re: jBPM 5.x and OSGI integration/porting
                                swiderski.maciej

                                Mdu, here is a basic structure of the project with some core interfaces, I am working on adding more stuff but it will take a while as I don't have enough time to spent on it right now. I can promise it will slowly progressing