Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
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?
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).
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.
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
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.
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.
