规则引擎如何基于规则引擎打造规则库

｀Jess 1e 、｀Jess x１、是什么意思？

JESS是一个规则引擎。

　　它是一个使用sun公司Java语言编写的脚本环境，由Ernest Friedman-Hill在加拿大Livermore的Sandia National Laboratories里完成。

使用JESS，用户可以通过输入陈述性的规则来进行知识推理形成Java软件。

JESS是一个小型、轻型并且十分快速的规则引擎。

他强大的脚本语言能够给你所有的Java的API（应用程序接口）。

JESS包括一个基于Eclipse平台的完全特征化的开发环境。

　　JESS 使用一个增强版本的Rete 算法来产生规则。

Rete 是一个可以解决复杂多对多问题的非常有效的求解机制(详见 "Rete: A Fast Algorithm for the Many Pattern/ Many Object Pattern Match Problem", Charles L. y, Artificial Intelligence 19 (1982), 17-37.)。

　　JESS拥有许多独特的特征包括返回操作和工作记忆查询功能，当然，JESS能够直接对Java目标进行控制和推理。

JESS同时是一个强大的Java脚本环境，你可以从中创建Java模板，调用Java方法，而且可以不用编译任何Java代码来执行Java的接口。

ilog是什么意思?

ILOG 拥有十年以上开发创新解决方案的经验，对项目解决方案具有独特的洞察力。

使用ILOG 技术，您可以创建无与伦比的软件应用程序。

ILOG 的研发工作致力于为客户提供最先进的产品。

业务规则使用ILOG 业务规则管理系统可让应用程序更具灵活性。

ILOG 业务规则引擎可在整个企业内部署和应用策略变化。

您可根据客户需求、规章变化和竞争情况迅速做出反应。

优化研发最好的规划和计划，以使服务、收入和利润最大化。

ILOG 优化技术可处理任意数目的运营约束。

帮您赢得自信，运筹帷幄，在正确的时间做出正确的决定，从而降低风险。

可视化使用 ILOG 可视化技术生动地显示复杂的数据。

ILOG 可视化勾画出总体形势，把原始数据转换成有用的信息。

可以通过行动信息的实时图像迅速获得数据。

专业服务以来自 ILOG 顾问的专家视角，让项目更快稳步启动。

ILOG 顾问都是应用 ILOG 技术的专业人士。

无论您身处哪个行业，我们的最佳实践都能帮助您加速研发和部署。

遍布全球的办事处为您提供优质的服务 ILOG 办事处遍布全球，相互联网，可为客户提供有力支持。

可在全球范围内提供销售、培训和咨询支持。

研发中心位于法国和美国。

在中国、德国、日本、新加坡、西班牙和英国的 ILOG 主办事处和子公司均设有销售和咨询团队。

无论何地，都可通过遍及世界的合作伙伴和供应商网络获取 ILOG 软件。

依赖于 ILOG 的主要行业客户 ILOG 客户包括来自许多行业的领先公司： 银行和金融业 企业资源计划 (ERP) 供应商 航空业 港口和机场 制造企业，如 Siemens、DaimlerChrysler 和 Nippon Steel 通讯设备制造商和网络运营商 2009年1月8日，IBM宣布其已完成以约3.4亿美元（相当于2.15亿欧元）现金收购ILOG（NASDAQ：ILOG）的股份。

自此ILOG收归IBM名下。

ILOG产品介绍 Ilog 主要包括以下四部分，分别为： ILOG业务规则管理系统 ILOG业务规则管理系统(BRMS)让您的应用程序更加灵活，快速应对客户需求，法规变动和外部竞争。

业务规则引擎对整个企业的政策变更进行快速部署及实施. ILOG优化 为您制定最佳的方案和时间表，最大限度地提高服务、增加收入和利润。

ILOG优化足以应对许多的工作约束，让您在合适的时间作出正确的决定。

ILOG可视化 ILOG可视化让复杂的数据具有生命，大大缩减开发时间。

图形化工具明朗化数据转换方向，把原始数据转换为可用的信息。

ILOG供应链应用 供应链应用程序帮您实现卓越经营，改善业绩，您可以在复杂的动态环境中发现机遇并做出最有效权衡。

ILOG LogicTools软件组包括Plant PowerOps、LogicNet Plus XE、Inventory Analyst

Java规则引擎如何集成

