规则引擎(DROOLS)培训资料v1.0.0

规则引擎(DROOLS)培训

DROOLS培训（5天）

目的：

重点讲解DROOLS是什么、能做什么、工作流程、怎么用到系统中，让学习人员可以对DROOLS有个全面初步的了解，并能够用DROOLS进行简单的系统开发。

参加人员：

需要使用DROOLS进行系统设计和开发或者对DROOLS感兴趣的同事。

主讲人员：

第一章 DROOLS 入门

第 1 节什么是DROOLS

如何组织企业应用中的业务逻辑，如果靠手工的代码来解决。随着大量业务规则的变化，导致应用程序不停的变更，如何能找到一种解决商业逻辑的架构，来解决当商务规则不停的变化时，可以保证我们的应用系统具有较好的柔韧性，可以适应特定的商务规则的变化，而无需修改我们的应用系统。Drools就是这样的一个应用在商务逻辑层的架构。

CODEHAUS的一个开源项目叫Drools，Drools是为Java量身定制的基于RETE算法的规则引擎的实现。

具有了OO接口的RETE,使得商业规则有了更自然的表达。Drools是用Java写的，但能同时运行在Java 和.Net上。最近被纳入JBOSS门下，更名为JBOSS Rules，成为了JBOSS应用服务器的规则引擎。

RETE算法是CHARLES FORGY在1979年发明的。RETE是唯一的，效率与执行规则数目无关的决策支持算法。For the uninitiated, that means it can scale to incorporate and execute hundreds of thousands of rules in a manner which is an order of magnitude more efficient then the next best algorithm。

RETE应用于生产系统已经有很多年了，但在Java开源软件中并没有得到广泛应用，直到DROOLS的出现。第 2 节 DROOLS能做什么

大多数web和企业Java应用可以分成三个部分：一个和用户交互的前台, 一个和后台系统，例如数据库交互的服务层，以及他们中间的业务逻辑。现在使用框架构建前台和后台系统已经成为普遍共识(例如, Struts, Cocoon, Spring, Hibernate, JDO, 和 Entity Beans), 但却没有一个标准的方法来构建业务逻辑。一些框架，例如 EJB 和 Spring 只在一个高层实现业务逻辑，但对于我们组织逻辑代码没有任何帮助，所以，为什么没有一个框架来替换冗繁，易错的if...then语句呢，这个框架应该和其它前台或后台框架一样，易于配置，具有可读性和重用性。Drools 规则引擎，这个就是来解决我们上述问题的框架。

第 3 节为什么使用DROOLS

软件应用领域充满了变化。在技术领域里，IT从业人员也在不断探索各种软件方法学，来适应用的变化，如快速软件开发，极限编程，敏捷软件开发等，它们无一例外地强调灵活和变化的重要性。

虽然IT团队反应迅速，但他们通常带来"电话效应"―IT给商业计划的执行带来的阻力和它带来的利益一样多。不幸的是，在开发团队完全理解商业决策规则并实现之前，规则已经改变了。在软件进入市场前，它已经过时了，需要进行重构以满足新的业务需求。如果你是一个开发人员，你会知道我在说什么。

再也没有比在需求变动的情况下构造软件让开发人员更沮丧的事情了。作为软件开发人员，你必须象业务人员一样了解业务，有时还要了解更多。

试想一下你是一位商业决策者。假如公司的成功依赖于你对于市场趋势敏锐的洞察力，它常常帮助你领先于竞争者利用变化的市场环境获利。每天你都会得到更多更好的市场信息，但并不要紧。完成新产品开发可能需要6－9个月，在此期间，对于市场大胆和敏锐的洞察和信息优势可能已经浪费了。而且，当产品发布时，有这样几种可能：产品没有什么吸引人的特性，预算超支，过了产品的最佳发布期限，或三者兼而有之。

情况可能还会更糟，在完成产品开发时，市场环境和规划产品开发时相比，已经发生了根本变化。现在你必须要遵守新的规则，你已经丧失了你的边际优势，而且设计软件的五人中的三人已经离开了公司。

你必须给接手的新人重新讲解复杂的业务。如果事情不顺利，你可能发现自己要对付一个缺少文档，并且你完全不了解的遗留应用。

你的战略在哪出现了问题？你在哪里应该可以做到更好？最近的轻量级软件过程，如极限编程，敏捷软件开发等都在强调自动单元测试和软件功能优先级的重要性。除此之外，还有其他的原则，你的开发团队可能也很熟悉，这些原则可以帮助他们对需求的变动做出迅速反应并缩短项目的开发周期。这些原则的大多数，如系统分解，多年前就已经出现，并得到了Java平台的支持（如JMX等），还有如面向对象和角色建模，已经内建在Java语言中。

为什么你的开发团队不得不像商业经理人一样，在代码中包含复杂微妙的商业决策逻辑呢？你怎样才能向他们解释决策推理的微妙之处呢？你这样做是否谨慎呢？可能不是。为什么要冒这样的风险，让应用代码或测试代码错误地表达你的商业决策逻辑呢？如果这样做的话，你怎样检查它们的正确性呢---难道你自己想学习如何编程和编写测试代码，或者你的客户会为你测试软件？你一方面要应付市场，一方面要应付软件代码，这实在太困难了。

如果使用DROOLS开发系统就能将这些商业决策规则集中地放在一个地方，以一种你可以理解的格式定义，让你可以直接管理，而不是散落在代码的各个角落。这样你就能把商业决策规则独立于你的软件代码，让开发团队做出技术决策，你将会获得更多好处。你的项目开发周期会更短，软件对于变动的需求更灵活。

第 4 节什么样的系统适合用DROOLS

既然DROOLS可以使程序更灵活，适应变化的能力更强，是否所有的系统都适合用DROOLS开发呢？回答是否定的！

是否需要用DROOLS，需要考虑一下问题：

第一：我的应用程序有多复杂?

对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你轻松应对这一切。

第二：我的应用的生命周期有多久？这个问题的正确答案往往是“令人惊讶的长”――还记得那些认

为他们的程序不会苟活到2000年的大型机的程序员吗？使用规则引擎将会在中长期得到好处。像这篇文章所展示的那样，甚至原型都能从Drools与灵活方法的组合中获益，让“原型系统”转化成生产系统。

第三：我的应用需要改变吗？唯一能确定的是你的需求将会改变，无论是在开发过程中或是在开发完成以后。Drools使用一个或多个简单的DRL文件帮你来应对这一切。

第 5 节规则引擎的框架结构

Drools 分为两个主要部分：构建（ Authoring ）和运行时（ Runtime ）。构建首先会使用 DRL 文件进行创建规则。运行时要构造出fact，把fact放入working memory 进行规则匹配。

1Production memory

规则加载流程：

首先创建xml或drl 规则文件→将规则文件加载到Parser(解析器)中→产生中间结构descr→使用Package Builder对中间结构descr 进行执行和编码→并且返回package对象。（package对象中包含1个或者多个规则）。

RuleBase是一个运行时组件，它包含了一个或多个 Package 对象。

RuleBase中可以包含一个或者多个package对象，并且可以在任何时刻将一个 Package 对象加入或移出 RuleBase 对象，RuleBase可以在任何时刻创建一个或者多个Working Memory对象。

2WorkingMemory

WorkingMemory是运行时规则引擎的主要类。它保持了所有被asserted 进WorkingMemory 的数据的引用，直到取消（ retracted ）。 WorkingMemory 是有状态对象。

