使用 Drools 规则引擎实现业务逻辑.docx

《使用 Drools 规则引擎实现业务逻辑.docx》由会员分享，可在线阅读，更多相关《使用 Drools 规则引擎实现业务逻辑.docx（41页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、使用规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性，降低应用程序的维护和可扩展性成本。这篇更新的文章展示如何使用开源的 Drools 规则引擎让 Java 应用程序更适应变化。Drools 项目引入了一个新的本地规则表达式语言和一个 Eclipse 插件，使 Drools 比以前更容易使用。要求施加在当今软件产品上的大多数复杂性是行为和功能方面的，从而导致组件实现具有复杂的业务逻辑。实现 J2EE 或 J2SE 应用程序中业务逻辑最常见的方法是编写 Java 代码来实现需求文档的规则和逻辑。在大多数情况下，该代码的错综复杂性使得维护和更新应用程序的业务逻辑成为一项令人畏惧的任务，甚至对于经

2、验丰富的开发人员来说也是如此。任何更改，不管多么简单，仍然会产生重编译和重部署成本。规则引擎试图解决（或者至少降低）应用程序业务逻辑的开发和维护中固有的问题和困难。可以将规则引擎看作实现复杂业务逻辑的框架。大多数规则引擎允许您使用声明性编程来表达对于某些给定信息或知识有效的结果。您可以专注于已知为真的事实及其结果，也就是应用程序的业务逻辑。有多个规则引擎可供使用，其中包括商业和开放源码选择。商业规则引擎通常允许使用专用的类似英语的语言来表达规则。其他规则引擎允许使用脚本语言（比如 Groovy 或 Python）编写规则。这篇更新的文章为您介绍 Drools 引擎，并使用示例程序帮助您理解如何

3、使用 Drools 作为 Java 应用程序中业务逻辑层的一部分。更多事情在变化俗话说得好，“惟一不变的是变化。”软件应用程序的业务逻辑正是如此。出于以下原因，实现应用程序业务逻辑的组件可能必须更改： 在开发期间或部署后修复代码缺陷 应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内 处理客户已更改的业务目标 符合组织对敏捷或迭代开发过程的使用如果存在这些可能性，则迫切需要一个无需太多复杂性就能处理业务逻辑更改的应用程序，尤其是当更改复杂 if-else 逻辑的开发人员并不是以前编写代码的开发人员时。Drools 是用 Java 语言编写的开放源码规则引擎，使用 Rete 算法（参阅参考资

4、料）对所编写的规则求值。Drools 允许使用声明方式表达业务逻辑。可以使用非 XML 的本地语言编写规则，从而便于学习和理解。并且，还可以将 Java 代码直接嵌入到规则文件中，这令 Drools 的学习更加吸引人。Drools 还具有其他优点： 非常活跃的社区支持 易用 快速的执行速度 在 Java 开发人员中流行 与 Java Rule Engine API（JSR 94）兼容（参阅参考资料） 免费当前 Drools 版本在编写本文之际，Drools 规则引擎的最新版本是。这是一个重要更新。虽然现在还存在一些向后兼容性问题，但这个版本的特性让 Drools 比以前更有吸引力。例如，用于表

5、达规则的新的本地语言比旧版本使用的 XML 格式更简单，更优雅。这种新语言所需的代码更少，并且格式易于阅读。另一个值得注意的进步是，新版本提供了用于 Eclipse IDE（Versions 3.2 和）的一个 Drools 插件。我强烈建议您通过这个插件来使用 Drools。它可以简化使用 Drools 的项目开发，并且可以提高生产率。例如，该插件会检查规则文件是否有语法错误，并提供代码完成功能。它还使您可以调试规则文件，将调试时间从数小时减少到几分钟。您可以在规则文件中添加断点，以便在规则执行期间的特定时刻检查对象的状态。这使您可以获得关于规则引擎在特定时刻所处理的知识（knowledge

