CN103532808B

CN103532808B - 一种整合规则引擎的企业服务总线

Info

Publication number: CN103532808B
Application number: CN201310525905.6A
Authority: CN
Inventors: 陶湧
Original assignee: Jiangsu Wanquan Science And Technology Co Ltd
Current assignee: Jiangsu Wanquan Intelligent Environment Equipment Co., Ltd.
Priority date: 2013-10-30
Filing date: 2013-10-30
Publication date: 2017-02-08
Anticipated expiration: 2033-10-30
Also published as: CN103532808A

Abstract

一种整合规则引擎的企业服务总线，包括服务总线模块，服务总线模块包括：服务接入单元，消息容器单元，服务接出单元，服务调解单元，消息路由单元，数据转换单元；企业服务总线还包括：平台管理模块，与所述服务总线模块相连，用于对企业服务总线的相关配置进行管理；企业服务总线还包括：规则服务模块，与所述服务总线模块相连，用于对企业服务总线进行业务规则和业务流程能力扩展；规则服务模块包括：业务规则单元，策略规则单元和规则引擎单元；本发明进行了基于ESB技术规范的功能研发和扩展，已是完整概念上的企业服务总线。有助于打破其它大型企业的市场垄断。

Description

一种整合规则引擎的企业服务总线

一、技术领域

本发明涉及网络通信技术领域，尤其涉及多通信协议服务总线和业务规则和业务流程处理。

二、背景技术

ESB(Enterprise Service Bus，企业服务总线)为分散服务提供了交互、组合和治理的基础架构，是SOA（Service Oriented Architecture，面向服务架构）的核心技术。

规则引擎是用以管理和自动实现业务规则的软件系统，其主要实现的功能是存储、分类和管理规则，验证规则的一致性，通过规则推断其它规则、联系规则和执行这些规则的应用程序，其中的规则主要是指企业内部（系统内部）业务逻辑、企业与企业间（系统与系统间）信息交互与处理的业务逻辑等。规则引擎概念的思想是从软件的应用逻辑中分离出业务规则，以实现各种业务的灵活处理。在传统的ESB下，业务逻辑被直接固定在ESB业务处理程序代码中，这使得应用程序维护复杂并且代价昂贵，变化的业务规则和业务流程总是引起对应用程序的频繁修改，尤其面临动态业务模型和业务流程的挑战时，传统ESB模式下开发的应用程序往往面临全面和代价高昂的修改，甚至设计变化。解决这个问题就需要采用新的开发模式，将业务逻辑从ESB业务处理代码层剥离。使用规则引擎恰恰提供了一个将业务处理和业务规则处理分离、共用和统一管理维护业务规则的系统开发构架。

三、发明内容

本发明所要解决的技术问题是，提供一种融合规则引擎的企业服务总线，推动技术创新。为解决上述技术问题，本发明提出了通过平台管理模块和规则服务模块对传统服务总线模块进行扩展，实现一个实用、易管理、易扩展的新型企业服务总线。

本发明的技术方案是：一种整合规则引擎的企业服务总线，上述企业服务总线包括服务总线模块，包括：

服务接入单元，接入单元基于OSGI组件技术实现的组态设计，把各种不同的接入格式（二进制、二进制数组、object、json、xml等）以及各种不同的通信协议（TCP/IP、UDP、HTTP、Web Service、SOAP、JMS等）封装成组态化组件，提供多种接入格式和协议适配；

消息容器单元，用于进行消息路由、服务组合、提供二进制转object、二进制数组转json、json转xml、xml转json等多种不同格式消息的数据映射和数据转换；

服务接出单元，用于向其它应用系统发送消息以及对消息格式和协议进行适配，关键技术和实现与服务接入单元相同；

服务调解单元，用于隐藏消息格式和协议，将业务逻辑从消息中独立出来，并可以实现本地独立的服务调用；

消息路由单元，用于对消息进行路由、过滤、合并和重新排序；

数据转换单元，用于对不同格式和传输协议的数据进行转换数据；

企业服务总线还包括：平台管理模块，与所述服务总线模块相连，用于对企业服务总线的相关配置进行管理；