它们的生命周期可长可短。如果从一个短生命周期的角度来同一个引擎进行交互，意味着你可以使用 RuleBase 对象来为每个 session 产生一个新的 WorkingMemory ，然后在结束session 后 discard 这个 WorkingMemory （产生一个 WorkingMemory 是一个廉价的操作）。另一种形式，就是在一个相当长的时间中（例如一个conversation ），保持一个WorkingMemory ，并且对于新的facts 保持持续的更新。当你希望dispose 一个WorkingMemory 的时候，最好的实践就是调用 dispose() 方法，此时 RuleBase 中对它的引用将会被移除（尽管这是一个弱引用）。不管怎样最后它将会被当成垃圾收集掉。术语WorkingMemory Actions 代表了对WorkingMemory 的assertions ，retractions 和modifications 。

2.1Facts

Facts 是从你的应用中，被 assert 进 WorkingMemory 中的对象（ beans ）。 Facts 是规则可以访问的任意的 java 对象。规则引擎中的 facts 并不是“ clone ” facts ，它只是持有到你的应用中数据的引用。 Facts 是你的应用数据。 String 和其他没有 getter 和setter 的类不是有效的 Fact 。这样的类不能使用域约束（ Field Constraints ），因为使用域约束要依靠 JavaBean 标准的 getter 和 setter 来同对象交互。

2.2Assertion

“Assertion”是将 facts 加入事实库的动作，例如 WorkingMemory.assertObject (yourObject) 。当你 assert 一个 fact ，它将被检查是否匹配规则。这意味着所有的匹配工作将会在 assert 的过程中完成。尽管如此，当你完成 assert facts 之后，你还要调用“ fireAllRules() ”方法来执行规则。

当一个对象被 assert 后，会返回一个 FactHandle 。这个 FactHandle 是一个代表在Working Memory 中你的 asserted Object 的令牌（ token ）。当你希望 retract 或者modify 一个对象的时候，这个令牌让你用来同 WorkingMemory 进行交互。

Cheese stilton = new Cheese( " stilton " );

FactHandle stiltonHandle = workingMemory.assertObject( stilton );

WorkingMeomry 有两种assertion 模式：Equality 和Identity （默认是Identity ）。

Identity 模式下 WorkingMemory 使用一个 IdentityHashMap 来存储所有的 asserted Objects 。这个模式下，当asserted 的Object 是同一个实例时，它返回同一个FactHandle 。

Equality 模式下WorkingMemory 使用一个HashMap 来存储所有的asserted Objects 。这个模式下，当 asserted 的 Object 相等时，它返回同一个 FactHandle 。

WorkingMemory.assertObject(yourObjcet) 只是进行 assertion 的一种 regular 方法，还存在有一种称为 logical assertion 的动作。

2.3Retraction

基本上就是 assert 的逆操作。当你 retract 一个 fact ， WorkingMemory 将不再跟踪那个 fact 。任何被 activated 并依赖那个 fact 的规则将被取消。注意：完全有可能存在某条规则是依赖于一个 fact 的“不存在”（ non existence ）。在这种情况下， retract 一个 fact 将导致一条规则被激活。对一个 Fact 进行 Retraction ，必须用 assert 时返回的那个 FactHandle 做为参数。

Cheese stilton = new Cheese( " stilton " );

FactHandle stiltonHandle = workingMemory.assertObject( stilton );

.

workingMemory.retractObject( stiltonHandle );

2.4Modification

当一个 Fact 被修改了，会通知规则引擎进行重新处理。在规则引擎内部实际上是对旧的 Fact 进行 retract ，然后对新的 Object 再进行 assert 。要使用 modifyObject() 方法来通知Working Memory ，被改变的Object 并不会自己通知规则引擎。注意：modifyObject() 方法总是要把被修改的 Object 做为第二参数，这就允许你把一个不可变对象替换为另一个新对象。

Cheese stilton = new Cheese( " stilton " );

FactHandle stiltonHandle = workingMemory.assertObject( stilton );

.

stilton.setPrice( 100 );

workingMemory.modifyObject( stiltonHandle, stilton );

2.5Globals

Global 是一个能够被传进 WorkingMemory 但不需要 assert 的命名对象。大多数这些对象被用来作为静态信息或服务。这些服务被用在一条规则的 RHS ，或者可能是从规则引擎返回对象的一种方法。

List list = new ArrayList（）;

workingMemory.setGlobal( " list " , list);

setGlobal() 方法传进去的命名对象必须同 RuleBase 中所定义的具有相同的类型（就是要同你的规则文件中用Global 关键字所定义的类型相同），否则会抛出一个RuntimeException 。如果一条规则在你 setGlobal 之前调用了定义的 Global ，会抛出一个 NullPointerException 。

2.6Property Change Listener

如果你的fact 对象是JavaBean ，你可以为它们实现一个property change listener ，然后把它告诉规则引擎。这意味着，当一个 fact 改变时，规则引擎将会自动知道，并进行响应的动作（你不需要调用 modifyObject() 方法来通知 WorkingMemory ）。Proxy libraries 将会帮助实现这一切。要让 Property Change Listener 生效，还要将 fact 设置为动态（ dynamic ）模式，通过将 true 做为 assertObject() 方法的第二个参数来实现：

Cheese stilton = new Cheese( " stilton " );

FactHandle stiltonHandle = workingMemory.assertObject( stilton, true ); //specifies t

hat this is a dynamic fact

然后要在JavaBean 中加入一个PropertyChangeSupport 实例，和两个方法：addPropertyChangeListener() 和 removePropertyChangeListener() 。最后要在 JavaBean

的 setter 方法中通知 PropertyChangeSupport 所发生的变化。示例代码如下：

private final PropertyChangeSupport changes = new PropertyChangeSupport( this );

public void addPropertyChangeListener( final PropertyChangeListener l) {

this .changes.addPropertyChangeListener( l );

}

public void removePropertyChangeListener( final PropertyChangeListener l) { this .changes.removePropertyChangeListener( l );

}

