CN102130965A - 一种基于规则引擎的服务动态组合方法和系统 - Google Patents

Abstract

本发明公开了一种基于规则引擎的服务动态组合方法和系统，所述方法包括：拦截web服务调用请求信息和服务响应的返回信息；为拦截的服务调用请求信息分配唯一的标识号，并将该请求信息插入到规则引擎中；对于拦截到的服务响应信息，将其响应信息插入到规则引擎中；规则引擎根据业务规则和规则执行需要的上下文数据，推理出该服务的服务处理策略；根据规则引擎推理出的服务替换方案和服务信息中心提供的服务转换映射信息，对服务调用信息进行替换处理和服务的重定向。利用本发明，可以在新流程开发维护和旧系统业务规则修改两方面提高系统的柔性和敏捷性。

Description

一种基于规则引擎的服务动态组合方法和系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于规则引擎的服务动态组合方法和系统。

背景技术

BPEL作为服务组合的重要手段，是一种业务流程的建模和描述语言。BPEL通过WSDL来声明提供的服务接口以及依赖的服务接口和数据接口，并通过BPEL的基本活动和流程活动来指定了服务的调用顺序，Web服务以顺序、选择、循环、并发等方式来进行。然而在实际应用的时候有两个问题经常困扰着BPEL的开发和维护人员，即服务组合的伸缩性和柔性的问题。

一方面，BPEL在面对大规模的Web服务组合的时候相当繁琐，缺乏良好的伸缩性。在银行、电信、旅游等应用中往往存在着大量的Web服务，一个服务往往存在着若干备用服务以提高流程的可靠性。大量类似的服务在进行组合的时候问题往往难于管理，其XML文件也十分庞大。虽然可以采取分层定义的方法来降低子流程的规模，然而并没有从总体上减少需要声明和维护的服务数量。

另一方面，BPEL在面临业务规则修改的时候经常还是不够灵活，缺乏柔性。大多数业务流程包含多个业务决策点。在这些业务决策点处需要根据业务的规则分别对不同的决策结果加以不同的方式处理。现有的实践方案通常是将规则嵌入到BPEL流程或者Java代码里。这将导致一些重要的业务规则往往分散在流程及代码的各个角落，缺乏有效的组织和管理。这加重了修改和维护的负担。当某些业务规则需要依据灵活的销售方案，不确定的市场政策等因素进行频繁的变更时IT往往力不从心。现代企业常常以实时商业为目标，不断追求迅速决策带来的“两秒优势”，IT的缓慢带来了严重的损失。

本发明采用规则引擎将业务流程与业务规则分离的方法来解决这两方面的问题，通过规则引擎动态管理规则的规则和具体服务的选择，通过BPEL管理服务运作的整体流程。

发明内容

本发明提供一种基于规则引擎的服务动态组合方法和系统，通过规则引擎将业务流程与业务规则分离的方法，实现动态地组合服务。

本发明提供一种基于规则引擎的服务动态组合方法，包括：

拦截web服务调用请求信息和服务响应的返回信息；

为拦截的服务调用请求信息分配唯一的标识号，并将该请求信息插入到规则引擎中，对于拦截到的服务响应信息，将其响应信息插入到规则引擎中；

规则引擎根据业务规则和规则执行需要的上下文数据，推理出该服务的服务处理策略，上下文数据包括但不限于事实、模板、规则、查询、函数；

根据规则引擎推理出的服务替换方案和服务信息中心提供的服务转换映射信息，对服务调用信息进行替换处理和服务的重定向。服务转换映射信息包括但不限于需替换服务与目标替换服务间的操作名称、命名空间和前缀、消息变量名及消息变量值的映射信息。其中，操作名称、命名空间和前缀直接进行一对一的替换。对于变量的替换，本发明采用变量替换表达式(Varible Replace Expression，VRE)进行标识，从而实现任何服务消息间的替换。

所述方法还包括：业务规则存储在规则引擎的规则库中，被拦截到的服务请求信息以事实的形式被插入到规则引擎的事实库中；

新插入的事实或规则触发推理引擎匹配事实，执行规则；

规则引擎根据规则执行需要的上下文数据推理出当前拦截到的服务请求应该和哪个服务进行服务替换，以满足相应的业务流程；

