业务规则管理系统的基本原理是：用一个或多个规则引擎替换以程序代码"固化"在应用系统中的业务逻辑。一个完善的BRMS可以对业务规则的整个生命周期实现全程管理。
业务规则的全生命周期管理如图1所示。BRMS在应用系统中的地位与数据库管理系统（DBMS）类似，处于比较基础的位置，是其他高端应用的基石。图2是GIGA Information Group 给出的IT架构中BRMS的位置图。
业务规则管理如何实现？
业务规则
一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。业务规则的理论基础是:设置一个或多个条件，当满足这些条件时会触发一个或多个操作。
规则引擎
这是一种嵌入在应用程序中的组件，它的任务是把当前提交给引擎的数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。
目前主流的规则引擎组件多是基于Java和C++程序语言环境。在2000年11月，Java Community Process（简称JCP） 组织开始着手起草Java规则引擎的API标准，即JSR 94 规范。参与JSR 94起草的有BEA、IBM、ILOG、甲骨文、Novell、ATG、Unisys、Fujitsu等著名的软件企业。JSR 94 在2003年11月25日正式定稿，支持JSR 94标准的规则引擎也几乎同时推向市场，包括ILOG 的JRules和Blaze的Advisor。
规则引擎的使用方式
由于规则引擎是软件组件，所以只有开发人员才能够通过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含以下几种API：加载和卸载规则集的API；数据操作的API；引擎执行的API。开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤：创建规则引擎对象；向引擎中加载规则集或更换规则集；向引擎提交需要被规则集处理的数据对象集合；命令引擎执行;导出引擎执行结果，从引擎中撤出处理过的数据。使用了规则引擎之后，许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代。
一个开放的业务规则引擎应该可以"嵌入"在应用程序的任何位置，不同位置的规则引擎可以使用不同的规则集，用于处理不同的数据对象。此外，对使用引擎的数量没有限制。
规则引擎的内部实现
规则引擎的基本机制是：对提交给引擎的数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般，规则引擎内部由下面几个部分构成：工作内存，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。规则引擎的结构示意图如图3所示。
任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。
当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种"动态"的规则执行链，形成规则的推理机制。这种规则的"链式"反应完全是由工作区中的数据驱动的。
规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。
BOM赋予规则行业特性
业务规则一定是针对某种业务的，不同的业务有自己特有的业务模型——业务对象模型（Business Object Mode，简称BOM）。BOM为业务规则语言提供了绝大多数的词汇，多由业务系统分析员设计，由开发人员具体实现。从面向对象的编程角度来看，BOM就是一个简化的类图，类图中有类名、类的属性、类的方法等。这些要素都将是业务规则语言中的基本"词汇"。BOM的来源可以是Java对象模型、C++对象模型、XML Schema、Web服务定义等。
假定我们有一个简单的宠物商店购物车应用程序，在这个应用程序中，顾客能够在购物车中放入各种宠物和相关物品对象。这个应用程序的业务对象集合就可以有ShoppingCart(购物车)、Customer(用户)、Item (条目)和ItemType(条目类型)这几个类。
表述业务规则的语法就是业务规则语言。由于规则语言的使用者主要有两类:业务人员和技术人员，所以规则语言一般也分为两类："面向程序技术"的规则语言，它技术性很强，可读性较弱，比较适合IT 技术人员使用，一般每个规则引擎开发商都有自己的一套"面向程序技术"的规则语言语法，不过OASIS组织定义了不同应用情况下的规则语言规范，包括 SRML（Simple Rule Markup Language），BMRL(Business Markup Rule Language)和RuleML（Rule Markup Language）等；"面向业务"的规则语言，它是业务人员使用的语言，必须具备非技术性和可定制性，通常它需要经过"翻译"之后才能被规则引擎解析。 BRMS必须提供这种"翻译"机制，而开发人员要实现从"面向业务"规则语言到"面向程序"规则语言的映射。
"面向业务"的规则语言无论从语法上还是语句结构上都可能千变万化，不同行业可能有自己的"行话"。一个好的BRMS应该提供一个完善的规则语言框架，能够迅速地为业务人员定制不同的"行话"，否则业务人员还是无法真正成为业务规则的主人。
"单纯"的规则如何互连?
业务规则有一个非常明显的特性：单纯性。每个业务规则只描述自己特有的条件和满足条件的操作，业务规则本身并不关心它与其他规则的关系，如优先关系、互斥关系、包含关系等。每个业务规则本身可以有自己的属性，称元信息，可以用来处理规则之间相关性，例如引擎可以使用规则的优先级来依序执行规则的操作。
有些BRMS还提供一种称为"规则流"的定制功能。规则流是一个图表，定义了解决问题或执行业务流程的顺序。类似于统一建模语言（UML）的活动图，由一组任务以及定义这些任务之间执行顺序的转换逻辑组成。一个转换由条件控制，只有当该限制条件为"真"时才能完成这种转换。
这些任务可以是规则任务、函数任务或子规则流任务。规则任务包含一组要作为任务主体执行的规则，规则的执行逻辑由用户设置的任务属性严格控制。这些属性决定规则的排序、规则触发策略、执行算法等；函数任务包含要作为任务主体执行的脚本代码；子规则流任务则包含任务开始后将依次执行的子规则流。
为了方便开发人员和业务人员管理业务规则，BRMS必须提供具有直观用户界面的工具来实现业务规则管理。规则管理工具至少应该具备以下功能：规则的定制和编辑、规则流的定制、决策表形式的规则定制、规则的查询、规则有效期限的控制、规则的组织结构、规则模板的定制、规则库访问权限的控制、规则变更历史的记录、规则文档的管理等。
·小资料2·
业务规则管理系统其实是一组工具集，它包括：规则引擎、规则库、规则语言框架、规则管理集成开发环境。业务规则管理系统的基本工作原理如图所示。
规则引擎（Rules Engine）
是执行业务规则的软件组件，它嵌入在程序中，是业务规则管理系统的核心元素。规则引擎的类型有：简单型、数据中心型和面向事务型。
规则库（Rules Repository）及其服务机制
用于存储规则和规则元数据（Meta Data）以及与规则有关的属性。它提供一组工具用于存储、分类、查询、版本控制、权限控制、测试、提交等，规则的状态和有效性可以跟踪。规则库可以依托文件系统或数据库管理系统。
规则语言框架（Rules Language Framework）
规则语言一般分为两类："面向程序技术"的规则语言，使用者是技术人员；"面向业务"的规则语言，使用者是业务人员。规则语言框架则为定制"面向业务"的规则语言提供支持。
规则管理工具（Rules Management Tool）
用于管理、创建、修改和部署业务规则的图形化工具，易用性强，除了开发人员外，业务人员也可以使用这套图形化工具实现对规则的管理。
规则集成开发环境（Rules IDE）
一般规则集成开发环境只有规则编辑器，而高级的规则集成开发环境可以实现对规则和规则库的管理：如规则的创建、分类、检索、修改、版本控制、权限管理等；甚至可以实现对多个规则引擎的"在线"调试；对规则集合进行冲突检查等。
一个完整的BRMS应该提供规则管理（Rules Management）、规则部署（ules Deployment）、规则分析（Rules Analysis）、规则定制和设计（Rules Design and Authoring）等功能
945
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