public void setState( final String newState) {

String oldState = this .state;

this .state = newState;

this .changes.firePropertyChange( " state " , oldState, newState );

2.7Agenda

基本流程：首先通过fire Rule –〉将相应的细节对象加载到事实库(Working Memory) 和相应的规则→确定单个细节对象对应的规则（规则可以为多个）→将规则和对象进行匹配并且加载，相应匹

配成功和不成功所触发的事件。

1、匹配成功后→Fire Rule查找是否有相应 rule进行匹配，有将继续执行rule流程，没有→exit

2、匹配不成功后→exit

jBoss Rule 中提供了两种算法

1、RETE算法通过节点之间的共享提供性能

2、Leaps算法迭代匹配

第 6 节规则引擎的工作流程

数据被 assert 进 WorkingMemory 后，和 RuleBase 中的 rule 进行匹配（确切的说应该是 rule 的 LHS ），如果匹配成功这条 rule 连同和它匹配的数据（此时就叫做Activation ）一起被放入 Agenda ，等待 Agenda 来负责安排激发 Activation （其实就是执行 rule 的 RHS ），上图中的菱形部分就是在 Agenda 中来执行的， Agenda 就会根据冲突解决策略来安排 Activation 的执行顺序。菱形部分执行完后会查找一下是否有新的规则需要匹配，如果有进入下一个匹配循环，如果没有结束退出。

第二章 DROOLS规则

第 1 节规则简介

既然JBoss Rules是一个商业规则引擎，那我们就要先知道到底什么是Rules，即规则。

在JBoss Rules中，规则是如何被表示的。

Drools 3 的rule采用了原生的规则语言，那是一种非 XML 文本格式。在符号方面，这种格式是非常轻量的，并且通过“ expanders ”支持符合你问题域的 Domain Specific Language （ DSL ）。下面重点介绍 Drools 规则格式。

1.1规则

一条规则是对商业知识的编码。一条规则有 attributes ，一个 Left Hand Side （ LHS ）和一个 Right Hand Side （ RHS ）。 Drools 允许下列几种 attributes ： salience ，agenda-group ， no-loop ， auto-focus ， duration ， activation-group 。

rule “ < name > ”

< attribute > < value >

when

< LHS >

then

< RHS >

end

规则的 LHS 由一个或多个条件（ Conditions ）组成。当所有的条件（ Conditions ）都满足并为真时， RHS 将被执行。 RHS 被称为结果（ Consequence ）。 LHS 和 RHS 类似于：

if ( < LHS > ) {

< RHS >

}

1.1规则文件

同一个package的规则通常被组织为一个规则文件，规则文件通常是一个以 .drl 扩展名结尾的文件。一个 DRL 文件是一个简单的文本文件。

1.1规则的结构

一个规则结构大致如下：

可以看到，这是非常简单的。通常的标点符号都是不需要的，甚至连“ name ”的双引号都是不需要的。 ATTRIBUTES 是简单的，也是可选的，来提示规则的行为方式。 LHS 是规则的条件部分，需要按照一定的语法来写。 RHS 基本上是一个允许执行 Java 语法的代码的块（以后将会支持 groovy 和 C ＃）。任何在 LHS 中使用的变量都可以在 RHS 中使用。

注意：每行开始的空格是不重要的，除非在 DSL （ Domain Specific Language ）语言中有特别的指明。

1.1Domain Specific Language

Domain Specific Language 是对原生规则语言的加强。它们使用“ expander ”机制。Expander 机制是一种可扩展的 API 。你可以使用 .dsl 文件，来提供从域或自然语言到规则语言和你的域对象的映射。你可以将 .dsl 文件看成是对你的域模型的映射。 DSL 提供了更高的规则可读性，你可以选择使用你自己创建的 DSL ，或者是原生的规则语言。

1.1保留字

在规则语言中存在一些保留字。你应该避免使用这些保留字，来命名规则文本中的域对象，属性，方法，功能。保留字如下： when ， then ， rule ， end ， contains ， matches ，and ， or ， modify ， retract ， assert ， salience ， function ， query ， exists ，eval ， agenda-group ， no-loop ， duration ， -> ， not ， auto-focus 。

第 2 节规则语法

2.1注释

单行注释

Figure 2.1.1 import

示例：

// 下面是一条规则

# 规则名称

rule " name "

ATTRIBUTES

when

LHS

then

RHS

end

多行注释

Figure 2.1.2 import

示例：

/* 下面是一条规则

规则名称

*/

rule " name "

ATTRIBUTES

when

LHS

then

RHS

end

2.2Package

代表了一个命名空间（具体感觉和java中的package相似）用来使给定的规则组之间保持唯一性

Figure 2.2. import

2.3Import

Figure 2.3. import

Import 语句的使用很像 Java 中的 import 语句。你需要为你要在规则中使用的对象，指定完整的路径和类名。 Drools 自动从相同命名的 java 包中引入所需的类。

2.4Expander

Figure 2.4. expander

expander 语句是可选的，是用来指定 Domain Specific Language 的配置（通常是一个 .dsl 文件）。这使得解析器可以理解用你自己的 DSL 语言所写的规则

2.5Global

Figure 2.5. global

Global 就是全局变量。如果多个 package 声明了具有相同标识符的 global ，那么它们必需是相同的类型，并且所有的引用都是相同的

注意： global 只是从你的 application 中传入 WorkingMemory 的对象的命名实例。这意味着你可以传入任何你想要的对象。你可以传入一个 service locator ，或者是一个 service 本身

2.6Function

Figure 4.1. function

Function 最有用的就是在规则的 RHS 调用 actions ，特别是当那个 action 需要反复调用的时候。

一个典型的 function 声明如下：

function String calcSomething(String arg) {

return " hola ! " ;

}

注意：“ function ”关键字的使用，它并不真正是 Java 的一部分。而 function 的参数就像是一个普通的 method （如果不需要参数就不用写）。返回类型也跟普通的 method 一样。在一条规则（在它的 RHS 中，或可能是一个 eval ）中调用 function ，就像调用一个 method 一样，只需要 function 的名字，并传给它参数。

function 的替代品，可以使用一个 Helper 类中的静态方法： Foo.doSomething() ，或者以 global 的方式传入一个 Helper 类或服务的实例： foo.doSomething() （ foo 是一个命名的 global 变量）。

2.7Rule

规则的 LHS 跟在“ when ”关键字的后面（最好是另起一行），同样 RHS 要跟在“ then ”关键字后面（最好也另起一行）。规则以关键字“ end ”结束。规则不能嵌套。

2.7.1Left Hand Side

判断的条件

Figure 5.2. Left Hand Side

Figure 5.3. pattern

2.7.2Right Hand Side

执行的操作可以使用java代码

modify(obj) ：告诉引擎一个对象已经发生变化，规则必须重新匹配（ obj 对象必须是出现在 LHS 中的对象）；

assert(new Something())：将一个新的 Something 对象加入 WorkingMemory ；

assertLogical(new Something())：与 assert 方法类似。但是，当没有 fact 支持当前激发规则的真实性的时候，这个新对象会自动被 retract ，

retract(obj)：从 WorkingMemory 中移除一个对象。

2.7.3R ule Attributes

Figure 5.4. rule attributes

2.7.

3.1 no-loop：

默认值： false

类型： boolean

当在 rule 的 RHS 中修改了一个 fact ，这可能引起这个 rule 再次被 activate ，引起

递归。将 no-loop 设为 true ，就可以防止这个 rule 的 Activation 的再次被创建。2.7.3.2 Salience

默认值： 0

类型： int

每个 rule 都可以设置一个 salience 整数值，默认为 0 ，可以设为正整数或负整数。

Salience 是优先级的一种形式。当处于 Activation 队列中时，拥有高 salience 值的

rule 将具有更高的优先级。

2.7.

3.3 agenda-group

默认值： MAIN

类型： String

Agenda group 允许用户对 Agenda 进行分组，以提供更多的执行控制。只有具有焦点的组

中的 Activation 才会被激发（ fire ）。

2.7.

3.4 auto-focus

默认值： false

类型： boolean

当一个规则被 activate （即 Activation 被创建了），如果这个 rule 的 auto-focus 值

为 true 并且这个 rule 的 agenda-group 没有焦点，此时这个 Activation 会被给予焦

点，允许这个 Activation 有 fire 的潜在可能。

2.7.

3.5 activation-group

默认值： N/A

类型： String

当处于同一个activation-group 中的第一个Activation fire 后，这个

activation-group 中其余剩下的 Activation 都不会被 fire 。

2.7.

3.6 Duration

默认值：没有默认值

类型： long

设置运行时间的

2.7.

3.7Column

Figure 5.5. Column

2.7.

3.8Field Constraints

使规则引擎可以从 WorkingMemory 中挑选出合适的 Fact 对象。一个 Fact 的“ Field ”必须符合JavaBean 规范，提供了访问 field 的 getter 方法。你可以使用 field 的名字直接访问 field ，或者使用完整的方法名（省略括号）。

2.7.

3.9Operators

Figure 5.7. Operators

有效的操作符是同域类型相关的。例如，对于日期域，“ < ”意味着“之前”。“ matches ”只适用于 String 域，“ contains ”和“ excludes ”只适用于 Collection 类型域。

2.7.

3.10字面值约束（ Literal Constraints ）

最简单的域约束就是字面值约束，允许用户将一个 field 约束于一个已知值。

注意：你可以检查域是否为 null ，使用 = = 或 != 操作符和字面值‘ null ’关键字。如，Cheese(type != null) 。字面值约束，特别是“ = = ”操作符，提供了非常快的执行速度，因为可以使

用散列法来提高性能。

Figure 5.8. Literal Constraints

Example 5.3 . Numeric Literal Constraint

Cheese( quantity == 5 )

Example 5.4. Date Literal Constraint

你可以通过指定 drools.dateformat 系统属性，来改变默认的日期格式

Cheese( bestBefore < " 27-Oct-2007 " )

Example 5.5. String Literal Constraint

Cheese( type == " stilton " )

Example 5.6 Boolean Literal Constraint

Cheese( smelly = = true )

Example 5.7. Regular Expression Constraint

Cheese( type matches " (Buffulo)?\\S*Mozerella " )

Example 5.8. Literal Cosntraints with Collections

CheeseCounter( cheeses contains " stilton " )

CheeseCounter( cheeses excludes " chedder " )

2.7.

3.11 Bound Variable Constraint

可以将 Facts 和它们的 Fields 附给一个 Bound Variable ，然后在后续的 Field Constraints 中使用这些 Bound Variable 。一个 Bound Variable 被称为声明（ Declaration ）。 Declaration 并不能和“ matches ”操作符合用，但却可以和“ contains ”操作符合用。

Example 5.9. Bound Field using '==' operator

Person( likes : favouriteCheese )

Cheese( type == likes )

Example 5.10 Bound Fact using 'contains' operator

$stilton : Cheese( type == " stilton " )

Cheesery( cheeses contains $stilton )

2.7.

3.12 Predicate Constraints

Figure 5.9. Predicate expression

Predicate 表达式可以使用任何有效的 Java 逻辑表达式。先前的 Bound Declaration 可以用在表达式中。

下面的例子将会找出所有男性比女性大 2 岁的 pairs of male/femal people ：

Example 5.11. Predicate Constraints

Person( girlAge : age, sex = = " F " )

Person( boyAge : age -> ( girlAge.intValue() + 2 == boyAge.intValue() ), sex = = " M " )

2.7.

3.13 Return Value Constraints

Figure 5.10. Return Value expression

Example 5.12. Return Value Constraints

Person( girlAge : age, sex = = " F " )

Person( age = = ( new Integer(girlAge.intValue() + 2 ) ), sex = = " M " )

2.7.

3.14 Conditional Elements

and

Figure 5.11. and

Example 5.13. And

Cheese( cheeseType : type ) && Person( favouriteCheese == cheeseType )

Cheese( cheeseType : type ) and Person( favouriteCheese == cheeseType )

or

Drools 规则引擎

Drools规则引擎 1. 概述: Drools分为两个主要部分：构建（Authoring）和运行时（Runtime）。 构建的过程涉及到.drl或.xml规则文件的创建，它们被读入一个解析器，使用ANTLR 3 语法进行解析。解析器对语法进行正确性的检查，然后产生一种中间结构“descr”，descr 用AST来描述规则。AST然后被传到PackageBuilder，由PackagBuilder来产生Packaged对象。PackageBuilder还承担着一些代码产生和编译的工作，这些对于产生Package对象都时必需的。Package对象是一个可以配置的，可序列化的，由一个或多个规则组成的对象。下图阐明了上述过程： Figure 1.1 Authoring Components RuleBase 是一个运行时组件，它包含了一个或多个 Package 对象。可以在任何时刻将一个 Package 对象加入或移出 RuleBase 对象。一个 RuleBase 对象可以在任意时刻实例化一个或多个 WorkingMemory 对象，在它的内部保持对这些WorkingMemory 的弱引用。 WorkingMemory 由一系列子组件组成。当应用程序中的对象被 assert 进 WorkingMemory ，可能会导致一个或多个 Activation 的产生，然后由 Agenda 负责安排这些 Activation 的执行。下图说明了上述过程：

Figure 1.2 . Runtime Components 2．构建（Authoring）： 主要有三个类用来完成构建过程：DrlParser, XmlParser 和 PackageBuilder。两个解析器类从传入的Reader实例产生descr AST模型。PackageBuilder提供了简便的API，使你可以忽略那两个类的存在。这两个简单的方法是：“addPackageFromDrl”和“addPackageFromXml”，两个都只要传入一个Reader 实例作为参数。下面的例子说明了如何从classpath中的xml和drl文件创建一个Package对象。注意：所有传入同一个PackageBuilder实例的规则源，都必须是在相同的package 命名空间（namespace）中。 PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl( new InputStreamReader( getClass().getResourceAsStream( " package1.drl" ) ) ); builder.addPackageFromXml( new InputStreamReader( getClass().getResourceAsStream( " package2.drl" ) ) ); Package pkg = builder.getPackage();

ILOG规则引擎系统运维手册

ILOG 规则引擎系统运维手册 一、 ILOG 规则引擎系统介绍 ? 为什么使用ILOG 规则引擎系统？ 保险行业是大量业务规则的处理过程，投承保规则、保费计算规则、核保规则、核批规则、费用规则、核赔规则。。。业务规则无所不在，且随着行业监管、市场环境、业务管理等因素不断变化。 业务规则管理混乱、业务规则变更过分依赖技术人员，业务人员无法单独完成业务规则变更，维护成本高昂，由此带来的问题： ? 业务规则变更周期长、成本高 ? 规则重用性差 ? 业务规则知识随着时间被淡忘 基于ILOG 的规则管理，可实现： ? 业务规则与保险应用剥离，业务规则易于管理 ? 使用集中规则库进行管理，业务人员可单独变更业务规则 ? 实现历史规则追溯 ? 规则可重用 ? 缩短新业务发布周期 ? ILOG 在都邦保险的运用 Ilog 规则引擎系统目前维护的规则有车险核保规则和车险费用规则。 自动核保规则是指根据某些核保因子判断当前保单是否能够自动核保通过或者不能够自动核保通过的规则。 其中，不能够自动核保通过的规则，一般又分为数据校验规则、打回出单规则以及自动核保校验规则（转人工核保）等。 人工核保权限规则是指在人工核保环节，不同级别的核保员具有不同的核保权限，配置不同级别的核保员核保权限的规则就是人工核保权限规则。 ? 产品组件 Rule Studio （规则开发环境） 用于对基于规则的应用程序进行编码、调试和部署； Rule Execution Server （规则执行服务器） RES 执行部署的规则应用，业务规则调用的组件，并包括一个web 的管理控制台，业务人员/技术人员编写的业务规则只有部署在规则的执行环境中才能被执行，才能起到作用； 核保规则 自动核保规则 人工核保规则 ——维护各核保级别的权限 打回出单（数据校验或拒保）规则 转人工核保规则 自动核保通过规则

规则引擎研究-整理

规则引擎研究——Rete算法介绍 一、R ETE概述 Rete算法是一种前向规则快速匹配算法，其匹配速度与规则数目无关。Rete是拉丁文，对应英文是net，也就是网络。Rete算法通过形成一个rete网络进行模式匹配，利用基于规则的系统的两个特征，即时间冗余性（Temporalredundancy）和结构相似性（structuralsimilarity），提高系统模式匹配效率。 二、相关概念 2.1事实（FACT）： 事实：对象之间及对象属性之间的多元关系。为简单起见，事实用一个三元组来表示：（identifier^attributevalue），例如如下事实： w1:(B1^onB2)w6:(B2^colorblue) w2:(B1^onB3)w7:(B3^left-ofB4) w3:(B1^colorred)w8:(B3^ontable) w4:(B2^ontable)w9:(B3^colorred) w5:(B2^left-ofB3) 2.2规则（RULE）: 由条件和结论构成的推理语句，当存在事实满足条件时，相应结论被激活。一条规则的一般形式如下： (name-of-this-production LHS/*oneormoreconditions*/ --> RHS/*oneormoreactions*/ ) 其中LHS为条件部分，RHS为结论部分。 下面为一条规则的例子： (find-stack-of-two-blocks-to-the-left-of-a-red-block (^on) (^left-of) (^colorred) -->

...RHS... ) 2.3模式（PATTEN）： 模式：规则的IF部分，已知事实的泛化形式，未实例化的多元关系。 (^on) (^left-of) (^colorred) 三、模式匹配的一般算法 规则主要由两部分组成：条件和结论，条件部分也称为左端（记为LHS,left-handside），结论部分也称为右端（记为RHS,right-handside）。为分析方便，假设系统中有N条规则，每个规则的条件部分平均有P个模式，工作内存中有M个事实，事实可以理解为需要处理的数据对象。 规则匹配，就是对每一个规则r,判断当前的事实o是否使LHS(r)=True，如果是，就把规则r的实例r(o)加到冲突集当中。所谓规则r的实例就是用数据对象o的值代替规则r的相应参数，即绑定了数据对象o的规则r。 规则匹配的一般算法： 1)从N条规则中取出一条r； 2)从M个事实中取出P个事实的一个组合c； 3)用c测试LHS(r)，如果LHS(r（c）)=True，将RHS(r（c）)加入冲突集中； 4)取出下一个组合c，goto3； 5)取出下一条规则r，goto2； 四、RETE算法 Rete算法的编译结果是规则集对应的Rete网络,如下图。Rete网络是一个事实可以在其中流动的图。Rete网络的节点可以分为四类：根节点（root）、类型节点（typenode）、alpha节点、beta节点。其中，根结点是一个虚拟节点，是构建rete网络的入口。类型节点中存储事实的各种类型，各个事实从对应的类型节点进入rete网络。 4.1建立RETE网络 Rete网络的编译算法如下： 1)创建根； 2)加入规则1(Alpha节点从1开始，Beta节点从2开始)； a.取出模式1，检查模式中的参数类型，如果是新类型，则加入一个类型节点；