企业服务总线还包括：规则服务模块，与所述服务总线模块相连，用于对企业服务总线进行业务规则和业务流程能力扩展；

规则服务模块包括：

业务规则单元，存放一组准确凝练的规则语句，用于描述、约束及控制业务的结构、运作等，是应用程序中的一段业务逻辑。是一组封装好的根据不同业务需求预先用XML的<Conditons>、<Consequence>节点写好的If--Then句式，而里面嵌入java代码作为一种业务逻辑判断语句和执行语句；

策略规则单元，存放一组业务决策和战略，是一段具体的业务执行指令。这是预先设定好的控制指令对象，包括各种符合服务总线模块100的格式化消息指令，包括报警信息指令、短信信息指令、发布信息指令、设备控制信息指令等。

规则引擎单元，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。本发明采用了drools实现规则引擎单元，通过服务总线模块100传递过来的消息的分类会在drools中调用不同的存储在业务规则单元中的规则语句进行逻辑判断，从而在策略规则单元中找到符合逻辑判断结果的业务执行指令进行最终的业务决策——向服务总线模块100发送具体的格式化消息指令，服务总线模块100会依据不同的格式化消息指令最终通过服务接出单元130向指定的目的地（其他应用系统或实际的输出设备）发送消息。

在本发明中，对传统企业服务总线（服务总线模块）进行规则服务模块扩展至关重要的原则是：（1）业务规则单元描述与业务相关的操作规范、管理章程、规章制度、行业标准等；（2）通过策略规则单元形式化地描述业务规则相应的决策和战略；（2）通过规则引擎单元分离工作流程和业务规则，匹配策略规则进行业务执行指令下发。在这个过程中，这三个原则贯穿始终。分离工作流程和业务规则的目的在于将关键的业务判断规则和业务事件响应提取出来，置于系统的公共部位（业务服务），供不同的应用程序工作流程使用，并且便于维护和管理。这是本发明得以顺利进行的前提。形式化地描述业务规则的目的则是将业务规则以一种能够被规则引擎处理的形式描述和表示，使业务规则可被运算化，使应用程序可以按照即定的策略规则也就是既定的决策和战略进行相应的处理。

本发明依托以下三个步骤通过规则服务模块对传统企业服务总线（服务总线模块）进行扩展：

（1）使用决策表提取规则（业务规则单元中的提取规则语句）

在本发明中首先要解决的问题是明确企业服务总线（服务总线模块）中有哪些规则以及对应的业务判定。商业事务中条件元素的集合构成规则，规则决定判定和反馈，在散乱的企业业务中初步提取规则和对应的判定可以使用决策表的方法。

	规则1	规则	2……	规则
					条件1	条件值
条件2
					……
条件j
					判定1	是否反馈
判定2
					……
判定k

表1

“表1”给出的是决策表的一般格式。其中条件将成为系统中的数据域，条件值则是对应的数据，是支持服务管理和维护的对象，同时是应用程序/数据获得系统捕获和提交的对象。若干条件及其值的集合构成规则，是业务服务管理和维护的对象，也是规则引擎处理的根据。判定是业务服务通过规则引擎处理给出的反馈，最后由应用程序/数据获得系统接收。

分离商业规则是基于规则引擎开发企业应用的前提，它是本发明中的第一步，也是必须和最重要的步骤。如果使用表1提供的决策表方法可以比较方便地分离业务逻辑和商业规则，比较清晰准确地描叙规则，并且具有与基于规则引擎的企业服务模型结合比较紧密的特点，这一特性使其可以对后续开发步骤中问题的解决提供有力支持。

（2）分析和解决规则冲突（规则引擎单元分析和解决业务规则冲突）

在分离和提取出规则之后，必须考虑规则之间的冲突，这里提到的冲突主要是指由于规则之间同一条件的值域相交而引起的判定歧义。如果规则之间存在冲突而没有得到解决将造成判定结果的不确定，使规则引擎的处理不能正确进行。我们可以通过使用决策网格来侦测规则之间的冲突。具体的做法是将各条规则依次置于网格的行首和列首，网格中的每一个单元表示对应规则的交叉点，用以记录相交的规则或者规则集合为真时，反馈值是否发生歧义。判断规则是否冲突的依据是相交规则所包含条件值域的交集以及各个判定的反馈值，具体流程如“图4”所示：

