CN101739248A - 执行规则集的方法和系统 - Google Patents

Abstract

本发明提供了一种对在规则引擎中处理的规则的优先级进行更新的方法和系统。在方法中，针对每个实例，根据与规则引擎的运行时间性能相关的因素，例如规则之间的被依赖关系、规则被执行的次数，来计算规则的优先级；以及使用所计算的优先级更新所述规则的优先级，使得具有较多执行次数和/或具有较多被依赖关系的规则具有更高的优先级。使用本发明对规则的优先级更新之后，根据更新后的优先级对规则进行排序，使得较高优先级的规则先运行，从而提高规则引擎的运行时间性能。

Description

执行规则集的方法和系统

技术领域

本发明总体上涉及规则集的执行，更具体地，本发明涉及更新规则的优先级以对规则集执行进行排序的方法及相关系统和计算机程序产品。

背景技术

在现代的生产活动中，管理者需要制定业务规则来对生产活动进行经营管理。此处“生产活动”的含义很广泛，可以包含例如银行系统的储蓄服务、商场的销售策略、物流公司的货物装载、网络安全策略、电子邮件中对垃圾邮件的过滤管理，等等。在各种不同的领域中，管理者可以制定不同的业务规则。例如，在商场的销售策略中，业务规则可以包括规则1：铜牌客户并且当日消费满3000元，直接升为金牌客户；规则2：银牌客户并且当日消费满1000元，升为金牌客户；规则3：金牌客户的优惠折扣是70％等。又如，在网络安全策略中，可以建立防火墙规则来保护网络，这些防火墙规则例如可以是：拒绝所有外面传入的、向外的和转发的包；允许所有外传的TCP连接；允许外发的TCP连接的返回封包通过防火墙，需检查封包的状态；等等。

将上面提到的这些业务规则采用逻辑上可执行的方式来表述，也即转换为处理器可以执行的计算机语言，就可以通过业务规则管理器来使管理者方便地管理规则逻辑，从而能够灵活地定制业务策略来满足随外部条件不断变化的业务需求。

现有技术中已经存在一些将业务规则转换为计算机语言的工具，例如ILOG公司的ILOG Rules组件工具。ILOG Rules主要是让用户用软件“语言”来描述其业务逻辑规则，从而自动生成业务规则并对其进行集中管理。还有一个工具是微软公司的基于VisualStudio的Workflow Foundation(WF)，图1中示出了WF的规则集编辑器的屏幕截图。

不管采用哪种工具编写业务规则，通常规则主要由两部分构成：条件过滤器和动作。从计算机语言的角度来说，规则包括“如果(IF)”子句与“那么(Then)”子句，可选地包括“否则(Else)”子句。条件过滤器描述了动作触发时所处的情景或者状态，而动作将会在条件过滤器的值为真的情况下被执行。每条规则包括一个条件过滤器和多个动作，其中条件过滤器又可以包含多个过滤条件，条件过滤器是布尔表达式的组合。每一种动作都应当有其相应的条件。当不同的条件出现时，就会有不同的动作被触发。

以上面提到的商场销售策略中的业务规则为例，其中规则3的条件是客户是金牌客户。在满足该条件时，该规则的动作是执行70％的优惠折扣。另一条规则2的条件是客户是银牌客户并且当日消费满1000元，在满足该条件时相应的动作是升为金牌客户。

在图1所示的WF的规则集编辑器的屏幕截图中，示出了采用计算机语言描述的规则。例如，对于屏幕截图中选中显示的名称为“Business Discount”的规则，其定义了条件(如图中所标示的)：订单价值＞10000并且客户类型是某一特定类型。该规则还定义了相应的动作(如图中所标示的)：折扣＝10。在此示例中未定义“否则(Else)”子句。

通常对于一项生产活动，可以有多条规则，例如前面提到的商场销售策略中的多条规则。这些相关规则的集合就构成了规则集。更确切地说，规则集是指一系列的按照一定顺序排列的规则的集合。最常见的形式是IF-THEN(如果-那么)规则集。在定义了各种各样的规则及其规则集之后，通过规则引擎来实践这些规则。在实际的生产活动中会产生各种各样的事件或事实。例如，在商场销售活动中，某银牌客户购物消费2000元，某金牌客户购物消费1000元等。在网络安全方面，可能会有从外面传入的数据包、向外发送的TCP连接等。在此文中，将这些事件或事实称为业务实例、实例或数据对象。规则引擎接收这些要被规则集处理的实例的输入，加载或者更新相关的规则集，解释规则，以及执行规则等。通过规则引擎的上述操作，可以有效地进行各类业务处理。

规则引擎对规则的处理通常包括：测试规则集中的规则的条件；以及在满足条件时执行相应的动作。在处理规则时，规则引擎根据规则的顺序依次测试规则的条件。每条规则只执行一次或者从不执行，直到没有规则可执行。

