WebSphere ILOG JRules 规则引擎运行模式简介

WebSphere ILOG JRules 规则引擎运行模式简介

引言

作为 JRules 的核心组件，规则引擎决定了在规则集的执行过程中，哪些业务规则会被执行，以及以何种顺序执行。理解并合理选择规则引擎的运行模式对于业务规则的正确应用有着重要意义。文章首先介绍了 JRules 规则引擎的三种运行模式，然后阐述了如何针对特定的应用场合选择合适的运行模式，最后展示了如何在 Rule Studio 中为 rule task 设置运行模式。本文需要读者对 WebSphere ILOG JRules 以及 Rule Studio 有一定了解。

 

回页首

背景

随着信息技术在企业的广泛的应用，企业 IT 部门所开发和维护的应用系统也越来越复杂，如何使应用系统能够更快的响应的企业业务的变化已成为企业 IT 发展的重要挑战之一。业务规则管理系统（Business Rule Management System）正是解决上述问题的最佳方案，BRMS 将以程序代码的形式固化在应用系统中的业务逻辑分离、抽象出来，被分离的业务逻辑以业务规则形式存储在规则库中，并通过规则引擎进行执行；同时，BRMS 还提供一系列的规则开发和管理工具供开发人员和业务人员来创建、修改、查询、部署和管理这些业务规则。ILOG JRules 是面向 Java 环境的完整的业务规则管理系统 (BRMS)。它提供了所有必要的工具 , 用于对整个企业的业务规则进行管理 , 包括规则建模、规则编写、规则测试、规则部署、规则执行和规则维护。

 

回页首

规则引擎简介

规则引擎是 BRMS 中的核心模块，它旨在处理业务规则集合与业务数据关系匹配，并通过选择规则匹配算法来得出最后的计算结果 ^[1]。我们知道，业务规则管理技术能将业务逻辑从固化在代码中剥离出来，使之能像管理业务数据一样管理业务规则，因此从系统应用设计的角度看，规则引擎可视为一座连接应用系统与业务规则之间的重要桥梁。

规则引擎由基于规则的专家系统中的推理引擎发展而来，通常包括规则库、Working Memory 和推理引擎（Inference Engine）。在规则引擎执行过程中，数据将首先被送入到 Working Memory，然后由推理引擎将 Working Memory 中的数据对象和规则库中的规则进行比较，得到符合条件的规则并执行。因此，规则引擎运行模式的核心在于如何高效地匹配出符合条件的规则，规则条件匹配的效率即决定了引擎的性能。

 

回页首

JRules 规则引擎运行模式

JRules 规则引擎根据规则的不同应用场景和业务规则的特点提供了三种不同的运行模式：RetePlus、Sequential 和 FastPath。

RetePlus

Rete 是目前主流的规则引擎模式匹配算法，RetePlus 则是 JRules 在 Rete 算法上的扩展和优化，也是 JRules 规则引擎默认的运行模式。RetePlus 运行模式为 ILOG 规则引擎提供了种种手段，用以尽量减少需要加以评估的规则和条件的数量，计算哪些规则应当执行，并确定这些规则的执行顺序。在 RetePlus 算法中，规则引擎使用 Working memory 和 Agenda 来存放和操作应用程序对象。Working memory 中包含的应用程序对象的引用，Agenda 则按顺序列出将要执行的规则实例。如图 1 所示：

图 1. RetePlus 执行模式

RetePlus 模式的执行过程如下：

1. 规则引擎依据 Working Memory 中的数据对象来匹配规则集中规则的条件部分。在模式匹配过程中，RetePlus 首先创建出以规则条件测试之间的语义关系为基础的网络（步骤 1），然后将匹配的规则实例化并添加到 Agenda 中，随后对 Agenda 中的规则按照一定原则进行排序（步骤 2）。
2. 执行 Agenda 中的规则实例，即执行规则的动作（Action）部分。同时，规则实例的执行也会影响 Working Memory 中的数据对象，主要方式有：（步骤 3）：

• 往 Working Memory 中加入一个新的对象
• 移除 Working Memory 中现有对象
• 修改现有对象的属性

1. 以上过程将不断重复，直至执行完 Agenda 中所有规则实例。

在 RetePlus 算法中每当 Working Memory 被修改，规则引擎将重复模式匹配的过程。它在每次规则执行数据修改后重新评估每个规则匹配。这可能会改变 Agenda 中的规则实例。因此，RetePlus 是渐进的和数据驱动的。这些特点使 RetePlus 在计算和关联性类型的应用方面拥有卓越的性能。

