CN1244268A

CN1244268A - 故障保险的事件驱动事务处理系统和方法

Info

Publication number: CN1244268A
Application number: CN97181124A
Authority: CN
Inventors: K·A·卡恩斯; T·R·杰哈尼安; R·E·杰弗里
Original assignee: Electronic Data Systems LLC
Current assignee: Hewlett Packard Development Co LP
Priority date: 1996-10-29
Filing date: 1997-10-29
Publication date: 2000-02-09
Anticipated expiration: 2017-10-29
Also published as: CA2270112A1; DE69733266T8; HK1024760A1; DE69733266D1; DE69733266T2; CA2270112C; CN1187700C; WO1998019262A1; AU5195998A; EP0935786A1; EP0935786B1; ATE295574T1; US5805798A; AU718006B2

Abstract

本发明的系统和方法为电子商业应用提供故障保险的事件驱动事务处理。系统包括至少一个有多个用于与诸如ATM和金融机构的外部设备通信的实体和进程的系统节点。在系统节点之间提供多个链路以便在节点发生故障时提供灵活的路由选择。一个可被进程访问的配置数据库为每个实体和进程提供备用实体或进程。各系统节点上驻存一个系统监控器,监控并向其它节点传送各节点的状态。

Description

故障保险的事件驱动事务处理系统和方法

本发明总体涉及计算机系统领域。更具体来说，本发明涉及故障保险的事件驱动事务处理系统和方法。

本专利申请涉及的共同未决美国专利申请的系列号为_，名称为“分布式联机数据通信系统和方法”，申请日为1996年_月_日。

图1是采用了允许许多应用程序12与远程设置的外部设备通信的常规中央通信系统11的常规电子资金与数据传输(EFIT)系统10的简化框图。例如，电子资金与数据传输(EFIT)系统的外部设备13可以包括一个或多个自动柜员机(ATM)14和金融机构15，它们通过中央通信系统11连接到路由器应用程序16、设备处理器程序17和资金转移授权程序(AUTH)18。中央通信系统11也可以连接到用于登录每项事务的日志程序和数据库19和用于与金融机构15交互的主接口过程20。

操作中，例如当在ATM 14上生成一个表示现金支取的事务消息时，事务消息传给中央通信系统11，后者将事务消息发往设备处理器17。设备处理器17于是从事务消息中提取数据，构造一个有能被应用程序12和中央通信系统11理解的预定内部格式的消息。这个重新格式化的消息然后被发回中央通信系统11，后者然后将消息转发到路由器16。路由器16确定消息的目的地后将消息发回中央通信系统11用于递送到目的地。目的地可以是授权程序18，它可以访问数据库21来确定事务是否是授权的。包含在返回消息中的授权然后被发往中央通信系统11用于递送到日志程序19去记录事务，然后再经过中央通信系统11，返回到设备处理器17。设备处理器17然后将授权消息转换成外部格式并经过中央通信系统11，将其传递到事务是由其起始的ATM。ATM 14然后按照授权消息中所含信息发放所请求资金或者拒绝该事务。

如果要求某事务要获得金融机构15的授权，则授权程序18就将事务消息经中央通信系统11发往接口程序20。接口程序20然后将消息重新格式化成金融机构15处的授权系统所能理解的格式，并将重新格式化的消息发往中央通信系统11，用于投递到目的地金融机构去授权。金融机构然后生成授权消息并将其发往中央通信系统11，后者将其传递到接口程序20以转换回能被应用程序12和中央通信系统11理解的格式。重新格式化的授权消息然后经由中央通信系统11被发往设备处理器17，后者如上所述地将消息转换成外部格式以将授权消息提供给从中产生事务的ATM。

以上可见，在应用程序12与外部设备13之间通讯的所有消息都必须经过中央通信系统11，后者就是中央控制器。随着电子资金与数据传输系统越来越大，以容纳越来越多的ATM和金融机构，中央通信系统11变成了一个延缓消息传递和事务处理响应时间的瓶颈。这是一个关键的问题，因为这一类的事务通常要求几乎是瞬时的响应时间一银行客户不愿意用30秒以上的时间来等待ATM对他们的取款请求作出响应。此外，由于所有通信都必须经过中央通信系统11这一个点，如果系统11发生故障，就会给整个电子资金与数据传输系统带来灾难，系统中的所有ATM都要瘫痪。

中央通信系统11的另一个缺点是，要求它能识别消息格式，以便为了路由选择而确定消息的目的地。所以消息格式不能轻易改变，不然就会影响系统11的主要功能。

系统的中央化结构也意味着，其增长受到系统11的容量的限制。系统不可能为了容纳更大数量级的用户而轻易扩展，除非花钱增加计算平台或其它硬件部件。在计算机行业，可扩展的特性被称为“可扩展性”。此外，诸如系统11的中央系统也不能移植到其它计算平台，这样，其部署就局限于单一的平台。

因此，需要一种克服与在上述中央通信系统上建立的系统相关联的缺点的事件驱动的事务处理系统。

在本发明的一个方面中，一种故障保险的事件驱动事务处理系统有至少一个具有多个用于处理由多个外部设备启动的事务的应用进程的系统节点。该系统是在一种向多个应用进程提供多个消息传递实体和服务以进行路由选择、彼此之间传送和接收消息的数据通信系统的基础上建立的。进一步包括一个系统配置数据库，用于存储各实体和进程以及它们各自的备用实体。驻存在各系统节点上的系统监控器监控并向其它系统节点传送该系统节点的运行状态。

