drools使用手册第六--十章

drools使用手册第六--十章内容摘要：

者注：原文如下average number of evaluation descending from the object type node for a random sample], f = facts, hd = 规则中的硬编码常量 , general = 通用格式使用的连接数 general( sum( bn(lf * rf) ) + sum(ae * f) ) hd( sum( bn(lf * rf) ) + sum(ae * f) ) 对这两种方式的最佳量化方法是通过两种方式编写规则，并运行系列测试。 大多数项目有严格的计划，开发者通常不可能有时间这样做。 另一个常见问题是使用了大量的扁平化对象。 简单地说，在规则中使用大量的扁平对象导致与硬编码常数同样的问题。 对于这个问题的解决方案是改变域对象，能够以一种更简洁的方式表达商业模型。 这个方法不一定每次都能适用。 当大多数规则共享同样的条件时，有两种解决方案。 最好的办法是使用链接重写规则。 识 别常用条件，并将它选取到通用的规则中。 通用的规则通过设置一个新的 fact 触发后来的规则。 通常这样可以将规则减少一个数量级或更多。 第二种方法是将通用条件放在规则的开始部分。 这样可以允许 RETE 规则引擎共享这些节点。 当节点被共享后，它将减少内存的占用，并提升性能。 如果 RuleSet 可以被分成更小的块，将 ruleset 分为离散的块，放在不同的 JVM或服务器上运行是一个好办法。 这个办法依赖于环境是否允许。 那在 ruleset规模过大，重写规则又不可行时还有什么办法呢。 仅有的办法是扩展硬件并使用一个不同的 JVM。 这 意味着使用 64 位 JVM 在一台至少 8GB 内存的机器上。 依赖于 ruleset 的情况，系统可能需要更多内存。 第 8 章 . 示例 . 获得示例 在 Drools 源代码中一些示例被当作集成测试包含。 另外，你可以下载droolsexamples 模块，这是一个自包含的 Eclipse 项目。 这个模块中有许多例子。 项目地址： 第 9 章 . 部署与测试 . 部署选项 一旦将规则集成在你 的应用中，你需要激活如何将规则与你的应用一起部署。 规则的特点是用来允许应用程序的改变而不用重新部署整个应用。 这意味着规则必须作为应用的数据提供，而不是应用的部分（如嵌入 classpath 中）。 规则引擎为规则部署开放了很多选项。 这章的主要焦点在部署选项和API 上。 Drools 的未来版本将会有一个规则服务器组件，用来管理规则的多个版本（包括锁定和自动部署）。 因为每个组织都有不同，因此需要不同的部署模式。 许多组织对于产品线的更改有配置管理流程。 从这方面考虑，最好将规则考虑为数据而不是软件。 但 是，因为规则可以包含相当多的强大的逻辑，应当使用正确的测试、确认流程来控制规则的改变，在将规则发布出去之前要确认它们正确。 . 可发布对象 RuleBase, Package 等 在最简单的情况下，你可以编译和构造一个 rulebase，然后缓存这个 rulebase。 这个 rulebase 可以被线程共享，每个线程中产生新的 working memory 来处理事务（然后 working memory 被抛弃）。 这本质上是一个无状态模式。 为了更新rulebase，需要重新装载一个新的 rulebase，然后交换出缓 存的 rulebase(任何正在使用旧的 rulebase 的线程可以继续使用直到结束，在这个情况下 rulebase最终会被垃圾处理器收集 )。 可以有许多更灵巧的办法实现上面的案例， Drools 规则引擎十分的动态，意味着许多组件能够被动态交换（ rules,packages）甚至有 working memory 正在使用的时候。 例如说，规则可以从一个有许多使用中的 working memory 的 rulebase中删除， RETE网络将自动调整以删除该规则而不需要将其它 fact重新设置一次。 长期运行的 working memory 对于复杂的应用来说是很有用的，规则引擎随时增加库中的知识，用来对实际情况进行辅助决策（在这些例子中，展现了引擎的动态特性）。 . DRL 和 PackageDescr 一种办法是将规则部署为源码格式。 这种办法依赖于运行时引擎（必需包含编译器组件）去编译规则，并建立 rulebase。 一个类似的方法是部署 PackageDescr对象，这意味着规则被预先解析好（对语法错误），但是没有被编译成二进制格式。 使用 PackageBuilder 类完成编译。 如果需要，你当然也可以使用 XML 格式的规则。 PackageDescr, PackageBuilder, RuleBaseLoader . Package 这种方法最具有灵活性。 在这种情况下，使用 PackageBuilder 从 DRL 源码建立Package，但是它是可以被部署的二进制 Package 对象。 多个 Package 可以被合并在一起。 这意味着 package 可能包含一个单独的新规则，或对现有规则的更改；可以建立这样的 package 然后与在 RuleBase 中的现有 package 合并。 RuleBase然后就能统治 working memory 新的规则 的存在（因为 RuleBase 保存着对由它产生的 working memory 的弱引用）。 RuleBase 保存着 Package 的列表，并且合并到其中一个 Package，你需要知道哪一个是你需要合并的 Package（显然，只有在同样包名中的规则可以被合并）。 Package 对象是可以序列化的，因此它们可以在网络上发送，或绑定到 JNDI，Session 等等。 PackageBuilder, RuleBase, . RuleBase 编译好的 Package 被加入 RuleBase。 RuleBase 是可序列化的，因此它们能够被当作二进制部署单元。 当 RuleBase 被整体更新时，这是一个有用的选项，对短期存在的 working memory。 如果存在的 Working Memory 需要动态改变规则，最好还是部署 Package 对象。 RuleBase, RuleBaseLoader . Serializing 序列化 事实上在 Drools 中所有与 RuleBase 有联系的对象都是可序列化的。 为了让WorkingMemory 可序列化，你设置的所有对象也必须可序 列化。 因此它通常可以进行远程发布，并且绑定规则到 JNDI 中，就像在容器中使用它们一样。 [译者注：这句翻译的意思不太理解，提供原文 So it is always possible to deploy remotely, and bind rule assets to JNDI as a means of using them in a container environment.] 请注意，当使用 Package Builder 时，在继续发布你的规则之前，你可能希望检查 hasError 标记。 如果存在错误， 你可以从 Package Builder 中获得它们，好过在部署的时候才发现问题。 . 部署模式 . 进程内规则构建 在这种情况下，规则以源码方式提供到运行时系统。 系统包含 droolspiler规则编译器组件构建规则。 这是最简单的方式。 . 进程外规则构建 在这种情况下，规则在运行时系统外被构建成二进制格式（例如在一个部署服务器中）。 进程外构建的主要好处是，运行时系统可以最少的依赖运行规则所需的库（只有一个 jar）。 它也意味着所有编译错误可以在部署到运行系统前获得并处理。 在进程外使用 PackageBuilder 类，然后使用 getPackage()获得 Package 对象。 你接着可以序列化 Package 到一个文件（使用 java 标准序列化）。 运行时系统只需要 droolscore 库引用，就可以使用().addPackage(deserialized package object)载入该文件。 . 一些部署方法 这节包含一些部署的建议。 当然你可以使用不同的技术去完成。 . Pull 拉风格 在这种方法中，规则从规则库中被拉到运行系统中。 规则库可以是一个简单的文件系统，或是一个数据库。 拉规则的触发器可以是一个定时任务（检查变更），或一个发到运行时系统的请求（可能使用 JMX 接口）。 这可能是最常用的方式。 . Push 推风格 在这种方式中，规则部署进程 /规则库推规则到运行系统中（规则可能是源码或二进制格式）。 当新的规则生效时，这可以给与更多的控制。 . Web Services 一种发布规则的可能方式是将规则暴露为 Web 服务。 有很多方法完成，但是目前最简单的一 种方法是使用一个接口优先的进程：定义将在 XML Schema 中使用的fact 类 /模板，然后使用绑定技术产生这些与实际操作对应的规则的绑定对象。 一种相反的可能是使用 XSD/WSDL 产生器产生对这些处理构建的类（操作对应的规则）的 XML 绑定。 希望在将来的版本中，可以有一种自动的工具将规则暴露为Web 服务（可能使用 XSD 作为 fact 来给规则操作）。 . 未来的期望 Drools 的将来版本将提供一个规则库组件，将直接支持以上的摸式，以及更多。 . 测试 在这些年，测试驱动开发成为了主流，作为这种技术 带给软件开发的价值已经被确认。 在某方面来说，规则是编码（虽然在更高的级别），测试驱动开发的许多原则同样适用。 你可以在规则编写前提供测试来规定规则的行为。 更进一步说，测试在规则频繁变动的环境下，比规则更重要。 测试可以提供一个信心底线，规则的改变是否与系统相容，可以从测试中了解。 当然，规则的改变也可能就是会引起测试的错误，这种情况下需要编写新的测试来覆盖新的规则行为。 在测试驱动开发的方式中，测试需要经常运行，在一个规则驱动的环境中，这意味着每次规则改变都应该运行测试（甚至软件本身没有任何变化）。 . 测试框架 对应程序员来说， Junit（或 TestNG）是开发测试代码的常用工具，它们也可以用来测试规则。 记住，规则的变更可能超过测试代码的范围，因此你应该随时将测试单元保持与规则的更新同步（在某些环境中可能是无法实现的）。 当然，最好的想法是让测试关注规则的核心特性，这样就不需要随时改变。 显然，对于规则测试，其它非源代码驱动的架构在某些环境下也可以用来测试规则。 下一节介绍了一个规则测试组件。 作为一个独立附件，有一个测试架构建立在 FIT（集成测试架构）上。 它允许规则测试套件 （功能）在 Word 文档中捕捉，或 Excel 电子表格中（实际上任何可以保存为 HTML 的工具）。 它利用一个表格层捕捉输入数据，并且通过对一个RuleSet 中的规则根据给定的 Fact 进行判断有效性。 因为测试被保存在文档中，这些方法和需求能够被保存在同样的文档中，为规则行为的提供一个单独的真实性约束。 同样因为测试文档不是代码，它们可以随着规则不断更新，用来确定变更规则的有效性。 因为输入的格式对于熟悉规则的领域的人来说相当简单，它也对“情景测试”有帮助，对这些规则可以使用不同的情景。 这些情景然后可以作为测试保存，增 加当规则发生变更时仍然按照用户希望的工作的保证性。 这个测试框架建立在 FIT 和 JSR94之上，对于 Jboos 规则来说是一个独立的项目。 因为建立在 FIT 上，它需要一个不同的认证，但也是开源的。 你可以下载并获得更多的资料，通过这个 Web 页面： Fit for rules 下面的页面显示 FIT 规则框架的截图 使用规则 FIT，你可以捕捉测试数据，将它传递到规则引擎，然后确认结果（使用测试组建文档）。 期望在将来， Drools 服务工具可以为测试提供一个类似的集成框架（单元格的底色，绿色意味成功，红色意味失败）。 访问 获得更多关于 FIT 框架信息。 更多的信息可以从这里下载 Here 第 10章 . 论文 . Manners 小姐和基准分析（ Benchmarking） . 介绍 [译者注：本章因为涉及大量的专业术语，要在对引用的论文及相关算法有较好理解的基础上才能准确翻译，因此这章的翻译仅作为参考，希望深入研究的话请以原版英文为准 ] Manners 小姐正在筹备一个聚会，作为一个好主人，她希望很好的安排座位。 她最初设计男女相邻而坐，接着她担心大家没有什么共同话题；一个好主人应该怎么做呢。 因此她决定标记每个客人的兴趣，这样她可以不但将客人安排成男女相邻而坐，并且 确信客人之间（或者左边或者右边）会有一个共同的话题。 图 . Manners 小姐的客人 . 基准分析 在 1991 年 Brant, Timothy Grose, Bernie Lofaso, amp。 Daniel P. Miranker 的论文 Effects of Database Size on Rule System Performance: Five Case Studies中提出了五个基准分析。  Manners o 使用一个深度优先搜索方法决定对男孩 /女孩的座位安排，并且与相邻 的同伴有共同的兴趣爱好  Waltz。