图2示出了一种在规则引擎中顺序执行规则集的典型算法流程。如图2所示，首先输入要被规则集处理的业务实例。接着在步骤S201中，测试规则集中的所有规则的条件。在图2中，规则由条件和动作构成的链表示。如果该业务实例能够满足某条规则R的条件，则称为该实例激活规则R。在测试完所有条件后，若同时存在多条被激活的规则，也即存在冲突，则将所有被激活的规则放入冲突集中。然后，在步骤S202，从冲突集中随机选择一条规则以执行其动作，并将该已执行的规则从规则集中删除。在步骤S203，判断是否已经执行了一条规则，如果否，即无激活的规则可执行，则结束对该业务实例的处理，可以进入下一实例；如果是，即已经执行了一条激活的规则，则由于规则的执行动作可能会改变业务实例，从而会使某些规则因为条件改变而失效或激活，因此必须回到步骤S201。再次测试规则集中的所有规则的条件，重复执行步骤S201到S202。注意，此时的规则集已经删除了已经执行过的规则。

上述方案中规则执行的顺序是随机的，并且每次都对所有条件进行测试，从而运行时间明显过长，是一种传统保守的方案。一种改进的解决方案是：由专家用户为每个规则指定优先级，然后按照优先级的顺序执行规则。此类规则例如参考图1中所示的WF的规则集编辑器，其中在对规则进行编辑时，对规则的优先级进行了设定(参见图中圆圈所标示的)。基于该预先设定的优先级，可以在规则引擎中更有效地执行规则，其算法流程如图3所示。

图3的算法流程类似于图2，包括：步骤S301，针对输入的业务实例，对规则集中的规则逐个测试其条件，将所有被激活的规则放入冲突集中；步骤S302，从冲突集中选择一条规则以执行其动作，并将该已执行的规则从规则集中删除；步骤S303，判断是否已执行一条规则，如果否，则结束对该业务实例的处理，如果是，则重复执行步骤S301到S302，直到冲突集中没有规则可执行。图3的算法流程相对于图2的改进在于：其在规则条件测试步骤S301以及选择规则执行步骤S302中考虑了规则的优先级。这些优先级是在规则设计阶段由专家用户设定的，也即是固定的。当规则引擎执行规则时，由于规则的执行动作可能会改变业务实例，从而会使冲突集中的某些规则因为条件改变而失效，必须从冲突集中撤销。规则的执行动作也可能会激活原来不满足条件的规则，生成新的被激活规则进入冲突集。因此，根据设定的优先级顺序来执行，能够在一定程度上改善该问题。

但是，在此改进方案中，规则的优先级需要专家用户预先指定。这对于不具有专家知识的用户来说其运行时间性能的改善效果不明显。而且，即使是专家用户设定规则的优先级，所设定的优先级不一定准确地反映了实际状况。此外，当业务环境改变时，固定的优先级不能适应该改变。

发明内容

现有技术中尚无进一步针对规则执行的顺序进行改进的方案。因此，需要一种对规则集执行的顺序进行改进的方案，以提高规则引擎运行时间性能，缩短花费的时间。

为了克服现有技术中存在的上述一个或多个不足之处，本发明提供了一种在规则引擎中更新规则的优先级的方法、系统以及相应的计算机程序产品。

根据本发明的一个方面，提供一种对在规则引擎中处理的规则的优先级进行更新的方法，包括步骤：针对每个实例，根据与规则引擎的运行时间性能相关的因素计算规则的优先级；以及使用所计算的优先级更新所述规则的优先级。其中，与规则引擎的运行时间性能相关的因素包括规则之间的被依赖关系以及规则被执行的次数中的至少一个。在计算规则的优先级时，使得具有较多执行次数和/或具有较多被依赖关系的规则具有更高的优先级。使用本发明的方法对规则的优先级更新之后，根据更新后的优先级对规则进行排序，使得较高优先级的规则先运行，从而提高规则引擎的运行时间性能。

根据本发明的另一方面，提供一种对在规则引擎中处理的规则的优先级进行更新的系统，包括：优先级计算组件，其配置为针对每个实例，根据与规则引擎的运行时间性能相关的因素计算规则的优先级；以及更新组件，使用所计算的优先级更新所述规则的优先级。其中与规则引擎的运行时间性能相关的因素包括规则之间的被依赖关系以及规则被执行的次数中的至少一个。所述优先级计算组件包括规则执行次数计算组件和规则被依赖关系分析组件，其使得具有较多执行次数和/或具有较多被依赖关系的规则具有更高的优先级。

根据本发明的另一方面，还提供一种包含用于执行根据本发明的方法的计算机程序代码的计算机程序产品。

本发明通过使用规则优先级对规则集中的规则进行排序，能够有效地改善运行时间性能，提高执行效率。特别地，本发明的规则优先级能够随着规则引擎的运行而不断学习、更新优先级，从而逐步修正规则的优先级并与变化的业务环境相适应。因此，非专家用户也能够简单、方便地应用本发明的系统，例如可以随意设置规则的初始优先级。

附图说明

参考以下结合附图的详细说明后，本发明的特征、优点以及其它方面将变得更加明显，其中在附图中：

图1示出了现有技术中规则集的示例，微软公司的基于VisualStudio的Workflow Foundation；

图2示出了现有技术中顺序执行规则集的典型算法流程；

图3示出了现有技术中具有固定优先级的顺序执行规则集的算法流程；

图4示出了根据本发明的方法的总体流程；

图5示出了可以应用本发明的整体系统架构；

图6示出了根据本发明的一种实施方式的更新优先级的算法流程；

图7示出了根据本发明的另一种实施方式的更新优先级的算法流程；

图8示出了应用本发明方法的算法1进行实验得到的结果；

图9示出了应用本发明方法的算法2进行实验得到的结果；以及

图10示出了可以实现本发明的计算机系统。