在本发明的另一个方面中，一种用于事件驱动事务处理系统的方法在系统配置数据库中记录系统中每个节点的逻辑标识符、物理地址和状态。此外，可选地为系统配置数据库中的每个实体指定一个备用节点。每个备用节点轮询系统中所有其它节点的状态以及它们对系统中所有其它节点的状态的理解。如果轮询进程检测到故障节点(downed node)，则将故障节点的处理负荷路由选择到备用节点。

在本发明的另一个方面中，一种事务处理系统包括有至少一个具有多个用于与多个外部设备通信的进程的系统节点。一个可被进程访问的配置数据库存储各进程和外部设备的逻辑名以及它们相应的物理地址。一个系统库进一步向进程提供多个用于彼此之间发送、接收消息的例程。至少一个应用进程用该进程和系统库来与外部设备通信以处理事务。

要更好地理解本发明，可参考以下各附图：

图1是采用中央通信系统的常规电子联机通信系统的简化框图；

图2的简化框图表示按照本发明教导构造的分布式联机数据通信系统；

图3是到控制点、操作系统和应用程序的典型系统监控器外部接口的框图；

图4是系统配置文件中示例的记录结构图；

图5是示例的通信配置的图；

图6是在示例的电子资金与数据传输应用中采用的分布式联机数据通信系统的简化图；

图7是表示按照本发明教导的线路处理器的结构和进程流的图；

图8是本发明的分布式联机数据通信系统的示例多层体系结构的图；

图9是按照本发明教导的示例系统消息格式的图；

图10A和10B是在控制点与其它进程之间使用的示例的消息结构图；

图11是在线路处理器与应用程序之间使用的示例的消息结构图；

图12是表示按照本发明教导的数据库同步进程的框图；

图13是表示检测并处理一般节点故障的示例进程的框图；

图14是表示备份处理和恢复主节点的示例进程的框图。

图2～14中具体说明了本发明的优选实施例，图中相同的编号用于标引不同图中相同或对应的部分。

参见图2，该图表示一个分布式联机数据通信系统22的简化框图。分布式联机数据通信系统22可以支持实现各种事件驱动的应用的应用进程，事件驱动的应用包括电子资金与数据传输(EFIT)、销售点(POS)、电子保健和保险赔付费事务或任何基于消息的事务处理应用。系统22包括许多进程，包括系统监控器及其备份24、控制点26、命令装置28、线路处理器30、事件记录器32和诊断跟踪器34。系统22进一步包括系统库35，它含有一组由所有系统进程和所有应用进程36使用的例程。

系统库例程35提供用于执行基本功能的接口过程，最好与系统和应用进程一起联编或编译。图2把这种在系统库例程35与系统监控器24、控制点26、线路处理器30、事件记录器32、跟踪器34和应用进程36之间的连接表示成开放式的流水线，以示其与上述的中央通信系统11中的I/O的区别。系统库功能包括发送、接收、路由选择、排队、登录和跟踪消息。系统库35使应用进程36能在彼此之间和与外部世界通信。系统库35最好在存储器中保留一个专用数据结构，存储为应用进程进行路由选择和接收服务所必需的数据。每个应用进程都有自己的一份库数据。因此，每个应用进程也都有自己对与其通信的进程的视图。数据库是动态的，依赖于到应用创建和放弃的其它进程的连接。库数据可以包括环境变量、用于读入消息的缓冲器以及列举所有能发送和/或接收消息的开放进程的表。此外还有含有要发往各目的地的消息的队列。

系统22对于事件驱动的应用程序特别有价值。消息到达、超时、消息故障、I/O完成都是事件的例子。为了识别事件，应用程序要调用系统库过程RECEIVE(接收)。系统库35要执行环境和操作系统特定的任务来确定事件是什么，然后将一个表示事件类型的值以及与事件关联的数据赋给应用程序。下面的算法表示采用这种方法的应用程序的示例主循环：

    While not time to stop

        Call RECEIVE
         Switch on EVENT-TYPE

            if MESSAGE，进程消息

            if COMPLETION，进程完成

            if FAILURE，进程失败

            if TIMEOUT，进程定时器
				
				<dp n="d4"/>
            否则，进程未知事件

        end switch

    end while

环境特定的任务可能包括分离消息或检查队列中更多要发送的消息。操作系统特定的任务可能包括与操作系统连接以从另一个程序接收消息，或者解释操作系统错误。这些任务的执行对于应用36是透明的。

系统监控器24是一个不间断地运行的进程，为的是监控所有系统进程并重新启动任何出故障的进程，包括控制点26。系统监控器24可以轮询其监控的进程以获取状态数据并从中接收确认信号。如图3中所示，系统监控器24通过系统库调用48来访问系统配置数据库37以获取进程配置数据。为不间断地运行系统监控器24，配备一个与系统监控器24并行运行的备份进程24’。系统监控器24也用操作系统调用49来创建应用进程的新实例、停止一个应用的一个实例以及接收来自应用实例的故障通知。系统监控器24最好检验点关键信息和事务到其备份进程24’。如果主系统监控器24出故障，备份进程就接替并从上一个检验点继续。操作员可以用命令装置24通过控制点26来控制系统监控器24。系统监控器24可配置成只监控位于其自己节点38的进程，也可配置成监控位于一个或多个其它选定节点40的进程，或者可配置成监控在系统中所有节点运行的进程，具体配置视应用而定。

如图2中所示，系统配置数据库37含有关于系统22中所有进程的数据，它们可能包括逻辑名称、物理地址、备份进程标识以及其它特性。系统配置数据库37的内容可以被来自命令装置28的命令修改。系统配置数据库37可以被远程访问，在其它站点复制或分布于多个站点，具体要视应用的需要而定。

