Understanding the Business Object Model (or BOM as it is affectionately known) is one of the keys to using JRules effectively. In this entry I hope to lay some groundwork for subsequent more in-depth entries on the Vocabulary, Executable Object Models and B2X mapping.
The BOM defines the “entities”, “classes”, “types”, or “concepts” (”things”) that you want to write rules about. It is a powerful and expressive object model in its own right, heavily influenced by the capabilities of the Java object model, but also with features from XML Schema and with annotations to describe domains.
The BOM is serialized into a .bom file using a plain text serialization that looks very similar to Java-style class definitions. For example, if you create a “Hello World” rule project using the Rule Project Wizard and then open the generated BOM in a text editor you will see:
property uuid "_L9byoE4CEd2KE6Zi_qxKvw"
package helloworld;
public class Clock
{
public static readonly ilog.rules.brl.Time currentTime;
}
The syntax should be pretty familiar to most developers. Note that ilog.rules.brl.Time is another BOM class, defined in the JRules System BOM. The System BOM defines the base classes and primitives that are automatically imported into a user application BOM.
BOM classes are namespaced using package declarations, and aggregated within a BOM Entry. BOM Entries are referenced from a Rule Project’s BOM Path. All the BOM classes from all the BOM Entries on the BOM Path are available to a Rule Project. The analogy with Java classes, packages, JARs and the classpath should be obvious.
Before the BOM can be used to author Business Action Language if-then-else rules or decision tables/trees it must be verbalized. The process of verbalization generates human-readable phrases for the classes, attributes and methods in the BOM. The verbalized BOM is expressed as a Vocabulary which is serialized into a .voc file. For the Hello World project the .voc file looks like this:
# Vocabulary Properties
uuid = _L9akgE4CEd2KE6Zi_qxKvw
helloworld.Clock.currentTime#phrase.navigation = the current time
I.e. the phrase “the current time” has been associated with the static attribute helloworld.Clock.currentTime.
BOM classes create vocabulary Terms while BOM attributes/methods create vocabulary Phrases. The diagram below shows how the text within a Business Rule is first related to the vocabulary, which is mapped onto a BOM.
One key point to keep in mind is that the BOM is locale independent — it is an object model created for rule authoring purposes. The vocabulary on the other-hand is locale specific as it contains human-readable text. You can create different vocabularies for the same BOM, allowing you to define how rules should look in English, French or Chinese for example.
A BOM is typically created though a “bottom-up” design process: Java classes or XML Schemas are created by the development team defining the Executable Object Model (XOM). A BOM Entry is then generated from the classes or complex types in the XOM. It is then a simple matter to verbalize the BOM to create a Vocabulary and start writing rules. Because the BOM was generated from a XOM, the rules will be directly executable, using instances of the types defined within the XOM as the source of data for the rule engine.
An alternative use case is to define the BOM using a “top-down” design process - creating the classes within the BOM independent of the XOM. Additional work is then typically required to map the BOM to a XOM for use during execution. This mapping declaration is defined in a B2X file which I will return to in a later post.
The BOM is represented and manipulated using the classes in the ilog.rules.bom package. For example, using the API it is possible to create a BOM from an external data source, such as database tables, UML diagram or even a structured requirements document.
Conclusions
The BOM serves several important purposes:
- Defines a locale independent object model describing the “things” you want to write rules about.
- Often the BOM is a simplified and flattened version of the XOM specifically tuned to the requirements of rule authors.
- Provides the foundation for defining a vocabulary, the locale specific expression of how you want to verbalize the BOM for a single language.
- Maps onto an Executable Object Model, which will be used during the execution of the rules. As such it serves as a bridge model between the requirements of rule authoring and rule execution.
- Allows the XOM to evolve independent of the BOM — the Java classes within the XOM may be subject to a traditional development process, with a controlled impact on the business rules.
- Enables rule authoring and maintenance to be performed in environments without the XOM accessible, such as within Rule Team Server.
- During rule testing using Rule Scenario Manager, rules are executed directly upon the BOM, and instances of BOM classes can be created from rows in Excel spreadsheets.
This post has only scraped the surface of the capabilities of the BOM, XOM, Vocabulary and B2X. I aim to drill down into some of the details in subsequent posts. Stay tuned!
