BlogJava-clant-文章分类-规则引擎

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

BPM — Fri, 15 Dec 2006 07:19:00 GMT

摘要 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）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式匹配器决定选择执行哪个规则，何时执行规则；议程管理模式匹配器挑选出来的规则的执行次序；执行引擎负责执行规则和其他动作。和人类的思维相对应，推理引擎存在两者推理方式：演绎法（Forward-Chaining）和归纳法（Backward-Chaining）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是根据假设，不断地寻找符合假设的事实。Rete算法是目前效率最高的一个Forward-Chaining推理算法，许多Java规则引擎都是基于Rete算法来进行推理计算的。推理引擎的推理步骤如下：(1)将初始数据（fact）输入Working Memory。(2)使用Pattern Matcher比较规则库（rule base）中的规则（rule）和数据（fact）。(3)如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。(4)解决冲突，将激活的规则按顺序放入Agenda。(5)使用执行引擎执行Agenda中的规则。重复步骤2至5，直到执行完毕所有Agenda中的规则。上述即是规则引擎的原始架构，Java规则引擎就是从这一原始架构演变而来的。2、规则引擎相关构件规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。1)信息元（Information Unit）信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。 2)信息服务（Information Services）信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相对应的信息元。3)规则集（Rule Set）顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。4)队列管理器（Queue Manager）队列管理器用来管理来自不同信息服务的信息元对象的队列。下面将研究规则引擎的这些相关构件是如何协同工作的。如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。

图2 处理过程协作图3、规则引擎的工作机制下面专门研究规则引擎的内部处理过程。如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定义顺序检查信息元所带规则集中的规则。如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下一条规则。如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中的所有规则执行完毕后，信息元将被销毁，然后从队列管理器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作（Discard Action）和包含动作（Include Action）。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包含动作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。这一过程将递归进行。

图3 规则引擎工作机制Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。Java规则引擎对提交给引擎的Java数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般来讲，Java规则引擎内部由下面几个部分构成：工作内存（Working Memory）即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。Java规则引擎的结构示意图如图4所示。

图4 Java规则引擎工作机制当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。

BPM 2006-12-15 15:19 发表评论

（六）: Drools规则语言详解（上）

BPM — Sun, 03 Dec 2006 01:56:00 GMT

Drools 规则语言详解（上）

1． 概述：

Drools 3 采用了原生的规则语言，那是一种非 XML 文本格式。在符号方面，这种格式是非常轻量的，并且通过“ expanders ”支持符合你问题域的 Domain Specific Language （ DSL ）。这一章把焦点放在了 Drools 原生的规则格式。如果你想从技术上了解规则语言的机制，可以参考“ drl.g ”源文件，这是用 Antlr3 语法来描述规则语言。如果你使用 Rule Workbench ，内容助手将会为你完成大量的规则结构，例如输入“ ru ”，然后按 ctrl ＋ space ，会为你建立规则结构。

1.1 规则文件

一个规则文件通常是一个以 .drl 扩展名结尾的文件。在一个 drl 文件中，你可以有多条 rules ， functions 等等。尽管如此，你也可以将你的规则分布在多个文件中，这有利于管理大量的规则。一个 DRL 文件是一个简单的文本文件。

1.2 规则的结构

一个规则结构大致如下：

rule " name "
    ATTRIBUTES
    when
        LHS
    then
        RHS
end

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

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

1.3 Domain Specific Language

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

1.4 保留字

在规则语言中存在一些保留字。你应该避免使用这些保留字，来命名规则文本中的域对象，属性，方法，功能。保留字如下： 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. Single line comment

2.2 多行注释：

Figure 2.2. Multi line comment

3. Package

一个包是 rule 和其他相关结构，像 import 和 global 的集合。 Package 的成员之间通常都是相关联的。一个 Package 代表了一个命名空间（ namespace ），用来使给定的规则组之间保持唯一性。 Package 的名字本身就是命名空间，并且与文件或文件夹并无关联。

可以将来自不同规则源的规则装配在一起，前提是这些规则必须处在同一个命名空间中。尽管如此，一个通常的结构是将处于同一个命名空间中的所有规则都放在同一个相同的文件中。

