Drools

Drools is an open-source Business Rule Management System (BRMS) and production rule engine built on the Java Virtual Machine. Since its creation in 2001, it has become the dominant rule engine in the Java enterprise ecosystem, allowing organizations to encode complex, frequently-changing business logic as declarative rules that can be managed independently of application code. Its foundation in the Rete algorithm — one of the most efficient approaches to rule matching — has made it the go-to choice for domains where decisions must be fast, auditable, and maintainable by people who are not necessarily software engineers.

History & Origins

Drools began in 2001 when Bob McWhirter registered the project on SourceForge with the goal of building a pure Java rule engine based on the Rete algorithm. Early versions (0.x and 1.x) were exploratory. The first significant milestone came in June 2005 when Drools 2.0 was released — the first major production-grade release and the project’s true public debut. Around this time, Mark Proctor took over as project lead, a role he has held continuously since.

The 2005 release coincided with Drools being adopted into the JBoss Enterprise Middleware System (JEMS), connecting it to the broader JBoss application server ecosystem and giving it enterprise reach. A year later, in 2006, Red Hat acquired JBoss, and Drools came along for the ride. This acquisition proved transformational: Red Hat’s resources accelerated development and eventually yielded a commercially supported product line (JBoss BRMS, later Red Hat Decision Manager) while the open-source core continued to evolve under community governance.

The Rete Algorithm Connection

Drools is fundamentally built on the Rete algorithm, originally described by Charles Forgy in his 1979 doctoral dissertation at Carnegie Mellon. Rete (Latin for “net”) constructs a network of nodes that efficiently matches rule conditions against working memory without re-evaluating unchanged data. Drools implements an enhanced variant called ReteOO — Rete for Object-Oriented systems — which extends the algorithm to work with Java objects as first-class facts. This lineage places Drools directly in the expert-system tradition alongside earlier Rete-based engines such as OPS5, CLIPS (developed at NASA), and Jess (a Java rule engine that predated Drools).

Design Philosophy

The central idea behind Drools is the separation of business logic from application code. In a traditional application, decision logic is scattered through conditional branches in Java classes, making it difficult to audit, modify, or hand off to domain experts. Drools inverts this: rules are authored in a dedicated language (DRL), loaded into a rule engine at runtime, and evaluated against a shared set of facts. The application code merely asserts facts into the engine and reacts to the consequences — it does not contain the decision logic itself.

This philosophy was shaped by decades of expert-system research. Systems like CLIPS and OPS5 demonstrated that rule engines could manage thousands of business policies efficiently, but they were not well integrated with mainstream enterprise platforms. Drools brought this capability into the Java world at a time when Java was the dominant enterprise language, and its adoption reflected a real need: large organizations in insurance, banking, and healthcare were maintaining business rules in spreadsheets, Word documents, and hard-coded Java, creating fragile, costly systems that broke whenever regulations changed.

The Drools Rule Language (DRL)

Rules are written in DRL (Drools Rule Language), a declarative text-based format that compiles to Java bytecode. Each rule has a name, a when clause (conditions matching facts in working memory), and a then clause (actions to execute when conditions are met):

package com.example.rules;

import com.example.model.LoanApplication;
import com.example.model.Applicant;

rule "Approve Standard Loan"
    when
        $app : LoanApplication(status == "PENDING", amount <= 50000)
        $applicant : Applicant(creditScore >= 700, annualIncome >= 40000)
    then
        $app.setStatus("APPROVED");
        $app.setApprovedAmount($app.getAmount());
        update($app);
end

rule "Flag High-Risk Application"
    when
        $app : LoanApplication(status == "PENDING")
        $applicant : Applicant(creditScore < 580)
    then
        $app.setStatus("REVIEW");
        $app.addFlag("LOW_CREDIT_SCORE");
        update($app);
end

The when clause uses pattern matching syntax to bind Java objects to variables (prefixed with $), and can express complex constraints including nested properties, collection membership, temporal relationships, and cross-object correlations. The then clause is plain Java code — any valid Java expression is legal, which makes integration with existing codebases straightforward.

Decision Tables

For rules that follow a tabular structure — many conditions varying across rows — Drools supports decision tables defined in spreadsheets (Excel or CSV format). A decision table represents a set of rules compactly, with columns mapping to condition and action templates and rows mapping to individual rule instances. This format is particularly accessible to business analysts who are comfortable with spreadsheets but not with code.

Key Features

Forward and Backward Chaining

Drools began as a purely forward-chaining engine: given a set of facts, it fires rules whose conditions match, potentially adding new facts or modifying existing ones, and continues until no more rules fire (the “inference cycle”). Starting with Drools 5, the engine also supports backward chaining in the style of Prolog — you can write queries that the engine will satisfy by working backwards from a goal, searching for supporting facts. This hybrid capability makes Drools suitable for both reactive rule execution and goal-driven reasoning.

