Re: [rules-users] Jbpm and drools

benjamin(a)romney.dk wrote: Yes jBPM3 and proposed jBPM4(schedueld for summer 2009) are indeed subsets of the Drools5 functionality. Drools5 Flow offers a richer set of nodes to model with and to support workflow design patterns. We also have out of the box rule integration, this is especially powerful with the new Complex Event Processing work we have done, which can be added to Event nodes or Wait nodes in the Flow for monitoring of streams. The reason for this is the jBPM team and Drools team have to different approaches for workflow. jBPM has a more conservative, stick with what you know, process centric approach to the problem domain. Where as the Drools team does not believe a process or rule centric approach is the future, instead we need a declarative modelling approach where rules and processes and event processing are all first class citizens with deep integration and unified apis and deployment mechanisms. The jBPM team believe our use cases too complex, they do not see the need for a unified api nor of a single way of doing deployment or server side management. For us moving away from process centric or rule centric, and allowing the problem to be modelled as the user feels fit is the more natural way and indeed some vendors (pega systems) have gone this way. What do I mean by uniformity of API? Well look how Drools and jBPM create their sessions now, very different, you have to learn everything twice and learning one does not help learning the other - there is simply no consistency. In Drools5 we have a new api that provides this uniformity as so: // Get your builder KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(); // Keep adding the resources that make up this KnowledgePackage kbuilder.addResource( urlToProcess ); kbuilder.addResource( urlToRules ); Collection<KnowledgePackage> pkgs =kbuilder.getKnowledgePackages(); // returns pkgs a deployable unit containing all your rules and processes KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(); // create the single knowledgebase that can contain rule and process defintions StatefulKnowledgeSession session = kbase.newStatefulKnowledgeSession(); // create your runtime session session.startProcess( "my process" ); // starts a process session.runUntilHalt(); // engine will continually evaluate all inserted objects, can also still use fireAllRules session.insert( myObject ); // inserts an object into rule engine session So as you can see from the above the uniformity provides consistency and intuitiveness across the too paradigms. Where as learning jBPM and Drools now is twice the effort, here if you learn the one you are very much close to learning the other. Also our flows, likes rules, can be managed and deployed from Guvnor our BRMS. What will the future hold? for jBPM and Drools? The Drools team have tried to do this jointly, but we couldn't agree on a joint vision, so currently there is no integration strategy for jBPM and Drools as they follow different paradigms (process-centric vs. unification of rules, processes, and event processing). As such, if a "stronger" paradigm of the two emerges at some point in the future, we can get the two teams to start working on this stronger paradigm in a joint effort - either way the future of jBPM and Drools Flow will be decided by you people, the end user. The new api will be in M3, which we are hoping to get out any day now, so please do checkout Drools Flow then. The pluggable domain specific work items for process modelling are particularly nice. After Drools 5.0 we will focus on a p2p agent infrastucture and api, which will facilitate distributed working and also remoting (which can be used for management and web based consoles, among other things). Again this will benefit from finding one generic way to do this, that applies to all. So if you like what we are doing, and think this is the way things should go, please do support us. Mark