Drools CEP features are really powerful and are as quick to resolve decisions as any other type of Drools-based rules. However, it has a few architectural elements that we need to be aware of in order to make the most of it.
First of all, all Kie Sessions operate in memory. This means that all events living inside a Kie Session have to be in memory while they are still relevant to at least one rule in its Kie Base. This can be overcome by the @expires annotation of an event type, but it will still require to plan ahead for the amount of memory required to define a Drools CEP service. One quick way of determining how much memory a server will need to run a Drools CEP scenario is as follows:
- Determine how long each event instance should be present in the Kie Session (because it might still be used in triggering a rule). Let's call this value A.
- Determine how many events can be received in a specific period of time. Let's call this value B.
- Determine how big an event instance is (using any Java profiler tool such as JProfiler available at https://www.ej-technologies.com/download/jprofiler/files). Let's call this value C.
A times B times C equals X, a very rough estimate of the minimal amount of memory required by the Kie Session only to keep the reference of all live events. We'll need to be careful though as we're still not considering the memory consumption of storing interrelations between events provoked by rule conditions and the Beta network. We'll discuss these topics in more detail in Chapter 9, Introduction to PHREAK.
Another limitation to take into account involves the possibility of storing the Kie Session in any persistence mechanism (something that we will discuss in Chapter 10, Integrating Rules and Processes). The KIE Session is usually persisted when something changes in its internal representation, whether it is the working memory or its matching agenda. For the case of a regular CEP scenario, this might mean storing all the working memory data every time a rule fires or a new event is inserted. Doing so with a CEP-based KIE Session could mean as much as gigabytes of data being stored multiple times per second. Therefore, other mechanisms for replicating a Kie Session in another system are required.
Currently, the only methods available for replicating a CEP-based Kie Session involve replicating small deltas between Kie sessions (as to not have to replicate the whole working memory) and coordination strategies for firing the rules (so that only one of the replicated Kie Sessions actually fires the rules for the replicated matching data). These are custom mechanisms and each user should implement their own at their own risk, therefore, the suggested alternative is to break down the CEP scenarios by domain and have different servers handle only a subgroup of cases.
To do so, usually the first step is to filter the events by type or specific components in its data and forward it to the specific Kie Sessions that take care of managing a specific scenario at a time.
To name an example, all the fraud detection cases from small providers are handled in a server and fraud detection for two large providers could be done in two dedicated servers. Even the filtering could be a Kie Stateless session, created to redirect each event to its corresponding Kie Stateful session, as shown in the following diagram:
In this way, an increase in the event throughput can be achieved within a Drools CEP Session and handled (at least to some extent) by adding additional servers.