javajohn

   大部分 web 以及企业级 Java 应用可被分成三部分：与用户交互的前台，与数据库这样的后台系统交互的服务层，以及它们之间的业务逻辑。最近这段时间，通常我们会使用框架来实现前台和后台的需求（例如：Struts, Cocoon, Spring, Hibernate, JDO, 以及实体 Beans），但是却没有一种标准手段很好的组织业务逻辑。像 EJB 和 Spring 这样的框架都以 high level 方式处理，这无助于组织我们的代码。除非我们改变这种凌乱，否则系统将不会健壮，框架中杂乱的 if...then 语句能带给我们可配置性、可读性的优点，以及在其他地方复用代码的愉悦吗？本文将介绍如何使用 Drools 规则引擎框架来解决这些问题。
   
    下列的范例代码展示了我们正要试图努力避免的问题。展示了包含一些业务逻辑的 Java 典型应用。

    我们经常写出类似的（甚至更复杂）业务逻辑。当这些用 Java 实现的业务逻辑成为标准方式时，将存在下列问题：
   
        业务用户怎样在这些难以理解的代码基础上添加另一个条件（比如"C987"）？一旦最初开发这些程序的员工离开了，你想成为维护这些代码的人吗？
        我们怎样检查规则的正确性？对业务伙伴的技术人员来说都够复杂的了，更不要说检查。我们可以有系统的测试这些业务逻辑吗？
        很用应用都有相似的业务规则－－当其中的一个规则改变，我们能保证这一改变可贯穿整个系统？当新应用使用这些规则，该应用已经部分添加了新的规则，但不完全，我们要把逻辑重写过吗？
        我们经常需要对每个细小调整所带来的改变进行重编译/重部署，而不是坚实的依靠 Java 代码，业务逻辑是否易于配置？
        可否复用已存在的用其他（脚本）语言编写的业务规则逻辑？
       
    J2EE/EJB 以及“IoC inversion of control”框架（比如 Spring,Pico,以及 Avalon）给我们带来的是 high level 代码组织能力。在提供良好复用性、可配置性、以及安全性的同时，没有一个能替代（解决）以上的“spaghetti 代码”范例出现的问题。理想地，无论选择何种框架，不仅仅适合 J2EE 应用，而且也可用于“normal”Java（J2SE）程序，以及大部分普遍采用的表现层以及持久层框架。这种理想框架应该允许我们这样做：
   
        业务用户应该可以方便的阅读和校验业务逻辑。
        业务规则应该可被复用，并可以通过程序进行配置。
        这种框架应该是可升级的，并在高负载情况下运行。
        Java 程序员可以像使用现有的前台（Struts,Spring）和后台（ORM object-relational mapping）框架一样方便地使用这个框架。
       
    另外的问题是，有许多的 web 页面、数据库访问组织方式，业务逻辑在这两种应用中应趋于不同。而框架应该能应付这些并促进代码复用。理想的框架将能“frameworks all the way down.”，通过这种方式使用框架，我们能在应用中大量的“out of the box”，这样我们只为客户记录添加值的部分。
   
规则引擎前来救援

    我们怎样解决问题呢？一种方案是通过规则引擎获取 traction。规则引擎是为组织业务逻辑应运而生的框架，它让开发者专注于做被认为正确的事情上，而不是以 low-level 方式作出决定。
   
    通常，业务用户舒适的表达他们知道的正确的事，而不是 if...else 格式的表达方式。你也许能从业务专家听见这些东西：
   
    “FORM 10A 用来索取额外 200 欧元费用。(FORM 10A is used for expense claims over 200 Euro.)”
    “我们只进行数量在 10,000 以上的贸易。”
    “购买大于 €10m 的要经过公司董事批准。”
   
    通过专注于我们认为正确的事情上，而不是只知道怎样用 Java 代码表达，那么上面的叙述将比之前的代码范例更清晰。我们仍然需要一种机制为我们知道和做决定的事实应用这些规则。这种机制就是规则引擎。
   
Java 中的规则引擎
   
    JSR 94，如同 JBDC 允许我们与多种数据库交互一样，javax.rules 是一组与规则引擎交互的通用标准 API。为什么 JSR-94 没有详细说明实际的规则怎样书写，有下面大量的 Java 规则引擎可供选择：
   
    Jess 或许是最成熟的 Java 规则引擎，有良好的工具支持（包括 Eclipse 插件）以及文档。但是，它是商业软件，而且用 Prolog-style 符号书写规则，对 Java 程序员来说是很晦涩的。
    Jena 是一套开源框架，最初由惠普发起。虽然它有规则引擎以及在 Web 语义方面特别强大，但它并不与 JSR-94 兼容。
    Drools 是与 JSR-94 兼容的规则引擎，并且在 Apache-style 许可下完全开源。它不仅用熟悉的 Java 和 XML 语法表述规则，而且它还有强大的用户、开发者社区。在本文中有范例，我们将使用 Drools，因为它有最容易使用的类似 Java 的语法以及完全开发许可。
   
