在你的企业级java应用中使用Drools

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

Drools
Drools 被设计为可插入式的语言实现。目前规则能用Java, Python和Groovy实现。更为重要的是，Drools提供了声明式程序设计(Declarative Programming),并且使用域描述语言(Domain Specific Languages (DSL))－专为你的问题域定义了某种模式的Xml, 它已经足够灵活到可以用来描述你的问题域。DSLs包含的XML元素(Element)和属性(Attribute)代表了问题域中各种要素。

(原文开始)
这段时间企业级Java简直能让你睡着。有多少J2EE-EJB应用程序只是从网页提取数据并把它们存入到数据库中?但开发者真正应该开发和维护的却是他们应用程序中复杂的商业逻辑。这个问题不仅仅适用于将要新应用，而且渐渐地，也适用于那些长期运行的商业核心应用，它们的内部逻辑也需要经常改变，而且往往要求在一个非常短的时间内。

在以前的文章中，“用Drools让你的商业逻辑使用框架”,我介绍了Drools框架，展示了它如何用来组织复杂的商业逻辑。Drool用一组简单的，众所周知的事物替换了许多缠杂的if…then表达式。如果你经历过和商业客户的会议，并为他们提出的想要实现的东西的复杂程度搞得头痛，或许你应该考虑一下像Drools这样的规则引擎了。这篇文章将向你展示如何在企业级Java应用中使用Drools.

一路到底的框架

大多数开发者都有自己喜爱的框架。无特定顺序，它们包括表现层框架（Struts, JSF, Cocoon和Spring）,持久化框架（JDO, Hibernate, Cayenne and Entity Beans）以及结构框架(EJB, 又是Spring, Pico和Excalibur), 还有其它很多。每种框架都各有所长，给开发者提供子许多“即开即用”的功能。使用框架来部署应用意味着你避免了许多让人厌烦的细节，让你集中注意力到关键之处。
到目前为直，在框架所能做的事中仍然有一个缺口，那就是商业逻辑没有框架。像EJB和Spring这样的工具虽好，但它们却几乎没有提及怎么组织你的那些if …then语句。把Drools加到你的开发工具箱中意味着现在你可以“一路到底”的使用框架来构建你的应用程序。图1显示了这样的一个应用


图1. 用于Java应用的框架

这篇文章将基于我们已经了解的Drools框架的功能，这些功能可以让我们构建这样的一个应用。]

我什么时候应该使用规则引擎？
“如果你有一把锤子，那所有的东西都看起来都像钉子”，这句话在软件工程领域几乎成了陈词滥调了。虽然规则引擎能解决我们的许多问题，但确实值得认真考虑一下规则引擎对我们的企业级Java应用是否合适。需要问的问题有：

● 我的应用程序有多复杂?对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你轻松应对这一切。

● 我的应用的生命周期有多久？这个问题的正确答案往往是“令人惊讶的长”――还记得那些认为他们的程序不会苟活到2000年的大型机的程序员吗？使用规则引擎将会在中长期得到好处。像这篇文章所展示的那样，甚至原型都能从Drools与灵活方法的组合中获益，让“原型系统”转化成生产系统。

● 我的应用需要改变吗？唯一能确定的是你的需求将会改变，无论是在开发过程中或是在开发完成以后。Drools使用一个或多个简单易配的XML文件帮你来应对这一切。

那么性能呢？
如果你正在写一个企业级应用，很有可能它会扩展到成百（如果不是成千）的用户。你已经知道现有的Java和J2EE应用能做到这一点，但一个使用了Drools的应用对这一压力的表现如何？答案是：“令人吃惊的好”。大多数开发者只是因为不愿“失控”而依赖于他人的代码（比如：某种框架），想想这个：Drools不仅可以让你的应用和“传统”的编程方法一样快，甚至可以更快,看下面：

● 避免糟糕的代码：Drools引导开发者去做“正确的事”。你可以确定你正在写的代码是好的，但你的开发伙伴呢？你可以同样这样说吗？使用框架可以让你更轻松地写出更快，更好的代码。

● 优化过的框架：你有多少次看见商业逻辑重复地从数据库中提取相同的信息，从而降低了整个应用的速度？如果正确使用的话，Drools不仅仅能够记住信息，而且还能记住以往使用该信息进行测试的结果，从而大幅提升应用的速度。

● Rete算法：很多次我们并不是真正需要使用“if”条件。被Drools实现的Rete算法，可以用一个优化的方法替换掉所有的“if…then”表达式。需要重点提及的是：Rete算法在使用更多的内存来降低运行时延迟方面作了折衷。当然这在现代的应用服务器中并不是一个问题，我们也并不推荐你在移动手机上使用Drools!

我们到哪里了？

在我们上一篇文章中，我们写了一个基于Drools引擎的简单的股票交易程序。我们实现了不同的商业规则，展示了我们可以如何迅速地改变规则去适应商业需求，并且JUnit测试给了我们高度自信可以确认系统确实是像我们设想的那样运作的。但是这个应用几乎没有用户介面，而且用硬编码代替了数据库。为了把我们的程序提升到企业级的水平，我们需要增加两个主要的东西。

● 某种用户介面，最理想的是基于标准的Web表现层的框架。
● 一个数据存取对象(DAO)让Drools与数据库（或其它后端）交互。

从现有表现框架中实现规则引擎