系统配置数据库37含有若干记录，每个记录含有关于系统22中一个实体的信息。如图4中所示，记录中关于实体的信息可以包括实体类型23、逻辑名称25、物理名称27以及该实体类型的独有特性29。实体类型23是记录或实体的类型；逻辑名称25是应用程序访问该实体时所用的名称，物理名称27是实体的系统名称和位置，特性29是在记录中所定义的特定于该实体类型的信息。最好是，特性21可以提供关于作为各实体的备份的实体的数据。

系统22中有若干不同的实体类型，包括一但不限于：SYSTEM(系统)、PROCESS(进程)、LOGICAL UNIT(逻辑单元)、PHYSICAL UNIT(物理单元)、LINE(线路)、USER(用户)、TERM(终端)、FILE(文件)、ROUTE(路由)、NETWORK(网络)、COMMAND(命令)、NODE(节点)、GROUP(组)、PARAMETER(参数)和ASSIGN(分配)。以下将对各实体类型作详细说明。

SYSTEM实体含有与系统中某站点或节点相关的数据。因此，系统配置数据库37可以包括若干SYSTEM实体记录，记录中含有与系统中能互相通信的所有节点有关的通信路径和其它数据。

PROCESS实体含有向分布式联机数据通信系统定义一个进程的数据。在平台上运行的应用程序是用其逻辑名称引用的。物理名称包括运行进程标识符。特性段定义对象的位置以及进程使用的资源，并提供使运行进程得以创建的数据。

LOGICAL UNIT(LU)实体是通信电路的最初级形式。它描述外向地连接到某特定设备的引线端。当进程用逻辑名称来引用LU时，消息就被路由选择到其线路处理器30。LU有穿越可选的PHYSICAL UNIT(PU)实体的链接，链接中止于LINE(L)实体，如图5中所示。线路处理器30(图2)用LU、PU、LINE的分层结构的数据来得出目的地设备的地址。设备的物理位置是由链接在一起的LU、PU和LINE实体的物理名称描述的。因此，LU的特性就包括线路处理器名称和链接。LU实体的其它特性定义LU的协议和协议选项。LU可用于定义一个通信路径，通向诸如结构45和ATM 44的外部源，或者通向分布式联机数据通信系统的节点40(图2)。

PHYSICAL UNIT实体(PU)是一个使网络设计者能建立一批一个或多个LU的实体。它是LINE实体的逻辑组成部分。通信的配置常常自然地采取图5中所示的分层体系。PU实体是一种指示这种分层体系的装置，这种分层体系充分利用了通信中的可用带宽。要访问(诸如某LU的连接链上的)PU，就要指定它的逻辑名称。物理名称含有访问LU的路由选择数据(部分地址)。特性包括协议和通向其它实体的连接，其它实体可能是更多PU，但连接必须在某LINE实体处中止。

LINE实体定义一个在由其可以通过通信电路而访问到一个或多个设备的物理设备上的端口。LINE的逻辑名称是用通过连接域与其连接的各LU和PU来规定的。物理名称描述了机器的或通信设备的端口名。特性包括线路处理器程序、协议和协议选项。

当线路处理器30为LU接收消息时，它已经将实体数据链接在一起。采用一般的路由选择算法来访问在LINE记录中描述的端口，使用由PU记录(如果出现的话)描述的线路的部分和LU记录上的地址来将消息传输到位于电路末端的设备。

USER实体描述分布式联机数据通信系统22的一个有效用户。其功能主要是作为安全措施或者用于对系统的有保护访问。对于安全区中的终端来说，可以设置USER实体，使得任何用户都是有效的。这些终端在系统配置数据库37中被定义为TERM实体。

FILE实体定义一个文件到系统22和其应用程序。它也有逻辑名称和物理位置。用逻辑名称来访问文件使分布式系统的机器和位置具有透明性。应用程序通过指定逻辑名称来访问文件，系统库35(图2)然后确定物理名称及其特性并向应用程序提供访问服务和数据。

ROUTE实体是由系统22提供、供应用库(下文将结合图6说明)或应用程序36使用的一般实体。在这个记录类型中，规定了一个逻辑名称，并规定了一个相关的“处理器”。处理器是一个进程实体。处理器进程是一个为识别来自ROUTE源的消息并对消息作相应处理而编制的应用程序。当某应用程序指示某ROUTE实体为目的地时，系统库35就自动地把它传递到该处理器进程。当某应用程序具有一个对系统中所有进程是全局的有名命令时，这个特征就有用。全局目的地的实现(通过使用ROUTE实体)保持了系统平台的通用性，使得系统22不必知道应用程序的具体细节，使应用程序具有灵活性。

NETWORK实体是一种描述为系统提供通信的物理网络的方便工具。它不影响路由选择但描述了组成分布式系统的硬件。

COMMAND实体允许操作员为应用特定的命令而定制用户接口。COMMAND实体由逻辑名称和物理名称(它是命令的文字)以及命令的目的地组成。这种命令的一个例子是，当某应用程序必须取得用于保密的新的键字时，系统配置文件37中就定义一个称为KEYS的COMMAND实体，由操作员用于通知该应用进程去取得新KEYS。

NODE实体定义系统22中的计算节点。计算节点是一组一个或多个紧密接合的物理处理器。节点的配置是独立于硬件的，这样它就可以是一组CPU或是一个工作站。因此，应用程序就能不知道节点的具体情况而访问节点的逻辑名称。节点的特性包括一个表示该节点的正常(up)或故障(down)的标志。NODE实体被规定为是SYSTEM实体中的时间同步节点。这样，系统22中的所有事务，即使是分布在多个节点上，也能被同步到同一个时钟。通过用一个时间同步节点和用一个系统库过程来配置SYSTEM记录而提供的时钟同步被称为SYSTEM TIME(系统时间)

