Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
The key benefits of abstracting a rule engine tier from the business object layer are: independent rules maintenance by business users, rules reuse across business objects, and reuse across multiple business contexts by multiple systems. This abstraction is a two-step process that involves:
In Part 1, we looked at the first step. In this article, we study the second step. We present different methods for rule engine deployment (e.g., stateful versus stateless) and determine the best options for specific situations. In Part 1, we introduced the Java Rule Engine API (Java Specification Request (JSR) 94) that provides a uniform mechanism to access rule engine services. Now we present emerging data interchange standards such as the Simple Rule Markup Language (SRML) that allow vendor independence in rules development.
Read the whole series, "Business Process Automation Made Easy with Java:"
In this section, we discuss two main options to integrate a rule engine product with a Model-View-Controller (MVC)-based J2EE (Java 2 Platform, Enterprise Edition) Web application. The integration options are based on the engine's invocation mechanism—synchronous or asynchronous. The view's main requirement is synchronization with the model so that data displayed to the user is up to date. Based on the Observer pattern, the model acts as the subject, and the view acts as the observer. Synchronization can be achieved by using a push mechanism, where the view listens for change notification in the model, or a pull mechanism, where the view calls the model to get updated data whenever required, as in a Struts framework.
Figure 1 shows the proposed design for the two integration options. The integration tier is abstracted in this figure to the rule engine controller, and the adapter as explained in Part 1. The pattern's main advantage is loose coupling between the application modules and the rule engine technology used in the back end.
Figure 1. Rule engine integration architecture. Click on thumbnail to view full-size image.
As explained earlier, using the suggested MVC design implies synchronous event execution from the Web tier. As shown in Figure
EJBAction component implements the business logic that may or may not require rules execution. Therefore, in case the need for rules
EJBAction invokes the
RulesController for that purpose. As a result of invoking the
RulesController, a rule session object is created and initialized with the required objects (facts) from the model that are needed by the
rules set to execute. The initialization objects are obtained by calling the corresponding EJBs (business components) and
usually represent a snapshot of the data each EJB represents at the time of invocation. The session object is sent to the
rules adapter that abstracts the proprietary Java Rule Engine API from the controller implementation. The adapter extracts
the facts from the session, initializes the rule engine with them, then loads the requested rules set from a cache (compiled
rules set), and fires the rules.