We have covered all the important aspects of using Drools as a rule engine. We've explored stateless and stateful Kie Sessions and interaction with business processes, and seen how complex event processing is managed. The last step we need to take is to understand the different ways Drools can interact with the rest of our application.
Drools is a framework; as such, it can interact with other frameworks in as many ways as we can imagine. In the next sections, we will discuss some of the most common design and architecture approaches to integrating Drools with the rest of our design, including some pros and cons for each approach. We will cover an in-detail explanation of:
- Types of Drools integration and architecture considerations
- How to integrate Drools with popular integration frameworks such as Spring and Camel
- Available examples of integrations, such as the Kie Server
The first thing we will need to address when designing how Drools should interact with the rest of our application components is how they will fit in the overall architecture; we will have specific requirements regarding how data will be fed into the rule engine, either from our own application or from external sources. Also, we must decide how information should be published back to our application from the rule engine, or how it should be exposed to external applications. We've already seen many mechanisms throughout previous chapters to communicate between Drools and the rest of the application (to name a few):
- We can use global variables to send and receive information outside the Kie Session, and to communicate with different systems. These global variables could represent any Java component, from simple lists, to database accessors, to web service client stubs, allowing the session to communicate with any part of our infrastructure.
- We can use entry points to identify different sources of information Drools will receive facts and events from. In our application, we could use each entry point in a different endpoint that communicates with our Kie Sessions.
- We can register channels to send new information inferred from the Drools runtime out to any other component. Registering listener-like classes, we can send information about specific domain situations.
- We can use any of the pluggable components to detect changes in the status of information inside the working memory (from event listeners to object marshalling strategies) to publish information about our Kie Session to any form of data source. Later on, other services can be built to query those data sources.
Also, we need to decide whether or not our rules should be running in a discrete or continuous fashion, based on the necessities of our domain logic. We will discuss this case in the next subsection.
As we discussed in Chapter 6, Complex Event Processing, we might have situations where the absence of input data on a Drools runtime might trigger a rule. For such cases, asynchronous management of rule execution is required. Even if this is not the case, we might still design our application as a set of asynchronous components connected through a common messaging bus, such as JMS, and still need to manage our rules in a way that accommodates asynchronous management.
If we need to execute our business rules in a synchronous manner, we can take a series of actions to simplify integrating our rule execution to our application, including:
- Using stateless Kie Sessions, if keeping state between rule executions is not something we need to worry about. If you do this, you can create as many Kie Sessions as potential service requests.
- Use global variables to store specific rule execution information. Since we will invoke
fireAllRulesafter the insertion of new data, we can get the rule execution information that might modify a global variable, and expose it in the response.
If we need to execute our business rules in an asynchronous manner, we need to take care of a few other things:
- Kie Sessions may be shared between different threads, because some of them may insert new information and others might take care of firing rules (that is, using
fireUntilHalt). - If rule execution is delayed to a different thread, we need to think about our rules in such a way that they notify special cases to other parts of the application, also asynchronously. One way to accomplish this would be to register special listeners as global variables that take care of notifying other components about special situations detected by the rules, instead of using lists of data as global variables to store information deferred to after rule execution. This is mainly because rule execution will not cease for rule-firing threads.
- Entry points become a very useful component when multiple sources will be inserting information into a single Kie Session, since it lets the rules easily identify the source of the information.
These considerations will be affecting the full structure of our application, and not just the Drools runtime. The purpose of this discussion of common practices used in Drools asynchronous and synchronous uses is just to understand that we can adapt to any situation we design our applications to handle.
Once we take care of these considerations, we might start considering how the Drools runtime will be deployed along with the rest of our application.