用规则引擎替换代码

作者: 何仁杰 梁冰



业务规则管理系统的基本原理是:用一个或多个规则引擎替换以程序代码"固化"在应用系统中的业务逻辑。一个完善的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)等功能
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 对于如何采用TBEL替换Nashorn引擎的问题,可能需要查看thingsboard老版本的文档或者代码库,因为具体实现方式可能会有所不同。但是一般而言,可以按照以下步骤进行替换: 1. 确定你的thingsboard版本是否支持TBEL引擎,如果不支持,则需要升级到支持TBEL引擎的版本。 2. 下载并安装TBEL引擎。 3. 配置thingsboard的环境变量,将Nashorn引擎替换为TBEL引擎。 4. 将使用Nashorn引擎的相关代码修改为使用TBEL引擎,具体代码修改方式需要根据项目实际情况来确定。 需要注意的是,在进行引擎替换时,可能会影响系统性能和安全性,因此一定要进行充分的测试和评估。同时,如果对系统的配置和代码不熟悉,建议寻求专业人员的帮助。 ### 回答2: 在旧版本的Thingsboard中,要将TBEL代替Nashorn引擎,可以按照以下步骤进行: 1. 更新Thingsboard版本:首先,需要确保已将Thingsboard更新至支持TBEL的最新版本。因为TBEL是在较新的Thingsboard版本中引入的,因此旧版本可能不支持TBEL。 2. 备份旧规则:在进行引擎替换之前,建议先备份之前针对Nashorn编写的所有规则。这样,万一出现问题,可以恢复到旧版本的规则。 3. 导入TBEL规则:将TBEL规则导入到Thingsboard中。TBEL 是一种简化的事物规则引擎语言,可以用于编写基于规则的设备处理逻辑。具体的导入方法可以参考Thingsboard的文档或开发者指南。 4. 调整规则逻辑:经过导入后,需要对原先的规则进行调整以适应TBEL引擎的语法和特性。TBEL使用了一些新的关键字和语法,可能需要对规则进行适当修改,以确保其在TBEL引擎下正常运行。 5. 测试和调试:在替换引擎后,进行测试和调试以确保规则逻辑的正确性。可以通过创建测试设备或使用模拟数据来验证规则的执行情况,以及确认其是否按照预期产生结果。 总结:采用TBEL替代Nashorn引擎需要更新Thingsboard到支持TBEL的版本,并使用TBEL规则替换原先的Nashorn规则。然后,需要调整规则逻辑以适应新引擎,并进行测试和调试以确保规则的正确性和功能。 ### 回答3: 要将ThingsBoard的旧版本中的Nashorn引擎替换为TBEL引擎,你需要执行以下步骤: 首先,确保你已经安装了TBEL引擎,并且熟悉其使用方法和配置。 接下来,进入ThingsBoard的代码库,找到与Nashorn引擎相关的文件。这些文件通常在源码的JavaScript解释器部分。 打开这些文件,并找到所有与Nashorn引擎相关的代码段。 将这些代码替换为TBEL引擎的相应代码。确保你按照TBEL引擎的规范编写这些代码,以确保其正确性和兼容性。 保存并编译修改后的代码,并确保没有任何错误或警告。 运行经过修改的ThingsBoard实例,并确保一切正常。 进行详尽的测试,确保所有相关的功能和模块都能正常工作,并检查是否有任何性能或稳定性问题。 如果出现问题,尝试修复或重新审查代码,并进行进一步的测试,直到问题完全解决。 最后,将已经替换了Nashorn引擎代码库重新发布,以便其它开发人员也可以使用其中的TBEL引擎。 总之,替换ThingsBoard旧版本中的Nashorn引擎为TBEL引擎需要逐一修改相关代码,并确保新引擎的正确性和兼容性。这样做可以提供更好的性能和稳定性,并为以后的开发和维护工作提供便利。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值