Reference > Glossary

Glossary

A | B | C | D | E | F | H | I | J | K | M | N | O | P | Q | R | S | T | V | W | X

A

action: A rule statement that specifies the operations to be carried out if all of the conditions in a rule are met. See also condition.
action column: An action part of a decision table. See also decision table, action.
action set: The leaf, or end, of a branch in a decision tree. Action sets consist of one or more actions to be carried out when the conditions defined in the rule are met. See also decision tree, action.
action phrase: In the vocabulary, a phrase that specifies an action to be executed. An action phrase corresponds to a void method in the business object model. See also vocabulary.
administrator: A BRMS user profile who is proficient in system configuration and administration and responsible for administrating the BRMS. See also BRMS, business analyst, developer, policy manager.
agenda: A logical workspace where rule instances that have conditions matching objects in the working memory are put. There can be several rule instances for the same rule. See also ILOG Rule Engine.

B

BAL: See Business Action Language.
baseline report: A scenario report whose ruleset execution trace provides the test values in the tests of other scenarios that reference it. Baseline reports are used for regression testing on rulesets. See also scenario report, execution trace, test.
BOM: See business object model.
BOM to XOM mapping: A mechanism that defines how business elements are mapped to the execution object model. See also business object model, Execution Object Model.
BRLDF: See Business Rule Language Definition Framework.
BRMS: See Business Rule Management System.
Business Action Language: BAL. A business rule language provided with ILOG JRules that uses an intuitive and natural language-like syntax for writing business rules. See also business rule.
business analyst: A BRMS user profile who is responsible for modeling business rule application projects. See also BRMS, administrator, developer, policy manager.
business object model: BOM. A representation of the core concepts of a business and their logical connections. The business object model is the basis for the vocabulary used in business rules. The elements of a business object model map to those of a corresponding execution object model. See also vocabulary, Execution Object Model.
business policy: The statements that define how an organization conducts its business. A business policy can define internal operations, a marketing strategy, a competitive strategy, and regulations.
business rule: A statement that models part of a business policy, is specified unambiguously, and can be implemented in a computer system. A business rule is written in a business rule language, in the form of a statement made of conditions and actions that execute only if the objects treated match the conditions. Business rules are packaged into a ruleset before they can be executed by a rule engine. See also business policy, action, condition.
business rule application: An application where the business policy has been implemented using business rules that are managed using ILOG BRMS. See also business policy, Business Rule Management System.
business rule language: A language for expressing business rules using natural language terms and syntax. With a business rule language you express rules using a vocabulary attached to a business object model rather than the underlying implementation. The Business Action Language (BAL) is a business rule language. See also Business Action Language, vocabulary.
Business Rule Language Definition Framework: BRLDF. A framework for defining custom business rule languages, using XML Schemas and property files. See also business rule language.
Business Rule Management System: BRMS. A system designed to modify and manage business logic independently from the enterprise application. ILOG JRules is a fully-featured BRMS.
business rule template: A partly completed business rule that can be used to create a series of rules with the same structure. See also business rule.

C

category: A property that can be applied on business classes and filtered in business rules. This property allows you to specify whether a business class and its members are visible in a rule. A business element is visible in a rule when at least one of the categories of this business element has been specified in the category filter of the rule. See also business object model.
Client project for RuleApps: A predefined project for Eclipse that contains a class to execute a ruleset contained in a RuleApp on Rule Execution Server. To debug a Java project for RuleApps, the debug launch configuration for a remote Java application for rules is used.
condition: A rule statement that expresses tests on objects. See also action.
condition column: A condition part of a decision table. See also decision table, condition.
condition node: A node in a decision tree that defines a rule condition and groups a set of branches. See also decision tree.
configuration: In Rule Scenario Manager, a structured set of parameters that controls the execution of scenarios. A configuration file sets data precision of tests, input and output databinding and the executor. The applied configuration is determined by an ordered hierarchy of up to three XML files, one at each of the simulation, scenario suite and scenario levels. See also scenario, databinding, test, executor.

D

