规则引擎的设计与实现答辩稿.pptVIP

规则引擎的设计与实现 提纲 简介 关键技术的介绍 轻量级讨论 总体结构 实现细节 外部组件 测试 总结 项目来源、研究的目的和意义 GSP平台三期中的核心引擎之一。 顺应“随需应变”的思想。企业级信息系统经常需要随着商业决策逻辑的变化而不断变化系统中的业务规则 。 实现灵活的修改商业逻辑，提高系统的柔韧性。 减小开发难度，降低维护的成本。 规则引擎的简介 规则引擎是一种嵌入在应用程序中的组件，实现了将复杂的业务逻辑从应用程序中分离，并使用预定义的规则定制器编写决策。依据已存的事实库或数据对象的输入，解释规则，匹配规则，做出决策。 核心思想：“用规则引擎替换以程序代码‘固化’在应用程序中的业务逻辑 ，以提高应用系统的灵活性 ”。 规则引擎的简介 本文描述规则引擎是一种瞬时的规则引擎，它不对运行产生的结果作任何的持续化，所有运行时的数据都是在引擎初始时加载的，并且所有操作的运行数据都是存放在内存中，运行结束后，释放所有数据。 我们称它为流程引擎。 有别于使用Rete算法实现的推理引擎。推理引擎对数据进行持续化，并且历史数据会对引擎运行结果产生影响。推理引擎产生一条新的数据插入事实库后，监听事实库的程序使用匹配算法发现某条产生式的条件都满足了，便会激活这条产生式，产生新的事实或执行相应的动作。 应用场景 应用场景广阔。ERP系统、游戏、智能决策系统。 在GSP平台中的应用。 工作流引擎中，判断入路由和出路由的条件。 消息引擎中，定制发消息的策略。 自定义表单中，控制界面的展现状态。 规则引擎的需求 定制复杂的商业规则。 根据业务规则的变化，快速、低成本的更新。 业务人员可以独立的完成规则的定制和修改。 规则引擎的特点 业务规则和系统代码分离，对业务规则的修改对系统没有任何的影响。这就可以快速、低成本的更新系统。 业务规则统一存取，易于管理，减小了维护的难度。 业务规则的定制可以使用图形化的规则设计模块来完成。这就可以让熟悉业务的企业人员独立的完成业务规则的修改。 使用规则引擎和规则设计器 与传统软件开发方式的比较 传统的软件开发方式 会用一段带有“if-else”、“while”、“foreach”等的程序块来表达业务逻辑。 业务变更需要修改程序。 使用规则的方式 业务逻辑和应用系统是分离的。 应用程序不需要修改一行代码就可以完成对业务逻辑的变更。 关键技术的选择 本文描述的规则引擎使用了流程引擎，而没有使用推理引擎，因为： 推理引擎实现难度大，流程引擎相对简单。 一般业务逻辑不需要进行推理，挖掘新知识。 流程引擎能更好的表现出业务流程。 运行原理 关于轻量级的讨论 本文描述的将是一种轻量级的规则引擎。 所谓轻量级，就是体现了一种够用的思想，加强核心功能，去除边缘功能。 将非核心功能留给其他外围组件去实现，让其他程序员组合使用。适应二次开发，以满足特殊需求的系统。 规则引擎的实现 规则引擎的实现 上图中，黄色框内部是规则引擎的核心。核心非常简单，将所有的与解析规则无关的功能都交给的外部的组件实现。 规则引擎的实现 引擎核心包括： Console是引擎的门户，调用引擎的接口。 Driver规则驱动器，封装规则文档，以统一的方式供引擎使用。 Factory规则引擎的工厂类，初始化引擎。 Implements包，包含引擎的实现，解析规则，执行规则。 Model包，支持引擎运行的需要保持的信息的结构。包括：引擎上下文、操作符、动作组件，以及规则结构的实体类，序列化和反序列化规则脚本的类。 Utils包，工具类的集合，包括参数类和提供反射机制的类。 Resource包，规则文档的结构描述。 Persistence包，提供给规则设计器的一些服务的封装。 规则引擎的实现 外围核心组件： 前处理组件，处理规则文档中的特殊定义。 应用程序调用组件实现了动作调用的功能，可以调用多种类型的外部程序。 规则设计器用图形化方式定制业务逻辑。 数据访问组件支持数据的访问。 配置组件和日志组件为了支持引擎的运行而设计。 规则文档结构 规则文档是规则的信息载体。规则语言设计的好坏决定了业务逻辑的表现能力和系统的功能。 本系统使用xml来描述规则。 将文档分成许多部件并对这些部件加以标识。降低解析的难度。 可扩展的。 易于交互的。 规则语言的定义 规则语言的定义 规则语言与程序语言的比较 内部结构—Console、接口和上下文 内部结构--RulesDriver 内部结构--Models 内部结构—操作符、Atom 内部结构—引擎运行 内部结构—初始化 内部结构—执行 实现细节 读取规则文档的方式的选择： DOM采用建立树形结构的方式访问XML文档，可以对树进行遍历，编程简单，但加载的过程长，占用系统的资源大，解析速度慢