请注意，在全部附图中，若存在的话，相同的参考标记表示相同的部件。

具体实施方式

在以下的详细描述中，为了便于全面理解本发明，通过示例的方式说明了许多特定的细节。不过本领域技术人员可以很清楚，本发明也可以不需要这些细节就能实现。此外，为了更加清楚地解释本发明，在某些示例中，公知的方法、处理、元件和电路仅仅是进行了概括性地描述，而没有详细说明。以下结合附图对本发明进行更详细的解释和说明。应当理解，本发明的附图及实施例仅用于示例性作用，不是用于限制本发明的保护范围。

从背景技术中的介绍可知，任何一个规则引擎都需要很好地解决规则条件测试的效率问题，规则条件测试的效率决定了规则引擎的运行时间性能。规则引擎需要快速测试业务实例，从相应的规则集中发现符合条件的规则并执行规则。规则条件测试的效率主要由规则的顺序决定，低效的顺序可能导致不可接受的性能。

因此，本发明的基本思想是为规则动态分配优先级，使得高优先级的规则先被测试/执行。该优先级能够随着规则引擎的运行、基于影响规则引擎的运行时间性能的因素而不断学习、更新，从而逐步修正规则的优先级。修正后的优先级能够正确反映规则所应用的业务环境，实现运行时间性能的提高。

影响规则引擎的运行时间性能的因素有很多。本发明人发现，如果在对大量业务实例的处理过程中，执行规则R1的次数较高，则将R1放在其他规则的前面，可以有效地减少条件测试的次数，从而提高运行时间性能。例如，以上面提到的商场销售策略中的业务规则为例。假设存在100个客户(业务实例)，其中40个是金牌客户，其直接激活规则3；60个是铜牌客户并且消费满3000元，其直接激活规则1，继而激活规则3。在该100个业务实例中，规则1总共执行60次，规则3总共执行100次，规则2执行0次。如果按照规则1、2、3的顺序排列，则针对该100个业务实例，条件测试的总次数为40×5+60×4＝440次。而如果按照执行次数排列，即按规则3、1、2的顺序排列，则条件测试的总次数为40×3+60×4＝360次。从该例子可以看出，对于所给定的100个业务实例，执行次数较多的规则3排在前面能够有效减少条件测试的次数。

另一方面，如前面所提到的，规则之间可能会相互影响，例如某个规则的执行可能会激活其他的规则。本发明人发现，如果将会激活其他规则的规则放置在前面，也能有效地减少条件测试的次数。此处将规则之间的这种关系称为被依赖关系。例如，再次以上面提到的商场销售策略中的业务规则为例。如果规则1被执行，即将铜牌且当日消费满3000元的客户直接升为金牌客户。这时，业务实例发生改变，会触发规则3，即金牌客户的优惠折扣为70％。从此关系可以看出，规则3的执行依赖于规则1的执行，换言之，规则1被规则3所依赖。

将具有较多此类被依赖关系的规则排放在其他规则的前面可能是有利的。因为对于某一业务实例，如果其会触发具有被依赖关系的规则(例如规则1)，则必然会导致触发依赖于其的规则(例如规则3)。仍然以上面提到的商场销售策略中的业务规则为例，考虑规则的顺序对铜牌客户并且消费满3000元的此类业务实例的影响。如果按照规则3、2、1的顺序排列，则对于铜牌客户并且消费满3000元的业务实例来说，其条件测试的次数为5次。具体地，第一轮测试3次后执行规则1，继而第二轮测试1次后执行规则3，第三轮测试1次后结束处理。该处理中，对规则3测试了两次。如果将具有被依赖关系的规则1放置在依赖其的规则3之前，也即按照规则1、3、2的顺序排列，则条件测试的次数为3次。具体地，第一轮测试1次后执行规则1，第二轮测试1次后执行规则3，第三轮测试1次后结束处理。从上述例子可以看出，对于会激活存在被依赖关系的规则的业务实例(例如，铜牌客户并且消费满3000元的业务实例)来说，如果具有被依赖关系的规则(例如规则1)排放在前面，就能有效避免重复测试依赖于该规则的规则(例如规则3)。

通常，规则引擎需要处理大量的业务实例。总的条件测试次数不仅与每类业务实例的测试次数有关，而且与每类业务实例的数量有关。通过上面的分析可知，每类业务实例的条件测试次数受规则之间的被依赖关系影响；而每类业务实例的数量对应于业务实例激活规则的分布，也即规则执行的次数。因此，本发明综合考虑执行次数和被依赖关系，优化总的运行时间性能。例如，仍以上面的100个业务实例进行说明，其中40个金牌客户，60个铜牌客户并且消费满3000元。单纯按照执行次数，将规则排序为规则3、规则1、规则2。此时，总的条件测试次数为40×3+60×4＝360次。单纯按照被依赖关系，将规则排序为规则1、规则2、规则3，此时总的条件测试次数为40×5+60×4＝440次。综合考虑执行次数和被依赖关系，将规则排序为规则1、规则3、规则2，此时总的条件测试次数为40×4+60×3＝340次。

本发明主要从这两个因素入手，将规则被执行的次数以及规则之间的被依赖关系反映在规则的优先级中，从而有效地提高规则引擎的运行时间性能。不过本领域技术人员可以理解，还存在其他影响规则引擎的运行时间性能的因素，可以根据本发明的教导将这些因素类似地引入到规则的优先级中。

