规则引擎的原理

　　1、基于规则的专家系统（RBES）简介

　　Java规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。为了更深入地了解Java规则引擎，下面简要地介绍基于规则的专家系统。RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示：

图1 基于规则的专家系统构成
　　如图1所示，推理引擎包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式匹配器决定选择执行哪个规则，何时执行规则；议程管理模式匹配器挑选出来的规则的执行次序；执行引擎负责执行规则和其他动作。

　　和人类的思维相对应，推理引擎存在两者推理方式：演绎法（Forward-Chaining）和归纳法（Backward-Chaining）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是根据假设，不断地寻找符合假设的事实。Rete算法是目前效率最高的一个Forward-Chaining推理算法，许多Java规则引擎都是基于Rete算法来进行推理计算的。

　　推理引擎的推理步骤如下：

　　(1)将初始数据（fact）输入Working Memory。

　　(2)使用Pattern Matcher比较规则库（rule base）中的规则（rule）和数据（fact）。

　　(3)如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。

　　(4)解决冲突，将激活的规则按顺序放入Agenda。

　　(5)使用执行引擎执行Agenda中的规则。重复步骤2至5，直到执行完毕所有Agenda中的规则。

　　上述即是规则引擎的原始架构，Java规则引擎就是从这一原始架构演变而来的。

　　2、规则引擎相关构件

　　规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。

　　1)信息元（Information Unit）

　　信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。

　　2)信息服务（Information Services）

　　信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相对应的信息元。

　　3)规则集（Rule Set）

　　顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。

　　4)队列管理器（Queue Manager）

　　队列管理器用来管理来自不同信息服务的信息元对象的队列。

　　下面将研究规则引擎的这些相关构件是如何协同工作的。

　　如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。

图2 处理过程协作图

3、规则引擎的工作机制

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

图3 规则引擎工作机制

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

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

　　任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。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提供了指导规范，并没有提供规则和动作该如何定义以及该用什么语言定义规则，也没有为规则引擎如何读和评价规则提供技术性指导。

　　结束语

　　规则引擎技术为管理多变的业务逻辑提供了一种解决方案。规则引擎既可以管理应用层的业务逻辑又可以使表示层的页面流程可订制。这就给软件架构师设计大型信息系统提供了一项新的选择。而Java规则引擎在Java社区制定标准规范以后必将获得更大发展。

文章转载自网管之家：http://www.bitscn.com/pdb/java/200709/110189_3.html

文章转载自网管之家：http://www.bitscn.com/pdb/java/200709/110189_2.html

文章转载自网管之家：http://www.bitscn.com/pdb/java/200709/110189.html

要说实现，必须先提一下规则引擎的困难：
1.人类对事物的推理方法[2]按照思维的进程方向来看主要有演绎、归纳和类比，在规则引擎中所说的forward-chaining和backward-chaining即是演绎法和归纳法。不管哪一种方法，规则引擎的性能决定于推理算法的效率。forward-chaining是从一个初始的事实出发，不断地应用规则（即进行条件判断，执行相关操作）得出结论。backward-chaining则是从假设出发，不断地寻找符合假设的事实。商用规则引擎多半对如何证实一个事实不那么感兴趣，所以现有的商用规则引擎多是forward-chaining的，而有名的RETE算法[3]就是一个高效率的forward-chaining算法。

2.使用规则引擎相比于普通产品，似乎适应性更强，但规则引擎本身对于产品的适应性则依赖于规则引擎是否足够通用。像Java语言系的JSR-94，使得规则引擎的实现标准化，由此产出的规则引擎也更加通用。

3.许多现有的规则引擎，对于规则的描述有自有一套规则语言，虽然也有标准语言RuleML[4]，为了规则能够重用，基于此不得不再做一套管理规则语言的转换器，规则语言没有标准化之前，规则引擎很难实现标准化。拿资料[5]中所列的三种规则引擎JRules、JBoss Rules（Drools）和Jess来说一下规则语言，它们或者是采用类XML文本混杂程序语言，但依赖于类Antlr这种解释器；或者使用专用程序语言，学习成本高；而且为了能成为产品，对于规则语言，规则引擎需要提供相应的编辑器和管理工具。就好像在规则引擎中集成了一个IDE。

