1 Introduction

Drools is an open‑source business rule management system (BRMS) and rule engine originally developed by Red Hat (now a subsidiary of IBM). It provides a forward‑chaining inference engine based on the Rete algorithm, a production rule system, and a domain‑specific language (DSL) for writing business rules. Drools enables the separation of decision logic from application code, allowing non‑programmers to create and maintain rules. In addition to its core rule engine, Drools includes a complex event processing (CEP) engine, decision tables for spreadsheet‑based rule management, and a web‑based authoring environment (Drools Workbench). The platform is widely used in enterprise applications for automating decisions, validating compliance, and managing intelligent processes.

1.1 History and development

Drools began as a project by Bob McWhirter in 2001 under the name “Drools” (a play on “rules”). In 2003 it was acquired by Red Hat and became part of the JBoss middleware portfolio. Over the years the engine underwent major rewrites: Drools 5 introduced the Drools Flow (later merged into jBPM), Drools 6 adopted the “Kie” (Knowledge Is Everything) API and the Phreak algorithm for improved performance, and Drools 7 added strong support for CEP and decision model and notation (DMN). In 2020, following Red Hat’s acquisition by IBM, Drools continued as an open‑source project under the Apache License 2.0.

1.2 Key features

  • Rete‑based inference engine with forward and backward chaining.
  • DRL (Drools Rule Language) for writing declarative rules.
  • Decision tables (spreadsheet‑based and guided) for non‑developers.
  • Domain‑specific languages (DSL) that map natural‑language phrases to rule constructs.
  • Complex event processing (CEP) with temporal operators and event correlation.
  • Kie ecosystem: KieBase, KieSession, KieContainer, KieModule.
  • Drools Workbench (Business Central) for collaborative rule authoring and management.
  • Execution server for deploying rules as RESTful services.
  • Integration with Java, Spring, and other JVM languages.

1.3 Use cases

Typical applications include loan approval and credit scoring, insurance underwriting, fraud detection, healthcare eligibility checks, e‑commerce discount engines, compliance validation, and real‑time monitoring of sensor data or financial transactions. Drools is also employed in process‑automation platforms (e.g., jBPM) to govern decision gates and workflow branching.

2 Architecture

Drools’ architecture separates the rule definition and inference engine from application code. At its core is the Rete algorithm (or its successor, Phreak), which efficiently matches facts against rule conditions.

2.1 Rete algorithm

The Rete algorithm (from Latin “rete” meaning net) is a pattern‑matching algorithm designed to reduce the computational cost of rule evaluation. It builds a network of nodes representing conditions; when a fact is inserted into working memory, it propagates through the network, allowing the engine to avoid re‑evaluating all rules. Drools uses an enhanced version of Rete called ReteOO (object‑oriented), which handles Java objects natively.

2.2 Rule engine components

The rule engine consists of three primary components: working memory, production memory, and an agenda.

2.2.1 Working memory

Working memory holds the facts (data objects) that the engine reasons about. Facts are asserted, modified, or retracted by the application or by rule actions. The engine continuously updates its internal state as facts change.

2.2.2 Production memory

Production memory contains the rule definitions (productions). Each rule has a left‑hand side (conditions) and a right‑hand side (actions). When all conditions of a rule are satisfied by the facts in working memory, the rule is activated and placed on the agenda.

2.2.3 Agenda

The agenda is a priority‑ordered list (or conflict set) of activated rules. The engine selects the highest‑priority rule and fires it (executes its actions). This cycle continues until no more rules are activated or a halt condition is reached.

2.3 Inference engine types

2.3.1 Forward chaining

Forward chaining is the default inference mode. It starts with known facts and applies rules to infer new facts or trigger actions. Data‑driven scenarios, such as fraud detection or real‑time decisioning, benefit from this approach.

2.3.2 Backward chaining (Drools backward chaining module)

Backward chaining (goal‑driven reasoning) is supported via a dedicated module. Starting from a query goal, the engine works backward through rules to find facts that satisfy the goal. This is useful for diagnostic systems, tax calculators, and other scenarios where the answer is sought from a set of known rules.

3 Rule definition languages

Drools provides multiple ways to define rules, catering to both developers and business analysts.

3.1 DRL (Drools Rule Language)

DRL is the native text‑based rule language, similar in style to Java.

3.1.1 Rule syntax

A DRL rule has the structure:

rule "rule_name"
    when
        // conditions (left‑hand side)
    then
        // actions (right‑hand side)
end

Conditions use the when keyword and can reference fact types, field constraints, and logical combinations (and, or, not, exists). Actions are written in Java or MVEL (MVFLEX Expression Language) and can modify working memory, call external services, or halt the engine.

