CN101593135A - 在分布式集成环境中集中处理业务流程故障的装置和方法 - Google Patents

Abstract

本发明公开了一种在分布式集成环境中集中处理业务流程故障的装置和方法。该装置包括：故障识别器，被配置成以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障；以及故障处理器，被配置成重试由故障识别器识别出的故障所对应的服务调用。根据本发明实施例的技术方案简化了分布式集成环境如基于服务组件架构(SCA)的集成环境中的业务流程故障处理。由于故障识别和处理对于服务调用者和服务被调用者是透明的，因此可以降低业务流程管理的成本并且提高业务流程的服务质量。

Description

在分布式集成环境中集中处理业务流程故障的装置和方法

技术领域

本发明涉及计算机信息处理领域，特别涉及在分布式集成环境中集中处理业务流程故障的装置和方法。

背景技术

基于互联网的分布式运算环境是一个异构的环境，从硬件到软件，从操作系统到实现语言，都有可能不同。正是由于现实世界的这种异构特性，面向服务的分析和设计思想近年来得到了迅速的发展和普及。服务在本质上是松耦合、无状态、异构且灵活的。作为一项服务整合技术，服务组件架构(SCA)已被提出，其提供了统一的调用方式，可以把不同类型的服务，比如普通旧式Java对象(POJO)、企业级Java Bean(EJB)、业务流程执行语言(BPEL)、Java消息服务(JMS)、Web服务等都通过统一的方式调用。SCA还提供了一个基于组件的构建模型，可以使其他不同种类的服务使用统一的方式来构建。这样，SCA提供了统一的编程模型来以服务构建业务应用和解决方案。

当利用SCA以服务装配业务流程时，业务流程中的各个服务调用可能遇到故障。这些故障分为两种类型，即系统级别的故障和业务级别的故障。系统级别的故障是诸如服务不可用、网络中断等的不可预料的错误，其发生于服务调用层以及服务组件的内部。而业务级别的故障涉及业务逻辑如找不到账户，其发生于服务组件的内部。由于SCA提供与诸如Web服务、JMS、无状态会话Bean、表述性状态转移(REST)、Java脚本对象表示-远程过程调用(JSON-RPC)等各种转换技术的协议绑定，并且服务组件可以采用诸如Java、C++、Python、Ruby等各种技术实现，因此在每一个服务调用端以及服务实现的内部识别并处理所有这些故障将是艰难的，尤其在动态服务调用时更是如此。

在基于SCA的集成环境中，服务调用故障典型地是由服务调用的调用者来处理的。这样，服务调用故障的处理分散在业务流程的各个服务组件当中。由于每个服务组件都需要自带复杂的故障处理逻辑，因此集成服务的开发和管理成本将很高。

另外，在现有技术中提出了以业务流程为中心的故障处理来解决上述问题。在业务流程中，每个组件负责检测和报告故障。当发生故障时调用故障处理器，并且组件将故障报告给业务流程级别的故降处理对象。当故障处理对象接收到故障报告时，它将分析该报告并且以预定义的恢复行为来处理故障。然而，该机制需要每个组件具有统一的故障处理接口以及故障检测和报告机制，因此集成服务的开发和管理成本也较高。此外，由于这些限制，该方案难以满足动态、异构的集成环境中的故障处理需求。特别是在遗留系统中的组件被包装为服务来参与业务流程的情况下，这些服务不允许被重新构造以实现新的故障处理功能。

发明内容

在下文中给出了关于本发明的简要概述，以便提供关于本发明的某些方面的基本理解。但是，应当理解，这个概述并不是关于本发明的穷举性概述。它并不是意图用来确定本发明的关键性部分或重要部分，也不是意图用来限定本发明的范围。其目的仅仅是以简化的形式给出关于本发明的某些概念，以此作为稍后给出的更详细描述的前序。

鉴于现有技术的上述情形，本发明的目的是提供一种在分布式集成环境中集中处理业务流程故障的装置和方法，其通过内置的集中式故障处理和恢复机制来减少或消除服务组件中的故障处理工作。

为了实现上述目的，本发明的一个实施例提供了一种在分布式集成环境中集中处理业务流程故障的装置，包括：故障识别器，被配置成以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障；以及故障处理器，被配置成重试由故障识别器识别出的故障所对应的服务调用。