databinding: In Rule Scenario Manager, a mapping of input data to a source that the Scenario Service Provider can process and of output data from a scenario execution. The classes defining databinding are specified in configuration files. See also input data, output data, Scenario Service Provider, configuration.
decision table: A set of business rules with similar conditions and actions represented as a table. Columns represent generalized forms of the conditions and actions. Rows contain specific values for each generalized condition and action. Each row represents a rule. See also action column, condition column.
decision tree: A way of representing business rules in a tree form. Decision trees provide a structure for laying out options and investigating the possible outcomes of choosing those options. See also condition node, action set.
deployment: The process of integrating business logic into an application. Deployment has three phases: extraction of a ruleset, generation of the ruleset, and execution of the ruleset within a rule engine. See also ruleset, ILOG Rule Engine.
developer: A BRMS user profile who is responsible for implementing the business rule application. See also BRMS, administrator, business analyst, policy manager.
dynamic domain: A way of defining the set of possible values for a type. With a dynamic domain, the set of values is stored and managed outside the business object model, and changes to the set of values are automatically reflected in the business object model. When rule authors write business rules using the type, they choose from a list of values that is created dynamically and always up-to-date. See also business object model, rule model.

E

execution component: A component that authorizes the execution of a ruleset by the Execution Unit (XU). The Rule Execution Server helper API, which includes interfaces known as rule sessions, is provided to bind an application and invoke the execution module. See also ruleset, Execution Unit, ILOG Rule Execution Server.
Execution Object Model: XOM. A model that references implementation objects that are used in the rules.
execution trace: The body of information, used in Rule Scenario Manager, that contains the data to initiate a ruleset execution and the results of that execution. The information included, such as the number of rules fired and the execution duration, is controlled by filters set in a scenario definition. Execution traces are included in file-based scenario reports. See also scenario, scenario report.
Execution Unit: XU. A J2EE connector or resource adaptor that handles the low-level details of ruleset execution for the Rule Execution Server. Configuration and runtime data is exposed through JMX. See also ruleset, ILOG Rule Execution Server.
executor: A proxy that determines how scenarios are executed, either locally or via the HTTP protocol. An executor is set in a configuration file. See also configuration.
extractor: In Rule Scenario Manager, the information-gathering element of a test. An extractor retrieves calculated data from the execution trace of a ruleset to be compared to a test value using an operator associated with that extractor. See also test, operator, execution trace.

F

H

hierarchical property: An extended rule property whose values are organized into a hierarchy. See also rule model, rule overriding.

I

ILOG Rule Engine

Accessible via a class, the ILOG Rule Engine takes a ruleset and executes it against a set of objects. The rule engine uses:

a ruleset: The set of rules that are processed by the rule engine, and rule execution flow information.

an object set: The set of objects to be treated by rules.

The rule engine evaluates the conditions of rules in the ruleset against the objects to determine which rules are eligible to be executed. See also ruleset, agenda, working memory.

ILOG Rule Execution Server

An ILOG JRules module that integrates into the J2EE environment, and as such offers the standard services of an application to execute, control, and monitor rulesets contained in management units called RuleApps. It is used to manage rulesets executed in Rule Scenario Manager during scenario execution, and provides the data for the execution trace. See also ruleset, RuleApp, execution trace, ILOG Rule Scenario Manager.

ILOG Rule Language

IRL. An executable rule language. Rules in IRL can reference any execution object and invoke methods on these objects.

ILOG Rule Scenario Manager

An ILOG JRules module that provides rule testing and simulation for rulesets managed by an ILOG Rule Execution Server. Rule Scenario Manager allows for unit and regression testing of rules by way of defined test scenarios, which can be defined and executed by developers in Eclipse or by policy managers in a Web-based Console. See also scenario.

ILOG Rule Studio

A business rule application development tool integrated into the Eclipse development environment and dedicated to the creation and management of business rule applications. See also business rule application, Rule perspective, rule project.

ILOG Rule Team Server

An ILOG JRules module that integrates into the J2EE environment and provides a Web interface designed to enable policy managers to author, edit, organize, and search for business rules. See also policy manager, business rule.

ilrmain function

