drools规则引擎

 J2EE应用中的应用框架不计其数，通用的框架能够解决常用的系统架构的客户端与服务器端的功能，如何组织企业应用中的业务逻辑，仍必须靠手工的代码来解决。随着大量业务规则的变化，导致应用程序不停的变更，如果能找到一种解决商业逻辑的架构，来解决当商务规则不停的变化时，可以保证我们的应用系统具有较好的柔韧性，可以适应特定的商务规则的变化，而无需修改我们的应用系统。Drools就是这样的一个应用在商务逻辑层的架构。

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


为什么用规则引擎：

商业世界充满了关于变化的陈词滥调，如任何事物都会改变，唯一不变的是变化等等。而在技术领域里，情况正好相反。我们仍然在试图解决30年前软件业中同样的一堆问题－－也许比30年前还要多的问题。在过去的十年，IT从业人员淹没在软件方法学的大量文献中，如快速软件开发，极限编程，敏捷软件开发等，它们无一例外地强调灵活和变化的重要性。

虽然IT团队反应迅速，但他们通常带来"电话效应"――IT给商业计划的执行带来的阻力和它带来的利益一样多。不幸的是，在开发团队完全理解商业决策规则并实现之前，规则已经改变了。在软件进入市场前，它已经过时了，需要进行重构以满足新的业务需求。如果你是一个开发人员，你会知道我在说什么。再也没有比在需求变动的情况下构造软件让开发人员更沮丧的事情了。作为软件开发人员，你必须比业务人员更了解业务，有时还要了解更多。
试想一下你是一位商业决策者。假如公司的成功依赖于你对于市场趋势敏锐的洞察力，它常常帮助你领先于竞争者利用变化的市场环境获利。每天你都会得到更多更好的市场信息，但并不要紧。完成新产品开发可能需要6－9个月，在此期间，对于市场大胆和敏锐的洞察和信息优势可能已经浪费了。而且，当产品发布时，有这样几种可能：产品没有什么吸引人的特性，预算超支，过了产品的最佳发布期限，或三者兼而有之。
情况可能还会更糟，在完成产品开发时，市场环境和规划产品开发时相比，已经发生了根本变化。现在你必须要遵守新的规则，你已经丧失了你的边际优势，而且设计软件的五人中的三人已经离开了公司。你必须给接手的新人重新讲解复杂的业务。如果事情不顺利，你可能发现自己要对付一个缺少文档，并且你完全不了解的遗留应用。
你的战略在哪出现了问题？你在哪里应该可以做到更好？最近的轻量级软件过程，如极限编程，敏捷软件开发等都在强调自动单元测试和软件功能优先级的重要性。除此之外，还有其他的原则，你的开发团队可能也很熟悉，这些原则可以帮助他们对需求的变动作出迅速反应并缩短项目的开发周期。这些原则的大多数，如系统分解，多年前就已经出现，并得到了Java平台的支持（如JMX等），还有如面向对象和角色建模，已经内建在Java语言中。
但Java仍然是一门相当年轻的语言，而且Java平台远远还没有完备。当前在Java社区，一个引人注目的新技术是，分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库，让它们能在运行时（即商务时间）可以动态地管理和修改。这是一个你值得考虑的策略。
为什么你的开发团队不得不象商业经理人一样，在代码中包含复杂微妙的商业决策逻辑呢？你怎样才能向他们解释决策推理的微妙之处呢？你这样做是否谨慎呢？可能不是。象bottom line一样，某些东西在解释的过程中丢失了。为什么要冒这样的风险，让应用代码或测试代码错误地表达你的商业决策逻辑呢？如果这样做的话，你怎样检查它们的正确性呢――难道你自己想学习如何编程和编写测试代码，或者你的客户会为你测试软件？你一方面要应付市场，一方面要应付软件代码，这实在太困难了。
如果能将这些商业决策规则集中地放在一个地方，以一种你可以理解的格式定义，让你可以直接管理，而不是散落在代码的各个角落，那该有多好。如果你能把商业决策规则独立于你的软件代码，让开发团队作出技术决策，你将会获得更多好处。你的项目开发周期会更短，软件对于变动的需求更灵活。


使用规则引擎的条件：

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

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

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