本发明的一个实施例提供了一种在分布式集成环境中集中处理业务流程故障的方法，包括：以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障；以及重试识别出的故障所对应的服务调用。

另外，本发明的实施例还提供用于实现上述在分布式集成环境中集中处理业务流程故障的方法的计算机程序产品。

此外，本发明的实施例还提供计算机可读介质，其上记录有用于实现上述在分布式集成环境中集中处理业务流程故障的方法的计算机程序代码。

根据本发明实施例的上述技术方案简化了分布式集成环境如基于SCA的集成环境中的业务流程故障处理。由于故障识别和处理对于服务调用者和服务被调用者是透明的，因此可以降低业务流程管理的成本并且提高业务流程的服务质量。

附图说明

参照下面结合附图对本发明实施例的说明，会更加容易地理解本发明的以上和其它目的、特点和优点。在附图中，相同的或对应的技术特征或部件将采用相同或对应的附图标记来表示。

图1示出了根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的装置的框图。

图2示出了根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的装置的具体实现示意图。

图3示出了根据本发明实施例的图2中所示的故障识别器的具体实现示意图。

图4示出了根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的方法的流程图。

图5示出了根据本发明实施例的在基于消息传递技术的集成环境中集中处理业务流程故障的具体实现示意图。

图6是示出其中实现本发明的计算机的示例性结构的框图。

具体实施方式

在下文中将结合附图对本发明的示范性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实施方式的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中必须做出很多特定于实施方式的决定，以便实现开发人员的具体目标。

在此，还需要说明的一点是，为了避免因不必要的细节而模糊了本发明，在附图中仅仅示出了与根据本发明的方案密切相关的装置结构和/或处理步骤，而省略了与本发明关系不大的其他细节。

下面以基于SCA的集成环境为例对根据本发明实施例的在分布式集成环境中集中处理业务流程故障的装置和方法进行说明。

图1示出了根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的装置的框图。如图1所示，该业务流程故障集中处理装置100可以包括故障识别器110、故障处理器120和故障管理器130。

故障识别器110可以以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障。故障处理器120可以重试由故障识别器110识别出的故障所对应的服务调用以恢复业务流程。当重试失败时，故障处理器120可以将故障持久化到故障数据库140中。故障管理器130可以通过提供故障管理接口来对持久化到故障数据库140中的故降进行集中管理，例如重新提交故障所对应的服务调用以恢复业务流程。

具体地，如图2所示，故障识别器110通过监听服务调用的连线(wire)来以透明于服务调用者和服务被调用者的方式识别服务调用中发生的故障。下面结合图3对故障识别器110的具体实现加以说明。

如图3所示，在SCA中，服务组件之间的服务调用的连线由与该连线所表示的服务契约的操作相关联的一个或多个调用链组成。每个调用链可以由一组调用器和拦截器组成。调用器可以根据服务组件的绑定协议和实现技术提供调用逻辑以完成相关的数据和/或协议转换。拦截器是为服务调用提供附加逻辑的特殊类型的调用器。故障识别器110可以将扩展监听器作为拦截器注册在业务流程的各个服务调用的调用链中，以捕获调用链中发生的故障，即传播到服务调用层的系统故障和业务故障。

故障处理器120可以重试由故障识别器110识别出的故障所对应的服务调用，即通过所注册的拦截器在恢复相应的服务调用上下文后将相应的服务调用消息重新发送到服务被调用者以重新进行服务调用。当重试失败时，故障处理器120可以将故障持久化到故障数据库140中，即将故障随同相应的服务调用上下文一起保存到故障数据库140中。

可选地，故障处理器120可以根据预定策略重试由故障识别器110识别出的故障所对应的服务调用，该预定策略是可配置的，并且规定最大重试次数和/或重试间隔。当重试次数已经达到最大重试次数而仍然失败时，故障处理器可以将故障持久化到故障数据库140中。

可选地，故障处理器120可以根据故障所对应的服务调用的调用类型和事务限定符来辨别故障是否是可恢复的，并且在辨别出故障是不可恢复的时候忽略该故障并作相应的日志记录，从而使故障回滚到服务调用者而不对该故障作后续处理。具体地，当故障所对应的服务调用是异步调用时，可以假定服务调用的调用组件和被调用组件处于不同的事务，因此该故障可以被认为是可恢复的。而当故障所对应的服务调用是同步调用时，可以通过服务调用的事务限定符来判定调用组件和被调用组件是否处于不同的事务，当服务调用的调用组件和被调用组件处于相同的事务时，则该故障被认为是不可恢复的，而当服务调用的调用组件和被调用组件处于不同的事务时，则该故障被认为是可恢复的。故障处理器120的这一处理可以在执行重试操作之前、或者在重试操作最终失败之后且在执行持久化操作之前执行。