Java 规则引擎是一种嵌入在 Java 程序中的组件，它的任务是把当前提交给引擎的 Java 数据对象 ( 原料 ) 与加载在引擎中的业务规则（ app ）进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。

引言： 目前， Java 社区推动并发展了一种引人注目的新技术 ——Java 规则引擎（ Rule Engine ）。

利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。

规则引擎的原理 1 、基于规则的专家系统（ RBES ）简介 Java 规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。

专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。

为了更深入地了解 Java 规则引擎，下面简要地介绍基于规则的专家系统。

RBES 包括三部分：Rule Base （ knowledge base ）、 Working Memory （ fact base ）和 Inference Engine 。

它们的结构如下系统所示： 图 1 基于规则的专家系统构成 如图 1 所示，推理引擎包括三部分：模式匹配器（ Pattern Matcher ）、议程（ Agenda ）和执行引擎（Execution Engine ）。

推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。

模式匹配器决定选择执行哪个规则，何时执行规则；议程管理模式匹配器挑选出来的规则的执行次序；执行引擎负责执行规则和其他动作。

和人类的思维相对应，推理引擎存在两者推理方式：演绎法（ Forward-Chaining ）和归纳法（ Backward-Chaining ）。

演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。

而归纳法则是根据假设，不断地寻找符合假设的事实。

Rete 算法是目前效率最高的一个 Forward-Chaining 推理算法，许多 Java 规则引擎都是基于 Rete 算法来进行推理计算的。

推理引擎的推理步骤如下： (1) 将初始数据（ fact ）输入 Working Memory 。

(2) 使用 PatternMatcher 比较规则库（ rule base ）中的规则（ rule ）和数据（ fact ）。

(3) 如果执行规则存在冲突（ conflict ），即同时激活了多个规则，将冲突的规则放入冲突集合。

(4) 解决冲突，将激活的规则按顺序放入 Agenda 。

(5) 使用执行引擎执行 Agenda 中的规则。

重复步骤 2 至 5 ，直到执行完毕所有 Agenda 中的规则。

上述即是规则引擎的原始架构， Java 规则引擎就是从这一原始架构演变而来的。

2 、规则引擎相关构件 规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。

与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。

1) 信息元（ InformationUnit ） 信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。

这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。

2) 信息服务（ InformationServices ） 信息服务产生信息元对象。

每个信息服务产生它自己类型相对应的信息元对象。

即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。

需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。

但无论如何，每个信息服务只产生它自己类型相对应的信息元。

3) 规则集（ Rule Set ） 顾名思义，规则集就是许多规则的集合。

每条规则包 含一个条件过滤器 和多个动作 。

一个条件过滤器可以包含多个过滤条件。

条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。

在程序运行时， 动作将会在条件过滤器值为 true 的情况下执行。

除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（ Discard Action ）、包含动作（ Include Action ）和使信息元对象内容持久化的动作。

前两种动作类型的区别将在 2.3 规则引擎工作机制小节介绍。

4) 队列管理器（ QueueManager ） 队列管理器用来管理来自不同信息服务的信息元对象的队列。

下面将研究规则引擎的这些相关构件是如何协同工作的。

如图 2 所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。

图 2 处理过程协作图 3 、规则引擎的工作机制 下面专门研究规则引擎的内部处理过程。

如图 3 所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定义顺序检查信息元所带规则集中的规则（规则已经排队就绪等待信息元的到来）。

如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下一条规则。

如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。

该信息元中的所有规则执行完毕后，信息元将被销毁 ，然后从队列管理器接收下一个信息元。

在这个过程中并未考虑两个特殊动作：放弃动作（ Discard Action ）和包含动作（ Include Action ）。

放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元 ( 就是短路了 ) 。

包含动作其实就是动作中包含其它现存规则集的动作。

包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。

这一过程将递归进行。

图 3 规则引擎工作机制 Java 规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。

Java 规则引擎对提交给引擎的 Java 数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。

这些实例将在引擎接到执行指令时、依照某种优先序依次执行。

一般来讲， Java 规则引擎内部由下面几个部分构成： 工作内存（ Working Memory ）即工作区，用于存放被引擎引用的数据对象集合； 规则执行队列，用于存放被激活的规则执行实例 ; 静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织， 当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。

Java 规则引擎的结构示意图如图 4 所示。

图 4 Java 规则引擎工作机制 当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。

于是就产生了一种 “ 动态 ” 的规则执行链，形成规则的推理机制。