Java规则引擎工作原理及其应用

Java规则引擎工作原理及其应用 作者：缴明洋谭庆平出处：计算机与信息技术责任编辑：方舟[ 2006-04-06 08:18 ] Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对 摘要Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程 序中对应的操作。 引言 目前，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）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式

Drools规则引擎开发说明

Drools规则动态更新 在常规开发方式中，如果涉及规则的变更(比如将物流费用从6元调整为8元)，可以通过重新完成规则的开发并发布应用来更新。或在设计上，将可能变更的规则以配置(比如数据库)方式管理。发生规则变更时，只需修改配置即可。事实上，Drools提供了另一种规则更新的方式--扫描Maven仓库(本地或远程)来自动发现规则模块的更新。 我们知道，Drools可以利用KieServices来创建基于classpath的KieContainer(即使用KieServices.newKieClasspathContainer()方法)。其实，KieServices还提供了从Maven 仓库加载并创建KieContainer的方法--newKieContainer(ReleaseId)。与通过classpath 创建KieContainer类似，使用Maven仓库加载的方法，会尝试读取对应jar包中的META-INF/kmodule.xml文件，基于此，我们可以完成KieSession的创建。 我们通过一个简单的例子来观察规则的动态更新。在这个例子中，我们会将商品的折扣进行动态调整。我们需要构建规则，并安装到Maven仓库中--简单起见，我们将应用发布到本地Maven仓库中。首先，我们创建一个Maven项目: $mvn-B archetype:generate-DarchetypeGroupId=org.apache.maven.archetypes\ -DgroupId=com.sharp.rules-DartifactId=discount 如果没什么问题，我们可以得到一个名为discount的文件夹，其中的pom.xml看起来像这样: 4.0.0 com.sharp.rules discount jar 1.0-SNAPSHOT discount https://www.wendangku.net/doc/d517775309.html, junit junit 3.8.1 test 在src/main/java/com/sharp/rules下创建Fact类: package com.sharp.rules; public class Commodity{ private double discount;

