Java规则引擎与其API(JSR-94)

时间  2019-11-17
标签 java 规则 引擎 与其 api jsr 栏目 Java 繁體版
原文   原文链接

复杂企业级项目的开发以及其中随外部条件 不断变化的业务规则(business logic),迫切须要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其余统一的地方，让它们能在运行时（即商 务时间）能够动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。 html

本文第一部分简要介绍了 规则引擎的产生背景和基于规则的专家系统，第二部分介绍了什么是规则引擎及其架构和算法，第三部分介绍了商业产品和开源项目实现等各类Java规则引擎， 第四部分对Java规则引擎API（JSR-94）做了详细介绍，讲解了其体系结构，管理API和运行时API及相关安全问题，第五部分则对规则语言及其 标准化做了探讨，第六部分给出了一个使用Java规则引擎API的简单示例，第七部分给予小结和展望。 java

一、 介绍

1.1 规则引擎产生背景

企 业管理者对企业级IT系统的开发有着以下的要求：(1)为提升效率，管理流程必须自动化，即便现代商业规则异常复杂(2)市场要求业务规则常常变化，IT 系统必须依据业务规则的变化快速、低成本的更新(3)为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不须要程序开发人员参与。 程序员

而 项目开发人员则碰到了如下问题:(1)程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型(2)软件工程要求从需求->设计 ->编码，然而业务规则经常在需求阶段可能尚未明确，在设计和编码后还在变化，业务规则每每嵌在系统各处代码中(3)对程序员来讲，系统已经维 护、更新困难，更不可能让业务人员来管理。 算法

基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。下面简要介绍一下基于规则的专家系统。 数据库

1.2 基于规则的专家系统(RBES)

专家系统是人工智能的一个分支，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证实它的推理结论。专家系统有不少分类：神经网络、基于案例推理和基于规则系统等。 编程

RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine（推理引擎）。它们的结构以下所示： api

图1.基于规则的专家系统组成
图1.基于规则的专家系统组成

如 上图所示，推理引擎包括三部分：Pattern Matcher、Agenda和Execution Engine。Pattern Matcher什么时候执行哪一个规则；Agenda管理PatternMatcher挑选出来的规则的执行次序；Execution Engine负责执行规则和其余动做。 安全

推理引擎经过决定哪些规则知足事实或目标，并授予规则优先级，知足事实或目标的规则被加入议程。 存在二者推理方式：演绎法（Forward-Chaining正向链）和概括法（Backward-Chaining反向链）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动做）。而概括法则是从假设出发，不断地寻找符合假设的事实。 服务器

回页首 网络

二、 规则引擎

2.1 业务规则

一 个业务规则包含一组条件和在此条件下执行的操做，它们表示业务规则应用程序的一段业务逻辑。业务规则一般应该由业务分析人员和策略管理者开发和修改，但有 些复杂的业务规则也能够由技术人员使用面向对象的技术语言或脚原本定制。业务规则的理论基础是:设置一个或多个条件，当知足这些条件时会触发一个或多个操 做。

2.2 规则引擎

什么是规则引擎？规则引擎是如何执行规则的？这能够称之为"什么"与"如 何"的问题。到底规则引擎是什么仍是目前业界一个比较有争议的问题，在JSR-94种也几乎没有定义。能够这样认为充分定义和解决了"如何"的问题，"什 么"问题本质上也迎刃而解。也许这又是一种"先有蛋仍是先有鸡"哲学争论。从此标准规则语言的定义和推出及相关标准的制定应该能够给这样的问题和争论划上 一个句号。本文中，暂且这样述说什么是规则引擎：规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出 来，并使用预约义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据规则作出业务决策。

2.3 规则引擎的使用方式

由 于规则引擎是软件组件，因此只有开发人员才可以经过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含如下几种API：加载和卸载规则集的 API；数据操做的API；引擎执行的API。开发人员在程序中使用规则引擎基本遵循如下5个典型的步骤：建立规则引擎对象；向引擎中加载规则集或更换规 则集；向引擎提交须要被规则集处理的数据对象集合；命令引擎执行;导出引擎执行结果，从引擎中撤出处理过的数据。使用了规则引擎以后，许多涉及业务逻辑的 程序代码基本被这五个典型步骤所取代。

