（计算机应用技术专业论文）规则引擎在业务逻辑层中应用的研究.pdf

中文摘要 摘要 大多数网络及企业级j a v a 应用可以分为三部分：表现层，数据持久层和这两 部分之间的业务逻辑层。通常使用某种框架( 表现层常用的框架有s t r u t s 和j s f 等，持久层常用的框架有h i b e r n a t e 和实体b e a n s 等) 来部署应用。这意味着程 序开发人员可以避免许多让人厌烦的细节，而把主要精力集中在业务逻辑层的实 现上。但到目前为止，对于业务逻辑层却没有一个标准的构建方法。 规则引擎是推理引擎的一种，它起源于基于规则的专家系统。基于规则的专 家系统主要是模仿人类的推理方式，使用试探性的方法进行推理，并试用人类能 理解的术语解释和证明它的推理结论。使用推理引擎能够将业务决策从应用程序 代码中分离出来，接受数据输入，解释业务规则，并根据规则做出业务决策。 本文通过对规则引擎的工作原理及其核心r e t e 算法的研究，而得到规则 引擎的推理过程，并利用规则引擎构建业务逻辑层，从而给出一个较好的业务逻 辑层构建方案。 另外，通过一个实际的订单系统来探讨如何将规则引擎框架运用到企业级 j a v a 应用的业务逻辑层中去。该系统采用s t r u t s q - d r o o l s - k h i b e r n a t e 的架构， 并且在构建该系统时，采用两种方式分别实现该系统的业务逻辑层，一种方式利 用规则引擎，另外种方式不利用规则引擎。最后，对采用这两种方式实现的系统 性能进行了测试，并对测试结果进行了分析与比较，从采用两种方式的开发难易 度和维护难易度等方面，总结出规则引擎框架的优势及缺陷，从而得出在开发系 统时何时该使用规则引擎，何时不需要用规则引擎。 关键词：规则引擎；w e b 架构；业务逻辑 茎兰塑茎 t h er e s e a r c ho f a p p l i c a t i o nu s i n gr u l ee n g i n ei nb u s i n e s sl o g i c l a y e r a b s t r a c t m o s te n t e r p r i s ej a v aa p p l i c a t i o nc a nb ed i v i d e di n t ot h r e el a y e r s ：v i e wl a y e r , p e r s i s t e n c el a y e r ( d a t a b a s e ) a n db u s i n e s sl o g i cl a y e rb e t w e e nt h o s et w ol a y e r s u s u a l l yw eu s ef r a m e w o r k ( v i e wl a y e rl i k e ss t r u t s ，s p r i n ga n ds oo n , p e r s i s t e n c e l a y e rl i k e sh i b e r n a t e 鹤w e l la se n t i t yb e a n se r e ，1 t od e p l o yt h ea p p l i c a t i o n , t h i s m e a n sy o uc a l li g n o r em a n yb o t h e r s o m ed e t a i l s ，a n df o c u so nb u s i n e s sl o g i c s b u ts o f a r , t h e r ei sn os u c hc r i t e r i o no nh o w t ob u i l dl o g i cl a y e r r u l ee n g i n ei sak i n do fi n f e r e n c ee n g i n e , i tc a l lt r a c eb a c kt or u l e - b a s e de x p e r t s y s t e m r u l e - b a s e de x p e r ts y s t e mi m i t a t e sh u m a n i t y si n f e r e n c ew a y , l l s e se x p l o r a t o r y m e t h o dc a l t i e so ni n f e r e n c e , a l s ou s e st e r m i n o l o g yw h i c hh u m a n i t yc a nu n d e r s t a n dt o e x p l a i na n dt op r o v ei t si n f e r e n c ec o n c l u s i o n u s i n gt h i sk i n do fi n f e r e n c ee n g i n ec a n s e p a r a t eb u s i n e s sm l e sf r o mt h ea p p l i c a t i o nc o d e s ，a c c e p tt h ed a t ai n p u t s ，c x p l a i l ut h e b u s i n e s sr u l e s ，a n dm a k ed e c i s i o n sa c c o r d i n gt ot h er u l e s v i at h er e s e a r c ho f r u l ee n g i n e sp r i n c i p l ea n di t sc o r em o d u l e r e t ea l g o r i t h m ，t h i s p a p e rr e v e a l sr u l ee n g i n e si n f e r e n c ev o c e s s ，u s e sr u l ee n g i n et ob u i l dt h eb u s i n e s s l a y e ra n dp r o p o s e sa b e t t e rs o l u t i o no nh o wt ob u i l dt h eb u s i n e s sl a y e r m o n 刖e f t h r o u g ha na c t u a ls m a l lo r d e rf o r ms y s t e mu t i l i z e st h er u l ee n g i n e f r a m e w o r kt of i n dh o wt ou s er u l ee n g i n ef r a m e w o r ki nt h eb u s i n e s sl o g i cl a y e ro f e n t e r p r i s ej a v aa p p l i c a t i o n s t h i so r d e rf o r ms y s t e mu s e $ s t r u t s + d r o o l s + h i b e r n a t ef r a m e w o r ka n du s e st w ow a y st oi m p l e m e n tt h eb u s i n e s sl o g i cl a y e r , o n e u s et h er u l ee n g i n ef r a m e w o r ka n dt h eo t h e ro n ed o e sn o t f i n a l l y , c o m p a r e st h e s et w o i m p l e m e n t a t i o n sw i t ht h ep e r f o r m a n c et e s ta n dt e s tr e s u l t 勰w e l la so t h e rc o m p a r i s o n s u c h 雏d e v e l o p m t n td i f f i c u l t yc o m p a r i s o na n dm a i n t e n a n c ed i f f i c u l t yc o m p a r i s o ne t c 。 a n ds u m m a r i z e st h es u p e r i o r i t ya n dt h ef l a wo fr u l ee n g i n ef r a m e w o r k , a l s ow h e n s h o u l du s er u l ee n g i n e 丘a m e w o r ka n dw h e ns h o u l dn o t k e yw o r 山= r u l ee n # n e ；w e ba r c h i t e c t u r e ；b u s i n e s sl o g i c 大连海事大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：本论文是在导师的指导下，独立进行研究工作所取得的成果，撰写成硕士 学位论文：拯则i 【墼在些釜逻整星虫廛盈的硒宜：。除论文中已经注明引用的内容外，对论文 的研究做出重要贡献的个人和集体，均己在文中以明确方式标明。本论文中不包含任何未加 明确注明的其他个人或集体已经公开发表或未公开发表的成果。 本声明的法律责任由本人承担。 论文作者签名：专7 胁o 侔1 月节日 学位论文版权使用授权书 本学位论文作者及指导教师完全了解“大连海事大学研究生学位论文提交、版权使用管 理办法”，同意大连海事大学保留并向国家有关部门或机构送交学位论文的复印件和电子版， 允许论文被查阅和借阅。本人授权大连海事大学可以将本学位论文的全部或部分内容编入有 关数据库进行检索，也可采用影印、缩印或扫描等复制手段保存和汇编学位论文。 本学位论文属于： 保密口 ， 不保密臼( 请在以上方框内打“”) 论文作者虢懈导：乞于刎 日期：o 矾 年弓月御 规则引擎在业务逻辑层中应用的研究 第1 章绪论 1 1 w e b 架构应用现状 在现今w e b 系统架构中，大多数企业级应用系统一般均采用w e bb r o w s e r w e b s e r v e r d a t as e r v e r 的b s d 三层w e b 架构【。企业级j a v a 应用也相应的分为三 层：表现层、数据持久层和业务逻辑层。通常使用框架来开发和部署企业级应用， 表现层常用的框架有s t r u t s ，j s f ，s p r i n g 等，持久层常用的框架有h i b e r n a t e ， e j b 等。 一个好的应用框架可以避免许多让人厌烦的细节，而将主要精力集中到关键 的业务逻辑层上。同时，业务逻辑层中往往是大量的随外部条件不断变化的业务 规则。但到目前为止，对于业务逻辑层却没有一个标准的构建方法。像e j b 和s p r i n g 只能在高端实现业务逻辑的构建，但却不能组织代码。因此，商业决策者和应用 开发者就非常迫切的需要将商业决策逻辑和技术决策分离出来，并把这些商业决 策放在中心数据库或其它统一的地方。这样，我们就可以在运行时动态地管理和 修改业务规则，并且使用在可配置性、可读性和重用性等方面能够带给我们极大 利益的框架来代替那些繁杂的条件判断语句，从而可提高系统的柔韧性和适应性。 1 2 规则引擎的产生背景 企业管理者对企业级i t 系统的开发有着如下的要求：尽管现代商业规则异常 复杂，但为提高效率，管理流程必须自动化；市场要求业务规则经常变化，i t 系 统必须依据业务规则的变化快速、低成本的更新；为了快速、低成本的更新，业 务人员应能直接管理i t 系统中的规则，而不需要程序开发人员的参与。这种情况 下，项目开发人员就会碰到以下问题：有些复杂的商业规则很难推导出算法和抽 象出数据模型；软件工程要求从需求一 设计一 编码，然而业务规则常常在需求阶 段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码 中；对程序员来说，系统维护、更新困难，更不可能让业务人员来管理。 基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎是推理 引擎的一种，它起源于基于规则的专家系统( 基于规则的专家系统模仿人类的推 理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的 第1 章绪论 推理结论) 。它能够将业务决策从应用程序代码中分离出来，接受数据输入，解 释业务规则，并根据规则做出业务决策。 1 3 规则引擎的发展及其在业务逻辑层的应用现状 随着商业以及市场的迅猛发展，业务逻辑的变化频率已经从以前的平均1 8 个 月下降到平均6 个月甚至更短的时间了，这就意味着企业级应用的更新和升级变 得越来越频繁。同时又由于业务逻辑层没有什么标准的框架和统一的开发方式， 使得系统升级变得很昂贵，又很麻烦。这就迫切需要一个框架或统一的方法来开 发业务逻辑层。很多的系统架构师已经注意到了这一点并且正在进一步的研究与 探讨。 源自于专家系统的规则引擎是一个重要的尝试。规则引擎的核心内容是它所 采用的匹配算法，至于规则引擎的原理将在第二章2 1 小节进行详细的阐述。早 期的匹配算法主要是索引计数匹配法。这种方法的匹配效率并不是很高，所以应 用并不广泛。在索引计数匹配算法的基础上，f o r g e 于1 9 7 9 年提出了r e t e 算法。 r e t e 算法牺牲了一部分空间来提高算法的效率，使得该算法有了广泛的应用空间。 目前，几乎所有成熟的规则引擎框架的实现都是基于该算法的。但是基于这些框 架的企业级应用却并不多，原因是这些框架有着自己的实现方式，有着自己的规 则定义语言。并且，绝大多数规则引擎框架都是商业产品，价格都非常昂贵。这 种情况直到j s r 9 4 规则引擎标准和开源规则引擎的出现才逐渐好转。 目前，满足j s r 9 4 标准并且比较成熟的规则引擎框架主要有：j r u l e s 、j e s s 和d r o o l s 等。其中j r u l e s 是i l o g 公司的一个商业产品，价格很高；j e s s 是由美 国s a n d i a 国家实验室分布式系统计算组成员e r n e s tj f r i e d m a n - h i l l 在1 9 9 5 年以应用广泛的c l i p s 专家系统外壳为基础开发出来的，它所采用的规则描述语 言是类c l i p s 的描述语言，比较难懂，而且它也是一个商业产品；d r o o l s 是一个 开源并且免费的框架，它采用x m l 或d s l 规则描述语言来描述业务逻辑，这是它 的优点，但它是最近才逐渐成熟起来的一个框架，还需要进一步的完善。因此， 企业级应用中很少采用这个框架。 基于以上原因，目前采用规则引擎来构建业务逻辑层的应用还不多，成功的 案例也非常少。 规则引擎在业务逻辑层中应用的研究 1 4 本课题研究的目的与意义 通过前面几节的介绍，我们可以看到目前的业务逻辑层很少采用框架结构， 基本上还处于无标准的自由开发阶段。无论是系统的设计、开发或维护都将花费 相当大的代价。因此，本文正是想通过对规则引擎的研究，提出一个适用于业务 逻辑层的开发标准以降低开发时花费的巨大代价。同时，通过对规则引擎匹配算 法的研究，针对其匹配算法的优缺点，提出更好的解决方案。 其次，由于目前规则引擎所使用的匹配算法还具有一定的局限性，这就使得 规则引擎的应用也具有一定的局限性。因此，本文也将研究什么样的应用适合采 用规则引擎，什么样的应用不适合采用规则引擎。通过对这个局限性的研究，也 可以为我们在今后的研究工作中如何突破这个局限性提供了一定的基础。 另外，规则引擎不仅可以应用于w e b 架构的业务逻辑层中，它还可以应用于 入侵检测、专家系统和人工智能推理等推理系统中。通过对规则引擎在业务逻辑 层中应用的研究，也可以对规则引擎在其它领域的应用研究起到一定的借鉴作用。 1 5 本文的内容组织 本文共分六章，第一章为绪论，第六章为总结与展望，第- - n 第五章为本文 的研究内容，具体安排如下： 第一章绪论：介绍了w e b 架构及规则引擎应用的现状，并阐述本文的研究背 景；另一方面，介绍了本文的研究目的与意义，以及本文的结构。 第二章规则引擎的研究：阿述规则引擎的原理，以及j a v a 规则引擎a p i ，并 介绍基于j a v a 规则引擎a p i 的d r o o l s 规则引擎框架。 第三章规则引擎的算法研究：对规则引擎中的r e t e 匹配算法进行详细的分析 和研究。 第四章订单系统设计与实现：利用规则引擎框架设计并实现一个订单系统。 第五章系统测试与结果：对第四章实现的订单系统进行系统测试，并结合该 系统测试的结果分析和规则变更对系统的影响分析等一系列分析，总结出应用规 则引擎框架的优势，并得出规则引擎框架的适用范围。 第六章总结与展望：总结本文研究成果，并指出今后的工作方向。 第2 章规则引擎的研究 第2 章规则引擎的研究 2 1 规则引擎的原理 规则引擎是基于规则的专家系统的一部分。为了更深入的了解j a v a 规则引 擎，下面简要地介绍一下基于规则的专家系统( r b e s ) 。 2 1 1 基于规则的专家系统( r b e s ) 简介 j a v a 规则引擎起源于基于规则的专家系统( r u l e - b a s e de x p e r ts y s t e m ) 【2 】， 基于规则的专家系统又是专家系统的一个分支。专家系统属于人工智能的范畴， 它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语 解释和证明它的推理结论。下面便简要地介绍基于规则的专家系统。 基于规则的专家系统包括三部分：规则库( 知识库) 、工作记忆( 事实库) 和推理引擎。它们的结构如图2 1 所示。 图2 1 基于规则的专家系统构成 其中【5 1 ： 规则库是中心数据库，存储各类模拟人类问题求解的产生式规则。一个规则 可以分为两部分：前件部分和后件部分。前件( a n t e c e d e n t ) 又称条件部分、模式 部分或左部( l e f t h a n d s i d e ，l h s ) ，是规则触发的条件。单独的条件称为条件元 素或一个模式；后件( c o n s e q u e n t ) 又称右部( r i g h t h a n d s i d e ，r h s ) ，是规则触 发时将要执行的一系列行为。 工作记忆是应用于规则事实的全局数据库，它保存系统的当前状态。 规则引擎在业务逻辑层中应用的研究 推理引擎通过决定哪些规则满足事实或目标，而授予规则优先级，并将满足 事实或目标的规则加入议程。如图2 1 所示，推理引擎包括三部分：模式匹配器、 议程和执行引擎。模式匹配器通过比较事实和规则的模式部分，决定选择执行哪 个规则，何时执行规则。它是基于规则的推理机的关键，并决定了推理机的推理 效率；议程是由推理机创建的一个规则优先级表，这些规则都匹配工作记忆中的 事实。如果同时有多个规则和事实匹配，则优先级最高的先被触发。被触发规则 的动作可能会产生新的事实，这些新的事实也会被加入工作记忆；执行引擎：负 责执行议程中的规则和其他动作。 和人类的思维相对应，推理引擎存在两种推理方式： 1 演绎法( 前向链推理方法) 。演绎法是从事实到结论的推理。这种方法从 一个初始的事实出发，不断地应用规则进行推理( 或执行指定的动作) ，最后到 达一个终止状态( 结论) 。其推理过程如图2 2 所示。 图2 2 演绎法( 前向链推理方法) 2 归纳法( 后向链推理方法) 。归纳法是从假设( 即要证明的结论) 到事实 的推理。这种方法是根据假设，不断地寻找符合假设的事实。其推理过程如图2 3 所示。 第2 章规则引擎的研究 图2 3 归纳法( 后向链推理方法) r e t e 算法是目前效率最高的一个前向链推理算法，许多j a v a 规则引擎都是基 于r e t e 算法来进行推理计算的。 推理引擎的推理步骤如下： 1 ) 将初始事实输入工作记忆。 规则引擎在业务逻辑层中应用的研究 2 ) 使用模式匹配器比较规则库中的规则和事实。 3 ) 如果执行的规则存在冲突，即同时激活了多个规则，将冲突的规则放入冲 突集合。 4 ) 解决冲突，将激活的规则按顺序放入议程。 5 ) 使用执行引擎执行议程中的规则。重复步骤( 2 ) 至( 5 ) ，直到执行完毕所有 议程中的规则。 2 1 2 规则引擎的原理 1 规则引擎相关构件 2 - 4 1 规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时的 实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念， 为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍： 1 ) 信息元 信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对 象。 2 ) 信息服务 信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对 象。即特定的信息服务根据信息元所产生的信息元对象有相同的格式，但可以有 不同的属性和规则集。 3 ) 规则集 规则集是规则的集合。每条规则包含一个条件过滤器和多个动作。一个条件 过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结 果仍然是布尔类型的。在程序运行时，动作将会在条件过滤器值为真的情况下执 行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作、 包含动作和使信息元对象内容持久化的动作。 4 ) 队列管理器 队列管理器用来管理来自不同信息服务的信息元对象的队列。 下面将研究规则引擎的这些相关构件是如何协同工作的。 第2 章规则引擎的研究 如图2 4 所示，规则引擎的处理过程分为三个阶段进行：首先，信息服务接 受事件并将其转化为信息元；其次，这些信息元被传递给队列管理器；最后，规 则引擎接收这些信息元，并应用规则集携带的规则进行推理，直到队列管理器中 不再有信息元。 图2 4 规则引擎相关构件处理过程协作图 2 规则引擎的工作机制 本节专门研究规则引擎的内部处理过程。如图2 5 所示，规则引擎从队列管 理器中依次接收信息元，然后根据规则的定义顺序检查信息元所带的规则。如图 所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此 规则相关的动作皆被忽略并继续检查下一个规则。如果第二个规则的条件过滤器 值为真，所有与此规则相关的动作都按照定义的顺序执行。执行完毕后继续下一 个规则。该信息元中的所有规则执行完毕后，信息元将被销毁，然后从队列管理 器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作和包含动 作。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁 所在信息元，规则引擎将会接收队列管理器中的下一个信息元。包含动作其实就 规则引擎在业务逻辑层中应用的研究 是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并 进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。 这一过程将递归进行。 图2 5 规则引擎工作机制 以上所述就是规则引擎的原始架构，j a v a 规则引擎就是从这一原始架构演变 而来的。 j a v a 规则引擎的工作机制与上述规则引擎的原始架构十分类似，只不过对上 述概念进行了重新包装和组合。 j a v a 规则引擎对提交给引擎的j a v a 数据对象进行检索，根据这些对象的当前 属性值和它们之间的关系，从加载到引擎的规则集中寻找符合条件的规则，并创 建这些规则的执行实例。这些实例将在引擎接到执行指令时，按照定义好的优先 值顺序执行。 j a v a 规则引擎的结构示意图如图2 6 所示。 第2 章规则引擎的研究 图2 6j a v a 规则引擎工作机制 一般来讲，j a v a 规则引擎由下面几个部分构成：工作记忆( w o r k i n gm e m o r y ) 即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激 活的规则执行实例；静态规则区，用于存放所有被加载的业务规则，这些规则将 按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作 区中的对象现状，调整规则执行队列中的规则执行实例。 当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则。由于规则 的执行可能会改变工作区中的数据对象，从而会使队列中的某些规则执行实例因 为条件改变而失效，必须从队列中撤销。也可能会激活原来不满足条件的规则， 生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则执行链，形 成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。 2 1 3 规则引擎的知识表示 规则引擎采用产生式规则作为基本的知识表达方式。本文采用d r o o l s 的语法 结构，规则引擎的知识表示如下l “1 ： 1 产生式规则 产生式规则( 或简称规则) 是对商业知识的编码。产生式规则的一般形式如 程序清单2 1 所示，每一条规则都是由一系列的属性、一个l e f th a n ds i d e ( l h s ) 规则引擎在业务逻辑层中应用的研究 和一个r i g h th a n ds i d e ( r h s ) 组成的。 程序清单2 1 产生式规则的一般形式 每条规则的l h s 由条件元素和列组成。这样可以方便的用一阶逻辑或命题逻 辑进行表述。列通常用来表示对一个事实的域约束。 规则l h s 是由一个或多个条件组成。当所有的条件都满足并为真时，r h s 将被 执行。这很类似程序中的i f 语句。如程序清单2 2 所示。 程序清单2 2 类似i f 语句的l h s 和r h s 在规则的语义识别上，当且仅当l h s 被匹配时才能激发规则r h s 。规则可以 通过p a c k a g e ( 包) 关键字同一个命名空间相关联。一个包中声明了类引用、全局 变量、函数和规则等。 规则引擎实现了数据同逻辑的完全解耦。规则并不能被直接调用，因为它们 不是方法或函数。规则的激发是对工作记忆中数据变化的响应。同时，规则语言 又被声明成像j a v a 语言一样的强制性语言，它描述了“什么”而不是“如何”。 程序清单2 3 是一个产生式规则的实例。 第2 章规则引擎的研究 程序清单2 3 一个产生式规则的实例 2 一阶逻辑 规则是用一阶逻辑写成的。一阶逻辑( f i r s to r d e rl o g i c f o l ) 又称谓词 逻辑，它是命题逻辑的延伸。e m i ll e o np o s t 是第一个利用符号表示逻辑，并用 这些符号来开发基于推理系统的人。因此，他也证明了任何逻辑系统( 包括数学 系统) 都可以用这种方式来实现。 一个命题就是能够用“真”和“假”来表示的一个陈述句。如果一个语句可 以单独表达“真”，就称该语句为“闭合的语句”。从编程的角度上讲，就是说该 表达式中不包含任何变量。程序清单2 4 是一个“闭合的语句”的实例。 程序清单2 4 一个“闭合的语句”的实例 规则引擎在业务逻辑层中应用的研究 如果一个语句表达式包含一个或多个变量，则称该语句为“开放的语句”。我 们无法判断该语句是“真”还是“假”，直到我们能够确定变量的值是什么。例如： p e r s o n s e x 一m a l e ”，在s q l 语句中，我们可以简单地把查询的结果看作是返 回给用户的用来匹配查询条件的结果集，如程序清单2 5 所示。 程序清单2 5 查找男性的s o l 语句 对于任何一条返回给我们的数据，其结果都是性别为男性的人。图2 7 展示 了上面的s q l 语句和“p e o p l e ”表在推理引擎架构中是如何描述的。 图2 7 同简单推理引擎相似的s q l 在j a v a 中，一个简单的命题是由变量、运算符和数值组成的。“数值”通常 可以被理解成字面上说的数值，因此，一个命题也被称作一个域约束。命题还可 以进一步结合接续性或转折性的连接词，从逻辑学角度讲便是“( 逻辑与) ”和 “ii ( 逻辑或) ”。程序清单2 6 和2 7 分别是用一个接续性的连接词连结两个开 放性的命题和一个转折性的连接词连结两个规则的例子。 程序清单2 6 用一个接续性的连接词连接的两个开放性命题语句的例子 程序清单2 7 用一个转折性的连接词连接的两条规则的例子 第2 章规则引擎的研究 命题逻辑并不是“图灵完备”的，因为它没有表述数据结构的标准，所以只 能完成那些可以被定义的问题。但一阶逻辑用两种新的量词概念允许表达式定义 新的结构来扩展命题逻辑这两种量词为全称量词和存在量词。 全称量词用来检查某个个体应用到全体是否都是“真”。 存在量词用来检查某个个体是否存在，如程序清单2 8 所示。 程序清单2 8 返回不及格学生的规则 现假设有两个类s t u d e n t 和m o d u l e ，m o d u l e 表示每个学生该学期参加的 课程。学期末每个m o d u l e 都要有一个得分。如果某个学生有一个m o d u l e 的分数 低于四十分，就说该生这学期不及格。存在量词此时就可以和“分数低于四十” 这个开放性命题来检查是否存在一个m o d u l e 满足这个命题，并以此作为标准。如 程序清单2 9 所示。 程序清单2 9 类s t u d e n t 和类m o d u l e j a v a 是图灵完备”的，可以通过写代码等方式遍历数据结构并检查满足命 题的m o d u l e 是否存在。程序清单2 1 0 中的代码应该返回该学期不及格的学生。 规则引擎在业务逻辑层中应用的研究 程序清单2 1 0 返回不及格学生的j a v a 实现 由于早期的s q l 实现并不提供量词，所以并不是“图灵完备”的。然而现在 的s q l 引擎允许通过关键字“e x i s t s ”和“i n ”的结合使s q l 进行嵌套。程序清 单2 1 l 中的查询应该返回该学期不及格的学生的集合。 程序清单2 1 1 返回不及格学生的s o l 查询 2 2 j a v a 规则引擎a p i 过去大部分规则引擎的开发并没有规范化，不同厂商开发的规则引擎有其自 有的a p i 。这使得不同厂商开发的规则引擎之间的交互和集成不够灵活。转而使用 另外一种产品时往往意味需要重写应用程序逻辑和a p i 调用，花费代价较大。规 则引擎标准的缺乏成为令人关注的重要方面。 2 0 0 3 年1 1 月定稿并于2 0 0 4 年8 月最终发布的j s r 一9 4 标准使得j a v a 规则引 擎的实现得以标准化。该标准称为j a v a 规则引擎a p i 规范 5 - 7 1 。它为j a v a 平台访 问规则引擎定义了一些简单的a p i 。 j a v a 规则引擎a p i 在j a v a x r u l e s 包中定义，是访问规则引擎的标准企业级 a p i 。j a v a 规则引擎a p i 允许客户程序使用统一的方式和不同厂商的规则引擎产品 进行交互，就如同使用j d b c 编写独立于厂商访问不同的数据库产品一样。j a v a 规 则引擎a p i 提供了创建和管理规则集合的机制，在工作记忆中添加、删除和修改 对象的机制，以及初始化、重置和运行规则引擎的机制。 2 3 o r o o i s 规则引擎 2 3 1 d r o o i s 简介 d r o o l s 分为两个主要部分：构建和运行时【l l 】【9 1 两个过程。 构建的过程涉及到d r l 或x m l 规则文件的创建。规则文件被读入规则文件解 析器，并使用a n t l r3 语法进行解析。解析器对规则的语法进行正确性检查，然 后产生一种中间结构“d e s c r ”，d e s c r 用a s t 来描述规则。然后，a s t 被传到包生 成器，由包生成器来产生包对象。包生成器还承担着一些代码产生和编译的工作， 这些对于产生包对象都是必需的。包对象是一个可以配置的，可序列化的，由一 个或多个规则组成的对象。图2 8 阐明了上述过程。 运行时过程是指规则引擎在运行的时候，规则库( 规则库r u l e b a s e ，是 一个运行时组件，它包含了一个或多个包对象) 可以在任何时刻将一个包对象加 入或移出规则库对象。一个规则库对象可以在任意时刻实例化一个或多个工作记 忆对象，并在它的内部保持对这些工作记忆的弱引用。当应用程序中的对象被断 言( 这里采用了j a v a 的a s s e r t 的概念，是指对象是否满足规则的l h s 。如果满足 则将该对象利用j a v a 的a s s e r t 函数添加到工作记忆中，否则继续检查下面的对 象) 进工作记忆后，可能会导致一个或多个激活过程的产生，然后由议程负责安 排这些激活过程的执行。图2 9 说明了上述过程。 规则引擎在业务逻辑层中应用的研究 ，f 解析嚣 li 11 i 轴1 或d r l ( d e s c r ) i 规则文件 a s t 中间过程 i 、 r 包生成器 编译器 l 代码生成器 h 图2 8 构建组件图2 9 运行时组件 2 3 2 为何选择d r o o i s 现在，市面上出现了很多规则引擎产品，有商业版的，也有免费开源的。这 里介绍几个常见的规则引擎产品。 j e s s 可能是最成熟的j a v a 规则引擎，有很多好的工具( 包括e c l i p s e 插件) 和文档。然而它是一个商业产品，并且它的规则是用类c l i p s 的描述语言写的， 比较晦涩难懂，这对许多j a v a 编程者都是一个挑战。 i l o gj r u l e s 是最有名的商用b r m s ，它和j e s s 一样是一个非常成熟的商业j a v a 规则引擎，但它同样是价格不菲，对于中小型应用来讲并不是最合适的。 d r o o l s 是完全遵守j s r 一9 4 的规则引擎【8 _ 1 0 1 1 9 1 。而且是a p a c h e 模式许可下的 完全开源框架。它不仅用大家熟知的j a v a 和x m l 语法来表示规则，而且有很强的 用户和开发团体。d r o o l s 使用像j a v a 的语法，并且有最开放的许可，同时，它是 完全免费的。 综上分析，笔者选择了d r o o l s 框架。 第3 章规则引擎的算法研究 第3 章规则引擎的算法研究 模式匹配，也就是对新的数据和被修改的数据进行规则的匹配。进行模式匹 配的引擎称为推理机。目前，推理机所采用的模式匹配算法主要有：r e t e 、l e a p s 、 l i n e a r 和t r e a t 。 任何个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率 问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数 据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。r e t e 算法 可以很好地解决这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都 是使用r e t e 算法1 2 i 。而d r o o l s 框架是采用r e t e 和l e a p s 两种算法实现。本章主 要介绍r e t e 算法。 3 1 r e t e 算法简介 r e t e 在拉丁语中是“n e t ”，有网络的意思。1 9 7 9 年美国卡耐基梅隆大学 的c h a r l e sl f o r g y 在他的博士论文中阐述了r e t e 算法。 r e t e 算法是目前效率最高的一个前向链推理算法【1 2 - 1 7 1 ，其核心思想是将分离 的匹配项，根据内容动态构造匹配树，以达到显著降低计算量的效果。 r e t e 模式匹配算法是在模式匹配中利用推理机的时间冗余性和规则结构的相 似性，通过保存中间过程及模式共享来提高推理效率的一种模式匹配算法。在模 式匹配过程中，规则的前提( l h s ) 中可能会有很多相同的模块，因此在匹配规则 的前提时，将进行大量的重复运算，这样就带来时间冗余性问题。例如： 程序清单3 1 三条简单的规则 若要匹配这3 条规则时，对于表达式a b 要进行三次计算，对b b ，m 2 = b c ；则规则可修改为如下所示。 规则引擎在业务逻辑层中应用的研究 程序清单3 2 采用r e t e 后的三条规则 这样只有当a 或b 发生变化时，才重新计算m 1 ；同样，当b 或c 发生变化时， 重新计算m 2 。这样就避免了在每次进行模式匹配都重复计算相同的表达式，而只 要检测相关参数是否变化来决定是否更新表达式，因此在推理过程中可节省大量 的时间开销，从而提高了推理效率。 3 2 r e t e 算法的原理 在推理过程当中，r e t e 算法是迄今为止被认为性能最好的匹配算法。在研究 r e t e 算法之前，先来研究事实和规则匹配的问题。 如果匹配过程只需一次，那么这个问题解决方法就简单易懂。推理机可以检 查每条规则并寻找事实来决定规则的模式是否已满足。如果满足就将此规则记入 动作序列中【1 7 1 ，如果不满足，则继续检查下一个规则。如图3 1 所示。 图3 1 寻找事实的规则 然而，在基于规则的系统中，匹配过程不断重复进行。通常，事实列表在每 次执行中都会被修改( 新的事实被添加到事实列表中或删除旧的事实) 。这些改 变可能使先前不满足条件的模式得到满足，反之亦然。因此，匹配问题成了不断 进行的循环过程。在每次循环过程中，随着事实的添加或删除，必须对已满足条 第3 章规则引擎的算法研究 件的规则集进行维护和更新。 通常，一个规则的运行或者数据库中数据的更新，仅仅会改变事实列表中的 少数事实，即系统中的事实随时间改变的速度很慢。在每次循环中，仅添加和删 除很少一部分事实，所以，事实列表中的变化一般只影响很少部分的规则。因此， 每次变动都让规则查找所需事实是否改变就需要进行大量计算，这样就会产生大 量不必要的计算问题。如图3 2 所示。阴影部分代表了对事实列表所做的改动。 但是，如果采用如图3 3 所示的方式，即在不断的循环中，通过记住那些已经匹 配好的，然后只计算那些刚添加或删除事实所引起的必要变化，这样就可以避免 不必要的计算。规则是不变的，而事实是变化的，所以应该是事实寻找相应的规 则，而不是规则寻找相应的事实。 图3 2 规则寻找事实产生不必要的计算图3 3 事实寻找规则 r e t e 模式匹配算法很好的解决了基于规则的系统所具有的时间冗余性。它的 实现是通过存储不断循环中匹配过程的状态，并且，仅仅考虑在事实列表中发生 了的且又反映到本次状态中的变化。也就是说，如果在一个执行周期中，一组模 式找到三个所需事实中的两个，那么，在下一个执行周期中，就无需对已经找到 的这两个事实进行检查，此时，只有第三个事实才是需要关注的。仅当添加或删 除事实时，匹配过程的状态才被更新。如果添加、删除事实的数量与事实和模式 的总数相比很小，那么匹配过程就可以进行得很快。最糟的情况是，如果所有的 事实都改变了，那么，所有的事实将与所有的模式进行重新匹配。 另外，许多规则通常包含了相似的模式或模式群，利用这一特性，r e t e 算法 规则引擎在业务逻辑层中应用的研究 通过将公共部分放在一起来提高效率，因为公共部分不必多次计算。这便是模式 共享的基本思想。 总体来说，r e t e 算法的基本思想是保存过去匹配过程中留下的全部信息，以 空间的代价来换取系统的执行效率。对每一模式，附加一个匹配列表来记录工作 记忆中所有能与之匹配的事实。当一个新事实加入到工作记忆时，算法找出所有 能与之匹配的模式，并将该事实加入到匹配事实表中；当一个事实从工作记忆中 删除时，同样找出所有与该事实匹配的模式，并将事实从匹配事实表中删除。r e t e 算法接受对工作记忆的修改操作的描述，从而产生一个修改冲突集的动作。 3 3 r e t e 匹配网络结构 r e t e 算法可以分为两部分：规则编译和运行时执行i l 。 规则的编译描述了规则如何在规则记忆中产生一个有效的辨别网络。方法是 通过数据在匹配网络上的传递来过滤数据。在匹配网络中，根节点将会有很多匹 配的数据。当我们顺着网络向下走，离根节点越远的节点，与其匹配的数据也就 越少。在网络的最底部是终止节点。 在f o r g y 的论文中，描述了4 种基本节点：根节点，卜i n p u t ( a l p h a ) 节点， 2 - i n p u t ( b e t a ) 节点和终止节点。同时，还描述了其它几种对象在匹配网络的匹 配过程中会出现的节点：对象类型节点和左输入适配器节点。如图3 4 所示。 o 对象类型节点 o a l p h a 节点 o 左输入适配器节点 根节点 凸点 凸辅点 _ - 终止节点 图3 4r e t e 节点类型 1 根节点( r o o t n o d e ) 是所有的对象进入网络的入口； 2 对象类型节点是指在r e t e 网络中用以描述了一个对象的节点。对象类型 第3 章规则引擎的算法研究 节点能够将被断言的对象传递到a l p h a 节点、左输入适配器节点或b e t a 节点，如 图3 5 所示； 根节点 图3 5 对象类型节点 3 卜i n p u t 节点通常被称为a l p h a 节点。a l p h a 节点被用来计算条件是否满 足。虽然，在f o r g y 的论文中只提到了相等条件，但很多的 e t e 实现支持其它的 操作。当一个规则对于一种对象类型有多条条件时，这些对象将被链接在一起。 也就是说，如果一个规则断言一个a c c o u n t 对象，在它被传递到下一个a l p h a 节 点之前，它必须先满足第一个条件。图3 6 表示了c h e e s e ( n a m e = = “c h e d d a r ”， s t r e n g t h 一“s t r o n g ”) 的a l p h a 节点组合； c基heese i 二， 4