3.1.2 Conditional elements

DRL supports many conditional elements:

  • Patterns: Person( age > 18 )
  • not, exists, forall: absence, existence, universal quantification.
  • from, collect, accumulate: collecting facts from collections or aggregating values (sum, count, average).
  • OOPath: object‑oriented path expressions to navigate object graphs.

3.1.3 Actions

Actions are placed in the then section. Common actions include:

  • modify( $person ) { setAge( 30 ) } – modifies a fact and re‑evaluates dependent rules.
  • insert( new Result( ... ) ) – inserts a new fact.
  • retract( $person ) – removes a fact.
  • drools.halt() – stops further rule execution.
  • Calling Java methods or logging.

3.2 Decision tables

Decision tables allow rules to be defined in tabular form, which is easier for business users.

3.2.1 Spreadsheet‑based rules

Rules can be authored in Excel or LibreOffice Calc spreadsheets using a specific template. Each row represents a rule; columns define conditions and actions. The spreadsheet is converted into DRL at compile time. This format is popular for large sets of similar rules (e.g., pricing brackets).

3.2.2 Guided decision tables

Drools Workbench provides a web‑based guided decision table editor. Users define columns (conditions, actions) and fill rows without touching DRL. The editor supports validation, hit policies (first hit, all hits), and custom DSL phrases.

3.3 Domain-specific language (DSL)

DSLs let non‑technical users write rules in natural‑language approximations.

3.3.1 DSL definition

A DSL definition file maps a linguistic pattern to a DRL expression. For example:

[when]There is a Person with age greater than {age}=Person( age > {age} )
[then]Send email to {address}=sendEmail( "{address}" )

3.3.2 DSL mapping

When a rule is authored using a DSL, the engine expands the phrases into full DRL. This makes rules readable and maintainable by business analysts without programming knowledge. Multiple DSL files can be layered.

4 Complex event processing (CEP)

Drools’ CEP capabilities extend the rule engine to handle streams of events with temporal relationships.

4.1 Event concepts

Events are facts that have a timestamp and may have a duration. Drools treats events as first‑class objects.

4.1.1 Event types and attributes

Events can be declared in DRL using the declare keyword with metadata:

declare Transaction
    @role( event )
    @timestamp( timestamp )
    @duration( duration )
    amount : double
end

Attributes include @role(event), @timestamp, @duration, and @expires (for sliding windows).

4.1.2 Temporal operators

Drools supports temporal operators to correlate events over time:

  • after, before, coincides – relative ordering.
  • during, includes, overlaps – interval relationships.
  • finishes, started, metBy – fine‑grained interval relations.

Sliding windows (e.g., window:time(5m)) restrict the scope of event matching.

4.2 CEP use cases

4.2.1 Fraud detection

CEP rules can detect suspicious patterns such as “three transactions over $500 within 10 minutes from different locations” and trigger alerts in real time.

4.2.2 Real-time monitoring

Industrial IoT and network monitoring use CEP to watch for threshold crossings, sequence violations, or missing heartbeats, and execute corrective actions (e.g., sending alerts, starting backups).

5 Integration and deployment

Drools can be embedded in applications or deployed as a standalone service.

5.1 Java API and embedded mode

The simplest integration is via the KieServices factory, which builds a KieContainer from a classpath resource. The container creates KieSessions to fire rules. Applications insert facts, fire all rules, and retrieve results programmatically.

KieServices ks = KieServices.Factory.get();
KieContainer kContainer = ks.getKieClasspathContainer();
KieSession kSession = kContainer.newKieSession();
kSession.insert( new Person( "John", 25 ) );
kSession.fireAllRules();
kSession.dispose();

5.2 Kie (Knowledge Is Everything) ecosystem

The Kie API organises rule artifacts and provides runtime management.

5.2.1 KieBase and KieSession

  • KieBase: An in‑memory repository of all rule definitions, types, and functions. It is thread‑safe and can be shared across sessions.
  • KieSession: A single, stateful conversation with the engine. Inserts facts, fires rules, and maintains session‑specific working memory.

5.2.2 KieContainer and KieModule

  • KieModule: A packaged unit (e.g., a JAR) that contains rules, DSLs, decision tables, and a kmodule.xml descriptor.
  • KieContainer: Manages a KieModule and creates KieBase instances. It can load modules from the classpath, Maven repositories, or dynamic URLs.

5.3 Spring integration

Drools integrates with Spring via XML or Java configuration, often using the org.kie.spring module. Beans for KieContainer and KieSession can be declared, enabling dependency injection into services. Spring Boot starters are also available for rapid setup.