GROUP实体便于对系统配置数据库37中的实体进行逻辑分组。它为监控和操作大型分布式系统提供了必要的方便。当为某个操作指定一个组名时，该组中的所有实体都被操作。

PARAM实体允许将应用程序所在环境中的变量定义为程序的外部变量，这样就能对变量进行修改。PARAM由逻辑名称和一个值组成。当应用程序需要环境变量时，就从系统库35调用一个过程，过程返回参数的值。具有逻辑名称SECURITY和值ON的PARAM就是一个例子。

ASSIGN实体也用于描述应用程序的环境。它定义程序的外部文件，使得文件能被改变。ASSIGN由逻辑名称和文件名或FILE实体组成。当应用程序需要对文件作处理时，就从系统库35调用一个过程，过程返回文件名或FILE实体。

图2中也显示了命令装置18一个到操作者的接口和控制点26，后者是系统22各站点或节点的控制器和管理器。命令装置28可以与数据输入与显示设备42-诸如终端、计算机或工作站一保持联系，并可通过电信线路或计算机网络连接到控制点26。命令装置28可向操作者提供图形和/或文字用户界面，用于接收命令和显示系统状态。

控制点26的主要功能是处理来自命令装置28的配置、监控和控制本地节点中各实体的请求。它是系统配置数据库的唯一维护者。控制点26与本地节点的所有进程通信并且是命令的中心发送者和要返回给命令装置28显示的信息的收集者。控制点26与所有进程的通讯，是通过如图10A和10B所示的灵活、可扩展的面向令牌的消息标准(下文将有详细说明)进行的，因此得以与多个平台上的命令装置接口。命令装置28负责以适合所选择的平台以图形和/或文字显示格式的方式，格式化和提供由控制点26转发的数据。命令装置28和控制点26进一步协作，按系统配置数据库37含有的USER实体记录所定义的那样提供防止对系统的非授权访问的保护。

线路处理器30是一些负责与外部设备进行数据通信的进程，这些设备诸如有自动柜员机(ATM)44、银行机构45、以及分布式联机数据通信系统22的其它节点40，但不限于这些。本发明中所定义的ATM 44是具有数据输入设备和屏幕显示器的专用终端，它接收并处理金融客户的事务请求，诸如现金支取、存款、余额查询等等。线路处理器30可以按专门的通讯协议-诸如Bisync、X.25、TCP/IP、SNA和其它协议-进行操作。此外，线路处理器30还可以包括对外部系统的桥接进程(bridge processes)。可以有多个线路处理器进程30并发地执行，以提供对大量外部设备的通信。

事件记录器32是一个接收以日志文件46为目的地的消息并且可以执行某些过滤功能的记录进程。通过在命令装置28或操作系统级上输入适当的命令就能检索出记录的消息。配备一个系统库进程来格式化记录的消息。

跟踪器34是一个收集在系统中的选定进程之间通讯的消息并将其存入跟踪文件47的进程。操作者能通过命令装置28或在操作系统级启动跟踪并选择该进程、消息类型和其它跟踪参数。配备一个系统库进程来格式化跟踪文件。此外，通过在命令装置28输入命令就能从文件47检索出所存储的消息。

参见图6，该简化框图表示一个示范的故障保险事件驱动的事务处理系统的过程流。图6专门表示了建立在按本发明方法构造的分布式联机数据通信系统50上的一个示范的电子资金与数据传输(EFIT)应用的过程流。分布式联机数据通信系统50可包括彼此远离的多个节点，跨越国家、大洲和/或全球的节点。例如在一个两节点的系统中，节点A可能位于(美国)伊利诺伊州的芝加哥，节点B可能位于(美国)德克萨斯州的Plano。在EFIT系统中节点A和节点B可能代表区域性处理中心。

当应用到EFIT时，例如可以由诸如由金融客户操作的ATM 52的事务求取者来启动一个事务-例如该ATM直接连接到分布式联机数据通信系统50的节点A。客户例如可通过插入金融机构发行的、含有独有卡号和有关该客户帐户的关联数据的卡来启动事务。客户进一步输入所需事务的类型，诸如存款、提款或查询余额，需要的话，还要输入美元数额。然后，客户的所需事务、卡号以及ATM的线路和设备名称/编号被打包成具有第一预定格式的事务消息后发送到线路处理器(LH)54。

与线路处理器相连的是一组系统库(SL)过程60。系统50可被看作具有如图8中所示的多层结构70。最底层的通信层72代表由线路处理器54用于与外部设备通信的数据通信设备、线路和协议。通信层72上部的系统库层74，对应于由该组系统库过程60执行的功能及其使用的数据库。系统库层74提供独立于通信层72中硬件及通讯协议的消息传递服务。系统库层74上方的应用库层76，含有其它特定于该应用的消息传递服务和数据库。最顶层的应用层78，包括执行诸如EFIT的特定功能的应用程序。可以看出，系统库层74不依赖应用层76和78，而是紧密接合到通信层72的硬件和通讯协议，以提供可移植和独立于硬件的接口。参见图6，图中的系统库层74被表示成与包括应用库层76中的进程以及应用层78中的进程在内的所有进程捆绑在一起的系统库(SL)过程60。系统库过程60可以是与各个进程的代码一起编译的代码。可替代方案是，可以将系统库过程60放在能被所有进程调用的运行库中。

