Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Business process automation made easy with Java, Part 2

Design options for rule engine integration

By Ahmed Abulsorour and Siva Visveswaran, JavaWorld.com, 10/18/02

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:

  • Integrating the external engine with a business tier
  • Selecting the appropriate deployment method and communication protocols between them


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:"



Rule engine integration design options

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.

Synchronous invocations

As explained earlier, using the suggested MVC design implies synchronous event execution from the Web tier. As shown in Figure 1, the EJBAction component implements the business logic that may or may not require rules execution. Therefore, in case the need for rules execution arises, 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.

Resources