规则引擎解决方案调研报告-V1.0

中国XXXXXXXX系统 for J2EE 规则引擎解决方案调研报告 Version 1.0

目录 1.规则引擎4 1.1概述4 2.应用方案的一般实现5 2.1建立规则集7 2.2部署规则集7 2.3规则服务接口－JSR94 7 2.4对规则的计算7 2.5规则的过滤8 2.6使用计算结果8 3.现有的商业解决方案8 3.1ＩＬＯＧ新产品ＩＬＯＧＪＲｕｌｅｓ8 3.2操作人员已经显示提单列表错误!未定义书签。 4.其它解决方案10 4.1提单和报检单完成对碰10 5.评估11

规则引擎解决方案调研报告 1. 规则引擎 规则引擎是解决可变的商业规则的问题的 1.1 概述 规则引擎（Rules Engine）的运作机制是在内存中向对象应用一套规则。首先内存使用来自调用对象的输入，例如用户档案请求会话。这样，在任何规则实际激活之前，在内存中就已经有了一份用户档案的内容。 规则只能在一个上下文环境中执行，上下文环境把规则集和内存关联起来。该环境提供了到Rules Engine的接口，Rules Engine控制着应用程序的规则部分与内存之间的关系。 内存由生产规则（production rules）负责操作，生产规则包含在规则集里。，依照规则的左半边（left-hand sides，LHS）针对内存中的对象进行计算。如果内存中的对象与LHS中描述的模式匹配，就会触发规则的右半边（right-hand side，RHS）指定的操作。此外某些操作可能会在内存中加入新的对象。例如，规则 Classifier 对用户年龄进行测试，如果 USER.age > 45，就在内存中加入一个新的Classification 对象。 生产系统的运行，要执行以下操作： 1.匹配: 估计规则的LHS，判断哪个规则与当前内存中的内容匹配。 2.冲突解决：选择一个LHS匹配的规则。如果没有规则匹配，就停止解释。 3.操作: 执行选中规则RHS中指定的动作。 4.返回第1步。 规则会一直在内存中执行，直到冲突解决集变为0时才停止（也就是没有规则能激活了）。 在Rules Engine停止之后，规则管理器组件会返回一个对象列表，列表中包含内存中仍然存在的对象。一个可能的场景就是，还剩下一个类型为“Classification”或“ContentQuery”的对象。 Rules Manager接着对剩下的对象进行迭代，用可选的对象过滤器过滤它们。过滤器可以有选择地忽略某些对象或者对某些对象进行变换。 1.2 规则引擎分类 值得注意的是，存在不同类型的规则引擎，在决定如何应用一种工具之前理解这种工具的用途是极其重要的。当您跨业务规则领域进行调查研究时，您将注意到这些工具可以分为以下几类： ?简单业务规则（simple business rule）——通过一张简化的、直观的词汇表来表达并且是在应用程序或业务流程的可变性情况下调用的一种业务规则。这种规则引擎的一个很好的例子就是 ilog、Blaze 和 IBM 的 BRBeans。

