规则规则引擎的定义及体系结构

规规则引擎的定义及其体系结构

摘要

随着经济的迅速发展市场的快速变化导致商业业务规则的变化也越来越快因此对于企业的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为例介绍这三种运行模式。

RetePlus

Rete是目前主流的规则引擎模式匹配算法RetePlus则是JRules在Rete算法上的扩展和优化也是JRules规则引擎默认的运行模式。 RetePlus运行模式为ILOG规则引擎提供了种种手段用以尽量减少需要加以评估的规则和条件的数量计算哪些规则应当执行并确定这些规则的执行顺序。在RetePlus算法中规则引擎使用Workingmemory工作内存和Agenda来存放和操作应用程序对象。Working memory中包含的应用程序对象的引用Ag e nd a则按顺序列出将要执行的规则实例。如图1所示

图1 .RetePlus执行模式

具体执行过程如下

1 、规则引擎依据Working Memory中的数据对象来匹配规则集中规则的条件部分。在模式匹配过程中RetePlus首先创建出以规则条件测试之间的语义关系为基础的网络步骤1  然后将匹配的规则实例化并添加到Ag e nd a中随后对Ag e nd a中的规则按照一定原则进行排序步骤2

。

2、执行Agenda中的规则实例即执行规则的动作Action 部分。同时规则实例的执行也会影响Working Memory中的数据对象主要方式有 步骤3 

 1 往Working Memory中加入一个新的对象

2移除Working Memory中现有对象

3修改现有对象的属性

3、以上过程将不断重复直至执行完Ag e nd a中所有规则实例。

在RetePlus算法中每当Working Memory被修改规则引擎将重复模式匹配的过程。它在每次规则执行数据修改后重新评估每个规则匹配。这可能会改变Agenda中的规则实例。 因此RetePlus是渐进的和数据驱动的。这些特点使RetePlus在计算和关联性类型的应用方面拥有卓越的性能。

Sequential

顺序运行模式顾名思义即规则引擎按顺序执行rule task中符合条件的所有规则。如图2所示

图2.顺序执行模式

具体执行过程如下

1、规则引擎根据输入参数以及working memory中的对象集合和规则的条件部分进行匹配。每次匹配都将生成一个规则实例并立即运行。 步骤1 

2、 当规则实例被执行后它有可能设置属性或规则集输出参数的值。 步骤2

顺序算法执行的规则是无状态的。顺序算法的运行就像堆栈一样匹配的规则只会运行一次而不会再次评估。 因此在顺序模式下规则中不能使用类似“至少有一个<词汇>”、 “如下对象的数目  <词汇>”等等跟working memory中对象有关系的存在性条件existence conditions  除非这个对象是集合类型。顺序模式的特性决定了其在校验和一致性等类型的应用中有良好的性能表现

。

FastPath

Fastpath运行模式是增强型的顺序运行模式和顺序模式类似 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如果执行规则存在冲突confl ict  即同时激活了多个规则将冲突的规则放入冲突集合。

4解决冲突将激活的规则按顺序放入Ag end a。

5执行Ag e nd a中的规则。重复步骤2至5 直到执行完毕Ag e nd a中的所有规则。

上述即是规则引擎的原始架构商业规则引擎就是从这一原始架构演变而来的。

3.2规则引擎的工作机制

规则引擎是一种根据规则中包含的指定过滤条件判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。为更好的理解并阐述规则引擎的工作机制下面先介绍四个与规则引擎相关的基本概念。

1 、信息元 Information Unit 

信息元是规则引擎的基本建筑块它是一个包含特定事件的所有信息的对象。这些信息包括消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息。

2、信息服务 Information Services

信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生的每个信息元对象有相同的格式但可以有不同的属性和规则集。需要注意的事在一台机器上可以运行许多不同的信息服务还可以运行同一信息服务的不同实例。但无论如何每个信息服务只产生它自己类型相对应的信息元。

3、规则集Rule Set 

顾名思义规则集就是许多规则的集合。每条规则包含一个过滤器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合其组合结果仍然是一个布尔类型的。在程序运行时动作将会在条件过滤器值真的情况下执行。除了一般的执行动作还有三类比较特别的动作它们分别是放弃动作Discard Action  、包含动作 Include Action 和使信息元对象内容持久化的动作。

4、队列管理器Queue Manager 

队列管理器用来管理来自不同信息服务的信息元对象的队列。

下面介绍规则引擎的工作机制。

规则引擎从队列管理器中依次接收信息元若是java规则引擎即为java对象 然后依规则定义的顺序检查第一个规则并对其条件过滤器求值如果值为假所有与此规则相关的动作皆被忽略并继续执行下一条规则。如果第二条规则的过滤器值为真所有与此规则相关的动作皆依定义顺序执行执行完毕继续下一条规则。该信息元中的所有规则执行完毕后信息元将被销毁然后从队列管理器接收下一个信息元。在这个过程中并考虑两个特殊动作放弃动作Discard Action 和包含动作 Include Action  。放弃动作如果被执行将会跳过其所在信息元中接下来的规则并销毁所在信息元规则引擎继续接收队列管理器中的下个信息元。包含动作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行规则引擎将暂停并进入被包含的规则集执行完毕后规则引擎还会返回原来暂停的地方继续执行。以上过程将递归进行。

由规则引擎的工作机制可以看出任何一个规则引擎都需要很好地解决规则的推理机制和规则的条件匹配的效率问题。 当引擎执行时引擎会根据规则执行队列中的先后顺序逐条执行规则实例。 出于规则的行为部分可能会导致工作区中的数据对象改变从而会是执行队列中的某些规则实例因为条件改变而失效必须从队列中撤销有可能会激活原来不满足条件的规则生成新的规则实例进入执行队列。于是就产生了一种“动态”的规则执行链形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。