由于规则在针对每个业务实例的处理中，或者被激活并且执行一次或者从不执行，因此，在本发明中用规则执行次数矢量E来反映规则集中的属性。若规则被执行，则在E中相应的元素值为1，否则为0。

实际的规则可能比较复杂，例如存在多个条件，与其他规则之间存在依赖与被依赖的关系。本发明将规则之间的被依赖关系定义为：如果规则R_k只有在R_i被激活和执行后才被激活，则R_i与R_k之间存在被依赖关系，表示为R_i→R_k。类似地，本发明将规则集中的这种属性用被依赖关系矢量D来表示。现有技术中已有多种针对规则静态分析它们之间的被依赖关系的方法，此处不再赘述。

根据本发明的一种动态测试被依赖关系的方法可以是：如果在过去的条件测试循环或迭代中，规则R_k已被测试但是没有激活，并且在R_i被激活和执行之后规则R_k被激活，则可以认为存在被依赖关系R_i →R_k。

很显然，被依赖关系可以进行传递。例如，如果R_i→R_k并且R_k→R_l，则可以认为R_i→R_l。

矢量E和D的具体形式根据所应用的算法而不同。在下文中将针对各种示例性算法具体描述这些矢量以及它们的计算。

现在参考图4，其中示出了根据本发明的方法的总体流程。

如图4所示，规则引擎接收业务实例的输入，对业务实例逐个进行处理。在步骤400，首先为规则集中的各个规则分配初始优先级，也即初始化优先级。然后根据初始优先级，对这些规则排序，使得具有较高优先级的规则先被测试/执行。由于本发明的规则优先级可以根据随后应用的实例而不断更新、修正，因此，本发明对于初始优先级的设定没有严格要求。例如可以由普通用户随机设定各个规则的优先级，也可以统一分配相同的优先级。当然也可以由专家用户指定优先级。优选地，还可以针对规则集中的规则，预先静态分析它们之间的被依赖关系。例如分析规则的条件部分和动作部分，构建被依赖关系，从而确定优先级以作为初始的优先级。

接着，在步骤401，针对业务实例，对规则集中的规则逐个测试条件。注意，此时的规则已经按照初始的优先级进行了排序，因此，高优先级的规则先被测试。一旦测试到满足条件的规则，直接执行该规则的动作。继而在步骤S402，将该已执行的规则从规则集中删除，因为规则集中的规则在一次业务实例中只能被执行一次。

当规则引擎执行了规则之后，由于规则的执行动作可能会改变业务实例。继续上面提到的商场销售规则的实例，例如当所处理的业务实例为：银牌客户并且当日消费满1000元。该实例可以激活规则2，即银牌客户并且当日消费满1000元，升为金牌客户。在执行被激活的规则2的动作之后，该银牌客户升为金牌客户，这时业务实例发生了改变。改变后的业务实例会激活原来不满足条件的规则3，即金牌客户的优惠折扣是70％。因此，根据该改变后的业务实例要重新测试条件。继而，在步骤S402之后返回到步骤S401，重新测试其他规则的条件。重复该步骤，直到没有规则可执行，随后进入步骤S403。

在步骤S403，根据前面分析的本发明对规则引擎的运行时间性能考虑的两个因素，计算规则被执行的次数得到矢量E，以及分析规则之间的被依赖关系得到矢量D。然后根据执行次数矢量E和被依赖关系矢量D、通过特定算法计算规则的优先级。

在步骤S404，使用计算得到的优先级更新各个规则的优先级。在步骤S405，根据更新后的优先级对规则集中的规则重排序，使得具有较高优先级的规则先运行。然后，继续下一业务实例的处理。由于已经使用更新后的优先级对规则进行重排序，因此在下一业务实例的处理中，能应用该新的优先级信息来更有效地测试/执行规则，也即将业务环境的信息自动、快速地反映在规则的排序上。

通常规则引擎需要处理大量的业务实例。通过使得具有较多执行次数和较多被依赖关系的规则具有更高的优先级并基于优先级排序后，从统计学的角度来说，就可以减少整体的条件测试次数，提高规则引擎的整体运行时间性能。

还应当理解，本发明虽然基于两个因素对规则的优先级进行更新，但是这两个因素可以单独考虑、结合考虑甚至与其他影响规则引擎的运行时间性能的因素结合考虑。

图5示出了可以应用本发明的整体系统架构500，其中主要包括规则引擎系统510和优先级更新系统520。

规则引擎系统510可以是常规的系统，其中例如包括用于规则集执行的事实/业务实例512。这些业务实例512输入给规则引擎516，由规则引擎516根据相对应的规则集514进行处理。在块518中保存规则引擎对规则集执行的记录。

本发明的优先级更新系统520包括优先级计算组件522，更新组件530。具体地，优先级计算组件522中包括规则执行次数计算组件524、规则被依赖关系分析组件526以及计算组件528。

规则执行次数计算组件524计算针对每个业务实例，规则集中的各个规则被执行的次数，并将其表示为执行次数矢量E。规则被依赖关系分析组件526分析规则之间的被依赖关系，并将其表示为被依赖关系矢量D。计算组件528根据执行次数矢量E和被依赖关系矢量D、通过特定算法计算规则的优先级。更新组件530使用计算得到的优先级更新各个规则的优先级。

