The working principle of Java Rule Engine and its application

　　 SummaryThe Java Rule engine is a component embedded in a Java program that tests and matches the Java data Objects currently submitted to the engine and the business rules that are loaded into the engine, activates the business rules that conform to the current data state, and, depending on the execution logic declared in the business rules, Triggers the corresponding action in the application.

　　 Introduction

At present, the Java community has promoted and developed a compelling new technology--java rules engine (rule Engine). It can be used to separate the business decision logic of business decision-makers and the technology decision of the application developer in the application system. And put these business decisions in the central database or other unified place, so that they can be dynamically managed and modified at runtime, so as to maintain flexibility and competitiveness of enterprises to provide effective technical support.

　　 principles of the rule engine

1. Introduction of rule-based Expert system (RBEs)

The Java rule Engine originates from the rule-based expert system, and the rule-based expert system is one of the branches of the expert system. Expert system belongs to the category of artificial intelligence, it imitates human reasoning way, uses exploratory method to infer, and uses the term that human can understand to explain and prove its inference conclusion. For a deeper understanding of the Java Rule Engine, a rule-based expert system is briefly introduced below. RBEs consists of three parts: rule base (Knowledge Base), Working Memory (fact base), and inference Engine. They are structured as shown in the following system:


Fig. 1 The composition of expert system based on rules
As shown in Figure 1, the inference engine consists of three parts: pattern Matcher, the agenda (Agenda), and the execution engine (Execution Engine). The inference engine is added to the agenda by determining which rules meet the facts or objectives, and give precedence to the rules, and the rules that satisfy the facts or objectives. The pattern-matching device determines which rule to execute, when to execute the rule, the order in which the rules are sorted by the agenda management pattern, and the execution engine is responsible for executing the rules and other actions.

As opposed to human thinking, the inference engine has two reasoning methods: Deductive (forward-chaining) and inductive method (backward-chaining). Deduction from an initial fact, constantly applying rules to draw conclusions (or perform specified actions). And the inductive law is based on the assumption, constantly looking for the facts that conform to the hypothesis. Rete algorithm is one of the most efficient forward-chaining inference algorithms, and many Java rule engines are based on rete algorithm to compute inference.

The inference engine's reasoning steps are as follows:

(1) Input the initial data (fact) into working Memory.

(2) Use pattern Matcher the rules (rule) and data (fact) in the rule base.

(3) If the execution rule has a conflict (conflict), that is, multiple rules are activated at the same time, the conflicting rules are put into the conflict set.

(4) Resolve the conflict and put the activated rules into the agenda in order.

(5) Use the execution engine to execute the rules in agenda. Repeat steps 2 through 5 until you have finished executing the rules in all agenda.

This is the original schema of the rule engine, which evolved from this primitive architecture.

2, Rule engine related components

A rule engine is an engine that determines whether a specified filtering condition in a rule can match a real-time condition of the runtime to perform the action specified in the rule. There are four basic concepts associated with the rule engine, and for a better understanding of how the rules engine works, these concepts are described below.

1) Information element (Information Unit)

The information element is the basic building block of the rule engine, which is an object that contains all the information for a particular event. This information includes: messages, application identities that generate events, event generation events, information meta types, related rule sets, common methods, common properties, and some system-related information, and so on.

2 Information Service (Information Services)

Information services generate information meta objects. Each information service produces its own type of information meta object. That is, a particular information service has the same format for each information meta object generated by the information element, but it can have different attributes and rule sets. It should be noted that many different information services can be run on a single machine, and different instances of the same information service can be run. However, each information service produces only the information elements of its own type.

3) ruleset (rule set)

As the name suggests, a rule set is a collection of many rules. Each rule contains a conditional filter and multiple actions. A conditional filter can contain multiple filter conditions. A conditional filter is a combination of multiple Boolean expressions whose combination result is still a Boolean type. When the program is running, the action will be executed if the condition filter value is true. In addition to the general execution action, there are three more specific actions, which are: discard the action (discard action), include action (include action), and make the contents of the information Meta object persisted. The difference between the first two action types will be described in the 2.3 Rules engine work mechanism section.

4 Queuing Manager (Queue Manager)

Queues used by the Queue Manager to manage information meta objects from different information services.

The following is a study of how these related artifacts of the rule engine work together.

