Mdu Keswa [https://community.jboss.org/people/mduk] created the discussion "Re: jBPM 5.x and OSGI integration/porting" To view the discussion, visit: https://community.jboss.org/message/719295#719295 -------------------------------------------------------------- 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? -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/719295#719295] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Mauricio Salatino [https://community.jboss.org/people/salaboy21] created the discussion "Re: jBPM 5.x and OSGI integration/porting" To view the discussion, visit: https://community.jboss.org/message/719491#719491 -------------------------------------------------------------- I'm also interested in that project :) , if you can send the details we can help! -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/719491#719491] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Maciej Swiderski [https://community.jboss.org/people/swiderski.maciej] created the discussion "Re: jBPM 5.x and OSGI integration/porting" To view the discussion, visit: https://community.jboss.org/message/719663#719663 -------------------------------------------------------------- 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 -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/719663#719663] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Maciej Swiderski [https://community.jboss.org/people/swiderski.maciej] created the discussion "Re: jBPM 5.x and OSGI integration/porting" To view the discussion, visit: https://community.jboss.org/message/720090#720090 -------------------------------------------------------------- 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 ;) 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... 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 -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/720090#720090] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Maciej Swiderski [https://community.jboss.org/people/swiderski.maciej] created the discussion "Re: jBPM 5.x and OSGI integration/porting" To view the discussion, visit: https://community.jboss.org/message/720703#720703 -------------------------------------------------------------- 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 -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/720703#720703] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Maciej Swiderski [https://community.jboss.org/people/swiderski.maciej] created the discussion "Re: jBPM 5.x and OSGI integration/porting" To view the discussion, visit: https://community.jboss.org/message/722790#722790 -------------------------------------------------------------- Mdu, https://github.com/mswiderski/jbpm-enterprise 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 :) -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/722790#722790] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&...]