在系统架构500中还包括排序组件532，其使用更新后的优先级对规则集中的规则进行排序。从而，在下一个业务实例的处理中，能应用该新的优先级信息来更有效地测试/执行规则。

接下来，将详细介绍计算规则优先级的算法。本领域技术人员可以理解，根据本发明中提到的关系(也即：使得具有较多执行次数的规则具有更高的优先级和/或具有较多被依赖关系的规则具有更高的优先级)可以设计出多种计算优先级的算法。以下仅以两种算法为例来阐述本发明的实施。

在一种实施方式中，采用一种计算简单的算法(简称算法1)来实施本发明。参见图6，其中示出了根据本发明的更新优先级的算法1的流程。

不妨假设规则集中存在N条规则R₁，…，R_i，…，R_N。这N条规则的优先级可以表示为优先级矢量P，P＝(P₁，…，P_i，…，P_N)^T，P_i对应规则R_i的优先级，其中N为正整数，1≤i≤N。

如图6所示，在步骤S600，设置规则的初始优先级。在此示例中设置P_i＝1/N，i＝1，...N。接着，规则引擎对所接收的大量业务实例进行处理。在步骤S601，针对第一个实例Sj，j＝1开始处理。在步骤S602，针对该第一个实例S1，规则引擎执行相应的规则集，包括：条件测试、规则执行、规则删除、重复条件测试等，如图4中的步骤S401和S402所描述的。在执行完该规则集后，对执行过程中的信息进行记录，例如计算规则被执行的次数矢量E以及规则之间的被依赖关系矢量D。

在算法1中，将执行次数矢量E表示为N×1维的矢量，E＝(e₁，…，e_i，…，e_N)^T，其元素e_i表示规则R_i被执行的次数。由于规则在针对每个业务实例的处理中，或者被激活并且执行一次或者从不执行。因此，若规则R_i被执行，则e_i＝1，否则e_i＝0。针对每个业务实例，可以得到一个执行次数矢量E。

被依赖关系矢量D也表示为N×1维的矢量，D＝(d₁，…，d_i，…，d_N)^T。初始时，由于还没有动态分析规则之间被依赖关系，因此设置d_i＝0，i＝1，...N。当在业务实例的处理过程中发现存在被依赖关系R_i→R_k时，则d_i＝d_i+1，其中1≤k≤N，k≠i。针对每个业务实例，可以得到一个被依赖关系矢量D。

接着，在步骤S603，根据所得到的执行次数矢量E和被依赖关系矢量D计算更新矢量H(Sj)，H(Sj)＝λ₁·E+λ₂·D，其中λ₁和λ₂是权重系数，可以根据实际情况中执行次数与被依赖关系的重要程度进行调整。例如，当只根据执行次数矢量E来更新计算优先级时，可以使λ₂＝0。当只根据被依赖关系矢量D来更新计算优先级时，可以使λ₁＝0。对H(Sj)进行归一化得到H^*(Sj)。

然后，在步骤S604中，通过P＝d×P+(1-d)×H^*(Sj)计算这N条规则R₁，…，R_i，…，R_N的优先级，其中阻尼系数d的范围是0≤d≤1。d的值影响规则优先级更新速度的快慢。以极端的情况为例，d＝1时，更新矢量H(Sj)对规则的优先级P不产生影响，也即P不变化。d＝0时，新的优先级P完全由更新矢量H(Sj)决定，也即每处理一个业务实例，规则的优先级就更新为适应该业务实例的数值。很容易理解，如果d的取值太小，则优先级P更新的速度过快，不容易收敛。因此，通常d取0.85。此外，如果规则的初始优先级是由专家用户设定的，或者如前所述的根据预先静态分析的被依赖关系而设定初始优先级，则收敛速度可以更快，因为这样设置的初始优先级已经比较接近实际情况。

在步骤S605，根据更新后的优先级P中的各项P_i对规则集中的N条规则重新排序。P_i值大的规则排在前面，从而具有高优先级的规则先被测试/执行。调整顺序之后，在步骤S606中，可以继续下一业务实例的处理。如此循环，直到处理完所有业务实例，或者处理了预定数目的业务实例。最后，在步骤S607，退出处理。

在本发明的另一种实施方式中，采用一种较为复杂的算法(简称算法2)。参见图7，其中示出了根据本发明的更新优先级的算法2的流程。

在算法2中同样假设规则集中存在N条规则R₁，…，R_i，…，R_N，并将其优先级表示为优先级矢量P，P＝(P₁，…，P_i，…，P_N)^T。与算法1不同的是，算法2将优先级矢量P定义为：P＝F^*×P。针对每个实例Sj，通过P＝d×F^*×P+(1-d)K来迭代求解优先级矢量P。F^*表示更新矢量F的列归一化矢量。更新矢量F是N×N维的矢量，其通过F＝F+F(Sj)进行计算。阻尼系数d为0≤d≤1，K是N×1维的矢量，K＝(1/N，…，1/N，…，1/N)^T。P的初始值为P＝(1/N，…，1/N，…，1/N)^T。

与算法1类似，更新矢量F表示为F(Sj)＝λ₁·E+λ₂·D，其中，E为执行次数矢量，D为被依赖关系矢量，λ₁和λ₂是权重系数。不同之处在于，算法2中的矢量E和D都表示N×N维的矢量，其中：执行次数矢量