Drools规则引擎的使用总结

前一段时间在开发了一个做文本分析的项目。 在项目技术选型的过程中， 尝试使用了 Drools 规则引擎。让它来作为项目中有关模式分析和关键词匹配的任务。但后来，因为某种原因, 还是撇开 了 Drools 。现将这个过程中使用 Drools 的一些经验和心得记录下来。 （一）什么时候应该使用规则引擎 ~这实际是一个技术选型的问题。 但这个问题又似乎是一个很关键的问题 （一旦返工的话, 你就知道这个问题是多么重要了）。不知大家有没有过这样的经验和体会。 往往在项目开始 的时候，总会遇到应该选用什么技术？是不是应该使用最新的技术？或者应该选用什么技术 呢（PS : 现在计算机软件中的各种技术层出不穷，具有类似功能的技术很多 ）？ 不管怎么样，这些问题总会困扰着我。比如，这次的这个项目。项目要求是要在一些 文件中（这些log 文件都是很大的应用系统所产生的，但由于legacy 的原因，log 本身的维 护 和规范工作一直没有得到改善，所以想借助于一些外部应用对这些 log 做以分析和清洗） 抽取出有用的信息。 于是，第一个想到的就是，这是一个文本挖掘类的项目。但又想，要抽取有用信息，必 须得建立一些规则或 pattern （模式）。所以，我第一个想到了规则引擎。因为这里面要建 立好多规则，而这些规则可以独立于代码级别（ 引擎去解析和执行。另一个重要的原因是，我原来用 过，比较熟悉。这样，也可以节省开发 时间吧。于是，好不犹豫的就开始做了 Demo.... 但事实上，在经历了一个多星期的编码、 测试后，我发现运用规则引擎实在是太笨拙了。 （1）首先必须建立一些数据模型。通过这些模型来 refer 规则文件中的LHS 和Action 。 （2 ）还要考虑规则的 conflict 。如果有一些规则同时被触发，就要考虑设定规则的优先 级或者 是设定activiation-group 来保证在一个group 中的规则只有一个规则可以被触发。 （3）对于 流'规则group ruleflow-group 的使用。如果要控制在 workingmemory 中的规 则被触发的顺序，则可以将这些规则分组。然后， 通过规则建模的方式来实现。但这也添加 了一定的effort 。修改或者更新不大方便。 ~所以，基于上述体会，我更认为规则引擎更适用于那些对非流程性规则匹配的应用。当 然，Drools 也支持对流程性规则的建模过程。但，这也许不是最好的方式。 （二） Drools 规则引擎的使用杂记 （1） Fact 的变更监听。在Drools 里，如果一个Fact 通过规则而改变，则需将这种 改变通知 给规则引擎。这里，一般有两种方式：显式和隐式。 显式---在drl 文件中通过 up date 、modify 来通知；在程序中，通过 Fact 的引用调用 modifyObject 等方法来实现。 隐式---通过在Java bea n 实现property Liste ner In terface 来让引擎自动监听到属性 值的变化。我更习惯于这种方式。因为，一般看来凡是在规则引擎中添加到 fact 都是希望 引擎来帮你进行管理的。所以，那它自己看到 fact 的变化是种很省事的办法。也很简单， 就是用Java bean property 监听的方式。 通过 StatefulSession 来注册。 调用 StatefulSession 的某个 instanee 的 insert （ Object ，true ）实现。而这个 object 是一个java bean 。其中，要实现 P rivate final Prop ertyCha ngeS upport cha nges Prop ertyCha ngeS upp ort( this ); public void add PropertyChangeListener(final PropertyChangeListener l) { this.cha nges.add Prop ertyCha ngeListe ner( l ); log 放到一个单独的drl 文件里）并可以用规则 =new

JAVA规则引擎 -- Drools

Drools是一个基于java的规则引擎，开源的，可以将复杂多变的规则从硬编码中解放出来，以规则脚本的形式存放在文件中，使得规则的变更不需要修正代码重启机器就可以立即在线上环境生效。 1、Drools语法 开始语法之前首先要了解一下drools的基本工作过程，通常而言我们使用一个接口来做事情，首先要穿进去参数，其次要获取到接口的实现执行完毕后的结果，而drools也是一样的，我们需要传递进去数据，用于规则的检查，调用外部接口，同时还可能需要获取到规则执行完毕后得到的结果。在drools 中，这个传递数据进去的对象，术语叫Fact对象。Fact 对象是一个普通的java bean，规则中可以对当前的对象进行任何的读写操作，调用该对象提供的方法，当一个java bean插入到workingMemory中，规则使用的是原有对象的引用，规则通过对fact对象的读写，实现对应用数据的读写，对于其中的属性，需要提供getter setter访问器，规则中，可以动态的往当前workingMemory中插入删除新的fact对象。 规则文件可以使用 .drl文件，也可以是xml文件，这里我们使用drl文件。规则语法： package：对一个规则文件而言，package是必须定义的，必须放在规则文件第一行。特别的是，package的名字是随意的，不必必须对应物理路径，跟java 的package的概念不同，这里只是逻辑上的一种区分。同样的package下定义的function和query等可以直接使用。 比如：package com.drools.demo.point import：导入规则文件需要使用到的外部变量，这里的使用方法跟java相同，但是不同于java的是，这里的import导入的不仅仅可以是一个类，也可以是这个类中的某一个可访问的静态方法。 比如： import com.drools.demo.point.PointDomain; import com.drools.demo.point.PointDomain.getById; rule：定义一个规则。rule "ruleName"。一个规则可以包含三个部分： 属性部分：定义当前规则执行的一些属性等，比如是否可被重复执行、过期时间、生效时间等。 条件部分，即LHS，定义当前规则的条件，如 when Message(); 判断当前workingMemory中是否存在Message对象。 结果部分，即RHS，这里可以写普通java代码，即当前规则条件满足后执行的操作，可以直接调用Fact对象的方法来操作应用。

基于JAVA的规则引擎

基于Java的规则引擎

目录 1.简介 (3) 1.1业务规则 (3) 1.2规则引擎产生背景 (3) 2.规则引擎 (4) 2.1业务规则 (4) 2.2规则引擎 (4) 2.3规则引擎的使用方式 (4) 2.4规则引擎架构与推理 (5) 2.5规则引擎的算法 (6) 3.Java规则引擎 (7) 3.1Java规则引擎商业产品 (7) 3.2规则引擎产品特点分析 (8) 3.2.1IBM WebSphere ILOG JRules (8) 3.2.2Redhat JBoss Dools (11) 3.2.3JESS (11) 4.Java规则引擎API（JSR94） (13) 4.1简介 (13) 4.2简介Java规则引擎API体系结构 (13) 3.2.4规则管理API (13) 3.2.5运行时API (14) 4.3Java规则引擎API安全问题 (15) 4.4异常与日志 (15) 4.5JSR94小结 (16) 5规则语言 (17)

