Saturday 12 July 2008

Working with Drools from a JRules perspective

I had heard a few good things about drools , so I had a play with it over the last few days. I decided to create a small project in JRules 6.7 and keeping the same object model port it to drools 4.07 and see what happens. I specifically wanted to test out porting the following:

  • verbalisations
  • a ruleflow , with a subflow
  • business rules (brl rules)
  • decision tables
  • local variables
The projects I created can be downloaded from a link at the bottom of this post.

The rule project

I created a simple JRules project to process a train ticket. Given a journey start point (zone) and a journey destination, the rules would work out the cost of the journey and deduct it from the user's credit on their prepaid card(Oyster card). The price would also be influenced by the type of user (i.e. train staff, student, senior) . I have tried to keep a one-to-one mapping between rules I have created in JRules and rules I created in Drools.

Download the report of the jrules project from here.

The editors

JRules and Drools both provide an editor which is a plugin to eclipse. Actually, using eclipse is the only way to build the rules too. Even if you need to build from the command line , it runs in eclipse headless mode. However in Drools you are not tied to the editor, you can write all you rules in notepad or vi if you want then use the libraries to build them. That said, I would recommend using the eclipse plugin for Drools.

Verbalising the object model

Firstly if you are unclear about what an object model is in relation to rules, read Dan Serner's useful entry on his ILOG blog.

Ok, JRules , creates your object mapping for free, and creates default verbalisations for your object model. This is great so you can start writing rules right away. However some rules can end up with some convoluted verbalisations as you would have verbalised your object model without thinking about how each one will be used in the rules. You will probably have to go through a verbalisation refactoring stage to sort this out.

However in Drools, you need to create a dsl (domain specific language) file which maps expressions and actions to some given text. So you first think of your rule, then think of the verbalisation, then you add the mapping to your dsl file. This can lead to rules with greater readability, but you have to add each verbalisation yourself.

Here's a shot of my dsl file. (btw all the source code can be downloaded from a link at the bottom)

Writing business rules

Ok in Drools you can write rules directly in DRL (equivalent of IRL in JRules) or you can write rules in dslr which use verbalisations (equivalent of BRLs I guess).

Ok the first thing that threw me, was that you can't use an else in a rule. Weird huh? But there is probably a good reason for it. The other thing was, that I found myself getting into an infinite loop in a rule. You need to set the no-loop property on the rule otherwise it will keep evaluating if the when condition is true. Otherwise no other great surprises here.

Decision Tables

In JRules, you create decision tables within the eclipse editor. I have always found the Jrules decision table editor a bit flaky and pretty slow to open an existing decision table.

In Drools, you create decision tables in excel spreadsheets, csv or openoffice spreadsheets. You do not get autocomplete like the JRules editor, and auto static analysis and some other wizzy stuff, but it is very flexible. And given that while I have been working with JRules, I end up importing and exporting everything I do with decision tables to spreadsheets, I found this pretty useful.

Ruleflows

The ruleflow functionality is pretty similar between JRules and Drools. The major exception though is probably that a rule or decision table in Drools points to the rule group(ruleflow task in jrules) it belongs to, rather than in Jrules where a ruleflow task only knows which rules it contains, and a rule can end up in many tasks.

Actually one of our complaints about JRules was that it was difficult to find out which ruleflows a rule is referenced in. But in Drools as it is the other way round, it is a bit of a hassle to search for all the rules that belong to a group, hopefully in a newer release the editor will automatically show all the rules that belong to a group.

Another thing about decision tables in Drools is that individual rows can belong to different rule groups. In JRules the whole table goes in the task.

Local variables

Ok this is where I found the most pain in drools. The equivalent of local variables in drools are global variables. I just couldn't get these damn things to work properly, so I created a local variable class, and a local variable object was passed into the ruleset as a parameter to provide the same functionality. It was also a pain , because I wanted to use a global with a primitive type and drools just didn't like it, and I ended up with some weird errors.

Building and executing

As I mentioned earlier drools is a bit more flexible as you do not need to use eclipse to build your rules in the same way JRules forces you to do. But in drools you need to add each rule or rule package to your ruleset or Rulebase , in your code. In JRules you just build your jar , and you have all your rules neatly packaged up. The code to execute the rules in drools is slightly easier than jrules i would say. Look at the code in com.transport.ticketFeeRules.jrules.RuleEngineRunner and com.transport.OysterCardRules.droolsrulerunner.DroolsRuleRunner , and you will see the difference.

The verdict

I like Drools, but if I was choosing a rules engine at the moment for my project I would stick with JRules. I know Drools is free, but I think it still needs to mature a bit. All the features are there, and it has a web based BRMS too. I have never used JRules Rule Team Server so I didn't compare it to Drools' equivalent.

In a couple of years though I expect Drools to be a real challenger in this space and as it is opensource I expect a lot more expertise to be out there. So if you have been working with JRules I encourage to try out Drools, but don't expect it to be a replacement just as yet. But if you are going throught the decision process now of picking a rules engine, do not discount Drools, it maybe exactly what you need.

Download my comparision projects from here.

Related blogs:

Drools Rules - useful examples on using Drools and benchmarking
ILOG Blogs - the official blog from the company behind JRules
Drools - the blog from the guys who produce Drools

6 comments:

  1. Interesting post and good feedback!

    I suspect that as your project became larger and more complex (realistic?) you'd get even more value from JRules. For example,
    - refactoring support when the BOM or XOM evolves,
    - ability to expose rules to business users for review or editing,
    - using complex expressions within your DSL.
    - deployment to a managed execution environment, such as provided by the Rule Execution Server

    Sincerely,
    Dan

    ReplyDelete
  2. We are using ILOG for the past few years..

    I find it they are really freaking expensive for what we use it for.. We are looking for alternatives, and I would like to try Drools for sure after reading this post..

    Thanks for sharing..

    ReplyDelete
  3. Hey SM,
    I want to learn ILOG Jrules 6.7 and was just looking for some ways to get a good start. Can you suggest something?

    BTW, am very new to JRules, and basically a java developer.

    Thanks...

    ReplyDelete
  4. Posso, I would suggest you download the trial version of JRules 6.7 from the ILOG website, then go through the tutorials. Also take a look at the ILOG forums.

    ReplyDelete
  5. Hi SM,

    This is more or less rewriting the whole rules back in Drools. Do you find any tool or plugin that converts a .irl file to .drl file?

    thanks
    Rams

    ReplyDelete