在图6中，线路处理器54在用户启动事务时从ATM接收事务消息。参见图7，该图7表示了线路处理器进程54的其它细节。图7中的箭头表示线路处理器进程54的共用码(内核)31和常规码(custom code)33中的进程流。首先接收一个要处理某LU-诸如开始、停止或传输-的请求。线路处理器处理LU共用码31的方法是，首先在状态表中找到该LU，然后调用常规码33，在处理的适当时刻去执行与协议相关的功能。状态表提供关于各LU和实体的上/下/挂起状态信息，是由共用码31保持的全局信息集合的一部分。线路处理器的常规码33然后(必要时)修改基于协议的消息处理，并将控制返回给共用码31。线路处理器共用码31然后在计算出的地址上执行通向诸如ATM的设备的I/O。可代替的方案是，通向设备的I/O可以由常规码33来执行。事务由其起源的特定ATM在图2所示系统配置37中对于预定的所有事务消息都有预定的目的地或设备处理器(DH)80。设备处理器80接收该消息，并将该消息重新格式化成系统50内部的第二预定格式，并示于图9中。

图9提供了在分布式联机数据通信系统50中传输的消息的示范格式90。消息格式90包括码组首部(block header)92，它可以包括关于随后的数据码组的信息，诸如码组中的消息数、距离码组中第一个消息的相对位移量、以及码组中消息的字节总数。码组首部92也可以包括一个标识符，它标识作为具有系统50可识别的格式的消息的数据。码组首部92之后是系统首部(system header)94，它可以含有多个域。系统首部94可以包括的信息诸如有指示消息类型的标识符、源实体名和目的地实体名。系统50中的所有进程和数据库，每个都被分配一个独有的逻辑标识符或名称。逻辑标识符由系统库60分配和使用，用于寻址所有消息，标识消息的源和目的地。系统首部94进一步包括扩充长度(extension size)、应用首部长度和应用数据长度。扩充长度提供必要时用可选择的扩充域96来扩充系统首部长度的灵活性。应用首部长度指示应用首部域98的长度，该域能被应用库和应用层76和78(图8)以任何方式使用，可以是任选的。消息格式90也包括一个可选的可变长度的应用数据域。图9中各消息域后附的星号(*)表示这些域是否是可选择的。可以看到，该示范的消息格式是通用的，它允许不同类型的应用程序来采用该系统。

图10A提供一例采用图9所示格式、用于控制点应用数据的消息。该消息可以有码组首部92、系统首部94、可选择的扩充96、可选择的应用首部98和可选择的应用数据100等域。此外，控制点应用数据可以包括许多标志标识符(TKN ID)、它们各自的长度(LEN)和关联数据。消息以结尾标志(END TKN)和长度0终止，以表示消息的结束。实际运用中，如图10B所示，要开始一个新进程，该消息可包括带有长度的命令标志(CMD TKN)，其关联数据是开始进程命令(STRT CMD)。下一个标志标识符是实体标志(ENTITY TKN)、其长度以及与正在开始的实体或进程有关的系统配置数据库记录数据。命令标志、开始命令和实体标志可以是整数值、字母数字串或任何其它合适的表示。注意在图10B中，省去了可选择的域92～98。

参见图11，该图表示的是用于线路处理器与应用程序进程之间通信的示范消息结构。在线路处理器应用首部部分，采用许多域来提供关于消息的数据。例如，线路处理器应用首部可以包括有关消息类型域来指示消息中所包含的应用数据是不是与命令有关的数据或信息。也可以提供一个或多个时间标记(timestamps)用于统计分析和定时目的。线路处理器应用首部中还可以含有一个错误码，用来指示已经发生的错误的性质。此外，还可以包括一个用于标识消息的目的地的内部标识符。

继续图6所示的进程流，设备处理器80调用一个称为SYSTEM SEND(系统发送)的系统库过程来将从线路处理器54所收的事务消息传递到另一个进程即路由器(RTR)110。路由器110能访问ATM数据库112，后者所含数据涉及求取者网络、ATM卡号以及银行卡各自的金融机构所有人、各个银行卡有权访问的ATM网络。相应地，路由器110查阅消息中所含的卡号，确定用户可以访问该特定ATM网络，并进一步获得可授权该事务的进程的逻辑标识符AUTHO1。获得授权进程(AUTH)116的标识符后，路由器110调用APP SEND并在消息中规定授权进程目的地(AUTH_DEST)是AUTHO1。APP SEND可以是提供一组应用库过程114的应用库层76(图8)的一部分。应用库114然后接收消息并调用以AUTHO1为目的地的SYSTEM SEND。SYSTEM SEND识别AUTHO1为本地授权进程程序116，并将消息传递给授权进程116。消息可能要排队，直到授权进程116从队列中将它取出并接收它。队列驻留在发送者进程的系统库专用存储器中。

授权进程116然后检查消息，并访问数据库或卡定义文件118，查找为确定所请求事务是否经过授权所需要的信息。授权进程116然后生成授权消息并调用APP END去传递该消息。授权进程116可以在消息中为消息指定一个或多个目的地，诸如RETURE_AND_JOURNAL_DEST-它规定该消息要被返回到发起者并由适当的日志进程(journal process)记录。在消息格式(图5)中的预定域中，可以规定其它的目的地逻辑实体名。因此，授权进程116可以在消息中规定日志(JRNL)120为第一个目的地、消息的发起者为第二个或下一个目的地。应用库(AL)114在检查消息时判定第一个目的地(JOURNAL_DEST)是日志120并将消息写在其上。日志120然后在数据库122中的指定文件中记录该事务，并用在消息中规定为下一个目的地(NEXT_DEST)的对象来调用APP SEND。应用库114判断下一个目的地是事务消息的发起者或为返回目的地(设备处理器80)。应用库然后就调用SYSTEM SEND将消息传递给设备处理器80。设备处理器80将消息发往线路处理器54，线路处理器然后将消息传递到ATM 52。ATM然后对所接收消息采取行动，要么执行所请求的事务，要么拒绝所请求的事务。

