Overview: Decision Server Rules

Decision Server provides development and runtime components for a rule-based solution that automates the response of highly variable decisions required by client applications.
  • Rule Designer is an Eclipse-based development environment in which you design, author, test, and deploy decision services.
  • Rule Execution Server provides the runtime environment for running and monitoring decision services.

At the core of a rule-based solution, you have a client application requesting a decision from a decision service. There can be many decision points required of the decision service by the client application. At each decision point, business rules packaged as rulesets are used to express policies for how decisions are made. A decision service is deployed to Rule Execution Server as a RuleApp. Each RuleApp contains one or more rulesets, each corresponding to a decision.

The following diagram illustrates how the different components interact:

Diagram shows Decision Server components.
Note: Decision Server also interacts with Decision Center, which includes a rule repository and collaborative web consoles for business users to author, manage, validate, and deploy decision services (see Overview: Decision Center.)

The design and development phases of decision services are managed through rule projects. A decision service project is the recommended unit of rule management, since it allows for complex decisions that involve several rule projects to be grouped as one entity. Synchronization, branching, and change management are applied to all rule projects in the decision service hierarchy, allowing the decision service behavior to be governed and deployed consistently.

You can also manage your rules in classic rule projects. The two approaches share features but manage them in different ways. The following table lists features and how they are handled in the two approaches.

Feature Classic rule project Decision service
Project hierarchy Standard rule projects Main and standard rule projects
Ruleset definition Rule project properties Decision operations
Branch management Project Project hierarchy
Release management Through branches or customization Decision governance framework
Synchronization Rule artifacts only Rule artifacts and deployment configurations
Deprecated feature:

Deprecation icon Classic rule projects are deprecated in V8.8.0. This feature will be removed in a future release of the product. See Deprecated features for migration details.


In Rule Designer, you design the granularity of your decision service and the contract with the client application. You also design the model and vocabulary for authoring business rules.

Designing involves putting in place the necessary infrastructure for editing rules and producing one or several rulesets.
  • You define the set of business rules that are put together as one executable decision unit called a ruleset. The ruleset uses input and output parameters to pass data to and from the client application. You define each ruleset and its parameters with a unique signature of input and output parameters. In decision services, you create decision operations, which defines the content and signature of the ruleset. Because you can use the same rule projects and packages for different decision operations, a decision service can easily change as new decision points requiring different signatures are added.
  • You define the vocabulary that is used in business rules. In Rule Designer, you develop the business object model (BOM) which defines the elements and relationships in the vocabulary. You can define the vocabulary by mapping the BOM to the Execution Object Model (XOM). You can also create the vocabulary by generating the BOM from the XOM, and then configuring the business vocabulary from the BOM.
  • You set up a rule project hierarchy. A rule project is a type of Eclipse project that is dedicated to the development of rule applications. With decision services, a main rule project is designed to be the top-level project, which allows the decision service behavior to be governed and deployed consistently.
  • In the rule projects, you organize rule packages for storing business rules and define a ruleflow to specify their flow of execution.
  • You define properties for managing and tracking business rules, by using rule model extensions.
  • You set up business user validation tools, by configuring and customizing tests and simulations.


If you are responsible for creating and managing the rules, you might author most of the business rules in the project. If business users are responsible for creating and managing the rules, you set up tools to facilitate rule authoring for them. You can create the different types of business rules, mainly action rules and decision tables. These business rules are all based on the Business Action Language (BAL), which is designed to look like natural language. In addition, you can create technical rules, which are based on the ILOG® Rule Language (IRL) and require programming skills.

As part of authoring, you can also:
  • Define vocabulary categories to filter the vocabulary elements that are available when you author business rules.
  • Create rule authoring extensions. You can use these extensions to integrate value editors for specific vocabulary elements, or to define dynamic domains that retrieve values from a data source.
Category Topic
Learn more

Authoring business rules

Follow a tutorial

Tutorial: Editing decision tables

View a sample

Authoring extensions samples


You debug a ruleset in Rule Designer.
  • You debug the ruleset by using an embedded rule engine to manage rule execution.
  • You analyze rules by using constrained semantic queries, which check the consistency and completeness of individual rules and of the ruleset as a whole.


In Rule Designer you prepare the capability for business users to run tests and simulations in Decision Center.


You integrate the client application from Rule Designer.

After the ruleset contract is established, you host the ruleset on Rule Execution Server and call the ruleset from the client application. Rule Execution Server is a managed, monitored execution environment for deployed business rules. Rule Execution Server handles the creation, pooling, and management of ruleset instances so that client applications can call the resulting decisions as easily as possible.

You call the ruleset from the client application code in one of the following ways:
  • A plain Java™ interface.

  • Local EJBs.

  • A remote Java virtual machine (JVM) that uses remote EJBs.

  • Message-driven beans (asynchronously).

  • You can host the ruleset as a transparent decision service to be called through web service protocols.

Decision Server provides components for each option.


A RuleApp defines a group of rulesets that are deployed together. The RuleApp also contains the input and output parameters that represent the contract with the client application, and the ruleset path needed by the client application to identify rulesets and their versions.

When a decision service or classic rule project is fully validated and approved, you can deploy to Rule Execution Server for use in a production environment. You can deploy from Rule Designer or Decision Center. If you are using classic rule projects, Decision Center does not apply versions to RuleApps, and there is no governance over who can change RuleApps.

The features that enable deployment are different depending on whether you use decision services or classic rule projects.

With decision services, you deploy by using a deployment configuration, which defines what to assemble in a RuleApp and where to deploy it. A deployment configuration can reference one or more decision operations. A decision operation includes all the settings needed to produce a ruleset: input and output parameters, main ruleflow, and any rule extraction. The deployment configuration is similar to the RuleApp definition for classic rule projects, but it is an artifact that can be synchronized with Decision Center and subject to change management and governance in the Business console.

The following table lists deployment features and how they are handled by the two approaches.

Feature Classic rule project Decision service
Deployment definition RuleApp Deployment configuration
Deployment version Managed by administrators in RuleApps Defined in deployment configuration
Deployment targets Selected at deployment time Defined in deployment configuration
Deployment options Rule Designer and Decision Center Enterprise console Rule Designer and Decision Center Business console
Deployment history Found in Rule Execution Server Audit trail in Decision Center
Deprecated feature:

Deprecation icon Classic rule projects are deprecated in V8.8.0. This feature will be removed in a future release of the product. See Deprecated features for migration details.

Administering and monitoring

Rule Execution Server provides tools to administer and monitor decision services.
  • You use the Rule Execution Server console, Ant scripts, or enterprise management tools (such as IBM® Tivoli® or HP OpenView) and JMX MBeans to monitor the execution of rulesets within Rule Execution Server.
  • You can debug rules that are running in Rule Execution Server.
  • You create backup versions of rulesets and revert to a previous version if necessary.
  • You also monitor and archive execution results in decision warehouse. You can also gather statistics on performance.


Ruleset execution trace data provides an audit trail of past decisions, sometimes required to satisfy regulatory requirements. This type of data provides a means to investigate a decision that is rendered in a past transaction by showing all associated rules.

By using decision warehouse with Rule Execution Server you can manage, backup, and remove stored decisions. Decision warehouse also stores and retrieves detailed reports on rulesets for which monitoring is enabled.