指导规则引擎的定义及标准体系结构.doc

规规则引擎定义及其体系构造摘 要 随着经济迅速发展，市场迅速变化导致商业业务规则变化也越来越快，因而对于公司IT部门或者IT公司来说，这就规定设计出来应用系统可以适应这种迅速变化。然而，软件开发周期和维护周期长，这和适应迅速变化市场需求产生了矛盾。规则引擎浮现较好解决了这一矛盾。有了规则引擎，咱们可将以程序代码形式固化在应用系统中业务逻辑分离、抽象出来，被分离业务逻辑以业务规则形式存储在规则库中，并通过规则引擎进行执行。本文将简介规则引擎定义，并将以WebSphere ILOG JRules 规则引擎为例简介其体系构造。核心字 规则引擎 业务规则 业务对象模型 规则执行模型 规则调用目 录第1章 绪论1.1规则引擎产生背景第2章 规则引擎概述2.1 业务规则2.2 规则引擎2.2.1 什么是规则引擎2.2.2 使用规则引擎长处2.3 规则引擎运营模式第3章 规则引擎架构和工作机制3.1 规则引擎架构原理3.2 规则引擎工作机制第4章 总结第1章 绪论1.1 规则引擎产生背景随着信息技术在公司广泛应用，公司 IT 部门所开发和维护应用系统也越来越复杂，而当代公司规定响应迅速及灵活，她们对公司软件也有同样规定。公司管理者对公司级IT系统开发有着如下规定：一、为提高效率，管理流程必要自动化，虽然当代商业规则异常复杂。二、市场规定业务规则经常变化，IT系统必要根据业务规则变化迅速、低成本更新。三、为了迅速、低成本更新，业务人员应能直接管理IT系统中规则，不需要程序开发人员参加。因而如何使应用系统可以更快响应公司业务变化已成为公司 IT 发展重要挑战之一。此外，项目开发人员会遇到了如下问题：一、程序=算法+数据构造，有些复杂商业规则很难推导出算法和抽象出数据模型。二、软件工程规定从需求设计编码，然而业务规则经常在需求阶段也许还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中。三、对程序员来说，系统已经维护、更新困难，更不也许让业务人员来管理。但是，当包括业务逻辑代码隐藏在大量其她代码中时，修改就变得缓慢、痛苦且易出错了。因而，复杂公司级项目开发以及其中随外部条件不断变化业务规则,迫切需要分离商业决策者商业决策逻辑和应用开发者技术决策，并把这些商业决策放在中心数据库或其她统一地方，让它们能在运营时（即商务时间）可以动态地管理和修改从而提供软件系统柔性和适应性。规则引擎正是应用于上述动态环境中一种解决办法。第2章 规则引擎概述2.1业务规则业务规则专家组 (BRG)规定了业务规则两个定义。第一种定义与业务观点有关，而第二个定义与IT有关：1、“从业务角度而言，业务规则是一种原则，包括在特定活动或范畴内关于指引、操作、实践或过程行为规范。” 2、“从IT角度而言，规则是可集成到既有基本构造（如基于应用程序或面向服务体系构造）决策系统灵活实现。”一种业务规则包括一组条件和在此条件下执行操作，它们表达业务规则应用程序一段业务逻辑。业务规则普通应当由业务分析人员和方略管理者开发和修改，但有些复杂业务规则也可以由技术人员使用面向对象技术语言或脚本来定制。业务规则理论基本是:设立一种或各种条件，当满足这些条件时会触发一种或各种操作。 运营时，规则引擎必要对这些业务规则进行解释。可以将规则引擎理解为一种高性能专用解释程序，其中包括if-then命令，可依照预先定义规则对转换值和对象进行分析，然后返回修改后值和对象，或直接执行操作。2.2 规则引擎 2.2.1 什么是规则引擎规则引擎由推理引擎发展而来，是一种嵌入在应用程序中组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义语义模块编写业务决策。接受数据输入，解释业务规则，并依照业务规则做出业务决策。其中，推理引擎由三某些构成，它们分别是规则解释器Rule Interprete、模式匹配器Pattern Matcher和议程Agenda。模式匹配器从规则库中找出需要执行规则并写入议程；议程为这些规则赋予优先级，拟定执行顺序；规则解释器执行这些规则并输出运营成果。规则引擎具备如下功能：1、可以将核心业务规则与其她源代码分开保存。它使顾客可以迅速实行业务逻辑更改而不必重新编写应用程序。2、它使用了XOM，即定义应用执行规则类。这些类可以有不同数据来源，这些数据可以在XOM中像对Java类同样进行查看和解决。例如，XOM使用了功能强大XML绑定系统，使规则引擎可以直接对XML数据或Web Service所提供数据进行操作。3、通过嵌入方式，可以在任何Java应用程序中执行业务规则，并支持各种布置方案，从而优化了系统性能和扩展性。2.2.2 使用规则引擎长处使用规则引擎可以通过减少实现复杂业务逻辑组件复杂性，减少应用程序维护和可扩展性成本，其长处如下： 1、分离商业决策者商业决策逻辑和应用开发者技术决策； 2、能有效提高实现复杂逻辑代码可维护性； 3、在开发期间或布置后修复代码缺陷； 4、应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内； 5、符合组织对敏捷或迭代开发过程使用；2.3 规则引擎运营模式 规则引擎依照规则不同应用场景和业务规则特点提供了三种惯用不同运营模式：RetePlus、Sequential 和 FastPath。下面将以当前最主流规则引擎JRules ILog 为例简介这三种运营模式。RetePlusRete是当前主流规则引擎模式匹配算法，RetePlus 则是 JRules 在 Rete 算法上扩展和优化，也是 JRules 规则引擎默认运营模式。RetePlus 运营模式为 ILOG 规则引擎提供了种种手段，用以尽量减少需要加以评估规则和条件数量，计算哪些规则应当执行，并拟定这些规则执行顺序。在 RetePlus 算法中，规则引擎使用 Working memory（工作内存） 和 Agenda来存储和操作应用程序对象。Working memory 中包括应用程序对象引用，Agenda 则按顺序列出将要执行规则实例。如图1所示： 图 1. RetePlus 执行模式详细执行过程如下：1、规则引擎根据 Working Memory 中数据对象来匹配规则集中规则条件某些。在模式匹配过程中，RetePlus 一方面创立出以规则条件测试之间语义关系为基本网络（环节 1），然后将匹配规则实例化并添加到 Agenda 中，随后对 Agenda 中规则按照一定原则进行排序（环节2）。2、执行 Agenda 中规则实例，即执行规则动作（Action）某些。同步，规则实例执行也会影响 Working Memory 中数据对象，重要方式有：（环节3）：（1）往 Working Memory 中加入一种新对象（2）移除 Working Memory 中既有对象（3）修改既有对象属性3、 以上过程将不断重复，直至执行完 Agenda 中所有规则实例。在RetePlus 算法中每当 Working Memory 被修改，规则引擎将重复模式匹配过程。它在每次规则执行数据修改后重新评估每个规则匹配。这也许会变化 Agenda 中规则实例。因而，RetePlus 是渐进和数据驱动。这些特点使 RetePlus 在计算和关联性类型应用方面拥有卓越性能。Sequential顺序运营模式，顾名思义，即规则引擎按顺序执行 rule task 中符合条件所有规则。如图 2 所示： 图 2. 顺序执行模式详细执行过程如下：1、 规则引擎依照输入参数以及 working memory 中对象集合和规则条件某些进行匹配。每次匹配都将生成一种规则实例并及时运营。（环节 1）2、 当规则实例被执行后，它有也许设立属性或规则集输出参数值。（环节 2）顺序算法执行规则是无状态。顺序算法运营就像堆栈同样，匹配规则只会运营一次，而不会再次评估。因而在顺序模式下，规则中不能使用类似“至少有一 个 ”、“如下对象数目：”等等跟 working memory 中对象关于系存在性条件（existence conditions），除非这个对象是集合类型。顺序模式特性决定了其在校验和一致性等类型应用中有良好性能体现。FastPathFastpath 运营模式是增强型顺序运营模式，和顺序模式类似，Fastpath 也是顺序运营，但是它同步还能和 RetePlus 模式同样在进行模式匹配时检测规则条件语义关系。如图 3所示： 图 3.FastPath 执行模式详细执行过程如下：1、在 Fastpath 模式中，规则引擎可以通过 working memory 引用应用数据对象或规则集参数。与 Reteplus 类似，在模式匹配时 Fastpath 同样创立以规则条件测试之间语义关系为基本网络（环节 1）。2、每次匹配，将创立一种规则实例并及时执行。规则实例执行后，它也许修改 working memory 中对象，但是这些修改不会影响其他规则执行，并且规则引擎也不会重复模式匹配过程（环节 2）。Fastpath 综合了 Reteplus 模式匹配和顺序运营模式规则执行特性，从这个意义上来说，它在关联型应用和校验类应用中均有较好体现。和顺序运营模式同样，Fastpath 运营模式也是无状态，适合在大量单独执行简朴鉴定或少量交叉测试规则上进行对象匹配。这样某些规则集可以在没有任何 agenda 支持下较好按顺序执行。除了作为一种变异顺序模式优势，Fastpath 运营模式目是进一步优化一致性和校验性类型规则执行，普通这些类型规则占据了商业规则绝大某些。第3章 规则引擎体系构造3.1 规则引擎架构原理1、规则引擎架构如图4所示：图4.业务规则引擎架构2、 规则引擎推理环节如下： （1）将初始数据（fact）输入至工作内存(Working Memory)。 （2）使用Pattern Matcher将规则库(Rules repository)中规则（rule）和数据（fact）比较。 （3）如果执行规则存在冲突（conflict），即同步激活了各种规则，将冲突规则放入冲突集合。 （4）解决冲突，将激活规则按顺序放入Agenda。 （5）执行Agenda中规则。重复环节（2）至（5），直到执行完毕Agenda中所有规则。上述即是规则引擎原始架构，商业规则引擎就是从这一原始架构演变而来。3.2 规则引擎工作机制规则引擎是一种依照规则中包括指定过滤条件，判断其能否匹配运营时刻实时条件来执行规则中所规定动作引擎。为更好理解并阐述规则引擎工作机制，下面先简介四个与规则引擎有关基本概念。1、 信息元（Information Unit）信息元是规则引擎基本建筑块，它是一种包括特定事件所有信息对象。这些信息涉及：消息、产生事件应用程序标记、事件产生事件、信息元类型、有关规则集、通用办法、通用属性以及某些系统有关信息。2、 信息服务（Information Services）信息服务产生信息元对象。每个信息服务产生它自己类型相相应信息元对象。即特定信息服务依照信息元所产生每个信息元对象有相似格式，但可以有不同属性和规则集。需要注意事，在一台机器上可以运营许多不同信息服务，还可以运营同一信息服务不同实例。但无论如何，每个信息服务只产生它自己类型相相应信息元。3、 规则集（Rule Set）顾名思义，规则集就是许多规则集合。每条规则包括一种过滤器和各种动作。一种条件过滤器可以包括各种过滤条件。条件过滤器是各种布尔表达式组合，其组合成果依然是一种布尔类型。在程序运营时，动作将会在条件过滤器值真状况下执行。除了普通执行动作，尚有三类比较特别动作，它们分别是：放弃动作（Discard Action）、包括动作（Include Action）和使信息元对象内容持久化动作。4、 队列管理器（Queue Manager）队列管理器用来管理来自不同信息服务信息元对象队列。下面简介规则引擎工作机制。规则引擎从队列管理器中依次接受信息元（若是java规则引擎，即为java对象），然后依规则定义顺序检查第一种规则并对其条件过滤器求值，如果值为假，所有与此规则有关动作皆被忽视并继续执行下一条规则。如果第二条规则过滤器值为真，所有与此规则有关动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中所有规则执行完毕后，信息元将被销毁，然后从队列管理器接受下一种信息元。在这个过程中并考虑两个特殊动作：放弃动作（Discard Action）和包括动作（Include Action）。放弃动作如果被执行，将会跳过其所在信息元中接下来规则，并销毁所在信息元，规则引擎继续接受队列管理器中下个信息元。包括动作其实就是动作中包括其他现存规则集动作。包括动作如果被执行，规则引擎将暂停并进入被包括规则集，执行完毕后，规则引擎还会返回本来暂停地方继续执行。以上过程将递归进行。由规则引擎工作机制可以看出，任何一种规则引擎都需要较好地解决规则推理机制和规则条件匹配效率问题。当引擎执行时，引擎会依照规则执行队列中先后顺序逐条执行规则实例。出于规则行为某些也许会导致工作区中数据对象变化，从而会是执行队列中某些规则实例由于条件变化而失效，必要从队列中撤销；有也许会激活本来不满足条件规则，生成新规则实例进入执行队列。于是就产生了一种“动态”规则执行链，形成规则推理机制。这种规则“链式”反映完全是由工作区中数据驱动。第4章 总结当今世界经济迅速变化，规定公司具备高度适应性来紧跟这种迅速变化，才干在当今竞争激烈经济环境中生存下去。这就规定作为公司重要构成某些IT系统同样具备这样适应性，来协助公司捕获市场机会。然而，软件开发周期和维护周期都很长，这就和适应当前迅速变化市场产生了矛盾。解决这个矛盾一种办法就是使这些迅速变化商业逻辑可以从应用程序系统中分离出来。基于规则专家系统浮现给开发人员以解决这个矛盾契机。规则引擎由基于规则专家系统中推理引擎发展而来，是一种嵌入在应用程序中组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义语义模块编写业务规则。这种分离方略使应用程序在不增长成本状况下能更好适应迅速变化市场。本文重要对规则引擎定义、运营模式、架构和工作机制等进行了阐述，也是对接触规则引擎以来一次总结。