在明确了规则之间的冲突关系之后，自然必须考虑如何解决冲突。在本发明中我们提出三种解决规则冲突的方案：(1)优先级模式；（2）队列模式；（3）常用模式。

优先级模式：设定规则的优先级顺序，在规则发生冲突时采纳较高优先级规则的判定反馈。有利于保持业务处理结果的长期稳定性，适用于业务处理规则比较明确的企业应用。

队列模式：先进先出原则，即先使用原则。在一个时间段内集中批处理业务时，若发生规则冲突，则采纳先使用（前一次或第一次处理已使用）规则的判定反馈。有利于保证统一批次业务处理结果的一致性，适用于有业务高峰的企业应用。

常用模式：记录和参考业务处理中规则的使用频率（规则为真的频率），在发生规则冲突时采纳使用频率较高或较低的规则反馈。有利于根据业务开展情况灵活适用规则，适用于业务开展情况多变的企业应用。

在一个企业应用服务中，以上提出的规则冲突解决方案可以单一使用也可以结合使用，以构成企业应用的规则冲突解决机制。在没有采取规则冲突解决方案的情况下，一般规则引擎会采用LIFO(last in,first out)原则解决规则冲突，但是对于一个成功的基于规则引擎开发的企业应用，一套规则冲突解决机制是必不可少的。

（3）形式化描述规则（策略规则形式化描述业务规则）

规则集的冲突问题得到解决之后，本发明的下一步是要形式化地描述规则，使其具有可代码化和可运算化的性质。当前的规则引擎一般都是基于Dr.Charles L.Forgy于1979年提出的Rete算法（网络算法）。Rete算法的基本思想是组织一个有效的辨别网络，通过数据在网络中的传播来过滤数据。Rete算法的具体做法是首先建立一个根结点（rootnode）作为数据对象进入辨别网络的入口，根据规则所包含的条件建立测试结点构成辨别网络，在网络的最底层构建若干终结点（terminal node）描述相应的规则。数据对象进入辨别网络之后经过途径结点，最终到达某个终结点，激活这个终结点所描述的规则。根据Rete算法的特性，要求将规则分割为LHS（left hand side）和RHS（right hand side），LHS由规则的条件部分组成，决定辨别网络中测试结点的生成，RHS由规则的判定部分组成，决定辨别网络中终结点的生成。

最终服务总线模块通过以上规则服务模块的设计和实现得到了业务规则和业务流程处理的能力扩展。

本发明的有益效果是：上述企业服务总线还具有以下特点，所述企业服务总线还包括：平台管理模块和规则服务模块，与所述服务总线模块相连，用于对企业服务总线的相关配置进行管理。本发明的企业服务总线，其核心功能模块部分主要基于规则引擎充当业务逻辑处理的功能，在此基础上，本发明进行了基于ESB技术规范的功能研发和扩展，本发明的企业服务总线已是完整概念上的企业服务总线。本发明的企业服务总线有助于打破其它大型企业例如IBM、Oracle等对ESB产品和SOA市场的垄断。

四、附图说明：

图1是包括整合规则引擎的企业服务总线的框图；

图2是本发明总路线模块框图；

图3是规则服务模块框图；

图4是判断规则是否冲突的依据以及各个判定的反馈值的具体流程。

五、具体实施方式：

服务接入单元，接入单元基于组态设计，提供多种接入格式和协议适配；消息容器单元，用于进行消息路由、服务组合、数据映射和数据转换；服务接出单元，用于向其它应用系统发送消息以及对消息格式和协议进行适配；

规则服务模块包括：

业务规则单元，存放一组准确凝练的规则语句，用于描述、约束及控制业务的结构、运作等，是应用程序中的一段业务逻辑；

策略规则单元，存放一组业务决策和战略，是一组具体的业务执行指令；

规则引擎单元，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

以下述三个步骤通过规则服务模块对传统企业服务总线（服务总线模块）进行扩展：

（1）使用决策表提取规则，即业务规则单元中的提取规则语句：