Sequential

顺序运行模式，顾名思义，即规则引擎按顺序执行 rule task 中符合条件的所有规则。如图 2 所示：

图 2. 顺序执行模式

具体执行过程如下：

1. 规则引擎根据输入参数以及 working memory 中的对象集合和规则的条件部分进行匹配。每次匹配都将生成一个规则实例并立即运行。（步骤 1）
2. 当规则实例被执行后，它有可能设置属性或规则集输出参数的值。（步骤 2）

顺序算法执行的规则是无状态的。顺序算法的运行就像堆栈一样，匹配的规则只会运行一次，而不会再次评估。因此在顺序模式下，规则中不能使用类似“至少有一个 < 词汇 >”、“如下对象的数目：< 词汇 >”等等跟 working memory 中对象有关系的存在性条件（existence conditions），除非这个对象是集合类型。

顺序模式的特性决定了其在校验和一致性等类型的应用中有良好的性能表现。

顺序处理可以通过规则任务的算法属性来指定，通常可以在 Rule Studio 中显式的选择。

FastPath

Fastpath 运行模式是增强型的顺序运行模式，和顺序模式类似，Fastpath 也是顺序运行，但是它同时还能和 RetePlus 模式一样在进行模式匹配时检测规则条件的语义关系。

图 3.FastPath 执行模式

在 Fastpath 模式中，规则引擎可以通过 working memory 引用应用数据对象或规则集参数。与 Reteplus 类似，在模式匹配时 Fastpath 同样创建以规则条件测试之间的语义关系为基础的网络（步骤 1）。

每次匹配，将创建一个规则实例并立即执行。规则实例执行后，它可能修改 working memory 中的对象，但是这些修改不会影响其它规则的执行，并且规则引擎也不会重复模式匹配的过程（步骤 2）。

Fastpath 综合了 Reteplus 的模式匹配和顺序运行模式的规则执行的特性，从这个意义上来说，它在关联型应用和校验类应用中都有较好表现。

和顺序运行模式一样，Fastpath 运行模式也是无状态的，适合在大量单独执行简单判定或少量交叉测试的规则上进行对象匹配。这样一些规则集可以在没有任何 agenda 支持下很好的按顺序执行。除了作为一种变异的顺序模式的优势，Fastpath 运行模式的目的是进一步优化一致性和校验性类型规则的执行，通常这些类型的规则占据了商业规则的绝大部分。

 

回页首

选择合适的运行模式

你可以为规则流中的每一个规则任务选择运行模式，默认情况下，规则任务采用 Reteplus 运行模式。为了达到最佳性能，您可能需要选择其他的运行模式，以更好的适应特定规则任务中的规则。

通常要确定规则任务应该使用哪种运行模式，你需要分析规则任务中各个规则的结构，以及它们执行何种类型的业务处理。

为了更好的作出决策，您需要回答一下这些问题：

• 您的业务规则针对何种类型的应用？
• 你的业务规则使用什么类型的对象？
• 规则执行的影响是什么？
• 规则条件中使用什么类型的测试？
• 您的业务规则使用了什么样的优先设置？

您的业务规则针对何种类型的应用？

根据规则任务中业务逻辑的目的不同，所选择的运行模式也各异。

一致性检查、校验

松散关联的规则检查一系列条件以产生 GO /NOGO 或类似限制的结果。一致性业务规则的应用通常用于承保，欺诈检测，数据验证和表单验证。这种类型的应用中的业务规则通常会有一个是或不是的结果并提供一些关于这个决定的解释。

对于这种类型的应用，推荐使用顺序或者 Fastpath 运行模式。

计算

紧密关联的规则，用来计算一个复杂对象模型的度量。计算型业务规则应用程序通常用于评分、定级，合同和分配。这种应用中的业务规则将针对特定对象进行不同运算并据此提供一个最终结果（或品级）。

对于这种类型的应用，推荐使用 RetePlus 运行模式。

相关性

紧密相关的规则，从一组对象中抽取信息，从而计算一些复杂的数据。相关性业务规则的应用程序通常用于计费。这种类型中的业务规则通常需要插入信息。

对于这种类型的应用，推荐使用 RetePlus 或 Fastpath 运行模式。

有状态会话

强烈的关联引擎的状态会期活动，相互关联的规则。有状态应用通常用于报警过滤和相关性，图形用户界面定制，以及网页导航。

对于这种类型的应用，推荐使用 RetePlus 运行模式。

你的业务规则使用什么类型的对象？

根据您的规则中所使用的对象的不同，所选择的运行模式也各异。