利用 Drools 开始 Java 开发

    假设有这样的场景：在阅读本文的数分钟后，你老板要求你做一个股票交易应用原型。这时，业务用户尚未被完全定义业务逻辑，你马上会想到最好的办法是用规则引擎实现。最终系统将可通过内部网访问，而且还要和后台数据库以及消息系统通讯。在着手行动前，先下载 Drools 框架（与支持库一起）。在你喜欢的 IDE 中创建新项目，确定所有 .jar 文件被引用进项目，如图 1 中所示。截图是基于 Eclipse 的，不过在其他 IDE 中创建也是相似的。

     
                   图 1. 运行 Drools 所需要的库(2.5版本可从http://dist.codehaus.org/drools/distributions/drools-2.5-final-bin-withdeps.zip下载包括支持库)

    
    如果我们的股票交易系统很混乱，将失去大量潜在客户（商机），所以在系统的整个步骤中放入一些模拟器（simulator）是至关重要的。这种模拟器给了你决心采用该系统的信心，甚至规则改变以后所带来的麻烦。我们将借助敏捷工具箱中的工具，以及 JUnit(http://www.junit.org/) 框架进行模拟。
   
    如下，我们写的第一段代码是 JUnit 测试/模拟器。即使我们无法测试每个对应用有价值的输入组合，但有测试也比没有测试的好。在这个范例中，所有的文件和类（包括单元测试）都放入一个文件夹/包中，但实际上，你可能会用一种适当的包、文件夹结构。范例代码中我们用 Log4j 代替 System.out 调用。

    这是最基本的 JUnt 测试，我们知道我们的系统应该买所有低于 100 欧元的股票。很明显，要是没有数据持有类（StockOffer.java）和业务层类（BusinessLayer.java）它将无法编译。这两个类如下。

    StockOffer 是这样：

    通过 IDE 的 JUnit 插件运行 BusinessRuleTest。如果你不熟悉 JUnit，可在 JUnit 网站找到更多信息。不必惊讶，如图 2 所示第二个断言测试失败，这是因为还没把业务逻辑放在适当的地方。测试结果用高亮显示了模拟器/单元测试所出现的问题，这是很保险的。

 
              图 2. JUnit 测试结果
             
用规则编写业务逻辑
   
    在这里，我们要写一些业务逻辑，来表达“一旦股票价格低于 100 欧元，就马上购买。” 要达到这个目的，需调整 BusinessLayer.java：

    这个类有些重要方法：
   
    loadRules()，从 BusinessRules.drl 文件加载规则。
    更新后的 evaluateStockPurchase()，用于评估业务规则。这个方法的注解如下：
        可以反复复用相同的 RuleSet（内存中的业务规则是无状态的）。
        为每次评估构造新的 WorkingMemory，因为我们的知识知道这个时刻是正确的。使用 assertObject() 放置已知事实（作为 Java 对象）到内存中。
        Drools 有个事件监听模式，允许我们“查看”事件模型中到底发生了什么。在这里我们用它打印 debug 信息。
        working memory 类中的 fireAllRules() 方法评估和更新规则（在本例中是股票出价）。
   
    再次运行该范例前，需要创建我们的 BusinessRules.drl 文件：

    该规则文件有些有趣部分：
   
        只有在 XML-Schema 定义 Java 对象之后，我们才能引用进规则。这些对象可以是来自于任何必须的 Java 类库。
        接下来是 functions，它们可以与标准 Java 代码进行混合。既然这样，我们干脆混入些日志功能来帮助我们观察发生了什么。
        再下来是我们的 rule set，rule set 由一到多个规则组成。
        每个规则可持有参数（StockOffer 类），并需要实现一个或多个条件，当条件符合时，将会执行相应结果。
       
    在修改和编译完代码后，再次运行 JUnit 测试。这次调用了业务规则，我们的逻辑进行正确地评估，并且测试通过，参看图 3。恭喜－－你已经构建了第一个基于规则的应用！

   
    图 3.成功的 JUnit 测试
   
使规则更聪明

    刚刚构建好应用，你就向业务用户示范上面的原型，他们却忽然想起先前并没有提出的规则。其中一个新规则是当数量是负数时（<0）不能进行股票交易。“没关系，”你说，接着回到办公桌上，紧扣已有知识，快速演化你的系统。
   
    首先要更新模拟器，把以下代码添加到 BusinessRuleTest.java：

    这个测试是为业务用户描述的新规则建立的。正如意料之中的，如果运行 JUnit 测试，我们的新测试将失败。所以，我们要添加新的规则到 .drl 文件：

    这个规则的格式和前面的相似，除了 （用于测试负数）以及 用于设置推荐购买为 No 以外。我们再次运行测试，这次通过了。
   
    这时，如果你习惯于过程化编程（像大多数 Java 程序员一样），你也许要搔头皮了：在一个文件中包含两个独立的业务规则，而且我们也没告诉规则引擎哪个更重要。不管怎样，股票价格（对于 -22）都满足两个规则（也就是少于 0 和少于 100）。尽管这样，我们仍能得到正确结果，即使交换规则顺序。这是怎么做到的呢？
   
    下面的控制台输出有助于我们了解到底怎么回事。我们看见两个规则都执行了（[activationfired] 这行），Recommend Buy 第一次被设置为 Yes 接着又被设置成 No。Drools 怎么知道执行这些规则的正确顺序呢？如果你观察 Stock Price Low Enough 规则，将发现 recommendPurchase() 其中一个条件为空。通过这点，Drools 规则引擎足以判断 Stock Price Low Enough 规则应该在 Stock Price Not Negative 规则之前执行。这个过程称为 conflict resolution。

FIRE RULES
----------
[ConditionTested: rule=Stock Price Not Negative;
  condition=[Condition: stockOffer.getStockPrice()
  < 0]; passed=true; tuple={[]}]
[ActivationCreated: rule=Stock Price Not Negative;
  tuple={[]}]
[ObjectAsserted: handle=[fid:2];
   object=net.firstpartners.rp.StockOffer@16546ef]
[ActivationFired: rule=Stock Price Low Enough;
   tuple={[]}]
[ActivationFired: rule=Stock Price Not Negative;
   tuple={[]}]
Name:MEGACORP Price: -22 BUY:YES
Name:MEGACORP Price: -22 BUY:NO

    如果你是一名过程化程序员，无论你用怎样聪明的方式考虑这些，你都不会完全相信。这就是为什么要进行单元/模拟器测试的原因：进行 "坚固的" JUnit 测试（使用一般 Java 代码）确保规则引擎所作出的决定是按照我们所想要的路线进行。（不会花费大量金钱在无价值的股票上）同时，规则引擎的强大和伸缩性允许我们快速开发业务逻辑。
   
    稍后，我们将学习如何用更加精练的解决方案进行冲突处理。
   
冲突结局方案

    现在业务伙伴被打动了，并且开始考虑进行选择了。随即他们遇到了个 XYZ 公司股票的问题，那么我们来实现新规则吧：只有 XYZ 公司股票低于 10 欧元才可购买。
   
    像以前一样，添加测试到模拟器，接着在规则文件中包含新业务规则。首先在 BusinessRuleTest.java 中添加新方法：

    接下来向 BusinessRules.drl 中添加新 ：

    注意业务规则文件，在 rule name 后面，我们把 salience 设置成 -1（到目前为止了解的最低优先级）。大多数规则在系统中是冲突的，这意味着 Drools 必须为规则的执行顺序做判断，假设这些条件都与规则匹配。默认的判断方式是：
       
    Salience：赋予的值。
    Recency：使用规则的次数。
    Complexity：首先执行有复杂值的特定规则。
    LoadOrder：规则载入的顺序。
   
    如果没有显示的在规则中详细指明，将会发生：
   
    XYZ 公司规则（"当价格高于 10 欧元就不购买 XYZ 的股票"）将先执行（Recommend Buy 标志被设置为 No）。
    接着更多的一般规则（"购买所有 100 欧元以下的股票"）被执行，把 Recommend Buy 标志设置为 yes。
   
    这会给我们一个不想要的结果。然而，一旦在范例中设置了 saliency 要素，最终的测试和业务规则将像预期的那样顺利运行。
   
    大多数时间，编写清晰的规则和设置 saliency 将给 Drools 足够信息以选择合适的顺序执行规则，有时我们想改变整个规则冲突处理方式。下面的例子说明了如何改变，告诉规则引擎首先执行最简单的规则。要注意的是：改变冲突解决方案要小心，它可能从根本上改变规则引擎的行为。

    我们的简单应用由 JUnit 测试驱动，我们不必改变 Drools 处理规则冲突的方式。知道冲突解决方案怎样运作是很有用的，尤其当你的应用为了迎合更复杂、更苛刻的需求时。
   
结束
   
    本文示范了大部分程序员不得不面对的问题：怎样安排复杂业务逻辑的顺序。我们示范了一个使用 Drools 作为解决方案并引入基于规则编程概念的简单应用，包括了怎样在运行时处理规则。接着，后续文章使用这些技术并展示了怎样在企业级 Java 应用中使用。

原文地址:http://www.onjava.com/pub/a/onjava/2005/08/03/drools.html（第一次看到外国人的文档写得这么不负责任）
原译者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen
本文仅供学习,不得随意引用、转贴