From Drools to Kogito Rule Engine

You might have already heard of Kogito so you may want to learn more about it and how it compares with Drools Rule engine. In this tutorial we will learn what is the relation between these two Rule engines.

The Kogito project aims to bring the business automation suite to the cloud and precisely into the Kubernetes ecosystem. At the same time, Kogito does not attempt to replace Drools, but to bring it further. Drools is a fantastic high-performance, feature-rich open source rule engine and it has been used to create rule-based artificial intelligence. Kogito aims to use Drools core features but bring the following improvements:

  • Introduce advanced features such as Modular Rules which will play an important role in the future of Rule Engines
  • Make Drools and jBPM 100% cloud-native, and well-suited for serverless deployments, also by embracing the Quarkus framework
  • Advanced Code generation to create Endpoints from Rules

Kogito modular Rules

JBoss Drools already provides a way to partition a set of rules into knowledge bases. The knowledge bases can be composed together, in order to form a larger sets of rules. When a knowledge base is instantiated through a Session, rules are then put together in the Production Memory), and the Facts are all inserted together in the same working memory.

This model is quite powerful and simple at the same time: as a rule author, you can rely upon the rules you have written to realize complex flows of reasoning, without worrying about how and when they will trigger. It however lacks of a complex execution model: there is no proper notion of a module hence you cannot perfectly isolate one rule from another, or to properly partition the working memory. As the rule base increases in complexity, it will become harder and harder to understand which rules trigger and why.

Kogito introduces the concept of Rule unit, which is a module for rules and a unit of execution. A rule unit collects a set of rules with the declaration of the type of facts that the rules act on. A rule unit also serves as a unique namespace for each group of rules. A single rule base can contain multiple rule units.

Example:

package org.kie.kogito.rules.alerting
unit MonitoringService
rule IncomingEvent when
   // matches when a temperature higher than 30 °C is registered (OOPath syntax)
   $e : /events # Temperature[ value >= 30 ] // Temperature is an Event subclass
then
   System.out.println("incoming event: "+ $e.getMessage());
   alerts.append( new WarningHighTemperature($e) );
end

You interact with the rule unit through the Data sources it exposes. Data sources are typed sources of data that rule units can subscribe to for updates.

For example, the following is a basic example of DataStream Data source which appends a new values and notify all active subscribers:

DataStream<Temperature> temperature = DataSource.createStream();
temperature.append(new Temperature(100));

Kogito as Cloud Native solution

You can easily deploy Kogito services on OpenShift for cloud implementation. This makes Kogito services simple to scale up and down automatically to provide as few or as many containers as required for a particular service. There are several ways to deploy Kogito in OpenShift Paas:

  • Using Kogito Operator: This OpenShift operator (https://github.com/kiegroup/kogito-cloud-operator) guides you through the deployment process and automates many of the deployment steps for you. For example, when you give the operator a link to the Git repository that contains your application, the operator can automatically configure the components required to build your project from source and deploy the resulting services.
  • Kogito command-line interface (CLI): A CLI tool that enables you to interact with the Kogito Operator for deployment tasks. The Kogito CLI also enables you to deploy Kogito services from source instead of relying on custom resources and YAML files. You can use the Kogito CLI as a command-line alternative for deploying Kogito services without the OpenShift web console.
$ kogito deploy-service example-quarkus https://github.com/kiegroup/kogito-examples --context-dir kogito-example --project PROJECT_NAME
  • Deploy Kogito as part of a Cloud native framework: for example, you can deploy Kogito applications as Quarkus extensions and then simply leverage Quarkus ability to deploy your Process/Rules on the Cloud

Automatic Endpoint generation

One key feature of Kogito is ist ability to use the Java-based declaration of a rule unit to automatically map it with the signature of a REST endpoint. POSTing to the endpoint implies instantiating the unit, inserting data into the data sources, firing rules, returning the response payload. The response is computed using a user-provided query. For instance, consider this example from Drools examples:

package org.kie.kogito.queries;
unit LoanUnit;

import org.kie.kogito.queries.LoanApplication

rule SmallDepositApprove when
    $l: /loanApplications[ applicant.age >= 20, deposit < 1000, amount <= 2000 ]
then
    modify($l) { setApproved(true) };
end

rule SmallDepositReject when
    $l: /loanApplications[ applicant.age >= 20, deposit < 1000, amount > 2000 ]
then
    modify($l) { setApproved(false) };
end

rule LargeDepositApprove when
    $l: /loanApplications[ applicant.age >= 20, deposit >= 1000, amount <= maxAmount ]
then
    modify($l) { setApproved(true) };
end

rule LargeDepositReject when
    $l: /loanApplications[ applicant.age >= 20, deposit >= 1000, amount > maxAmount ]
then
    modify($l) { setApproved(false) };
end

rule NotAdultApplication when
    $l: /loanApplications[ applicant.age < 20 ]
then
    modify($l) { setApproved(false) };
end


query FindApproved
    $l: /loanApplications[ approved ]
end

query FindNotApprovedIdAndAmount
    /loanApplications[ !approved, $id: id, $amount : amount ]
end

When you include the above Rule unit in a Kogito project, a REST Endpoint will be automatically created for you to invoke each Rule with the right typed Parameters. Further more, as you can plug Swagger UI interface on the top of it, you already have an UI to test your Rules:

From Drools to Kogito

Summary

This was a brief introducion on how Kogito can bring further the capabilities of Drools engine. In the next tutorial we will show all the steps required to create a RESTful application by just designing Rules with the editor and adding them in a Kogito project.

Found the article helpful? if so please follow us on Socials