[rules-users] Jbpm and drools

[keithnielsen]

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

-- 
View this message in context: http://www.nabble.com/Jbpm-and-drools-tp20337520p20428373.html
Sent from the drools - user mailing list archive at Nabble.com.