As shown in Figure 2, the processing process is divided into four phases: The information service accepts the event and converts it into an information element, and then the information elements are passed to the Queue manager, which receives the information elements and applies the rules they carry themselves to execute until the message element is no longer in the queue manager.


Figure 2 Process collaboration diagram
3. The working mechanism of the rule engine

The following specializes in the internal process of the rule engine. As shown in Figure 3, the rule engine receives the information element sequentially from the queue manager, and then checks the rules in the rule set of the information element in the order defined by the rule. As shown in the figure, the rules engine checks the first rule and evaluate its conditional filter, and if the value is false, all actions associated with this rule are ignored and the next rule continues. If the filter value for the second rule is true, all actions associated with this rule are performed in the order defined, and the execution continues with the next rule. When all the rules in the information element have been executed, the information element is destroyed and the next message element is received from the queue Manager. Two special actions are not considered in this process: the Discard action (discard action) and the include action (include action). The abort action, if executed, skips all subsequent rules in its information element and destroys the information element in which the rule engine continues to receive the next information element in the queue Manager. The inclusion action is actually an action that contains other existing rule sets. If the containing action is executed, the rule engine pauses and enters the included rule set, and after execution completes, the rule engine returns to where it was previously paused. This process will be recursive.

Figure 3 Rule Engine working mechanism

The working mechanism of the Java Rule engine is very similar to that of the rule engine mechanism, except that the above concepts are repackaged together. The Java Rule engine retrieves Java data objects that are submitted to the engine, and creates an execution instance of those rules, based on the current property values of those objects and the relationships between them, to find eligible rules from the set of rules that are loaded into the engine. These instances are executed in the order in which the engine is executed, in accordance with some sort of precedence. Generally speaking, the Java Rule Engine consists of the following parts: Working memory (Working Memory) is the workspace, used to hold the collection of data objects referenced by the engine, the rule execution queue, which holds the activated rule execution instance, and the static rule area, which holds all the loaded business rules. These rules will be organized according to some kind of data structure, and the engine needs to adjust the rule execution instance in the queue quickly according to the status of the objects in the workspace after the changes in the work area. The structure diagram of the Java Rule Engine is shown in Figure 4.

Figure 4 Java Rule Engine working mechanism

When the engine executes, the rule execution instance is executed according to the precedence order in the rule execution queue. Because the execution part of the rule may alter the data object of the workspace, it causes some rule execution instances in the queue to expire because of a conditional change, to be revoked from the queue, or to activate a rule that originally did not meet the condition. Generates a new rule execution instance into the queue. Thus, a "dynamic" rule execution chain is created, which forms the inference mechanism of rules. The "chained" response to this rule is entirely driven by data in the workspace.

Any rule engine needs to solve the efficiency problem of rule inference mechanism and rule condition matching well. The efficiency of the rule condition matching determines the performance of the engine, the engine needs to quickly test the data objects in the workspace, find the eligible rules from the loaded rule set, and generate the rule execution instance. Charles L. Forgy of the University of Carnegie Mellon, USA, in 1982, invented a rete algorithm that solves this problem well. At present, the world's top commercial business rules engine products are basically using the rete algorithm.

　　 Java rules engine api--jsr-94

To standardize the rule engine technology, the Java community has developed the Java Rules Engine API (JSR94) specification. It defines a few simple APIs for the Java Platform Access rule engine.

The Java Rules Engine API, defined in the Javax.rules package, is the standard enterprise API for accessing the rules engine. The Java Rules Engine API allows clients to interact with the rules engine products of different vendors in a uniform way, just as you would use JDBC to write independent vendor access to different database products. The Java Rules Engine API includes mechanisms for creating and managing rule sets, adding, deleting, and modifying the mechanisms of objects in the workspace, and initializing, resetting, and executing rules engines.

1. Java Rule Engine API architecture

The Java Rules Engine API consists of two main types of APIs: the Rule Management API (the Rules Administrator API) and the runtime Client API (the Runtime client API).

1) Rules Management API

The Rule Management API is defined in Javax.rules.admin, which contains the load rules and the actions that correspond to the rules (the execution set execution sets) and the instantiation Rule engine. Rules can be loaded from external sources, such as uri,input streams, XML streams and readers, and so on. The Rule Management API also provides a mechanism for registering and canceling the execution set and maintaining the execution set. Using the admin package Definition rule helps control management of client access running rules by defining permissions on the execution set so that unauthorized users cannot access the managed rules.

