How to Write Rules Independently of the Execution Model

Samples > Rule-Based Programming > How to Write Rules Independently of the Execution Model

How to Write Rules Independently of the Execution Model

This sample shows how to use the Business Object Model (BOM) to Execution Object Model (XOM) mapping mechanism to isolate rules from the "physical" execution layer.

The same rules can sometimes be applied on different execution applications and platforms. For example:

Staged deployment with different execution classes
Dynamic model (XML based or dynamic classes) versus static model
Production/test models (active objects versus mock objects)

In this sample, a single BOM is mapped to two very different XOMs.

The BOM was initially designed for regular Java static classes and has been remapped to a model made of generic objects (also called synthetic, or dynamic objects) made of key-value properties, such as hash maps. The same BAL rules can be executed on the two execution layers.

The sample is derived from the engine > patternmatching sample (the Java XOM is shared, and the rules have been rewritten in BAL). The execution results are the same.

Key Features

Key features include:

BOM to XOM mapping and translation:

with execution class names
with extenders
with IRL code

Importing this Sample

To import the bom2xom sample:

Click File > Import.
In the Import Wizard, select ILOG Rule Studio Samples and Tutorials and click Next.
Select the samples > engine > bom2xom sample.
Click Finish.
If one or more files already exist in your workspace, a warning message is displayed indicating that the corresponding file(s) were not re-imported. Close the message window.

The imported sample project files are displayed in the Rule Explorer.

Running this Sample

Make sure that you are in the Rule Perspective before running this sample.

To prepare your environment for the sample:

Adjust the filter settings in the Rule Explorer so that BOM to XOM mapping files will be visible:

In the Rule Explorer, open the Filters menu.
Uncheck the BOM to XOM mapping files entry in the list of elements to exclude.
Click OK.

For this sample, it is also useful to have multiple consoles visible at once.

Click Windows > Preferences.
Select Run/Debug > Launching in the list of options and uncheck the Remove terminated launches when a new launch is created option.
Click OK.

To run the sample:

Click Run > Open Run Dialog.
Select the Rule Project > bom2xom-rules launch configuration and click Run.

This runs the sample with the XOM made of generic objects.

Note the way in which objects are displayed in the Console view:

type CashEvent accountID=AC1 amount=-120.0 parentID=null type=DEBIT currency=EUR ...

This format is the one implemented in the toString() method of the generic objects.

Expand the b2x > financialevent-xom folder in the Rule Explorer and copy the file financial.b2x to the bom folder.
Click OK to confirm replacement of the existing file.

The project rebuilds automatically.

Run the bom2xom-rules launch configuration again.

This time, the sample runs with the XOM made of Java regular objects.

Note the way objects are displayed in the Console view:

Type: DEBIT Date:...

This format is the one implemented in the toString() method of the financialevent xom objects.

If you have multiple consoles, you can switch between the two traces and compare the execution results.

Expand the bom2xom > generic-xom folder in the Rule Explorer and copy the file financial.b2x to the bom folder to revert to the initial configuration.
Click OK to confirm replacement of the existing file.

The project rebuilds automatically.

Run each launch configuration again, but this time in debug mode.
Step into the rules, into the BOM to XOM mapping translations, and finally into the Java XOM code.

You will see that the XOM code invoked in each run is different.

Highlights

The Java XOM is defined in financialevent-xom. The whole model is based on interfaces and implementation classes. The interfaces have been imported to create the BOM.

The generic XOM is defined in bom2xom-genericxom. It consists of three classes:

The GenericObject interface that describes the contract of a generic object. In contrast to a Map contract, it adds:

more typed accessors and mutators, such as getInt/setInt, getDouble/setDouble, etc.
support for unary and multiple references to other GenericObject instances.
a type system with getType() and isOfType(String) methods, to support object models with inheritance.

The GenericObjectImpl implementation of GenericObject:

This implementation delegates all the property manipulation to a HashMap.
Minimal type checking is performed.
The type system is delegated to the GenericObjectHelper described below.

The GenericObjectHelper helper class that implements the type system and creates generic objects:

It requires a GenericObject implementation class, for the creation of objects.
It creates the type system from a String array. Each String has the following format: subtype->supertype. The types are stored statically in this class, and are themselves instances of GenericObject.
It can read a model description in a model.properties file if the file is present in the classpath.

The generic XOM is completed by an adapter XOM, called bom2xom-extenderxom, which is specific to this sample and is defined in the bom2xom-extenderxom project. This provides an extender class for one of the BOM classes, and a model.properties that models the extension relationship between CashEvent and FinancialEvent classes.

As a generic object model does not support behavioral methods (that is, methods other than accessors and mutators), these methods are implemented either with:

IRL code. For example, see the Account.addBalance BOM methods.

Or:

An extender class from the bom2xom-extenderxom project. For example, see the EventDispatcher class: the exception and send methods are delegated to the DispatcherExtender class, with static methods.

As the Java XOM uses constructors to create objects, and the generic XOM requires the GenericObjectHelper 'static factory' to create objects, the choice has been to create static BOM 'create' methods on each BOM class. These methods are translated into calls to the appropriate constructors in the case of the Java XOM, and into calls to the GenericObjectHelper.create(String type) static method in the case of the generic XOM.

For the sake of simplicity, both configurations use utility classes for currency and date management that belong to the financialevent-xom XOM project. But these could have been different as well.

Related Concepts

BOM and XOM