基于P2P全文检索系统的设计与实现.doc

作者签名： 导师签名 日期： 年 月 日 Drools 规则引擎在 ERP 系统中的应用 摘 要：ERP 软件作为一个通用产品，需要灵活地适应不同客 户的个性化需求，也需要适应客户业务规则的经常性变化，这要求 ERP 软件是高度可配置、可修改的；这种配置和修改工作最好能由 ERP 实施顾问和没有技术背景的业务人员来完成，以降低系统的维 护成本。为了达到这个目标，传统的解决办法是通过精心设计一个 数据库系统或文件配置系统来支持系统的可配置性，少数经常需要 动态修改的地方则借助于脚本语言来完成。这种解决方法的缺点是： 它只能在一个相对固定的范围内工作，超出这个范围，它就会失控 或无能为力；使用脚本语言的地方则性能低下，并且非专业技术人 员很难进行维护。自上世纪八十年代出现规则引擎技术后，人们即 寄希望于它能解决此类难题，但直到近十年来，规则引擎技术逐渐 成熟，性能大幅提升，业界才出现少量成功案例。本文重点讨论如 何在 ERP 系统中应用规则引擎技术，以提高系统的动态可修改性， 并降低维护的成本。 本文首先介绍了规则引擎的工作原理，讨论了规则引擎常用的 两种模式匹配算法RETE 算法和 LEAPS 算法的原理；接着从实用 的角度简明地分析了 Drools 规则引擎的开发、测试及部署技术；最 后文章系统地探讨了如何在 ERP 基础框架和 ERP 业务场景中应用 Drools 规则引擎,以及应用中可能遇到的典型问题及解决办法。在 ERP 基础框架的应用中，论文给出了用 Drools 规则引擎来实现数据 校验、数据联动、信息交换平台等功能模块的解决方案，探讨了使 用 Drools 规则引擎时可能遇到的性能问题及解决办法。在 ERP 业务 系统的应用中，论文从 ERP 财务系统和业务系统两方面探讨了 Drools 规则引擎的使用方法，最后，论文还探讨了如何建立一个容 易阅读和理解的领域语言，以便业务人员能用它来描述业务规则， 从而降低系统的维护成本。 图 20 幅，表 18 个，参考文献 55 篇。 关键词：Drools；规则引擎；ERP；RETE；LEAPS 分类号： TP311 The Application of Drools Rules Engine in ERP Systems Abstract：An ERP system, as a general-purpose software system, should adapt to various requirements and changeful business rules of its customers. This requires the ERP software is highly configurable and modifiable. In order to reduce the system maintenance costs, the changeful business rule base should preferably be maintained by ERP consultants or business people without any technical background. To achieve this goal, the traditional solution is building a configurable database system or file system elaborately, and using scripting language in some special places. But this solution has some obvious defects, such as it can work fine only in a fixed scope, beyond that, it will out of control; and the script programs are poor performance and difficult to maintain to non-professional people. This paper focuses on how to solve these problems by using Drools, an open source rules base engine, in the ERP system. In this paper, firstly, we explain the working principle and the matching algorithms of a rules engine. Then we discuss the development, test and deployment technologies of the Drools rules engine. Finally, we systematically research how to use the Drools rules engine in the basic framework and business modules of an ERP system. Some typical problems and solutions that like to be encountered when using Drools are also discussed in this paper. 20 figures, 18 tables, 55 references. Keywords: Drools, Rules Engine, ERP, RETE, LEAPS Classification: TP311 目录 原创性声明原创性声明.I 摘要.II 目录.IV 第一章 绪论.1 1.1 课题背景和意义.1 1.2 国内外研究现状.2 1.3 论文研究内容及组织结构.6 1.3.1 论文的研究内容.6 1.3.2 论文的组织结构.6 第二章 相关理论基础.8 2.1 Drools 规则引擎的基本概念.8 2.1.1 Drools 规则系统.8 2.1.2 Drools 规则系统.9 2. 2 RETE 算法.10 2.2.1 RETE 算法.10 2.2.2 RETE 算法的优缺点.15 2.3 LEAPS 算法 .15 2.4 Drools 开发环境概述.16 2.5 Drools 规则编译运行与部署.17 2.5.1 Drools 规则描述.17 2.5.1 Drools 规则编译运行.21 2.5.3 Drools 部署于测试.23 2.6 本章小结.25 第三章 基于 Drools 在 ERP 系统框架研究.26 3.1 需求分析与系统设计问题.26 3.1.1 需求分析问题.26 3.1.2 系统设计问题.28 3.2 Drools 在 ERP 系统框架中的应用场景.28 3.2.1 数据校验.28 3.2.2 数据联动.31 3.2.3 信息交换平台.33 3.2.4 工作流.36 3.2.5 其它场景.38 3.3 性能问题.38 3.3.1 多次启动、多次加载带来的性能问题.38 3.3.2 临时编译、多次编译带来的性能问题.38 3.3.3 频繁调用带来的性能问题.39 3.3.4 巨量规则库带来的性能问题.40 3.4 本章小结.40 第四章 Drools 在 ERP 业务系统中的应用 .42 4.1 应用场景概述.42 4.1.1 ERP 系统结构概述.42 4.1.2 ERP 系统数据概述.43 4.1.3 应用场景概述.45 4.2 Drools 在 ERP 财务系统中的典型应用场景.46 4.2.1 财务会计平台.46 4.2.2 管理会计平台.49 4.2.3 其它财务系统.51 4.3 Drools 在 ERP 业务系统中的典型应用场景.52 4.3.1 供应链系统中的典型应用.52 4.3.2 其它业务系统中的典型应用.53 4.4 业务规则低成本维护与领域语言.54 4.4.1 业务规则的低成本维护.54 4.4.2 领域语言的建立与使用.55 4.4.3 领域语言的维护.57 4.5 本章小结.58 第五章 总结与展望.59 5.1 全文总结.59 5.2 后期展望.59 参考文献.61 攻读学位期间主要的研究成果.64 致 谢.65 工程硕士学位论文 第一章 绪论 1 第一章 绪论 1.1 课题背景和意义 对于 ERP 这类庞大而复杂的软件系统来说，不同的用户通常有着不同的个 性化需求，并且随着时间的变化，有些用户的业务规则可能经常发生变化，因 此，在开发一个 ERP 系统时，分析和设计人员需要非常小心地注意这些可能频 繁地发生变化的地方。在分析时需要将未来可能经常变化的功能模块与未来不 会或很少发生变化的功能模块进行分离；在开发和设计时又往往需要采用一些 特别的技术，以便将来能方便地进行配置或低成本地进行修改。但长期以来， 让软件方便灵活地随着用户需求的变化而变化从来就不是一件容易的事。上世 纪八十年代规则引擎出现了，它一出现就得到广泛重视，被寄望于能彻底解决 此类问题，但由于技术不成熟，性能低下，在当时的实际应用中罕见成功案例。 近十年来，规则引擎技术有了长足的发展，性能已不再是问题，技术也日趋成 熟，它再次被寄望于能有效地解决此类问题。 随着信息技术的发展，企业的信息化程度越来越高；今天，绝大多数现代 企业的日常经营不得不依赖于信息系统。但是随着时间的变迁、企业的发展， 市场发生了变化、公司的产品发生了变化、产品的工艺流程发生了变化、公司 的销售策略发生了变化、公司的管理政策发生了变化为了应对这一切变化， 当初为企业量身打造的信息系统也不得不随时进行修改。但对于 ERP 这类复杂 的信息系统来说，其修改和维护决不是一件简单的事。下面的分析说明了这种 修改和维护的困难及高昂代价： (1) 频繁的系统维护可能影响企业的正常运营； (2) 信息系统的修改总是滞后于需求的变化，这必将影响企业正常的运营或对 市场的响应速度； (3) 需要专门的技术人员才能维护信息系统，但这些技术人员往往对业务并不 熟悉，他们需要与业务人员进行充分的沟通才能准确地把握业务需求，一旦沟 通不充分或者理解不准确就可能导致修改后的系统不能满足业务的需求。于是 技术人员不得不花费更多的时间和精力在沟通和理解业务需求上； (4) 公司的经营策略和业务规则可能需要专门的业务人员进行集中管理、并且 不断积累，传统的信息系统把经营策略和业务规则分散地固化在信息系统的不 同角落，根本无法集中管理； (5) 公司复杂的业务规则可能需要一个简单而强大的规则系统进行描述和管理， 工程硕士学位论文 第一章 绪论 2 业务规则的执行需要有迹可寻，正确性必须有保证，以免给公司造成经营上的 损失。 为解决上述与业务规则相关的种种困难，人们借鉴人工智能（Artificial Intelligence）的理论和技术发展了规则引擎（Rule Engine） 。 1.2 国内外研究现状 1.2.1 规则引擎的研究现状 规则引擎（Rule Engine）1这个词虽然二十多年前就已经出现了，但直到 现在它都不是一个非常明确的概念，我们很难明确地定义一个规则引擎应该具 有哪些功能，应该以什么样的方式工作。2004 年 8 月定稿的 JSR 94 规范定义 了一个基于 JAVA 的规则引擎系统应该具有哪些功能和什么样的对外接口2，这 可能是当今对规则引擎最清晰的规范性定义了。但一方面它仅是 JAVA 社区进程 （JCP）对基于 JAVA 的规则引擎所定义的规范，JCP 范围之外并不一定认可这 种规范；另一方面，JSR 94 对规则引擎仅定义了一个最基本的规范，可以说相 当粗糙，它对于规则引擎的具体实现方法、工作方式、应该达到的性能标准等 均没有明确定义；它甚至没有定义一个通用的规则描述语言。目前常见的商业 或开源规则引擎系统的功能则大大超出了 JSR 94 所定义的功能，但不同的规则 引擎的实现方式、对外接口、规则描述方法、开发方法等均不相同。 从广义上说，任意一个能够将规则作用于数据之上并能产生结果的系统都 可以称为规则引擎3。大到具有复杂推理功能的专家系统（Expert System） ， 小到简单的表单验证系统、动态表达式求值引擎、工作流引擎等都可称为规则 引擎。 人们普遍认为规则引擎起源于基于规则的专家系统（Rule Based Expert System 简称 RBES）4，从目前常见的规则引擎系统的功能和结构看，它们与 RBES 基本上都是相似的。下面是 RBES 的系统结构示意图5： 图 1.1 RBES 结构图 其中规则库（Rule Base 也叫知识库 Knowledge Base） 、事实库（Fact Base 也叫工作内存 Working Memory）和推理引擎（Inference Engine）是 RBES 的核心部分。而推理引擎又由模式匹配器（Pattern Matcher） 、议程 （Agenda）和执行引擎（Execution Engine）组成，其结构示意图如下6： 图 1.2 推理引擎结构图 工程硕士学位论文 第一章 绪论 3 系统工作时，模式匹配器根据规则库对事实库内的所有事实进行模式匹配， 从而决定哪些规则将被执行的；议程管理模式匹配器挑选出来的规则，决定它 们的执行次序；执行引擎则负责规则的执行。 1.2.2 推理过程研究状况 本文讨论的规则引擎 Drools 就是一个基于规则的类似于专家系统的规则引 擎，更准确地说 Drools 是一个产生式规则系统，它用产生式来表示规则7。产 生式的基本形式是： PQ 或者 IF P THEN Q （公式 1.1） 其中 P 是产生式的前提，也称为前件或条件，由事实（fact）的逻辑组合构成， 它给出了产生式可否使用的先决条件；Q 是一组结论或操作，也称为产生式的 后件或动作，它指出当前提 P 满足时，应该推出的结论或应该执行的动作。公 式 1.1 的含义是：如果前提 P 满足，则可推出结论 Q 或执行 Q 所规定的操作。 因为产生式表示格式固定，形式简单，规则间相互较为独立，没有直接关 系，这使规则库的建立较为容易。另一方面，基于产生式的规则系统推理方式 单纯，没有复杂计算，系统的推理路径容易解释；规则库与推理机是分离的， 这种结构给规则的修改带来了方便，因为它不涉及程序的修改。所以，产生式 或其变形常用作规则系统的规则表示方法。 如图 1.2 所示，Drools 的推理引擎也具有相同的系统结构，它能够处理形 如公式 1.1 这样的规则，这个处理过程即是推理过程。具体来说就是（以正向 推理为例） ，针对事实库中任意的事实 Fi,模式匹配器试着用它匹配条件 P，如 果匹配成功，则将 Fi 添加到议程中，并由议程给它所对应的动作 Qi 分配一个 执行优先级，把 Qi 放入待执行序列；如果匹配失败，则不处理 Fi。当事实库 中所有的事实均被处理完毕后，执行引擎按优先级从高到低的顺序依次执行议 程排定的动作序列。 基于产生式的规则系统一般能执行三类推理：正向推理、逆向推理和双向 推理。所谓正向推理是指从已知事实出发，通过规则库求得结论，可称为数据 驱动方式。所谓反向推理是指从目标（作为假设）出发，反向使用规则，求得 已知事实，可称为目标驱动方式。双向推理是指同时使用正向推理和反向推理。 Drools 目前只支持正向推理。 推理引擎是规则引擎的核心，正如图 1.2 所示，推理引擎由模式匹配器、 议程和执行引擎构成，其中模式匹配器所用的匹配算法是影响系统性能的关键 部分，因为规则引擎需要应用在具有大量规则和事实的业务系统或者需要频繁 工程硕士学位论文 第一章 绪论 4 调用的场合，所以它的性能显得特别重要。正因如此，所以目前大多数的理论 研究都集中在如何改进模式匹配的算法上。目前已经实现的规则引擎系统大多 使用了 RETE 算法和 LEAPS 算法，这也是目前最成熟、性能最好的两种算法。一 些商业性规则系统宣称实现了 RETE II 或 RETE III 之类的算法，这些估计都是 RETE 算法的改进版，笔者并没有见到过任何公开发表的、公认的 RETE III 之 类算法介绍。另外还有一些不太常见的匹配算法，如 LINEAR 算法、TREAT 算法 等也可以作为规则引擎模式匹配算法。 在规则引擎标准化领域，目前只有 JCP 制定过 JSR 94 规范。这是一个比较 简单的规范，目前已经有 Drools、Hammurapi Rules、ILOG JRules（注：2009 年 1 月 ILOG 被 IBM 收购） 、Jess、JLisa 等规则系统实现了该规范。 目前业界比较有影响的规则引擎产品主要有 ILOG JRules、Jess、Drools 等，其中 Drools 为著名开放源代码组织 JBOSS 的开源规则引擎产品。Drools 使用 Apache License 2.0 许可协议8。这是一种宽松的、对商业应用友好的许 可协议，使用者可以在需要时修改 Drools 源代码来满足自己的需要，修改后的 产品可作为开源或商业产品自由发布或销售。当前，规则引擎产品在实际业务 中已经有了一些成功的应用案例，特别是在金融、保险和电信业，例如光大银 行和太平人寿保险就使用了 ILOG 公司的 JRules 规则系统9。 规则引擎主要应用在那些存在大量业务规则、业务规则经常发生变化、或 者需要集中管理业务规则的地方,它也可以作为一个内嵌的引擎用于需要动态进 行决策的软件系统中。例如，用于可配置的系统框架、用于需要动态配置的工 作流系统、用于需要经常调整决策的业务系统等等。 规则引擎具有强大的动态管理业务逻辑的能力，能够很好地应用于前面所 述的各种场合。但规则引擎也有它自身的缺点，在决定一个软件系统中是否使 用规则引擎时我们应该衡量各方面的利弊再做决定。一方面，规则引擎是一个 复杂的软件系统，在熟练地使用它之前需要一定的学习成本；一旦使用了规则 引擎就必须按它特有的方式来配置和管理规则。另一方面，在某些场合不使用 规则引擎就可以轻易实现需求；或者某些场合规则引擎可能难以满足实际需求。 即使在规则引擎能够胜任的场合，也可能存在其它可替代规则引擎的技术。下 面就是两种传统上最常见的用来替代规则引擎的技术： 1）借助元数据或数据库来描述规则的系统。如果规则能够清晰方便地使用 配置系统或数据库来描述，那么通过精心的设计，完全可以通过配置系统或数 据库的修改来影响系统的行为，达到与使用规则引擎相同的效果。这类系统的 缺点是：它只能在一个相对固定的范围内很好地工作，超出这个范围，它很可 能就会失控或者无能为力。 工程硕士学位论文 第一章 绪论 5 2）使用脚本技术。脚本语言的动态性是众所周知的，从某个角度来说，脚 本引擎的动态能力甚至远超规则引擎，所以在很多场合，我们完全可以通过预 留接口调用脚本引擎来实现需求。脚本技术的缺点是性能低下、规则分散，并 且非专业技术人员很难维护。 1.3 论文研究内容及组织结构 1.3.1 论文的研究内容 传统的 ERP 系统在应对复杂的业务逻辑、业务逻辑经常变化以及降低系统 维护成本等问题时，几乎无一例外地依靠如数据库系统、文件配置系统和脚本 技术。但随着规则引擎技术的日益成熟，其巨大的优势便逐渐显露出来。本文 重点研究如何在 ERP 系统中应用规则引擎技术，以应对复杂业务逻辑，提高系 统的动态可修改性，并降低系统维护的成本。具体研究内容如下： 1、规则引擎的工作原理 2、Drools 规则引擎的开发技术 3、基于规则引擎的需求分析、系统设计思想 4、Drools 规则引擎在 ERP 系统中的应用场景 5、Drools 规则引擎的性能问题 6、如何低成本地维护经常变化的业务规则库 1.3.2 论文的组织结构 本文共分 6 章来讨论 Drools 规则引擎在 ERP 系统中的应用。 第一章为绪论；第 2 至 5 章为本文研究内容；第 6 章为总结与展望。各章 的主要内容如下： 第二章 介绍什么是规则引擎、规则引擎的发展现状及常见应用场景；本 文的研究内容及文章的组织结构。 第三章 介绍开源规则引擎系统 Drools 的工作原理及目前大多数规则引擎 所使用的模式匹配算法RETE 算法及 LEAPS 算法。讨论 Drools 规则引擎系 统的开发环境、规则的表征以及如何使用 Drools 进行开发、测试及部署。讨论 如何在 ERP 基础框架中使用 Drools 规则引擎、讨论了数据校验、数据联动、信 息交换、工作流等各种常见场景下规则引擎的应用方法、可能产生的问题及解 决办法。 第四章 讨论如何在实际的 ERP 业务中使用 Drools 规则引擎、讨论在典型 的财务和业务应用场景中使用 Drools、使用过程中可能产生的问题及解决办法。 工程硕士学位论文 第一章 绪论 6 第五章 总结全文、指出本文的独到之处、展望未来的研究方向。 工程硕士学位论文 第二章 相关理论基础 7 第二章 相关理论基础 本章介绍 Drools 规则引擎的工作原理。绝大多数开源或商业规则引擎的工 作原理与 Drools 规则引擎的工作原理大同小异，所以这里介绍的规则引擎工作 原理也同样适用于其它规则引擎。 2.1 Drools 规则引擎的基本概念 Drools 早先是一个由 Bob McWhirter 开发的开源项目10，后来被著名的开源 组织 JBOSS 接管，并逐渐成为当今最具影响力的开源规则引擎。在笔者写作本 文时 Drools 的最新版本是 5.0，但从 Drools 3.0 开始它就是一个非常受欢迎 的开源规则引擎，目前界业还有不少遗留系统使用的是 Drools 3.0 或 4.0 版本。 Drools 5.0 版是在 4.0 版的基本上发展起来的，它在规则描述、系统概念、开 发接口、多线程规则匹配、规则流等方面进行了较大的改进甚至重新设计11。 本文以 Drools 5.0 为蓝本，文中所提到的概念、所讨论的开发、测试、部署方 法等均以 Drools 5.0 为准。 2.1.1 Drools 规则系统 完整的 Drools 规则系统被分成了四大组成部分，它们是：Drools Guvnor (BRMS/BPMS)、Drools Expert (rule engine)、Drools Flow (process/workflow)和 Drools Fusion (event processing/temporal reasoning)。其中 Drools Guvnor 是一个规则管理系统（Business Rule Management System 简称 BRMS） ，它的主要部分是一个基于 WEB 的可以用来管理 规则库的应用程序。Drools Expert 就是狭义上的“规则引擎” ，它是一个独立 的、可以嵌入到应用系统中使用的规则引擎。Drools Flow 是一个工作流系统。 Drools Fusion 用于在规则系统中支持复杂事件处理（Complex Event Processing 简称 CEP）以及时序推理12。此外，Drools 还附带有相应的系统开 发集成环境，包括一整套的开发、测试、部署工具。本文主要关注 Drools Expert 系统的开发以及它在 ERP 系统中的应用。一个使用了规则管理技术的信 息系统的体系结构如图 2.1 所示： 图 2.1 规则管理系统架构 在上述的图中，规则引擎被嵌入到商业应用系统中，IT 技术人员通过系统 集成环境（IDE）来创建和管理业务规则；而业务人员通过专有的规则管理程序 工程硕士学位论文 第二章 相关理论基础 8 来管理业务规则，不需要技术人员的干预；企业的业务规则库被独立出来集中 管理。 2.1.2 Drools 规则系统 上一节我们提到，规则引擎起源于基于规则的专家系统（RBES） ，并且介绍 过 RBES 的系统结构图，Drools 规则引擎的系统构架与 RBES 的系统架构有很大 的相似性。下面是一幅来自 JBoss 官方文档记载的 Drools 系统结构图13： 图 2.2 Drools 系统结构图 如图 2.2 所示，Drools 把规则（rule）保存在规则库（Production Memory）中，推理机要匹配的事实（fact）保存在工作内存（Working Memory）中。开始工作时，Drools 首先把所有规则读入 Production Memory， 再把事实插入到 Working Memory，然后系统开始进行匹配工作，一个有大量规 则和事实的系统可能会有很多条规则被成功匹配，此时这些规则被称为具有冲 突性。议程（Agenda）使用冲突解决策略来管理这些有冲突的规则的执行顺序。 以正向推理为例，下图描述了整个推理的过程： 图 2.3 Drools 的正向推理过程 2. 2 RETE 算法 如图 2.2 所示，Drools 的推理引擎使用的模式匹配算法14是 ReteOO 和 Leaps，所谓 ReteOO 算法其实是对 Rete 算法的一种改进，Drools 为面向对象 系统（Object Oriented System）增强并优化了 Rete 算法15。模式匹配算法 是影响规则引擎性能的关键部分，本节讨论 Drools 所实现的 Rete 算法，下节 将介绍 Leaps 算法。 2.2.1 RETE 算法 1) RETE 算法介绍 Rete（拉丁语“网络”的意思）算法最早在 1979 年由美国卡耐基梅隆大 学的 Charles L. Forgy 在他的博士论文中发表16，1982 年曾公开发表过 Rete 算法的一个简化版。它至今仍被认为是效率最高的正向推理算法之一。其核心 思想是根据内容动态构造匹配树，在匹配的过程中大量使用记忆和共享，以避 免不必要的重复计算，达到显著降低计算量的目的。 工程硕士学位论文 第二章 相关理论基础 9 Rete 算法可以分为规则编译和运行时执行两部分。规则的编译描述了如何 在规则工作空间中产生一个有效的辨别网络，方法是在匹配网络的传递过程中 过滤数据。在匹配网络中，数据从根节点进入网络，此时根节点会有很多匹配 的数据。当顺着网络往下走，通过层层过滤，离根节点越远的节点，其匹配的 数据也就越少，网络的最底部是终止节点。 在 Forgy 博士 1982 年的论文17中描述了 4 种最基本的节点：根节点、1- input 节点、2-input 节点和终止节点。另外，在匹配过程中还会出现其它的节 点，如对象类型节点、求值节点和左输入适配器节点等，如图 2.4 所示。 图 2.4 Rete 算法的节点类型 ReteNode 根节点，所有对象由此节点进入匹配网络。 ObjectTypeNode 对象类型节点，通常是最初级的过滤节点，只有类型与规 则相匹配的对象才能通过此节点的过滤。如图 2.5 所示,经过 ObjectTypeNode 节点的过滤后，符合规则的对象将被传递到后续节点。后续节点可能是 AlphaNode、LeftInputAdapterNode 或 BetaNode 等（这些类型的节点的介绍见 后文） 。 图 2.5 对象类型节点 1-input 节点，即 AlphaNode，AlphaNode 用来对字符串进行求值。在 Forgy 博士的论文中只提到了等式操作，但许多 Rete 算法的实现还支持其它操 作。当规则中一个对象类型有多个字符串等式匹配时，它们会链接在一起。图 2.6 显示了 AlphaNode 节点针对 Cheese 对象的链接情况，假定规则为： Cheese( name = cheddar, strength = strong ) 图 2.6 Alpha 节点 2-input 节点即 BetaNode，BetaNode 有两种:JoinNode（连接节点）和 NotNode（非节点） 。连结节点用来对两个对象进行对比。这两个对象可以是同 种类型，也可以是不同类型。为方便起见，约定 BetaNode 的两个输入分别称为 左输入和右输入。一个 BetaNode 的左输入通常是一个对象的列表，在 Drools 中称之为元组（Tuple） 。右输入通常是一个单体对象。左输入与右输入之间可 以用非节点（NotNode）来进行“exist”检查。图 2.7 示例了 JoinNode 在匹配 网络中的用法。 图 2.7 连接节点的用法 工程硕士学位论文 第二章 相关理论基础 10 NotNode（非节点）可用来进行“exist”检查，即它可用来检查是否存在 满足条件的输入对象。 LeftInputNodeAdapter（左输入适配器节点）可用来将一个单体对象转换 成一个单体对象的元组，从而使单体