一个开放的业务规则引擎应该能够"嵌入"在应用程序的任何位置，不一样位置的规则引擎可使用不一样的规则集，用于处理不一样的数据对象。此外，对使用引擎的数量没有限制。

2.4 规则引擎架构与推理

规则引擎的架构以下图所示：

图2. 业务规则引擎架构
图2. 业务规则引擎架构

规 则引擎的推理步骤以下：a. 将初始数据（fact）输入至工做内存(Working Memory)。b. 使用Pattern Matcher将规则库(Rules repository)中的规则（rule）和数据（fact）比较。c. 若是执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。d. 解决冲突，将激活的规则按顺序放入Agenda。e. 执行Agenda中的规则。重复步骤b至e，直到执行完毕Agenda中的全部规则。

任何一个规则引擎都须要很好地解决规则的推理机制和规则条件匹配的效率问题。

当 引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，因为规则的执行部分可能会改变工做区的数据对象，从而会使队列中的某些规则执行实例因 为条件改变而失效，必须从队列中撤销，也可能会激活原来不知足条件的规则，生成新的规则执行实例进入队列。因而就产生了一种"动态"的规则执行链，造成规 则的推理机制。这种规则的"链式"反应彻底是由工做区中的数据驱动的。

规则条件匹配的效率决定了引擎的性能，引擎须要迅速测试工做区中的 数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。

2.5 规则引擎的算法

大 部分规则引擎产品的算法，基本上都来自于Dr. Charles Forgy在1979年提出的RETE算法及其变体，Rete算法是目前效率最高的一个Forward-Chaining推理算法，Drools项目是 Rete算法的一个面向对象的Java实现，Rete算法其核心思想是将分离的匹配项根据内容动态构造匹配树，以达到显著下降计算量的效果。详情请见 CIS587:The RETE Algorithm，The Rete Algorithm，RETE演算法，《专家系统原理与编程》中第11章等。

回页首

三、 Java规则引擎

目前主流的规则引擎组件可能是基于Java和C++程序语言环境，已经有多种Java规则引擎商业产品与开源项目的实现，其中有的已经支持JSR94，有的正朝这个方向作出努力，列出以下：

3.1 Java规则引擎商业产品

Java规则引擎商业产品主要有（Jess不是开源项目，它能够免费用于学术研究，但用于商业用途则要收费）：

3.2 Java规则引擎开源项目

开源项目的实现主要包括：

Drools - Drools规则引擎应用Rete算法的改进形式Rete-II算法。从内部机制上讲，它使用了和Forgy的算法相同的概念和方法，可是增长了可与面向对象语言无缝链接的节点类型。

Mandarax 基于反向推理（概括法）。可以较容易地实现多个数据源的集成。例如，数据库记录能方便地集成为事实集(facts sets)，reflection用来集成对象模型中的功能。目前不支持JSR 94

OFBiz Rule Engine - 支持概括法(Backward chaining).最初代码基于Steven John Metsker的"Building Parsers in Java"，不支持JSR 94

JLisa - JLisa是用来构建业务规则的强大框架，它有着扩展了LISP优秀特点的优势,比Clips还要强大.这些特点对于多范例软件的开发是相当重要的.支持JSR 94

其 它的开源项目实现有诸如Algernon, TyRuBa, JTP, JEOPS, InfoSapient, RDFExpert, Jena 2, Euler, JLog, Pellet OWL Reasoner, Prova, OpenRules, SweetRules, JShop2等等。

回页首

四、 Java规则引擎API(JSR-94)

4.1 简介

过 去大部分的规则引擎开发并无规范化，有其自有的API，这使得其与外部程序交互集成不够灵活。转而使用另一种产品时每每意味须要重写应用程序逻辑和 API调用，代价较大。规则引擎工业中标准的缺少成为使人关注的重要方面。2003年11月定稿并于2004年8月最终发布的JSR 94（Java规则引擎API）使得Java规则引擎的实现得以标准化。