下面的 rail-road 图显示了组成一个 Package 的所有组件。注意：一个 package 必须有一个命名空间，并且采用 Java 包名的约定。在一个规则文件中，各组件出现的位置是任意的，除了“ package ”和“ expander ”语句必须出现在任何一个规则之前，放在文件的顶部。在任何情况下，分号都是可选的。

Figure 3.1. package

3.1 import

Figure 3.2. import

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

3.2 expander

Figure 3.3. expander

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

3.3 global

Figure 3.4. global

Global 就是全局变量。如果多个 package 声明了具有相同标识符的 global ，那么它们必需是相同的类型，并且所有的引用都是相同的。它们通常用来返回数据，比如 actions 的日志，或者为 rules 提供所需的数据或服务。 global 并不是通过 assert 动作放入 WorkingMemory 的，所有当 global 发生改变时，引擎将不会知道。所以， global 不能作为约束条件，除非它们的值是 final 的。将 global 错误的使用在约束条件中，会产生令人惊讶的错误结果。

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

下面的例子中，有一个 EmailService 的实例。在你调用规则引擎的代码中，你有一个 EmailService 对象，然后把它放入 WorkingMemory 。在 DRL 文件中，你声明了一个类型为 EmailService 的 global ，然后将它命名为“ email ”，像这样： global EmailService email ；。然后在你的规则的 RHS 中，你可以使用它，像这样： email.sendSMS(number,message) 等等。

4. Function

Figure 4.1. function

Function 是将代码放到你的规则源中的一种方法。它们只能做类似 Helper 类做的事（实际上编译器在背后帮你生成了 Helper 类）。在一个 rule 中使用 function 的主要优势是，你可以保持所有的逻辑都在一个地方，并且你可以根据需要来改变 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 变量）。

BPM 2006-12-03 09:56 发表评论

（七）: Drools规则语言详解（下）

BPM — Sun, 03 Dec 2006 01:56:00 GMT

摘要: Drools规则语言详解（下） 5. Rule Figure 5.1. r... 阅读全文

BPM 2006-12-03 09:56 发表评论

（五）: JBoss Rules 3.0.1 类库介绍

BPM — Sun, 03 Dec 2006 01:55:00 GMT

下载地址：

http://labs.jboss.com/portal/index.html?ctrl:id=page.default.downloads&project=jbossrules

下载文件说明：

JBoss Rules 3.0.1 Binaries (includes javadocs) （ 13MB ）― 仅仅包含 JBoss Rules 的四个核心类库：

l drools-core.jar－核心引擎，运行时组件。包含了RETE引擎和LEAPS引擎；

l drools-compiler.jar－规则文件的编译组件，构建可执行的RuleBase；

l drools-jsr94.jar－提供了JSR-94的兼容实现，本质上是drools- compiler组件的包裹层。注意：由于JSR94规约的限制，不是所有的特点都可以通过此接口暴露。

l drools-decisiontables.jar－决策表的“编译”组件（使用了drools- compiler组件）。支持excel和CSV输入格式。

JBoss Rules 3.0.1 Binaries with dependencies (includes javadocs) （ 23 MB ）－包含了 JBoss Rules 的核心类库和它们的 dependencies ：

l antlr-2.7.6.jar

l antlr-3.0ea8.jar

l colt-1.2.0.jar

l commons-collections-3.1.jar

l commons-io-1.1.jar

l commons-jci-core-1.0-406301.jar

l commons-jci-eclipse-3.2.0.666.jar

l commons-jci-janino-2.4.3.jar

l commons-lang-2.1.jar

l commons-logging-api-1.0.4.jar

l concurrent-1.3.4.jar

l core-3.2.0.666.jar

l janino-2.4.3.jar

l jsr94-1.1.jar

l jung-1.7.2.jar

l junit-3.8.1.jar

l poi-2.5.1-final-20040804.jar

l stringtemplate-2.3b6.jar

l xercesImpl-2.6.2.jar

l xml-apis-1.0.b2.jar

l xpp3-1.1.3.4.0.jar

l xstream-1.1.3.jar

如果你运行在 Java 1.5 环境下，有一些类库，例如 XML libraries ，可以不需要。需要注意的类库有：

“ JCI ”－这是 Apache Java Compiler Interface , 提供了运行时编译能力。可以通过 PackageBuilderConfiguration 实例来设定采用 eclipse 或 janino 编译器，默认是 eclipse ；

“ POI ”－提供了解析 Excel 文件的能力；

“ antlr ”－提供了解析规则语言的能力。

JBoss Rules IDE 3.0.1 （ 13 MB ）－这是 JBoss Rules 的 Eclipse 插件，只支持 Eclipse 3.2 或以上版本。它提供了运行 JBoss Rules 的所有 dependencies 。你可以创建一个 Rule Project ，它能够为你编写规则文件提供自动完成的功能，并且它为你提供了 Agenda view ， WorkingMemory view ， Global Data view ，使你可以通过 eclipse 视图很清楚的看到 Agenda ， WorkingMemory 和 Global Data 的情况。

你还可以通过 update site 来自动安装这个插件 ,URL 是：

http://anonsvn.labs.jboss.com/labs/jbossrules/updates/drools-ide-update/

BPM 2006-12-03 09:55 发表评论

（三）: Drools规则引擎（上）

BPM — Sun, 03 Dec 2006 01:54:00 GMT

从今天开始，我们将分两期来详细的介绍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();

Figure 2.1 PackageBuilder

PackageBuilder是可以配置的，使用PackageBuilderConfiguration。通常，你可以指定另一个parent ClassLoader和用什么编译器（compiler），默认是Eclipse JDT。下面显示了如何指定JANINO编译器：

PackageBuilderConfiguration conf = new PackageBuilderConfiguration();
conf.setCompiler( PackageBuilderConfiguration.JANINO );
PackageBuilder builder = new PackageBuilder( conf );

Figure 2.2 . PackageBuilderConfiguration

3．RuleBase:

Figure 3.1 . RuleBase

一个RuleBase包含了多个将被使用的规则包（packages of rules）。一个RuleBase是可以序列化的，所以它可以被配置到JNDI或其他类似的服务。通常，第一次使用时，一个RuleBase被创建并缓存。RuleBase用RuleBaseFactory来实例化，默认返回一个ReteOO RuleBase。可以传入参数来指定采用ReteOO或Leaps。然后，用addPackage方法加入Package实例。你可以加入有相同命名空间（namespace）的多个Package。

RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage(pkg);

Figure 3.2. RuleBaseFactory

一个 rulebase instance 是线程安全的，所有你可以在你的应用中，让一个 rulebase instance 在多个线程中共享。对于一个 rulebase 的最通常的操作是产生一个新的 WorkingMemory 。

这个 rulebase 保持着到它所产生的 WorkingMemoryd 的弱引用，所以在长时间运行的 WorkingMemory 中，如果 rules 发生改变，这些 WorkingMemory 可以即使的根据最新的 rules 进行更新，而不必重启 WorkingMemory 。你也可以指定 RuleBase 不必保持一个弱引用，但是你要保证 RuleBase 不用更新。

ruleBase.newWorkingMemory(); // maintains a weak reference.
ruleBase.newWorkingMemory( false ); // do not maintain a weak reference

任何时候， Package 可以被加入或移除；所有的改变都会被反映到现存的 WorkingMemory 中。不要忘了调用 fireAllRules() 让 Activations 激发。

ruleBase.addPackage( pkg ); // Add a package instance
ruleBase.removePackage( " org.com.sample " ); // remove a package, and all its parts, by it's namespace
ruleBase.removeRule( " org.com.sample " , " my rule " ); // remove a specific rule from a namespace

虽然有删除一个单独规则的方法，但是却没有加入一个单独规则的方法（要达到这个目的只有加入一个只有一条规则的 package ）。

RuleBaseConfigurator 可以指定 RuleBase 的附加行为。在加入 RuleBase 后， RuleBaseConfiguration 就变成不可变对象。

RuleBaseConfiguration conf = new RuleBaseConfiguration();

conf.setProperty( RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR,
RuleBaseConfiguration.WM_BEHAVIOR_EQUALITY );

RuleBase ruleBase = new ReteooRuleBase( conf );

两个主要的属性是： PROPERT_ASSERT_BEHAVIOR 和 PROPERTY_LOGICAL_OVERRIDE_BEHAVIOR （在以后的部分中会解释）。所有的属性值都是 RuleBaseConfiguration 类中的静态域常量。

Figure 3.3 RuleBaseConfiguration

BPM 2006-12-03 09:54 发表评论

（四）: Drools规则引擎（下）

BPM — Sun, 03 Dec 2006 01:54:00 GMT

Drools 规则引擎(下)

4 ． WorkingMemory:

Figure 4.1 WorkingMemory

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 。

4.1 Facts

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

4.2 Assertion

“Assertion” 是将 facts 告诉 WorkingMemory 的动作，例如 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 的动作）。

4.3 Retraction

基本上就是 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 );

4.4 Modification

当一个 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 );

4.5 Globals

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

List list = new ArrayList（）;
workingMemory.setGlobal( " list " , list);

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

4.6 Property 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 );

5. Agenda:

Figure 5.1 . Agenda

Agenda 是 RETE 的一个特点。在一个 WorkingMemory Action 发生时，可能会有多条规则发生完全匹配。当一条规则完全匹配的时候，一个 Activation 就被创建（引用了这条规则和与其匹配的 facts ），然后放进 Agenda 中。 Agenda 通过使用冲突解决策略（ Conflict Resolution Strategy ）来安排这些 Activations 的执行。

引擎工作在一个“ 2 阶段”模式下：

1） WorkingMemory Actions ：assert新的facts，修改存在的facts和retract facts都是WorkingMemory Actions。通过在应用程序中调用fireAllRules()方法，会使引擎转换到Agenda Evaluatioin阶段。

2） Agenda Evaluation ：尝试选择一条规则进行激发（fire）。如果规则没有找到就退出，否则它就尝试激发这条规则，然后转换到WorkingMemory Actions阶段，直到Agenda中为空。

这个过程一直重复，直到 Agenda 是空的，此时控制权就回到应用程序中。。当 WorkingMemory Actions 发生时，没有规则正在被激发。

下图说明了这个循环的过程：

Figure 5.2 . Two Phase Execution

5 ． 1 Conflict Resultion

当有多条 rules 在 agenda 中，就需要解决冲突。当激发一条规则时，会对 WorkingMemory 产生副作用。规则引擎需要知道规则要以什么顺序来激发（例如，激发 rule A 可能会引起 rule B 被从 agenda 中移除。）

Drools 采取的冲突解决策略有 2 种，按照优先级排列如下： Salience ， LIFO （后进先出）。最易懂的策略是“ Salience ”，即优先级， user 可以为某个 rule 指定一个高一点的优先级（通过附给它一个比较大的数字）。高 Salience 的 rule 将会被优先激发。

5 ． 2 Agenda Groups

Agenda Groups 是划分 Agenda 中 rules （其实是“ activations ”）的一种方法。在任意一个时刻，只有一个 group 拥有“ focus ”，这意味着只有在那个 group 中的 activations 才是有效的。

Agenda Groups 是在 grouped rules 之间创建一个“流”（ flow ）的简便的方法。你可以在规则引擎中，或是用 API 来切换具有焦点的组。如果你的规则有很明确的多“阶段”（ phases ）或多“序列”（ sequences ）的处理，可以考虑用 Agenda Groups 来达到这个目的。

每次调用 setFocus() 方法的时候，那个 Agenda Group 就会被压入一个堆栈，当这个有焦点的组为空时，它就会被弹出，然后下一个组就会被执行。一个 Agenda Group 可以出现在堆栈的多个位置。默认的 Agenda Group 是“ MAIN ”，所有没有被指定 Agenda Group 的 Activations 都被放到那个组中，这个组总是被放在堆栈的第一个组，并默认给予焦点。

5 ． 3 Agenda Filters

Figure 5.3. Agenda Filter

Filter 必须实现 AgendaFilter 接口，用来允许或禁止一个 activation 能够被激发。 Drools 提供了下面几种方便的默认实现：

· RuleNameEndWithAgendaFilter

· RuleNameEqualsAgendaFilter

· RuleNameStartsWithAgendaFilter

要使用一个 filter 就要在调用 fireAllRules() 方法的时候指定它。下面的例子将对所有名字以“ Test ”结尾的规则进行过滤：

workingMemory.fireAllRules( new RuleNameEndsWithAgendaFilter( " Test " ) );

6．事件模型（ Event Model ）

Event 包里提供了规则引擎的事件机制，包括规则激发，对象被 asserted 等等。你可以使用事件机制来进行 AOP 编程。

有两种类型的 Event Listener ： WorkingMemoryEventListener 和 AgendaEventListener 。

Figure 6.1. WorkingMemoryEventListener

Figure 6.2 AgendaEventListener

对两个 EventListener 接口都提供了默认实现，但在方法中并没有做任何事。你可以继承这两个默认实现来完成你自己的实现－ DefaultAgendaEventListener 和 DefaultWorkingMemoryEventListener 。下面代码说明了如何扩展一个 DefaultAgendaEventListner 并把它加到 WorkingMemory 中，例子中只完成了 afterActivationFired() 方法：

workingMemory.addEventListener( new DefaultAgendaEventListener() {
    public void afterActivationFired(AfterActivationFiredEvent event) {
        super .afterActivationFired( event );
       System.out.println( event );
   }

});

Drools 也提供了 DebugWorkingMemoryEventListener 和 DebugAgendaEventListener 两个实现类，在这两个类的方法中实现了 debug 信息的输出：

workingMemory.addEventListener( new DebugWorkingMemoryEventListener() );

BPM 2006-12-03 09:54 发表评论

（二）: RETE算法

BPM — Sun, 03 Dec 2006 01:53:00 GMT

在 JBoss Rules 学习（一）:什么是Rule 中，我们介绍了JBoss Rules中对Rule的表示，其中提到了JBoss Rule中主要采用的RETE算法来进行规则匹配。下面将详细的介绍一下RETE算法在JBoss Rule中的实现，最后随便提一下JBoss Rules中也可以使用的另一种规则匹配算法Leaps。

1.Rete 算法 ：

Rete 在拉丁语中是 ”net” ，有网络的意思。 RETE 算法可以分为两部分：规则编译（ rule compilation ）和运行时执行（ runtime execution ）。

编译算法描述了规则如何在 Production Memory 中产生一个有效的辨别网络。用一个非技术性的词来说，一个辨别网络就是用来过滤数据。方法是通过数据在网络中的传播来过滤数据。在顶端节点将会有很多匹配的数据。当我们顺着网络向下走，匹配的数据将会越来越少。在网络的最底部是终端节点（ terminal nodes ）。在 Dr Forgy 的 1982 年的论文中，他描述了 4 种基本节点： root , 1-input, 2-input and terminal 。下图是 Drools 中的 RETE 节点类型：

Figure 1. Rete Nodes

根节点（ RootNode ）是所有的对象进入网络的入口。然后，从根节点立即进入到 ObjectTypeNode 。 ObjectTypeNode 的作用是使引擎只做它需要做的事情。例如，我们有两个对象集： Account 和 Order 。如果规则引擎需要对每个对象都进行一个周期的评估，那会浪费很多的时间。为了提高效率，引擎将只让匹配 object type 的对象通过到达节点。通过这种方法，如果一个应用 assert 一个新的 account ，它不会将 Order 对象传递到节点中。很多现代 RETE 实现都有专门的 ObjectTypeNode 。在一些情况下， ObjectTypeNode 被用散列法进一步优化。

Figure 2 . ObjectTypeNodes

ObjectTypeNode 能够传播到 AlphaNodes, LeftInputAdapterNodes 和 BetaNodes 。

1-input 节点通常被称为 AlphaNode 。 AlphaNodes 被用来评估字面条件（ literal conditions ）。虽然， 1982 年的论文只提到了相等条件（指的字面上相等），很多 RETE 实现支持其他的操作。例如， Account.name = = “Mr Trout” 是一个字面条件。当一条规则对于一种 object type 有多条的字面条件，这些字面条件将被链接在一起。这是说，如果一个应用 assert 一个 account 对象，在它能到达下一个 AlphaNode 之前，它必须先满足第一个字面条件。在 Dr. Forgy 的论文中，他用 IntraElement conditions 来表述。下面的图说明了 Cheese 的 AlphaNode 组合（ name = = “cheddar” ， strength = = “strong” ）：

Figure 3. AlphaNodes

Drools 通过散列法优化了从 ObjectTypeNode 到 AlphaNode 的传播。每次一个 AlphaNode 被加到一个 ObjectTypeNode 的时候，就以字面值（ literal value ）作为 key ，以 AlphaNode 作为 value 加入 HashMap 。当一个新的实例进入 ObjectTypeNode 的时候，不用传递到每一个 AlphaNode ，它可以直接从 HashMap 中获得正确的 AlphaNode ，避免了不必要的字面检查。

