Tao Xiaojun, Zhu Min
(Computing Center, School of Information Science and Technology, East China Normal University, Shanghai 200062)
Focusing on the idea of separating business process and business rules by rule engine technology, this paper discusses and puts forward a set of development modes that should be followed when developing enterprise service application system effectively by rule engine technology, including designing an enterprise service model based on rule engine; This paper puts forward the concrete steps and methods of using rule engine technology to realize enterprise service application in the actual development process.
Keywords: rule engine JSR-94 Rete algorithm Drools
Constructing enterprise service model with rule engine
Zhu Min Tao Xiaojun
(Computer Center of East China Normal University, Shanghai, 200062)
This paper will study and propose a mode based on the idea of rule engine, which can be used to actually build enterprise services and use the rule engine technology effectively and simply. This model includes the enterprise service model based on rule engine, and the steps and processes of developing enterprise services using rule engine technology.
Keywords: rule engine JSR-94 Rete algorithm saliva
1. Introduction
Rule engine is a software system for managing and automatically implementing business rules. Its main function is to store, classify and manage rules, verify the consistency of rules, and infer other rules through rules, contact rules and applications to realize these rules, in which rules mainly refer to enterprise or business logic, legal provisions, enterprise policies and so on. The concept of rule engine is to separate business rules from the application logic of software. In the traditional enterprise service application development mode, business logic is directly fixed in the application code, which makes the maintenance of the application complicated and expensive. The ever-changing business rules and business processes always lead to frequent modifications of applications, especially when faced with the challenges of dynamic business models and business processes, applications developed in the traditional mode often face comprehensive and expensive modifications. Even the design has changed. In order to solve this problem, it is necessary to adopt a new development model to separate business logic from code layer. Using the rule engine provides a system development framework, separates business processing from business rule processing, and manages and maintains business rules in a unified way. This paper discusses the development model of enterprise service application based on rule engine, including the enterprise service model based on rule engine and the basic development steps and methods.
2. Enterprise service model based on rule engine
Designing a clear and effective system model is the premise of the smooth operation of enterprise service system. Figure 1 A simple enterprise service application architecture is designed by using the rule engine and its pattern conforming to JSR-94 standard.
Figure 1
"Figure 1" describes that the enterprise service system is divided into three parts:
Application/data acquisition system: It captures and stores all the data submitted by the application, and is the user of business services. Its main function is to submit business requests and handle business judgments.
Business service: call the selected rule engine through the callable network server or API to execute or run business rule logic and generate feedback information and data. At the same time, it also provides the function of maintaining business rule logic conveniently and effectively.
Support service: provides relevant data submitted by business service users, that is, relevant data or application programs or service interfaces required by the rule engine to execute or calculate business rules.
3. Steps and methods of enterprise service development model based on rule engine.
In the enterprise service development model based on rule engine, the most important principles are: (1) separating workflow from business rules; (2) Formally describe business rules. In this development model, these two principles run through. The purpose of separating workflow from business rules is to extract key business judgment rules and business event responses and put them in the public part of the system (business services) for different application workflows. And is easy to maintain and manage. This is the premise of the smooth development of the system in this mode. The purpose of formally describing business rules is to describe and represent business rules in a form that can be processed by the rules engine, so that business rules can be calculated, and applications can access these rules through the service layer according to defined protocols.
The methods and principles in the development model mentioned and discussed below all revolve around the above two principles.
3. 1 Use decision table to extract rules
In the enterprise service development mode based on rule engine, the first problem to be solved is to clarify the rules in enterprise application and the corresponding business judgment. The set of conditional elements in business affairs constitutes rules, which determine judgment and feedback. The method of decision table can be used to extract the rules and corresponding judgments in scattered enterprise business.
Rule 1
Rule 2
……
Rule one
Condition 1
Relational value
Condition 2
……
Condition j
Decision 1
Feedback or not
Decision 2
……
Decision k
Table 1
"Table 1" gives the general format of the decision table. See the model shown in figure 1, in which conditions will become data fields in the system, and condition values will be corresponding data, which is the object to support business management and maintenance, and also the object to be captured and submitted by the application/data acquisition system. The set of several conditions and their values constitutes a rule, which is the object of business service management and maintenance and the basis of rule engine processing. Judgment is business.
The use of decision table is further illustrated by taking the example that the enterprise decides the sales bonus of the sales staff in the current month:
A
B
C
D
E
F
G
1
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
Rule 6
2
Achieve the goal
ordinary
ordinary
ordinary
Y
Y
Y
three
Sales
The previous month.
& gt= 10k
& lt 10k
= 10k
four
warn
Y
ordinary
ordinary
ordinary
Y
ordinary
five
amortize
0%
1%
2%
2%
2%
3%
Table 2
"Achieving the target" in Table 2 indicates the condition of "achieving the sales target"; "Sales volume" refers to the condition "sales volume"; "Amortization" means judging "commission"; "Warning" means to judge the meaning of "giving a warning"; "Top Quantity" refers to the data of "Last Month Sales".
In "Table 2", column A describes the conditions involved in the application and the judgment after the system processing, and forms columns B to G by combining with various conditions or values judged in cells in the same row. Each column in columns B to G is a rule separated by a decision table, and the rules are described in the form of condition value sets and judgment feedback values. For example, the business rule described in Rule 2 is: If the sales target is not achieved and the sales volume is greater than last month, no warning will be given, and the commission rate will be determined as 1%. The business rule described in Rule 5 is: If the sales target is achieved and the sales volume is less than or equal to last month, a warning will be given and the commission rate will be determined as 1%. In practical application, a decision table can be generated by summarizing the written or unwritten business rules of an enterprise, if necessary, such as in the case of unclear business rules.
Separating business rules is the premise of developing enterprise application based on rule engine, and the first step, necessary and most important step in enterprise service development model based on rule engine. If the decision table method provided in this paper is used, business logic and business rules can be separated more conveniently, and the rules can be described more clearly and accurately, and it is closely combined with the enterprise service model based on the rule engine, which provides strong support for solving problems in the subsequent development steps.
3.2 Analyze and resolve rule conflicts.
After separating and extracting rules, conflicts between rules must be considered. The conflict mentioned here mainly refers to the judgment ambiguity caused by the intersection of the value ranges of the same conditions between rules. If there are conflicts between rules that are not resolved, the judgment result will be uncertain and the processing of the rule engine will not be carried out correctly. We can detect conflicts between rules by using decision grid. The specific way is to put the rules at the front of the grid in turn. Each cell in the grid represents the intersection of corresponding rules, which is used to record whether the feedback value is ambiguous when the intersection rule or rule set is true. The basis of judging whether the rules conflict is the intersection of the condition ranges contained in the intersection rules and the feedback value of each judgment. The specific process is shown in Figure 2:
Figure 2
Taking the rules obtained in 2. 1 as an example, the conflict between amortization feedback and rules is judged by decision grid analysis, and the results are shown in Table 3.
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
Rule 6
Rule 1
network computer
Y
ordinary
ordinary
ordinary
ordinary
Rule 2
Y
network computer
Y[2]
ordinary
ordinary
ordinary
Rule 3
ordinary
Y[2]
network computer
ordinary
ordinary
ordinary
Rule 4
ordinary
ordinary
ordinary
network computer
Y[ 1]
ordinary
Rule 5
ordinary
ordinary
ordinary
Y[ 1]
network computer
Y
Rule 6
ordinary
ordinary
ordinary
ordinary
Y
network computer
Table 3
"Table 3" clearly describes the conflicts between various rules, where Y indicates that the rules may be true and have conflicts at the same time, and the following "[]" indicates the judgment name, judgment serial number or judgment description of specific conflicts; N means that the rules do not conflict or cannot happen at the same time.
After clarifying the conflict relationship between rules, it is natural to consider how to solve the conflict. This paper puts forward three methods to solve rule conflicts: (1) priority mode; (2) Queuing mode; (3) Common patterns
Priority mode: set the priority order of the rules, and when the rules conflict, use the judgment feedback of the rules with higher priority. It is conducive to maintaining the long-term stability of business processing results and is suitable for enterprise applications with clear business processing rules.
Queuing mode: first-in, first-out principle, that is, first-use principle. If there is a rule conflict in centralized batch processing within a period of time, the judgment feedback of the first rule (used for the last or first processing) will be adopted. It is beneficial to ensure the consistency of the processing results of unified batch processing, and is suitable for enterprise applications with peak business.
Common mode: record and refer to the usage frequency of rules in business processing (the frequency when the rules are true), and adopt the feedback of rules with higher or lower usage frequency when the rules conflict, which is conducive to flexible application of rules according to business development and is suitable for enterprise applications with changeable business development.
In enterprise application services, the above-mentioned rule conflict resolution schemes can be used alone or in combination to form a rule conflict resolution mechanism for enterprise applications. If there is no solution to rule conflict, the general rule engine will adopt LIFO (last in, first out) principle to solve rule conflict, but a set of rule conflict resolution mechanism is essential for a successful enterprise application based on rule engine development.
3.3 Formal Description Rules
After solving the conflict problem of rule sets, the next step of enterprise service development model based on rule engine is to formally describe the rules for coding and calculation. The current rule engine is generally based on the Rete algorithm (network algorithm) proposed by Dr. Charles L. Forgy in 1979. The basic idea of Rete algorithm is to organize an effective recognition network. Filter data through its propagation in the network. The concrete method of rete algorithm is to establish a root node as the entrance of data objects into the discriminant network, establish test nodes to form the discriminant network according to the conditions contained in the rules, and construct several terminal nodes at the bottom of the network to describe the corresponding rules. After the data object enters the authentication network, it passes through the path node. Finally, it reaches an endpoint and activates the rules described by this endpoint. According to the characteristics of Rete algorithm, rules need to be divided into LHS (left hand side) and RHS (right hand side). LHS consists of the conditional part of the rule, which determines the generation of test nodes in the identification network, and RHS consists of the decision part of the rule, which determines the generation of endpoints in the identification network.
Taking the rules obtained in 2. 1 as an example, the decision table obtained in the rule extraction step can be used to solve the problem. For each rule, its column condition value constitutes its LHS, and the decision feedback value constitutes its RHS. Therefore, each rule can be formally described as:
The formal description of rules paves the way for the subsequent coding process of rules in enterprise service development model based on rule engine.
3.4 Design business processes
Like the usual design pattern, the development pattern of enterprise service based on rule engine also includes and pays attention to the business process design of enterprise service. Due to the separation of business process and business rules, the design of business process is greatly simplified and the burden of business process is greatly reduced. The design principle of business process should follow the service model described in Figure 1. The design method adopts the same UML method as the previous design pattern, which will not be discussed in detail in this paper. Taking the example proposed in 2. 1 as an example, the corresponding business process activity diagram is given, which intuitively explains the simplification of business process design after the separation of business process and business rules.
Figure 3
It can be clearly seen from Figure 3 that the business process no longer contains business logic. When the business logic changes, there is no need to change the business process.
3.5 Business Rule Coding and Business Process Coding
The coding step is not only the process of enterprise service realization, but also the process of program code realization in short. In this process, it is necessary to follow the design and results of the previous steps and develop around the service model described in "Figure 1". Taking the example in 2. 1 as an example, Java language and "Drools" rule engine are selected to realize coding. This paper only gives the classes that need to be implemented and their brief descriptions.
Implementation of application program part
SellApplication.class captures data, submits business judgment request, receives feedback, and realizes business process.
SalesPerson.class is a data object that records the data of salespeople.
FeedBack.class records judgment and feedback data.
Support the implementation of the service part
AchieveTargetService.class is responsible for giving the sales target of the sales staff.
SaleVolume.class is responsible for providing monthly and last month's sales of salespeople.
Implementation of business service part
Amortization service class accepts business judgment request, calls rule engine service, and feeds back judgment.
Rule coding
Take the rule 1 in "Table 1" as an example, and its corresponding "Drools" rule engine code is as follows.
Rule "rule 1"
Significance-100 // Priority setting
When //LHS
Salesperson (achieveTarget == false, sales volume < =100000)
$sa: SellApplication()
$fb: feedback ()
Then //RHS
FB . set warn(true)；
FB. set amortization ("0%");
sa . set feedback(FB)；
end
4. Concluding remarks
The enterprise service development model based on rule engine architecture proposed in this paper closely combines the idea of rule engine. The proposed steps and methods can help developers to separate business processes and business rules in the process of developing enterprise application services, clarify business rules, make these business rules descriptive and available, and finally realize their functions in application services. Although the application of rule engine is not extensive and in-depth, its concept and theory are relatively mature, and it has obvious advantages for enterprise service applications, especially in dynamic business models. In the actual process of enterprise application service development, the introduction of enterprise service development model based on rule engine architecture will make enterprise service application more maintainable and flexible, and has the value of popularization and use.
References:
Malcolm Chisholm. How to build a business rule engine [M]. United States: Morgan Kaufman
[2] Ian Graham. Business rule management and service-oriented architecture [M]. United States: Willie, 2007.0 1
[3] (America) Gamma et al, Li Yingjun et al. Design Pattern [M]. Beijing: Machinery Industry Press, 2005.06.
[4] (America) translated by Dida et al., translated by Li Hongdong et al., Pattern Classification (2nd Edition) [M]. Beijing: Machinery Industry Press, September 2003.