在服务组合流程运行过程中，业务规则可以动态的添加到规则库中，事实可以动态的添加到规则引擎的事实库中，从而实现服务的动态组合。

所述方法还包括：规则库中的规则决定于具体业务规则，业务规则以脚本的方式写入规则引擎中，随着业务规则的改变可以动态修改规则库中的规则，而不需要重新部署。

所述方法还包括：如果规则引擎推理结果是不需要进行服务替换，则立即返回该服务调用；

如果规则引擎推理后得到的是服务替换方案，即规则引擎推理出当前服务应该与哪个服务进行替换；

根据该替换方案和服务信息中心存储的替换服务间的映射关系信息，对拦截到的服务调用消息进行替换处理后发出替换服务的请求调用，之后替换服务将会响应该服务请求，对拦截到的服务响应消息进行替换处理后将替换后的服务消息返回到其调用方。

所述方法还包括：通过变量替换表达式VRE来标识，通过VRE可以实现任何服务消息间的变量替换。对拦截到的服务消息进行替换处理后，服务调用将变为替换后的服务请求调用消息，替换服务将响应该服务请求。

在VRE中，定义了四种符号：string，.，$，#。这四个符号的运算优先级别是一次递增的关系，其中：

string：变量名/常量标识。由字符组成，可以是字母和数字、符号或汉字。根据前缀的不同，代表了变量名称或变量的值。String不可以包含$和#，并且当string表示变量时不能为全数字

.：变量层次关系前缀。例如person.id中的点标识变量id是变量person的一个子属性。

$：多重关系前缀。例如person.$friend中的$代表firend和person是一对多的关系

#：常量前缀。例如#3.0代表一个值为3.0的常量。

通过VRE，可以实现任何服务消息的替换。对调用服务消息进行替换处理后进行替换服务请求调用，替换服务将响应该服务请求。

本发明还提供一种基于规则引擎的服务动态组合系统，包括：服务调用代理、服务转换器、业务规则库、规则引擎和规则管理界面。

所述服务调用代理，用于拦截Web服务的调用，将调用的SOAP消息交由服务转换器处理，并将根据服务转换器的计算结果，将处理好的SOAP消息发给指定的接收者。

所述服务转换器，用于将Web服务的调用信息转换成事实，输入到规则引擎的事实库中，再从规则引擎中取出推理结果的服务替换处理策略。服务转换器根据替换策略从服务信息中心中获取服务映射关系，进行SOAP消息和服务的转换，最后将替换的结果交还给服务调用代理。

所述业务规则库，用于存储了服务转换的业务规则和规则运行需要的上下文数据。业务规则由前件和结论组成，前件是事实出发的条件，结论通常是增加新的事实或修改已有的事实，这些规则决定了最终服务的调用。

所述规则引擎，用于规则的推理，当服务转换器向规则引擎的事实库中添加事实时可能会触发一定的规则，最终获得若干表示执行命令的事实，规则引擎提供了Java程序的接口，以便和服务转换器交换数据，在推理的过程中默认采用后向推理，并通过Rete算法优化提高规则和事实匹配的效率。

所述规则管理界面，用于规则管理人员可以动态实时地改变规则，从而影响服务调用代理的行为，从而影响服务的组合。

由以上本发明实施例提供的技术方案可以看出，本发明实施例通过基于规则的动态服务组合，可以将业务流程与业务规则分离开来，从而在新流程开发维护和旧系统业务规则修改两方面提高系统的柔性和敏捷性。

附图说明

图1是本发明方法的基于规则引擎的服务动态组合架构图；

图2是本发明基于规则的服务动态组合方法流程图；

图3是本发明方法服务调用请求拦截示意图；

图4是本发明方法的规则引擎推理图；

图5是本发明方法的服务替换处理图；

图6是本发明方法的基于规则引擎的动态服务组合方法图；

图7是本发明传统的BPEL流程图；

图8是本发明基于规则引擎的动态BPEL流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明实施例作进一步的详细说明。

首先，参照图1是本发明方法的基于规则引擎的服务动态组合架构图，包括：服务调用代理、服务转换器、业务规则库、规则引擎和规则管理界面。