1.简介 1.1业务规则 一个业务规则包含一组条件和在此条件下执行的操作．它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。 业务规则的理论基础是：设置一个或多个条件，当满足这些条件时会触发一个或多个操作。 1.2规则引擎产生背景 复杂企业级项目的开发以及其中随外部条件不断变化的业务规则（business logic），迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。 企业管理者对企业级IT系统的开发有着如下的要求： 1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂； 2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更 新； 3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序 开发人员参与。 而项目开发人员则碰到了以下问题： 4程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型； 5软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中； 6对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。 基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。

规则引擎解决方案调研报告_V1.0

中国XXXXXXXX系统 for J2EE 错误！未指定书签。 Version 1.0

目录 1.规则引擎4 1.1概述4 2.应用方案的一般实现5 2.1建立规则集7 2.2部署规则集7 2.3规则服务接口－JSR94 7 2.4对规则的计算7 2.5规则的过滤8 2.6使用计算结果8 3.现有的商业解决方案8 3.1ＩＬＯＧ新产品ＩＬＯＧＪＲｕｌｅｓ8 3.2操作人员已经显示提单列表错误！未定义书签。 4.其它解决方案10 4.1提单和报检单完成对碰10 5.评估11

错误！未指定书签。 1. 规则引擎 规则引擎是解决可变的商业规则的问题的 1.1 概述 规则引擎（Rules Engine）的运作机制是在内存中向对象应用一套规则。首先内存使用来自调用对象的输入，例如用户档案请求会话。这样，在任何规则实际激活之前，在内存中就已经有了一份用户档案的内容。 规则只能在一个上下文环境中执行，上下文环境把规则集和内存关联起来。该环境提供了到Rules Engine的接口，Rules Engine控制着应用程序的规则部分与内存之间的关系。 内存由生产规则（production rules）负责操作，生产规则包含在规则集里。，依照规则的左半边（left-hand sides，LHS）针对内存中的对象进行计算。如果内存中的对象与LHS中描述的模式匹配，就会触发规则的右半边（right-hand side，RHS）指定的操作。此外某些操作可能会在内存中加入新的对象。例如，规则 Classifier 对用户年龄进行测试，如果 USER.age > 45，就在内存中加入一个新的Classification 对象。 生产系统的运行，要执行以下操作： 1.匹配: 估计规则的LHS，判断哪个规则与当前内存中的内容匹配。 2.冲突解决：选择一个LHS匹配的规则。如果没有规则匹配，就停止解释。 3.操作: 执行选中规则RHS中指定的动作。 4.返回第1步。 规则会一直在内存中执行，直到冲突解决集变为0时才停止（也就是没有规则能激活了）。 在Rules Engine停止之后，规则管理器组件会返回一个对象列表，列表中包含内存中仍然存在的对象。一个可能的场景就是，还剩下一个类型为“Classification”或“ContentQuery”的对象。 Rules Manager接着对剩下的对象进行迭代，用可选的对象过滤器过滤它们。过滤器可以有选择地忽略某些对象或者对某些对象进行变换。 1.2 规则引擎分类 值得注意的是，存在不同类型的规则引擎，在决定如何应用一种工具之前理解这种工具的用途是极其重要的。当您跨业务规则领域进行调查研究时，您将注意到这些工具可以分为以下几类： 简单业务规则（simple business rule）——通过一张简化的、直观的词汇表来表达并且是在应用程序或业务流程的可变性情况下调用的一种业务规则。这种规则引擎的一个很好的例子就是 ilog、Blaze 和 IBM 的 BRBeans。

国内外主流工作流引擎及规则引擎分析

国内外主流工作流引擎及规则引擎分析2013年2月创新研发部

目录

一.背景 目前中心建成的“一大核心系统，七大共享平台”以及OA系统，对工作流应用程度高，但各系统实现工作流程管理没有建立在统一的工作流平台上，导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤，同时还要与多个系统进行交互，因此，为了提高管理效率，降低业务流转时间，同时还要结合农信银中心的总体IT战略规划，备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎，作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求，形成农信银中心工作流平台的发展规划，从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国内外领先的工作流产品和案例，同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品，进行工作流产品选型。 目前国内外的工作流引擎层出不穷，行业标准多种多样，通过对比不同工作流公司产品，本次工作流技术选型决定分析商业工作流引擎4款，开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款，本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主，选型工作将不再单独分析规则引擎，而是直接使用与所选工作流引擎搭配最好的或者是同一厂商的规则引擎。根据国内外知名度、厂商的规模和与符合农信银中心的SOA体系架构等原则，将选取以下6种工作流引擎与规则引擎进行研究与分析：

drools规则引擎的使用总结

前一段时间在开发了一个做文本分析的项目。在项目技术选型的过程中，尝试使用了Drools 规则引擎。让它来作为项目中有关模式分析和关键词匹配的任务。但后来，因为某种原因，还是撇开了Drools。现将这个过程中使用Drools的一些经验和心得记录下来。 （一）什么时候应该使用规则引擎 这实际是一个技术选型的问题。但这个问题又似乎是一个很关键的问题（一旦返工的话，你就知道这个问题是多么重要了）。不知大家有没有过这样的经验和体会。往往在项目开始的时候，总会遇到应该选用什么技术是不是应该使用最新的技术或者应该选用什么技术呢（PS：现在计算机软件中的各种技术层出不穷，具有类似功能的技术很多）？ 不管怎么样，这些问题总会困扰着我。比如，这次的这个项目。项目要求是要在一些log文件中（这些log文件都是很大的应用系统所产生的，但由于legacy的原因，log 本身的维护和规范工作一直没有得到改善，所以想借助于一些外部应用对这些log做以分析和清洗）抽取出有用的信息。 于是，第一个想到的就是，这是一个文本挖掘类的项目。但又想，要抽取有用信息，必须得建立一些规则或pattern（模式）。所以，我第一个想到了规则引擎。因为这里面要建立好多规则，而这些规则可以独立于代码级别（放到一个单独的drl文件里）并可以用规则引擎去解析和执行。另一个重要的原因是，我原来用过，比较熟悉。这样，也可以节省开发时间吧。于是，好不犹豫的就开始做了Demo.... 但事实上，在经历了一个多星期的编码、测试后，我发现运用规则引擎实在是太笨拙了。 （1）首先必须建立一些数据模型。通过这些模型来refer规则文件中的LHS和Action。 （2）还要考虑规则的conflict。如果有一些规则同时被触发，就要考虑设定规则的优先级或者是设定activiation-group来保证在一个group中的规则只有一个规则可以被触发。 （3）对于‘流’规则group ruleflow-group的使用。如果要控制在workingmemory 中的规则被触发的顺序，则可以将这些规则分组。然后，通过规则建模的方式来实现。但这也添加了一定的effort。修改或者更新不大方便。

规则引擎原理

