等考二级JAVA：Java规则引擎工作原理及应用

　　3、规则引擎的工作机制

　　下面专门研究规则引擎的内部处理过程。如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定义顺序检查信息元所带规则集中的规则。如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下一条规则。如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中的所有规则执行完毕后，信息元将被销毁，然后从队列管理器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作(Discard Action)和包含动作(Include Action)。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包含动作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。这一过程将递归进行。

　　Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。Java规则引擎对提交给引擎的Java数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般来讲，Java规则引擎内部由下面几个部分构成：工作内存(Working Memory)即工作区，用于存放被引擎引用的数据对象集合;规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。Java规则引擎的结构示意图如图4所示。

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

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

　　Java规则引擎API——JSR-94

　　为了使规则引擎技术标准化，Java社区制定了Java规则引擎API(JSR94)规范。它为Java平台访问规则引擎定义了一些简单的API。

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

　　1、Java规则引擎API体系结构

　　Java规则引擎API主要由两大类API组成： 规则管理API(The Rules Administrator API)和运行时客户API(The Runtime Client API)。

　　1)规则管理API

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

　　规则管理API使用类RuleServiceProvider来获得规则管理器(RuleAdministrator)接口的实例。该接口提供方法注册和取消注册执行集。规则管理器提供了本地和远程的RuleExecutionSetProvider，它负责创建规则执行集(RuleExecutionSet)。规则执行集可以从如XML streams， binary streams等来源中创建。这些数据来源及其内容经汇集和序列化后传送到远程的运行规则引擎的服务器上。在大多数应用程序中，远程规则引擎或远程规则数据来源的情况并不多。为了避免这些情况中的网络开销，API规定了可以从运行在同一JVM中规则库中读取数据的本地RuleExecutionSetProvider。规则执行集接口除了拥有能够获得有关规则执行集的方法，还有能够检索在规则执行集中定义的所有规则对象。这使得客户能够知道规则集中的规则对象并且按照自己需要来使用它们。

　　2)运行时客户API

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

　　运行时API提供了对厂商规则引擎API的访问方法，这类似于JDBC。类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)提供给用户。

　　2、Java规则引擎API安全问题

　　规则引擎API将管理API和运行时API加以分开，从而为这些包提供了较好粒度的安全控制。规则引擎API并没有提供明显的安全机制，它可以和J2EE规范中定义的标准安全API联合使用。安全可以由以下机制提供，如Java 认证和授权服务 (JAAS)，Java加密扩展(JCE)，Java安全套接字扩展(JSSE)，或者其它定制的安全API。使用JAAS可以定义规则执行集的许可权限，从而只有授权用户才能访问。

　　3、异常与日志

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

　　JSR 94 为规则引擎提供了公用标准API，仅仅为实现规则管理API和运行时API提供了指导规范，并没有提供规则和动作该如何定义以及该用什么语言定义规则，也没有为规则引擎如何读和评价规则提供技术性指导。