明确服务总线模块中有哪些规则以及对应的业务判定：商业事务中条件元素的集合构成规则，规则决定判定和反馈，在散乱的企业业务中初步提取规则和对应的判定可以使用决策表的方法。

上述“表1”给出的是决策表的一般格式。

表2

表2中的“achieveTarget”表示条件“完成销售指标”；“saleVolume”表示条件“销售额”；“amortization”表示判定“提成”；“warn”表示判定“提出警告”；“preVolume”表示数据“上月销售额”。

在“表2”中，列A描述了应用中所涉及的条件和系统处理后的判定，与各个条件或者判定同行的单元格中的值组合构成列B至列G，列B至列G中的每一列都是通过决策表得以分离的规则，规则通过条件值集合和判定反馈值的形式得以描述。例如规则2（rule2）描述的业务规则是：若没有完成销售指标，且销售额大于上月销售额，那么不给警告、并且判定提成比率为1%。规则5（rule5）描述的业务规则是：若完成销售指标，且销售额小于或等于上月销售额，那么给予警告，并且判定提成比率为1%。在实际的应用中可以通过对企业成文或不成文商业规则的总结和归纳来生成决策表，在必要时，例如商业规则不明确时也可以通过对条件组合的穷举来制定决策表，在以后的开发过程中再进行精简。

分离商业规则是基于规则引擎开发企业应用的前提，它是基于规则引擎的企业服务开发模式中的第一步，也是必须和最重要的步骤。如果使用本文提供的决策表方法可以比较方便地分离业务逻辑和商业规则，比较清晰准确地描叙规则，并且具有与基于规则引擎的企业服务模型结合比较紧密的特点，这一特性使其可以对后续开发步骤中问题的解决提供有力支持。

在分离和提取出规则之后，必须考虑规则之间的冲突，这里提到的冲突主要是指由于规则之间同一条件的值域相交而引起的判定歧义；如果规则之间存在冲突而没有得到解决将造成判定结果的不确定，使规则引擎的处理不能正确进行；能通过使用决策网格来侦测规则之间的冲突；具体的做法是将各条规则依次置于网格的行首和列首，网格中的每一个单元表示对应规则的交叉点，用以记录相交的规则或者规则集合为真时，反馈值是否发生歧义；判断规则是否冲突的依据是相交规则所包含条件值域的交集以及各个判定的反馈值，具体流程如“图4”所示：

在明确了规则之间的冲突关系之后，自然必须考虑如何解决冲突；采用三种解决规则冲突的方案：(1)优先级模式；（2）队列模式；（3）常用模式；

优先级模式：设定规则的优先级顺序，在规则发生冲突时采纳较高优先级规则的判定反馈。有利于保持业务处理结果的长期稳定性，适用于业务处理规则比较明确的企业应用；

队列模式：先进先出原则，即先使用原则。在一个时间段内集中批处理业务时，若发生规则冲突，则采纳先使用（前一次或第一次处理已使用）规则的判定反馈。有利于保证统一批次业务处理结果的一致性，适用于有业务高峰的企业应用；

常用模式：记录和参考业务处理中规则的使用频率（规则为真的频率），在发生规则冲突时采纳使用频率较高或较低的规则反馈。有利于根据业务开展情况灵活适用规则，适用于业务开展情况多变的企业应用；

在一个企业应用服务中，以上规则冲突解决方案单一使用或结合使用，以构成企业应用的规则冲突解决机制；在没有采取规则冲突解决方案的情况下，规则引擎会采用LIFO(last in,first out)原则解决规则冲突；

（3）形式化描述规则（策略规则形式化描述业务规则）

采用Rete算法，首先建立一个根结点（root node）作为数据对象进入辨别网络的入口，根据形式化描述规则所包含的条件建立测试结点构成辨别网络，在网络的最底层构建若干终结点（terminal node）描述相应的规则；数据对象进入辨别网络之后经过途径结点，最终到达某个终结点，激活这个终结点所描述的规则；根据Rete算法的特性，要求将规则分割为LHS（left hand side）和RHS（right hand side），LHS由规则的条件部分组成，决定辨别网络中测试结点的生成，RHS由规则的判定部分组成，决定辨别网络中终结点的生成。