说明一下，对于困难点1，虽然我们不需要构建规则引擎，但规则引擎之争很关键的一点就是规则引擎的性能。对于困难点2和3，本身对使用者而言是否标准并不重要，但重要的是规则引擎的易用性，如果说使用规则引擎需要耗费的学习成本大大高于不使用规则引擎时对产品维护所需要的成本，那么也没有必要引入规则引擎。

这或许可以说是规则引擎的窘境。但不妨我们回归到规则引擎需求。在技术选型时，很关键要做的一步是清楚明了相关技术的适用范围。资料[6]中用例子阐述了规则引擎需求。

即便在最有利的情况下，在软件系统中编写业务规则也是一项必要的挑战性任务。不明确、不完整、易误解的需求的出现只会使开发工作复杂化，并带来成本高昂的错误。业务规则的可视化和文本描述的结合提供了更准确、更有效地捕捉业务规则的途径，特别对于使用规则驱动引擎的实现来说更是如此。使用本文描述的技术，您就可以使用强大的分析框架更好地武装业务分析人员，便于其沟通复杂的业务处理规则。

基于规则引擎需求，对规则引擎做总结如下：
1.当需要在产品运行过程中不断修改规则，而使得重构产品的成本远远大于引入规则引擎的成本时，则适合引入规则引擎
2.规则引擎的规则编辑和管理面向的用户一般是业务人员，所以规则语言要对业务人员足够有好
3.快速匹配条件从而定位到对应的操作是规则引擎高性能的关键
4.规则引擎已经出现标准化，且有多种解决方案，没有必要重复发明轮子，但使用现有规则引擎实现产品仍然有点门槛

综上，再来看看前文中最初始的需求，我们需要实现的是对于复杂step流式的程序进行step和程序的解耦：
1.需要在运行时不断修改规则，但是引入规则引擎成本过高
2.更改规则的用户是程序员（测试脚本的编写者），不用关心是否要弄一套全新的规则语言，以及这套规则语言的解释器
3.总的来说step执行还是一个顺序流，没有必要维护一个匹配树，即不需要引入RETE算法
4.学习规则引擎标准的成本或许高于给出当前需求下的其他解决方案的实现。

后续文中将继续讨论前文中code3中后面engine.exe()部分的实现，也就是这里的其他解决方案。

参考资料
[1]http://www.ibm.com/developerworks/cn/java/j-java-rules/index.html?ca=dwcn-newsletter-java
[2]http://sci-art.cz.cc/?p=46
[3]http://www.cis.temple.edu/~ingargio/cis587/readings/rete.html
[4]http://www.ruleml.org/
[5]http://www.blogjava.net/calvin/archive/2005/10/04/14789.html
[6]http://www.ibm.com/developerworks/cn/opensource/os-rulesengines/index.html

Ilog JRules 是最有名的商用BRMS，刚拿了JOLT；
Drools 是最活跃的开源规则引擎，一路高歌猛进；
Jess 是Clips的java实现，就如JRuby之于Ruby，是AI系的代表。

今天对比了一下这三个颇有代表性的规则引擎的规则语言。其中Ilog是商业产品，没有机会实战。

作者：江南白衣 

1.一样的If--Then 句式与Rete引擎

    三者都会把原来混乱不堪的if---else---elseif----else谜团，
    拆成N条带优先级的"If  条件语句  then  执行语句" 的句式。
   
    三者都主要使用foreward-chaining的Rete引擎，按优先级匹配条件语句，执行规则语句。
    规则执行后会引发事实的变化，引擎又会重新进行条件匹配，直到不能再匹配为止，Rete的算法保证了效率的最高。

2.开发人员使用的规则语言

