学习JBoss Rules有几天了，我把我看的一些重要的东西翻译整理了一下，希望可以对想学习JBoss Rules的同学们提供一点帮助。

1、JBoss Rules简介

JBoss Rules（Drools ）具有一个易于访问企业策略、易于调整以及易于管理的开源业务规则引擎，符合业内标准，速度快、效率高。业务分析师或审核人员可以利用它轻松查看业务规则，从而检验是否已编码的规则执行了所需的业务规则。
JBoss Rules 的前身是Codehaus的一个开源项目叫Drools。最近被纳入JBoss门下，更名为JBoss Rules，成为了JBoss应用服务器的规则引擎。
Drools是为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。具有了OO接口的RETE,使得商业规则有了更自然的表达。

既然JBoss Rules是一个商业规则引擎，那我们就要先知道到底什么是Rules，即规则。在JBoss Rules中，规则是如何被表示的

1.1    规则文件

一个规则文件通常是一个以 .drl 扩展名结尾的文件。在一个 drl 文件中，你可以有多条 rules ， functions 等等。尽管如此，你也可以将你的规则分布在多个文件中，这有利于管理大量的规则。一个 DRL 文件是一个简单的文本文件。

1.2 规则的结构

一个规则结构大致如下：

可以看到，这是非常简单的。通常的标点符号都是不需要的，甚至连“ name ”的双引号都是不需要的。 ATTRIBUTES 是简单的，也是可选的，来提示规则的行为方式。 LHS 是规则的条件部分，需要按照一定的语法来写。 RHS 基本上是一个允许执行 Java 语法的代码的块（以后将会支持 groovy 和 C ＃）。任何在 LHS 中使用的变量都可以在 RHS 中使用。

注意：每行开始的空格是不重要的，除非在 DSL （ Domain Specific Language ）语言中有特别的指明。

2、◆ 那么什么是规则引擎呢？

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

 3、◆ 使用规则引擎的好处

■ 声明式编程：规则引擎允许你描述做什么而不是如何去做

■ 逻辑与数据分离：数据保存在系统对象中，逻辑保存在规则中。这根本性的打破了面向对象系统中将数据和逻辑耦合起来的局面

■ 速度及可测量性：Rete算法、Leaps算法,以及由此衍生出来的Drools的Rete、Leaps算法，提供了对系统数据对象非常有效率的匹配

■ 知识集中化：通过使用规则，将建立一个可执行的规则库。这意味着规则库代表着现实中的业务策略的唯一对应，理想情况下可读性高的规则还可以被当作文档使用

■ 工具集成：例如Eclipse（将来可能在基于Web的界面上）这样的工具为规则的修改与管理、即时获得反馈、内容验证与修补提供了办法。审查与调试工具同样也可用了

■ 解释机制：通过将规则引擎的决断与决断的原因一起记录下来，规则系统提供了很好的“解释机制”

■ 易懂的规则：通过建立对象模型以及DSL（域定义语言），你可以用接近自然语言的方式来编写规则。这让非技术人员与领域专家可以用他们自己的逻辑来理解规则（因为程序的迷宫已经被隐藏起来了）

4、◆ 适合使用规则引擎系统的场合

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

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

■ 没有优雅的算法

■ 业务规则频繁改变

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

 5、◆ 不适合使用规则引擎系统的场合

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

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

JBoss Rules 总结