After looking at jbpm and drools I got a bit confused. It seems like drools can do the same kind of work as e.g. jbpm bpel using rule flow and work items. I am just wondering why I should bother learning jbpm when drools are available. Can someone please enlighten me on this matter?

_______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Mark, Do you have plans to support the persistence of workflows/rule flows (or maybe its already there and I am missing it). Seems this is one area that BPM team has put alot of their energies.

I would also agree that its terribly confusing to companies like mine who are moving into the BPM/Rules space to have two solutions from the same organization with no apparent strategy to consolidate them.

Thanks Mark Proctor wrote: > benjamin(a)romney.dk wrote: > >> After looking at jbpm and drools I got a bit confused. It seems like >> drools can do the same kind of work as e.g. jbpm bpel using rule flow and >> work items. I am just wondering why I should bother learning jbpm when >> drools are available. >> >> Can someone please enlighten me on this matter? >> >> > 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 > > >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > >