Drools研究 drools学习.doc

Drools的进一步研究徐建军 2006-09-241.概述12.规则表示22.1.Package22.2.Rule42.2.1.规则属性52.2.2.LHS62.2.3.RHS82.3.Query92.4.DSL102.5.XML112.6.决策表133.规则编译154.Rete算法184.1.Rete网络的构成184.2.基于Rete网络的前向推理过程245.Leaps算法245.1.Leaps推理机的构造过程265.2.事实对象的操作过程315.2.1.事实对象的断言过程315.2.2.事实对象的收回过程325.2.3.事实对象的修改过程335.3.基于Leaps推理机的前向推理过程335.4.Droosl 3的Leaps算法的说明376.RuleBase387.WoringMemory398.Agenda439.Drools的下一步发展4510.结论461. 概述在介绍规则系统的文章中，经常提到的一句话是：任何事物都会改变，唯一不变的是变化。Drools同样也不例外。目前Drools已经从Codehaus中独立出来，转投JBoss这座靠山，目前最新发布版本是3.0.4。目前名称叫JBoss Rules，但为了描述方便，这里仍称为Drools。Drools 3与前面分析的2.5版本比较在很多方面都发生了改变。图1描述了目前Drools规则引擎的构成。图1 Drools规则引擎的构成 从图上可以发现最显著的变化是引擎的模式匹配（Pattern Matcher）算法除了实现了Rete算法，还实现了Leaps算法。但是其它模块在具体细节上也有改变或者改进。本文主要针对Drools 2.5版本，介绍Drools 3新的实现方法和机制。并且只对这些变化较大的部分进行介绍，而忽略了相同的或者有细微改变但实现原理相通的地方。理解不清的部分可以参照以前的分析文档。本文首先介绍了Drools 3中一个主要变化：Drools独立的规则定义语言，其中还包括DSl和决策表。然后介绍Drools 3的规则编译过程。重点分析Drools 3中的两种推理算法Rete算法和Leaps算法，对于Rete算法只介绍了Drools 3和Drools 2.5实现的不同之处，由于Leaps算法是Drools 3新引进的算法，所以对它进行了详细分析。最后分几小节介绍Drools 3在RuleBase、WorkingMemory和Agenda三个部分所进行的主要改进，最后给出结论。2. 规则表示Drools 3与Drools 2.5相比较，很重要的改变就是规则的表示从XML格式转变为文本格式，使用了一套自己的规则描述语言。这种语言的格式非常简单易懂，便于规则的创建和维护，而且可以通过DSL（Domain Specific Languages）的形式进行扩展。规则定义文件仍然以“drl”为后缀，同时Drools 3仍然支持XML格式的规则定义方式。为了方便对业务规则的定义、维护和分析，Drools 3还实现了决策表功能。2.1. Packagepackage表示一系列规则的集合，是定义和管理规则的基本单位，对应到Drools 2.5中的RuleSet。与Java的package不同，这里package的名称只有名字空间的作用，与文件和目录结构无关。package的主要内容由import、expander、global、function、query和rule部分构成。结构见图2。下面主要介绍import、expander、global和function四个部分，query和rule在后续小节中介绍。图 2 package的语法结构这里的import语句与Java中的import语句功能相同。把规则需要引用的Java对象类名德全路径写在“import”之后，规则引擎运行时会自动装载相应类。示例如下：import org.drools.examples.FibonacciExample.Fibonacci;expander语句用于表示扩展规则定义所需的DSL文件，这些DSL文件解释了规则体中针对特定问题领域的方便用户理解的组成元素。示例如下：expander ticketing.dsl;global语句表示多个规则用到的全局变量，常用于表示规则使用的数据，对应于Drools 2.5中的application-data属性。如果多个包同时定义同一名称的全局变量，那这些变量必须是同一类型，实际执行时它们都指向同一变量。由于全局变量并不会断言到WorkingMemory中，引擎并不知道变量值是否发生了改变，所以全局变量一般不能用在规则的条件限制语句（constraints）中，除非明确知道global变量值不会发生改变。示例如下：global java.lang.Integer i;function表达式用于定义规则体经常使用的业务逻辑，常用在规则的结论部分。引擎实际执行时会将function部分编译成Java代码。用function的形式把业务逻辑提取出来的好处是便于重用。function String calcSomething(String arg) return hola !;一个完整的package例子如下：package org.drools.examplesexpander fibonacci.dsl import org.drools.examples.FibonacciExample.Fibonacci;function String calcSomething(String arg) return hola !;query query1.rule rule1.2.2. Rule规则体采用IFTHEN格式，这里关键字分别采用的是“when”和“then”（不用“IF”的原因是IF一般对应于ELSE），以关键字“end”表示规则的结束。规则的语法结构见图3。图 3 rule的语法结构要求规则名称在一个package中必须唯一。规则体的基本构成包括：规则的基本属性、LHS（Left Hand Side，条件部分）和RHS（Right Hand Side，结论部分）。2.2.1. 规则属性规则有下面这些属性： no-loop：布尔型，标识规则是否循环执行，规则的结论部分可能会修改某个事实，而这次修改可能会导致这条规则再次被激发。如果no-loop属性值设为true，则引擎会忽略后面新产生的激活规则动作。 salience：整数类型，表示规则的优先级，值越大则优先级越高。 agenda-group：字符串类型，当Agenda调度执行激活的规则时，会将规则分组依序执行。Agenda当前组中的规则会先被调度，只用当前组中规则全部执行完成后，然后再调度后续组中的规则。 auto-focus：布尔型，如果该值被设为“true”，即便该规则不属于Agenda的当前组，也会被调度执行； activation-group：字符串类型，与Drools 2.5中的作用相同，表示互斥的规则组，即同一activation-group的规则只会执行其中的一条。 duration：长整型，有时规则需要延迟执行，该属性表示需要延迟的时间。示例如下：rule my rulesalience 42agenda-group number 1when .2.2.2. LHSLHS是规则的条件部分，由多个pattern构成（见图4），而pattern的最基本组成单位是column（见图5）。并且每个column可以进行事实绑定（factBinding），实际上是把column表示的事实对应到一个变量，这样的变量可以用在规则的其他条件以及规则的Consequence部分。 图4 LHS的语法结构 图5 pattern的语法结构图 6 column的语法结构column的作用是对工作内存中的事实对象进行限制（constraint，类似于过滤），其语法结构见图6。实现方法是把事实对象作为一个JavaBean对象处理，在column中出现的事实对象的属性（field）会转化为事实对象的对应方法。例如“Cheese(type = .) ”，会调用工作内存中的Cheese类型的事实对象的getType方法进行比较。l literalConstraint：literalConstraint是最基本的限制方法，它直接把事实对象的属性进行比较。支持的类型包括：Numeric（数字型）、Date、String、Boolean、Enum和Regexp（正则表达式型）。每种类型的都提供了相应的操作符，这些操作符包括： | | = | = | != | matches | contains | excludes。其中matches用于正则表达式型，contains和excludes都用于集合类型。l boundVariableConstraint：把事实对象或事实对象的属性绑定为一个变量，然后该变量就可以在规则的LHS的其他地方被使用。下面的例子中，Person对象的属性“favouriteCheese”就被绑定为变量“likes”：Person( likes : favouriteCheese )Cheese( type = likes )l predicateConstraint：使用-操作符，表示对事实对象属性的进一步限制。例如下面的示例，它表示所有比某一女性大两岁的男性。Person( girlAge : age, sex = F )Person( boyAge : age - ( girlAValue() = boyAValue() + 2 ), sex = M )l returnValueConstraint：功能与predicateConstraint表达式相同，表示对事实对象属性的进一步限制。例如下面的示例，作用与上述例子一样，但表述起来更加简单自然。Person( girlAge : age, sex = F )Person( age = ( new Integer(girlAValue() + 2) ), sex = M )在使用上述语法结构定义的一个或者多个column的基础上，使用CE（Conditional Element）可以定义更加复杂的规则条件。目前支持的CE包括下面几种：l and：用and或&来表示，表示column之间的与关系。l or：用or或|来表示，表示column之间的或关系。使用or这种CE，规则引擎执行时会根据or操作符把规则分为两条独立部分（在Rete网络中，这条规则有两个独立的TerminalNode）。例如下面这个例子，在实际执行时，规则引擎会将其解析成两个独立部分，一部分包含column：pensioner : ( Person( sex = f, age 60 )；另一部分包含column：pensioner : Person( sex = m, age 65 ) )。pensioner : ( Person( sex = f, age 60 ) or Person( sex = m, age 65 ) )l eval：用eval来表示，表示确认计值，允许执行Java代码片段，可以调用function功能，一般用在规则LHS部分的最外层。在实际执行时，因为规则引擎每次都要eval表达式进行重新计值，eval表达式的效率要比一般column的效率低，但column的功能用eval都能实现。l not：用not来表示，表示工作内存中不存在其内嵌column表示的事实对象。目前版本的Drools只支持直接内嵌column，下一步它将支持内嵌and和or语句。l exists：用exists来表示，与not相反，表示工作内存中存在（at least one，至少有一个）其内嵌column表示的事实对象。目前版本的Drools只支持直接内嵌column，下一步它将支持内嵌and和or语句。l group：用(和)来表示，作用等效于数学运算中括号，用来明确条件运算的优先级。2.2.3. RHSRHS是规则的结论部分（Consequence），可以是Java语义的代码（Drools声称下一步将支持其它语言，如groovy和C#）。RHS的主要作用是向工作内存中断言、收回和修改事实，当然它也可以针对特定应用的动作。RHS部分的关键字包括“log”、“assert”、“retract”和“modify”等，并且LHS中被绑定的变量也可以在这里出现。这里需要指出的是，Drools 3在RHS还提出一个新关键字：“assertLogical”。“assertLogical”与“assert”的功能类似，也是向工作内存中断言一个事实。但它表示的是一种逻辑断言。事实如果是被某一规则的结论部分以逻辑断言的形式断言到工作内存中，当这条断言事实的规则不再有效时，该事实对象会被引擎自动收回。（详细的关于逻辑断言解释参见工作内存小节）一个完整的rule例子如下。这个例子的作用是求解Finonacci级数，LHS部分声明了三个事实变量：f1、f2和f3。这三个变量的序号是连续的，即f3.sequence = f2.sequence + 1 = f1.sequence + 2。其中f1和f2的值已经被求出（value != -1），f3的值还没有被求出（value = -1）。RHS部分先根据f1和f2的值，求f3的值（f3.setValue( f1.getValue() + f2.getValue() )）。然后修改事实f3，收回事实f1，最后在终端上显示操作结果。rule “Fibonacci Calculate”whenf1 : Fibonacci( s1 : sequence, value != -1 )f2 : Fibonacci( s2 : sequence = (new Integer( Value() + 1 ) ), value != -1 ) f3 : Fibonacci( sequence = (new Integer( Value() + 1 ) ), value = -1 )thenf3.setValue( f1.getValue() + f2.getValue() );modify( f3 );retract( f1 );System.out.println( f3.getSequence() + = + f3.getValue() );end2.3. QueryDrools新提供了查询（Query）的功能，能够从工作内存查询符合条件的事实。其语法结构见图7，即查询体只包含Rule的LHS部分，没有关键字“when”和“then”，同样以“end”结束。要求查询的名称对于一个RuleBase是唯一的（而不是限于一个package）。图 7 query的语法结构下面是一个关于查询的例子，查询的是年龄大于30的人。query people over the age of 30 person : Person( age 30 )end通过WorkingMemory.getQueryResults(name)方法获取查询结果，这里name指的是查询的名称，返回查询结果QueryResults，其中包含的一个QueryResult对象的列表，可以通过for循环取得其中的元素，示例如下：QueryResults results = workingMemory.getQueryResults( people over the age of 30 );System.out.println( we have + results.size() + people over the age of 30 );System.out.println( These people are are over 30: );for ( Iterator it = results.iterator; it.hasNext(); ) QueryResult result = ( QueryResult ) it.next(); Person person = ( Person ) result.get( person ); System.out.println( person.getName() + n );2.4. DSLDSL（Domain Specific Languages）的作用是能够针对特定问题领域对规则定义语言进行扩展。通过DSL可以实现所要解决的特定问题与规则引擎所处理的对象之间的分离。DSL隐藏了具体的实现细节，而使得规则编辑者将注意力集中于规则的业务逻辑。它能够使得那些不了解技术细节的非技术人员也能够很容易地编辑、理解和维护业务规则。另一方面，DSL还具备规则定义“模板”的作用，它把一些比较复杂又经常使用的业务规则片段对应于用自然语言表示的描述，然后在定义具体规则时就可以以DSL的方式使用已经定义好的业务规则片段。DSL不会对规则引擎的运行产生任何影响，它仅仅在编辑、解析和编译时才会起作用。但DSL的定义需要领域专家与技术人员共同合作完成。与Drools 2相比，Drools 3的DSL发生了很大变化（Drools 2也有DSL机制吗？）。在下面一小节，介绍了Drools 3的规则定义也可以用XML格式进行描述，所以可以通过XSLT工具把Drools 2的DSL内容映射成为Drools 3的格式。具体的DSL内容是以文本文件的形式存放，而且Drools自身的IDE提供DSL文件编辑器。DSL的格式非常简单，如下示：scopeThis is something=Something(something=something)其中“scope”可以是“when”和“then”，表示这个DSL配置是属于规则的LHS还是RHS。“scope”之后是会出现在规则中的类似于自然语言的表达式，“=”右边部分是符合规则定义语言的表达式，实际解析规则时会将左边内容映射成右边内容，“”和“”之间的部分表示所要传递的参数。一个具体的例子如下：whenThere is a Person with name of name=Person(name=name)whenPerson is at least age years old and lives in location=Person(age age, location=location)thenLog message=System.out.println(message);使用定义好的DSL配置需要两个步骤：一是通过package的expander属性指定；二是在解析编译规则是，需要把DSL源文件名传给相应的API，示例如下：PackageBuilder builder = new PackageBuilder();builder.addPackageFromDrl( source, dsl );DSL的具体实现请参见drools-compiler项目中ExpanderResolver、Expander 和DefaultExpander等类，详细的解释请参看规则编译部分。2.5. XMLDrools 3除了支持使用它自身的规则定义语言（DRL）定义规则之外，还支持以XML格式定义规则。所有在DRL中支持的功能都能在XML格式中实现。由于XML是与平台无关的数据格式，所以使用XML的好处是具有很好的可移植性，规则定义可以在不同的规则系统中移植使用。它的缺点在于没有DRL方式容易理解和维护。一个示例如下（说明：该示例并没有实际含义，只是表示了规则定义的XML格式）。 System.out.println(hello world); System.out.println( hello ); 可以发现所有在DRL中的语法元素都能以XML格式实现。规则主要有lhs和rhs两部分构成，rhs非常简单（直接是Java语义的模块），而lhs要复杂得多，lhs的基本构成元素仍是“column”。与Drools 2.5相比，Drools 3的XML格式有很多不同之处，但也有许多类似的地方，例如两者都有“import”和“function”的概念，Drools 3中的“global”等效于Drools 2.5的“application-data”。通过stylesheet工具可以实现把Drools 2.5的规则定义转化为Drools 3的规则定义。同DRL方式一样，XML格式的规则在解析编译时也会被转化为“AST”格式的内部表示，而AST格式的内部表示可以根据需要通过对应的dumper类反转化为DRL格式或者XML格式，因此可以实现规则定义DRL格式与XML格式的互相转化。相关的类有： org.drools.xml.XmlDumper：根据AST中间格式，把规则内容以XML格式导出； org.drools.lang.DrlDumper：根据AST中间格式，把规则内容以DRL格式导出； piler.DrlParser：解析输入的DRl文件，将规则内容转化成AST中间格式； org.drools.xml.XmlPackageReader：解析输入的XML文件，将规则内容转化成AST中间格式。2.6. 决策表决策表（decision table）是一种精确而又紧致（compact）的表达条件逻辑的方法，非常适合用于表达业务规则。Drools 3增加了对决策表的支持，即支持以电子表格格式（Spreadsheet）表示的规则，目前这些电子表格格式包括Excel和CSV等。可以用Microsoft Excel或者OpenO Calc这些工具进行编辑和管理。Drools声称将实现一个基于Web的决策表工具。在Drools中，决策表的作用是能够利用决策表的各项特点编辑和管理电子表格，再根据电子表格中的数据产生对应的业务规则。规则在决策表中体现为模板加数据，即先在表格中定义了规则的基本格式（模板），然后再在具体的行中填入规则信息（数据）。实际执行时，配合模板可以生成对应的业务规则。下图是一个示例：图 8 决策表示例图中9到11行定义了规则包（package）的一些信息，从14行到16行说明了规则的基本格式（模板）。17行和18行分别定义了两条具体的规则，其中C列和D列定义规则的LHS部分，D列定义了规则的RHS部分。从字面上可以看出，某些行用关键字表示它的特殊作用，例如“RuleSet”、“Import”和“RuleTable”等。这里“RuleSet”和“RuleTable”分别对应于Drools规则定义语言中的“package”和“rule”。规则中的参数用“$”表示，具体的参数值在相应的表格项中，例如17行的“42”、“stillton”和“Old man stilton”。从本质上说，决策表的作用是能够方便地自动产生DRL规则。drools-decisiontables项目中的org.drools.decisiontable.SpreadsheetCompiler类是处理这些电子表格的类，它允许输入的电子表格采用不同的格式，输出的是DRL格式的规则描述，然后这些输出的规则就可以与普通规则一样被使用了。Drools 3提供的IDE提供了创建决策表的功能。总的说来，电子表格应用于商业领域已经有很长一段时间了。而决策表能够让领域专家与IT应用更好地合作，在很大程度上方便了业务规则的定义、维护和分析，从而很好地实现了关注点的分离。3. 规则编译Drools 分为两个主要部分：构建（ Authoring ）和运行时（ Runtime ），具体由drools-compiler项目负责规则的解析和构建工作，它的工作原理见下图：图 9 构建规则库的过程输入可以是drl格式和xml格式的规则文件，它们被读入一个解析器，使用 ANTLR 3解析器或者XML解析器进行解析。解析器对语法进行正确性的检查，然后产生一种中间描述（Intermediate descr）结构AST模型。 AST 模型然后被传到 Package Builder ，由 Package Builder 来产生 package 对象。 PackageBuilder 还承担着一些代码产生和编译的工作，这些对于产生 package对象都是必需的。drools-compiler项目中主要的类和它们之间的关系见图10。图 10 drools-compiler项目的主要类图一般情况下客户端与piler.PackageBuilder类打交道，PackageBuilder向外提供了两个方法：“addPackageFromDrl”和“addPackageFromXml”。PackageBuilder调用了具体解析类DrlParser和XmlPackageReader，屏蔽了底层的实现细节。下面的例子说明了如何从classpath中的xml和drl文件创建一个Package对象。注意：所有传入同一个PackageBuilder实例的规则源，都必须是在相同的package 命名空间（namespace）中，例如“org.drools”和“org.drools.test”就是在一个命名空间。PackageBuilder builder = new PackageBuilder();builder.addPackageFromDrl(new InputStreamReader(getClass().getResourceAsStream(package1.drl);builder.addPackageFromXml(new InputStreamReader(getClass().getResourceAsStream(package2.drl);Package pkg = builder.getPackage();实际完成解析工作的是piler.DrlParser和org.drools.xml.XmlPackageReader两个类。传给DrlParser类的是drl文件生成的Reader对象，然后DrlParser使用了ANTLR 3 语法解析器进行解析，具体由org.drools.lang.RuleParser类完成，最后生成描述规则的AST中间模型。XmlPackageReader接收由xml文件生成的Reader对象，调用SAX解析器解析xml文件内容，生成描述规则的AST中间模型。关于规则AST模型的类详见org.drools.lang.descr包。如果规则使用DSL功能，则会用到org.drools.lang.Expander和org.drools.lang.ExpanderResolver 等类，详细的实现在org.drools.lang.dsl和org.drools.lang.dsl.template包。在这里，Drools本身实现了一个小的解析器，把DSL中的面向特定领域的描述映射成可以理解的规则描述。需要注意的是Expander和ExpanderResolver都是接口，编译器再解析DSL内容的时候使用了默认的实现类DefaultExpander和DefaultExpanderResolver。但也可以使用自定义的实现类，通过这种方式可以实现自定义格式的DSL内容。PackageBuilder类还负责根据DrlParser和XmlPackageReader解析产生AST的模型生成Java语义的规则代码，这里涉及的相关类是org.drools.semantics.java.FunctionBuilder和org.drools.semantics.java.RuleBuilder。然后通过JCI（Java Compiler Interface）把生成的代码编译成可以可被规则引擎调用执行的Java类。另外PackageBuilder可以通过org,piler.PackageBuilderConfiguration类配置的。通常，你可以指定另一个parent ClassLoader和用什么编译器（compiler），默认是Eclipse JDT。下面显示了如何指定JANINO编译器：PackageBuilderConfiguration conf = new PackageBuilderConfiguration();conf.setCompiler( PackageBuilderConfiguration.JANINO );PackageBuilder builder = new PackageBuilder( conf );org.drools.lang.DrlDumper类和org.drools.xml.XmlDumper类则分别可以把描述规则的AST中间格式转化成drl文件格式和xml文件格式，从而实现规则的drl格式和xml格式的互换。通过piler.RuleBaseLoader类的loadFromReader方法可以直接创建用于运行期的RuleBase对象，而RuleBaseLoader实际上也是调用了PackageBuilder的方法。整个构建期的大概执行过程可以用下面的UML顺序图描述（这里只说明了drl格式规则的解析过程）。首先由PackageBuilder的addPackageFromDrl方法引领，然后调用DrlParser的解析功能，如果规则文件使用了DSL功能则使用DefaultExpanderResolver类实现DSL内容到规则的映射，然后由RuleParser类通过ANTLR 3 语法解析器对规则内容进行解析，返回给PackageBuilder解析产生的AST中间模型。PackageBuilder根据包名与已有的包进行合并，然后调用FunctionBuilder和RuleBuilder类生成对应的Java语义的源代码，最后调用JCI功能对产生的源代码进行编译。图 11 解析过程的UML顺序图4. Rete算法4.1. Rete网络的构成Drools 3的Rete算法的实现与Drools 2.5相比较，有了很大的变化。在 Dr Forgy 的 1982 年的论文中，他描述了4种基本节点：root、1-input、2-input 和 terminal。而图12列出的是Drools 3中Rete算法的节点类型。下面详细介绍每一种节点。图 12 Drools 3中Rete算法的节点类型（1）ReteNode：根节点是所有的对象进入网络的入口，然后从根节点直接进入到 ObjectTypeNode。实际程序中并没有ReteNode这个类，实现对应功能的类应该是org.drools.reteoo.Rete类。（2）ObjectTypeNode：ObjectTypeNode与Drools 2.5相比较没有太大的变化，它的作用是使引擎只做它需要做的事情，能够根据事实对象类型（ObjectType）对事实进行匹配过滤。Drools 3的ObjectTypeNode 用HashMap格式的Cache进一步优化，即每次对事实的ObjectType进行匹配进行时，先从Cache中查看是否有对应ObjectTypeNode列表存在，有则直接返回ObjectTypeNode列表，否则从Rete规则网络中查找对应ObjectTypeNode，放到Cache中再返回。ObjectTypeNode能够传播到AlphaNode、LeftInputAdapterNode和BetaNode。（3）AlphaNode：原始算法中的1-input节点在Drools 3中主要对应的是AlphaNode（在Drools 2.5中对应的是ConditionNode）。AlphaNode被用来评估规则中单独的条件，例如A = “Mr Trout”。显然对于一个ObjectTypeNode 有多条的匹配条件，即在Rete规则网络中有多个后继的AlphaNode。如果这些条件属于同一规则将被链接在一起。这意味着如果一个事实对象如果要遍历Rete规则网络，在它能到达下一个 AlphaNode 之前，它必须先满足其前面AlphaNode对应的条件。图13说明了这样的 AlphaNode 组合：Cheese（name=“cheddar”，strength=“strong”）。图 13 Alpha节点组合示例Drools 通过散列法优化了从 ObjectTypeNode到AlphaNode 的传播。每次一个 AlphaNode 被加到一个ObjectTypeNode的时候，就以条件对应的字面值（literal value）作为key，以AlphaNode作为value加入HashMap。当一个新的实例进入 ObjectTypeNode 的时候，不用传递到每一个AlphaNode，它可以直接从 HashMap 中获得正确的 AlphaNode，避免了不必要的字面检查。（4）EvalNode：EvalNode用于规则定义的EvalCondtion表达式中。它与AlhpaNode相似，也是用来进行条件判断的。但EvalNode的条件判断是一种计值判断，即需要执行条件部分。而且EvalNode的输入输出是元组（Tuple），而AlphaNode输入输出仍然是事实对象（Object）。（5）JoinNode：原始算法中的2-input节点在Drools 3中对应的是BetaNode。Drools 3中有两种 BetaNode：JoinNode和NotNode。BetaNode 被用来对2个对象进行对比。这两个对象可以是同种类型，也可以是不同类型。BetaNode的2个输入被称为左边和右边。一个BetaNode 的左边输入通常是对象列表（在实现时用Tuple表示），右边输入是单一的事实对象。JoinNode表示一般的汇聚操作，图14展示了一个 JoinNode 的使用：图 14 JoinNode（6）LeftInputAdapterNode：图14中左边输入用到了一个 LeftInputAdapterNode ，这个节点一般用来表示BetaNode的左输入。LeftInputAdapterNode的作用是将一个事实对象转化为一个元组（Tuple，实际上是事实对象列表），传播到后继节点。（7）NotNode：NotNode对应规则定义中的“not”CE。如下图示，它也是一个BetaNode，左边是一个TupleSource，对应“not”CE的前提条件，右边是一个ObjectSource，对应“not”CE内嵌的column。图 15 NotNodeNotNode的工作原理是：如果来自TupleSource的Tuple和来自ObjectSource的Object能够在NotNode构成一个匹配，则说明该Tuple对象能够使得“not”CE内嵌的column被满足，所以该Tuple不符合“not”CE的语义限制，NotNode会收回已经通过的Tuple对象；如果来自TupleSource的Tuple和来自ObjectSource的Object不能在NotNode构成一个匹配，则说明该Tuple对象不能使得“not”CE内嵌的column被满足，所以该Tuple符合“not”CE的语义限制，NotNode不会影响左边的Tuple对象通过。所以总结起来，NotNode在Rete网络中的作用体现在根据右边输入对左边输入的Tuple进行过滤。注意如果“not”CE没有前提条件，那么左边输入一定是一个LeftInputAdapterNode，并且这个LeftInputAdapterNode的源节点是类型为InitialFact类型的ObjectTypeNode。InitialFact类型是Drools 3保留使用的一种事实类型。规则引擎在创建工作内存过程中，会自动先断言一个InitialFact类型事实，其作用就是让那些没有前提条件的“not”CE能够直接被满足。（8）RightInputAdapterNode：作用与LeftInputAdatperNode相反，它会从输入的Tuple对象提取出一个Object对象，并输出。主要用下面要介绍的ExistsNode中。（9）ExistsNode：ExistsNode并不是Rete网络中的一个实际的节点，如下图所示的虚线框，ExistsNode由两个NotNode和一个RightInputAdapterNode组合构成。ObjectSource部分表示“exists”CE内嵌的column。TupleSource部分表示执行对应“exists”CE的前提条件。图 16 ExistsNodeExistsNode的工作原理是：如果来自TupleSource的Tuple和来自ObjectSource的Object能够在NotNode(1)构成一个匹配，所以会通知RightInputAdapterNode收回已经通过NotNode(1)的Tuple，那么在NotNode(2)将不会形成匹配，所以不影响左边TupleSource的Tuple通过NotNode。如果来自TupleSource的Tuple和来自ObjectSource的Object不能在NotNode(1)构成一个匹配，所以左边的Tuple通过NotNode(1)后到达RightInputAdapterNode。然后RightInputAdapterNode与来自左边TupleSource的Tuple会在NotNode(2)形成一个匹配，所以会收回已经通过NotNode(2)的Tupl