故障管理器130可以通过提供故障管理接口来对持久化到故障数据库140中的故障进行集中管理，其中故障管理接口例如为一组故障管理应用编程接口(API)或者基于这组故障管理API开发的供终端用户使用的故障管理图形用户界面(GUI)。例如，故障管理器130可以用来执行至少以下故障管理操作中的一个或多个：查看故障及其所对应的服务调用的业务数据；根据故障的元信息如服务组件名称、故障发生时间等搜索故障；根据业务数据诸如订单ID搜索故障；重新提交服务调用或者修改业务数据并以修改后的业务数据重新提交服务调用，另外，在重新提交服务调用成功之后将故障从故障数据库140中丢弃；删除用户不再关心的故障；基于业务角色进行故障管理。

上面结合附图详细描述了根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的装置。下面将结合附图描述根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的方法。

图4示出了根据本发明实施例的在基于SCA的集成环境中集中处理业务流程故障的方法的总体流程图。如图4所示，该方法的处理流程从步骤S401开始。在步骤S403，以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障。在步骤S405，按照预定策略重试识别出的故障所对应的服务调用。在步骤S407，判断步骤S405中的重试操作是否成功。当重试操作成功时，该方法转到步骤413结束。相反，当重试操作失败时，在步骤409，将故障持久化到故障数据库中。在步骤411，通过提供故障管理接口来对持久化到故障数据库中的故障进行集中管理。然后，该方法在步骤413结束。

该方法的上述步骤的可选实施方式前面已经作过详细描述，在此不再重复说明。

从上可知，根据本发明实施例的技术方案简化了基于SCA的集成环境中的业务流程故障处理。由于故障识别和处理对于服务调用者和服务被调用者是透明的，因此可以降低业务流程管理的成本并且提高业务流程的服务质量。

虽然在前面的实施例中是以基于SCA的集成环境为例来说明的，但是本领域的技术人员应当清楚，本发明也可以适用于其它分布式集成环境，例如基于诸如JMS/MQ等消息传递技术的集成环境。如图5所示，在基于消息传递技术的集成环境中，故障识别器510可以被实现为对错误消息队列进行监听的消息监听器，从而以透明于服务调用者和服务被调用者的方式捕获服务调用中的故障而不中断正常的业务流程。故障处理器520可以通过向消息队列重新发送服务调用消息来重试故障所对应的服务调用。故障管理器530也可以通过向消息队列重新发送服务调用消息来重新提交故障所对应的服务调用。

另外，还应该指出的是，上述系列处理和装置也可以通过软件和固件实现。在通过软件或固件实现的情况下，从存储介质或网络向具有专用硬件结构的计算机，例如图6所示的通用计算机600安装构成该软件的程序，该计算机在安装有各种程序时，能够执行各种功能等等。

在图6中，中央处理单元(CPU)601根据只读存储器(ROM)602中存储的程序或从存储部分608加载到随机存取存储器(RAM)603的程序执行各种处理。在RAM 603中，也根据需要存储当CPU 601执行各种处理等等时所需的数据。

CPU 601、ROM 602和RAM 603经由总线604彼此连接。输入/输出接口605也连接到总线604。

下述部件连接到输入/输出接口605：输入部分606，包括键盘、鼠标等等；输出部分607，包括显示器，比如阴极射线管(CRT)、液晶显示器(LCD)等等，和扬声器等等；存储部分608，包括硬盘等等；和通信部分609，包括网络接口卡比如LAN卡、调制解调器等等。通信部分609经由网络比如因特网执行通信处理。

根据需要，驱动器610也连接到输入/输出接口605。可拆卸介质611比如磁盘、光盘、磁光盘、半导体存储器等等根据需要被安装在驱动器610上，使得从中读出的计算机程序根据需要被安装到存储部分608中。

在通过软件实现上述系列处理的情况下，从网络比如因特网或存储介质比如可拆卸介质611安装构成软件的程序。