A function which is used as an alternative entry point for ruleset execution. This function can be called from an application. See also ruleset.

initial action

A set of actions attached to a ruleflow task. Initial actions are performed before the task is executed. See also ruleflow, task.

input data

The data applied to a ruleset during its execution. In Rule Scenario Manager, the input data source is specified in a scenario definition, and an associated databinding class must be specified in the corresponding configuration. Input data can be provided in a number of formats, including XML, Excel, and JDO, using the necessary databinding. See also scenario, databinding, configuration.

insertion

The action of adding a new object into the object set provided to the rule engine for execution. See also ILOG Rule Engine.

IRL

See ILOG Rule Language.

J

Java project for rules: A predefined Java project for Eclipse that contains a single runnable main class to execute some rules contained in a rule project. To execute a Java project for rules, the run/debug configuration Java Application with Rules is used.

K

key performance indicator: KPI. In Rule Scenario Manager, a global test condition applied to the results of scenario executions, returning a set of numeric values that can be used to evaluate the relative performance of scenarios. KPIs can be defined in scenario suites and simulations. See also scenario suite, simulation.
KPI: See key performance indicator.

M

message-driven rule bean: An enterprise bean that allows J2EE applications to process messages asynchronously. The bean invokes the XU when a JMS message arrives and posts the results of the rule engine processing to a JMS destination. See also Execution Unit.

N

navigation phrase: In the vocabulary, a phrase that associates two business elements. A navigation phrase corresponds to a nonvoid method or an attribute in the business object model. See also vocabulary.

O

operator: In Rule Scenario Manager, the comparative action carried out during the application of a test. Extracted values are compared to given test values (or a baseline report) according to the logic of the operator. See also test, extractor, baseline report.
output data: The data returned by the rule engine during the execution of a ruleset. In Rule Scenario Manager, a databinding class, specified in a configuration file, is required to map output data to a human-readable format, such as XML or Excel. See also databinding, configuration.

P

phrase template: A pattern for the verbalization of a business element. See also action phrase, navigation phrase, vocabulary.
policy manager: A BRMS user profile who is generally responsible for enforcing business policy through the creation and maintenance of rules. See also BRMS, administrator, business analyst, developer.
precondition: A group of rule statements in which you define global variables for a decision table and conditions that must be met before any rows in the decision table can be executed. See also decision table.
priority: A property that determines the order in which rules are executed in an application. See also ILOG Rule Engine.
publishing: The process of sending the rules in ILOG Rule Studio to the ILOG Rule Team Server for storage and management. Once rules are published, they need to be synchronized between ILOG Rule Studio and ILOG Rule Team Server. See also ILOG Rule Studio, ILOG Rule Team Server.

Q

query: A mechanism allowing rule artifacts to be searched and processed.

R