企业服务总线即服务总线模块进行规则服务模块扩展：（1）业务规则单元描述与业务相关的操作规范、管理章程、规章制度、行业标准；（2）通过策略规则单元形式化地描述业务规则相应的决策和战略；（3）通过规则引擎单元分离工作流程和业务规则，匹配策略规则进行业务执行指令下发。在这个过程中，这三个原则贯穿始终。

分离工作流程和业务规则的目的在于将关键的业务判断规则和业务事件响应提取出来，置于系统的公共部位（业务服务），供不同的应用程序工作流程使用，并且便于维护和管理；形式化地描述业务规则的目的则是将业务规则以一种能够被规则引擎处理的形式描述和表示，使业务规则可被运算化，使应用程序按照即定的策略规则也就是既定的决策和战略进行相应的处理。

虽然本发明已以较佳实施例揭露如上，然其并非用以限定本发明。本发明所属技术领域中具有通常知识者，在不脱离本发明的精神和范围内，当可作各种的更动与润饰。因此，本发明的保护范围当视权利要求书所界定者为准。

Claims

1.一种整合规则引擎的企业服务总线，其特征是包括服务总线模块，服务总线模块包括：服务接入单元，服务接入单元基于OSGI组件技术实现的组态设计，把各种不同的接入格式以及各种不同的通信协议、包括TCP/IP、UDP、HTTP、Web Service、SOAP、JMS封装成组态化组件，提供多种接入格式和协议适配；消息容器单元，用于进行消息路由、服务组合、提供二进制转object、二进制数组转json、json转xml、xml转json多种不同格式消息的数据映射和数据转换；服务接出单元，用于向其它应用系统发送消息以及对消息格式和协议进行适配，关键技术和实现与服务接入单元相同；服务调解单元，用于隐藏消息格式和协议，将业务逻辑从消息中独立出来，并可以实现本地独立的服务调用；消息路由单元，用于对消息进行路由、过滤、合并和重新排序；数据转换单元，用于对不同格式和传输协议的数据进行转换数据；企业服务总线还包括：平台管理模块，与所述服务总线模块相连，用于对企业服务总线的相关配置进行管理；企业服务总线还包括：规则服务模块，与所述服务总线模块相连，用于对企业服务总线进行业务规则和业务流程能力扩展；规则服务模块包括：业务规则单元，存放一组准确凝练的规则语句，用于描述、约束及控制业务的结构、运作，是应用程序中的一段业务逻辑；这是一组封装好的根据不同业务需求预先用XML的<Conditons>、<Consequence>节点写好的If--Then句式，而里面嵌入java代码作为一种业务逻辑判断语句和执行语句；策略规则单元，存放一组业务决策和战略，是一段具体的业务执行指令；这是预先设定好的控制指令对象，包括各种符合服务总线模块(100)的格式化消息指令，包括报警信息指令、短信信息指令、发布信息指令、设备控制信息指令；规则引擎单元，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策；接收数据输入，解释业务规则，并根据业务规则做出业务决策；以下述三个步骤通过规则服务模块对传统企业服务总线即服务总线模块进行扩展：(1)使用决策表提取规则，即业务规则单元中的提取规则语句：明确服务总线模块中有哪些规则以及对应的业务判定：商业事务中条件元素的集合构成规则，规则决定判定和反馈，在散乱的企业业务中初步提取规则和对应的判定能使用决策表的方法；表1

“表1”给出的是决策表的一般格式；其中条件将成为系统中的数据域，条件值则是对应的数据，是支持服务管理和维护的对象，同时是应用程序/数据获得系统捕获和提交的对象；若干条件及其值的集合构成规则，是业务服务管理和维护的对象，也是规则引擎处理的根据；判定是业务服务通过规则引擎处理给出的反馈，最后由应用程序/数据获得系统接收；

表2