参照图2是本发明实施例的基于规则的服务动态组合方法流程图，将业务规则以规则形式加入到规则库中。并将所有可替换服务对信息及映射关系注册到服务信息中心中。BPEL中所有的WSDL描述中的Web服务结点中的服务地址均替换为服务调用代理地址和服务名称，并且在web.xml中配置服务调用代理servlet对所有的服务都可以进行拦截。

参照图3是服务调用请求拦截示意图。服务调用代理拦截所有服务调用请求，该请求中包括但不限于服务调用方的地址信息，服务名称，SOAP消息。采用Servlet作为实现的手段。通过重载doPost方法，获取请求中的服务名称，SOAP消息体。将拦截到的请求信息以事实的形式添加到规则引擎中。

参照图4是本发明方法的规则引擎推理图。主要步骤包括：

步骤401-步骤402：将拦截信息封装成事实，并插入到规则引擎的事实库中。进行插入是为每次的服务调用消息分配一个唯一的id；

步骤403：规则引擎根据事实库和规则库中的信息进行规则推理，得出推理结果。规则库中的信息为用户初始化时插入的业务规则信息。新插入的事实将被插入到事实库中，并触发一系列的规则匹配，得到推理结果。推理结果为一条策略事实。本发明中策略有两种：不替换和服务替换。不替换即直接返回该服务调用。服务替换事实包括但不限于服务调用id，替换服务，目标替换服务，替换方式。服务调用id用来区分不同服务调用信息。替换服务是当前拦截到的服务。目标替换服务是当前服务需要被替换后的服务。替换方式包括正向替换和反向替换两种。如果拦截到的服务是调用时服务，则进行正向替换。如果拦截到的服务是返回时服务，则需进行反向替换。

参照图5是本发明中服务替换处理图，主要步骤包括：

步骤501：服务转换器不断的查询规则引擎，当其查询到一条服务替换事实后，立即需要进行服务替换处理。

步骤502：根据查询到的服务替换事实中的替换服务对信息，从信息服务中心获取需要替换的服务信息及其映射信息。

步骤503：根据服务替换事实中的替换方式信息，进行正向替换或反向替换。

步骤504-505：根据服务替换事实，替换服务对信息及其映射信息，对当前服务进行正向或反向替换。替换部分包括：操作名称、命名空间和前缀、消息变量名及消息变量值的替换。其中，操作名称、命名空间和前缀直接进行一对一的替换。对于变量的替换，我们采用变量替换表达式(VRE)进行标识，从而实现任何服务消息间的替换。

另外，如果进行的是正向替换，服务请求被改变，调用替换后服务。服务调用成功后会返回一个回复消息，该消息内容类似调用时请求信息。返回信息同样会被服务调用拦截器拦截，并通过规则引擎判断是否进行替换，处理过程同上述步骤502-步骤504。最后返回到最初的服务调用方。至此，一次服务动态组合过程完成。

参照图6是本发明方法的基于规则引擎的动态服务组合方法图，一个BPEL流程实例中存在多次的服务调用，每次调用都会经过服务拦截，规则推理，服务替换三个过程，从而动态改变服务组合流程，最终实现服务动态组合。

参照图7是本发明传统的BPEL流程图，在新流程开发维护方面，传统的BPEL需要通过条件判断<If>，<Pick>等结构化活动实现复杂的业务规则，这一方面引入了大量相似服务，从而使得WSDL接口变得复杂庞大，难以开发维护，另一方面使得BPEL流程变得冗长难以理解。在传统方法中，BPEL通过两个<If>的判断实现了业务规则，决定接下来需要调用哪个服务，实现这种判断和调用需要两个判断活动和三个调用活动共五个活动。

在旧系统业务规则修改方面，传统的BPEL流程的业务规则如果发生了改变，则需要更改整个BPEL流程并重新部署。

参照图8是本发明基于规则引擎的动态BPEL流程图，在新流程开发维护方面，使用规则引擎后，一方面可以通过服务替换机制将相似服务进行合并，从而简化WSDL的开发维护，另一方面，将复杂的业务逻辑抽取出来，采用规则语言实现，从而使得BPEL的流程更加简单清晰。加入规则引擎之后，BPEL流程简化成直接调用，而具体的调用对象由规则引擎来判断，由于服务是实现发布和注册好的，因此实现相同的功能仅需要一个调用活动和两条规则语句。