2-input 节点通常被称为 BetaNode 。 Drools 中有两种 BetaNode ： JoinNode 和 NotNode 。 BetaNodes 被用来对 2 个对象进行对比。这两个对象可以是同种类型，也可以是不同类型。

我们约定 BetaNodes 的 2 个输入称为左边（ left ）和右边（ right ）。一个 BetaNode 的左边输入通常是 a list of objects 。在 Drools 中，这是一个数组。右边输入是 a single object 。两个 NotNode 可以完成‘ exists ’检查。 Drools 通过将索引应用在 BetaNodes 上扩展了 RETE 算法。下图展示了一个 JoinNode 的使用：

Figure 4 . JoinNode

注意到图中的左边输入用到了一个 LeftInputAdapterNode ，这个节点的作用是将一个 single Object 转化为一个单对象数组（ single Object Tuple ），传播到 JoinNode 节点。因为我们上面提到过左边输入通常是 a list of objects 。

Terminal nodes 被用来表明一条规则已经匹配了它的所有条件（ conditions ）。在这点，我们说这条规则有了一个完全匹配（ full match ）。在一些情况下，一条带有“或”条件的规则可以有超过一个的 terminal node 。

Drools 通过节点的共享来提高规则引擎的性能。因为很多的规则可能存在部分相同的模式，节点的共享允许我们对内存中的节点数量进行压缩，以提供遍历节点的过程。下面的两个规则就共享了部分节点：

rule
    when
        Cheese( $chedddar : name == " cheddar " )
        $person : Person( favouriteCheese == $cheddar )
    then
        System.out.println( $person.getName() + " likes cheddar " );
end

rule
    when
        Cheese( $chedddar : name == " cheddar " )
        $person : Person( favouriteCheese != $cheddar )
    then
        System.out.println( $person.getName() + " does likes cheddar " );
end

这里我们先不探讨这两条 rule 到的是什么意思，单从一个直观的感觉，这两条 rule 在它们的 LHS 中基本都是一样的，只是最后的 favouriteCheese ，一条规则是等于 $cheddar ，而另一条规则是不等于 $cheddar 。下面是这两条规则的节点图：

Figure 5 . Node Sharing

从图上可以看到，编译后的 RETE 网络中， AlphaNode 是共享的，而 BetaNode 不是共享的。上面说的相等和不相等就体现在 BetaNode 的不同。然后这两条规则有各自的 Terminal Node 。

RETE 算法的第二个部分是运行时（ runtime ）。当一个应用 assert 一个对象，引擎将数据传递到 root node 。从那里，它进入 ObjectTypeNode 并沿着网络向下传播。当数据匹配一个节点的条件，节点就将它记录到相应的内存中。这样做的原因有以下几点：主要的原因是可以带来更快的性能。虽然记住完全或部分匹配的对象需要内存，它提供了速度和可伸缩性的特点。当一条规则的所有条件都满足，这就是完全匹配。而只有部分条件满足，就是部分匹配。（我觉得引擎在每个节点都有其对应的内存来储存满足该节点条件的对象，这就造成了如果一个对象是完全匹配，那这个对象就会在每个节点的对应内存中都存有其映象。）

2. Leaps 算法：

Production systems 的 Leaps 算法使用了一种“ lazy ”方法来评估条件（ conditions ）。一种 Leaps 算法的修改版本的实现，作为 Drools v3 的一部分，尝试结合 Leaps 和 RETE 方法的最好的特点来处理 Working Memory 中的 facts 。

古典的 Leaps 方法将所有的 asserted 的 facts ，按照其被 asserted 在 Working Memory 中的顺序（ FIFO ），放在主堆栈中。它一个个的检查 facts ，通过迭代匹配 data type 的 facts 集合来找出每一个相关规则的匹配。当一个匹配的数据被发现时，系统记住此时的迭代位置以备待会的继续迭代，并且激发规则结果（ consequence ）。当结果（ consequence ）执行完成以后，系统就会继续处理处于主堆栈顶部的 fact 。如此反复。

BPM 2006-12-03 09:53 发表评论

