JBossRulesUserGuide 主要部分的翻译

JBossRulesUserGuide （即Drools参考手册）主要部分的翻译──见附件。
原文地址：
http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/3.0.6/html_single/index.html

Drools手册是学习Drools最好的教材，网上中文资料很少，下面的博客里有博主的对Drools手册的几个部分的翻译：
http://www.blogjava.net/guangnian0412/
我觉得手册中的3. The Rule Language部分比较重要，是写规则的基础。
手册中的1.6. The Drools Rule Engine部分，我的文档中没有加入翻译，需要的话可以参考这个博客。

翻的不好，希望对需要的人能有帮助。

还是看英文的好...
几个概念其实都是从数学里面搬过来的,但似乎这些数学也只有E文的

对，当然是看英文的好！
我自己对英文资料的体会是，每次看时都要在大脑中反应成中文（可能还是英文不好吧），浪费时间。翻过来，下次再看就省时间了。

我当时注册成JavaEye的会员就是为了在这里问关于Drools的问题，我这个文档其实是给自己用的，有些翻不好的地方就直接用英文代替着，随时觉得哪段会常用到就再补充进去。
发到这来，主要是想体验一下，当然最好是有人觉得有用啦^_^

最近改变了对drools的看法，它的适用领域比想象的要小很多。

讨论一下？我也在研究这个东东，我感觉出了规则匹配以外，随时变也是个很好的东西，我就拿来当java代码用，这个东西都方便。说说你用Drools遇到的问题和困惑，我学习学习 

1. 调试困难
2. 严重依赖IDE
3. 为了提供客户个性定制匹配的功能，你需要建立一套复杂的规则录入界面。(天啊，已经和商业规则引擎很像了)
4. 需要如此复杂的机制来处理的业务领域很少。
5. 没有FROM、COLLECT之前易用性很差(3.0.X)，甚至妨碍到了建模，和OO思想并不特别搭调。

1 严重同意，我目前最怕的也是这个
2，3 同意，但是不认为是主要问题，确实用不起iLog，用这个也能解决很多问题，免费嘛。我的思路是界面能提供多少就多少。
4.我觉得用来耦合东西挺爽，我目前做的东西似乎无一例外用规则要方便点
5.我还没有深入的体会，可否把以前你写的一些东东共享一下？或者说明一下具体的用法。我现在也遇到了一些问题，还没有解决思路

BTW: 你的 3.0.x 这个x具体多少？我用的3.0.4 可以用Form collect么？

你的界面能提供的东西很少，更何况这主要取决于客户的需求。
下面用一个客户需求变更的实例来说明你将会遇到的窘境。
一般客户需要定制的部分由几个部分组成：(顺序为客户需求的不断改变)

1. 定制LHS中的数值

2. 定制RHS中的行为

3. 定制LHS中的匹配公式

4. 定制LHS中匹配条件的个数和优先级


其中1是最容易解决的，在数据库中构建类似决策表的机制就能满足用户的需求。

rule "Sample"
  when
    $foo : Foo()
    $para : Parameter()
    #bar数值和数据库中的因子相符则匹配上
    eval($foo.getBar().equals($para.getValue()))
  then
    #doSomeThing
end

2也比较容易解决，可以塞一个global到workingMemory或者干脆把service当作fact塞进去。

rule "Sample"
  when
    $service : Service()
  then
    $service.doSomeThing()
end

3对于客户来说是十分常见的需求，而对于DRools而言却很难实现(无法想象客户在没有IDE的支持的情况下，在界面上编辑drl)，这也是我所说的drools严重依赖ide的原因。
我最终用了一个折中的方法来解决，允许用户自己录入表达式，用表达式解析器来判断是否匹配

rule "Sample"
  when
    $foo : Foo()
    $para : Parameter()
    $exp : Expression()
    #expression类似(bar == p1)
    eval(ExpressionHelper.isValidate($exp,$foo,$para))
  then
    #doSomeThing
end

-_-已经开始有不祥的预感了，这还是我的drools吗？

姑且不讨论4这样的需求是否合理，但是确实已经无法用drools来实现，不是由于drools的技术不够强大，而是由于这是drools原生支持的功能，除了修改drl以外没有其他方法可以做到。
啥？可以这样搞定？

  //获取按照优先级排序后的规则名
  List ruleSets = ruleManager.getSortRules();
  for (Iterator iter = ruleSets.values().iterator(); iter.hasNext();) {
      String ruleName = (String) ruleSets.next();
      //根据规则名执行规则
      ruleTemplate.execute(ruleName, facts);
  }

rule如下：

#调用同一个模板Rule
rule "Sample"
  when
    $foo : Foo()
    $para : Parameter()
    $exp : Expression()
    eval(ExpressionHelper.isValidate($exp,$foo,$para))
  then
    #doSomeThing
end

情况变得很糟糕，已经失去了用drools的必要，而且模板失去了Drools的很多特性(modify?group? 88)。

为啥说3.0.x易用性差，为啥和OO不搭调？
下面用一个算佣金的例子来说明

/**
 * 佣金项
 */
public class Element {

  private String eleCode;
  
  /** 结算公式 **/
  private String expression;
  
  /** parts **/
  private Set parts = new HashSet()
  
  ...
  
}

/**
 * 佣金的组成项目
 */
public class Part {
  
  private Element element;
  
  private Strint partCode;
  
  private String expression;
  
  /** 因子项 **/
  private Set factors = new HashSet();

  ...
  
}

/**
 * 因子
 */
public class Factor {

  private Number value;
  
  private String factCode;
  
  private Part part;
  
  ...

}

下面我们来完成一个在规则中计算佣金的流程

rule "Sample"
  when
    $element : Element()
    $part : Part() from $element.getParts()
    $factor : Factor() from $part.getFactors()
    #判断佣金类型是否匹配
    #也可以写成 $element : Element( eleCode = "SomeElement")，但是如果SomeElement的值会发生改变，一切就太可怕了
    eval($element.getEleCode().equals(ElementSupport.SomeElement))
    #判断佣金组成项类型是否匹配
    eval($part.getPartCode().equals(PartSupport.SomePart))
    #是否匹配某些规则
    eval(someRule.......)
  then
    #doSomeThing
end

上面这是我们最正常的处理流程，但是遗憾的是3.0.X并不支持from -_-。
你不得不自己在对象中建立双向引用，而不是直接使用List或者诸如此类的容器。


另一个让人遗憾的地方是上面的代码效率并不高

rule "Sample"
  when
    $factor : Factor() from $part.getFactors()
    #判断佣金类型是否匹配
    eval($factor.getPart().getElement().getEleCode().equals(ElementSupport.SomeElement))
    #判断佣金组成项类型是否匹配
    eval($factor.getPart().getPartCode().equals(PartSupport.SomePart))
    #是否匹配某些规则
    eval(someRule.......)
  then
    #doSomeThing
end

这段代码在3000个对象的情况下至少可以比上面一段代码提升30%的性能,但是咋就感觉怪怪的？

这种文档还是看原文，技术文体翻译过来要么面目全非，要么羞涩难懂，汁味全无。真正精华的部分往往是翻译的最差的部分。

读原文刚开始都会不适应，逼一逼自己过了这道槛就好了。