In Rule Studio, rule projects that contain the business logic are managed separately from Java projects. Rule projects contain all artifacts related to rule writing and ruleset creation. Rule projects can reference each other like Java projects. For example, this is a good way to share a common model between several projects implementing different decisions, or to manage commonly-used rules in a project. A project that references another can see and use all elements from this project. A ruleset can come from a single project, or from a top-level rule project that references other rule projects.

Rule Studio provides rule project templates that set a predefined structure for the rule project contents.

Specifying the Objects to be Manipulated by the Ruleset

Ruleset parameters specify the objects to be manipulated by the ruleset. They also define the interface between the business rules and the calling client. They specify the types (XML or Java) expected as input, and the types produced as output by the ruleset. The input data defines the data that is available to the rule engine for processing, while the output data contains the results of rule processing.

For example, if your decision applies to a borrower and a loan, and as a result provides information about the status of the loan, you define two parameters: borrower and loan. By providing a verbalization to the ruleset parameters, you make them available in the vocabulary for editing business rules.

Defining the ruleset parameters involves close collaboration between business users (including business analysts) and software architects. The business users must have the data required by the business policy available, while the architects must ensure that the data can be retrieved efficiently and must understand the required inputs for invoking the ruleset, and the data available after execution is complete.

A change to the ruleset parameters can be disruptive to calling applications as it may require client code changes to make additional input data available or to process additional output conclusions. However, version management capabilities, such as those provided by Rule Execution Server, can help to manage changes in rules while maintaining compatibility with existing clients.

Defining the Entities Upon Which you Write Rules

In order to write business rules, you first need to set up the model upon which they apply. You define this model as a Business Object Model (BOM) in Rule Studio. The BOM is a logical model of your business domain.

For example, if policy managers in a bank want to write business rules about how loans are granted to candidate borrowers, the BOM would contain a class Borrower with a creditScore attribute, and a class Loan.

Creating a Natural Language Layer on Top of the Business Object Model

To make the BOM understandable to business users, you verbalize it, that is, you attach natural-language terms and phrases to the classes and methods in the BOM. The complete set of terms and phrases available to write rules is called the vocabulary. Think of the vocabulary as a near natural language verbalization of the formal concepts and data elements in your business model. The vocabulary enables business users to write business rules in a near-natural language.

For example, if the BOM contains an attribute creditScore on class Borrower, the vocabulary will contain two phrases {the credit score} of {a borrower} and set the credit score of {a borrower} to {a number}.

Implementing the Physical Model Upon Which the Rules Execute

So that the vocabulary has an executable base, the BOM must be mapped to a physical data model. This data model is called the Execution Object Model (XOM). Every BOM element used in a rule must have a corresponding XOM implementation, but it does not have to be a simple one-to-one mapping. You can create more complex BOM to XOM mappings, such as combining information from multiple XOM properties into one BOM element.

You can implement the XOM as a Java object model, or an XML schema (XSD). If your XOM is a Java object model, you can work on it as a Java project in Rule Studio. If your XOM is an XML schema, JRules can process schema-typed XML data using business rules without code generation. This dynamic deployment option is loosely coupled, because only the XML Schema is shared between the client and the rules, and is useful for applications that process XML. You can also use the JRules to .NET tool to develop a mapping to a .NET CLR (Common Language Runtime).

For example, the two classes Borrower and Loan in the BOM are implemented as Java classes in the XOM.

Related Concepts

Related Tasks