规则引擎

业务规则引擎是在运行时生产环境中执行一个或多个业务规则的软件系统。这些规则可以是法律规定（“员工因任何原因或无理由而被解雇，但不是因为非法原因而被解雇”），公司政策（“所有一次花费超过100美元的客户将获得10％的折扣” ）或其他来源。业务规则系统可以支持公司策略和其他操作决策能够与应用程序代码分开定义，测试，执行和维护。

规则引擎通常支持规则，事实，优先级（得分），互斥，先决条件和其他功能。

规则引擎软件通常作为业务规则管理系统的一个组件，除其他功能外，还提供以下功能：注册，定义，分类和管理所有规则，验证规则定义的一致性（“金级客户是当订单数量> 10“和”银级客户的最大订单数量= 15“时，才有资格获得免费送货），定义不同规则之间的关系，并将这些规则中一些与受影响或需要强制执行的IT应用程序相关联。

什么是规则：

# 规则是知识的一部分，通常表达为:“当一些条件出现时，就做一些任务。” 

When
    <Condition is true>
Then
    <Take desired Action>

# 规则最重要的部分是它的when部分。 如果满足WHEN部分要求，则触发THEN部分。


rule  <rule_name>
      <attribute> <value>
      
      when
         <conditions>
      
      then
         <actions>
end

模式匹配 

将新的或现有的事实与产生式规则进行匹配的过程称为模式匹配，由推理引擎执行。 有许多用于模式匹配的算法，包括:

• Linear
• Rete
• Treat
• Leaps

Drools实现并扩展了Rete算法。 Drools Rete实现称为RETEOO，这意味着Drools对面向对象系统的Rete算法进行了增强和优化。

规则引擎的优点 

声明式程序设计 

规则使表达困难问题的解决方案变得容易，并使解决方案得到验证。 与代码不同，规则是用不太复杂的语言编写的； 业务分析人员可以轻松地读取和验证一组规则。

逻辑与数据分离 

数据保留在域对象中，业务逻辑在规则中。 根据项目的类型，这种分离可能非常有利。

速度和可伸缩性 

编写Drools的Rete OO算法已经是一个经过验证的算法。 在Drools的帮助下，应用程序变得可伸缩。 如果存在频繁的更改请求，则可以添加新规则，而不必修改现有规则。

知识集中化 

通过使用规则，可以创建可执行的知识库（知识库）。 这是商业政策的唯一真理。 理想情况下，规则的可读性是如此之好，以至于它们也可以用作文档。

工具集成 

Eclipse之类的工具提供了编辑和管理规则以及获得即时反馈、验证和内容帮助的方法。 审计和调试工具也是可用的。

【来源：https://www.tutorialspoint.com/drools/drools_introduction.htm 】

IT使用

许多组织的规则原先努力将工作流设计与传统规则设计的方面结合起来。如果不能将这两种方法分开，就会导致重用和控制业务规则和工作流的能力出现问题。避免这种困惑的设计方法将业务规则和工作流的作用分开：

• 业务规则产生知识（knowledge）;
• 工作流程执行业务工作。

具体而言，这意味着业务规则执行检测已发生的事情的业务情况；检测引发业务事件（通常通过消息传递基础架构进行）；创建更高级别的业务知识（例如，评估组织，产品和关于贷款是否符合承保标准的基于监管的规则）。另一方面，工作流将通过启动一系列活动来响应指示诸如路由点过载之类的事件。

这种分离很重要，因为相同的商业判断（抵押符合承保标准）或商业事件（路由器过载）可以通过许多不同的工作流程作出反应。将响应规则驱动的知识创建而完成的工作嵌入到规则本身中会大大降低业务规则在整个组织中重用的问题，因为它使工作流特定于工作流。

为了创建业务规则引擎的体系结构，必须结合BPM（Business Process Management) 和BRM（Business Rules Management) 平台之间建立，这种集成基于对事件响应，检测业务判断流程的商业规则而制定的。市场上一些产品本身就是提供这种集成的。在其他情况下，这种类型的抽象和集成必须在特定的项目或组织中开发。