RetePlus: A rule execution mode for matching many patterns with many objects. The RetePlus execution mode is used by the JRules rule engine to minimize the number of rules and conditions that need to be evaluated, compute which rules should be executed, and identify in which order these rules should be fired. See also ILOG Rule Engine, Fastpath, sequential.
retraction: The action of removing an object bound to a rule variable from the working memory. See also ILOG Rule Engine.
RSM archive: In Rule Scenario Manager, a structured, zip-formatted and executable archive containing a complete set of artifacts needed to execute a scenario, scenario suite or simulation. It can comprise scenario, scenario suite and simulation definitions, configuration files, input data, test sets and baseline reports. It is the means by which file-defined Rule Scenario Manager artifacts can be imported to the Rule Scenario Manager Console. RSM archives can also be downloaded from the Console to file.
rule artifact: An item used to express a business policy in a business rule application. Business rules and decision tables are examples of rule artifacts. See also business policy, business rule, decision table.
Rule Execution Server Configuration project: A server configuration is persisted in a Rule Execution Server Configuration project when it is saved. The configuration provides the information necessary for Rule Studio to make a connection to Rule Execution Server when you deploy a RuleApp. See also ILOG Rule Studio, ILOG Rule Execution Server, RuleApp.
Rule Execution Server Console: A Web user interface that provides support for deploying RuleApps and the management of executable resources on a Rule Execution Server. See also RuleApp, ILOG Rule Execution Server.
Rule Scenario Manager Console: A Web user interface for use by policy managers to create, launch and manage scenarios in Rule Scenario Manager. See also ILOG Rule Scenario Manager, scenario.
rule instance: An occurrence of a rule that includes the combination of objects in the working memory that match the patterns specified in the rule. More than one instance of the same rule may exist in the agenda at any time because the rule patterns may be satisfied by more than one object or set of objects. See also ILOG Rule Engine, RetePlus.
rule model: The model that defines the set of items that are managed in a rule project, and their associated properties. See also rule project, hierarchical property.
rule overriding: A rule that overrides one or more other rules is executed in place of the rules(s) that are overridden. Typically rule overriding operates within a hierarchy of rules, with a local or more specific rule overriding a more general rule. For example, a minimum customer age for a particular state could take precedence over a minimum customer age for the country. See also hierarchical property.
rule package: A container for organizing rule artifacts according to business logic. Rule packages become folders once published to Rule Team Server. See also rule artifact, publishing.
Rule perspective: An Eclipse perspective that defines the initial set and layout of views in the Workbench window that will be used in the development of a rule project. See also ILOG Rule Studio, rule project.
rule project: A type of project in which you can manage and organize rule artifacts and business object models. See also rule artifact, business object model.
rule project template: A partly completed rule project that can be used to create a series of rule projects with the same structure. See also rule project.
rule session: A runtime connection between a client and a rule engine. A rule session may consume initialized rule engine resources. A session can be either stateful or stateless and run on both J2SE and J2EE platforms. The Rule Execution Server uses rule sessions as an execution component. See also ILOG Rule Engine, ILOG Rule Execution Server.
rule task: A ruleflow task that refers to and orders rule artifacts. See also ruleflow, task.
RuleApp: A deployment and management unit for the Rule Execution Server that may contain one ore more rulesets. See also ILOG Rule Execution Server, ruleset.
RuleApp project: In Rule Studio, a RuleApp is handled as an Eclipse project, and the deployment of a RuleApp to a running Rule Execution Server is performed through the RuleApp project. See also ILOG Rule Execution Server, RuleApp.
ruleflow: A way to control and order the execution of rule artifacts. You define a ruleflow in terms of tasks. See also task, rule artifact.
ruleset: The parts of a rule project, rule artifacts and nonrule artifacts, included in an executable package called the ruleset archive. The ruleset archive is usually generated by extraction from a rule store. The ruleset is modeled as an object in the rule engine. See also rule artifact, ILOG Rule Engine.
ruleset extractor: A mechanism for selecting the rules of the ruleset to be deployed. It is typically based on the value of rule properties. See also ruleset.
ruleset interceptor: A mechanism that allows services to be added to an execution component transparently and to be triggered automatically when certain events occur. See also ruleset.
ruleset parameter: A parameter that can be defined to set and/or retrieve values on a ruleset. Ruleset parameters are accessible from outside of the ruleset, and therefore are a bridge between the business logic and the application. See also ruleset, ruleset signature, ruleset variable.
ruleset signature: The list of in, out, and inout parameters of a ruleset. See also ruleset, ruleset parameter.
ruleset variable: A variable that can be defined to be used in all the rule artifacts of a ruleset. See also ruleset, rule artifact.
runtime rule selection: A way to filter rule artifacts at runtime. The selection is expressed in rule statements and associated with a rule task. See also rule artifact, rule task.

S