在上述情形中，所请求的事务是在同一个节点即节点A本地授权的。然而，在节点A请求的事务也可以通过将该事务消息传送给远程节点B而在节点B获得授权。例如，当路由器110从设备处理器80接收消息并在其数据库112中查阅卡号时，路由器110从数据库112取得能对该事务授权的进程的逻辑标识符，例如NODEB.AUTHO1。路由器110然后调用APP SEND去传递消息。应用库114然后从消息中取出NODEB.AUTHO1并用该参数调用SYSTEM SEND。系统库60注意到这是外部系统名，就通过调用系统库子例程来在为效率和性能而保持在存储器的系统配置数据库名130中查阅该系统名，取得连接节点B和其线路处理器132的通信端口的逻辑地址。配置数据库130最好存储所有系统进程和硬件的逻辑名和相应的物理地址。以此方式来操作，进程就只需知道它们与之交互作用的其它进程的逻辑名，而跟踪相应的物理位置或地址并保证消息的准确传递则是系统库的功能。

系统库60然后将实际或物理目的地地址附加到消息中的系统首部94(图9)作为下一个目的地(NEXT_DEST)，将消息排队到线路处理器132，后者将消息转送到节点B的线路处理器132’。可以看出，消息可以通过计算机网络、电信网络、无线网络、卫星通信等在线路处理器132和132’之间传送。

在节点B处，线路处理器132’得到消息，将其转发到消息中指定的下一个目的地(NEXT_DEST)-NODEB.AUTHO1或授权进程116’。授权进程116’授权该事务并调用APP SEND来返回所授权的消息并将事务记录在一个或多个日志数据库(RETURE_AND_JOURNAL_DEST)中。应用库114’判定日志目的地(JOURNAL_DEST)是个日志进程，并进一步注意到消息的起源者是节点A，所以它调用SYSTEM END将目的地规定为NODEA.JOURNAL。SYSTEM END然后排队，将消息写到位于节点A的日志120。系统库60’注意到NODEA是外部系统名，就查阅系统，确定连接节点A的通信端口的逻辑名。系统库60’然后将位于节点A的日志120的实际目的地址附到消息的系统首部94作为下一个目的地(NEXT_DEST)。系统库60’进一步查找线路处理器132’连接节点A的通信端口，将消息向其排队。线路处理器132读取消息并将消息转发到NODEA.JOURNAL 120，它被规定为下一个目的地。日志120然后接收消息并写入其数据库或事务日志文件122。日志120进一步调用APP SEND，规定下一个目的地(NEXT_DEST)。应用库114解析下一个目的地为返回目的地(RETURN_DEST)，它在消息中被规定为设备处理器80。SYSTEM SEND然后排队并将消息写到设备处理器80，后者将授权决定转给ATM 52。ATM然后根据该消息中的授权要么执行所请求的事务，要么拒绝该事务。

有许多与诸如EFIT的不同应用相关联的可能情形，分布式联机数据通信系统和方法50同样适用。例如，某宿主(未予示出)诸如银行机构可能被要求授权该事务。可能要用一个宿主接口与宿主连系。进一步，持卡者可以访问位于第一个节点的ATM卡网，而要求在位于第二个节点的宿主授权该事务，但宿主接口可以在第三个节点存在。因此，事务消息必须从第一个节点通过第三个节点中继到第二个节点。可以用类似的系统库和应用库进程来完成这个事务。

按照本发明思想的分布式联机数据通信系统和方法50，其结构是为了在一个或多个节点处发生系统故障时提供数据库复制。参见图6，该图表示了示范数据库复制或同步系统和进程200。再次用EFIT应用来解释系统200。当某个事件导致在选定数量的文件或数据库中发生变化时，这种变化就被转发到备用数据库去更新其记录。例如，当授权进程202授权某个改变在正余额文件(PBF)204中存储的帐户的帐户余额的事务时，该改变在消息中打包并发送到DB_SYNC进程306。当用户帐户文件(CAF)206记录被更新时，授权进程202也将放在消息中的更新的信息发送给DB_SYNC进程306。类似地，对帐户异常文件的改变也被文件服务器进程CAD SVR 302发送到DB_SYNC进程306。

更新数据消息的投递是通过调用系统库例程SYSTEM SEND来执行的。消息可以含有备用系统或节点的逻辑标识、记录类型和改变了的数据。DB_SYNC进程306然后将消息写到DB_SYNC存储文件308，并也用SYSTEM SEND将消息转发到指定的备用系统(节点A)上的DB_SYNC进程320。回想一下，系统库60可以访问系统配置数据库130来确定目的地系统的物理地址。可以启动一个定时器310来跟踪逝去的时间。DB_SYNC存储文件308为需要在备用节点复制的事务数据起着临时存储器的作用。可以看到，可以用如图3所示的类似的线路处理器进程来将消息投递给远程节点。

节点A处的DB_SYNC进程320接收消息，并将消息转发给由消息内的记录类型所指示的服务器，包括PBF SVR 322、AUTH 324或CAFSVR 326。适当的服务器然后将消息内的事务数据存储到各自的文件或数据库330-334。节点A处的DB_SYNC进程320在收到消息时或者在事务数据成功地存储到适当的文件中后，可以向节点B处的DB_SYNC进程306发送一个确认消息(acknowledge message)。DB_SYNC进程306接收这个确认消息后，就将相应的消息从DB_SYNC存储器308中删除。如果当定时器310已经超时，而DB_SYNC进程306还没有从备用系统接收到确认消息，DB_SYNC进程306就可以检索出在DB_SYNC存储文件308中存储的消息，将其再次传送给备用系统。再次传送的消息可以包括一个域来指示这是以前发送过的消息的第二次传送。

