General Questions

What are RBS, when to use rule engines, when to avoid...


What's a rule-based system (RBS)?

Any software system which employs an inference rule-engine for its purpose.


What's a "Rule-Engine"?

This site talks about production rule systems, a.k.a. inference engines. The term rule-engine is really ambigous, as every piece of software that deals with if-then-else rules nowadays gets called rule-engine by its authors....

In my understanding, a rule engine is an inference engine, which does the following things:

  1. It knows a number of facts, present in the so called working memory.
  2. It knows a number of rules, present in the so called production memory. Rules are declarative statements of the form

    when-condition-then-consequence.

  3. It matches every fact with the condition-part of every rule and collects all matching rules in the so called agenda.
  4. It executes the rules in the agenda one-by-one. If the consequence-part of any executed rule alters the existing facts, all rules are re-evaluated...
  5. repeat until no more rules can fire.
This procedure is called match-select-act or recognize-act cycle. You find some more detail here (external link).

When shall I use a Rule Engine?

When you:
  • have your overall business logic scattered around your business classes, much of it within nested if - then - else statements.
  • need loads of flexibility in your business logic.
  • your classes suffer from overly high coupling, making them difficult to adapt to new requirements.
  • are open to new technologies which you can evaluate without severe pressure, you should flirt with rule engines. Later marriage possible...
Reference:

Some Guidelines For Deciding Whether To Use A Rules Engine, by George Rudolph, http://herzberg.ca.sandia.gov/jess/guidelines.shtml


When shall I avoid a Rule Engine?

Rule engines and rule languages follow a different paradigm (*declarative logic*) than *conventional* languages like Java, C# or Ruby with their statement- and command-oriented usage. Mixing two paradigms within a single application increases complexity (yes - it *can* also increase flexibility). A simple test: Get together with one of your business experts and try to write down typical rules. Brainstorm, do not strive for perfection. Create rules of the form: when (conditions) then (consequence) If you cannot find significant rules within half an hour, avoid using a rule engine. You should avoid using a rule engine if your application:
  • can derive its decisions based upon pure algorithmic computation or database queries.
  • has to operate under severe resource constraints, concerning memory footprint, processor cycles or both.
  • contains only static processes or logic, which is really unlikely to change over time. You can code this kind of logic in conventional programming languages.
  • needs to fulfill hard-realtime constraints, has to guarantee timing constraints.
If your project operates under severe timing constraints, you should **not** introduce too many new technologies. In case rule engines are new stuff for your team, forget it (at least as long as the pressure remains). Reference:

Some Guidelines For Deciding Whether To Use A Rules Engine, by George Rudolph, http://herzberg.ca.sandia.gov/jess/guidelines.shtml


What is Business-Rule-Management

From any serious business point of view, there is much more to managing business-rules than just the plain rule-engine: Rules have to be *governed* (though few people nowadays talk about rule-governance, most of the governance-people are way tooo busy selling SOA-governance...) You have to care for at least the following aspects:
  • Responsibility for the business-side of rules: Who may introduce new rules, are there signoff-procedures?
  • How are rules "deleted" from the rule-base? Are there procedures for removing active rules?
  • How are rules implemented (not all business rules are suitable for execution by a rule engine)?
  • How is re-use ensured across different applications? Especially if those applications are based upon different software-infrastructures, developed indifferent languages and operated in different IT-centers...
  • How is the financial benefit of a specific rule monitored? Did the new rule increase or decrease overall profits? How can an organization detect bad rules?
  • How are environment changes (laws, new partnerships, infrastructure changes) incorporated into the business rules?

How do I incorporate rule engines into my architecture?

A long version [here](../../samples/samples/wrapper.html) - you'll need to adapt it. The short version:
  • Hide away all the rule-engine specific stuff behind a wrapper (I prefer to call this one RuleInvoker or RuleEngineWrapper).
  • Have one component add business objects to this RuleEngineWrapper, call the rule engine and propagate its results back to your application.
  • Construct a proper testing facility. It is difficult to test rules with pure unit tests, so you gotta invest some brain here. Start with simple unit tests.
  • Care for operations: Integrate logging facilities into your RuleEngineWrapper- many rule engines support you with clever strategies.
  • Take special care for an effective rule governance: Somebody within your organization has to care for rule management:
    • When to introduce new rules?
    • When to delete rules from the rule base?
    • How to modularize your rule base?

How do I incorporate rule engines into my code?

That depends on your rule engine. You find some useful info in the [RuleEngineWrapper](../../samples/samples/wrapper.html) within the Samples-Section.

What's forward- and backward-chaining?

The two possible types of rule-engines. Both types build on facts and rules, they differ in the way they operate. My (overly simple) answer:
  • Forward-chaining: Gather all interesting facts in working-memory and let the rule engine determine what can be deduced from those facts and rules. You start with facts, some rules can fire and possibly create/modify other facts. The process ends when nothing new can be determined or no rule can fire. JBoss-Rules is a typical forward-chaining engine (although it might add backward-chaining capabilities in the future).
  • Backward-chaining: The rule engine tries to prove a conclusion. Prolog is a typical backward-chaining system/language. You state some facts and rules and let the system (try-to) prove a given conclusion: "Can this fact be deduced from the rules and the other facts?"

What's JSR 94?

An initiative to define a Java runtime API for rule engines by providing a simple API to access a rule engine from Java. In theory, rule engines can be seamlessly interchanged if they comply to JSR 94. In my opinion this attempt is futile due to at least two reasons:
  1. JSR 94 covers only the rule engine API, but NOT the rule language. This API describes how a rule engine should be invoked from Java, that's the (simple) infrastructure code. You'd have to rewrite (and re-test) ALL your business rules to change the engine - and rule languages are by no means similar to each other...
  2. Who wants to change the database? In more than 20 years I have not seen a single customer migrating a productive system from one database to another - although database independency long seemed a crucial issue. I've experienced cases where we used MySQL for development and Oracle for production - but they behaved differently, even with powerful OR-Mappers we could not resolve those issues. Don't tell me anybody wants to try this with their business rules... nobody wants them in two different rule-languages.

Please let me know if your experience differs from mine...


What's RETE?

A matching algorithm developed by Charles Forgy. It very efficiently (meaning: fast!) finds out which rules of a given rule-set can fire against a given set of facts. RETE exists in several variations. Don't care about the details - you still have to develop the rules...

Some links:


How do I manage large rulesets?

Tricky question. Every possible answer might be wrong in some cases. Here's a list of helpful tactics:

  1. Introduce rule governance - well-defined processes on how rules are created, designed, tested and administered.
  2. Think before you act. Governance (see above) will likely be more important than technology.
  3. Define your architecture - get some experience from several different applications using it, refine it and standardize it, at least within your organization.
  4. Have business- and IT-people row in the same boat, pull the same strings and cooperate.
  5. Have a good look at some success-stories. The big rule-engine-vendors have some impressive ones for you. But: The price-tag does not necessarily correlate to applicability within your organization. It's the same evalutation story as with other long-lasting decisions...

I like this site (1) - where can I donate money?

Donate to charity, not to me. Our envirnoment badly needs support. We're currently destroying wildlife at an alarming rate, with unforeseeable impact on our childrens' future.


I like this site (2) - where can I learn more?

Have a look here (which I promise will be fun and effective) or read a little.