6、）（在本文的后面您将熟悉这个术语）的信息。要解决的问题本文展示如何使用 Drools 作为示例 Java 应用程序中业务逻辑层的一部分。为了理解本文，您应该熟悉使用 Eclipse IDE 开发和调试 Java 代码。并且，您还应该熟悉 JUnit 测试框架，并知道如何在 Eclipse 中使用它。下列假设为应用程序解决的虚构问题设置了场景： 名为 XYZ 的公司构建两种类型的计算机机器：Type1 和 Type2。机器类型按其架构定义。 XYZ 计算机可以提供多种功能。当前定义了四种功能：DDNS Server、DNS Server、Gateway 和 Router。 在发运每台机器之前，X

7、YZ 在其上执行多个测试。 在每台机器上执行的测试取决于每台机器的类型和功能。目前，定义了五种测试：Test1、Test2、Test3、Test4 和 Test5。 当将测试分配给一台计算机时，也将测试到期日期分配给该机器。分配给计算机的测试不能晚于该到期日期执行。到期日期值取决于分配给机器的测试。 XYZ 使用可以确定机器类型和功能的内部开发的软件应用程序，自动化了执行测试时的大部分过程。然后，基于这些属性，应用程序确定要执行的测试及其到期日期。 目前，为计算机分配测试和测试到期日期的逻辑是该应用程序的已编译代码的一部分。包含该逻辑的组件用 Java 语言编写。 分配测试和到期日期的逻辑一个

8、月更改多次。当开发人员需要使用 Java 代码实现该逻辑时，必须经历一个冗长乏味的过程。何时使用规则引擎？并非所有应用程序都应使用规则引擎。如果业务逻辑代码包括很多 if-else 语句，则应考虑使用一个规则引擎。维护复杂的 Boolean 逻辑可能是非常困难的任务，而规则引擎可以帮助您组织该逻辑。当您可以使用声明方法而非命令编程语言表达逻辑时，变化引入错误的可能性会大大降低。如果代码变化可能导致大量的财政损失，则也应考虑规则引擎。许多组织在将已编译代码部署到托管环境中时具有严格的规则。例如，如果需要修改 Java 类中的逻辑，在更改进入生产环境之前，将会经历一个冗长乏味的过程：1. 必须重新

9、编译应用程序代码。2. 在测试中转环境中删除代码。3. 由数据质量审核员检查代码。4. 由托管环境架构师批准更改。5. 计划代码部署。即使对一行代码的简单更改也可能花费组织的几千美元。如果需要遵循这些严格规则并且发现您频繁更改业务逻辑代码，则非常有必要考虑使用规则引擎。对客户的了解也是该决策的一个因素。尽管您使用的是一个简单的需求集合，只需 Java 代码中的简单实现，但是您可能从上一个项目得知，您的客户具有在开发周期期间甚至部署之后添加和更改业务逻辑需求的倾向（以及财政和政治资源）。如果从一开始就选择使用规则引擎，您可能会过得舒服一些。因为在对为计算机分配测试和到期日期的逻辑进行更改时，公司

10、会发生高额成本，所以 XYZ 主管已经要求软件工程师寻找一种灵活的方法，用最少的代价将对业务规则的更改 “推” 至生产环境。于是 Drools 走上舞台了。工程师决定，如果它们使用规则引擎来表达确定哪些测试应该执行的规则，则可以节省更多时间和精力。他们将只需要更改规则文件的内容，然后在生产环境中替换该文件。对于他们来说，这比更改已编译代码并在将已编译代码部署到生产环境中时进行由组织强制的冗长过程要简单省时得多（参阅侧栏何时使用规则引擎？）。目前，在为机器分配测试和到期日期时必须遵循以下业务规则： 如果计算机是 Type1，则只能在其上执行 Test1、Test2 和 Test5。 如果计算机是

11、 Type2 且其中一个功能为 DNS Server，则应执行 Test4 和 Test5。 如果计算机是 Type2 且其中一个功能为 DDNS Server，则应执行 Test2 和 Test3。 如果计算机是 Type2 且其中一个功能为 Gateway，则应执行 Test3 和 Test4。 如果计算机是 Type2 且其中一个功能为 Router，则应执行 Test1 和 Test3。 如果 Test1 是要在计算机上执行的测试之一，则测试到期日期距离机器的创建日期 3 天。该规则优先于测试到期日期的所有下列规则。 如果 Test2 是要在计算机上执行的测试之一，则测试到期日期距离机

