规则新版规则引擎的定义及综合体系结构

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

摘要

伴随经济快速发展市场快速改变造成商业业务规则改变也越来越快所以对于企业I T部门或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为例介绍这三种运行模式。

R e te Plus

Rete是现在主流规则引擎模式匹配算法ReteP lus则是J Rules在Rete算法上扩展和优化也是JRules规则引擎默认运行模式。 RetePlus运行模式为ILOG规则引擎提供了种种手段用以尽可能降低需要加以评定规则和条件数量计算哪些规则应该实施并确定这些规则实施次序。在RetePlus算法中规则引擎使用Working memory 工作内存 和Agenda来存放和操作应用程序对象。Working memory中包含应用程序对象引用Agenda则按次序列出将要实施规则实例。 图1所表示

图1.Re te Plus实施模式

具体实施过程以下

1、规则引擎依据Working Memory中数据对象来匹配规则集中规则条件部分。在模式匹配过程中 ReteP lus首先创建出以规则条件测试之间语义关系为基础网络步骤1然后将匹配规则实例化并添加到Agenda中随即对Agenda中规则根据一定标准进行排序步骤2。

2、实施Agenda中规则实例 即实施规则动作Action部分。 同时规则实例实施也会影响Working Memory中数据对象关键方法有 步骤3

1往Working Memory中加入一个新对象

2移除Working Memory中现有对象

3修改现有对象属性

3、 以上过程将不停反复直至实施完Agenda中全部规则实例。

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

Se que ntial

次序运行模式顾名思义即规则引擎按次序实施rule task中符合条件全部规则。图2所表示

图2.次序实施模式

具体实施过程以下

1、规则引擎依据输入参数和working memory中对象集合和规则条件部分进行匹配。每次匹配全部将生成一个规则实例并立即运行。 步骤1

2、当规则实例被实施后它有可能设置属性或规则集输出参数值。 步骤2

次序算法实施规则是无状态。次序算法运行就像堆栈一样匹配规则只会运行一次而不会再次评定。所以在次序模式下规则中不能使用类似“最少有一个<词汇>”、 “以下对象数目 <词汇>”等等跟working memory中对象相关系存在性条件existenc ec onditions除非这个对象是集合类型。次序模式特征决定了其在校验和一致性等类型应用中有良好性能表现。

Fas tPath

F as tp ath运行模式是增强型次序运行模式和次序模式类似 F as tp ath也是次序运行不过它同时还能和ReteP lus模式一样在进行模式匹配时检测规则条件语义关系。图3所表示

图3.FastPath实施模式

具体实施过程以下

1、在Fastpath模式中规则引擎能够经过working memory引用应用数据对象或规则集参数。和Retep lus类似在模式匹配时F as tp ath一样创建以规则条件测试之间语义关系为基础网络步骤1。

2、每次匹配将创建一个规则实例并立即实施。规则实例实施后它可能修改workingmemory中对象不过这些修改不会影响其它规则实施而且规则引擎也不会反复模式匹配过程步骤2。

F as tp ath综合了Reteplus模式匹配和次序运行模式规则实施特征从这个意义上来说它在关联型应用和校验类应用中全部有很好表现。和次序运行模式一样 F as tpath运行模式也是无状态适合在大量单独实施简单判定或少许交叉测试规则上进行对象匹配。这么部分规则集能够在没有任何agenda支持下很好按次序实施。除了作为一个变异次序模式优势F as tp ath运行模式目标是深入优化一致性和校验性类型规则实施通常这些类型规则占据了商业规则绝大部分。

第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系统一样含有这么适应性来帮助企业捕捉市场机会。然而软件开发周期和维护周期全部很长这就和适应该前快速改变市场产生了矛盾。处理这个矛盾一个方法就是使这些快速改变商业逻辑能够从应用程序系统中分离出来。基于规则教授系统出现给开发人员以处理这个矛盾契机。规则引擎由基于规则教授系统中推理引擎发展而来是一个嵌入在应用程序中组件实现了将业务决议从应用程序代码中分离出来并使用预定义语义模块编写业务规则。这种分离策略使应用程序在不增加成本情况下能愈加好适应快速改变市场。

本文关键对规则引擎定义、运行模式、架构和工作机制等进行了叙述也是对接触规则引擎以来一次总结。