My hovercraft is full of eels

The centre (no, this is not a spelling mistake) of the programmatic world in JRules is the rule engine (IlrContext) also known as a context. The context holds a set (IlrRuleset) of rules (IlrRule). The context also holds facts. Facts are simple java objects and, as the name implies, are the things we know about the state of the processing "world". As you add (assert) facts about the state of your "world", the rule engine updates the agenda. At any given point, the agenda holds the rules that have conditions matching the current state and are therefore ready for firing.

Once a rule has fired, it is removed from the agenda and will not be made available for firing unless it, or another rule, modify the current state such that the rule conditions would once again be satisfied. This is pretty neat as it means you can have rules assert facts that cause other rules to fire.

Rules can be assigned a priority to assist in determining the firing order. The specific ordering rules are clearly documented so I wont repeat them here.

Rules can be grouped into "packets". Packets can then be referenced (and executed) by name. This can be very useful if you have certain classes of rules that you know you will/wont need during processing and therefore wish to programmaticaly enable/disable at runtime. JRules 4.5 also provides a RuleFlow mechanism which is supposedly the "preferred" method of achieving the same thing. I must admit that in our case, ruleflows didn't seem appropriate so we have so far stuck with packets.

There is one more facility for filtering rules from the agenda. These firing filters are applied to rules whos conditions have already been evaluated and are in the agenda. This differs from packets and ruleflows which selectively add/remove rules prior to evaluation.

Rulesets support in, out and inout variables which are then available to all rules within the ruleset. This is one mechanism you could use to parameterise your rules.

JRules out-of-the-box provides three languages in which rules can be written:

• IRL - ILog Rule Language;
• TRL - Technical Rule Language; and;
• BAL - Business Action (Natural) Language.

I started off using IRL as it was the language given in the documentation examples. It's a fairly low-level language. I think from a geeks perspective it's the one to start with as it gives you a good understanding of what actually goes on. IRL can be written using the text editor of your choice. A simple example of IRL might look like:

when {
    ?order: Order(product == Product.CHAMPAGNE);
    Customer(state == State.VIC; status == CustomerStatus.GOLD) from ?order;
} then {
    ?order.applyDiscountPercentage(15.00);
    System.out.println("Discount applied!");
}

This essentially says, whenever an order for champagne is raised by gold customers in victoria, apply a 15% discount and print a message to that effect.

Each condition in the when clause is evaluated in the order declared. The conditions are AND'ed together. If the condition(s) are met, any statements in the then clause are executed when the rule is fired. For completeness, there is also an else clause.

As you can probably see, the IRL is a Java-like language supporting, as far as I can tell, almost all usual java syntax (including imports) plus the additional syntax required for describing rule conditions.

TRL is pretty much the same as IRL but is more verbose. For example:

when there exists an Order(product == Product.CHAMPAGNE)...

Strictly speaking, the BAL is actually an example language that demonstrates how you can build your own language on top of the underlying languages. Having said that, the BAL is almost feature complete and many businesses will choose it over the TRL and IRL. The intention is that business people can write in BAL. In actualality, I see this being about as likely to happen as business people using Crystal Reports to write custom reports. If you can make it happen, great but I very much doubt it. However, BAL is much easier to read especially for business people and even for developers. So when, as a developer, you need to validate that the rule you've just written is correct, BAL is a god send. Even mildly complex rules are quite hard to follow in raw IRL and, for that matter, TRL.

BAL also requires a mapping layer between your Java objects and natural language. This is so that instead of writing order.getTotal() we can instead use the total amount of the order. On an agile project that is ramping up, I can see this as being an small but certainly not insurmountable issue due to the ever changing domain model.

JRules comes with a GUI Editor that allows you to maintain rules in any of the supported languages. While it is possible to create rules by hand in IRL and stored as plain text files, TRL and BAL require the GUI. The rules are stored in a repository (directory structures) that can then be exported to an IRL file for use by an application. Again, Not so much of a problem really but being forced to point and click when I really just want to type is very frustrating. If I could ask for one thing, it would be the ability to edit BAL rules in my editor of choice and then import them into the repository.

BAL and TRL are both converted to IRL. IRL can be converted back into TRL. Unfortunately the conversion from BAL to IRL is a one-way street. Taking a look at the generated IRL was quite an eye-opener. The rule editor converts BAL into IRL that is almost impossible to understand by a human.

From a purely technical perspective, it matters little what language the rules are written in as they end up as IRL which is then parsed and executed by your application. Loading and running a test requires only one jar file (jrules-engine.jar) and can be as simple as:

public void testEngineIntegration() {
    // Define a simple rule
    final String rule = "rule TestRule\n" +
            "{\n" +
            "    when\n" +
            "    {\n" +
            "        not String();\n" +
            "    }\n" +
            "    then\n" +
            "    {\n" +
            "        assert Integer(57);\n" +
            "    }\n" +
            "};";

    // Parse the rule
    IlrRuleset ruleset = new IlrRuleset();

    assertTrue("Rule parsing failed", ruleset.parseReader(new StringReader(rule)));

    // Create a context (rule engine)
    IlrContext context = new IlrContext(ruleset);

    // Execute the rule and ensure it was actually run
    assertEquals(1, context.fireAllRules());

    // Check the final state matches the expected state
    Enumeration enum = context.enumerateObjects();

    assertNotNull(enum);
    assertTrue(enum.hasMoreElements());
    assertEquals(57, ((Integer) enum.nextElement()).intValue());
    assertFalse(enum.hasMoreElements());
}

You can also load rules directly from the repository if you wish. So far we haven't attempted this and for the time being at least it's not a high priority as we will be loading the ruleset from the exported script.

The repository, apart from being a pain to use, has some other mildly annoying issues when working in an agile team. These are mainly to do with locking rules for editing. The rule editor allows you to create rule packages (not to be confused with packets) and it is only at these levels that locking is possible. Again, not too much of an issue. Besides, you will quickly find your rules unmanageable if you don't group them at all. Packages are also useful if/when writing ruleflows. Remember however that these packages are purely logical and affect only the names of the generated rules. Something you will most likely rarely have to worry about anyway.

Generally, I would recommend keeping your rules as simple as possible. If your find your rules blowing out to four pages, stop and think again. Rules can and should be decomposed into smaller rules. James Ross has been reading a great book on the subject, Principles of the Business Rule Approach, which he says is a must read for anyone embarking on business rules analysis.