[rules-users] Jbpm and drools

[Mark Proctor]

keithnielsen wrote:
> 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.
>   
This is working in Drools 5.0 - we support transactions and persistence 
of sessions. There is also task management, based on WS-HumanTask, the 
backend is now solid but we still need to do more for the front end.
> 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.
>   
Agreed, definitely confusing. But our only other choice was to not do it 
at all. I hope that once people start looking into what we've produced 
(especially once we have more documentation) they will be glad that we 
did push ahead with what we have, and realise that our passion for this 
was justified. This isn't just another BPM product, it's a lot more than 
that.

> 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
>>
>>
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20081110/af845365/attachment.html