12、器的创建日期 7 天。该规则优先于测试到期日期的所有下列规则。 如果 Test3 是要在计算机上执行的测试之一，则测试到期日期距离机器的创建日期 10 天。该规则优先于测试到期日期的所有下列规则。 如果 Test4 是要在计算机上执行的测试之一，则测试到期日期距离机器的创建日期 12 天。该规则优先于测试到期日期的所有下列规则。 如果 Test5 是要在计算机上执行的测试之一，则测试到期日期距离机器的创建日期 14 天。捕获为机器分配测试和测试到期日期的上述业务规则的当前 Java 代码如清单 1 所示：清单 1. 使用 if-else 语句实现业务规则逻辑 Machine machine =

13、 ./ Assign testsCollections.sort(machine.getFunctions();int index;if (machine.getType().equals(Type1) Test test1 = . Test test2 = . Test test5 = . machine.getTests().add(test1); machine.getTests().add(test2); machine.getTests().add(test5); else if (machine.getType().equals(Type2) index = Collections

14、.binarySearch(machine.getFunctions(), Router); if (index = 0) Test test1 = . Test test3 = . machine.getTests().add(test1); machine.getTests().add(test3); index = Collections.binarySearch(machine.getFunctions(), Gateway); if (index = 0) Test test4 = . Test test3 = . machine.getTests().add(test4); mac

15、hine.getTests().add(test3); ./ Assign tests due dateCollections.sort(machine.getTests(), new TestComparator();.Test test1 = .index = Collections.binarySearch(machine.getTests(), test1);if (index = 0) / Set due date to 3 days after Machine was created Timestamp creationTs = machine.getCreationTs(); m

16、achine.setTestsDueTime(.); return;index = Collections.binarySearch(machine.getTests(), test2);if (index = 0) / Set due date to 7 days after Machine was created Timestamp creationTs = machine.getCreationTs(); machine.setTestsDueTime(.); return;.清单 1 中的代码不是太复杂，但也并不简单。如果要对其进行更改，需要十分小心。一堆互相缠绕的 if-else 语

17、句正试图捕获已经为应用程序标识的业务逻辑。如果您对业务规则不甚了解，就无法一眼看出代码的意图。导入示例程序使用 Drools 规则的示例程序附带在本文的 ZIP 存档中。程序使用 Drools 规则文件以声明方法表示上一节定义的业务规则。它包含一个 Eclipse 3.2 Java 项目，该项目是使用 Drools 插件和 4.0.4 版的 Drools 规则引擎开发的。请遵循以下步骤设置示例程序：1. 下载 ZIP 存档（参见下载）。2. 下载并安装 Drools Eclipse 插件（参见参考资料）。3. 在 Eclipse 中，选择该选项以导入Existing Projects into

18、 Workspace，如图 1 所示：图 1. 将示例程序导入到 Eclipse 工作区4. 然后选择下载的存档文件并将其导入工作区中。您将在工作区中发现一个名为DroolsDemo的新 Java 项目，如图 2 所示：图 2. 导入到工作区中的示例程序如果启用了Build automatically选项，则代码应该已编译并可供使用。如果未启用该选项，则现在构建DroolsDemo项目。检查代码现在来看一下示例程序中的代码。该程序的 Java 类的核心集合位于demo包中。在该包中可以找到Machine和Test域对象类。Machine类的实例表示要分配测试和测试到期日期的计算机机器。下面来看

19、Machine类，如清单 2 所示：清单 2.Machine类的实例变量 public class Machine private String type; private List functions = new ArrayList(); private String serialNumber; private Collection tests = new HashSet(); private Timestamp creationTs; private Timestamp testsDueTime; public Machine() super(); this.creationTs = ne

20、w Timestamp(System.currentTimeMillis(); .在清单 2 中可以看到Machine类的属性有： type（表示为string属性） 保存机器的类型值。 functions（表示为list） 保存机器的功能。 testsDueTime（表示为timestamp变量） 保存分配的测试到期日期值。 tests（Collection对象） 保存分配的测试集合。注意，可以为机器分配多个测试，而且一个机器可以具有一个或多个功能。出于简洁目的，机器的创建日期值设置为创建Machine类的实例时的当前时间。如果这是真实的应用程序，创建时间将设置为机器最终构建完成并准备测试的

21、实际时间。Test类的实例表示可以分配给机器的测试。Test实例由其id和name惟一描述，如清单 3 所示：清单 3.Test类的实例变量 public class Test public static Integer TEST1 = new Integer(1); public static Integer TEST2 = new Integer(2); public static Integer TEST3 = new Integer(3); public static Integer TEST4 = new Integer(4); public static Integer TEST5

22、 = new Integer(5); private Integer id; private String name; private String description; public Test() super(); .示例程序使用 Drools 规则引擎对Machine类的实例求值。基于Machine实例的type和functions属性的值，规则引擎确定应分配给tests和testsDueTime属性的值。在demo包中，还会发现Test对象的数据访问对象 (TestDAOImpl) 的实现，它允许您按照 ID 查找Test实例。该数据访问对象极其简单；它不连接任何外部资源（比如关系数

23、据库）以获得Test实例。相反，在其定义中硬编码了预定义的Test实例集合。在现实世界中，您可能会具有连接外部资源以检索Test对象的数据访问对象。RulesEngine类demo中比较重要（如果不是最重要的）的一个类是RulesEngine类。该类的实例用作封装逻辑以访问 Drools 类的包装器对象。可以在您自己的 Java 项目中容易地重用该类，因为它所包含的逻辑不是特定于示例程序的。清单 4 展示了该类的属性和构造函数：清单 4.RulesEngine类的实例变量和构造函数 public class RulesEngine private RuleBase rules; private

24、 boolean debug = false; public RulesEngine(String rulesFile) throws RulesEngineException super(); try / Read in the rules source file .getResourceAsStream(/ + rulesFile); / Use package builder to build up a rule package PackageBuilder builder = new PackageBuilder(); / This parses and compiles in one

25、 step builder.addPackageFromDrl(source); / Get the compiled package Package pkg = builder.getPackage(); / Add the package to a rulebase (deploy the rule package). rules = RuleBaseFactory.newRuleBase(); rules.addPackage(pkg); catch (Exception e) throw new RulesEngineException( Could not load/compile

26、rules file: + rulesFile, e); .在清单 4 中可以看到，RulesEngine类的构造函数接受字符串值形式的参数，该值表示包含业务规则集合的文件的名称。该构造函数使用PackageBuilder类的实例解析和编译源文件中包含的规则。（注意：该代码假设规则文件位于程序类路径中名为 rules 的文件夹中。）然后，使用PackageBuilder实例将所有编译好的规则合并为一个二进制Package实例。然后，使用这个实例配置 DroolsRuleBase类的一个实例，后者被分配给RulesEngine类的rules属性。可以将这个类的实例看作规则文件中所包含规则的内存中

27、表示。清单 5 展示了RulesEngine类的executeRules()方法：清单 5.RulesEngine类的executeRules()方法 public void executeRules(WorkingEnvironmentCallback callback) WorkingMemory workingMemory = rules.newStatefulSession(); if (debug) workingMemory .addEventListener(new DebugWorkingMemoryEventListener(); callback.initEnvironme

28、nt(workingMemory); workingMemory.fireAllRules();executeRules()方法几乎包含了 Java 代码中的所有魔力。调用该方法执行先前加载到类构造函数中的规则。DroolsWorkingMemory类的实例用于断言或声明知识，规则引擎应使用它来确定应执行的结果。（如果满足规则的所有条件，则执行该规则的结果。）将知识当作规则引擎用于确定是否应启动规则的数据或信息。例如，规则引擎的知识可以包含一个或多个对象及其属性的当前状态。规则结果在调用WorkingMemory对象的fireAllRules()方法时执行。您可能奇怪（我希望您如此）知识是如何

29、插入到WorkingMemory实例中的。如果仔细看一下该方法的签名，将会注意到所传递的参数是WorkingEnvironmentCallback接口的实例。executeRules()方法的调用者需要创建实现该接口的对象。该接口只需要开发人员实现一个方法（参见清单 6 ）：清单 6.WorkingEnvironmentCallback接口 public interface WorkingEnvironmentCallback void initEnvironment(WorkingMemory workingMemory) throws FactException;所以，应该是execute

30、Rules()方法的调用者将知识插入到WorkingMemory实例中的。稍后将展示这是如何实现的。TestsRulesEngine类清单 7 展示了TestsRulesEngine类，它也位于demo包中：清单 7.TestsRulesEngine类 public class TestsRulesEngine private RulesEngine rulesEngine; private TestDAO testDAO; public TestsRulesEngine(TestDAO testDAO) throws RulesEngineException super(); rulesEn

31、gine = new RulesEngine(testRules1.drl); this.testDAO = testDAO; public void assignTests(final Machine machine) rulesEngine.executeRules(new WorkingEnvironmentCallback() public void initEnvironment(WorkingMemory workingMemory) / Set globals first before asserting/inserting any knowledge! workingMemor

32、y.setGlobal(testDAO, testDAO); workingMemory.insert(machine); ; ); TestsRulesEngine类只有两个实例变量。rulesEngine属性是RulesEngine类的实例。testDAO属性保存对TestDAO接口的具体实现的引用。rulesEngine对象是使用testRules1.drl字符串作为其构造函数的参数实例化的。testRules1.drl 文件以声明方式捕获要解决的问题中的业务规则。TestsRulesEngine类的assignTests()方法调用RulesEngine类的executeRules()

33、方法。在这个方法中，创建了WorkingEnvironmentCallback接口的一个匿名实例，然后将该实例作为参数传递给executeRules()方法。如果查看assignTests()方法的实现，可以看到知识是如何插入到WorkingMemory实例中的。WorkingMemory类的insert()方法被调用以声明在对规则求值时规则引擎应使用的知识。在这种情况下，知识由Machine类的一个实例组成。被插入的对象用于对规则的条件求值。如果在对条件求值时，需要让规则引擎引用未用作知识的对象，则应使用WorkingMemory类的setGlobal()方法。在示例程序中，setGloba

34、l()方法将对TestDAO实例的引用传递给规则引擎。然后规则引擎使用TestDAO实例查找它可能需要的任何Test实例。TestsRulesEngine类是示例程序中惟一的 Java 代码，它包含专门致力于为机器分配测试和测试到期日期的实现的逻辑。该类中的逻辑永远不需要更改，即使业务规则需要更新时也是如此。Drools 规则文件如前所述，testRules.xml 文件包含规则引擎为机器分配测试和测试到期日期所遵循的规则。它使用 Drools 本地语言表达所包含的规则。Drools 规则文件有一个或多个rule声明。每个rule声明由一个或多个conditional元素以及要执行的一个或多个

35、consequences或actions组成。一个规则文件还可以有多个（即 0 个或多个）import声明、多个global声明以及多个function声明。理解 Drools 规则文件组成最好的方法是查看一个真正的规则文件。下面来看 testRules1.drl 文件的第一部分，如清单 8 所示：清单 8. testRules1.drl 文件的第一部分 package demo;import demo.Machine;import demo.Test;import demo.TestDAO;import java.util.Calendar;import java.sql.Timestamp

36、;global TestDAO testDAO;在清单 8 中，可以看到import声明如何让规则执行引擎知道在哪里查找将在规则中使用的对象的类定义。global声明让规则引擎知道，某个对象应该可以从规则中访问，但该对象不应是用于对规则条件求值的知识的一部分。可以将global声明看作规则中的全局变量。对于global声明，需要指定它的类型（即类名）和想要用于引用它的标识符（即变量名）。global声明中的这个标识符名称应该与调用WorkingMemory类的setGlobal()方法时使用的标识符值匹配，在此即为testDAO（参见清单 7）。function关键词用于定义一个 Java 函

37、数（参见清单 9）。如果看到 consequence（稍后将讨论）中重复的代码，则应该提取该代码并将其编写为一个 Java 函数。但是，这样做时要小心，避免在 Drools 规则文件中编写复杂的 Java 代码。规则文件中定义的 Java 函数应该简短易懂。这不是 Drools 的技术限制。如果想要在规则文件中编写复杂的 Java 代码，也可以。但这样做可能会让您的代码更加难以测试、调试和维护。复杂的 Java 代码应该是 Java 类的一部分。如果需要 Drools 规则执行引擎调用复杂的 Java 代码，则可以将对包含复杂代码的 Java 类的引用作为全局数据传递给规则引擎。清单 9. t

38、estRules1.drl 文件中定义的 Java 函数 function void setTestsDueTime(Machine machine, int numberOfDays) setDueTime(machine, Calendar.DATE, numberOfDays);function void setDueTime(Machine machine, int field, int amount) Calendar calendar = Calendar.getInstance(); calendar.setTime(machine.getCreationTs(); calend

39、ar.add(field, amount); machine.setTestsDueTime(new Timestamp(calendar.getTimeInMillis(); .清单 10 展示了 testRules1.drl 文件中定义的第一个规则：清单 10. testRules1.drl 中定义的第一个规则 rule Tests for type1 machinesalience 100when machine : Machine( type = Type1 )then Test test1 = testDAO.findByKey(Test.TEST1); Test test2 = t

40、estDAO.findByKey(Test.TEST2); Test test5 = testDAO.findByKey(Test.TEST5); machine.getTests().add(test1); machine.getTests().add(test2); machine.getTests().add(test5); insert( test1 ); insert( test2 ); insert( test5 );end如清单 10 所示，rule声明有一个惟一标识它的name。还可以看到，when关键词定义规则中的条件块，then关键词定义结果块。清单 10 中显示的规则有一

41、个引用Machine对象的条件元素。如果回到清单 7可以看到，Machine对象被插入到WorkingMemory对象中。这正是这个规则中使用的对象。条件元素对Machine实例（知识的一部分）求值，以确定是否应执行规则的结果。如果条件元素等于true，则启动或执行结果。从清单 10 中还可以看出，结果只不过是一个 Java 语言语句。通过快速浏览该规则，可以很容易地识别出这是下列业务规则的实现： 如果计算机是 Type1，则只能在该机器上执行 Test1、Test2 和 Test5。因此，该规则的条件元素检查（Machine对象的）type属性是否为Type1。 （在条件元素中，只要对象遵从

42、 Java bean 模式，就可以直接访问对象的属性，而不必调用 getter 方法。）如果该属性的值为true，那么将Machine实例的一个引用分配给machine标识符。然后，在规则的结果块使用该引用，将测试分配给Machine对象。在该规则中，惟一看上去有些奇怪的语句是最后三条结果语句。回忆 “要解决的问题” 小节中的业务规则，应该分配为测试到期日期的值取决于分配给机器的测试。因此，分配给机器的测试需要成为规则执行引擎在对规则求值时所使用的知识的一部分。这正是这三条语句的作用。这些语句使用一个名为insert的方法更新规则引擎中的知识。确定规则执行顺序规则的另一个重要的方面是可选的sa

43、lience属性。使用它可以让规则执行引擎知道应该启动规则的结果语句的顺序。具有最高显著值的规则的结果语句首先执行；具有第二高显著值的规则的结果语句第二执行，依此类推。当您需要让规则按预定义顺序启动时，这一点非常重要，很快您将会看到。testRules1.drl 文件中接下来的四个规则实现与机器测试分配有关的其他业务规则（参见清单 11）。这些规则与刚讨论的第一个规则非常相似。注意，salience属性值对于前五个规则是相同的；不管这五个规则的启动顺序如何，其执行结果将相同。如果结果受规则的启动顺序影响，则需要为规则指定不同的显著值。清单 11. testRules1.drl 文件中与测试分配

44、有关的其他规则 rule Tests for type2, DNS server machinesalience 100when machine : Machine( type = Type2, functions contains DNS Server)then Test test5 = testDAO.findByKey(Test.TEST5); Test test4 = testDAO.findByKey(Test.TEST4); machine.getTests().add(test5); machine.getTests().add(test4); insert( test4 ); insert( test5 );endrule Tests for type2, DDNS server machinesalience 100