当对于实例Sj，规则R_i和R_k都被激活并执行时，e_i，k＝1，否则e_i，k＝0。被依赖关系矢量

初始时d_i，k＝0，当发现存在被依赖关系R_i→R_k时，d_i，k＝d_i，k+1，其中1≤i≤N，1≤k≤N。很明显，因为由于一条规则不能激活其自身，因此d_i，i＝0。

针对实例Sj，更新矢量F计算为：F＝F+F(Sj)。将其展开，即F＝F(S1)+F(S2)+...+F(Sj)。

图7示出了更新优先级的算法2的流程。在步骤S700，设置规则的初始优先级以及更新矢量F的初值。在此示例中设置P_i＝1/N，i＝1，...N，F＝0。接着，规则引擎对所接收的大量业务实例进行处理。在步骤S701，针对第一个实例Sj，j＝1开始处理。在步骤S702，针对该第一个实例S1，规则引擎执行相应的规则集，包括：条件测试、规则执行、规则删除、重复条件测试等，如图4中的步骤S401和S402所描述的。在执行完该规则集后，对执行过程中的信息进行记录，例如计算规则被执行的次数矢量E以及规则之间的被依赖关系矢量D。

接着，在步骤S703，根据所得到的执行次数矢量E和被依赖关系矢量D计算更新矢量F，F＝F+F(Sj)，F(Sj)＝λ₁·E+λ₂·D。对F进行列归一化得到F^*。

然后，在步骤S704中，对P＝d×F^*×P+(1-d)K迭代求解出优先级矢量P，直到P不变化或者变化幅度在预定范围内。具体地，求解优先级矢量P中的每个元素P_i，也即对于i＝1到N，计算为：

P_i＝(1-d)/N；

对于k＝1到N

P_i+＝d×F^*(i，k)×P_k

在步骤S705，根据更新后的优先级P中的各项P_i对规则集中的N条规则重新排序。P_i值大的规则排在前面，从而具有高优先级的规则先被测试/执行。调整顺序之后，在步骤S706中，可以继续下一业务实例的处理。如此循环，直到处理完所有业务实例，或者处理了预定数目的业务实例。最后，在步骤S707，退出处理。

上面通过示例性的方式介绍了两种更新优先级的算法。算法1计算简单，但是准确度稍差；算法2计算复杂，准确度高。通过应用本发明对大量业务实例进行测试，可以比较两种算法的差异以及相对于现有技术中已有的典型算法的优越性。

在实验中，设定了包含100条规则的规则集，即N＝100，随机分配这100条规则的优先级P。处理M个业务实例，M＝10000，假设每个业务实例根据高斯分布激活这100条规则，并且在这些规则之间存在随机的被依赖关系。

图8示出了应用本发明方法的算法1进行实验得到的结果。其中，图8(a)示出了100条规则初始的优先级分布。横坐标为规则的序号，从1到100。纵坐标为各个规则对应的优先级的数值，基本上分布在均值1/N＝0.01附近。

图8(b)示出了应用本发明的方法、在处理M个业务实例时采用算法1进行更新后的优先级分布。横坐标与纵坐标的含义与图8(a)相同。从图8(b)中可以看出，更新后的优先级近似于高斯分布。很容易理解，由于每个业务实例根据高斯分布激活此100条规则，因此，规则被执行的次数也基本上按照高斯分布。执行次数越多的规则应具有较高的优先级，因此，经过M次更新后，规则的优先级分布也接近于高斯分布。每次都按照更新后的优先级对规则进行排序，可以大大较少条件测试的次数。

图8(c)示出了算法1与现有技术的典型算法的比较。横坐标表示所处理的业务实例的数量，纵坐标表示算法1的平均条件测试次数与现有典型算法的比值。可以看出，由于采用了本发明的优先级更新算法，随着业务实例处理数量的增多，算法1的平均条件测试次数急速下降。算法1在处理了40-50个实例之后，逐步趋于稳定。此时算法1的平均条件测试次数只有典型算法的测试次数的12％左右，极大地提高了规则引擎的运行时间性能。

图9示出了应用本发明方法的算法2进行实验得到的结果。与图8类似，图9(a)示出了100条规则初始的优先级分布。横坐标为规则的序号，从1到100。纵坐标为各个规则对应的优先级的数值，基本上分布在均值1/N＝0.01附近。

图9(b)示出了应用本发明的方法、在处理M个业务实例时采用算法2进行更新后的优先级分布。从图9(b)可以明显看出，更新后的优先级比图8(b)的分布更接近于高斯分布，曲线很光滑。

图9(c)示出了算法2与现有技术的典型算法的比较。同样横坐标表示所处理的业务实例的数量，纵坐标表示算法2的平均条件测试次数与现有典型算法的比值。再次可以看出，由于采用了本发明的优先级更新算法，随着业务实例处理数量的增多，算法2的平均条件测试次数急速下降。算法2在处理了30-40个实例之后，逐步趋于稳定，此时算法2的平均条件测试次数接近典型算法的测试次数的10％。

此外，对比图8和图9也可以看出两种算法的差别：算法1计算简单，但是收敛速度相对较慢，而且收敛的结果有噪音；算法2计算相对复杂，但是收敛速度快，而且收敛的结果很理想，并且最终在平均测试条件次数方面也略优于算法1。

