data-contexts.adoc

Data Contexts

We propose an alternative way to define RuleUnitData classes, which is more flexible and should work better in the long run.

Current Status

In Kogito/Drools a RuleUnit is defined by declaring a RuleUnitData implementation:

public class Person implements RuleUnitData {
    String name;
    int age;
    DataSource<Address> addresses;
}

This generates a few files, including a REST endpoint accepting the payload:

{
    "name": "John",
    "age": 40,
    "addresses": [...]
}

i.e. the JSON serialization of Person. The expected JSON payload is automatically adapted so that the DataSource field pulls data from a JSON Array.

Proposal

We introduce the Context or Data Context term. A Context is equivalent to a RuleUnitData, in that it defines the way data is provided to a runtime.

We specify where data is pulled from by annotating the class or the fields in the class (strawman syntax):

@DataSource(type=HTTP)
public class Person implements Context {
    String name;
    int age;
    List<Address> address;
}

Meaning that the source of data (an HTTP endpoint) will produce a Person instance, that will be fed into the rule engine. Rules will handle the name, age and address fields. This is effectively equivalent to what we have now in Kogito.

But we can support other types of data sources:

@DataSource(type=KAFKA)
public class People implements Context {
    String name;
    int age;
    List<Address> address;
}

Moreover, this syntax scales better in the presence of many data sources.

In the presence of multiple DataSource declarations, we are implicitly declaring that the RuleUnit must survive to multiple requests to make sense; e.g.:

public class MonitoringService implements Context {
    @DataSource(type=HTTP) DataSource<Sensor> sensors;
    @DataSource(type=KAFKA) DataSource<Alert> alerts;
}

In other words, the case when the class is annotated as @DataSource may default to the stateless use case, while the case with multiple @DataSource fields would default to stateful.

We should also deprecate the usage of DataSource<T> fields when the intended use case is stateless, and instead use List<T>. ^[1]

Writing The Result

In the simplest case:

@DataSource(type=KAFKA)
public class People implements Context {
    String name;
    int age;
    List<Address> address;
}

Provided that the user has defined a query; e.g.:

query some_result
   /address[ street == "main" ]
end

the result of the query could be pushed to a kafka topic named after the query itself (in this case "some_result") — similarly to how processes in Kogito handle Kafka messages.

---

1. we can optimize the from node to a real entry point internally.