Intelli的专栏

要求施加在当今软件产品上的大多数复杂性是行为和功能方面的，从而导致组件实现具有复杂的业务逻辑。实现 J2EE 或 J2SE 应用程序中业务逻辑最常见的方法是编写 Java 代码来实现需求文档的规则和逻辑。在大多数情况下，该代码的错综复杂性使得维护和更新应用程序的业务逻辑成为一项令人畏惧的任务，甚至对于经验丰富的开发人员来说也是如此。任何更改，不管多么简单，仍然会产生重编译和重部署成本。规则引擎

http://jcp.org/en/jsr/detail?id=94 

什么是Drools(译者增加：什么是Drools, 摘自drools.org)Drools 是一个基于Charles Forgys的Rete算法的，专为Java语言所设计的规则引擎。Rete算法应用于面向对象的接口将使基于商业对象的商业规则的表达更为自然。Drools是用Java写的，但能同时运行在Java和.Net上。DroolsDrools 被设计为可插入式的语言实现。目前规则能用Java,

复杂企业级项目的开发以及其中随外部条件不断变化的业务规则(business logic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。本文第一部分简要介绍了规则引擎的产生背景和基于规则的专家系统，第二部

1.Rete 算法 ：Rete 在拉丁语中是 ”net” ，有网络的意思。 RETE 算法可以分为两部分：规则编译（ rule compilation ）和运行时执行（ runtime execution ）。 编译算法描述了规则如何在 Production Memory 中产生一个有效的辨别网络。用一个非技术性的词来说，一个辨别网络就是用来过滤数据。方法是通过数据在网络中的传播来过滤数据

1 Facts Facts 是从你的应用中，被 assert 进 WorkingMemory 中的对象（ beans ）。 Facts 是规则可以访问的任意的 java 对象。规则引擎中的 facts 并不是“ clone ” facts ，它只是持有到你的应用中数据的引用。 Facts 是你的应用数据。 String 和其他没有 getter 和 setter 的类不是有效的 Fact 。这

 1．概述： Drools 3 采用了原生的规则语言，那是一种非 XML 文本格式。在符号方面，这种格式是非常轻量的，并且通过“ expanders ”支持符合你问题域的 Domain Specific Language （ DSL ）。这一章把焦点放在了 Drools 原生的规则格式。如果你想从技术上了解规则语言的机制，可以参考“ drl.g ”源文件，这是用 Antlr3 语法来描述规

动机　　更新业务流程的平均周期已经从1980年的84个月缩短到了现在的6个月，而且IT解决方案交付周期也从30个月缩短到了3个月（参见图1）。在银行业也是这样。其中的核心元素包括银行业的工业化、消费者需求的更改、竞争的日趋激烈以及政府调控的影响。另外，银行的业务环境和操作流程也在不断变化。但是，当试图使受影响的软件系统适应这些改变时，出现了很大的延迟。从技术的观点来看，有高度适应性和灵活性是很有必

下载地址： http://labs.jboss.com/portal/index.html?ctrl:id=page.default.downloads&project=jbossrules 下载文件说明： JBoss Rules 3.0.1 Binaries (includes javadocs) （ 13MB ）― 仅仅包含 JBoss Rules 的四个核心类库：  droo