规则引擎原理
本文对Java规则引擎与其API(JSR-94)及相关实现做了较详细的介绍，对其体系结构和API应用有较详尽的描述，并指出Java规则引擎,规则语言，JSR-94的相互关系,以及JSR-94的不足之处和展望。
复杂企业级项目的开发以及其中随外部条件不断变化的业务规则(businesslogic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。
本文第一部分简要介绍了规则引擎的产生背景和基于规则的专家系统，
第二部分介绍了什么是规则引擎及其架构和算法，
第三部分介绍了商业产品和开源项目实现等各种Java规则引擎，
第四部分对Java规则引擎API（JSR-94）作了详细介绍，讲解了其体系结构，管理API 和运行时API及相关安全问题，
第五部分则对规则语言及其标准化作了探讨，
第六部分给出了一个使用Java规则引擎API的简单示例，
第七部分给予小结和展望。
1.介绍
1.1. 规则引擎产生背景
企业管理者对企业级IT系统的开发有着如下的要求：
(1)为提高效率，管理流程必须自动化，即使现代商业规则异常复杂
(2)市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更新
(3)为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序开发人员参与。
而项目开发人员则碰到了以下问题:
(1)程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型
(2)软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中
(3)对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。
基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。下面简要介绍一下基于规则的专家系统。
1.2. 基于规则的专家系统(RBES)
专家系统是人工智能的一个分支，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。专家系统有很多分类：神经网络、基于案例推理和基于规则系统等。
RBES包括三部分：RuleBase（knowledgebase）、WorkingMemory（factbase）和InferenceEngine（推理引擎）。它们的结构如下所示：
图1.基于规则的专家系统组成
如上图所示，推理引擎包括三部分：PatternMatcher、Agenda(议程)和ExecutionEngine。
?PatternMatcher何时执行哪个规则；
?Agenda管理PatternMatcher挑选出来的规则的执行次序；
?ExecutionEngine负责执行规则和其他动作。
推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。存在两者推理方式：演绎法（Forward-Chaining正向链）和归纳法（Backward-Chaining反向链）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是从假设出发，不断地寻找符合假设的事实。
(这就是规则引擎的原理)
2.规则引擎
2.1. 业务规则
一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。业务规则的理论基础是:设置一个或多个条件，当满足这些条件时会触发一个或多个操作。
2.2. 规则引擎
规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据规则做出业务决策。
2.3. 规则引擎的使用方式
由于规则引擎是软件组件，所以只有开发人员才能够通过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含以下几种API：
?加载和卸载规则集的API；
?数据操作的API；
?引擎执行的API。
开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤：
?创建规则引擎对象；
?向引擎中加载规则集或更换规则集；
?向引擎提交需要被规则集处理的数据对象集合；
?命令引擎执行;
?导出引擎执行结果，从引擎中撤出处理过的数据。
使用了规则引擎之后，许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代。
一个开放的业务规则引擎应该可以"嵌入"在应用程序的任何位置，不同位置的规则引擎可以使用不同的规则集，用于处理不同的数据对象。此外，对使用引擎的数量没有限制。
2.4. 规则引擎架构
规则引擎的架构如下图所示：
图2.业务规则引擎架构
规则引擎的推理步骤如下：
?将初始数据（fact）输入至工作内存(WorkingMemory)。
?使用PatternMatcher将规则库(Rulesrepository)中的规则（rule）和数据（fact）比较。
?如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲
突集合。
?解决冲突，将激活的规则按顺序放入Agenda。
?执行Agenda中的规则。重复步骤b至e，直到执行完毕Agenda中的所有规则。
2.5. 规则引擎的推理
任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。
当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种"动态"的规则执行链，形成规则的推理机制。这种规则的"链式"反应完全是由工作区中的数据驱动的。
规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的CharlesL.Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。
2.6. 规则引擎的算法
大部分规则引擎产品的算法，基本上都来自于Dr.CharlesForgy在1979年提出的Rete 算法及其变体，Rete算法是目前效率最高的一个Forward-Chaining推理算法，Drools项目是Rete算法的一个面向对象的Java实现，Rete算法其核心思想是将分离的匹配项根据内容动态构造匹配树，以达到显著降低计算量的效果。
3.Java规则引擎
目前主流的规则引擎组件多是基于Java和C++程序语言环境，已经有多种Java规则引擎商业产品与开源项目的实现，其中有的已经支持JSR94，有的正朝这个方向做出努力，列出如下：
3.1. Java规则引擎商业产品
Java规则引擎商业产品主要有（Jess不是开源项目，它可以免费用于学术研究，但用于商业用途则要收费）：
3.2. Java规则引擎开源项目
开源项目的实现主要包括：
Drools-Drools规则引擎应用Rete算法的改进形式Rete-II算法。从内部机制上讲，它使用了和Forgy的算法相同的概念和方法，但是增加了可与面向对象语言无缝连接的节点类型。
Mandarax基于反向推理（归纳法）。能够较容易地实现多个数据源的集成。例如，数据库记录能方便地集成为事实集(factssets)，reflection用来集成对象模型中的功能。目前不支持JSR94
OFBizRuleEngine-支持归纳法(Backwardchaining).最初代码基于StevenJohnMetsker的"BuildingParsersinJava"，不支持JSR94
JLisa-JLisa是用来构建业务规则的强大框架，它有着扩展了LISP优秀特色的优点,比
Clips还要强大.这些特色对于多范例软件的开发是至关重要的.支持JSR94
其它的开源项目实现有诸如Algernon, TyRuBa, JTP, JEOPS, Info SAP ient, RDFExpert, Jena2, Euler, JLog, PelletOWLReasoner, Prova, OpenRules, SweetRules, JShop2等等。
4.Java规则引擎API(JSR-94)
4.1. 简介
过去大部分的规则引擎开发并没有规范化，有其自有的API，这使得其与外部程序交互集成不够灵活。转而使用另外一种产品时往往意味需要重写应用程序逻辑和API调用，代价较大。规则引擎工业中标准的缺乏成为令人关注的重要方面。2003年11月定稿并于2004年8月最终发布的JSR94（Java规则引擎API）使得Java规则引擎的实现得以标准化。
Java规则引擎API由javax.rules包定义，是访问规则引擎的标准企业级API。Java规则引擎API允许客户程序使用统一的方式和不同厂商的规则引擎产品交互，就像使用JDBC编写独立于厂商访问不同的数据库产品一样。Java规则引擎API包括创建和管理规则集合的机制，在WorkingMemory中添加，删除和修改对象的机制，以及初始化，重置和执行规则引擎的机制。
4.2. 简介Java规则引擎API体系结构
Java规则引擎API分为两个主要部分:运行时客户
API(theRuntimeclientAPI)和规则管理API(therulesadministrationAPI)。4.2.1.规则管理API
规则管理API在javax.rules.admin中定义,包括装载规则以及与规则对应的动作(执行集executionsets)以及实例化规则引擎。规则可以从外部资源中装载,比如说URI,Inputstreams,XMLstreams和readers等等.同时管理API提供了注册和取消注册执行集以及对执行集进行维护的机制。使用admin包定义规则有助于对客户访问运行规则进行控制管理,它通过在执行集上定义许可权使得未经授权的用户无法访问受控规则。
管理API使用类RuleServiceProvider来获得规则管理(RuleAdministrator)接口的实例.规则管理接口提供方法注册和取消注册执行集.规则管理器(RuleAdministrator)提供了本地和远程的RuleExecutionSetProvider.在前面已提及,RuleExecutionSetProvider负责创建规则执行集.规则执行集可以从如XMLstreams,inputstreams等来源中创建.这些数据来源及其内容经汇集和序列
化后传送到远程的运行规则引擎的服务器上.大多数应用程序中,远程规则引擎或远程规则数据来源的情况并不多见.为了避免这些情况中的网络开销,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进行注册。注册方式类似于JDBCAPI的DriverManager和Driver。
运行时接口是运行时API的关键部分.运行时接口提供了用于创建规则会话(RuleSession)的方法,规则会话如前所述是用来运行规则的.运行时API同时也提供了访问在serviceprovider注册过的所有规则执行集(RuleExecutionSets).规则会话接口定义了客户使用的会话的类型,客户根据自己运行规则的方式可以选择使用有状态会话或者无状态会话。
无状态会话的工作方式就像一个无状态会话bean.客户可以发送单个输入对象或一列对象来获得输出对象.当客户需要一个与规则引擎间的专用会话时,有状态会话就很有用.输入的对象通过addObject()方法可以加入到会话当中.同
一个会话当中可以加入多个对象.对话中已有对象可以通过使用updateObject()方法得到更新.只要客户与规则引擎间的会话依然存在,会话中的对象就不会丢失。
RuleExecutionSetMetaData接口提供给客户让其查找规则执行集的元数据(metadata).元数据通过规则会话接口(RuleSessionInterface)提供给用户。
使用运行时RuntimeAPI的代码片断如下所示:
RuleServiceProviderruleProvider=RuleServiceProviderManager.getRuleSer viceProvider
("com.mycompany.myrulesengine.rules.RuleServiceProvider"); RuleRuntimeruleRuntime=ruleProvider.getRuleRuntime(); StatelessRuleSessionruleSession=(StatelessRuleSession)ruleRuntime.cre ateRuleSession(ruleURL,
null,RuleRuntime.STTELESS_SESSION_TYPE);
ListinputRules=newArrayList();
inputRules.add(newString("Rule1"));
inputRules.add(newInteger(1));
ListresultRules=ruleSession.executeRules(inputRules);
4.3. Java规则引擎API安全问题
规则引擎API将管理API和运行时API加以分开,从而为这些包提供了较好粒度的安全控制.规则引擎API并没有提供明显的安全机制,它可以和J2EE规范中定义的标准安全API联合使用.安全可以由以下机制提供,如Javaauthenticationandauthorizationservice(JAAS),theJavacryptographyex tension(JCE),Javasecure Socket Extension(JSSE),或者其它定制的安全API.JAAS能被用来定义规则执行集的许可权限,从而只有授权用户才能访问。
4.4. 异常与日志
规则引擎API定义了javax.rules.RuleException作为规则引擎异常层次的根类.所有其它异常都继承于这个根类.规则引擎中定义的异常都是受控制的异常(checkedexceptions),所以捕获异常的任务就交给了规则引擎。规则引擎API 没有提供明确的日志机制,但是它建议将JavaLoggingAPI用于规则引擎API。
4.5. JSR94小结
JSR94为规则引擎提供了公用标准API,仅仅为实现规则管理API和运行时API提供了指导规范,并没有提供规则和动作该如何定义以及该用什么语言定义规则,也没有为规则引擎如何读和评价规则提供技术性指导.JSR94规范将上述问题留给了规则引擎的厂商.在下一节我将简要介绍一下规则语言。
5.规则语言
JSR94中没有涉及用来创建规则和动作的语言.规则语言是规则引擎应用程序的重要组成部分,所有的业务规则都必须用某种语言定义并且存储于规则执行集中,从而规则引擎可以装载和处理他们。
由于没有关于规则如何定义的公用规范,市场上大多数流行的规则引擎都有其自己的规则语言，目前便有许多种规则语言正在应用，因此，当需要将应用移植到其他的Java规则引擎实现时，可能需要变换规则定义，如将Drools私有的DRL规则语言转换成标准的ruleML，Jess规则语言转换成ruleML等。这个工作一般由XSLT转换器来完成。
规则语言的详情这里不作详细介绍，名称及其网址列出如下：
RuleMarkuplanguage(RuleML)
https://www.doczj.com/doc/9c13520393.html,/SimpleRuleMarkupLanguage(SRML)
http://XML.cov ERP https://www.doczj.com/doc/9c13520393.html,/srml.htmlBusinessRulesMarkupLanguage(BRML)
https://www.doczj.com/doc/9c13520393.html,/brml.htmlSWRL:ASemantic Web RuleLanguageCombi ningOWLandRuleML
https://www.doczj.com/doc/9c13520393.html,/2003/11/swrl/
多种规则语言的使用使得不同规则引擎实现之间的兼容性成为问题.通用的规则引擎API或许可以减轻不同厂家API之间的问题,但公用规则语言的缺乏将仍然阻碍不同规则引擎实现之间的互操作性.尽管业界在提出公用规则语言上做出了一些努力,比如说RuleML,SRML的出现,但距离获得绝大部分规则引擎厂商同意的公用标准还有很长的路要走。
6.Java规则引擎API使用示例
6.1. 设置规则引擎
Java规则引擎的管理活动阶段开始于查找一个合适的
javax.rules.RuleServiceProvider对象，这个对象是应用程序访问规则引擎的入口。在J2EE环境中，你可能可以通过JNDI获得RuleServiceProvider。否则，你可以使用javax.rules.RuleServiceProviderManager类：
javax.rules.RuleServiceProviderManagerclass:
StringimplName="org.jcp.jsr94.ri.RuleServiceProvider";
Class.forName(implName);
RuleServiceProviderserviceProvider=RuleServiceProviderManager.getRule ServiceProvider(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对象。如以下的代码所示：
RuleAdministratoradmin=serviceProvider.getRuleAdministrator(); HashMapproperties=newHashMap();
properties.put("name","MyRules");
properties.put("description","Atrivialrulebase");
FileReaderreader=newFileReader("rules.xml"); RuleExecutionSetruleSet=null;
try{
LocalRuleExecutionSetProviderlresp=admin.getLocalRuleExecutionSetProv ider(properties);
ruleSet=lresp.createRuleExecutionSet(reader,properties);
}finally{
reader.close();
}
接下来，你可以使用RuleAdministrator注册获得的RuleExecutionSet，并给它分配一个名称。在运行时，你可以用同一个名称创建一个RuleSession；该RuleSession使用了这个命名的RuleExecutionSet。参见下面的用法：admin.re GIS terRuleExecutionSet("rules",ruleSet,properties);
6.2. 执行规则引擎
在运行时阶段，你可以参见一个RuleSession对象。RuleSession对象基本上是一个装载了特定规则集合的规则引擎实例。你从RuleServiceProvider得到一个RuleRuntime对象，接下来，从javax.rules.RuleRuntime得到RuleSession 对象。
RuleSession分为两类：stateful和stateless。它们具有不同的功能。StatefulRuleSession的WorkingMemory能够在多个方法调用期间保存状态。你
可以在多个方法调用期间在WorkingMemory中加入多个对象，然后执行引擎，接下来还可以加入更多的对象并再次执行引擎。相反，StatelessRuleSession类是不保存状态的，为了执行它的executeRules方法，你必须为WorkingMemory 提供所有的初始数据，执行规则引擎，得到一个内容列表作为返回值。
下面的例子中，我们创建一个StatefulRuleSession实例，添加两个对象（一个Integer和一个String）到WorkingMemory，执行规则，然后得到WorkingMemory中所有的内容，作为java.util.List对象返回。最后，我们调用release方法清理RuleSession：
RuleRuntimeruntime=rsp.getRuleRuntime();
StatefulRuleSessionsession=(StatefulRuleSession)runtime.createRuleSes sion("rules",
properties,RuleRuntime.STATEFUL_SESSION_TYPE);
session.addObject(newInteger(1));
session.addObject("Astring");
session.executeRules();
Listresults=session.getObjects();
session.release();
7.结束语
Java规则引擎API(JSR-94)允许客户程序使用统一的方式和不同厂商的规则引擎产品交互，一定程度上给规则引擎厂商提供了标准化规范。但其几乎没有定义什么是规则引擎，当然也没有深入到规则是如何构建和操纵的，规则调用的效用，规则与Java语言的绑定等方面。并且JSR-94在对J2EE的支持上也不足。规则语言的标准化，JSR-94的进一步的充实深化都有待研究。
规则引擎在排产系统中的应用
规则引擎排产系统中的应用 排产系统是制造企业ＭＥＳ系统的重要组成部分，对应于生产管理系统的短期计划安排，主要目标是通过良好的作业加工排序，最大限度减少生产过程中的准备时间，优化某一项或几项生产目标，为生产计划的执行和控制提供指导。在不同的问题环境中，排产的优化目标也不同。在生产制造企业中影响排产的因素很多（比如需求变化多、插单多、各条生产线生产能力与特长不同等），因素众多，通常最影响排产计划的进行，降低了生产效率和交货及时性。传统的手工排产已完全不能满足企业多变的需求。另外在不同的环境下，影响排产的规则数量、优先级都会
发生变化。过去排产系统将业务逻辑与主体代码紧耦合，业务规则以： 的形式被硬编码到代码中去，结果是线性、确定的执行路由，所有的约束和判断都按照建模时的约定执行。当业务规则发生变更时，唯一的途径是修改代码。 这种形式无法适应制造企业生产规则的频繁变更，导致排产系统的开发、升级和维护成本急剧增加，甚至排产系统完全无法适应企业的实际需求。因此排产系统在保证对目标优化的前提下，将业务逻辑与主体程序的分离，已成为排产系统首要解决的问题。本文着重阐述通过规则引擎技术将生产规则逻辑从排产系统分离，克服生产规则灵活变更导致排产系统无法适应企业生产策略变更的问题。 目前开源和商业的规则引擎产品有很多，其中开源的以Drools为代表，商业的有ILog，旗正规则引擎（VisualRules）等，本文以商业规则引擎中的旗正规则引擎来说明。说句题外话，开源的产品有开源产品的优点，但是规则引擎作为
一个高端的应用来说，还是希望在售后服务，技术支持等方面能有商业化的保障。 在制造企业中，生产策略的变更非常频繁并且影响排产系统的业务策略很多，而传统的排产系统将业务逻辑与排产逻辑紧密耦合，导致系统的开发，维护都变得异常艰难。因此如何将业务逻辑与主体程序分离，屏蔽业务策略变更对主体程序的影响，则成为排产系统的关键问题。 基于规则引擎的排产系统架构设计的核心是实现业务逻辑与应用程序解耦。它的实现方案可分为以下几个步骤： 1. 生成业务规则业务人员对影响排产的业务策略进行收集，抽象，归纳，按照规则文件格式配置成业务规则。 2. 业务规则管理业务人员通过规则管理平台实现对规则的存储，版本，废弃，冻结等一系列的管理 3. 执行业务规则应用程序中启动规则引擎（服务和接口）解析执行已经编辑配置好的规则文件，然后将结果返回给应用程序。 规则引擎，能够让整个排产系统快速适应企业业务策略的频繁变更，隔离策略变更对应用程序的影响，同时又能与主体程序进行动态通信。主体程序动态感知业务策略的变更，将变更结果推动执行和呈现。
国内外主流工作流引擎及规则引擎分析2013年2月创新研发部
目录 国内外主流工作流引擎及规则引擎分析 (1) 一.背景 (4) 二.原则 (4) 三.工作流功能分析点 (6) 4.1.标准类 (6) 3.1.1BPMN2.0标准支持 (6) 4.2.开发类 (7) 3.1.1业务模型建模工具 (7) 3.1.2工作流建模工具 (7) 3.1.3人工页面生成工具 (8) 3.1.4仿真工具 (9) 4.3.功能类 (9) 4.1.1流程引擎 (9) 4.1.2规则引擎 (10) 4.1.3组织模型与日期 (10) 4.1.4对外API的提供 (11) 4.1.5后端集成/SOA (11) 4.1.6监控功能 (12) 四.中心已有系统工作流功能点分析 (13) 4.1.备付金系统工作流分析 (13) 4.1.1联社备付金调出流程 (13)
4.1.2联社备付金调入流程 (16) 4.1.3资金划入孝感农信通备付金账户业务流程 (18) 4.1.4备付金运用账户开立流程 (20) 4.1.5备付金沉淀资金运用流程 (23) 4.1.6备付金沉淀资金支取流程 (26) 4.2.多介质项目工作流分析 (28) 4.1.1开卡审批流程 (28) 4.3.新一代农信银资金清算系统工作流分析 (29) 4.4.电子商票系统工作流分析 (29) 4.5.OA系统工作流分析 (32) 五.工作流产品分析 (32) 六.分析结论 (44) 4.4.对比 (44) 4.5.建议 (45)
一.背景 目前中心建成的“一大核心系统，七大共享平台”以及OA系统，对工作流应用程度高，但各系统实现工作流程管理没有建立在统一的工作流平台上，导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤，同时还要与多个系统进行交互，因此，为了提高管理效率，降低业务流转时间，同时还要结合农信银中心的总体IT战略规划，备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎，作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求，形成农信银中心工作流平台的发展规划，从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国内外领先的工作流产品和案例，同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品，进行工作流产品选型。 目前国内外的工作流引擎层出不穷，行业标准多种多样，通过对比不同工作流公司产品，本次工作流技术选型决定分析商业工作流引擎4款，开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款，本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主，选型工作将不再单独分析规则
应用业务规则管理技术构建 灵活的BSS/OSS 何仁杰 3G不仅仅是一种新的无线技术，更是一种新的业务平台。许多新业务将随着3G的出现而应运而生。作为运营商，他们很难准确预知未来3G的新业务到底以何种业务策略进行运作，一切将由市场决定。因此一个能够灵活应对策略变化的业务运营支撑系统(BSS/OSS)对运营商来讲至关重要。经验证明，使用传统的系统开发思路和技术已无法满足运营商对灵活性的要求，业务规则管理技术作为一种经过实践考验的技术在灵活性和应对市场变化方面体现出了独特的优势。 四层结构的BSS/OSS 目前，许多BSS/OSS都实现了三层结构，即接入层（包括展现层）、应用逻辑层和数据层。三层结构由于使用了数据库管理系统（DBMS），很好地实现了数据集中管理和数据在应用层上的共享，使新应用的添加和修改比传统方式方便了许多。但是这种三层结构系统在灵活性方面还是存在着瓶颈，主要表现在： 1）业务规则还是驻留在程序中，无法被有效的管理。规则无法被查询、无法被共享。 2）业务规则的实现非常复杂繁琐。几乎很难解决规则之间的复杂关联关系（如互斥、并发、顺序、多选一等）。 3）业务规则的维护十分困难，在程序代码级上的规则维护不仅耗时，而且风险很大。虽然有些系统使用了所谓的参数化和模板化来试图提供灵活性，但经验证明，这种方式的效果依然有限。 4）业务人员无法接触到他们的业务规则。更无从参与业务规则的开发。 由于业务规则在BSS/OSS中是最活跃的元素，为了能够真正实现灵活性，我们必须把业务规则作为一种特殊的“对象”转移到程序之外，在一个特殊的层面，即“业务规则层”上进行管理。这个“业务规则层”结合原来三层结构中的“接入层”、“应用层”和“数据层”就构成了四层结构的 BSS/OSS。 业务规则层与其它层的最大区别在于它完全向精通业务策略的非技术人员开放。过去所有的开发工作都由IT人员承担；现在，通过业务规则层上提供的各种服务(Service)，业务人员可以参与规则的开发和管理。 四层结构的好处不言而喻：它实现了业务规则的集中统一的控制，实现了规则的共享和复用、缩短了的业务策略的定制周期，改变了业务规则的开发方式。这种结构使得运营商们第一次有机会能够把业务规则变化成他们的特殊资产，第一次能够自如地调整他们的运营策略。
ILOG 规则引擎系统运维手册 一、 ILOG 规则引擎系统介绍 ? 为什么使用ILOG 规则引擎系统？ 保险行业是大量业务规则的处理过程，投承保规则、保费计算规则、核保规则、核批规则、费用规则、核赔规则。。。业务规则无所不在，且随着行业监管、市场环境、业务管理等因素不断变化。 业务规则管理混乱、业务规则变更过分依赖技术人员，业务人员无法单独完成业务规则变更，维护成本高昂，由此带来的问题： ? 业务规则变更周期长、成本高 ? 规则重用性差 ? 业务规则知识随着时间被淡忘 基于ILOG 的规则管理，可实现： ? 业务规则与保险应用剥离，业务规则易于管理 ? 使用集中规则库进行管理，业务人员可单独变更业务规则 ? 实现历史规则追溯 ? 规则可重用 ? 缩短新业务发布周期 ? ILOG 在都邦保险的运用 Ilog 规则引擎系统目前维护的规则有车险核保规则和车险费用规则。 自动核保规则是指根据某些核保因子判断当前保单是否能够自动核保通过或者不能够自动核保通过的规则。 其中，不能够自动核保通过的规则，一般又分为数据校验规则、打回出单规则以及自动核保校验规则（转人工核保）等。 人工核保权限规则是指在人工核保环节，不同级别的核保员具有不同的核保权限，配置不同级别的核保员核保权限的规则就是人工核保权限规则。 ? 产品组件 Rule Studio （规则开发环境） 用于对基于规则的应用程序进行编码、调试和部署； Rule Execution Server （规则执行服务器） RES 执行部署的规则应用，业务规则调用的组件，并包括一个web 的管理控制台，业务人员/技术人员编写的业务规则只有部署在规则的执行环境中才能被执行，才能起到作用； 核保规则 自动核保规则 人工核保规则 ——维护各核保级别的权限 打回出单（数据校验或拒保）规则 转人工核保规则 自动核保通过规则
本文为“等考二级JAVA：Java规则引擎工作原理及应用”，以供广大学员参考使用。更多关于计算机 等级考试资料，请访问考试吧计算机等级考试频道。 摘要：Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。 引言 目前，Java社区推动并发展了一种引人注目的新技术——Java规则引擎(Rule Engine)。利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。 规则引擎的原理 1、基于规则的专家系统(RBES)简介 Java规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其 中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。为了更深入地了解Java规则引擎，下面简要地介绍基于规则的专家系统。RBES包括三部分：Rule Base(knowledge base)、Working Memory(fact base)和Inference Engine。它们的结构如下系统所示： 如图1所示，推理引擎包括三部分：模式匹配器(Pattern Matcher)、议程(Agenda)和执行引擎(Execution Engine)。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式匹配器决定选择执行哪个规则，何时执行规则;议程管理模式匹配器挑选出来的规则的执行次序;执行引擎负责执行规则和其他动作。 推理引擎的推理步骤如下： (1)将初始数据(fact)输入Working Memory。
BI YE SHE JI （20 届） 保险核保业务中的规则引擎系统开发 所在学院 专业班级信息管理与信息系统 学生姓名学号 指导教师职称 完成日期年月
诚信申明 本人声明： 我所呈交的本科毕业设计论文是本人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成果。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。本人完全意识到本声明的法律结果由本人承担。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：日期：年月日
毕业设计（论文）任务书 设计（论文）题目：规则引擎系统于保险中核保业务的应用 1．设计（论文）的主要任务及目标 收集规则引擎系统相关资料，了解规则引擎系统的工作流程，分析系统功能的需求，完成相应的系统分析与设计工作，同时编码实现系统的主要功能模块，使系统具有较好的适用性、安全性和稳定性。 2．设计（论文）的基本要求和内容 毕业论文应结构合理、观点正确、文字流畅，内容包括课题的研究背景及意义，相关计算机技术，系统需求分析、设计方案以及总体框架，系统的关键程序及实现界面。系统设计方案应完整正确。采用Java与SQL sever 数据库的方式进行设计，完成与规则引擎系统相关的各个主要项目的内容设计。 3．主要参考文献 [1] 薛华成主编．管理信息系统(第三版)．北京：清华大学出版社，1999 [2]印旻. Java语言与面向对象程序设计[M]. 清华大学出版社, 2000. [3]苗雪兰. 数据库系统原理及应用教程[M]. 机械工业出版社, 2001. [4]严, 蔚敏, 吴, 伟民. 数据结构(C语言版)[J]. 计算机教育, 2012(12):62-62. 4．进度安排
规则引擎Ｖeｒsion 1.０.0 作者：Joｈｎny Leoｎ发布日期：2016-08—08
目录 1 业务规则?错误!未定义书签。 1.１?什么是业务规则 ............................................................................... 错误!未定义书签。 1。２?业务规则的例子?错误!未定义书签。 1。3?业务规则的分类?错误!未定义书签。 1.4 业务规则的特性?错误!未定义书签。１．５?业务规则的要素 .......................................................................... 错误!未定义书签。 2 规则引擎?错误!未定义书签。 2．1 规则引擎是什么?错误!未定义书签。 2.2?规则引擎的组成?错误!未定义书签。 2。3 规则引擎的推理?错误!未定义书签。 2.4 规则引擎的应用 ........................................................................... 错误!未定义书签。 2.5 业务规则的提取?错误!未定义书签。 2。6?业务规则的管理?错误!未定义书签。 ３?典型案例?错误!未定义书签。案例1：信用卡申请 ................................................................................ 错误!未定义书签。 案例2:企业薪资计算?错误!未定义书签。 案例３：保险公司核保理赔?错误!未定义书签。案例4:快递产品报价 ............................................................................... 错误!未定义书签。案例5:电商促销 ....................................................................................... 错误!未定义书签。
本技术公开了一种可配置的保险风控规则引擎系统及流程方法，系统包括支持业务人员自定义风控规则的录入界面模块，支持模糊匹配、快速定位的录入提示模块，实时的规则有效性校验模块，规则更新后的实时编译、发布模块，基于分布式调度器的并行流式规则处理引擎模块。本技术属于互联网金融信息技术和保险防控技术领域，具体是提供了一种实用性高、操作简单、可大大缩减业务人员的核保流程时间的可配置的保险风控规则引擎系统及方法。 技术要求 1.一种可配置的保险风控规则引擎系统，其特征在于，包括支持业务人员自定义风控规则的录入界面模块，支持模糊匹配、快速定位的录入提示模块，实时的规则有效性校验模块，规则更新后的实时编译、发布模块，基于分布式调度器的并行流式规则处理引擎模块。 2.一种可配置的保险风控规则引擎系统的流程方法，其特征在于，包括如下步骤：
1)保险业务人员通过录入界面模块编辑、增加、删除风控规则；在此过程中，系统通过模糊匹配，快速通过业务人员输入的拼音首字母等快速定位到待录入的字段；每当更新一条规则后，系统会通过开源工具Antlr进行实时地规则语法检查以及通过Rete等有向图分析算法进行规则有效性检查，并将合法的规则集转化为后端规则引擎所需的规则文件； 2)启动编译器将新生成的规则文件编译打包进可执行文件，然后将程序发布； 3)对于实时到达的业务数据，通过基于分布式调度器的并行流式规则处理引擎实时进行处理，并将处理结果反馈给业务分析人员。 技术说明书 一种可配置的保险风控规则引擎系统及流程方法 技术领域 本技术属于互联网金融信息技术和保险防控技术领域，具体是指一种可配置的保险风控规则引擎系统及流程方法。 背景技术 长久以来，保险行业的服务痛点集中存在于理赔的时效性和风险管控。对于保险公司而言，理赔风险管控是一个行业性的挑战，存在着人工投入大、效率低、理赔欺诈严重、经验迭代慢等问题。能否高效地识别理赔工作中的风险点、及时发现理赔中的高风险行为是保险风控引擎的重点关注领域。 通常的风控引擎需要编程人员预先设计好风控规则，然后将程序编译打包后，交由保险业务人员在核保和理赔中使用。这样的弊端在于：1.风控规则需要由专业的编程人员实现；2.当需要更新规则时，需要由业务人员反馈给编程人员进行编码，重新打包发布，更新周期长，实效性无法得到保证；3.传统的规则引擎在构建有向图时需要耗费大量内存，使得单机无法满足存在大量规则的业务系统的运行需要。 技术内容
规则引擎研究——Rete算法介绍 一、R ETE概述 Rete算法是一种前向规则快速匹配算法，其匹配速度与规则数目无关。Rete是拉丁文，对应英文是net，也就是网络。Rete算法通过形成一个rete网络进行模式匹配，利用基于规则的系统的两个特征，即时间冗余性（Temporalredundancy）和结构相似性（structuralsimilarity），提高系统模式匹配效率。 二、相关概念 2.1事实（FACT）： 事实：对象之间及对象属性之间的多元关系。为简单起见，事实用一个三元组来表示：（identifier^attributevalue），例如如下事实： w1:(B1^onB2)w6:(B2^colorblue) w2:(B1^onB3)w7:(B3^left-ofB4) w3:(B1^colorred)w8:(B3^ontable) w4:(B2^ontable)w9:(B3^colorred) w5:(B2^left-ofB3) 2.2规则（RULE）: 由条件和结论构成的推理语句，当存在事实满足条件时，相应结论被激活。一条规则的一般形式如下： (name-of-this-production LHS/*oneormoreconditions*/ --> RHS/*oneormoreactions*/ ) 其中LHS为条件部分，RHS为结论部分。 下面为一条规则的例子： (find-stack-of-two-blocks-to-the-left-of-a-red-block (^on) (^left-of) (^colorred) -->
...RHS... ) 2.3模式（PATTEN）： 模式：规则的IF部分，已知事实的泛化形式，未实例化的多元关系。 (^on) (^left-of) (^colorred) 三、模式匹配的一般算法 规则主要由两部分组成：条件和结论，条件部分也称为左端（记为LHS,left-handside），结论部分也称为右端（记为RHS,right-handside）。为分析方便，假设系统中有N条规则，每个规则的条件部分平均有P个模式，工作内存中有M个事实，事实可以理解为需要处理的数据对象。 规则匹配，就是对每一个规则r,判断当前的事实o是否使LHS(r)=True，如果是，就把规则r的实例r(o)加到冲突集当中。所谓规则r的实例就是用数据对象o的值代替规则r的相应参数，即绑定了数据对象o的规则r。 规则匹配的一般算法： 1)从N条规则中取出一条r； 2)从M个事实中取出P个事实的一个组合c； 3)用c测试LHS(r)，如果LHS(r（c）)=True，将RHS(r（c）)加入冲突集中； 4)取出下一个组合c，goto3； 5)取出下一条规则r，goto2； 四、RETE算法 Rete算法的编译结果是规则集对应的Rete网络,如下图。Rete网络是一个事实可以在其中流动的图。Rete网络的节点可以分为四类：根节点（root）、类型节点（typenode）、alpha节点、beta节点。其中，根结点是一个虚拟节点，是构建rete网络的入口。类型节点中存储事实的各种类型，各个事实从对应的类型节点进入rete网络。 4.1建立RETE网络 Rete网络的编译算法如下： 1)创建根； 2)加入规则1(Alpha节点从1开始，Beta节点从2开始)； a.取出模式1，检查模式中的参数类型，如果是新类型，则加入一个类型节点；
ILOG规则引擎系统运维手册 一、ILOG规则引擎系统介绍 ?为什么使用ILOG规则引擎系统？ 保险行业是大量业务规则的处理过程，投承保规则、保费计算规则、核保规则、核批规则、费用规则、核赔规则。。。业务规则无所不在，且随着行业监管、市场环境、业务管理等因素不断变化。 业务规则管理混乱、业务规则变更过分依赖技术人员，业务人员无法单独完成业务规则变更，维护成本高昂，由此带来的问题： ?业务规则变更周期长、成本高 ?规则重用性差 ?业务规则知识随着时间被淡忘 基于ILOG的规则管理，可实现： ?业务规则与保险应用剥离，业务规则易于管理 ?使用集中规则库进行管理，业务人员可单独变更业务规则 ?实现历史规则追溯 ?规则可重用 ?缩短新业务发布周期 ?ILOG在都邦保险的运用 Ilog规则引擎系统目前维护的规则有车险核保规则和车险费用规则。
自动核保规则是指根据某些核保因子判断当前保单是否能够自动核保通过或者不能够自动核保通过的规则。 其中，不能够自动核保通过的规则，一般又分为数据校验规则、打回出单规则以及自动核保校验规则（转人工核保）等。 人工核保权限规则是指在人工核保环节，不同级别的核保员具有不同的核保权限，配置不同级别的核保员核保权限的规则就是人工核保权限规则。 ? 产品组件 Rule Studio （规则开发环境） 用于对基于规则的应用程序进行编码、调试和部署； Rule Execution Server （规则执行服务器） RES 执行部署的规则应用，业务规则调用的组件，并包括一个web 的管理控制台，业务人员/技术人员编写的业务规则只有部署在规则的执行环境中才能被执行，才能起到作用； 核保规则 自动核保规则 人工核保规则 ——维护各核保级别的权限 打回出单（数据校验或拒保）规则 转人工核保规则 自动核保通过规则
Java规则引擎工作原理及其应用 作者：缴明洋谭庆平出处：计算机与信息技术责任编辑：方舟[ 2006-04-06 08:18 ] Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对 摘要Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程 序中对应的操作。 引言 目前，Java社区推动并发展了一种引人注目的新技术——Java规则引擎（Rule Engine）。利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力 提供有效的技术支持。 规则引擎的原理 1、基于规则的专家系统（RBES）简介 Java规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。为了更深入地了解Java规则引擎，下面简要地介绍基于规则的专家系统。RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示： 图1 基于规则的专家系统构成 如图1所示，推理引擎包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式
目前制造业所面临的“多品种、少批量、短交货期、多变化”的国际市场环境下，传统ERP的计划模型已经越来越不能适应现代企业的管理要求，扩展ERP 的功能成了必行的趋势，APS(高级计划与排程)系统在此情况下应运而生。（APS 是一种基于供应链管理和约束理论的先进计划与排产工具，包含了大量的数学模型、优化及模拟技术，为复杂的生产和供应问题找出优化解决方案） 企业的难题： 订单——企业是否满足随机的订单需求？计划变化频繁，计划总是跟不上变化；插单非常多，计划调整非常困难；交货期经常发生延误，无法正确回答客户的交货期。 产能——企业设计产能很高，就是产量上不去，机器、人员忙闲不均，生产成本居高不下；无法准确预测未来机台产能负荷，无法均衡分配产能。 调度——在排满计划的车间，调度指令牵一发而动全身，一个插单、一个工序，后面一连串的计划都要调整。谁能预见未来的状况？谁能做出快速准确判断？谁能平衡计划、生产、物流部门的矛盾？ 库存——经常发生原材料、零部件的备货不足；半成品、原材料的库存水平非常高，在目前自己工厂的管理体系下，无法确定应该在什么时候什么环节准备多少的库存。 成本——产品的生产周期非常长；计划人员过多，工作协调性差；效率低而且容易造成经费的浪费。
在生产计划和排程当中，以上所遇到的时最常见的，也是最需要解决的，这些问题，复杂多变，光靠排产软件无法根本解决问题，如果通过不断的改进程序后台，或者坚持人工排产，是无法跟进生产要求的。 那么这个时候，就需要有一款软件，能进行智能化排程，在每一个订单进来的时候，能及时分析产能，能科学的进行智能排期，并且能快速得出结果，订单交付日期能准确而又及时，同时，结合库存、原料等信息，及时的发现生产环节中的每一个细节所出现的问题，保持最优的订单进程。还有一个很重要的问题，通常在计划排满的车间，来一个插单，或者工序的变化，就容易打乱整个计划…… 旗正规则引擎，完美解决，并且让排产计划始终处于最优的状态，比起排产软件，旗正规则引擎能随需快速添加规则，业务人员即可参与，不需IT部门参与，这是排产软件很难做到的。我们来看个案例： 松下电器是世界巨头，来到中国后从总部引入一套排产系统，但是基本不能满足国内生产排产需要，由于国内客户需求变化多、插单多、各条生产线生产能力与特长不同，基本依靠手工排产，远远不能满足客户订单需求。 旗正提供了什么？ 旗正在充分了解公司实际情况后，引入公司规则引擎产品，在调研客户需求，梳理客户流程、管理方式等基础上，为客户快速开发出一套智能化排产系统，完全满足了排产需要。 取得什么效果？ 人工减少了50%，生产效率提高20%，订单满足率从70%提高到近99%。
第9卷第3期杨凌职业技术学院学报V ol.9 No.3 2010年9月Jour nal of Y ang ling V ocatio nal&T echnical Co lleg e Sep.2010 * Jess规则引擎在数据质量分析中的应用 史 峰 (江苏省宿迁市广播电视大学,江苏宿迁223809) 摘 要:规则引擎通过将业务规则和开发者的技术决策分离,实现了动态管理和修改业务规则而又不影响软件系统的需求。Jess是一个基于Java的规则引擎,可以方便地嵌入到Jav a应用程序中。本文论述了Jess规则引擎的核心组成及基于Jess规则的数据质量分析的工作原理,通过实例对基于SQ L查询、自定义规则和Jess规则进行了对比分析,得出了Jess规则引擎能够有效地对业务规则进行结构化表示和自动完成数据质量分析的结论。 关键词:Jess规则引擎;数据质量分析;事实库;规则库 中图分类号:T P311.13;T P311.5 文献标识码:A 文章编号:1671 9131(2010)03 0052 04 The Application of Jess Rule Engine in Data Q uality Analysis SHI Feng (Suqian Radio&T V U niv ersity,Suqian,Jiang su223809,China) Abstract:T he reg ular eng ine meets the demand o f dy namic manag ement and the r ev isio n o f business r ule,and does not af fect soft war e sy st em as w ell thr ough the separ ation of ser vice rule and ex ploiter's technical decisio n making.Jess is one r eg ular eng ine based on the Java,ma y be inserted co nv eniently into the Java application procedur e.T his art icle elabor ated the co re composition of Jess r egular eng ine and the w or king principle of data qualit y analysis based on the Jess r ule.With case study,w e made a compariso n of self def initio n rule based on SQ L inquiry and Jess rule,the co nclusion is obtained that Jess rule eng ine could car ry on st ruct ur al represent ation f or business rule effectively and t o co mplete the data qualit y analysis au to matically. Key words:Jess rule engine;data quality analysis;fact base;r ule base 在现代的企业级项目开发中,商业决策逻辑或业务规则往往是硬编码嵌入在系统各处代码中的。但是外部市场业务规则是随时可能发生变化的,这样开发人员必须时刻准备修改、更新系统,降低了效率。在这种背景下,规则引擎应运而生,它通过将业务规则和开发者的技术决策分离,实现了动态管理和修改业务规则而又不影响软件系统的需求。规则引擎具有广泛的应用领域,同样也适用于数据质量分析和清洗。 Jess是一个基于Java的规则引擎,是流行的CLIPS专家系统的Java实现,可以方便地嵌入到Java应用程序中。Jess采用产生式规则作为基本的知识表示,其核心由事实库、规则库和推理机组成。 Jess规则引擎的外部输入包括两部分:事实库和规则库。在数据质量分析应用中,待分析的数据构成了事实库,而所有业务规则构成了规则库。 1 事实库 Jess事实模板与数据库关系表定义有很好的对应关系: 表1 Jess事实模板与数据库关系表定义的对应 事实模板模板名槽名槽类型槽值 关系表定义表名字段名字段类型字段值 因此可以从待分析的数据库中抽取关系表的定义来构造事实模板,而关系表的每一条记录则对应一个事实。这样所有待分析的数据构成了事实库。假设有一个员工信息数据表employee,其字段定义如表2所示。 *收稿日期:2010 04 11 作者简介:史峰(1975 ),男,江苏省沭阳县人,讲师,主要从事数据库研究与数字化校园建设。
规则获取中的规则发现 姓名：杨海泷 摘要：规则获取包括规则发现和规则发现，本文主要介绍了规则的分类以及常见的规则发现活动。并给出了简单的规则发现流程。 关键词：业务规则，规则获取，规则发现，规则分类； Rule Discovery in Rule Harvesting Yang Hailong Abstract:Rule harvesting includes the two main activities of rule discovery and analysis.This paper mainly introduces the classification of rules,common rule discovery activities.In addition,this paper gives out a simple process of rule discovery. Keyword:Business Rule；Rule Harvest；Rule Discovery；Classification of Rules 规则发现，也称为企业业务规则建模，目的是开发简单模型，像规则描述，业务实体图表，业务流程图。规则发现是一个不断迭代的过程，不是一蹴而就的过程。业务规则发现技术和传统的需求抽取类似，主要有一个不同就是，它更关注企业中的那些特殊的需求，这些需求为业务如何执行提供决策。在开始阶段，我们首先要获取一些产品，这些产品在规则发现阶段会用到。这些产品包括：业务流程的顶层描述；当前和将来架构的顶层描述；数据源和数据模型的列表；决策表。特别是决策表能够帮助定义哪里能够找到规则（规则源），哪个方法可以在规则获取时使用。规则发现流程会随着规则源的不同而改变。例如，通过合法文档里获取规则和通过采访专业领域专家获取规则的流程是不同的。 1.业务规则的分类 在决定如何书写规则和如何实现他们之前，我们必须要首先明确我们要获取哪一类型的规则。早在2008年，对象管理组织（OMG）定义了业务词汇和业务规则语义的编制规范，称作业务词汇和业务规则语义（SBVR）。 该规范描述了SBVR作为OMG的模型驱动架构（MDA）的一部分，其目的是捕获自然语言中的规范并正规的方式表示它们以便于自动化。SBVR包括两个专业词汇：一个是通过商业术语视图定义商业术语和意义。这在SBVR规范中称为业务词汇。另一个是用一种清楚的方式表达规则。 所谓意义就是某人理解或者想要表达的意思。意义可以分成概念，问题和建议。OMG 定义了一种业务动机模型（BMM），该模型定义了业务政策，管理，业务流程，业务规则之间的关系。BMM模型沿用了SBVR中的分类： ·结构型（定义型）业务规则。该种类型规则描述业务实体的结构，指定了如值的类型，强制关系等元素。 ·操作型（行为型）业务规则。该种类型规则描述如何加强业务策略使运行效率提高，实现
规则引擎排产系统中的应用 排产系统是制造企业ＭＥＳ系统的重要组成部分，对应于生产管理系统的短期计划安排，主要目标是通过良好的作业加工排序，最大限度减少生产过程中的准备时间，优化某一项或几项生产目标，为生产计划的执行和控制提供指导。在不同的问题环境中，排产的优化目标也不同。在生产制造企业中影响排产的因素很多（比如需求变化多、插单多、各条生产线生产能力与特长不同等），因素众多，通常最影响排产计划的进行，降低了生产效率和交货及时性。传统的手工排产已完全不能满足企业多变的需求。另外在不同的环境下，影响排产的规则数量、优先级都会发生变化。过去排产系统将业务逻辑与主体代码紧耦合，业务规则以： 的形式被硬编码到代码中去，结果是线性、确定的执行路由，所有的约束和判断都按照建模时的约定执行。当业务规则发生变更时，唯一的途径是修改代码。 这种形式无法适应制造企业生产规则的频繁变更，导致排产系统的开发、升级和维护成本急剧增加，甚至排产系统完全无法适应企业的实际需求。因此排产系统在保证对目标优化的前提下，将业务逻辑与主体程序的分离，已成为排产系统首要解决的问题。本文着重阐述通过规则引擎技术将生产规则逻辑从排产系统分离，克服生产规则灵活变更导致排产系统无法适应企业生产策略变更的问题。 目前开源和商业的规则引擎产品有很多，其中开源的以Drools为代表，商业的有ILo g，旗正规则引擎（VisualRules）等，本文以商业规则引擎中的旗正规则引擎来说明。说句题外话，开源的产品有开源产品的优点，但是规则引擎作为一个高端的应用来说，还是希望在售后服务，技术支持等方面能有商业化的保障。
在制造企业中，生产策略的变更非常频繁并且影响排产系统的业务策略很多，而传统的排产系统将业务逻辑与排产逻辑紧密耦合，导致系统的开发，维护都变得异常艰难。因此如何将业务逻辑与主体程序分离，屏蔽业务策略变更对主体程序的影响，则成为排产系统的关键问题。 基于规则引擎的排产系统架构设计的核心是实现业务逻辑与应用程序解耦。它的实现方案可分为以下几个步骤： 1. 生成业务规则业务人员对影响排产的业务策略进行收集，抽象，归纳，按照规则文件格式配置成业务规则。 2. 业务规则管理业务人员通过规则管理平台实现对规则的存储，版本，废弃，冻结等一系列的管理 3. 执行业务规则应用程序中启动规则引擎（服务和接口）解析执行已经编辑配置好的规则文件，然后将结果返回给应用程序。 规则引擎，能够让整个排产系统快速适应企业业务策略的频繁变更，隔离策略变更对应用程序的影响，同时又能与主体程序进行动态通信。主体程序动态感知业务策略的变更，将变更结果推动执行和呈现。 在制造业企业中，制约排产的业务规则很多，在不同的场景中业务规则的组合形式多种多样并且规则的执行先后顺序对调度结果也起着制约作用，业务规则的表现形式也是多种多样的，如何灵活易用的配置统一格式的规则是我们关注的重点。
基于SaaS的规则引擎在企业流程中的应用引言规则引擎原理流程应用基于saas的模式意义 1、引言 目前，B2B电子商务平台发展了大量的中小企业用户，提供具有共性的信息管理服务，但是这些服务对于特定用户来说，无法根据该用户的业务流程来构造与其自身业务相匹配的管理过程；同时，平台亦无法应对会员企业将来发展带来的管理过程的不断变化。 在这种情况下，为中小企业用户提供个性化的服务，对企业的意义是非常重大的。 尽管现在有些软件开发商为企业提供量身定制的功能需要，但这种方式开发成本很高，而且基本上是按照当时或者用户可以预见的方式进行开发，不可避免的出现一些弊端：（1）需要安装专门的管理系统软件，维护困难； （2）功能的灵活性较小，只能符合某些行业的特点，不符合B2B电子商务平台上广大行业的需求； （3）功能的配置操作复杂，不利于中小企业用户的使用； （4）功能维护和修改的成本高。 为了解决上述弊端，基于SaaS的业务规则引擎的方法被提了出来，这种方法充分利用了SaaS（软件即服务）的特点，不需要在中小企业的计算机上安装任何软件，把系统的日常维护工作都交给软件服务运营商；而且使用成本低廉，符合中小企业的信息化成本要求。同时通过企业业务流程与规则引擎的结合应用，把商业规则与应用开发代码，让中小企业的工作人员能在运行时可以动态地管理和修改商业规则，保证了软件系统的柔性和自适应性，使电子商务平台为中小企业用户提供个性化的服务打下了良好的基础。 2、业务流程与规则引擎 2.1 业务流程与流程引擎 业务流程属于工作流的范畴。工作流指全部或者部分由计算机自动处理的业
务过程。而工作流管理系统是这样的一个系统：详细定义、管理并执行“工作流”，系统通过运行一些软件来执行工作流，这些软件的执行顺序由工作流逻辑的计算机表示形式（流程定义）来驱动。 工作流系统与业务系统的关系如下图所示： 国际标准化组织WFMC（工作流管理联盟）发布了一个通用的工作流系统实现模型，这个模型可以适用于市场上的大多数产品，因此为开发协同工作的工作流系统奠定了基础。 把工作流系统中的主要功能组件，以及这些组件间的接口看成抽象的模型。考虑到会有许多其他的具体实现不同于这个抽象模型，因此，特定的接口在不同的平台中会采用不同的技术，有不同的实现方式。而且并不是所有的开发商都会暴漏功能组件间的每一个接口，具体的规范会定义接口之间的相互操作功能，不同的厂商必须支持这些开放接口才能实现不同工作流之间的协作。 通用的工作流系统实现参考模型如下所示：
基于Java的规则引擎
目录 1.简介 (3) 1.1业务规则 (3) 1.2规则引擎产生背景 (3) 2.规则引擎 (4) 2.1业务规则 (4) 2.2规则引擎 (4) 2.3规则引擎的使用方式 (4) 2.4规则引擎架构与推理 (5) 2.5规则引擎的算法 (6) 3.Java规则引擎 (7) 3.1Java规则引擎商业产品 (7) 3.2规则引擎产品特点分析 (8) 3.2.1IBM WebSphere ILOG JRules (8) 3.2.2Redhat JBoss Dools (11) 3.2.3JESS (11) 4.Java规则引擎API（JSR94） (13) 4.1简介 (13) 4.2简介Java规则引擎API体系结构 (13) 3.2.4规则管理API (13) 3.2.5运行时API (14) 4.3Java规则引擎API安全问题 (15) 4.4异常与日志 (15) 4.5JSR94小结 (16) 5规则语言 (17)
1.简介 1.1业务规则 一个业务规则包含一组条件和在此条件下执行的操作．它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。 业务规则的理论基础是：设置一个或多个条件，当满足这些条件时会触发一个或多个操作。 1.2规则引擎产生背景 复杂企业级项目的开发以及其中随外部条件不断变化的业务规则（business logic），迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。 企业管理者对企业级IT系统的开发有着如下的要求： 1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂； 2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更 新； 3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序 开发人员参与。 而项目开发人员则碰到了以下问题： 4程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型； 5软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中； 6对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。 基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。