这种规则的 “ 链式 ” 反应完全是由工作区中的数据驱动的。

任何一个规则引擎都需要很好地解决规则的推理机制 和规则条件匹配的效率问题 。

规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。

1982 年美国卡耐基 ? 梅隆大学的 Charles L. y 发明了一种叫 Rete 算法，很好地解决了这方面的问题。

目前世界顶尖的商用业务规则引擎产品基本上都使用 Rete 算法。

如何基于规则引擎打造规则库

1、业务逻辑从程序代码中脱离出来。

通过配置来实现业务规则。

2、业务规则的变更，可以直接由用户通过web界面来修改和变更。

针对这一类需求情况，其实我们有一般由以下的几种可选方案： 1、选择规则引擎来实现。

现有的规则引擎产品一般都能满足以上这两种要求。

可以不用代码，比如Java来实现业务逻辑，而采用规则语言通过规则配置器来完成。

用户需要变更时，一般都会提供C/S或者B/S版本的规则配置器来实现。

2、采用动态语言： 直接采用JS或者其他的动态语言BeanShell等，也可以实现不通过Java代码来实现业务逻辑。

通过也可以提供一个编辑界面，让用户来进行修改。

3、表格配置或者自定义公式 通过定义一个表格或者加上一定的自定义公式语法来实现具体的逻辑。

以上几种方案，在不同的项目中，都有各自的优缺点： 1、采用规则引擎实现，使得业务规则的配置更加标准化、专业化。

同时一般的规则引擎都会对修改的记录进行版本控制，以便于跟踪、测试、恢复等操作。

规则配置器一般提供的界面，更加人性化，用户使用上更加便捷。

缺点是会使得整个系统的架构变得庞大，需要有人专门负责研究规则引擎，以及相关的配置和管理工具。

2、采用动态语言的实现，对于开发上会更加简单。

动态语言一般纯粹处理逻辑，因此接口设计上会更加容易。

同时使用动态语言时，一般很少会去考虑继承关系、相互调用等问题。

缺点是可支持的逻辑相对扁平化，也相对简单。

同时动态语言需要有个学习过程。

3、通过表格配置以及自定义公式，是一般项目中最常用的。

通过一个配置表来实现对应管理、逻辑流转。

这种方式对于用户来说最友好，用户操作上更加方便，问题也最少。

缺点是不够灵活，开发工作量大。

以上这些考虑，都只是从一个技术角度出发，如何将一个技术编码工作，因为需求的不断变化，而更换一种实现方式。

使得不会因为需求变化，而造成对代码的改动。

因为代码改动会带来一系列的问题，变更流程、测试、部署等等。

但是我们既然已经将和业务相关的业务逻辑，从程序中脱离出来，就不能仅仅停留在开发实现阶段。

而应该将其纳入到客户的管理系统中。

成为用户系统管理的一部分。

比如我们至少应该考虑，用户可以查阅有多少业务规则，是可以由用户配置，哪些人对哪些业务规则有查看、创建、修改、删除权限，谁在何时进行了修改，谁负责的测试，测试结果如何，什么时候应用了新的修改之后的业务规则等等。

在这种情况下，我们不能仅从规则引擎工具的角度来考虑这个实现问题，而应该从规则库管理角度来考虑问题。

因此，不管我们是采用规则引擎还是动态语言，来实现业务逻辑供用户自己维护修改。

就应该加强更多的用户维护方面的管理功能，使得这个工作更加标准化、规范化。

实现一个业务规则库，需要考虑以下方面的问题： 1、用户权限管理。

采用现有的应用系统的权限系统，增加相应的针对规则的权限设置。

2、规则权限设置时，需要考虑查看、创建、修改、删除、测试、审核、发布、执行等权限。

3、规则分类的考虑。

考虑多种方式来进行分组，用户角色权限按照规则组进行分配。

4、规则版本控制：可以设置规则的版本号，可以设置规则组的标签，以便测试发布是区分。

5、规则的单独测试：对于规则的测试，可以设置批量测试用例，可以在线执行测试。

当然，如果应用系统是集群的，还需要考虑集群方面的问题。

因此规则的执行中，最好是无状态的。

在将业务规则从程序中脱离出来进行管理，是解决用户需求变更的有效手段，同时我们应该需要用规则库管理的思想来更近一步，达到规范、标准、统一。