以这种构造方式，位于节点的每个系统都被分配以位于另一个节点的一个备用系统或多个备用系统，在数据库中存储的有关事务的数据是双份的。相应地，主系统与备用系统之间选定的文件或数据库被同步化，使得它们含有实际上相同的数据。可以确定，某些事务对于系统的操作来说是根本性的，例如发放现金，所以只将与这个事务关联的数据库和文件进行复制。例如，帐户异常文件208可以被复制，因为它记录了被遗失或偷窃了的、而又可能会非法使用的ATM卡；正余额文件204提供的是有足够余额供发放现金的帐户；用户帐户文件206含有用户帐户信息。可见数据库同步并不限于如图6中所示的这些数据库和文件。

参见图7，该简化框图表示了用于检测和处理一般节点故障的示范进程。本实例中的分布式联机数据通信系统400包括三个节点，即节点A、B、C。节点之间的通信，是由按照每个节点的系统配置数据库130(图3)中的规定彼此连接的线路处理器402-406完成的。可以看到，在线路处理器402-406之间还提供了备用连接，如虚线所示。每个链接，无论主链接还是备用链接，都由一个逻辑单元来代表。当在线路处理器402-406之间通信的消息在规定的时间限制内没有被接收到时，就用备用链接来进行线路处理器之间的通信。如果主链接和备用链接都不行，继续存在通信故障，节点的控制点412-416就会通过一个在它们之间连接的链接420-424通信来继续向任何节点位置的操作者提供访问其它节点，包括故障节点。

每个节点也有一个系统监控器426-430，系统监控器执行与其它节点的系统监控器的握手协议。每个系统监控器向系统中的所有其它系统监控器发送一个握手消息。握手消息最好包括发送者角度的系统中所有节点的状态图。当某系统监控器接收来自另一个节点的握手消息时，就将消息中包含的状态与其自己的关于所有节点状态的数据进行比较。只有两个或更多节点的系统监控器都认为某节点可能有故障时，才能宣布该节点有故障。例如，如果节点A的系统监控器426的消息将节点B标记为可能有故障，节点C的系统监控器430的消息也将节点B标记为可能有故障，则就节点B的状态达成了一致，节点B被标记为有故障。当系统监控器与某节点通过主链接和备用链接通信出现问题时，当它不能成功地与该节点处的监控器交换握手消息时，或者当它从该节点得到的握手消息中有“标记我故障”的请求时，系统监控器就将该节点标记为可能有故障。

对握手进程的更详细说明如下所述。节点A处的系统监控器426从系统配置数据库读取系统中其它节点处的系统监控器的逻辑名，这些逻辑名标识系统监控器428和430。系统监控器426然后向节点B处的系统监控器428发送握手消息。握手消息含有其自己的状态但没有站点标记(site token)。站点标记用于通讯其它节点的状态。在系统监控器426向节点B发送握手消息的同时，它也设置一个间隔定时器。系统监控器426也向节点C处的系统监控器430发送握手消息，该消息也含有其自己的状态但没有站点标记。也设置一个间隔定时器。然后，节点A处的系统监控器426从节点B处的系统监控器428接收握手消息，该消息含有节点B的状态。这个信息被用于更新节点A中的状态表。系统监控器426也从系统监控器430接收含有节点C的状态的握手消息，用其中的数据来更新状态表。

当为节点B设置的间隔定时器到期时，节点A的系统监控器426就向节点B的系统监控器428发送一个带有节点A状态和一个含有节点C状态的站点标记的握手消息，如在状态表中所报告的。同样，当第二个间隔定时器到期时，一个带有节点A状态和一个含有节点B状态的站点标记的握手消息也被发送给节点C。这时，节点B中的系统监控器428用一个含有在站点标记中表示的自己对节点C状态的理解的握手消息来响应节点A的握手消息。节点A的系统监控器426然后将从节点B接收的节点C的状态与其状态表中节点C的状态条目进行比较。注意，如果节点A以前向节点C发送的任何握手消息得不到确认或回答，节点A的状态表就会将节点C列为有故障。因此如果状态表和节点B的握手消息二者都表明节点C有故障，则节点A的系统配置数据库就要更新，将节点C标记为有故障。节点B执行与上述完全相同的进程，也将发现到节点C的故障状态，并相应地更新其系统配置数据库。

然后开始的就是用备用节点来承担故障节点的事务负荷的接管处理。为了通知备用节点内部的进程来处理故障节点的事务，备用节点的系统监控器可以向同一节点的控制点发送一条命令消息，请求如上所述地更新系统配置数据库，将该节点标记为故障，请求向备用节点处的所有进程发送一个广播消息，告知接管处理就要开始。

在接管处理期间，当一个或多个节点有故障时，去向故障节点的流量就被路由选择到备用节点。例如在图8中，节点B有故障，而节点A以前被指定为其备用系统。该系统中的每个进程实体也有至少一个指定的备用进程，流量被路由选择到备用实体。例如，一个终端定义文件记录了每个ATM终端的网络所有权数据，每条终端定义文件记录可以有一个主节点名和至少一个在系统配置数据库中保存的备用节点名。