表2中的“achieveTarget”表示条件“完成销售指标”；“saleVolume”表示条件“销售额”；“amortization”表示判定“提成”；“warn”表示判定“提出警告”；“preMonth”表示数据“上月销售额”；在“表2”中，列A描述了应用中所涉及的条件和系统处理后的判定，与各个条件或者判定同行的单元格中的值组合构成列B至列G，列B至列G中的每一列都是通过决策表得以分离的规则，规则通过条件值集合和判定反馈值的形式得以描述；(2)分析和解决规则冲突、即规则引擎单元分析和解决业务规则冲突：在分离和提取出规则之后，必须考虑规则之间的冲突，这里提到的冲突主要是指由于规则之间同一条件的值域相交而引起的判定歧义；如果规则之间存在冲突而没有得到解决将造成判定结果的不确定，使规则引擎的处理不能正确进行；能通过使用决策网格来侦测规则之间的冲突；具体的做法是将各条规则依次置于网格的行首和列首，网格中的每一个单元表示对应规则的交叉点，用以记录相交的规则或者规则集合为真时，反馈值是否发生歧义；判断规则是否冲突的依据是相交规则所包含条件值域的交集以及各个判定的反馈值；在明确了规则之间的冲突关系之后；采用三种解决规则冲突的方案：1)优先级模式；2)队列模式；3)常用模式；优先级模式：设定规则的优先级顺序，在规则发生冲突时采纳较高优先级规则的判定反馈；有利于保持业务处理结果的长期稳定性，适用于业务处理规则比较明确的企业应用；队列模式：先进先出原则，即先使用原则；在一个时间段内集中批处理业务时，若发生规则冲突，则采纳先使用规则的判定反馈、即前一次或第一次处理已使用；有利于保证统一批次业务处理结果的一致性，适用于有业务高峰的企业应用；常用模式：记录和参考业务处理中规则的使用频率、规则为真的频率，在发生规则冲突时采纳使用频率较高或较低的规则反馈；有利于根据业务开展情况灵活适用规则，适用于业务开展情况多变的企业应用；在一个企业应用服务中，以上规则冲突解决方案单一使用或结合使用，以构成企业应用的规则冲突解决机制；在没有采取规则冲突解决方案的情况下，规则引擎会采用LIFO last in,first out原则解决规则冲突；(3)形式化描述规则即策略规则形式化描述业务规则采用Rete算法，首先建立一个根结点rootnode作为数据对象进入辨别网络的入口，根据形式化描述规则所包含的条件建立测试结点构成辨别网络，在网络的最底层构建若干终结点terminal node描述相应的规则；数据对象进入辨别网络之后经过途径结点，最终到达某个终结点，激活这个终结点所描述的规则；根据Rete算法的特性，要求将规则分割为LHS即left hand side和RHS即right hand side，LHS由规则的条件部分组成，决定辨别网络中测试结点的生成，RHS由规则的判定部分组成，决定辨别网络中终结点的生成。

2.根据权利要求1所述的整合规则引擎的企业服务总线，其特征是企业服务总线即服务总线模块进行规则服务模块扩展：(1)业务规则单元描述与业务相关的操作规范、管理章程、规章制度、行业标准；(2)通过策略规则单元形式化地描述业务规则相应的决策和战略；(3)通过规则引擎单元分离工作流程和业务规则，匹配策略规则进行业务执行指令下；在这个过程中，这三个原则贯穿始终。

3.根据权利要求2所述的整合规则引擎的企业服务总线，其特征是分离工作流程和业务规则的目的在于将关键的业务判断规则和业务事件响应提取出来，置于系统的公共部位的业务服务，供不同的应用程序工作流程使用，并且便于维护和管理；形式化地描述业务规则的目的则是将业务规则以一种能够被规则引擎处理的形式描述和表示，使业务规则可被运算化，使应用程序按照即定的策略规则也就是既定的决策和战略进行相应的处理。

4.根据权利要求1所述的整合规则引擎的企业服务总线，其特征是所述规则引擎单元采用了drools实现规则引擎单元，通过服务总线模块传递过来的消息的分类会在drools中调用不同的存储在业务规则单元中的规则语句进行逻辑判断，从而在策略规则单元中找到符合逻辑判断结果的业务执行指令进行最终的业务决策：向服务总线模块发送具体的格式化消息指令，服务总线模块会依据不同的格式化消息指令最终通过服务接出单元向指定的目的地、包括其他应用系统或实际的输出设备发送消息。