JBoss Rules入门指南.ppt

Right Hand Side Right Hand Side （ RHS ）就是规则的结果（ consequence ）或者动作（ action ）部分。实际上， RHS 是当规则激发（ fire ）时执行的then语句代码块。 在 RHS 中，有几个方便的 method 可以改变 WorkingMemory ： “ modify(obj) ”：告诉引擎一个对象已经发生变化，规则必须重新匹配（ obj 对象必须是出现在 LHS 中的对象）； “ assert(new Something()) ”：将一个新的 Something 对象加入 WorkingMemory ； “ assertLogical(new Something()) ”：与 assert 方法类似。但是，当没有 fact 支持当前激发规则的真实性的时候，这个新对象Something会自动被 retract ； “ retract(obj) ”：从 WorkingMemory 中移除一个对象。 以上的这些methods其实是Jboss Rules提供的KnowledgeHelper函数的DRL语言封装。而且与modify函数类似的，都会引起规则的重新匹配。 杂项官方的Examples 请先下载Drools 5.0 Examples 然后在安装好Jboss Rules插件的Eclipse中新建一个Drools Project 然后将源码都拷贝到新建的工程中 切记，因为官方Examples的工程依赖设置有误，我们不能直接从下载的zip包中导入官方的Examples工程，必须遵照以上步骤来导入。 ?这些样例足够丰富。请参考官方文档关于这些样例的介绍 规则引擎可以配置成有状态的。在这种状态下，被规则X处理过的对象如果在处理之后符合另外的规则Y，则再次被规则引擎过滤，以此循环反复。这样有状态的规则处理，性能开销较大。但这也正是我们希望规则引擎能够处理的复杂性。 无状态的规则处理，不会引起连锁调用。无状态的规则可以类比为用规则语言Rules来写的简单java函数。规则引擎不需要对无状态规则进行推理，它只需要将之编译成等价的java helper methods。在运行时只是简单的method calls 有状态的规则处理，规则引擎会在所有计算完成之前保留对数据对象的引用，以便反复对照计算 在状态的规则运算中，需要显式的表达 在规则文件中，如果希望被更新的对象能被其他规则再次处理，则用关键字modify、insert、retract等来更新对象 如果在java 代码中做了一些动作，希望规则引擎能够对这些细粒度的更新有所反应，则需要通过调用WorkingMemory的相应方法，来通知规则引擎 复杂的规则运算基本上都是有状态的 之前看到的DRL代码，对有编程语言经验的人来说是容易足够友好的。但由于离自然语言还有一大段距离，对于领域专家或者编写业务规则的人来说则不够亲切。综合使用DSL、DRL可以大大提高可读性： 首先是定义DSL 然后在DRL中引入这一个DSL文件，就可以使用非常接近自然语言的人工语言来编写业务规则了。关键字expander暗示，DSL类似于C语言中的宏展开，采用的是一种字符替换机制。 编译规则生成规则集对象RuleBase的开销很大。而用RuleBase生成WorkingMemory则是轻量级的。 因此，在实际开发中，应该缓存编译后的规则集对象RuleBase 。 WorkingMemory将动态的数据(POJO)与缓存的规则集RuleBase结合起来，计算并且更新POJO。计算完毕之后， WorkingMemory就被废弃了。而缓存的规则集还可以保留着，等待下一次计算的使用。 规则有可能会被动态更新，如果有缓存，则可能带来同步问题。 杂项在执行规则时如何捕捉异常 如果异常是在执行更新(RHS)结果时发生的，则可以这样捕捉： 首先，实现接口” org.drools.runtime.rule.ConsequenceExceptionHandler”，假设该实现类名为” CustomConsequenceExceptionHandler”。我们通过实现方法里传进起来的三个参数来获取信息，并处理异常 最后，将该handler实现设置为KnowledgeBaseConfiguration的异常处理器 Jboss Rules所提供的异常处理机制没有将异常进行层层的包装。例如，Javabean的setter在被规则引擎调用时抛出了MyException，则传给CustomConsequenceExceptionHandler的也是MyException。 在执行一条规则的when语句(LHS)时发生的异常，不能用以上的方法来捕