The Rule Management API uses class Ruleserviceprovider to obtain an instance of the Rule Manager (Ruleadministrator) interface. This interface provides method registration and unregister execution sets. The Rule Manager provides both local and remote Ruleexecutionsetprovider, which is responsible for creating the rule execution set (Ruleexecutionset). Rule execution sets can be created from sources such as XML streams, binary streams, and so on. These data sources and their contents are aggregated and serialized and then transferred to a remote server running the rule engine. In most applications, there is not much of a remote rule engine or remote rule data source. To avoid network overhead in these cases, the API provides a local ruleexecutionsetprovider that can read data from a rule library running in the same JVM. The rule execution set interface has the ability to obtain methods for the execution set of rules, as well as to retrieve all rule objects defined in the rule execution set. This allows customers to know the rule objects in the rule set and to use them as they want.

2 Runtime Client API

The runtime APIs are defined in the Javax.rules package, providing a class and method for rules engine users to run rules to obtain results. At run time, clients can access only those rules that are registered with the Rule Management API, and the runtime APIs help users get a rule session and execute the rules in that session.

The runtime API provides access to the vendor Rules Engine API, which is similar to JDBC. Class Ruleserviceprovider provides access to the Run-time and management APIs implemented by the specific rule engine, through which the Rules engine vendor provides its rule engine implementation to the customer and obtains a URL that ruleserviceprovider uniquely identifies the rule engine. The standard usage of this URL is to use an Internet domain name space similar to "Com.mycompany.myrulesengine.rules.RuleServiceProvider", which guarantees the uniqueness of the access URL. Class Ruleserviceprovider internally implements the interfaces required for rule management and Run-time access. All Ruleserviceprovider must be registered with Ruleserviceprovidermanager in order to be accessed by the customer, and the registration method is similar to the JDBC API DriverManager and driver.

The Run-time interface is a critical part of the Run-time API. The Run-time interface provides a method for creating a rule session (Rulesession) that is used to run rules. The runtime API also provides access to all rule execution sets (ruleexecutionsets) that have been registered with the service provider. The rule session interface defines the type of session that the customer uses, and the customer can choose to use stateful or stateless sessions in the way they run the rules. A stateless session works like a stateless session bean. The customer can send a single input object or a list of objects to get the output object. Stateful sessions are useful when a client needs a dedicated session with the Rule engine. The input object can be added to the session through the AddObject () method. Multiple objects can be added to the same session. An existing object in the dialog can be updated by using the Updateobject () method. Objects in a session are not lost as long as the session between the customer and the rule engine persists.

The Ruleexecutionsetmetadata interface is provided to the customer to find the metadata (metadata) for the rule execution set. Metadata is provided to the user through the regular session interface (Rulesession Interface).

2, Java Rules Engine API security issues

The Rules Engine API separates the management APIs from the Run-time APIs, providing better granular security control for these packages. The Rules Engine API does not provide a clear security mechanism that can be used in conjunction with the standard security APIs defined in the Java EE specification. Security can be provided by the following mechanisms, such as the Java Authentication and authorization service (JAAS), Java Cryptographic Extensions (JCE), Java Secure Sockets extension (JSSE), or other custom security APIs. Using Jaas, you can define permission permissions for the rule execution set, so that only authorized users can access it.

3. Exceptions and logs

The Rules Engine API defines the javax.rules.RuleException as the root class for the exception hierarchy of the rule engine. All other exceptions are inherited from this root class. Exceptions defined in the rules engine are controlled exceptions (checked exceptions), so the task that catches the exception is given to the rule engine. The Rules Engine API does not provide a clear logging mechanism, but it recommends that the Java Logging API be used for the Rules Engine API.

JSR 94 provides a common standard API for the rule engine, providing guidelines for implementing the Rule management APIs and Run-time APIs, providing no guidance on how rules and actions should be defined and what languages should be used to define rules, or providing technical guidance on how rules engines read and evaluate rules.

　　 Concluding remarks

Rule Engine technology provides a solution for managing volatile business logic. The rules engine can manage both the business logic of the application tier and the page flow of the presentation layer. This provides a new option for software architects to design large information systems. The Java rules engine will be more developed in the Java community after the standard specification has been developed.