Java规则引擎API由javax.rules包定义，是访问规 则引擎的标准企业级API。Java规则引擎API容许客户程序使用统一的方式和不一样厂商的规则引擎产品交互，就像使用JDBC编写独立于厂商访问不一样的 数据库产品同样。Java规则引擎API包括建立和管理规则集合的机制，在Working Memory中添加，删除和修改对象的机制，以及初始化，重置和执行规则引擎的机制。

4.2 简介Java规则引擎API体系结构

Java规则引擎API分为两个主要部分:运行时客户API(the Runtime client API)和规则管理API(the rules administration API)。

4.2.1规则管理API

规 则管理API在javax.rules.admin中定义,包括装载规则以及与规则对应的动做(执行集 execution sets)以及实例化规则引擎。规则能够从外部资源中装载,好比说URI,Input streams, XML streams和readers等等.同时管理API提供了注册和取消注册执行集以及对执行集进行维护的机制。使用admin包定义规则有助于对客户访问 运行规则进行控制管理,它经过在执行集上定义许可权使得未经受权的用户没法访问受控规则。

管理API使用类 RuleServiceProvider来得到规则管理(RuleAdministrator)接口的实例.规则管理接口提供方法注册和取消注册执行集. 规则管理器(RuleAdministrator)提供了本地和远程的RuleExecutionSetProvider.在前面已提 及,RuleExecutionSetProvider负责建立规则执行集.规则执行集能够从如XML streams, input streams等来源中建立.这些数据来源及其内容经聚集和序列化后传送到远程的运行规则引擎的服务器上.大多数应用程序中,远程规则引擎或远程规则数据 来源的状况并很少见.为了不这些状况中的网络开销,API规定了能够从运行在同一JVM中规则库中读取数据的本地 RuleExecutionSetProvider.

规则执行集接口除了拥有可以得到有关规则执行集的方法,还有可以检索在规则执行集中定义的全部规则对象.这使得客户可以知道规则集中的规则对象而且按照本身须要来使用它们。

4.2.2 运行时API

运行时API定义在javax.rules包中,为规则引擎用户运行规则得到结果提供了类和方法。运行时客户只能访问那些使用规则管理API注册过的规则，运行时API帮助用户得到规则对话而且在这个对话中执行规则。

运 行时API提供了对厂商规则引擎API实现的相似于JDBC的访问方法.规则引擎厂商经过类RuleServiceProvider(类 RuleServiceProvider提供了对具体规则引擎实现的运行时和管理API的访问)将其规则引擎实现提供给客户,并得到 RuleServiceProvider惟一标识规则引擎的URL.

URL推荐标准用法是使用类 似"com.mycompany.myrulesengine.rules.RuleServiceProvider"这样的Internet域名空间, 这将有助于访问URL的惟一性.类RuleServiceProvider内部实现了规则管理和运行时访问所需的接口.全部的 RuleServiceProvider要想被客户所访问都必须用RuleServiceProviderManager进行注册。注册方式相似于 JDBC API的DriverManager和Driver。

运行时接口是运行时API的关键部分.运行时接口提供了用于建立规则会话 (RuleSession)的方法,规则会话如前所述是用来运行规则的.运行时API同时也提供了访问在service provider注册过的全部规则执行集(RuleExecutionSets).规则会话接口定义了客户使用的会话的类型,客户根据本身运行规则的方式 能够选择使用有状态会话或者无状态会话。

无状态会话的工做方式就像一个无状态会话bean.客户能够发送单个输入对象或一列对象来得到输出 对象.当客户须要一个与规则引擎间的专用会话时,有状态会话就颇有用.输入的对象经过addObject() 方法能够加入到会话当中.同一个会话当中能够加入多个对象.对话中已有对象能够经过使用updateObject()方法获得更新.只要客户与规则引擎间 的会话依然存在,会话中的对象就不会丢失。

RuleExecutionSetMetaData接口提供给客户让其查找规则执行集的元数据(metadata).元数据经过规则会话接口(RuleSession Interface)提供给用户。