大多数基于Java的规则引擎提供基于JSR94应用程序编程接口（API）标准的技术调用级接口，以便允许与不同的应用程序集成，并且许多规则引擎允许通过基于Web的标准进行面向服务的集成，如：WSDL和SOAP。

大多数规则引擎都提供开发数据抽象的能力，该数据抽象表示应该编写规则的业务实体和关系。这种业务实体模型（ business entity model ）通常可以从各种源填充，包括XML、POJO、flat files等。没有标准语言用于编写规则本身。许多引擎使用类似Java的语法，而有些引擎允许自定义友好的业务语言的定义。

大多数规则引擎都是可调用的库。然而，越来越普遍的是，他们运行作为一个通用的过程类似于RDBMS的行为方式。大多数引擎将规则被视为要加载到其流程实例中的配置，尽管有些实际上是规则执行实例的代码生成器，而其他引擎则允许用户选择。

Types of rule engines

有许多不同类型的规则引擎。这些类型（通常）在如何调度规则执行时有所不同。企业使用的大多数规则引擎都是前向链接，可以进一步分为两类：

• 第一类：处理所谓的生产/推理规则。这些类型的规则用于表示IF类型的行为，然后表示动作。例如，这样的规则可以回答这样一个问题：“这个客户应该被允许抵押吗？”通过执行“如果有条件，然后允许客户-抵押”的规则。
• 另一种规则引擎：处理所谓的反应/事件条件动作规则。反应规则引擎检测和反应传入事件和处理事件模式。例如，当某些项目缺货时，可使用反应规则引擎来提醒管理者。

这些类型之间的最大区别在于，生产规则引擎是在用户或应用程序调用它们执行的，通常是无状态的。反应式规则引擎在事件发生时自动反应，通常是有状态的。许多（实际上大多数）流行的商业规则引擎都具有生成和反应规则能力。例如，大多数业务规则引擎主要是生产规则引擎，而复杂事件处理规则引擎则强调反应规则。

此外，一些规则引擎支持反向链接。在这种情况下，规则引擎试图解决符合特定目标的事实。它通常被称为“目标驱动”，因为它试图根据现有信息来确定一些东西是否存在。

另一类规则引擎在推理运行期间自动在反向和正向链接之间进行多次切换，例如，因特网业务逻辑系统，可以通过搜索网络找到。

第四类规则引擎可以称为确定性引擎（deterministic engine）。这些规则引擎可以放弃正向链接和反向链接，而是使用特定域的语言方法来更好地描述策略。这种方法通常更容易实现和维护，并且与正向或反向链接系统相比，有更好的性能优势。

在某些情况下，基于模糊逻辑（Fuzzy Logic）的推理可能更合适，其中在规则处理中使用启发式而不是布尔规则（Boolean rules）。示例可以包括客户分类、缺失数据推断、客户价值计算等。DARL语言和相关的推理引擎和编辑器是这种方法的示例。

访问控制/授权规则引擎（Rules Engines for Access Control / Authorization）

规则引擎的一个常见用例是对应用程序的标准访问控制。OASIS（定义了专用于访问控制的规则引擎体系结构和标准XACML（Access Control Markup Language）。XACML规则引擎和业务规则引擎之间的一个关键区别是XACML规则引擎是无状态的，并且不能改变任何数据的状态。XACML规则引擎称为策略决策点（Policy Decision Point）（PDP），它期望二进制Yes/Noquesty，例如“Alice查看文档D吗？”并返回一个决定，例如允许/拒绝。

【出处：https://en.wikipedia.org/wiki/Business_rules_engine#cite_note-1】

2. 发展历史

描述

大多数规则引擎都支持规则的次序和规则冲突检验，支持简单脚本语言的规则实现，支持通用开发语言的嵌入开发。目前业内有多个规则引擎可供使用，其中包括商业和开放源码选择。开源的代表是Drools，商业的代表是VisualRules ,iLog。很明显，业务规则引擎在应用领域得到的关注远比研究领域更多。

