Drools应用手册版本日期修改历史作者0.12010年8月27日文档创建刘俊豪目录TOC\o"1-3"\h\z\u1简介11.1什么是规则引擎？12Drools工作原理33Drools实战13.2HelloDrools23.3.12LHS(when)条件元素17简介本文档是描述如何去使用Drools的文档，重点放在规则的语法和用法上，可让读者在编写规则是查阅，因此对于Drools的实现原理就不会详尽的介绍，如果读者有兴趣可以联系本文作者索取相关资料。什么是规则引擎？在大型商业系统中，业务规则、商业逻辑等等都会比较复杂。而且在很多大型系统当中，很多业务规则、商业逻辑并不是一成不变的。甚至当系统进入生产阶段时，客户的业务规则、商业逻辑也会改变。某些系统要求甚至更高，要求能24小时不停机，并且能够实时修改商业规则。这就对商业系统提出了较大的挑战。如果将这些可变的规则直接编写到代码里面的话，业务规则一旦改变，就要修改代码。并由此带来编译、打包、发布等等问题。这对于生产系统来说是极不方便的。因此，如何考虑把一些可变的业务规则抽取到外面，使这些业务规则独立于程序代码。并最好是能够实时的修改业务规则，这样就可以做到不用打包编译发布等等。因此，规则引擎营运而生。规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。使用规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性，降低应用程序的维护和可扩展性成本。大多数规则引擎都支持规则的次序和规则冲突检验，支持简单脚本语言的规则实现，支持通用开发语言的嵌入开发。目前，市面上应用产生了众多的规则引擎。开源规则引擎的代表是Drools；商业规则引擎的代表是ILog。Drools简介Drools(又称JBossRules)是JBoss开源社区中的一个为Java量身定制的、基于RETE算法的产生式规则引擎的实现。，本文档是基于此版本来描述，所有例子都是基于Drools。读者可到Drools的官方网站下载Drools的相应版本()。何时使用Drools对这个问题最简短的回答就是“当没有令人满意的传统的程序设计方法能够解决这个问题时”。下面上对所谓没有传统解决方法的一个描述：对于传统代码来说，问题需要的精确度太高。这种问题可能并不复杂，但是你找不到一种稳定的方法去建立它。问题超越了任何有明显运算法则的方案。它是一个难以解决的复杂问题，没有明显的传统解决方案或者问题没有一个准确的定论。业务逻辑经常发生改变逻辑本身是简单的（但不是指过于简单），但是规则经常发生变化。在许多软件组织中正式版本的间隔是较长并且较少的，规则可以在适当的安全前提下帮助提供一定的敏捷性。领域专家（或者业务分析师）是非技术人员领域专家通常对业务规则和流程具有很好的认知。他们通常是不了解软件技术的人员，但是具有很好的逻辑性。规则能够让他们用自己的术语来描述业务逻辑。当然他们仍然需要严密的思考和良好的逻辑思维能力（许多在非软件技术型岗位上的人没有进行过形式逻辑的训练，因此在和他们工作时要特别小心，在将业务知识编撰成规则时，要特别注意业务规则和流程应当是当前能够理解的）。如果规则对于你的项目组来说是一种新的技术，那在使用前必须将学习与管理的费用成本考虑进去。规则不是一种无意义的技术，这篇文档尽量让其易于理解。在一个面向对象的应用中，规则引擎通常被用在包含业务逻辑的关键部分（具体与应用相关），特别是在十分繁杂凌乱的部分。这是对面向对象中将所有逻辑封装在对象中的一个倒置。但这并不是说应该抛弃对象模型，相反的来说在任何一个现实应用中业务逻辑仅仅是应用的一部分。如果你曾注意到在你的代码中有很多”if””else””switch”和其它凌乱的逻辑，你总是要回过头去修改它们（可能是由于提供给你的逻辑是错误的，或是你的理解变化了），那么可以考虑使用规则。如果你所面对的问题没有算法或者模式合适解决，考虑使用规则。规则可以被嵌入你的应用中，或者作为一个服务使用。通常规则最好被当作一个有状态的组件使用——因此它们通常在应用中是一个整体。无论怎样，在一些规则被成功定义为可重用的服务的个案中，规则是无状态的。如果考虑在组织中使用规则，那考虑产品中将如何使用和更新规则是很重要的(选择很多，但是不同的组织间有不同的需要——通常这超出了应用者/项目团队的控制)。Drools工作原理上文中曾经提到过，Drools是基于RETE算法的产生式规则引擎。那么，什么事产生式规则引擎？什么事RETE算法呢？下面为您逐一讲解。产生式规则引擎工作原理产生式