2.1 Drools的XML框架+Java/Groovy/Python嵌入语言

     Drools的用XML的<Conditons>、<Consequence> 节点表达If--Then句式，而里面可以嵌入上述语言的代码作为判断语句和执行语句。
     其中Java代码会使用Antlr进行解释，而Groovy和Python本身就是脚本语言，可以直接调用。
     Drools的聪明之处在于，用XML节点来规范If--Then句式和事实的定义，使引擎干起活来很舒服。
     而使用Java,Groovy等原生语言来做判断和执行语句，让程序员很容易过渡、移植，学习曲线很低。

  2.2 ILog的IRL(ILog Rule Language)

        IRL用When{}Then{}表达 If--Then句式

    文档称IRL的语法是Java Syntax-like的，但我怎么也看不出两者是相同的。不过他因为是商业产品，有很强大的编辑器和管理工具，编写规则的速度应该不坏。

  2.3 Jess的CLIPS
   jess用  =>  表达 If-Then句式。 这CLIPS是真正的程序员专用语言，而且还要是很专业的程序员才习惯的东西。但这种本来就是用来做专家系统的AI语言，对规则的表达能力也应该是最强的。
   讲解一下下面这段代码，airplane有一个属性--name，有两个子类--喷气式和螺旋桨飞机，其中螺旋桨飞机可以使用任意跑道，而喷气式飞机不能使用Grass跑道。

; Fact templates     (deftemplate airplane (slot name))      (deftemplate jet extends airplane)      (deftemplate prop extends airplane) ;       Rules      (defrule can-use-grass-runway      (prop (name ?n))       =>      (printout t "Aircraft can use grass - " ?n crlf))          (defrule can-use-asphalt-runway       (airplane (name ?n))       =>       (printout t "Aircraft can use asphalt - " ?n crlf))

3.客户使用的规则语言

   如果客户可以自己任意编写规则，无疑是产品一个很大的卖点。大部分客户都会喜欢这样一个玩具。而且也只有把规则编写交给客户，才能达到规则引擎的全部意义。

3.1 Drools的 DSL
     Drools的最新版Drools2.0Rc2里，House和Conways game of Live两个例子有DSL的版本
     对比一下Java版本，效果如下：

vs

     但这种XML Base的DSL语法其实好不了多少，而且实现的代价一点不少，要自己实现Conditons和Consequence Factory类，自行解释那段XML，基本上没有什么便利的底层支持。
    其实，一不做二不休，干脆用Antlr来定义真正的DSL，同样是实现Conditons和Consequence Factory类可能更好。只不过解释XML人人都会，Antlr就比较少人用而已。

3.2 ILog的BAL(Business Action Language)--最完美的王者？
   没有实际用过，只能看文档过过瘾。从文档来看，配合Ilog的编辑器，的确就是很完美的规则语言了。

 JBoss Rules 

 Mandarax 

 JLisa 

 OpenRules 

 JEOPS 

 InfoSapient 

 JRuleEngine 

1      Java规则系统简介

在大型商业系统中，业务规则、商业逻辑等等都会比较复杂。而且在很多大型系统当中，很多业务规则、商业逻辑并不是一成不变的。甚至当系统进入生产阶段时，客户的业务规则、商业逻辑也会改变。某些系统要求甚至更高，要求能24小时不停机，并且能够实时修改商业规则。这就对商业系统提出了较大的挑战。如果将这些可变的规则直接编写到代码里面的话，业务规则一旦改变，就要修改代码。并由此带来编译、打包、发布等等问题。这对于生产系统来说是极不方便的。因此，如何考虑把一些可变的业务规则抽取到外面，使这些业务规则独立于程序代码。并最好是能够实时的修改业务规则，这样就可以做到不用打包编译发布等等。

值得庆幸的是现在出现了一些Java规则引擎（Rule Engine），专门解决以上所述的问题。利用它，我们就可以在应用系统中分离客户的商业决策逻辑和应用开发者的技术决策，并把这些商业规额则放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改。