Drools Fusion (Complex Event Processing)

Drools Fusion, introduced in the Drools 5.x series, extends the rule engine to handle event streams with temporal semantics. Where standard Drools works with static facts, Drools Fusion treats events as facts with timestamps, supports sliding time windows, and provides temporal operators (before, after, during, coincides, etc.) for expressing time-based correlations. This capability is aimed at scenarios like detecting patterns in financial transactions, monitoring network traffic, or correlating log events — domains where high volumes of events (potentially thousands per second, depending on hardware and rule complexity) must be evaluated against complex temporal rules.

KIE Ecosystem

Starting with Drools 6, the project was reorganized under the KIE (Knowledge Is Everything) umbrella, which unified three complementary projects:

• Drools — rules and decision management
• jBPM — business process management (workflows, BPMN)
• OptaPlanner (formerly Drools Planner) — constraint satisfaction and planning optimization (shift rostering, vehicle routing, scheduling)

These three engines share a common deployment infrastructure (KIE Server), a shared build system (KIE Maven integration), and a workbench UI (Business Central / KIE Workbench). An organization can use them independently or combine them: a process defined in jBPM can invoke a Drools decision service at a decision gateway, and OptaPlanner can use Drools to score solution candidates.

Stateful and Stateless Sessions

Drools offers two session modes. A stateful session maintains working memory across multiple rule firings — facts can be inserted, modified, and retracted, and the engine tracks which rules have fired. This is appropriate for complex, evolving scenarios where the decision depends on an accumulation of events or state changes. A stateless session evaluates a single snapshot of facts and returns results — simpler, with no retained state. Stateless sessions are commonly used for request-scoped decisions like loan approvals or pricing lookups.

Evolution and the Cloud-Native Turn

For most of its history, Drools was deployed as an embedded library inside Java EE or Spring applications, or as a standalone KIE Server instance. The rise of microservices and containerization created new demands: rule services needed to be independently deployable, cloud-native, and startable in milliseconds rather than seconds.

Kogito emerged as the answer. Announced by Red Hat as part of the Quarkus ecosystem, Kogito is a cloud-native realization of Drools and jBPM, designed for deployment on Kubernetes and Knative. Kogito uses GraalVM’s ahead-of-time compilation to produce native executables, reportedly reducing startup times from seconds to milliseconds and significantly lowering memory footprints compared to traditional JVM deployments. Rules authored in DRL or DMN (Decision Model and Notation) are compiled at build time rather than runtime, enabling near-instant cold starts. Kogito also introduced the concept of Rule Units, which encapsulate a set of rules with their input/output data into a cohesive, testable module — a significant architectural improvement over the traditional session-based API.

In January 2023, the KIE Community submitted the entire project — Drools, jBPM, and OptaPlanner — to the Apache Software Foundation for incubation as Apache KIE. This governance move reflects the maturity and community breadth of the project while ensuring its independence from any single vendor.

DMN: Standards-Based Decision Modeling

Alongside its native DRL format, Drools implements the Decision Model and Notation (DMN) standard published by the Object Management Group (OMG). DMN defines a graphical and textual notation for decision logic, including decision tables, decision requirements graphs, and the FEEL (Friendly Enough Expression Language) expression language. By supporting DMN, Drools enables organizations to model decisions using a vendor-neutral standard that tools from multiple vendors can consume — reducing lock-in and improving governance around business rule assets.

Current Status

Drools remains actively developed in 2025 under dual stewardship: Red Hat sponsors core development and publishes enterprise products (Red Hat Decision Manager, Red Hat Process Automation Manager), while the broader KIE Community maintains the open-source codebase under Apache incubation. The 8.x series is the current stable line, requiring JDK 11 or later. Release cadence is frequent, with point releases appearing throughout the year.

The Drools community spans a large Java enterprise user base, with the project continuing to see adoption in regulated industries where audit trails, rule versioning, and business-user accessibility are non-negotiable requirements.

Why Drools Matters

Drools represents something rare: a decades-old academic concept — the expert system and production rule engine — that found sustained, practical application in mainstream software development. Where most expert-system work from the 1980s remained in research labs, Drools succeeded by meeting Java enterprise developers on their own terms: Java objects as facts, Java in the then clause, Maven for builds, Spring or Java EE for integration.

Its influence on how enterprise software manages decision logic has been significant. The pattern of externalizing business rules into a managed, auditable, version-controlled rule store — separate from application deployment — is now considered best practice in heavily regulated domains. Drools pioneered this pattern in the Java world and continues to define the state of the art for open-source rule engine technology on the JVM.