5.4 Drools Workbench (Business Central)

Business Central is a web‑based IDE for managing rules, decision tables, DSLs, and guided editors.

5.4.1 Authoring environment

Users can create and edit rules using guided editors, or upload DRL and spreadsheet files. The Workbench provides version control (Git), collaboration (comments, roles), and testing tools (scenario simulation). It also supports deployment to execution servers.

5.4.2 Execution server

The execution server (Kie Server) exposes Drools functionality as REST or JMS endpoints. Applications send facts and receive results via HTTP, allowing rule execution in a microservices architecture. The server can be embedded or deployed on application servers such as WildFly.

6 Performance and optimization

Drools offers several mechanisms to improve rule evaluation speed and memory usage.

6.1 Rule evaluation strategies

  • Sequential mode: Disables the agenda and fires rules in declaration order. Useful for offline processing where no dynamic activation is needed.
  • Passive vs. active evaluation: By default, the engine uses “passive” (fire‑all‑rules) semantics. Active (incremental) evaluation is available in stateful sessions.
  • Rule‑base indexing: Indexes on field values speed up pattern matching.

6.2 Phreak algorithm (Drools 6+)

Phreak replaces the classic Rete algorithm with a more memory‑efficient, lazy‑evaluation approach. It maintains a network of “path” nodes and only evaluates changes when facts are modified. Phreak reduces overhead in scenarios with large rule bases and infrequent updates.

6.3 Memory management

  • Object sharing: Facts are stored as references; the engine uses identity‑based equality to avoid duplication.
  • Fact expiration: In CEP, events can be automatically retracted after a sliding window or explicit expiration time.
  • Segmented memory: The engine partitions working memory into segments to reduce contention in multi‑session deployments.

6.4 Best practices for rule authors

  • Keep conditions simple; avoid deeply nested logical groups.
  • Use eval sparingly; prefer field constraints.
  • Prefer accumulate over multiple sequential rules.
  • Use salience or activation‑group to control rule priority.
  • Test with realistic data volumes to identify bottlenecks.

7 Comparison with other rule engines

Drools is often compared with commercial and open‑source alternatives.

7.1 ILog JRules (IBM ODM)

IBM Operational Decision Manager (ODM, formerly ILog JRules) is a commercial product with a rich rule authoring environment and enterprise support. It uses a different execution model (sequential ruleflow) and has stronger integration with IBM middleware. Drools is free and open‑source, with a larger community but less polished GUI tools.

7.2 Jess

Jess (Java Expert System Shell) was one of the first Java rule engines, also based on Rete. It is no longer actively maintained and is licensed under a restrictive license. Drools offers better performance, modern features (CEP, DSL), and active development.

7.3 Easy Rules

Easy Rules is a lightweight rule engine for simple “if‑then” scenarios. It lacks inference, CEP, and decision table support. Drools is more suitable for complex, performance‑sensitive enterprise rule systems.

8 Community and resources

Drools is supported by a vibrant open‑source community.

8.1 Documentation and tutorials

Official documentation covers installation, tutorials, and API references. The Drools Story (guide) and KIE‑specific documentation are available on the Red Hat Customer Portal and GitHub. Community blogs and YouTube channels provide additional learning material.

8.2 Mailing lists and forums

The Drools mailing list (drools‑user) and Stack Overflow tag (drools) are active. Users ask questions about rule syntax, performance tuning, and integration issues. The JBoss Community forum also hosts discussions.

8.3 Contributing to Drools

Contributions are welcome via GitHub pull requests. The project uses JIRA for issue tracking, builds with Maven, and requires code adherence to community standards. New contributors can start with easy issues labelled “newbie” or “help wanted”.

9 Future directions

Drools continues to evolve with industry trends.

9.1 Drools 8 and beyond

Drools 8 (released in 2021) marked a major refactoring, aligning with the Kogito ecosystem for cloud‑native decisions. Future versions are expected to further optimise the Phreak algorithm, improve DMN support, and enhance the Workbench user experience.

9.2 Integration with cloud and microservices

The Kogito project (incubated under the same umbrella) trans compiles Drools rules to native executables using GraalVM. This allows rule execution as lightweight, serverless functions that scale on Kubernetes. Integration with Quarkus and Spring Boot remains a priority.

9.3 Machine learning integration (decision model and notation)

Drools already supports DMN (Decision Model and Notation) for modelling decisions graphically. Future releases may incorporate tighter coupling with machine‑learning models (e.g., PMML, TensorFlow) to allow hybrid rule‑ML decision logic. The aim is to provide a unified framework for both deterministic rules and predictive models.