Working memory 对象或规则集参数

如果您的规则中使用的对象是通过规则集传入的，那么建议您选择顺序或 Fastpath 运行模式。如果这些对象是您插入到 working memory 中的，那么建议您选择 RetePlus 或 Fastpath 运行模式。

当规则操作的不是相同的对象时，我们称之为异构绑定，当遇到异构绑定时，这些规则的条件部分可能会有不同，例如：

表 1. 异构绑定

Rule1	when{A();B()} ...
Rule2	... when{A()} ...
Rule3	... when{B()} ...

如果您的规则采用了异构绑定，那么建议您使用 RetePlus 或 Fastpath 运行模式。

当规则操作的对象相同（相同类型相同数量）仅仅是测试条件不同时，我们称之为同构绑定，例如：

表 2. 同构绑定

Rule1	... when{Person(age == 12);} ...
Rule2	... when{Person(age > 20);} ...

如果您的规则采用了同构绑定，那么建议您选择顺序运行模式。

规则执行的影响是什么？

根据您的规则执行所产生的影响的类型，所选择的运行模式也各异。

对 Working memory 进行修改

如果规则的执行部分通过使用 IRL insert、retract 或者 update 关键字操作 working memory 对象，那么你必须要使用 RetePlus 运行模式。因为这些关键字需要修改 working memory，并期望规则引擎重新评估后续的规则。如果您选择其他运行模式，规则引擎将不会在工作区修改之后重新评估后续规则。

规则链

所谓规则链即规则的执行部分将触发工作区或者参数的更改而且这些规则所匹配的对象本身没有关联。

例如有这样的规则：

金卡客户订单超过 5000 元，升级为钻石客户

钻石客户订单超过 5000 元，享受 75 折优惠

可以看到这两个规则之间存在规则链，因为它们的模式匹配基于两个不同的对象——客户和订单，并且订单的多少将导致客户对象级别的变化。

一般来说，如果您知道您的规则的执行部分将引发其他规则的执行，那么您应该使用 RetePlus 运行模式。

规则条件中使用什么类型的测试？

根据您的规则中使用什么类型的条件，所选择的运行模式也各异。

测试需要查询工作区

如果您的规则的条件使用 IRL exist 关键字验证 working memory 中否存在一个对象或使用 collect 关键字从工作区中收集一些对象而不提供 from 或 in 在条件的构造中，那么我们建议您使用 RetePlus 或者 Fastpath 运行模式。

测试条件具有特定规律

如果您的规则的测试条件具有一致的模式或顺序，就像决策表所使用的测试，那么我们建议您使用 Fastpath 运行模式。

如果测试条件的顺序没有规则，则使用 RetePlus 或者顺序运行模式。

您的业务规则使用了什么样的优先设置？

如果您的规则设置了静态优先级，可以使用任何运行模式。然而如果您设置的是动态的优先级即优先级被定义成一个表达式，则您只能选择 RetePlus 运行模式。

小结

您可以参考下表来决定为您的任务选择运行模式：

表 3. 选择运行模式

规则任务类型	RetePlus	Sequential	Fastpath
一致性检查、校验	×	√	√
计算型应用	√	×	×
相关性应用	√	×	√
有状态型应用	√	×	×
使用 Working Memory 对象	√	√	√
规则链	√	×	×
对 Working Memory 中的对象进行存在性和集合性测试	√	√	√
测试条件具有一致性	×	×	√
异构绑定	√	×	√
动态优先级	√	×	×
动态规则选择	√	√	×
大量规则聚合	×	√	√

 

回页首

在 Rule Studio 中为您的任务设置运行模式

JRules 支持在规则任务级别上设置运行模式，因此，您可以在 Rule Studio 中为规则流中的每一个规则任务指定不同的运行模式，默认情况下，规则任务将采用 Reteplus 模式执行。为规则任务设置运行模式，首先需要代开需要设置的规则任务所在的规则流；选中需要设置的规则任务。

图 4. 规则流

这时在规则任务的属性窗口中，将可以看到该规则任务所使用的规则执行的算法，默认是使用 RetePlus，您可以在这里修改为 Sequential 或者 FastPath。

图 5. 规则任务属性

 

回页首

结束语

JRules 规则引擎提供了 RetePlus、Sequential 和 FastPath 三种运行模式，以适应不同的应用需求，获得最优性能。在基于业务规则引擎的应用中，需要根据不同应用的特点，合理地组织和编排业务规则，选择合适的运行模式，有助于更好的发挥规则引擎的效能。