在接管操作模式期间，当某个事务在直接与节点B相连的ATM 52’处启动时，它被传送到节点A的设备处理器80和路由器110去处理。路由器110确定，它的系统就是在接管模式期间负责这个事务的备用系统，并将事务消息发送给授权进程116。授权进程116也确定，它就是负责当前事务的特定卡定义文件(CDF)118记录的备用进程，于是就授权该事务。授权进程116在接管模式期间可以使用一个不同的预定事务授权限制集。授权进程116然后将消息发送给日志120以便将该事务记录在事务日志文件(TJF)122中，并且将该事务写入存储和转发文件(SAF)432。

当节点B变得可以运行时，恢复进程434将数据库更新数据传送给用户帐户文件(CAF)436和正余额帐户文件(PBF)438，以便它们能得到更新，以反映在接管期间所发生的事务。

以上对本发明的描述，总体设定的上下文是作为例子的电子资金与信息传输。然而，本发明适用于任何要求与外部设备或系统进行联机通信的应用程序。其它例子包括用于电子保险赔付金传输系统(electronicbenefits transfer system)、自动联机订票和信用卡销售点事务的应用程序。

尽管本文详细描述了本发明及其优点，应当明白，能从中作出各种变化、替代和改变而不偏离如后附权利要求中定义的本发明的精神和范围。

Claims

1.一种故障保险的事件驱动事务处理系统，包含：

至少一个具有多个用于处理由多个外部设备启动的事务的应用进程的系统节点；

一个向所述多个应用进程提供多个消息传递实体和服务以进行路由选择、彼此之间传送和接收消息的数据通信系统；

一个用于存储各实体和进程以及它们各自的备用实体的系统配置数据库；

在各系统节点上驻存的、用于监控并向其它系统节点传送每个系统节点的运行状态的系统监控器。

2.如权利要求1所述的系统，其中，每个系统节点进一步包含：

至少一个用于处理所述事务的应用数据库；

至少一个备用应用数据库。

3.如权利要求2所述的系统，其中，所述应用进程进一步包含用于将对所述应用数据库的修改传送给其备用应用数据库的数据库同步进程。

4.如权利要求2所述的系统，其中，所述应用进程进一步包含一个数据库恢复进程，用于在故障系统节点恢复运行后将由备用系统节点处理的事务传送到该故障系统节点上驻存的应用数据库。

5.如权利要求4所述的系统，其中，由所述备用系统节点处理的所述事务存储在所述备用系统上的预定数据库中，一直到所述故障系统节点恢复操作并且所述数据库恢复进程成功地将存储的所述事务传送到其上。

6.如权利要求1所述的系统，其中，各节点处驻存的所述系统监控器包括一个用于向位于其它系统节点的系统监控器轮询该其它系统节点的状态的握手协议。

7.如权利要求1所述的系统，进一步包含可由所述系统监控器访问的、用于记录各系统节点的状态的状态表。

8.如权利要求1所述的系统，其中，所述应用进程包括一个用于接收含有事务请求的消息并授权该消息的授权器进程。

9.如权利要求1所述的系统，其中，所述应用进程包括一个用于接收含有事务请求的消息并确定该消息的目的地的路由器进程。

10.如权利要求1所述的系统，其中，所述应用进程包括一个用于记录每个事务的日志进程。

11.如权利要求1所述的系统，进一步包含：

各系统节点与至少一个其它系统节点之间的主通信链路；

各系统节点与至少一个其它系统节点之间的备用通信链路，所述备用通信链路在所述主通信链路发生故障时是可运行的。

12.如权利要求11所述的系统，进一步包含在各系统节点之间的、用于传送控制消息的控制通信链路。

13.一种用于故障保险的事件驱动事务处理系统的方法，包含的步骤是：

在系统配置数据库中记录系统中每个节点的逻辑标识符、物理地址和状态；

轮询该系统中所有节点的状态以及它们对系统中所有其它节点的状态的理解；

如果判定有故障节点，则将处理消息路由选择到备用节点。

14.如权利要求13所述的系统，其中，所述轮询步骤包括的步骤是：

从各节点向该系统的各其它节点发送握手消息，该握手消息含有发送者节点的状态；

接收该握手消息，在状态表中更新发送者节点的状态条目，通过发送握手消息来回答发送者节点，其中该握手消息含有接收者节点的状态；

再次从各节点向该系统的各其它节点发送握手消息，该握手消息含有发送者节点和该系统中除该握手消息的目的接收者节点以外的所有节点的状态；

接收该握手消息，将该消息中的所有节点的状态与该状态表中的相应条目作比较。

15.如权利要求14所述的系统，其中，所述轮询步骤进一步包括的步骤有：

如果在该比较步骤中，状态表和握手消息中预定数量的节点都表明某节点有故障，则将该节点标记为有故障；

然后通知被指定为备用节点的节点开始对故障节点的进程负荷进行接管处理。

16.如权利要求13所述的系统，其中，进一步包含的步骤是：

执行对该故障节点的进程负荷的接管处理；

存储在接管处理期间执行的事务；

在该故障节点恢复运行时将所存储的事务转发给该故障节点；

更新该故障节点的数据库以反映接管处理期间执行的事务。

17.如权利要求16所述的系统，其中，该事务存储步骤包含的步骤有，存储对接管处理中使用的选定数据库集的修改。

18.如权利要求13所述的系统，进一步包含的步骤有：

记录对至少一个选定应用数据库中数据的修改；

将该修改转发给备用应用数据库；

对备用应用数据库中存储的数据作同样的修改。

19.如权利要求18所述的系统，其中，所述记录、转发和修改步骤定期进行，使该选定应用数据库中存储的数据与其备用应用数据库同步。