scenario: A specification for a test case of a single ruleset. A scenario definition includes the path to the RuleApp serving the ruleset to execute, the input data the ruleset is to execute on, and performance tests. Scenario execution is controlled by a configuration file, and the results of a scenario execution are contained in a structured scenario report. See also RuleApp, ruleset, input data, databinding, test, configuration, scenario report.
scenario report: A structured summary of the results of a scenario execution. It is composed of the ruleset execution trace, the tests defined in the scenario, and the results of the tests. See also scenario, execution trace, test.
Scenario Service Provider: In Rule Scenario Manager, a web application residing on an application server that processes and executes scenarios. It works with the Rule Execution Server in managing the rulesets executed in scenarios. See also ILOG Rule Execution Server, scenario.
scenario suite: A specification defined by a list of scenarios and a KPI to be calculated over the scenario execution results. A scenario suite can use a common configuration for its constituent scenarios. The results of a scenario suite execution are contained in a scenario suite report. See also scenario, key performance indicator, configuration, scenario suite report.
scenario suite report: A structured summary of the results of a scenario suite execution. It is composed of the individual scenario reports for the suite's constituent scenarios, the KPI defined in the scenario suite, and the results of the KPI. See also scenario suite, scenario, key performance indicator.
sequential: A rule execution mode for stateless pattern-matching. With this mode, rules can be processed sequentially, which can improve the speed of rule processing in specific cases. The sequential mode can be selected for individual tasks in a ruleflow. See also ILOG Rule Engine, RetePlus, Fastpath.
simulation: A specification defined by a list of scenario suites and a KPI to be calculated over the scenario suite execution results, allowing the relative performance of rulesets to be compared. A simulation can use a common configuration for its constituent scenario suites. The results of a simulation execution are contained in a simulation report. See also scenario suite, key performance indicator, configuration, simulation report.
simulation report: A structured summary of the results of a simulation execution. It is composed of the individual scenario suite reports for the simulation's constituent scenario suites, the KPI defined in the simulation, and the results of the KPI. See also simulation, scenario suite, key performance indicator.
static rule analysis: A mechanism for checking whether the rules are semantically consistent. Inconsistencies can be found either in the rule itself (for example, a rule with contradictory conditions will never apply) or with respect to other rules (for example, two rules that can be applied to the same object and that set a given attribute to different values are conflicting).
synchronization: The process of synchronizing rules published to ILOG Rule Team Server from ILOG Rule Studio. See also ILOG Rule Studio, ILOG Rule Team Server.

T

task

The basic unit of organization in a ruleflow. A task can contain rule artifacts (rule task), functions (function task), or another ruleflow (flow task). See also ruleflow, rule task, function task, flow task.

technical rule

A rule written in a technical rule language, IRL for instance.

test

In Rule Scenario Manager, a comparative indicator, specified during the definition of a scenario, that provides information about the performance of a ruleset execution. The calculated value, extracted from the execution trace of a ruleset, is compared against a test value (or a baseline report) using an operator. The result of a test is given as passing or failing. See also extractor, operator, scenario, execution trace, baseline report.

transition

A connection between two tasks in a ruleflow. Transitions are unidirectional, and they can have conditions attached to them. See also ruleflow, task.

transition condition

A condition on a transition that specifies when the following task can be executed. See also ruleflow, task, transition.

transparent decision service

Transparent decision services are truly reusable, owned by business users, easy to adapt, and contribute to an enterprise compliance strategy. The services are transparent because a BRMS provides easy access to the rules in the decision service to all the participants of its lifecycle: developers, business analysts, and policy managers. JRules provides the following transparent decision services:

Hosted transparent decision services--Rule Execution Server automatically exposes deployed rulesets that use an XML schema or a Java XOM with simple types as a Web service. These rulesets can be exposed as a Web service without passing through code deployment.

Monitored transparent decision services--expose management and runtime information about the Web service to Rule Execution Server. A monitored transparent decision service is not limited to rulesets that use an XML schema or a Java XOM with simple types like the hosted transparent decision services. Rule Studio provides a Client Project for RuleApps wizard to generate a monitored transparent decision service.

V

verbalization: The process of associating terms and phrases to elements of the business object model. See also action phrase, navigation phrase, phrase template, vocabulary.
vocabulary: The set of natural language terms and phrases attached to elements of a business object model and used for rule editing. See also action phrase, navigation phrase, verbalization, business object model.

W

working memory: A part of the rule engine that stores objects against which a ruleset is executed. It contains the current state of objects that lead to the current rules in the agenda. See also ILOG Rule Engine, RetePlus.

X

XOM: See Execution Object Model.
XU: See Execution Unit.