Computerworld上的一篇文章描述了20世纪90年代早期的规则引擎以及来自Pegasystems，Fair Isaac Corp和ILOG等产品的产品。

2004年，Jang, M., & Sohn, J. C.提出Bossam，基于owl推理的规则引擎。

OASIS Version 1.0 在 2003被成功的规范。版本2.0也在2005年一月发布。

之后，基于Java的规则引擎也被相继开发，如2008年，《the rule engine for the java platform》

XACML 3.0的第一次规范于2010年8月10日。 最新版本的XACML 3.0于2013年1月标准化。

规则引擎是解析、调用、执行规则包的服务，目前VisualRules采用java语言来实现规则引擎，并且提供了java类接口、Socket、Servlet、SOAP等多种外部调用接口。其实Java类接口是所有这些接口的核心，其他接口其实也是通过Java类接口来加以调用。考虑到最小化规则引擎，因此规则包的解析工作已经放在规则编辑时，预先进行了处理。规则引擎只处理规则包的调用和执行，同时为规则包用到的数据库接口、Excel接口、内存表接口、Xml接口提供缺省的实现。

【出处：https://en.wikipedia.org/wiki/Decision_theory#cite_note-8 】

主要事件

3. 发展分析

瓶颈

规则引擎产品有三种执行方式：基于Rete算法推理式、顺序执行、静态顺序执行。基于Rete算法推理式是绝大多数产品采用的一种方式。此种方式基于Rete算法进行模式匹配，在规则运行过程中耗费大量资源进行推理式解析。规则执行速度和效率低下。

除此之外，lua作为普通的脚本语言并非为了规则而生，因为如果要实现类似Jrule的中文描述规则将会有难度，并且如果要实现可视化设计逻辑，像设计流程图等等，在实现上要给lua脚本设计一个代码格式，代码标准，以使我们的编辑器实现可视化设计。因此，目前的理解而言，lua作为规则描述语言最大的缺点就在于可视化实现，当然也并非不可实现，但真的要费很大的劲。

最后，许多组织正从面向对象的业务流程管理范例转移到面向服务的方法；实际上，服务正在成为应用程序开发的基本元素。同时，业务流程执行语言(BPEL)已经成为编排这些服务和管理业务流程的无缺陷执行的事实标准。这些趋势所产生的结果是，为更灵活、更经济高效地管理业务流程提供了一些良机。

Contributor: Ruiying Cai

大多数业务流程（贷款审批就是一个典型示例）包含多个决策点。在这些决策点处，将对某个条件进行评估。业务流程根据这些标准或业务规则更改它们的行为。(一个是BPEL流程编排的分支可能存在规则，一个是BPEL中的活动节点本身可能存在数据处理规则。)实际上，这些业务规则对业务流程起到了推动作用。这些规则通常嵌入到业务流程本身或自定义Java代码的内部，这将导致在将来的某个时候出现若干问题：

• 业务规则比业务本身更改得更频繁，而更改和管理嵌入的业务规则是一个复杂问题，并超出了大多数分析员的能力范围。因此，随着业务规则的更改，程序员通常要消耗大量时间来执行该任务。
• 大多数组织都缺少中央规则信息库。策略中任何涉及到组织范围的更改都无法运用到所有业务流程中。
• 业务流程无法重用规则。因此，IT人员最终要为每个流程设计规则，这通常导致不一致性或冗余。

未来发展方向

结合BPEL：

避免这些问题的最佳方法是使用规则引擎将业务流程与业务规则分离。在这些方法中，规则公开为服务，而BPEL流程在到达决策点时通过查询该引擎来利用这些服务。该方法更为灵活-可以通过图形方式操作规则，而不是在编程语言中或在流程内部对规则进行编码。业务用户可以使用工具自行编写规则，并且无需IT人员的协助即可进行部署后的规则更改。由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。

Contributor: Ruiying Cai