OOPSLA-98 Mid-Year Conference

Denver, Co. July 19-21, 1998

Using Rule Systems within Insurance Industry

Introduction

The Equitable Insurance Company and EDS has been developing an object-oriented rule engine and rule editor system to support a life insurance new business application. The rule engine and rule editor supports the technical requirements of the insurance industry, as well as many other industries, of:

1. Separating the domain rules for the application logic

2. Providing the ability to implement changes quickly into the domain rules without changing the application logic

3. Providing the ability for the Domain Experts to defined and maintain the business rules

During the development of the rule engine and rule editor, the concept of packaging rules for specific applications and versions of applications has evolved to provide significant functionality required to support the needs of the Rule System and supporting applications. O-O has provided the foundation to enhance the rule engine and rule editor smoothly through the constantly changing requirements.

We would like to focus our discussion on the rule packaging functionality of our system.

Brief discussion of Rule System/Rule Editor/Rule Packaging

The overall system architect is a three-tiered client/server environment consisting of a GUI front-end, processing/workflow component, rule engine, rule repository and a rule editor.

The processing component handles:

· communicating to a client GUI for data entry and display of rule results

· communicating to the rules engine to execute rules and retrieve rule results

· communicating to a RDBMS to save and retrieve application data

The rule engine component handles:

· retrieving rules from the rule repository

· executing rules based on data communicated via the processing component

· communicating rule results to the processing component

The rule repository component handles:

· saving and retrieving rule objects via an OODBMS

The rule editor component handles:

· creating and modifying domain and rule objects

· creating and modifying application specific rule results associated with each rule

· creating and modifying rule packages for a specific application

Application Environment

Rule Object "Make-up"

Domain rules are defined for the rule system, via a GUI Rule Editor application, independent of the specific applications. Rule objects are generated for the particular business logic and saved along with the corresponding Rule API object required by the calling application code.

The rules generated from the Rule Editor consists of 3 parts:

· Rule object(s) containing the logic of the domain rule

· Rule API object containing the interface protocol, required by the Rule Engine, to communicate the required data to the Processing component

· Rule Result object(s) containing the domain outcome of executing the rule object(s).

Rule Objects

Rule Packaging

A Rule Package identifies the individual rules that are available for execution by a given application. The Rule Package provides the ability to:

1. Organize the rules available to an application via the Rule Editor GUI

2. Identify the version of a rule available to the application (dynamic or static)

3. Assign different rule results for a given rule based on application

The appropriate rule objects are retrieved from the OODBMS, along with the corresponding domain objects required by the rules. The Rule Package frees the Domain Expert to create rules and domain objects without concern for how the application(s) will use the results of each rule. The Rule Package will guarantee completeness of the rules in a given package, such that any rules that are dependent of other rules are automatically included.

The Rule Package provides the capability of identifying application specific actions to be taken based on the result of executing a rule. Since packages are generated for specific applications, the result of a business rule being executed can be captured and the application specific rule result can be returned to the calling application. This is very useful when different applications execute the same rule but require a different error messages or different workflow actions to be triggered.

Rule Package Objects