Pros and cons of Java rules engines [closed]

Question

What are the pros and cons to adopting the Java rules engines JESS and Drools? Are there any other players?

I understand that Drools is Open Source and JESS is not, but how do they compare in other areas like ease of use, performance, level of integration with your code?

Fickle

Answer 1

What are the pros and cons to adopting the Java rules engines JESS and Drools?

Use a rule engine if you need to separate the business rules from the application logic. The Does Your Project Need a Rule Engine article has a good example:

For example, a typical storefront system might involve code to calculate a discount:

if (product.quantity > 100 && product.quantity < 500) {
  product.discount = 2;
} else if (product.quantity >= 500 && product.quantity < 2000) {
  product.discount = 5;
} else if (product.quantity >= 2000) {
  product.discount = 10;
}

A rule engine replaces the above with code that looks like this:

ruleEngine.applyRules(product);

Up to you to decide whether putting a rule admin console in the hands of non-technical people is a good thing or not :)

More details in Should I use a Rules Engine?, Why use a Rule Engine?, Some Guidelines For Deciding Whether To Use A Rules Engine and on Google.

Are there any other players?

Other players include JRules, Corticon (JRules is the most famous IMO - which doesn't mean the best).

how do they compare in other areas like ease of use, performance, level of integration with your code?

Can't tell you precisely, I only have a little (positive) experience with Drools. But you'll get some feedback from blog posts like JBoss Drools vs ILog JRules - an anecdotal story (be sure to read it) or Working with Drools from a JRules perspective. I'm sure you can find more of them on Google (but I would give Drools a try).

Gustin

your answer looks good. Could you please tell me where to use drool and where to Jess? Basically , I'm expecting the answer more related diff. b/w drool and Jess. – Budworth

Wow, @Pascal, that product quantity/discount example is a real WTF. Say quantity is 5,000. The first IF evaluates to true, the ELSE IFs are never evaluated. Putting that kind of business logic in a rules engine isn't going to help anything, though it might make it more difficult to find the bug. – Winglet

In his defense that example was from that first article. Not so sure how credible that one's looking anymore...:) – Deoxidize

Just a good example of the dangers of putting rules control in non-technical hands. – Vertigo

The Why use a Rule Engine? is the best among the links listed – Osteoarthritis

Answer 2

We are evaluating rules now for use with our application server. We have come across OpenRules, which is easy to integrate with Java and, as far as our testing has shown, fast enough. The main advantage of OpenRules above the others is the way the rules are modified and handled. It all happens in Excel tables, which is the easiest way for non-programmers. Everybody involved, even the non-technical people, understood everything perfectly :-)

We also have drools integrated, but the rules are way more complicated to understand as it is a more programmatic approach. That's why we - most likely - will stick to OpenRules.

Bessette

Drools also supports rules edited in Excel, and via a web interface. – Fuss

Answer 3

We had similar question with us, we finally picked up Drools, one should use drools if you have following:

• Business logic which you think is getting cluttered with multiple if conditions because of variety of scenarios
• You will have growing demand of increase in the complexity
• The business logic changes would be frequent (1 - 2 times a year would also be frequent)
• Your server's have enough of memory as it is a memory hungry tool, it provides performance at cost of memory

Have more details at following URL

Hung

Answer 4

Just adding that many people are looking for something more akin to managing whether certain conditions are met to enable or disable certain features in an application.

I grew tired of re-implementing the same pattern over and over everywhere I went, so I decided to make an OSS project for it called Roolie http://sourceforge.net/projects/roolie/

I just maven-ized it and since there have been no bugs reported since 2010 when it was released, I upgraded it to v 1.0 with no changes other than those required to host it at Maven Central (which i'm in the process of doing).

Basically JSR-94 is overkill for most things, and there is a huge learning curve and overhead that go along with the current offerings. That's fine if that's what you want. But if you just want to chain simple rules written in Java together with XML to maintain your state tests, Roolie is a very fast way to do it. No dependencies and no learning curve.

Jaqitsch

Roolie states it's MIT licensed on SourceForge, but the code reports LGPLv3. This essentially means it's dubious to use it in any commercial product (and in some Open Source products, too). See nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html . – Distressful

Answer 5

When we needed a rules engine, we decided to roll our own, because the available ones were far too complicated for our simple tasks. If you are even remotely experienced with parsing expressions users may put in, this is not very hard to do. In our case, most of the spec is handled by an XSD and only a few of the fields are parsed further.

Ubangishari

Rule engines use well-established algorithms (such as forward chaining and the Rete algorithm) in order to scale up to non-trivial problems. If you are simply evaluating expressions, an existing library such as MVEL may be useful. – Mosstrooper