[rules-users] Jbpm and drools

[Mark Proctor]

benjamin at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>