I need a simple rules engine, I think?

21,034

Solution 1

This is not an yes/no question, but I can probably share my experiences, and hope it helps. I have used DROOLS quite successfully in a few projects. Apart from some cases (another team had issues with DROOLS under heavy load,) DROOLS is quite an useful library.

I built an application which:
1. read input from a source
2. chose the next action based on the input from a set of available operations

As trivial as it looks, it needed to be very flexible:
1. The input was a variable set of name-value pairs, names not predetermined.
2. values, presence/absence of certain name/values (based on occurrence/absence of events), trigger different actions.
3. The business rules can change while the application is running.

Maybe there are better solutions, but for better or worse, I ended up using DROOLS. I developed a BPEL in which the decisions are made by the DROOLS component. The DROOLS component internally reads the decision making rules from a Microsoft Excel spreadsheet. It rebuilds the rules if there is a change in the file. Now the domain experts change this spreadsheet when required, and we do not go through painful deployments!

If you want a sophisticated UI, DROOLS Guvnor is a readily available web-application (with rich UI,) which would help your domain/subject-matter experts to build rules and store them in a database.

Solution 2

The Drools documentation talks about when to use a rules engine. http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-expert/html_single/index.html#d0e181

From the docs...

The shortest answer to this is "when there is no satisfactory traditional programming approach to solve the problem.". Given that short answer, some more explanation is required. The reason why there is no "traditional" approach is possibly one of the following:

-- The problem is just too fiddle for traditional code.

The problem may not be complex, but you can't see a non-fragile way of building a solution for it.

-- The problem is beyond any obvious algorithmic solution.

It is a complex problem to solve, there are no obvious traditional solutions, or basically the problem isn't fully understood.

-- The logic changes often

The logic itself may even be simple but the rules change quite often. In many organizations software releases are few and far between and pluggable rules can help provide the "agility" that is needed and expected in a reasonably safe way.

-- Domain experts (or business analysts) are readily available, but are nontechnical.

Domain experts often possess a wealth of knowledge about business rules and processes. They typically are nontechnical, but can be very logical. Rules can allow them to express the logic in their own terms. Of course, they still have to think critically and be capable of logical thinking. Many people in nontechnical positions do not have training in formal logic, so be careful and work with them, as by codifying business knowledge in rules, you will often expose holes in the way the business rules and processes are currently understood.

When not to use...

As rule engines are dynamic (dynamic in the sense that the rules can be stored and managed and updated as data), they are often looked at as a solution to the problem of deploying software. (Most IT departments seem to exist for the purpose of preventing software being rolled out.) If this is the reason you wish to use a rule engine, be aware that rule engines work best when you are able to write declarative rules. As an alternative, you can consider data-driven designs (lookup tables), or script processing engines where the scripts are managed in a database and are able to be updated on the fly.

Share:
21,034
Andy
Author by

Andy

Elasticsearch, Java, Video, C#, React, iOS, AWS

Updated on May 28, 2020

Comments

  • Andy
    Andy about 4 years

    I need some advice on the best approach to solving this problem.

    I've researched DROOLS, Java Rule Engine and a few others. All of these are powerful, and have good things about them. I don't know which (if any) will be the best choice for me.

    I have one business object. (simplified for demo)

    Person
         firstName:String
         lastName:String
         departMent:String
         hireDate:Date
    

    I need to write an editor in a web application that will allow for complex rules to be built around these fields. I need to support complex nested AND/OR logic. I just need basic operators, and the rule should simply evaluate to true or false. If the rule evaluates to true or false, one action will occur respectively.

    For example,

    firstName CONTAINS "value" AND (lastName EQUALS "input" OR department CONTAINS "input")

    I had thought, maybe I should just write my own parser and evaluate the logic in my own code. I don't know what to do, any advice or links to something to read would be greatly appreciated. Is there a specific design pattern I could research?

    How would you solve this problem? One reservations about the rules engines is that maybe they are too complex for just a simple problem?

  • Andy
    Andy over 13 years
    I'm slightly confused by what you mean by serialize the object. The web front end is simply going to build the rule based off the fields. I will apply the rules on the back end against all of the "Person" objects in my database.
  • Andy
    Andy over 13 years
    I read this. We are going to have "Domain Experts" build the rules, but there is no way they would consider writing Drools rules in the Drools editor. These people want a nice editor that practically does it for them, and is tailored precisely for the problem domain. I don't like the idea of write my own code that writes drools rules, and I like typing drools rules. :)
  • Bill
    Bill over 13 years
    You don't have to have non-programmers write rules. That is one rational for having a rules engine, but it's perfectly fine to have a programmer write the rules. However a cursory glance at what you have given points more to a non-rules based solution. A parser seems simpler, rules-engines are non-trivial to setup.
  • Bill
    Bill over 13 years
    @Stephen Not sure I agree with the statement "Rules systems only work with simple rules on a restricted domain, where you can explain people not trained as programmers how to build them" They are also good for complex rules where the algorithm is not easily defined. I've used a rules engine effectively to address a network provisioning issue that none of the experts could effectively explain (except of course thier own part).
  • Andy
    Andy over 13 years
    No, I will google it. Thanks
  • Stephan Eggermont
    Stephan Eggermont over 13 years
    I have to disagree there. They are not good at all for complex rules. Lack of visibility, refactoring, modularisation, speed, flexibility are the common problems I've encountered. For those I strongly prefer something like a Smalltalk system, where you can simply create DSLs and build powerful models.
  • Stephan Eggermont
    Stephan Eggermont over 13 years
    But be aware that bringing some agility to the organization is much more likely to bring good results than pushing a rules engine because the IT organization releases quarterly. It is not difficult to build an organization that releases twice a month. And once you allow programmers to build the rules, you've effectively created two problems out of one.
  • rds
    rds over 13 years
    The question is obviously not on parsing the object, but the best approach to apply rules on these objects.
  • Dasith Wijes
    Dasith Wijes over 13 years
    When he said "I had thought, maybe I should just write my own parser and evaluate the logic in my own code." , I thought he was asking the best way to apply the rules on an object that would be constructed on the front end using user input. Didn't get that he wanted to contruct the rules on the front end.
  • flup
    flup over 10 years
    How is a testing framework supposed to help implementing business rules? Do you mean he can rip out the test definition engine and reuse it to implement the rules?
  • Manu
    Manu about 9 years
    Not sure this answer is intended for the above question