JbossRules是一个优秀的JAVA规则引擎，其前身是Drools3，后来被Jboss合并并改名为JbossRules

1.1基于规则的专家系统简介

人工智能是一个新兴的学科，它是想让计算机模拟人脑的思维和推理模式。人工智能分成如下几个主要的分学科：

知识表示

神经网络

基因算法

决策树

专家系统

等等几个学科

知识表示是人工智能中的一个基础领域，其目的是如何更好的在计算机当中描述已存在的事实。专家系统就是使用知识表示，来做规则推理，得出最后的结论来。

Java规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。为了更深入地了解Java规则引擎，下面简要地介绍基于规则的专家系统。RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示：

如上图所示，推理引擎包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式匹配器决定选择执行哪个规则，何时执行规则；议程管理模式匹配器挑选出来的规则的执行次序；执行引擎负责执行规则和其他动作。

和人类的思维相对应，推理引擎存在两者推理方式：演绎法（Forward-Chaining）和归纳法（Backward-Chaining）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是根据假设，不断地寻找符合假设的事实。Rete算法是目前效率最高的一个Forward-Chaining推理算法，许多Java规则引擎都是基于Rete算法来进行推理计算的。

l 正向推理：

正向推理图形如下：

正向推理引擎的推理步骤如下：

n 将初始数据（fact）输入Working Memory。

n 使用Pattern Matcher比较规则库（rule base）中的规则（rule）和数据（fact）。

n 如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。

n 解决冲突，将激活的规则按顺序放入Agenda。

n 使用执行引擎执行Agenda中的规则。重复步骤2至5，直到执行完毕所有Agenda中的规则。

n 直到得出最终的结果为止

l 反向推理：

反向推理是目标驱动的推理方式。从目标出发，找出所有能满足该目

标的子目标。这样一直推导下去，直到所有的子目标都已经满足为止。

1.2Java规则引擎

Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。

一般来说，一条规则的形式如下：

when

    <conditions>

then

    <actions>

也就是说，当conditions成立的话，就做下面的actions。其中actions可以为生成新的事实、或者做其他动作，比如，发送email通知、执行一些本地任务等等。

1.3    JAVA规则引擎的优点

n 声明式编程

声明式编程，规则引擎让我们直到“做什么”，而不用直到“怎么做”。我们只要把一系列规则表示出来后。具体的推理动作就交给规则引擎来处理。

n 逻辑和数据分开

将可变的业务逻辑和数据分开。虽然，这违背了面向对象原则。面向对象强调数据和业务逻辑耦合。但是，对于一些易变而复杂的业务规则。如果散步在程序的各个地方、各个层次。那么一旦业务规则更改的话，就会出现“牵一发而动全身”的局面。因此，将可变的业务逻辑独立出来管理，将有助于后面的业务变更。

n 性能

Rete算法的性能比较高。

n 知识集中表示

通过使用规则，我们把规则集中存放起来，从而使系统知识能够集中表示。

n 可读性

规则的可读性比较高。对于熟悉业务规则。但不会程序开发的业务专家，只要熟悉规则的标示，也可以编写和修改业务规则。

1.4    使用JAVA规则系统的场合

那么，在那些场合下适合应用JAVA规则系统呢？总而言之，可以用一句话来概括：当用传统的程序开发，无法得到一种优雅的解决方法的时候，就可以考虑使用规则系统。如下的一些场合：

n 用传统的代码开发比较复杂、繁琐

n 问题虽然不复杂，但是用传统的代码开发比较脆弱，也就是经常修改

n 没有优雅的算法

n 业务规则频繁改变

n 有很多业务专家、不懂技术开发

1.5    不适合使用JAVA规则系统场合

虽然规则系统看起来比较不错，但是并不是任何地方都可以使用规则系统。很多简单、固定的业务系统，可以不用使用规则系统。规则系统也不能用来作为标示重要的业务流程、不能用来作为工作流引擎。