（一）: 什么是Rule

BPM — Sun, 03 Dec 2006 01:52:00 GMT

        学习JBoss Rules有几天了，因为这方面的中文资料较少，所以这几天都在看官网上的manual。这是一份不错的教程，我把我看的一些重要的东西翻译整理了一下，希望可以对想学习JBoss Rules的同学们提供一点帮助。
       在开始这份教程之前，我先简要介绍一下JBoss Rules：
       JBoss Rules 的前身是Codehaus的一个开源项目叫Drools。最近被纳入JBoss门下，更名为JBoss Rules，成为了JBoss应用服务器的规则引擎。
       Drools是为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。具有了OO接口的RETE,使得商业规则有了更自然的表达。

       既然JBoss Rules是一个商业规则引擎，那我们就要先知道到底什么是Rules，即规则。在JBoss Rules中，规则是如何被表示的

Rules

一条规则是对商业知识的编码。一条规则有 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 >
}

规则可以通过 package 关键字同一个命名空间（ namespace ）相关联；其他的规则引擎可能称此为规则集（ Rule Set ）。一个 package 声明了 imports ， global 变量， functions 和 rules 。

package com.sample

import java.util.List
import com.sample.Cheese

global List cheeses

function void exampleFunction(Cheese cheese) {
    System.out.println( cheese );
}

rule “A Cheesy Rule”
    when
        cheese : Cheese( type == " stilton " )
    then
        exampleFunction( cheese );
        cheeses.add( cheese );
end

对新的数据和被修改的数据进行规则的匹配称为模式匹配（ Pattern Matching ）。进行匹配的引擎称为推理机（ Inference Engine ）。被访问的规则称为 ProductionMemory ，被推理机进行匹配的数据称为 WorkingMemory 。 Agenda 管理被匹配规则的执行。推理机所采用的模式匹配算法有下列几种： Linear ， RETE ， Treat ， Leaps 。

Drools 采用了 RETE 和 Leaps 的实现。 Drools 的 RETE 实现被称为 ReteOO ，表示 Drools 对 Rete 算法进行了加强和优化的实现。

一条规则的 LHS 由 Conditional Element 和域约束（ Field Constraints ）。下面的例子显示了对一个 Cheese Fact 使用了字面域约束（ Literal Field Constraint ）

rule " Cheddar Cheese "
    when
        Cheese( type == " cheddar " )
    then
        System.out.println( " cheddar " );
end

上面的这个例子类似于：

public void cheddarCheese(Cheese cheese) {
     if ( cheese.getType().equals( " cheddar " ) {
        System.out.println( " cheddar " );
    }
}

规则引擎实现了数据同逻辑的完全解耦。规则并不能被直接调用，因为它们不是方法或函数，规则的激发是对 WorkingMemory 中数据变化的响应。结果（ Consequence ，即 RHS ）作为 LHS events 完全匹配的 Listener 。

当 rules 被加入 Productioin Memory 后， rules 被规则引擎用 RETE 算法分解成一个图：

当 Facts 被 assert 进入 WorkingMemory 中后，规则引擎找到匹配的 ObjectTypeNode ，然后将此 Fact 传播到下一个节点。 ObjectTypeNode 拥有一块内存来保存所有匹配的 facts 。在我们的例子中，下一个节点是一个域约束（ Field Constraint ）， type = = “cheddar” 。如果某个 Cheese 对象的类型不是“ cheddar ”，这个 fact 将不会被传播到网络的下一个节点。如果是“ cheddar ”类型，它将被记录到 AlphaNode 的内存中，并传播到网络的下一个节点。 AlphaNode 是古典 RETE 术语，它是一个单输入 / 单输出的节点。最后通过 AlphaNode 的 fact 被传播到 Terminal Node 。 Terminal Node 是最终节点，到此我们说这条规则被完全匹配，并准备激发。

当一条规则被完全匹配，它并没有立刻被激发（在 RETE 中是这样，但在 Leaps 中它会立刻被激发）。这条规则和与其匹配的 facts 将激活被放入 Agenda ，由 Agenda 来负责安排激发 Activations （指的是 rule + the matched facts ）。

下面的图很清楚的说明了 Drools 规则引擎的执行过程：

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

BPM 2006-12-03 09:52 发表评论