使用运行时Runtime API的代码片段以下所示: 

RuleServiceProvider ruleProvider = 
RuleServiceProviderManager.getRuleServiceProvider
("com.mycompany.myrulesengine.rules. RuleServiceProvider");   
RuleRuntime ruleRuntime = ruleProvider.getRuleRuntime();
StatelessRuleSession ruleSession = (StatelessRuleSession)  
ruleRuntime.createRuleSession(ruleURL, null, RuleRuntime.STTELESS_SESSION_TYPE);
List inputRules = new ArrayList();
inputRules.add(new String("Rule 1"));
inputRules.add(new Integer(1));
List resultRules = ruleSession.executeRules(inputRules);

4.3 Java规则引擎API安全问题

规 则引擎API将管理API和运行时API加以分开,从而为这些包提供了较好粒度的安全控制.规则引擎API并无提供明显的安全机制,它能够和J2EE规 范中定义的标准安全API联合使用.安全能够由如下机制提供,如Java authentication and authorization service (JAAS),the Java cryptography extension (JCE),Java secure Socket Extension (JSSE),或者其它定制的安全API.JAAS能被用来定义规则执行集的许可权限,从而只有受权用户才能访问。

4.4 异常与日志

规则引擎API定义了javax.rules.RuleException做为规则引擎异常层次的根类.全部其它异常都继承于这个根类.规则引擎中定义的异常都是受控制的异常(checked exceptions),因此捕获异常的任务就交给了规则引擎。 规则引擎API没有提供明确的日志机制,可是它建议将Java Logging API用于规则引擎API。

4.5 JSR 94 小结

JSR 94 为规则引擎提供了公用标准API,仅仅为实现规则管理API和运行时API提供了指导规范,并无提供规则和动做该如何定义以及该用什么语言定义规则,也 没有为规则引擎如何读和评价规则提供技术性指导.JSR 94规范将上述问题留给了规则引擎的厂商.在下一节我将简要介绍一下规则语言。

回页首

五、 规则语言

JSR 94中没有涉及用来建立规则和动做的语言.规则语言是规则引擎应用程序的重要组成部分,全部的业务规则都必须用某种语言定义而且存储于规则执行集中,从而规则引擎能够装载和处理他们。

由 于没有关于规则如何定义的公用规范,市场上大多数流行的规则引擎都有其本身的规则语言，目前便有许多种规则语言正在应用，所以，当须要将应用移植到其余的 Java规则引擎实现时，可能须要变换规则定义，如将Drools私有的DRL规则语言转换成标准的ruleML，Jess规则语言转换成ruleML 等。这个工做通常由XSLT转换器来完成。

规则语言的详情这里不做详细介绍，名称及其网址列出以下： 

Rule Markup language (RuleML)                        http://www.ruleml.org/
Simple Rule Markup Language (SRML)                    http://xml.coverpages.org/srml.html
Business Rules Markup Language (BRML)                    http://xml.coverpages.org/brml.html
SWRL: A Semantic Web Rule Language Combining OWL and RuleML   http://www.daml.org/2003/11/swrl/

多 种规则语言的使用使得不一样规则引擎实现之间的兼容性成为问题.通用的规则引擎API或许能够减轻不一样厂家API之间的问题,但公用规则语言的缺少将仍然阻 碍不一样规则引擎实现之间的互操做性.尽管业界在提出公用规则语言上作出了一些努力, 好比说RuleML,SRML的出现,但距离得到绝大部分规则引擎厂商赞成的公用标准还有很长的路要走。

回页首

六、 Java规则引擎API使用示例

6.1 设置规则引擎

Java 规则引擎的管理活动阶段开始于查找一个合适的javax.rules.RuleServiceProvider对象，这个对象是应用程序访问规则引擎的入 口。在J2EE环境中，你可能能够经过JNDI得到RuleServiceProvider。不然，你可使用 javax.rules.RuleServiceProviderManager类： 