本领域的技术人员应当理解，这种存储介质不局限于图7所示的其中存储有程序、与设备相分离地分发以向用户提供程序的可拆卸介质611。可拆卸介质611的例子包含磁盘(包含软盘(注册商标))、光盘(包含光盘只读存储器(CD-ROM)和数字通用盘(DVD))、磁光盘(包含迷你盘(MD)(注册商标))和半导体存储器。或者，存储介质可以是ROM 602、存储部分608中包含的硬盘等等，其中存有程序，并且与包含它们的设备一起被分发给用户。

还需要指出的是，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

虽然已经详细说明了本发明及其优点，但是应当理解在不退出由所附的权利要求所限定的本发明的精神和范围的情况下可以进行各种改变、替代和变换。而且，本申请的范围不仅限于说明书所描述的过程、设备、制造、物质的结构、手段、方法和步骤的具体实施例。本领域内的普通技术人员从本发明的公开内容将容易理解，根据本发明可以使用执行与在此所述的相应实施例基本相同的功能或者获得与其基本相同的结果的、现有和将来要被开发的过程、设备、制造、物质的结构、手段、方法或者步骤。因此，所附的权利要求旨在它们的范围内包括这样的过程、设备、制造、物质的结构、手段、方法或者步骤。

Claims (14)

1.一种在分布式集成环境中集中处理业务流程故障的装置，包括：

故障识别器，被配置成以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障；以及

故障处理器，被配置成重试由故障识别器识别出的故障所对应的服务调用。

2.如权利要求1所述的装置，其中故障识别器进一步被配置成将扩展监听器作为拦截器注册在业务流程的各个服务调用的服务调用链中，以捕获在服务调用中发生的故障。

3.如权利要求1所述的装置，其中故障处理器进一步被配置成按照预定策略重试由故障识别器识别出的故障所对应的服务调用，该预定策略是可配置的，并且规定最大重试次数和重试间隔中的至少一个。

4.如权利要求1所述的装置，其中故障处理器还被配置成在重试失败后将故障持久化到故障数据库中。

5.如权利要求1所述的装置，其中故障处理器还被配置成根据故障所对应的服务调用的调用类型和事务限定符来辨别故障是否是可恢复的，并且在辨别出故障是不可恢复的时候忽略该故障。

6.如权利要求4所述的装置，还包括：

故障管理器，被配置成通过提供故障管理接口来对持久化到故障数据库中的故障进行集中管理。

7.如权利要求6所述的装置，其中故障管理器进一步被配置成执行至少以下故障管理操作中的一项或多项：查看故障及其所对应的服务调用的业务数据；根据故障的元信息搜索故障；根据业务数据搜索故障；重新提交服务调用或者修改业务数据并以修改后的业务数据重新提交服务调用；删除故障；以及基于业务角色进行故障管理。

8.一种在分布式集成环境中集中处理业务流程故障的方法，包括：

以透明于服务调用者和服务被调用者的方式识别业务流程的各个服务调用中发生的故障；以及

重试识别出的故障所对应的服务调用。

9.如权利要求8所述的方法，其中识别业务流程的各个服务调用中发生的故障包括：通过将扩展监听器作为拦截器注册在业务流程的各个服务调用的服务调用链中，捕获在服务调用中发生的故障。

10.如权利要求8所述的方法，其中重试识别出的故障所对应的服务调用包括按照预定策略重试识别出的故障所对应的服务调用，该预定策略是可配置的，并且规定最大重试次数和重试间隔中的至少一个。

11.如权利要求8所述的方法，还包括：在重试失败后将故障持久化到故障数据库中。

12.如权利要求8所述的方法，还包括：根据故障所对应的服务调用的调用类型和事务限定符来辨别故障是否是可恢复的，并且在辨别出故障是不可恢复的时候忽略该故障。

13.如权利要求11所述的方法，还包括：

通过提供故障管理接口来对持久化到故障数据库中的故障进行集中管理。

14.如权利要求13所述的方法，其中对持久化到故障数据库中的故障进行集中管理包括执行至少以下故障管理操作中的一项或多项：查看故障及其所对应的服务调用的业务数据；根据故障的元信息搜索故障；根据业务数据搜索故障；重新提交服务调用或者修改业务数据并以修改后的业务数据重新提交服务调用；删除故障；以及基于业务角色进行故障管理。

Images