drools初识（一）

        因为公司项目的需要，最近在研究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）。

       这不是说扔了面向对象的习惯，恰恰相反，在所有实际的应用程序中，业务逻辑只是应用程序的一部分。如果你曾经注意到许多条件语句，比如"if"和"switch"，在你的代码中过多的策略模式和其他凌乱的逻辑，只让你感到不正确： 这将是放置规则的地方。 如果有这样一些逻辑， 你可能回来继续修补它，因为你有错，或你的逻辑或你理解改变了：思考使用规则。如果您对面临的难题，没有任何算法或模式：考虑使用规则。

       规则可以被嵌入到你的应用程序中，或可以象一个服务一样。通常规则引擎最好以一个“有状态”组件工作，作为应用程序的一个组成部分。然而，已有过创建可重用的无状态的规则服务的成功案例。对你的组织，决定你在生产的系统中将使用的更新规则的流程是重要的。选项很多，不同的组织有不同的需求。通常情况下，规则的维护脱离了应用程序供应商和项目开发人员的控制。

四、什么时候不使用规则引擎

       引用一个平常的 Drools 邮件列表：

       “在我看来， 在运用规则引擎的兴奋中， 人们忘记了规则引擎只是复杂应用程序或解决方案的一部分。

       规则引擎不是真正有意用于处理工作流和流程执行的， 工作流引擎或流程管理工具也不是设计来做规则的。为工作使用正确的工具。   当然，一个钳子在紧要关头可以被用来当锤打工具，但是它不是设计来做这个的。” --Dave Hamu

       因为规则引擎是动态的（在动态情况下，可以存储和管理规则，可以用数据更新规则），所以它们常常被看作部署软件问题的一个解决方案。（似乎多数 IT 部门存在的目的是防止软件被推出。）如果这是你希望使用规则引擎的理由， 请注意规则引擎最好工作在你能编写声明式规则时。作为替代方案，可以考虑数据驱动设计 （查看表） ， 或脚本处理引擎， 脚本在数据库中被管理， 并且能够被即时更新。