Architecture of a Business Rule Application

Welcome to ILOG JRules > Getting Started > ILOG JRules Architecture Guidelines > Architecture of a Business Rule Application

Architecture of a Business Rule Application

PREVIOUS NEXT

JRules BRMS allows you to manage business rules independently from the application logic, and to enable business users to manage these business rules.

Business rule application development consists in putting in place the infrastructure necessary for editing rules, and producing one or several rulesets.

The ruleset is a standalone and executable container that corresponds to a decision. Rules are atomic expressions of policies, and the automation of these policies and their application to events can generate decisions. Rules pertaining to a given decision are organized for execution and stored in the ruleset.

Using Rule Studio, you develop rule projects from which you extract rulesets.

A BRMS enables the business logic to be written in business terms, rather than in programming language terms. To this end, you create a Business Object Model (BOM) that describes the data on which your decision is based, and assign it a natural language vocabulary. All elements of the decision can then be written in terms of this vocabulary.

In order for your application to take advantage of this decision written in terms of the vocabulary, there must be a contract between the application and ruleset. In the simplest case this contract consists of two primary elements:

A mapping from the BOM to your application environment's Java objects or XML schemas. These objects or schemas are called the Execution Object Model (XOM). The mapping allows data that your application manipulates in the form of native Java objects or XML to be reasoned upon by the ruleset written in terms of the BOM. In the simplest case, the BOM can be the same as the XOM. In more complex cases, however, you need to provide an explicit BOM to XOM mapping.
A set of input and output parameters describing the data you pass to the ruleset and the data you expect to receive back in terms of the BOM. Through the BOM to XOM mapping, these data elements are provided from and to your application in the form of the XOM, but reasoned on by the rules in terms of the vocabulary and BOM.

Once the ruleset contract has been established, you have several options for invoking the ruleset from your application:

You can host the ruleset on Rule Execution Server. In this case you can invoke the ruleset from your application code using either a plain Java interface, or local EJBs. Or, you may invoke the ruleset from a remote Java Virtual Machine (JVM) using remote EJBs or asynchronously using message driven beans. JRules provides prewritten components for all four of these options. In addition, JRules includes tools that make it easy to expose a ruleset as a Web Service. Hosting the decision in Rule Execution Server is the preferred option as it gives you maximum flexibility in managing the rulesets.
You can host the ruleset as a transparent decision service, for invocation through Web service protocols.
You can embed the invocation into your application and interact directly with the rule engine. In this case, the ruleset must be packaged as a standalone ruleset archive.
You can deploy the ruleset to a test environment to perform test and simulation using Rule Scenario Manager.

To put business users in control of the business logic, you publish rule projects to Rule Team Server. Rule Team Server is a JRules module that provides a database for storing rule projects, and a Web-based interface to enable business users to edit and manage rule project contents. A user with the appropriate rights may also extract rulesets from Rule Team Server and deploy them to your application.

Architecture of a Business Rule Application

Related Concepts

Related Tasks

Related Reference