Rule Engine (1)

1. Application Scenarios of the Rule Engine
2. The structure and operation principle of the rule engine project
3. Advantages and disadvantages of using lua as a rule language

 

1 Application scenarios of the rule engine

　　We know that everything is constantly developing, including of course any of our computer systems, business rules are constantly changing, and we have to change, often driven by the business system changes. This has caused us to be very passive. Business rules may change every month or even every day, and it is obviously impossible for our business system to change with such a frequency. In daily life, there is a common discount in supermarkets, whether it is discounted, and whether individual products are not discounted; another example, in the insurance industry, the industry association or the China Insurance Regulatory Bureau has a new regulatory requirement; another example is the state in order to prevent deflation. Loose monetary policy and significantly lower requirements for lending, etc. These requirements are changeable and volatile, often adjusted from time to time, and even regional differences.

　　Businesses increasingly rely on information technology (IT) to manage their business, and IT departments need to develop more complex applications while also adapting to rapid changes in the applications they support. Often, implementing a company's business strategy within these applications is too complex, bulky, and changing too quickly for traditional software architectures.

　　If we also adjust the core business system according to the previous thinking, it will lead to many problems:

1. Therefore, there are many types of requirements, resulting in frequent adjustment of the system, which damages the stability of the system, and the stability of the system is often the most important.
2. Testing is difficult, so business-like systems are often multi-dimensional, and it is difficult to carry out high-coverage tests in each transformation, and it is difficult to carry out unit testing
3. Requirements are difficult to achieve. Whether it is an old c/c++ system or a new system such as java/c#, the description of the business is very different from natural language, and it is difficult to express, let alone visual design of the business.
4. Such business controls may be spread throughout the project, making it difficult to iteratively optimize and upgrade the code

　　We have listed the above points casually, which can basically illustrate the benefits of rule engine application. Developers and architects can extract business logic from application legacy code. If business policies are hard-coded into enterprise applications, the process of updating the system requires dedicated programmers, puts system stability at risk, and takes a long time. By extracting business logic out of business applications with business rules, IT users can develop and run business logic independently of the application. A full BRMS (ie Business Rules Management System) implementation can do even more and enable business users to directly manage business policies with limited reliance on the IT department. The degree of reliance ranges from limited review by business users of policies implemented by IT to the specification, creation, testing, and deployment of policies with full control by business users.

　　The IT cycle consists of the time to develop and maintain this infrastructure. Before the rules engine was used, the IT cycle appeared to be inconsistent with the business cycle. In the rule engine solution, we can understand the original business system as an application program and business rule application; the business rule management cycle and the application development life cycle can develop in parallel. Business policies can evolve on demand without the additional burden of application development. Every time an application evolves, business policy enforcement keeps pace with the application. With this separation, business policy and application architecture can be managed asynchronously. For example, an application developer might work on a semi-annual cycle during which a new application version is developed every six months in response to changing application infrastructure (for example, JDK and RDBMS versions) and other core Business needs. At the same time, policy managers may work on a one-week cycle during which new versions of business policies are delivered in response to evolving markets, new customers, or a changing regulatory environment.

　　Business users, on the other hand, are not concerned with the details of application development, but are interested in defining, testing, and managing well-defined decisions (implementing business policies expressed as business rules within the application). Therefore, they need tools that simplify organizing, searching, and writing rules within the context of an overall policy. Developers work in their environment at their own pace, as do business users, and the two can easily be synchronized and merged. Finally, both IT and business users need access to the rules execution environment to deploy rules. For developers, rule deployment is part of application testing. For business users, rule deployment is part of specification, validation, and putting new or changed policies into production.

 

Schematic (taken from JRule6.6 quickstart)

2 The structure and operation principle of the rule engine project

2.1 Key terms of rule engine

　　All programs are algorithms and data structures, and rules engines are no exception. These business rules are actually programs, so naturally he also cares about these data structures. The data structure concerned in the rule engine is called BOM (Business Object Modal), that is, the business object model; the algorithm concerned in the rule engine is the rule.

　　Now let's focus on a few key terms in the rule engine:

• DTO (Data Translate Object, that is, the data transfer object)
• BOM (Business Object Modal, the Business Object Model)
• Ruleset (rule set)
• Ruleset Execute Flow
• Rule Runtime Context runtime context
• decision table
• decision tree

　　

　　

 

2.2 Modules of the rule engine

　　We mainly divide the rule engine into interface layer, adaptation layer, core, data layer, and rule management layer. The following figure shows the relationship between each layer.

　　当一次请求进入规则引擎时，即DTO，DTO具体的样式，可能是一份xml文档，或者是一段内存，序列化的对象等等；当然，这具体与规则引擎与应用程序的调用方式相关，比如使用http post请求：web service，或者是简单的xml对象模型的，当然也可以将之嵌入应用程序等，此是后话。当DTO经过适配层时，由适配层负责去访问其他的接口，或者是数据库，进行填充数据。为什么需要这个步骤呢？在这里举一个例子，这是一个计算购物折扣率的应用，应用程序过来的DTO中，肯定包含了购物车中的具体信息，包括所购商量的数量及价格，以及会员信息，但是，肯定不包含该会员的历史购买记录，如果这个时候，有这么一条规则，注册至今购买金额超过1W给予9折的优惠，那就得访问DB，统计该会员的注册至今的购买金额，并组成在规则中需要的BOM。

　　规则引擎核心得到BOM之后，将该对象（LUA中的Table)传入运行的上下文环境，然后对规则进行逐条运算，最终得到运算结果的输出BOM，中间可能也得经过适配层并访问DB填充数据成为DTO并返回给应用程序。