因为公司项目的需要，最近在研究drools，现在正在初步学习阶段，总结和转载一些文章以备学习以及共享。
一、什么是规则引擎呢？
Drools（JBoss Rules ）具有一个易于访问企业策略、易于调整以及易于管理的开源业务规则引擎，符合业内标准，速度快、效率高。业务分析师或审核人员可以利用它轻松查看业务规则，从而检验是否已编码的规则执行了所需的业务规则。 JBoss Rules 的前身是Codehaus的一个开源项目叫Drools。最近被纳入JBoss门下，更名为JBoss Rules，成为了JBoss应用服务器的规则引擎。 Drools是为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。具有了OO接口的RETE,使得商业规则有了更自然的表达。
规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。
二、规则引擎的优势
声明式编程
规则引擎允许你说“做什么”，不用说“怎样做”。
这点的主要优势是： 使用规则可以让困难问题的解决方案的表达， 以及这些解决方案的验证变得容易。
规则比代码更容易阅读。
规则系统有能力解决非常、非常困难的问题，对解决方案如何得出，每个“决定”向前的线路为何做出，提供了一个解释（利用其他的 AI 系统，如神经网络和人类大脑，没那么容易——我不知道为什么我擦破了车皮）。
逻辑和数据的分离
你的数据是在你的域对象中，你的逻辑是在规则中。这是从根本上打破了面向对象的数据和逻辑的耦合，这可能是一个优点，也可能是一个缺点，取决于你的视角点。结果是逻辑可能更容易维护，因为将来有变化，因为逻辑完全设置在规则中。如果逻辑是跨域或多域逻辑，这可能更是如此。而不是逻辑分散在域对象或控制器中，它可以完全在一个或多个独特的规则文件中被组织。
速度和可伸缩性
Rete 算法， Leaps 算法，及其派生物，比如 Drools 的 ReteOO，为你的域对象数据提供了非常有效的匹配规则模式的方法。当你使用较少变化的数据集时，特别有效，因为规则引擎可以记住过去的匹配。这些算法已被实战证明。
集中管理知识
通过使用规则，你创始了一个可执行的知识库（a knowledge base）。这意味着它是一个单点真相（asingle point of truth），例如，对业务策略。规则是这样完美可阅读的，所以也可以用文档服务。
工具集成
工具，比如 Eclipse（在将来，，基于网页的用户界面）提供了编辑和管理规则、立即得到反馈、验证和内容帮助的方法。也提供可用的审计和调试工具。
解释机制
规则系统，通过能够记录由规则引擎作出的决定，以及为什么作出决定，有效地提供了一个“解释机制”。
可理解的规则
通过创建对象模型，以及，可选择的，你的问题域模型的域特定语言，你可以自己设置来编写非常接近自然语言的规则。它们对可能非技术的域专家赋予了它们自身可以理解的逻辑，因为他们用自己的语言表达它们，所有程序的探求，技术决窍被隐藏于常规代码中， 适用的系统企业应用的ERP、CRM以及电子商务的销售系统及营销系统等
三、什么时候应使用规则引擎
对此最简捷的回答是：“在解决问题时，没有令人满意的传统编程方式。”给出这样简短的回答，需要进一步解释。为什么没有“传统”的方法，原因是以下之一：
问题只是对传统代码太琐碎（fiddle）。
问题可能不是很复杂，但是你可能不理解构建它的解决方案的耐脆性方式（non-fragile way）
问题超出了所有明显算法的解决方案。
解决一个复杂问题，没有明显的传统解决方案，或者基本问题没有完全理解。
逻辑经常变化。
逻辑本身甚至可能是简单的，但是规则变化相当频繁。在许多组织的软件版本中是少见的，并且可插式规则可以用一种合理安全的方式提供需要和期望的“敏捷性”。
域专家（或业务分析员）是乐意使用，而且是非技术的。
域专家常常处理有关规则和流程的大量知识。他们通常是非技术的，但是却非常有逻辑头脑的。规则可以允许他们用他们自己的术语表达逻辑。当然，他们仍然必须辩证思考，并具有逻辑思维的能力。在非技术岗位的大多人没有形式逻辑方面的训练，那么要小心与他们一起工作，因为在用规则系统化业务知识时，你常常会在当前理解业务规则和流程的道路上暴露出漏洞。如果规则对你的项目团队是一个新的技术，在进行中的管理费用必须考虑进来。 它不是一个普通技术，但是本文档试图让它更容易理解。通常在一个现代的面向对象应用程序中，你应该使用一个规则引擎，包含你的业务逻辑的主要部分，特别是真正凌乱的部分。这是封装所有逻辑在你的对象内的面向对象概念的一个颠覆（inversion）。
其实生命无论长短，只要我们能努力绽放出生命的光彩，便会拥有精彩的人生。