有很多程序员把JAVA规则系统当成是一种动态修改配置。也就是把一部分代码逻辑抽取到外面，统一存放起来。这样，当一些配置修改的话，通过修改规则，就能修改代码的一部分逻辑。如果把JAVA规则仅仅用在这个场合下的话，可以考虑采用脚本引擎。比如BeanShell、JEXL、Groovy等等。

（本文档的全篇可以到博客下面的文件列表下载，地址下面） 
http://www.blogjava.net/jspark/admin/Files.aspx

为了让尽快对jbossRules有一个感官的认识，下面先开发一个HelloWorld的程序。

建立一个java工程，目录如下：

如上所示，建立一个com包，然后在下面分别建立一个Sample.drl文件和DroolsTest.java文件。

Sample.drl是一个规则文件，内容如下：

package com

import com.DroolsTest.Message;

rule"Hello World"

    when

       m : Message( status == Message.HELLO, message : message )

    then

       System.out.println( message );

       m.setMessage( "Goodbye cruel world" );

       m.setStatus( Message.GOODBYE );

       update( m );

end

rule"GoodBye"

    no-looptrue

    when

       m : Message( status == Message.GOODBYE, message : message )

    then

       System.out.println( message );

       m.setMessage( message );

end

DroolsTest.java是测试以上规则的JAVA程序，内部代码如下：

package com;

import java.io.InputStreamReader;

import java.io.Reader;

import org.drools.RuleBase;

import org.drools.RuleBaseFactory;

import org.drools.WorkingMemory;

import org.drools.compiler.PackageBuilder;

import org.drools.rule.Package;

/**

 *Thisisasamplefiletolauncharulepackagefromarulesourcefile.

 */

publicclass DroolsTest {

    publicstaticfinalvoid main(String[] args) {

        try {

        //load up the rulebase

            RuleBase ruleBase = readRule();

            WorkingMemory workingMemory = ruleBase.newStatefulSession();

            //go !

            Message message = new Message();

            message.setMessage( "Hello World" );

            message.setStatus( Message.HELLO );

            workingMemory.insert( message );

            workingMemory.fireAllRules();  

        } catch (Throwable t) {

            t.printStackTrace();

        }

    }

    /**

     *Pleasenotethatthisisthe"lowlevel"ruleassemblyAPI.

     */

    privatestatic RuleBase readRule() throws Exception {

       //read in the source

       Reader source = new InputStreamReader( DroolsTest.class.getResourceAsStream( "/com/Sample.drl" ) );

       //optionally read in the DSL (if you are using it).

       //Reader dsl = new InputStreamReader( DroolsTest.class.getResourceAsStream( "/mylang.dsl" ) );

       //Use package builder to build up a rule package.

       //An alternative lower level class called "DrlParser" can also be used...

       PackageBuilder builder = new PackageBuilder();

       //this wil parse and compile in one step

       //NOTE: There are 2 methods here, the one argument one is for normal DRL.

       builder.addPackageFromDrl( source );

       //Use the following instead of above if you are using a DSL:

       //builder.addPackageFromDrl( source, dsl );

       //get the compiled package (which is serializable)

       Package pkg = builder.getPackage();

       //add the package to a rulebase (deploy the rule package).

       RuleBase ruleBase = RuleBaseFactory.newRuleBase();

       ruleBase.addPackage( pkg );

       return ruleBase;

    }

    publicstaticclass Message {

       publicstaticfinalintHELLO = 0;

       publicstaticfinalintGOODBYE = 1;

       private String message;

       privateintstatus;

       public String getMessage() {

           returnthis.message;

       }

       publicvoid setMessage(String message) {

           this.message = message;

       }

       publicint getStatus() {

           returnthis.status;

       }

       publicvoid setStatus( int status ) {

           this.status = status;

       }

    }

}

运行DroolsTest.java程序，可以看到如下输出结果：

Hello World

Goodbye cruel world

以上就是一个最简单的jbossRules规则系统的例子。下面将具体讲解jbossRules的详细结构和语法。

引于：http://www.blogjava.net/jspark