Drools(JBoss Rules) 总结

  这是我主学的JBoss Rules,给大家简单总结一下。open和share这两种思想希望大家传承!

1、JBoss Rules简介

JBoss Rules(Drools )具有一个易于访问企业策略、易于调整以及易于管理的开源业务规则引擎,符合业内标准,速度快、效率高。业务分析师或审核人员可以利用它轻松查看业务规则,从而检验是否已编码的规则执行了所需的业务规则。
JBoss Rules 的前身是Codehaus的一个开源项目叫Drools。最近被纳入JBoss门下,更名为JBoss Rules,成为了JBoss应用服务器的规则引擎。
Drools是为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。具有了OO接口的RETE,使得商业规则有了更自然的表达。

既然JBoss Rules是一个商业规则引擎,那我们就要先知道到底什么是Rules,即规则。在JBoss Rules中,规则是如何被表示的

1.1    规则文件

一个规则文件通常是一个以 .drl 扩展名结尾的文件。在一个 drl 文件中,你可以有多条 rules , functions 等等。尽管如此,你也可以将你的规则分布在多个文件中,这有利于管理大量的规则。一个 DRL 文件是一个简单的文本文件。

1.2 规则的结构

一个规则结构大致如下:

 

rule  " name "
    ATTRIBUTES
    when
        LHS
    then
        RHS
end

 

可以看到,这是非常简单的。通常的标点符号都是不需要的,甚至连“ name ”的双引号都是不需要的。 ATTRIBUTES 是简单的,也是可选的,来提示规则的行为方式。 LHS 是规则的条件部分,需要按照一定的语法来写。 RHS 基本上是一个允许执行 Java 语法的代码的块(以后将会支持 groovy 和 C #)。任何在 LHS 中使用的变量都可以在 RHS 中使用。

注意:每行开始的空格是不重要的,除非在 DSL ( Domain Specific Language )语言中有特别的指明。

2、◆ 那么什么是规则引擎呢?

规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。接受数据输入,解释业务规则,并根据业务规则做出业务决策。

 3、◆ 使用规则引擎的好处

■ 声明式编程:规则引擎允许你描述做什么而不是如何去做

■ 逻辑与数据分离:数据保存在系统对象中,逻辑保存在规则中。这根本性的打破了面向对象系统中将数据和逻辑耦合起来的局面

■ 速度及可测量性:Rete算法、Leaps算法,以及由此衍生出来的Drools的Rete、Leaps算法,提供了对系统数据对象非常有效率的匹配

知识集中化:通过使用规则,将建立一个可执行的规则库。这意味着规则库代表着现实中的业务策略的唯一对应,理想情况下可读性高的规则还可以被当作文档使用

■ 工具集成:例如Eclipse(将来可能在基于Web的界面上)这样的工具为规则的修改与管理、即时获得反馈、内容验证与修补提供了办法。审查与调试工具同样也可用了

■ 解释机制:通过将规则引擎的决断与决断的原因一起记录下来,规则系统提供了很好的“解释机制”

■ 易懂的规则:通过建立对象模型以及DSL(域定义语言),你可以用接近自然语言的方式来编写规则。这让非技术人员与领域专家可以用他们自己的逻辑来理解规则(因为程序的迷宫已经被隐藏起来了)

 

 

4、◆ 适合使用规则引擎系统的场合

■ 用传统的代码开发比较复杂、繁琐

■ 问题虽然不复杂,但是用传统的代码开发比较脆弱,也就是经常修改

■ 没有优雅的算法

■ 业务规则频繁改变

■ 有很多业务专家、不懂技术开发

 5、◆ 不适合使用规则引擎系统的场合

虽然规则系统看起来比较不错,但是并不是任何地方都可以使用规则系统。很多简单、固定的业务系统,可以不用使用规则系统。规则系统也不能用来作为标示重要的业务流程、不能用来作为工作流引擎。

 

有很多程序员把规则系统当成是一种动态修改配置。也就是把一部分代码逻辑抽取到外面,统一存放起来。这样,当一些配置修改的话,通过修改规则,就能修改代码的一部分逻辑。如果把规则仅仅用在这个场合下的话,可以考虑采用脚本引擎。比如BeanShell、JEXL、Groovy等等。

posted @ 2016-11-02 19:32  青春不再见  阅读(2692)  评论(0编辑  收藏  举报