在旧系统业务规则修改方面，而使用了规则引擎之后，只需向规则引擎中动态添加脚本即可，并不需要任何大的改动或者重新部署的过程。如果规则发生了修改的变化，则需要改变BPEL的流程，通过修改<If>活动来实现，之后重新部署整个流程，仅需规则向规则引擎中动态修改规则即可实现，无需修改流程。

以上对本发明实施例进行了详细介绍，本文中应用了具体实施方式对本发明进行了阐述，以上实施例的说明只是用于帮助理解本发明的系统及方法；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (7)

1.一种基于规则引擎的服务动态组合方法，其特征在于，包括：

拦截web服务调用请求信息和服务响应的返回信息；

为拦截的服务调用请求信息分配唯一的标识号，并将该请求信息插入到规则引擎中；

对于拦截到的服务响应信息，将其响应信息插入到规则引擎中；

规则引擎根据业务规则和规则执行需要的上下文数据，推理出该服务的服务处理策略；

根据规则引擎推理出的服务替换方案和服务信息中心提供的服务转换映射信息，对服务调用信息进行替换处理和服务的重定向。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：服务转换映射信息包括但不限于需替换服务与目标替换服务间的操作名称、命名空间和前缀、消息变量名及消息变量值的映射信息，操作名称、命名空间和前缀直接进行一对一的替换。

3.根据权利要求1所述的方法，其特征在于，业务规则存储在规则引擎的规则库中，被拦截到的服务请求信息以事实的形式被插入到规则引擎的事实库中；

新插入的事实或规则触发推理引擎匹配事实，执行规则；

规则引擎根据规则执行需要的上下文数据推理出当前拦截到的服务请求应该和哪个服务进行服务替换，以满足相应的业务流程；

在服务组合流程运行过程中，业务规则可以动态的添加到规则库中，事实可以动态的添加到规则引擎的事实库中，从而实现服务的动态组合。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：规则库中的规则决定于具体业务规则，业务规则以脚本的方式写入规则引擎中，随着业务规则的改变可以动态修改规则库中的规则。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：如果规则引擎推理结果是不需要进行服务替换，则立即返回该服务调用；

如果规则引擎推理后得到的是服务替换方案，即规则引擎推理出当前服务应该与哪个服务进行替换；

根据该替换方案和服务信息中心存储的替换服务间的映射关系信息，对拦截到的服务调用消息进行替换处理后发出替换服务的请求调用，之后替换服务将会响应该服务请求。对拦截到的服务响应消息进行替换处理后将替换后的服务消息返回到其调用方。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：通过变量替换表达式VRE来标识，实现任何服务消息间的变量替换，对拦截到的服务消息进行替换处理后，服务调用将变为替换后的服务请求调用消息，替换服务将响应该服务请求。

7.一种基于规则引擎的服务动态组合，其特征在于，所述系统包括：服务调用代理、服务转换器、业务规则库、规则引擎和规则管理界面，其中，

所述服务调用代理，用于拦截Web服务的调用，将调用的SOAP消息交由服务转换器处理，并将根据服务转换器的计算结果，将处理好的SOAP消息发给指定的接收者；

所述服务转换器，用于将Web服务的调用信息转换成事实，输入到规则引擎的事实库中，再从规则引擎中取出推理结果的服务替换处理策略，服务转换器根据替换策略从服务信息中心中获取服务映射关系，进行SOAP消息和服务的转换，最后将替换的结果交还给服务调用代理；

所述业务规则库，用于存储了服务转换的业务规则和规则运行需要的上下文数据，业务规则由前件和结论组成，前件是事实出发的条件，结论通常是增加新的事实或修改已有的事实，这些规则决定最终服务的调用；

所述规则引擎，用于规则的推理，当服务转换器向规则引擎的事实库中添加事实时可能会触发一定的规则，最终获得若干表示执行命令的事实，规则引擎提供了Java程序的接口，以便和服务转换器交换数据，在推理的过程中默认采用后向推理，并通过Rete算法优化提高规则和事实匹配的效率；

所述规则管理界面，用于规则管理人员可以动态实时地改变规则，从而影响服务调用代理的行为，从而影响服务的组合。

Images