上文介绍了本发明的更新优先级的方法和系统，并且通过两种示例性的算法详细介绍了如何实现优先级的更新。但是，本领域技术人员可以理解，可以对本发明的方法进行扩展以适应各种现实生产活动中需要。

例如，考虑到规则引擎在对业务实例进行处理的实际运行中，如果每次都进行优先级更新，可能会降低处理速度。另外，偶然发生的实例可能会影响优先级的收敛。因此，本发明的方法可以扩展为，在对规则的优先级更新了预定次数或处理的业务实例达到预定数目之后，将最后更新的优先级固定下来，不再进行更新。

在一种实施方式中，可以将本发明的方法分为两个阶段实现：训练阶段和运行阶段。在训练阶段，从大量的训练业务实例中学习、更新规则的优先级，在对规则的优先级更新达到预定次数或者学习的业务实例达到预定数目之后结束训练。算法1和算法2可以分别用于训练阶段。然后，在规则引擎的实际操作，也即运行阶段，将从训练阶段中学习到的优先级固定下来，不再对其更新。在对随后的业务实例的处理中，始终使用该固定的优先级进行处理。

在另一种实施方式中，也可以在规则引擎的运行过程中更新优先级。当对规则的优先级更新预定次数或者处理的业务实例达到预定数目之后，停止更新，使用该最后更新的优先级作为固定的优先级，进行随后的其他业务实例处理。该实施方式实质就是将部分实际发生的业务实例作为训练序列来学习、更新规则的优先级。

下面，将参考图10来描述可以实现本发明的计算机系统。图10示意性示出了可以实现根据本发明的实施方式的计算机系统的结构方框图。

图10中所示的计算机系统包括CPU(中央处理单元)1001、RAM(随机存取存储器)1002、ROM(只读存储器)1003、系统总线1004、硬盘控制器1005、键盘控制器1006、串行接口控制器1007、并行接口控制器1008、显示器控制器1009、硬盘1010、键盘1011、串行外部设备1012、并行外部设备1013和显示器1014。在这些部件中，与系统总线1004相连的有CPU 1001、RAM 1002、ROM 1003、硬盘控制器1005、键盘控制器1006、串行接口控制器1007、并行接口控制器1008和显示器控制器1009。硬盘1010与硬盘控制器1005相连，键盘1011与键盘控制器1006相连，串行外部设备1012与串行接口控制器1007相连，并行外部设备1013与并行接口控制器1008相连，以及显示器1014与显示器控制器1009相连。

图10中每个部件的功能在本技术领域内都是众所周知的，并且图10所示的结构也是常规的。图10所述的结构方框图仅仅为了示例的目的而示出的，并非是对本发明的限制。在一些情况下，可以根据需要添加或者减少其中的一些部件。

此外，本领域技术人员可以理解，尽管本发明的各个方面可以作为框图、流程图或使用其它图示表示加以说明和描述，但可以理解，在此描述的这些模块、组件、设备、系统、技术或方法可以以作为非限制性实例的硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其它计算设备或其组合来实现。

尽管本发明的教导是在具体实施的上下文中描述的，但对于本领域技术人员显而易见的是，在不脱离本发明精神的情况下，可以对本发明各实施方式进行修改和变更。本说明书中的描述仅仅是用于说明性的，而不应被认为是限制性的。本发明的范围仅受所附权利要求书的限制。

Claims (22)

1.一种对在规则引擎中处理的规则的优先级进行更新的方法，包括步骤：

针对每个实例，根据与规则引擎的运行时间性能相关的因素计算规则的优先级；以及

使用所计算的优先级更新所述规则的优先级。

2.根据权利要求1所述的方法，其中与规则引擎的运行时间性能相关的因素包括规则之间的被依赖关系以及规则被执行的次数中的至少一个。

3.根据权利要求2所述的方法，其中在计算规则的优先级时，使得具有较多执行次数的规则具有更高的优先级。

4.根据权利要求2或3所述的方法，其中在计算规则的优先级时，使得具有较多被依赖关系的规则具有更高的优先级。

5.根据权利要求1-4任一所述的方法，在对所述规则的优先级更新预定次数或所处理的业务实例达到预定数目之后，将最后更新的优先级固定下来，不再进行更新。

6.根据权利要求4所述的方法，计算规则的优先级进一步包括：

将N条规则R₁，…，R_i，…，R_N的优先级表示为优先级矢量P，P＝(P₁，…，P_i，…，P_N)^T，N为正整数，1≤i≤N；

对于每个实例Sj，将优先级矢量P计算为：P＝d×P+(1-d)×H^*(Sj)，其中0≤d≤1，H^*(Sj)表示更新矢量H(Sj)的归一化矢量，计算更新矢量H(Sj)为：H(Sj)＝λ₁·E+λ₂·D，其中，E为执行次数矢量，D为被依赖关系矢量，λ₁和λ₂是权重系数。

7.根据权利要求6所述的方法，其中

执行次数矢量E＝(e₁，…，e_i，…，e_N)^T，当规则R_i被执行时，e_i＝1，否则e_i＝0；

被依赖关系矢量D＝(d₁，…，d_i，…，d_N)^T，初始时d_i＝0，当发现存在被依赖关系R_i→R_k时，d_i＝d_i+1，其中1≤k≤N，k≠i。

8.根据权利要求4所述的方法，计算规则的优先级进一步包括：

