InfoQ - Tracking change and innovation in the enterprise software development community

06 Aug 09

Tobi B

First and foremost, rule engines are a different way to look at a problem - not necessarily better or worse, just different.

13 Jan 09

GoWing Lee

rulesengine rules java

19 Sep 08

Uma Shankar

workflow tutorial rulesengine programming opensource java rules-engine rulesengines software rules

21 Aug 08

Nicolas Krzyzanowski

drools architecture

08 Jun 08

Raymond Pendergraph

research rules engine

Most offer sophisticated matching algorithms like Rete, Treat and Leaps to connect facts with rules, determine which rules should be run and in what order.
Drools, like many of its competitors, uses Rete, a matching algorithm developed by Charles Forgy. Although a detailed treatment of Rete is beyond the scope of this article, the simplified form is this: Rete builds a tree from the rules, like a state machine.
9 more annotations...
- This is an area in which rule engines vary widely. Some support one or more existing languages in relatively full or snippet form, while others offer a proprietary language, and others still offer a visual design system.
- As of version 2.5, Drools offers support for coding rules in Java, Python and Groovy in an XML-based rule file or Java POJO rules wired up with Spring or JSE 5.0 annotations, as well as in custom-developed domain-specific languages.
- Fundamentally, both general-purpose programming languages and rule engines can be used to solve a similar class of problems, although some problems are more easily solved with the use of a rule engine, and others with general-purpose programming languages.
- Rule engines offer matching algorithms that can determine which rules need to be run and in which order, while still allowing the rule writers to exert some control over these factors when necessary with filters, workflow or conflict resolution.
- These qualities create subtle interactions which can have powerful results, even when the facts and rules themselves are simple. Often, its these characteristics that offer value over a general purpose programming language.
- The performance of the rule solution is likely to fall on the shoulders of the structure and code of rules themselves, rather than the engine that fires them, but particular rule engines will have their own best practices with respect to performance. It's not uncommon for the overall pattern-matching algorithm to be run repeatedly while the rule engine is interpreting inputs and scheduling rules, so it's important to keep these dependencies as thin as possible. For instance, in Drools, conditions may be run repeatedly during the early scheduling process, so one or more particularly computationally-expensive and frequently-visited conditions can have a significant impact on the overall performance. Until you're familiar with developing rule solutions in a particular rule engine, it will be worth keeping an eye on performance as you develop.
- By keeping the quotation rules outside of the web application archive, they can be deployed and redeployed on a separate lifecycle from the application that uses the server. Keeping the rules light and implementation agnostic, any information they need is passed into them, rather than being retrieved directly within the rules.
- It's often true that rule engines are an improvement in this regard, but it's also true that most rule solutions of even moderate complexity will require some involvement by developers. Even if the tool support is extremely easy-to-use, there's a technical analysis mindset and rigor that many business users have not needed to develop when considering edge cases and extreme conditions.
  
  The most successful solutions in this space empower a sort of collaboration between developers and business users where developers create the boundaries, set up the grand structures, and deal with any necessary technical complexities while allowing business users to customize the specifics of individual business rules within a more controlled environment.
- Rule engines are a useful tool that can be used to externalize business logic, allow business users to write rules, or solve certain classes of problems in an efficient way. When compared to other approaches, there are tradeoffs, so it's important to approach this decision in a methodical manner:
  
  Understand what problems you're trying to solve, what you're trying to accomplish
  Investigate if rule engines in general or a specific rule engine will help you achieve those goals
  
  In general, you might consider a business rule solution if you need to externalize business rules, support rapid change and empower business users to change business rules. You'll get the most out of a rule engine if you accept the new paradigm by relinquishing flow control, using fine-grained rules and objects, avoiding cross-products, and understanding the combinatorics and recursion that a rule approach can create.
  
  If, after consideration, you're not sure that a rule engine will accomplish what you need, consider developing a low-cost proof-of-concept with a freely available rule engine like Drools and evaluate for yourself if a rule engine is right for your problem space.
  
  If you decide to adopt a rule engine as part of your solution, accept that rule engines require some new skills in design and development, and expect some increased development costs and missteps until your team has acquired these skills.