JAX 2009: Drools (- freie Rule Engine vom Feinsten)

(Disclaimer: this text was written while listening to the presentation – please be forgiving with errors that might result from both listening and writing)

Our last JAX 2009 talk – we are waiting for Arno Haase to begin his talk about Drools, a business rules engine. Business rules engines have been one of the areas we have been neglecting for too long and I suspect great potential for our internal model driven framework – therefor I hope for a closing highlight of this JAX. Let’s get started…

Arno is going to present both an introduction, an overview, architectural information and specific examples. He introduces rules engines as a new programming paradigm based on truth logic (whatever he means by that). Drools exists since 2001, the current release is 4.0.7. Version 5.0 is expected to appear in the not too far away future and will rename quite a number of concepts although the concepts themselves remain unchanged.

Rules engines operate on facts which can be imagined as a kind of database. These facts represent the truth of the world. Rules operate via preconditions on the facts and then execute actions (e.g. modifies facts). Additionally rules engines usually shine by allowing to formulate rules in a kind of natural language. The rule base is called the production memory.

Rules are defined in text files suffixed “.drl” and are compiled to Java classes. Rules have a name (without further meaning), a when-part specifying an execution condition and a then-part that defines the action(s) to take. The actions are arbitrary Java code. Arno seems somewhat unsure about his own code – I thus would like to point to the Drools manual. To execute rules you need to load the rules and have Drools compile them, then you initialize a rule base by adding the packaging ensuing from the compilation process. Next a working memory is created, the facts are added to this working memory and from then you can start firing rules. The fireAllRules() method shown in Arnos example will – according to his examples – fire rules as long as some of them can fire. If several rules are eligible for firing, the rules engine first puts them on the so-called agenda and then executes them in an arbitrary order (at least you should imagine it that way – in reality the rules engine uses quite a number of engines to determine which rules might fire again, etc.). If the order is important each rule can be given a salience (an integer value) – the fireable rule with the highest salience will fire first.

According to Arnos explanations the life expectancy of a working memory usually is longer than the current user interaction. Objects are inserted with insert(o), update(o) informs the rule base about changes to the object o.

Additionally global objects can be inject via setGlobal(o) in order to provide services, etc. Additionally functions can be defined for recurring actions and Drools also offers queries in order to retrieve collections of facts that hold true for a given matching condition.

Finally objects can extend PropertyChangeSupport of Java Bean API fame in order to communicate with the Drools engine by using property change events.

An important aspect of rules engines is the so-called truth maintenance meaning that once a rules engine stops working, no more rules can be fired because all facts are true (as stated by the rules).

Drools also can process Excel tables containing decision tables. A short example was shown – Arno probably has also seen once or twice.

A very interesting feature of Drools is to be able to handle domain specific languages, e.g. human understandable textual facts. These are defined in “.dsl” files and contain placeholders for variables. Each line represents a rule, the text blocks are transformed into actual rules. Additionally there is an XML syntax to represent rules, which – like so often with XML – is useful for machine readable (and writeable) rule exchange but seems to be much too verbose for human use.

Drools differentiates stateful working memories (the typical case) and stateless memories – in the latter case the state is dropped after firing the rules.

Arno explains that rules engines typically are used in areas with huge data sets that quickly have to be analyzed, e.g. for evaluating call data records in telecommunications.

Finally Arno provided some information about how to deploy and update rules engines, rules sets, working sets, etc. I found them to be too trivial to repeat here since they seemed to be what you usually expect for updates. There also seems to be a Drools server that provides a lot more workflows, versioning, historization, a permission concept and more. These could be especially useful when domain experts without IT knowledge are expected to work with rules sets and you don’t want to scare them with complicated technical procedures (like e.g. subversion checkins).

He concluded stating that rules engine are a powerful tool to solve certain problems, Drools being first choice in most cases. He also warned against regarding Drools as a tool to solve all problems.

While Arno seems to be a really nice guy (from northern Germany I would guess) his presentation was a bit shaky… he sometimes was surrised by his slides, the beamer resolution was not really sharp (not his fault) and he didn’t want to take questions due to the room size (the room was barely 20% filled – but large). So all in all the presentation was okay but not the highlight I had hoped for as our final event. Next time, better luck.