将N条规则R₁，…，R_i，…，R_N的优先级表示为优先级矢量P，P＝(P₁，…，P_i，…，P_N)^T，N为正整数，1≤i≤N；

将优先级矢量P定义为P＝F^*×P，其中F^*表示更新矢量F的列归一化矢量，更新矢量F是N×N维的矢量；

对于每个实例Sj，通过P＝d×F^*×P+(1-d)K，迭代求解优先级矢量P，其中0≤d≤1，K是N×1维的矢量，K＝(1/N，…，1/N，…，1/N)^T，P的初始值为P＝(1/N，…，1/N，…，1/N)^T；

更新矢量F计算为：F＝F+F(Sj)，F的初始值为0，F(Sj)＝λ₁·E+λ₂·D，其中，E为执行次数矢量，D为被依赖关系矢量，λ₁和λ₂是权重系数。

9.根据权利要求8所述的方法，其中：

执行次数矢量

当对于实例Sj，规则R_i和R_k都被激活并执行时，e_i，k＝1，否则e_i，k＝0；

被依赖关系矢量

初始时d_i，k＝0，当发现存在被依赖关系R_i→R_k时，d_i，k＝d_i，k+1，其中1≤i≤N，1≤k≤N。

10.根据权利要求1所述的方法，其中所述规则的优先级具有初始值，该初始值是随机设定的或者根据事先分析的规则之间的被依赖关系设定。

11.根据权利要求1所述的方法，其中在更新所述规则的优先级之后，根据更新后的优先级对规则进行排序，使得较高优先级的规则先运行。

12.一种对在规则引擎中处理的规则的优先级进行更新的系统，包括：

优先级计算组件，其配置为针对每个实例，根据与规则引擎的运行时间性能相关的因素计算规则的优先级；以及

更新组件，使用所计算的优先级更新所述规则的优先级。

13.根据权利要求12所述的系统，其中与规则引擎的运行时间性能相关的因素包括规则之间的被依赖关系以及规则被执行的次数中的至少一个。

14.根据权利要求13所述的系统，其中所述优先级计算组件包括规则执行次数计算组件，其使得具有较多执行次数的规则具有更高的优先级。

15.根据权利要求13或14所述的系统，其中所述优先级计算组件包括规则被依赖关系分析组件，其使得具有较多被依赖关系的规则具有更高的优先级。

16.根据权利要求12-15任一所述的系统，在对所述规则的优先级更新预定次数或所处理的业务实例达到预定数目之后，将最后更新的优先级固定下来，不再进行更新。

17.根据权利要求15所述的系统，所述优先级计算组件执行计算：

将N条规则R₁，…，R_i，…，R_N的优先级表示为优先级矢量P，P＝(P₁，…，P_i，…，P_N)^T，N为正整数，1≤i≤N；

对于每个实例Sj，将优先级矢量P计算为：P＝d×P+(1-d)×H^*(Sj)，其中0≤d≤1，H^*(Sj)表示更新矢量H(Sj)的归一化矢量，计算更新矢量H(Sj)为：H(Sj)＝λ₁·E+λ₂·D，其中，E为执行次数矢量，D为被依赖关系矢量，λ₁和λ₂是权重系数。

18.根据权利要求17所述的系统，其中

所述规则执行次数计算组件计算执行次数矢量E＝(e₁，…，e_i，…，e_N)^T，当规则R_i被执行时，e_i＝1，否则e_i＝0；

所述规则被依赖关系分析组件计算被依赖关系矢量D＝(d₁，…，d_i，…，d_N)^T，初始时d_i＝0，当发现存在被依赖关系R_i→R_k时，d_i＝d_i+1，其中1≤k≤N，k≠i。

19.根据权利要求15所述的系统，所述优先级计算组件执行计算：

将N条规则R₁，…，R_i，…，R_N的优先级表示为优先级矢量P，P＝(P₁，…，P_i，…，P_N)^T，N为正整数，1≤i≤N；

将优先级矢量P定义为P＝F^*×P，其中F^*表示更新矢量F的列归一化矢量，更新矢量F是N×N维的矢量；

对于每个实例Sj，通过P＝d×F^*×P+(1-d)K，迭代求解优先级矢量P，其中0≤d≤1，K是N×1维的矢量，K＝(1/N，…，1/N，…，1/N)^T，P的初始值为P＝(1/N，…，1/N，…，1/N)^T；

更新矢量F计算为：F＝F+F(Sj)，F的初始值为0，F(Sj)＝λ₁·E+λ₂·D，其中，E为执行次数矢量D为被依赖关系矢量，λ₁和λ₂是权重系数。

20.根据权利要求19所述的系统，其中：

所述规则执行次数计算组件计算执行次数矢量

当对于实例Sj，规则R_i和R_k都被激活并执行时，e_i，k＝1，否则e_i，k＝0；

所述规则被依赖关系分析组件计算被依赖关系矢量

初始时d_i，k＝0，当发现存在被依赖关系R_i→R_k时，d_i，k＝d_i，k+1，其中1≤i≤N，1≤k≤N。

21.根据权利要求12所述的系统，其中所述规则的优先级具有初始值，该初始值是随机设定的或者根据事先分析的规则之间的被依赖关系设定。

22.根据权利要求12所述的系统，还包括排序组件，用于在更新所述规则的优先级之后，根据更新后的优先级对规则进行排序，使得较高优先级的规则先运行。

Images