大多数企业级Java应用是通过Web介面进行交互的，其中最被广泛使用的Web表现层框架是Apache的Struts。理想的结果是：我们写的应用可以从表现层知道它下面的应用层,而不是通过相反的方向。它的好处在于不仅仅可以使我们将来变换其它的表现层（比如Ajax或web service界面），而且意味着示例代码可以非常容易地应用于其它像Spring的框架。

下面的代码片断演示了始何从Web表现层调用商业逻辑（通过规则引擎），并根据返回结果显示不同的页面。这一例子中，我们使用了一个Struts行为，但其代码是和使用其它表现层框架甚至一个Servlet或一个Jsp页面是很类似的。这个片断使用了struts-config.xml配置文件，JSP页面来上传/显示数据，并且生成WAR文件来进行布署。片断展示了怎样把规则引擎和web框架集成使用。

这个例子包含了几个东西。经常，我们需要的数据是用户通过好几个网页传来的，因此在这一例子中展示了通过session中的StockOffer对象来保存过去以来的数据。

下一步，如果用户改变了一些值，我们更新StockOffer对象。然后我们重置了rcommendPurchase标志用以在调用商业逻辑层之前清除以前的结果。最后我们使用商业逻辑层的返回来决定让用户转向哪一页面。

在这一例子中，需要注意我们将商业逻辑（买或不买一支股票）与表现层逻辑（决定转向哪一页面）分离开来。这将使我们可以在不同的应用中重用我们的商业规则。另外，看一下状态信息（用户已经告知我们的东西）是存储在Session中的StockOffer对象中的，并没有在商业层中。这样就保证了商业层的无状态性，这将使整个应用更具扩展性和性能。

集成规则引擎与数据库层

到目前为止，我们的应用已经有一个web表现层和一个商业层的规则引擎，但还没有方法与数据库进行交互。这一节的例子将展示如何实现。我们的例子是基于数据访问对象（DAO）模式的，它把所有与数据库（或后端数据源）交互的代码包装在了一个可插入，可配置的类中。同样的，这一例子一样适用于其它持久性框　架，比如Hibernate和Cayenne。
关于如何组织数据导有几个要点：

● 应该只有商业层与数据层交互。如果表现层（前端）需要一些数据，它首先应通过商业层。这将使我们的代码更容易组织和阅读。
● 尽可能地，我们应让我们的数据层无状态－我们应该在其它的地方存放客户端数据（比如：web前端的session，就像前面的例子）。这不同于我们可以在这一层做的数据缓存。两者的区别在于状态信息经常是用户定义的，而我们在数据层缓存的数据应该是整个应用共享的。这样的层次提升了性能。
● 我们应该让商业逻辑决定数据是否需要――如不需要，提取数据的调用就不应该执行。

为了实现我们简单的数据访问对象，我们创建三个新对象：StockNameDao, DaoImplementation,和 DaoFactory

StockNameDao是一个定义了两个方法的接口：getStockName()返回一个我们可以处理的股票名称的列表,isOnStockList()检查一个给定的股票是否在处理列表中。我们的商业层在需要这些信息时会调用这些方法。

DaoImplementation是StockNameDao的一个实现。这里的数据是硬编码的，但我们可以通过查询数据库或通过像Bloomberg这样的web service提取信息。

DaoFactory我们用来生成合适的StockNameDao实例。不直接创建对象而使用这一小骤的好处在于，它充许我们在运行时刻决定使用哪一个DAO实现（这是像Spring这样的框架特别擅长的）.一个factory（工厂）可以返回多种类型的DAO(比如：StockNameDao, StockPriceDao, StockHistoryDao),这意味着我们可以通过我们的DaoFactory,让规则自己决定需要什么数据和DAO.

这是StockNameDao接口：

简单的DaoFactory,只是返回DaoImplementation：

现在我们有了简单的DAO实现来作为我们的数据库层，那如何将它与Drools商业层集成在一起呢？最新的商业规则文件，BusinessLayer.xml将会向我们展示：

为了与数据访问层集成，该文件(相对于上一篇文章)有几处改变：
● 在最上面，我们有几个新的来把StockNameDao, DaoImplementation, 和 DaoFactory类引入系统。
● 我们有一个新的标记,它把DaoFactory的实例赋给一个变量。标记类似于参数，只不过它是运用于所有商业规则，而不只是一个。
● “股价足够低”的规则有一个新条件，它用DaoFactory和StockNameDao来检查股票是否在处理列表中。

我们又一次运行BusinessRulesTest(模拟器)。模拟单元测试没有问题，既使我们改变了程序的结构，我们仍然没有改变它在做什么。从输出的日志来看，我们可以看到我们的商业规则使用StockNameDao作为他们评估的一部份，并且DaoImplementation.isOnStockList()被调用了。
虽然这个例子展示的是从数据源读取信息，其实写信息也是一样的原理。如果某个规则决定应该做的话。区别在于我们的DAO将会有一些setSomeInformation()的方法，一旦条件满足，这个方法将会在商业规则的部分被调用。

总结
这篇文章中，我们展示了大多数Java服务器端的应用有的三层：表现层，商业逻辑层和数据持久化层。当框架被广泛地使用在表现层和持久层中，直到目前为止还没有框架可以包装低级的商业逻辑。就像我们在这些例子中看的，Drools和JSR-94是降低java应用复杂度，提高开发速度的理想候选者。我希望这些例程能鼓励你去进一步接近规则引擎，他们将会为你的应用的开发和维护节省不少时间。