规则引擎原理 本文对Java规则引擎与其API(JSR-94)及相关实现做了较详细的介绍，对其体系结构和API应用有较详尽的描述，并指出Java规则引擎,规则语言，JSR-94的相互关系,以及JSR-94的不足之处和展望。 复杂企业级项目的开发以及其中随外部条件不断变化的业务规则(businesslogic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。 本文第一部分简要介绍了规则引擎的产生背景和基于规则的专家系统， 第二部分介绍了什么是规则引擎及其架构和算法， 第三部分介绍了商业产品和开源项目实现等各种Java规则引擎， 第四部分对Java规则引擎API（JSR-94）作了详细介绍，讲解了其体系结构，管理API 和运行时API及相关安全问题， 第五部分则对规则语言及其标准化作了探讨， 第六部分给出了一个使用Java规则引擎API的简单示例， 第七部分给予小结和展望。 1.介绍 1.1. 规则引擎产生背景 企业管理者对企业级IT系统的开发有着如下的要求： (1)为提高效率，管理流程必须自动化，即使现代商业规则异常复杂 (2)市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更新 (3)为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序开发人员参与。 而项目开发人员则碰到了以下问题: (1)程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型 (2)软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中 (3)对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。 基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。下面简要介绍一下基于规则的专家系统。

Drools5规则引擎介绍

Drools5规则引擎介绍 2011-7-27

目录 1 规则引擎介绍 (3) 1.1 什么是规则引擎 (3) 1.2 使用规则引擎的优势 (3) 1.3 什么场景适合使用规则引擎 (3) 2 Drools简介 (4) 2.1 Drools简介 (4) 2.2 Drools的使用场景 (4) 3 Drools的工作原理 (4) 3.1 规则的工作流程 (4) 3.2 Rete算法总结 (5) 4 Drools5的安装 (5) 4.1下载drools相关的组件 (5) 4.2 解压缩已下载文件并放入eclipse中 (5) 4.3 查看Drools是否安装成功 (6) 4.4配置drools的Runtime环境 (6) 5 创建第一个示例及代码分析 (7) 5.1 创建规则 (7) 5.2 代码分析(规则的编译和运行) (11) 5.2.1 KnowledgeBuilder (11) 5.2.2 KnowledgeBase (11) 5.2.3 StatefulKnowledgeSession (12) 5.2.4 StatelessKnowledgeSession (13) 5.2.5 Fact对象 (14) 6 规则 (14) 6.1 规则文件 (14) 6.2 规则语言 (15) 6.2.1 条件部分 (15) 6.2.2 结果部分 (16) 6.2.3 属性部分 (17) 6.2.4 函数 (17) 6.2.5 查询 (17) 6.2.6 对象定义 (18)

1 规则引擎介绍 1.1 什么是规则引擎 规则引擎是基于规则的专家系统的核心部分，主要由三部分组成：规则库(Knowledge base)+Working Memory(Fact base)+推理机(规则引擎)，规则引擎根据既定事实和知识库按照一定的算法执行推理逻辑得到正确的结果。 规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。 目前，市面上应用产生了众多的规则引擎。开源规则引擎的代表是Drools；商业规则引擎的代表是ILog。 1.2 使用规则引擎的优势 能够将业务规则从技术实现中提取出来，实现技术和业务分离，开发人员处理技术、业务分析人员定义业务规则，各自做自己所擅长的事情。 1.3 什么场景适合使用规则引擎 虽然规则引擎能解决我们的许多问题，但我们还需要认真考虑一下规则引擎对我 们的项目本身是否是合适的。需要关注的点有： ? 我的应用程序有多复杂? 对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你更轻松应对这一切。 ? 我的应用的生命周期有多久？ 如果我们应用的生命周期很短，也没有必要使用Drools，使用规则引擎将会在中长期得到好处。

Drools开发教程、规则引擎

Drools5规则引擎规则引擎 开发开发教程教程教程 高杰 上海锐道信息技术有限公司 2009-8-20

1.学习前的准备 Drools是一款基于Java的开源规则引擎，所以在使用Drools之前需要在开发机器上安装好JDK环境，Drools5要求的JDK版本要在1.5或以上。 1.1. 开发环境搭建 大多数软件学习的第一步就是搭建这个软件的开发环境，Drools也不例外。本小节的内容就是介绍如何搭建一个Drools5的开发、运行、调试环境。 1.1.1.下载开发工具 Drools5提供了一个基于Eclipse3.4的一个IDE开发工具，所以在使用之前需要到https://www.wendangku.net/doc/d517775309.html,网站下载一个 3.4.x版本的Eclipse，下载完成之后，再到https://www.wendangku.net/doc/d517775309.html,/drools/downloads.html网站，下载Drools5的Eclipse插件版IDE及Drools5的开发工具包，如图1-1所示。

图1-1 除这两个下载包以外，还可以把Drools5的相关文档、源码和示例的包下载下来参考学习使用。 将下载的开发工具包及IDE包解压到一个非中文目录下，解压完成后就可以在Eclipse3.4上安装Drools5提供的开发工具IDE了。 1.1. 2.安装Drools IDE 打开Eclipse3.4所在目录下的links目录（如果该目录不存在可以手工在其目录下创建一个links目录），在links目录下创建一个文本文件，并改名为drools5-ide.link，用记事本打开该文件，按照下面的版本输入Drools5 Eclipse Plugin文件所在目录： path=D:\\eclipse\\drools-5.0-eclipse-all 这个值表示Drools5 Eclipse Plugin文件位于D盘eclipse目录下的drools-5.0-eclipse-all 下面，这里有一点需要注意，那就是drools-5.0-eclipse-all文件夹下必须再包含一个eclipse 目录，所有的插件文件都应该位于该eclipse目录之下，接下来要在win dos下重启Eclipse 3.4，检验Drools5 IDE是否安装成功。 进入win dos，进入Eclipes3.4所在目录，输入eclipse –clean启动Eclipse3.4。启动完成

规则引擎(DROOLS)培训资料v1.0.0

规则引擎(DROOLS)培训 DROOLS培训（5天） 目的： 重点讲解DROOLS是什么、能做什么、工作流程、怎么用到系统中，让学习人员可以对DROOLS有个全面初步的了解，并能够用DROOLS进行简单的系统开发。 参加人员： 需要使用DROOLS进行系统设计和开发或者对DROOLS感兴趣的同事。 主讲人员：

第一章 DROOLS 入门 第 1 节什么是DROOLS 如何组织企业应用中的业务逻辑，如果靠手工的代码来解决。随着大量业务规则的变化，导致应用程序不停的变更，如何能找到一种解决商业逻辑的架构，来解决当商务规则不停的变化时，可以保证我们的应用系统具有较好的柔韧性，可以适应特定的商务规则的变化，而无需修改我们的应用系统。Drools就是这样的一个应用在商务逻辑层的架构。 CODEHAUS的一个开源项目叫Drools，Drools是为Java量身定制的基于RETE算法的规则引擎的实现。 具有了OO接口的RETE,使得商业规则有了更自然的表达。Drools是用Java写的，但能同时运行在Java 和.Net上。最近被纳入JBOSS门下，更名为JBOSS Rules，成为了JBOSS应用服务器的规则引擎。 RETE算法是CHARLES FORGY在1979年发明的。RETE是唯一的，效率与执行规则数目无关的决策支持算法。For the uninitiated, that means it can scale to incorporate and execute hundreds of thousands of rules in a manner which is an order of magnitude more efficient then the next best algorithm。 RETE应用于生产系统已经有很多年了，但在Java开源软件中并没有得到广泛应用，直到DROOLS的出现。第 2 节 DROOLS能做什么 大多数web和企业Java应用可以分成三个部分：一个和用户交互的前台, 一个和后台系统，例如数据库交互的服务层，以及他们中间的业务逻辑。现在使用框架构建前台和后台系统已经成为普遍共识(例如, Struts, Cocoon, Spring, Hibernate, JDO, 和 Entity Beans), 但却没有一个标准的方法来构建业务逻辑。一些框架，例如 EJB 和 Spring 只在一个高层实现业务逻辑，但对于我们组织逻辑代码没有任何帮助，所以，为什么没有一个框架来替换冗繁，易错的if...then语句呢，这个框架应该和其它前台或后台框架一样，易于配置，具有可读性和重用性。Drools 规则引擎，这个就是来解决我们上述问题的框架。