javax.rules.RuleServiceProviderManager class: 
           String implName = "org.jcp.jsr94.ri.RuleServiceProvider";
           Class.forName(implName);
           RuleServiceProvider 
serviceProvider = RuleServiceProviderManager.getRuleServiceProvider(implName);

拥 有了RuleServiceProvider对象，你就能够得到一个javax.rules.admin.RuleAdministrator类。从 RuleAdministrator类中，你能够获得一个RuleExecutionSetProvider，从类名能够知道，它用于建立 javax.rules.RuleExecutionSets对象。RuleExecutionSet基本上是一个装入内存的，准备好执行的规则集合。

包 javax.rules.admin包括两个不一样的RuleExecutionSetProvider类。 RuleExecutionSetProvider类自己包括了从Serializable对象建立RuleExecutionSets的方法，所以在规 则引擎位于远程服务器的状况下，仍然可使用RuleExecutionSetProvider类，构造器的参数能够经过RMI来传递。另外一个类是 LocalRuleExecutionSetProvider，包含了其余方法，用于从非Serializable资源（如 java.io.Reader－本地文件）建立RuleExectionSets。假设拥有了一个RuleServiceProvider对象，你能够从 本地文件rules.xml文件建立一个RuleExectionSet对象。如如下的代码所示： 

RuleAdministrator admin = serviceProvider.getRuleAdministrator();
          HashMap properties = new HashMap();
          properties.put("name", "My Rules");
          properties.put("description", "A trivial rulebase");
          FileReader reader = new FileReader("rules.xml");
          RuleExecutionSet ruleSet = null;
          try {
               LocalRuleExecutionSetProvider lresp =
               admin.getLocalRuleExecutionSetProvider(properties);
               ruleSet = lresp.createRuleExecutionSet(reader, properties);
          } finally {
               reader.close();
          }

接下来，你可使用RuleAdministrator注册得到的 RuleExecutionSet，并给它分配一个名称。在运行时，你能够用同一个名称建立一个RuleSession；该RuleSession使用了 这个命名的RuleExecutionSet。参见下面的用法：admin.registerRuleExecutionSet("rules", ruleSet, properties);

6.2 执行规则引擎

在运行时阶段，你能够参见一 个RuleSession对象。RuleSession对象基本上是一个装载了特定规则集合的规则引擎实例。你从RuleServiceProvider 获得一个RuleRuntime对象，接下来，从javax.rules.RuleRuntime获得RuleSession对象。

RuleSession 分为两类：stateful和stateless。它们具备不一样的功能。StatefulRuleSession的Working Memory可以在多个方法调用期间保存状态。你能够在多个方法调用期间在Working Memory中加入多个对象，而后执行引擎，接下来还能够加入更多的对象并再次执行引擎。相反，StatelessRuleSession类是不保存状态 的，为了执行它的executeRules方法，你必须为Working Memory提供全部的初始数据，执行规则引擎，获得一个内容列表做为返回值。

下 面的例子中，咱们建立一个StatefulRuleSession实例，添加两个对象（一个Integer和一个String）到Working Memory，执行规则，而后获得Working Memory中全部的内容，做为java.util.List对象返回。最后，咱们调用release方法清理RuleSession： 

RuleRuntime runtime = rsp.getRuleRuntime();
         StatefulRuleSession session = (StatefulRuleSession)
         runtime.createRuleSession("rules", properties,
         RuleRuntime.STATEFUL_SESSION_TYPE);
         session.addObject(new Integer(1));
         session.addObject("A string");
         session.executeRules();
         List results = session.getObjects();
         session.release();

回页首

七、 结束语

Java 规则引擎API(JSR-94)容许客户程序使用统一的方式和不一样厂商的规则引擎产品交互，必定程度上给规则引擎厂商提供了标准化规范。但其几乎没有定义 什么是规则引擎，固然也没有深刻到规则是如何构建和操纵的，规则调用的效用，规则与Java语言的绑定等方面。而且JSR-94在对J2EE的支持上也不 足。规则语言的标准化，JSR-94的进一步的充实深化都有待研究。

参考资料

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程