CN1682191A - 适于集成非同类过程的数据处理系统 - Google Patents

Abstract

一种数据处理系统，包含至少一个资源管理器(RM)，用于依照提交/撤销协议管理对各个系统资源的改变，和资源管理器协调器(RMC)，用于协调所述至少一个资源管理器的提交/撤销操作。提供了根据提交/撤销协议由资源管理器协调器协调的过程资源管理器(ERM)，用于管理不服从提交/撤销协议的非服从过程的执行。过程资源管理器在接收到撤销请求后，自动地确定要被执行的一系列补偿操作，以撤销在次级非服从过程的执行期间被执行的操作，并管理所述补偿操作的执行。

Description

适于集成非同类过程的数据处理系统

技术领域

本发明一般地涉及数据处理系统，并特别涉及在系统中运行的过程需要根据提交/撤回协议(commit/backout protocol)协调的数据处理系统，例如事务(transaction)处理系统。具体来说，本发明涉及适用于集成非同类(non-homogeneous)过程的数据处理系统，所述非同类过程即服从(compliant)提交/撤回协议的过程以及不服从这样的协议的过程。

背景技术

在现有数据处理环境中引入新的应用(例如程序、事务处理、类别、对象或方法)造成几个问题。由于快速的技术进步，和现有应用相比，新的应用一般基于不同的体系结构；使得新应用能够与现有应用交互作用可能是真正的挑战。

在今天尤其感受到了这个问题，因为出现了新的基于因特网的服务，例如用于实施电子商务功能。这些新的服务需要在公司数据处理系统内和例如传统应用的已有商务功能交互作用。

当已经存在的部件需要合作以实施新的服务时，可能会遇到类似的问题。

为了把新的应用集成在现有非同类(heterogeneous)应用的框架内，或者使得现有非同类应用交互作用以获取新的功能，需要考虑几个关键因素，既有技术的也有应用的。信息技术领域的多个不同技术被涉及到，成本和时间随之增加。

可以区分为四种可能的手段。

第一种办法试图最大程度地利用现有过程；为了使新的过程能够和现有过程交互作用，创建了接口层，它能够解释(interpreting)并把来自商务流程的请求恰当地翻译成服务和相关的一致控制(coherence control)。用这种方法就保护了用于开发已经存在的应用所做的投资。

根据第二种办法，开发冗余的功能。实行新的商务流程所必需的功能，尽管已经存在于现有环境中，但还是在新的环境中被复制。结果是功能和数据的重复，导致增大的开发和管理的时间和成本。此外，还可能出现复制的数据的一致性的问题。

按照第三种办法，已经存在的功能被修改，以适于要被实施的新的商务流程的要求。这涉及对现有功能和环境的高度准确的了解和专业技术的可用性，专业技术可能并非很容易获得。因此，成本可能会很高。

最后，第四种办法提供用于开发新的应用，新的应用既包括新的商务流程还包括已经在生产中的商务流程。除了成本以外，还需要相当长的时间来把新的过程投入生产，对公司核心商务有负面影响。

发明内容

考虑到前面所概括的技术的状态，本发明的一个目的就是提供能够支持不同类型(etherogeneous)应用的数据处理系统。

根据本发明，采用如所附权利要求1中所描述的数据处理系统，已达到此目的和其他目的。

简单地说，该数据处理系统包含至少一个资源管理器和资源管理器协调器，资源管理器用于依照提交/撤回协议管理对各个系统资源的改变，资源管理器协调器用于协调该至少一个资源管理器的提交/撤回行为。

提供了过程资源管理器，由资源管理器协调器根据提交/撤回协议协调，用于管理不服从提交/撤回协议的非服从过程的执行。在接收到撤回请求后，过程资源管理器自动地确定一系列要被执行的补偿操作，以撤回在非服从过程的执行期间所执行的操作。

附图说明

通过下面参考附图以非限制性的例子的方式对本发明的一个实施例的详细描述，将使得本发明的特点和优点更加清晰，其中：

图1是根据本发明的实施例的事务处理管理系统的主要部件的原理框图；

图2A和图2B示意性地示出图1的事务处理管理系统的资源管理器协调器对工作单位的管理；

图3示意性地示出图1的事务处理管理系统的服务提供器子系统所提供的服务；

图4示意性地示出由服务提供器子系统所提供的商务请求编目(cataloging)服务所拥有的商务请求栏目；

图5示意性地示出由服务提供器子系统所提供的目录(directory)服务所拥有的对应(counterpart)系统目录；

图6示意性地示出由服务提供器子系统所提供的系统恢复服务所实施的系统恢复过程；

图7示意性地示出事务处理管理系统的工作。

具体实施方式

参考附图，图1按照功能块，示意性地示出根据本发明的实施例的事务处理管理系统的主要部件。

事务处理系统包含数据处理系统SYS，内含(hosting)事务处理管理器系统TM，事务处理管理器系统在下面被简称为事务处理管理器。

事务处理管理器TM管理由应用所发出的商务服务请求BR(在下面被称为商务请求)，所述应用或者是对于内含事务处理管理器TM的数据处理系统SYS来说在本地运行，如所示例子中的应用APP，或者是在远程数据处理系统中运行，例如在通过因特网连接到企业的数据处理系统的客户端计算机上运行。举例来说，数据处理系统SYS是银行代理的前端服务器，接收银行ATM的商务服务请求。

数据处理系统SYS被连接到一个或多个独立的数据处理系统，例如在图中所示、在下面被称为对应系统的两个数据处理系统：C_SYS1和C_SYS2。数据处理系统SYS可以和对应系统C_SYS1、C_SYS2交互作用，用于为商务请求服务。系统SYS和对应系统C_SYS1、C_SYS2可以通过LAN、系统综合体(SYSPLEX)、集群(CLUSTER)、WAN、因特网连接。系统SYS和对应系统C_SYS1、C_SYS2可以形成本地数据处理系统组，例如系统综合体或集群，并且本地系统组可以被连接到一个或多个地理上的远程数据处理系统或系统组。回到前面引用的例子，系统SYS(前端银行代理服务器)被连接到银行代理主服务器，主服务器转而又连接到不同银行代理中的其他主服务器的网络。

数据处理系统SYS内含资源管理器协调器RMC，控制和协调多个资源管理器RM的行为(activity)。每一个资源管理器负责管理各自的系统资源(未在图中示出)，例如数据库、档案文件、数据表格、文档、数据记录等。每一个资源管理器RM管理由在事务处理管理器TM的控制下运行的通用任务所请求的对各自资源的改变。

事务处理处理系统的被称为原子性(atomicity)的一个特征是：对系统资源的访问和更新一般是通过执行也被称为工作单位(unit of work，此后的UOW)的离散事务处理而被实行。UOW是在系统资源上的一系列协调操作，以便所有的改变都生效或者全都无效。这些操作一般是对事务处理处理系统的储存器内所保存的数据做出的改变。以这种方法防止了系统资源彼此不一致。如果更新操作组其中之一失败了，则其他的也必须不能生效。然后，UOW把系统资源的一致状态变换为另一种一致状态，但不需要保持所有中间步骤的一致性。

依靠一般被称为提交过程的事务处理同步过程来保持事务处理的原子性质。在事务处理执行中，资源改变被同步的一致性的逻辑点被称为提交点；一旦到达提交点，UOW被声明提交的任务关闭，或者当任务终止时UOW被关闭。

事务处理的原子性通过资源更新来获得，所述资源更新在事务处理中进行，被保持存疑(未提交)直到完成事务处理后声明提交为止。如果事务处理成功，则使事务处理的结果为永久性的(被提交)；如果事务处理失败，则所述不成功的事务处理的所有作用均被拒绝(被撤回或者被退回重来)。即，使得资源更新对任务是永久性的和可见的，但是不包括下述任务：在此任务下，资源更新仅仅在成功的完成之后被实行；在每个工作单元的执行期间，所有此时被更新的资源必须被锁定，以防止进一步的更新访问。反之，当事务处理撤销时，资源被恢复到事务处理开始之前存在的一致状态。

由一个任务所请求的对由通用资源管理器RM管理的系统资源的改变被那个资源管理器以这样的方式来管理：在单步(single-phase)或双步(two-phase)提交协议下，在接收到资源管理器协调器RMC的提交请求后，依据任务的结果，允许所述改变的推迟提交。对系统资源的改变的确定或者拒绝可以由提交或撤回命令显式地(explicitly)触发，或者可以由任务的成功或不成功的终止而隐式地(implicitly)触发。资源管理器协调器RMC接收显式的提交或撤回命令，或任务成功或不成功的终止的指示，并把提交或撤回请求传播到资源管理器RM，该资源管理器RM负责管理在改变中所涉及到的系统资源。

事务处理管理器TM包括商务请求管理器子系统BRM、扩展资源管理器子系统ERM和服务提供器子系统SER，为商务请求管理器子系统BRM和扩展资源管理器子系统ERM都提供服务。

每当接收到商务请求BR时，商务请求管理器BRM被事务处理管理器TM激活。事务处理管理器TM检测进入商务请求，并激活商务请求管理器BRM。进入商务请求BR被商务请求管理器BRM作为指向通用事务处理或者应用的服务请求来管理；服务请求由任务T1处理，涉及一个或多个UOW。

像下文中将要详细地说明的那样，商务请求管理器BRM在任务T1开始之后被事务处理管理器TM激活，被启动用于处理商务请求BR，商务请求管理器BRM利用服务提供器子系统SER所提供的服务，用于控制任务执行。

具体来说，商务请求管理器BRM实施商务请求分类方案，并依据进入商务请求BR所属的商务请求类别，利用服务提供器SER所提供的不同服务。

总的来说，依据商务流程，在为处理进入商务请求BR而开始的任务T1的执行期间，可以产生一个或多个服务请求，这些服务请求指向不同程序或者事务处理，它们在内含事务处理管理器TM的同一系统SYS内运行，或者在一个或多个对应系统C_SYS1、C_SYS2中运行，例如图1中所示的服务请求OBR1和OBR2，并且此后被称为输出商务请求，或缩写为OBR(outboundbusiness request，输出商务请求)。这些服务请求被和进入商务请求BR类似地对待，这些服务请求导致在OBR所指向的各个对应系统C_SYS1、C_SYS2中开始了任务T21、T22，并且这些服务请求被扩展资源管理器ERM管理。

可以看到，在本说明的上下文中，OBR不仅仅是相应于系统SYS的对应系统发出的商务请求，还是相应于系统SYS的部件，例如一个应用所发出的商务请求，该部件的特点是具有较弱的链接，即是一个不能服从提交/撤回协议的部件。

不服从提交协议的接口过程，即其UOW在撤销阶段没有被资源管理器协调器同样地协调的过程，使得有必要运用一个补偿行为(隐式或显式的)，所述补偿行为专用于使得系统向动态确定的一致状态收敛。这由错误操作或者显式的撤回请求来触发，并由扩展资源管理器ERM通过显式的激活补偿部件(XBR和/或XOBR，稍后详细描述)来管理，或通过取回先前由服务提供器子系统SER所提供的日志服务所记录的内容来管理。在前面确立阶段(可能包括先前的补偿企图)期间由日志服务所记录的信息的基础上，补偿行为所必需的信息被动态地确定。

具体来说，扩展资源管理器ERM被事务处理管理器TM看作资源管理器RM之一。每一次OBR，例如ORB1和OBR2被发出时，事务处理管理器TM激活扩展资源管理器ERM；像稍后将要说明的那样，OBR可以显式地调用扩展资源管理器ERM，或者后者可以被隐式地调用。简单地说，扩展资源管理器ERM监督OBR的执行，并确保它们即使在异常的情况下仍然能被正确地执行，所述异常的情况例如在OBR的处理中所涉及的UOW的执行期间可能出现的存疑(in-doubt)状况。从资源管理器协调器RMC的观点，扩展资源管理器ERM以与资源管理器RM管理各个系统资源相类似的方式管理OBR和在对应系统上运行的用于为OBR服务的过程，使得能够实施在对应系统上运行的过程的单步或两步提交/撤回协议。

具体来说，扩展资源管理器ERM标识、激活和监视次级过程(secondaryprocess)(例子中的任务T21和T22)，次级过程被初级过程(primary process)(T1)调用，并被商务请求管理器BRM激活。虽然对由资源管理器RM所管理的系统资源所做的改变可以被撤销，并且系统资源被带回到施加这样的改变之前所处的状态，但是总的来说，对于由次级过程所导致的改变，这是不可能的。在系统SYS和对应系统之间的通信协议、后者的行为等的问题，在此上下文中被统称为不稳定(labile)链接问题，这些问题使得无法使对应系统回到它们在次级过程开始前所处的状态。总的来说，扩展资源管理器ERM运用对次级过程所做的改变的补偿行为，来替代真正的撤销。

在通用任务的生存周期期间，几个UOW可以被顺序地实例化，并被提交或撤销。每一个UOW都由用于管理UOW的单意标识码(UOWID)所标识。UOW的提交或撤销导致在执行中的UOW的自动结束，并且如果商务逻辑需要，有可能实例化一个新的UOW。

在任务T1执行期间，可以请求对由不同的资源管理器RM所管理的系统资源做出的改变。在这种情况下，多个相关的UOW被同时实例化；所有这些相关的UOW均从属于(subordinate)由资源管理器协调器RMC管理的主UOW，主UOW在下面将被称为协调UOW(coordination UOW，COO-UOW)。这种状况被在图2A中示意性地示出，其中UOW1、UOW2、和UOW3是相关的，并由资源管理器协调器RMC作为协调UOW COO-UOW管理。

类似地，在任务T1(主任务)执行期间，相关的任务T21、T22(次级任务)可以被在不同的对应系统C_SYS1、C_SYS2上开始；这样，几个潜在地彼此相关的UOW可以被同时地在逻辑上和主任务T1相关联；还是在这种情况下，所有这些UOW从属于由资源管理器协调器RMC管理的COO-UOW。这种状况被示意性地在图2B中绘出。

在此第二种情况下，并假设在系统SYS和对应系统之间的链接很强(即并非不稳定的，使得能够实施提交/撤销协议)，则在对应系统中的资源管理器，例如图2B中所示的对应系统C_SYS1中的资源管理器C-RMC1，可以由系统SYS的资源管理器协调器RMC来协调，或者，它们可以由本地资源管理器协调器来协调，转而由系统SYS中的资源管理器协调器来协调。在任何情况下，所有被实例化的UOW从属于唯一的COO-UOW。

反之，如果在系统SYS和对应系统之间的链接是不稳定的，则将建立几个COO-UOW，每一个均由各自的资源管理器协调器管理，这些COO-UOW彼此不进行协调。这样的COO-UOW，例如图2B中的COO-UOW1和COO-UOW2，由扩展资源管理器ERM作为在下面被称为EXT-UOW的扩展UOW EXT-UOW(extend UOW，EXT-UOW)来处理。

通常，由每一个任务所请求的对数据所做的改变被分组为UOW，由资源管理器RM来管理，而该资源管理器RM由资源管理器协调器RMC来协调，这样以便允许更多的任务同时作用在共享的档案文件上。只有在相关联的UOW提交之后，才使由通用任务所请求的改变对其他的任务公开和可用的；如果该UOW被撤销，则改变不被确定，并使档案文件中的数据以未被改变的形式对其他的任务公开。这样，可以确保不同的任务访问一致的数据，而不受其他任务所做的部分的改变的影响。管理被程序或事务处理使用的逻辑上一致的数据组的事务处理(transaction)处理系统的能力被称为参考完整性。

但是，由COO-UOW协调的UOW可以既包括服从提交/撤销协议的UOW(服从UOW)，也包括由于所涉及的过程或资源的性质而不支持提交/撤销协议的UOW(所谓的非服从UOW)。在这种情况下的COO-UOW被称为扩展UOW(extended UOW，EXT-UOW)。

和COO-UOW由服从UOW所组成的情况不同，在EXT-UOW的情况下，非服从UOW的存在妨碍了保障正常的数据完整性方案，至少对于在非服从UOW中所发生的那部分改变来说如此。在服从UOW的执行期间对系统资源所做那些的改变的确定被推迟，并从属于主任务的结果；在非服从UOW的执行期间对系统资源所做的剩下的改变，或者可以视其执行情况而确定，或者可以在相关联的次级任务结束时被确定。和EXT-UOW相关联的主任务的成功完成不会造成问题，因为所有的改变均被确认：在服从UOW中所做的改变被确定，而在非服从UOW中所做的改变已经被确定，无须被撤销。不同的是，可能的撤销请求(或者是应用的，或者是基础设施的)产生了所涉及的资源的失调：尚没有被提交的改变可以被撤销并被撤销，而已经被确定的改变因为不受提交协议支配，故无法被撤销，而没有被撤销。在这种情况下，整个系统的状态(系统SYS和对应系统C_SYS1和C_SYS2)不能被带回到做出改变前的状态；因为系统不能被带回到初始状态，而需要执行特定的补偿行为，用于使得整个系统向着动态确定的一致状态收敛。

这涉及两个层次的系统注释。在提交服从UOW中所带的改变的情况下，由于使被改变的数据对不同的任务公开的时刻不同，产生一个第一层的注释。由于撤销由任务所带来的改变，并由于系统为撤销请求所做的服务的不同，产生一个第二层的注释，系统所做的服务的不同在于：在服从UOW内所做的改变被立刻撤销，而在非服从UOW内所做的改变被补偿，并且，补偿甚至可以被推迟。暂时地失调会使得逻辑上相关的数据在不同的时间以及以不确定的形式公开。

参考图3，示意性地示出了在本发明的一个实施例中，由服务提供器子系统SER所实施的服务。服务提供器子系统SER所提供的一些服务被商务请求管理器BRM利用，其他的服务被扩展资源管理器ERM利用，并且一些服务既被商务请求管理器BRM利用，也被扩展资源管理器ERM利用。特别是，服务的子集一般被提供给商务请求管理器BRM所开始的每一个任务，无论它是和分类的商务请求相关联的任务还是和非分类的商务请求相关联的任务。服务提供器子系统SER所提供的服务的列表包括：商务请求编目服务CATS(cataloging Service，CATS)、目录服务DIRS(directory service，DIRS)、任务恢复服务TSR(task recovery service，TSR)、系统恢复服务SYSR(systemrecovery service，SYSR)、连接服务CNCT(connectivity service，CNCT)、日志服务LOG(log service，LOG)、监视服务MON(monitor service，MON)、UOW保护服务UOW-P(UOW protection service，UOW-P)、错误恢复服务ERR(error recovery service，ERR)、商务请求保护服务BRPR(business requestprotection service，BRPR)、商务请求验证服务BRVR(business request verifyservice，BRVR)。

一般被提供给分类的和非分类的商务请求的服务包括：日志服务LOG、监视服务MON、UOW保护服务UOW-P和错误恢复服务ERR。

除了公共服务之外，针对分类的商务请求的特定服务包括：编目服务CATS、商务请求保护服务BRPR和商务请求验证服务BRVR。

商务请求管理器BRM所利用的服务包括：商务请求保护服务BRPR、错误恢复服务ERR、UOW保护服务UOW-P、商务请求验证服务BRVR、监视服务MON、日志服务LOG和编目服务CATS。

扩展资源管理器ERM所利用的服务包括：编码服务CATS、日志服务LOG、UOW保护服务UOW_P、监视服务MON、错误恢复服务ERR、连接服务CNCT、目录服务DIRS、任务恢复服务TSR和系统恢复服务SYSR。

商务请求管理器BRM所实施的商务请求分类方案依靠商务请求编目服务CATS，以便把进入商务请求分类为分类的商务请求CBR或非分类的商务请求NCBR，所述分类的商务请求CBR被列出在由编目服务CATS所拥有的商务请求栏目中，而非分类的商务请求NCBR在所述栏目中不存在。

稍后将详细地描述服务提供器子系统SER所实施的服务。

在工作中，考虑到服务请求所指向的部件的性质(应用程序、事务处理、底层服务，例如连接器)，以及与其相关联的过程的逻辑状态(运行、撤销、未决、存疑等)，商务请求管理器BRM和扩展资源管理器ERM对服务请求进行分类，无论它们是对事务处理处理系统的进入商务请求，还是在先前接收的商务请求的处理期间所产生的服务请求。

商务请求管理器BRM和扩展资源管理器ERM的行为依赖于发出服务请求的实体的状态、依赖于被发出的服务请求的种类，以及依赖于服务请求所指向的部件的状态。

来自系统SYS外部，或在为已接收到的商务请求服务时所产生的每一个服务请求，均被商务请求管理器BRM分析。服务请求可以包括显式的指示，指明该服务请求指向商务请求管理器BRM或扩展资源管理器ERM(显式服务请求)：在这种情况下，商务请求管理器BRM或者直接处理服务请求、或者调用扩展资源管理器ERM。如果服务请求不包括这样的显式指示(隐式服务请求)，则服务请求被监视服务MON拦截，并被传递到商务请求管理器BRM。商务请求管理器BRM利用编目服务CATS确定服务请求的种类。如果服务请求是分类的，则它将被商务请求管理器BRM或者扩展资源管理器ERM处理。反之，如果服务请求结果是非分类的，则它将被路由回到事务处理管理器TM，并由事务处理管理器TM服务。

在本发明的实施例中，下面的可能的服务请求分类方案被采用。

非分类的商务请求(Non-classified business request，在下面被称为NCBR)是相应于由事务处理管理器TM所管理的事务处理或程序而发出的通用服务请求，商务请求管理器BRM无法将NCBR与在编目服务CATS所拥有的商务请求栏目中列出的任何服务请求相关联；商务请求管理器BRM提供给NCBR的服务仅仅是属于公共服务的子集的那些。NCBR可以发出任何类型的商务请求，显式的或隐式的，分类的或非分类的；以及访问可恢复的或不可恢复的系统资源。

分类的商务请求(Classified business request，在下面被称为CBR)是商务请求管理器BRM可以将其与在编目服务CATS所拥有的栏目中列出的服务请求之一相关联的服务请求。

在CBR类别中，额外地定义了下列种类的商务请求。

非受保护分类的商务请求(Non-protected classified business request，在下面被称为NPCBR)是商务请求管理器BRM为其提供所有的公共服务、以及编目服务CATS和验证服务VER的CBR。在NPCBR的处理没有完成的情况下，由于错误或者异常，商务请求管理器BRM不采取任何涉及商务请求的自动再激活的操作，把这个负担留给该服务最初的请求者。NPCBR可以发出任何类型的商务请求，显式的或隐式的，分类的或非分类的；以及访问系统资源，可恢复的或不可恢复的。

受保护分类的商务请求(Protected classified business request，在下面被称为PCBR)是从所有由商务请求管理器BRM所实施的服务，包括保护服务BRPR受益的CBR。和NPCBR不同，如果由于错误或者异常未完成PCBR的处理，则商务请求管理器BRM利用商务请求保护服务，自动地管理商务请求的再激活，以便保证其处理和完成，可能有所推迟。PCBR可以发出任何种类的商务请求，显式的或隐式的，分类的或非分类的；以及访问系统资源，可恢复的或不可恢复的。假如一个PCBR(主PCBR)发出另一个PCBR(次级PCBR)，则保护服务仅被提供给主PCBR，而不提供给次级PCBR，以避免次级PCBR的多次再激活。可以看到，没有给NPCBR或NCBR所发出的次级PCBR提供保护服务，这些次级PCBR也没有被自动地再激活；换句话说，只有主PCBR被再激活。

补偿商务请求(Compensation business request，在下面被称为XBR)是特殊种类的PCBR，被激活用于实行撤销行为，或者更一般地说，补偿行为。XBR指向在系统SYS内运行的程序或事务处理，系统SYS内含事务处理管理器TM。具体来说，当资源管理器协调器RMC通知扩展资源管理器ERM有关于错误或撤销请求时，XBR被扩展资源管理器ERM自动地激活。在商务请求管理器BRM和扩展资源管理器ERM的控制之下工作的XBR可以发出补偿输出商务请求(compensation outbound business request，XOBR，稍后描述)、NCBR和CBR，以及访问可恢复的或不可恢复的系统资源。作为一种特殊类型的PCBR，XBR受益于保护服务，并被自动地再激活。

有关于OBR，定义了下列种类。

不可恢复输出商务请求(Non-recoverable outbound business requests，在下面被称为NROBR)是被NCBR或CBR(NPCBR或PCBR或XBR)显式地或隐式地发出的服务请求，并指向在对应系统C_SYS1或C_SYS2中运行的程序或事务处理，对系统SYS来说，对应系统C_SYS1或C_SYS2是本地的或远程的；或者，NROBR指向系统SYS的部件，但是该部件与系统SYS链接较弱。为了处理NROBR，ERM利用编目服务CAT、目录服务DIR、任务恢复服务TSR、系统恢复服务SYS_R和连接服务CNCT。当异常或撤销请求发生时，扩展资源管理器ERM不尝试恢复输出商务请求。NROBR可以访问可恢复或不可恢复的系统资源，并根据其去往的对应系统的特征和商务逻辑，发出任何种类的服务请求。

显式补偿、可恢复输出商务请求(Explicit-compensation，recoverableoutbound business request，在下面被称为EROBR)是NCBR或CBR发出的服务请求，指向在对应系统C_SYS1或C_SYS2中运行的程序或事务处理，或者指向系统SYS的部件，但是该部件与系统SYS链接较弱。当异常或撤销请求发生时，扩展资源管理器ERM直接开始用于EROBR的显式补偿的行为；或者为了达到此目的，利用由服务提供器子系统SER所提供的服务，特别是日志服务LOG、UOW保护服务UOW_P、连接服务CNCT、监视服务MON和错误恢复服务ERR。EROBR可以访问可恢复或不可恢复的系统资源，并根据其指向的对应系统的特征和商务逻辑，发出任何种类的服务请求。

隐式补偿，可恢复输出商务请求(Implicit-compensation，recoverableoutbound business request，在下面被称为IROBR)是NCBR或CBR发出的服务请求，指向在对应系统中运行的程序或事务处理，或者指向系统SYS的部件，但是该部件与系统SYS链接较弱。当异常或撤销请求发生时，扩展资源管理器ERM不直接开始用于IROBR的补偿的行为；相反，补偿被隐式地实行，这意味着推迟到IROBR重新执行的时候；如果IROBR被PCBR调用，则这样的重新执行被商务请求管理器BRM自动管理，或者，在IROBR由NPCBR发出的情况下，重新执行由服务请求者激活。扩展资源管理器ERM利用服务提供器子系统SER提供的服务，特别是日志服务LOG、工作单位保护服务UOW_P、连接服务CNCT、监视服务MON和错误恢复服务ERR。IROBR可以访问可恢复的或不可恢复的系统资源。

补偿输出商务请求(Compensation outbound business request，在下面被称为XOBR)是特殊类型的IROBR，并且是由在特定任务内运行的XBR所发出的服务请求，受扩展资源管理器ERM的支配，扩展资源管理器ERM支持先前发出的EROBR，这些EROBR需要被补偿或者由于错误或撤销请求还未被补偿。XOBR也可以在任务恢复阶段(稍后描述)中被底层服务激活。XOBR指向在对应系统中运行的程序或事务处理，或者指向系统SYS的部件，但是该部件与系统SYS链接较弱。当异常发生时，XOBR不被自动地激活：只有被扩展资源管理器ERM发出的XBR能够激活XOBR。XOBR可以访问可恢复的或不可恢复的系统资源。XBR和XOBR的激活由ERM处理，不给请求者应用添加负担，请求者应用可能正在等待任务恢复阶段的完成代码，或者，在导致超时的情况下，已经被通知有关于由扩展资源管理器ERM所负责的恢复操作的发生。

任何商务请求，或者是非分类的(NCBR)，或者是分类的(CBR)，并且，如果是分类的，则或者是受保护的(PCBR)，或者是不受保护的(NPCBR)，都可以(显式地或隐式地)发出一个或多个OBR(NROBR、EROBR或IROBR)。

上述服务请求的分类要在新应用的开发中被采用，以便正确地标识实施所需商务流程必需的部件，在错误、异常事件或撤销请求的情况下，由事务处理管理器TM通过资源管理器协调器RMC协调，上述服务请求的分类确保为了管理任何补偿而激活的适当的应用或底层部件被一直进行到在EXT-UOW中所涉及的数据的时刻。这样就确保了在错误、异常事件或应用撤销请求的情况下，依靠自动的显式补偿或推迟的隐式补偿，在EXT-UOW中所涉及的资源的状态向一致最终状态收敛，所述补偿受商务请求管理器BRM和扩展资源管理器ERM支配。

具体来说，在涉及EXT-UOW的任务的不成功完成的情况下，商务请求管理器BRM和扩展资源管理器ERM能够标识并自动激活使得整个系统(即所涉及的资源)在可能时向着初始状态收敛，或者向动态确定的一致状态收敛的过程，所述一致状态由商务请求管理器BRM、扩展资源管理器ERM和可能嵌入在XBR/XOBR中的应用商务逻辑动态确定。尽管可以开发任何种类的XBR，但是缺省的XBR实施补偿阶段，以相反次序发出与每一个EROBR相关的XOBR，在对连接服务CNCT的调用的结果和每一个被调用的XOBR的结果的基础上发挥作用。

下面将详细地描述商务请求管理器BRM和扩展资源管理器ERM所实施的服务。

编目服务CATS

编目服务CATS允许根据前面所描述的分类方案对商务请求进行分类。

编目服务CATS在栏目CAT的基础上运行，在图4中示意性地绘出了栏目CAT的例子。栏目CAT是具有多条记录的表格。每一条栏目记录包括多个字段：BRID/CLID、BRCLS、ASSCMP、STUPSTAT、IN-FLGT STAT、C-SYS、SUB C-SYS、HEADER、TRAILER、ASSBR、XBR/XOBR、USAUT/ACC、MSGFRMT、OTHER INFO。

字段BRID/CLID包含标识分类的商务请求的商务请求标识符(A、B、C...)，或者标识商务请求类别的商务请求类别标识符(例如NPCBR、NCBR...)。字段BRID/CLID是栏目CAT的输入键(entry key)。

字段BRCLS包含商务请求类别标识符(例如NPCBR、PCBR、OBR、XBR、XOBR)，商务请求类别标识符指定在相关联的字段BRID/CLID中标识的商务请求的类别。

字段ASSCMP包含与在相关联的字段BRID/CLID中标识的商务请求相关联的部件(程序，或商务处理，或两者皆有)的指示。例如，对于被标识为A的商务请求，在栏目中没有指定相关联的程序或者事务处理：当商务请求A被接收到时，被激活的部件是A自身；不同的是，对于被标识为P的商务请求，程序PGh和事务处理Trk被指定，意味着当商务请求P被接收到时，事务处理Trk内的程序PGh将被激活。

字段STUPSTAT定义了在系统启动(稍后描述)时要给予商务请求的状态(开或关)。字段IN-FLGT STAT包含商务请求未定(in flight)时对其当前状态的指示。

字段C-SYS为OBR定义了它们所指向的对应系统。在对应系统具有一个或多个与其相关联的子系统的情况下，字段SUB C-SYS指定了OBR指向字段C-SYS中所定义的对应系统的哪一个子系统。储存在字段C-SYS和SUB-C SYS中的信息形成了对栏目服务的访问键。

字段HEADER和TRAILER定义了商务请求，这些商务请求分别被在为在相关联的字段BRID/CLID中标识的商务请求服务之前和之后发出。在所示的例子中，当接收到被标识为A的商务请求时，在为其服务之前和之后，分别为商务请求E和F服务。

字段ASSBR定义了商务请求，这些商务请求可以在为在相关联的字段BRID/CLID中标识的商务请求服务的同时被发出。再次参考所示的例子，当接收到被标识为A的当商务请求时(并且在已经服务了头商务请求(headerbusiness request)E之后)，服务商务请求G和H(跟着是尾商务请求(trailerbusiness request)F)。

字段XBR/XOBR(对EROBR是强制性的)定义了补偿商务请求(XBR或XOBR)，要执行所述补偿商务请求，用于补偿由在相关联的字段BRID/CLID中所标识的商务请求所执行的操作。在所示的例子中，为了补偿在为商务请求A服务时所执行的操作，发出了XBR J(XBR J反过来对应于XOBR次序L和M)。如果对于给定的商务请求没有指定特定的XBR，则将调用缺省的XBR，用于补偿在商务请求内所发出的OBR所执行的操作；扩展资源管理器ERM将在服务LOG所提供的信息的基础上，确定补偿操作。可以看到，没有补偿商务请求可以与XBR和XOBR相关联，因为它们是隐式的补偿商务请求，其补偿在由服务LOG所提供的信息(指示已经被执行的行为和那些要被执行的行为)的基础上实行。

总而言之，有关于商务请求A，储存在栏目CAT内的信息提供了在接收到商务请求A时，商务请求序列E-＞G-＞H-＞F被实际发出和服务；在出错的情况下，XBR J实行所执行的操作的补偿，XBR J反过来和XOBR序列L-＞M对应。关于商务请求B，它是商务请求P的别名。在发出OBR G和H之后发生的故障事件中，缺省XBR被扩展资源管理器ERM调用，并且涉及XOBRL和M的逆序列(reverse sequence)被自动地实施。

字段USAUT/ACC定义了用于在相关联的字段BRID/CLID中所标识的商务请求的执行允许的用户权限等级和帐号。

字段MSGFRMT定义了在相关联的字段BRID/CLID中所标识的商务请求的调用消息的格式(指定了用于解释的一组规则)。

字段OTHER INFO用于指示额外的信息可以被储存在栏目CAT中。

除了用于特定商务请求(例如图4中被标识为A、B、C等的记录)的记录以外，栏目CAT还可以包括提供用于商务请求的类别的缺省信息的记录，例如被标识为NPCBR的记录(用于所有类别NPCBR的商务请求)。当接收到在列表A、B、C等中找不到、但是被标识为NPCBR的商务请求时，储存在栏目的记录NPCBR中的信息被应用。在所示的例子中，为类别NPCBR指定的缺省信息包括开(ON)状态和XBR Z，所述开(ON)状态要在系统启动时被分配给每一个NPCBR，所述XBR Z在错误的情况下或用于补偿在NPCBR中发出的一个或多个OBR所执行的操作的撤销请求的情况下被调用。

此外，栏目CAT还可以包括指定关于NCBR的缺省信息的记录，例如在所示例子中的记录NCBR，要被给予任何非分类的商务请求。

最后，栏目CAT可以包括定义用于特定类别商务请求的重载信息(override information)的记录(例如在所示例子中的记录NPCBR)。

从栏目CAT取回的信息对商务请求的执行上下文(execution context)的定义有贡献。具体来说，编目过程，或者用于定义商务请求的执行上下文的过程如下：

当商务请求被发出时，可以提供定义商务请求的执行上下文的信息。在商务请求被显式地调用的情况下，该信息可以被显式地提供；或者在隐式的调用的情况下，该信息被从商务请求的调用的上下文推导出。通常，商务请求的显式调用具有形式：

a)APPcallBRM(BR，inpData，[XBR]，[CTXT/ANNL data]，[tran]，[user])；

b)BRcallERM(OBR，inpData，[C-SYS]，[SUBC-SYS]，[XOBR]，[CTXT/ANNL data]，[tran]，[user])；

c)XBRcallERM(XOBR，OBRinp/out/CTXT/ANNLdata，[C-SYS]，[SUBC-SYS]，[tran]，[user]，[previous XOBR in/reply/outcome])其中，a)代表应用APP发出被编目或未被编目的商务请求的情况；b)代表商务请求(被编目或未被编目)发出OBR的情况；和c)代表在补偿阶段期间，XBR调用XOBR的情况。方括号内的信息是可选的。具体来说，BR是被调用的商务请求的标识符；inpData是在调用时所提供的输入消息；C-SYS、SUBC-SYS是对应系统和子系统的标识符；XBR是补偿商务请求的标识符，在有必要进行补偿时，系统将激活所述补偿商务请求；XOBR是输出补偿商务请求的标识符；CTXT/ANNL数据代表在调用时间所提供、可以在补偿阶段由系统使用的信息；tran和user定义了上下文(权限等级、事务处理等)，被调用的商务请求在该上下文中被执行。在调用XOBR(情况c)时所提供的信息可以包括与要被补偿的OBR相关联的信息，包括OBR的结果/回复消息。

此信息与储存在栏目中的信息集成在一起。不同的优先权等级被分配给不同的信息源；特别是，与商务请求的调用一起提供的信息具有超过在栏目中为该商务请求指定的信息的优先权，在栏目中为该商务请求指定的信息转而具有超过在栏目中为该类别商务请求指定的缺省信息的优先权。在栏目中为该类别商务请求指定的重载信息如果存在的话，具有最高的优先权。

将要看到，可以提供两个独立的栏目而非单个栏目，一个用于商务请求管理器BRM，而另一个用于扩展资源管理器ERM。可以在多于一个表中构建一个或几个栏目。

系统SYS的专用部件(配置部件)使得能够配置系统，特别是栏目CAT。

目录服务DIRS

目录服务DIRS提供了定义OBR的执行上下文的信息。

目录服务DIRS在目录DIR的基础上工作，图5中示意性地绘出了它的一个例子。目录DIR是具有多条记录的表。每一条栏目记录包括多个字段：C-SYS、SUB C-SYS、ASSCMP、C-SYS ST-UP STAT、C-SYS IN-FLGT STAT、CNCT ID、CNCT ATTR、SIGN-ON、IN-DOUBT、BACKOUT、VER、SYS RECMODE、TO、USAUT/ACC、MSGFRMT。

字段C-SYS、SUB C-SYS是目录DIR的输入键。当OBR被调用时，从上面所描述的编目过程导出此信息。

字段ASSCMP和在栏目CAT中的字段ASSCMP类似，包含对与OBR相关联的部件(程序，或事务处理，或两者皆有)的指示。在目录的这个字段中指定的信息重载从上面所描述的编目过程导出的那个；如果在这个目录字段中没有指定相关联的部件，则从编目过程导出的信息保持有效。参考所示例子，每一次调用指向对应系统C-SYS2的OBR，将执行远程事务处理RMTRq内的远程程序RMPGp。

字段C-SYS ST-UP STAT定义了在系统SYS启动时对应系统的状态；如果这个字段被设置为开(ON)，则在系统SYS启动时不需要执行用于对应系统的系统恢复过程。字段C-SYS IN-FLGT STAT定义了对应系统的当前状态：如果被设置为开(ON)，则此字段指示对应系统是可用的。

字段CNCT ID提供了扩展资源管理器ERM调用的连接器的标识符，用于和对应系统建立连接。连接器是负责连接系统SYS和对应系统的部件，OBR指向所述对应系统。期望连接包括处理在逻辑层和物理层的通信协议。对于每一个对应系统，可以定义一个或多个连接器，给定连接器的选择依赖于通信问题的考虑，依赖于采用的通信范例，以及依赖于OBR的性质。每一个连接器最好被设计成能够一次支持与一个或多个对应系统的多个会话(指向一个或多个对应系统的OBR)。连接器辅助扩展资源管理器ERM实行OBR主张、OBR补偿(XOBR)、系统开始(sign-on)和验证阶段、存疑状况的解决行为中的任何一个。

当开发了新的OBR时，要与其相关联的连接器需要被标识；如果可用的连接器中无一合适，则需要根据新的OBR的应用协议和扩展资源管理器ERM的激活协议，开发新的连接器。

字段CNCT ATTR指定了用于连接器的信息，例如要被建立的连接的属性，定义了通信的类型以及建立连接要利用的资源。此信息重载了连接器的缺省信息。

字段SIGN-ON、IN-DOUBT、BACKOUT和VER分别指定了开始过程、存疑过程、撤销过程和验证过程，这些过程在系统恢复阶段(稍后描述)被激活。如果在这些字段中没有标识特定的过程，则利用由扩展资源管理器ERM所实施的缺省过程；反之，如果指定了特定的过程，则激活这些过程以替代缺省过程。

字段SYS REC MODE指定了商务请求管理器BRM和扩展资源管理器ERM将采用的系统恢复/任务恢复逐步升级(escalation)范例(稍后描述)，用于对对应系统的错误操作或不可用性(unavailability)做出反应。还是在这种情况下，可以定义缺省范例，如果在栏目中没有提供特定的信息，则采用该缺省范例。

字段TO指定了超时时间，即连接器(和扩展资源管理器ERM)被授权等待来自对应系统的回复的最大时间；如果经过了超时时间而未接收到回复，则该操作被分类为存疑。

字段USAUT/ACC和MSGFRMT包含和在栏目CAT的对应字段中包含的类似的信息；特别是，字段USAUT/ACC指定了用户和相关联的特权，用以为商务请求服务。字段MSGFRMT标识了与OBR的调用一起提供的数据的格式。

当OBR被发出时，从目录DIR(通过在栏目CAT的字段C-SYS和SUBC-SYS中指定的访问键访问)取回的信息完成从编目过程导出的执行上下文信息。当被扩展资源管理器ERM调用时，几条信息(特别是与OBR相关联的远程程序/事务处理、连接属性、超时时间、用户和消息格式)被提供给连接器；扩展资源管理器ERM直接利用有关对应系统状态、开始、存疑、撤销和验证过程，以及逐步升级范例的信息。

依靠系统配置部件，可以配置目录DIR。

日志服务LOG

日志服务LOG专门用于在专用档案文件(日志档案文件)中储存涉及系统SYS的行为的综合和详细的信息，包括资源管理器协调器RMC和资源管理器RM、商务请求管理器BRM和扩展资源管理器ERM所执行的操作。被储存的信息提供了所发生的事件在逻辑上一致的视图，当需要补偿行为时可以使用所述视图。

储存在日志档案文件中的信息由商务请求管理器BRM或扩展资源管理器ERM在涉及到的不同底层部件的商务请求的处理和/或补偿期间，显式地提供。

日志服务LOG作为资源管理器，在资源管理器协调器RMC的协调之下工作。数据被商务请求管理器或扩展资源管理器提供给日志服务；资源管理器协调器协调日志服务，与其他的资源管理器类似。日志服务确定商务请求管理器或扩展资源管理器接收到的信息相应于任何UOW要被如何处置：如果给定的UOW被提交，则相应于该UOW储存在日志档案文件的信息被固定；如果UOW被撤回，则相应于该UOW储存在日志档案文件的信息对于可能的补偿行为是可用的。商务请求管理器或扩展资源管理器所提供的信息被用涉及到上下文的信息(例如工作单元、状态信息、工作单元完成代码)完成，在该上下文中执行UOW。

为了允许对储存在日志档案文件中的信息的快速访问，日志服务逻辑地组织储存在日志档案文件中的信息。具体来说，信息按照EXT-UOW、EXT-UOW的UOW、实施UOW的任务、商务请求、在商务请求中调用的OBR和OBR指向的对应系统来组织。利用了EXT-UOW、UOW、任务、商务请求、OBR和对应系统的标识符代码。

当接收到商务请求时，事务处理管理器TM激活由程序实施的任务，事务处理在任务中运行。事务处理管理器把UOW与任务相关联，给其分配单意标识符代码。如果商务请求被商务请求管理器拦截，则为其分配单意标识符代码。如果在商务请求内发出了OBR，则为其分配单意标识符代码。所有这些单意标识符代码被提供给日志服务。

依靠日志服务，每一个服务请求的详细的历史(完成的、因为未定或被延迟而还未完成的)可以被确定，包括显式或隐式的补偿行为。

在为服务请求服务期间的错误或存疑状况的情况下，上下文信息(或者由扩展资源管理器提供，和/或由日志服务直接收集)被储存在日志档案文件中，要被用于后续的细化和/或评估任务/系统恢复服务。

转向前面所列出的调用格式，在OBR被调用的时间，单个OBR请求能够被特定用户数据ANNL伴随，也能够被日志(LOG)服务储存。变成了OBR调用上下文的一部分的这些用户数据也可以被用于后续的、由任务恢复服务和系统恢复服务进行的细化和/或评估，对于XBR过程可用，或被直接地提供给连接服务CNCT。

日志服务处理锚定点(anchor point)，用于标识EXT-UOW、UOW、任务还未完成。当EXT-UOW被完成时，在EXT-UOW的执行期间带给资源的改变被提交之后，或在补偿操作以后，达到一种状况，涉及那个EXT-UOW的锚定点被删除；以这种方式，有可能在任何时间，很容易地确定哪一个行为正被执行、被暂停或等待被完成。

在补偿阶段，被接收或捕获、并且储存在日志档案文件中的信息使得能够如期地确定用于达到动态确定的一致状态所需的操作序列。这时，此信息还可以被XBR部件或被连接服务CNCT混合和/或重新安排，以便组成XOBR输入消息。缺省时，不存在加给所涉及的XBR或连接器的任何商务逻辑，由缺省XBR建立的XOBR输入消息可以是下列(由储存在栏目和/或栏目中的信息导出)其中之一：

-原始OBR输入消息；

-OBR回复消息；

-在OBR调用时间提供的数据CTXT/ANNL；

-包括数据IN/OUT/CTXT/ANNL的多段数据。

更具体地，储存在日志档案文件中的数据依赖于所涉及的部件和商务请求的性质，如下表所述：

商务请求类型	储存在日志档案文件中的数据
		不调用OBR的NCBR和NPCBR	-错误或错误操作；-次级PCBR或NPCBR的调用
调用OBR的NCBR和NPCBR	-错误或错误操作；-次级PCBR或NPCBR的调用-OBR的调用；-调用的每一个OBR的逻辑结果；-每一个被调用的OBR的提交请求和相关的结果；-每一个被调用的OBR的撤销请求和相关的结果；
		调用OBR的PCBR	-调用消息；-调用回复消息和相关的结果；-错误或错误操作；

	-次级PCBR或NPCBR的调用-OBR的调用；-调用的每一个OBR的逻辑结果；-提交请求和相关的结果；-撤销请求和相关的结果；
		NROBR	-连接器激活消息，或到OBR的输入消息；-连接器激活回复消息或来自OBR的输出消息；-连接器所产生的OBR的逻辑结果，或底层结果；-错误或错误操作；-存疑解决行为结果(如果有的话)
EROBR和IROBR	-连接器激活消息，或到OBR的输入消息；-为支持补偿操作所提供的上下文信息(如果有的话)；-连接器激活回复消息或来自OBR的输出消息；-连接器所产生的OBR的逻辑结果，或底层结果；-错误或错误操作；-存疑解决行为结果(如果有的话)
		XBR	-XBR调用消息(调用时提供给XBR，包括到对应商务请求的输入信息和由对应商务请求产生的输出信息)；-XBR调用回复消息和相关的结果；-错误或错误操作；-XBR对XOBR的调用；-调用的每一个XOBR的逻辑结果；

	-提交请求和相关的结果；-撤销请求和相关的结果
		XOBR	-连接器激活消息(包括当调用相关联的OBR时提供给连接器的信息)；-连接器激活回复消息或来自XOBR的输出消息；-连接器所产生的XOBR的逻辑结果，或底层结果；-存疑解决行为结果(如果有的向话)

错误恢复服务ERR

错误恢复服务ERR专门用于控制由于在应用或底层中的错误操作所致的错误状况。在系统启动时，以及在指向事务处理或程序的服务请求的执行期间发生错误的时候，此服务由事务处理管理器TM激活。

在激活错误恢复服务ERR之前，涉及到的所有应用或底层部件试图自发地处理错误状况，以便解决它，或者发出适当的信号。总的来说，不需要向事务处理管理器TM声明任何错误；错误状况可用被降级为应用错误，并由各个应用来处理。

如果错误状况持续(或者是因为应用不能处理错误状况，或者是因为错误状况不能被降级)，则事务处理管理器TM激活错误恢复服务ERR。错误恢复服务ERR，在导致该错误状况的任务的UOW内，分类并处理该错误状况；上下文信息被日志服务LOG存档在日志档案文件中；此信息对任务恢复服务TR和商务请求保护服务PR可能是有用的。

具体来说，所获得的信息涉及商务请求管理器BRM和扩展资源管理器ERM的逻辑状态(确定错误状况的处理)、在执行中的行为的种类(正常处理、撤销、补偿、存疑解决、系统恢复、任务恢复)、涉及到的部件的类型、错误的种类以及它是如何被产生的。

错误恢复服务ERR确定要执行的操作，采取下列操作之一：

a)  确认错误状况，并把控制返回给事务处理管理器TM；事务处理管理器自动地激活撤销过程，该撤销过程由资源管理器协调器RMC管理；

b)  任务恢复服务TRS激活任务恢复过程，用于收集和组织扩展资源管理器ERM将要使用的信息；然后，控制被返回给事务处理控制器TM，其自动地激活撤销过程，该撤销过程由资源管理器协调器RMC管理；然后，资源管理器协调器将调用扩展资源管理器ERM，其将执行支持可能的补偿行为的操作；

c)  任务恢复服务TRS激活任务恢复过程，并阻止错误处理过程；控制被返回给事务处理管理器TM，用于自动地激活由资源管理器协调器RMC管理的提交过程；这样，错误状况不被事务处理管理器处理。

错误恢复服务ERR不直接成为隐式或显式补偿阶段的一部分；这些活动由扩展资源管理器ERM管理，和其他的资源管理器RM类似，在服务请求的执行期间所发生的改变的撤销阶段，由资源管理器协调器RMC激活。

在a)和b)情况中，将执行撤销；撤销可能涉及到补偿过程，其可能先于补偿过程。

对于情况b)和c)，为了保证即使在应用或底层错误操作的情况下，负责管理推迟的补偿行为的商务请求管理器BRM和扩展资源管理器ERM也被适当地激活，错误恢复服务ERR总是在存在PCBR、XBR和XOBR时，激活任务恢复服务TRS。

UOW保护服务UOW-P

此服务确保UOW的完整性，在此条件下，在服务请求的处理中运行一个或多个应用程序。利用日志服务LOG，UOW保护服务UOW-P拦截由在商务请求的处理中涉及的应用发出的显式的提交和撤销请求，阻止提交命令的执行；撤销命令被执行，并通知给商务请求管理器BRM和扩展资源管理器ERM，并被使得对任何其他的应用或部件可用，以便允许可能的失调导致的推迟处理。

具体来说，UOW保护服务防止显式的提交命令在COO-UOW或EXT-UOW的情况下被执行，从而避免了它的分裂(fragmentation)；在撤销命令的情况下，该命令被执行，并且UOW保护服务通知商务请求管理器和扩展资源管理器。这样，UOW保护服务保护了COO-UOW和EXT-UOW的完整性，保障所有为服务请求所执行的操作仅受到一致的和不分裂的UOW的支配。这样，仅仅在处理结束，在输入消息获取、消息处理、回复输出消息产生阶段完成之后，每一个行为才被隐式地视为完成。

感谢UOW保护服务，商务请求管理器BRM保证每一个服务请求被单意地处理，并产生单意的回复，避免了输入/输出消息的丢失，和/或产生多个回复消息。

在这种情景中，当部件(与商务请求管理器和扩展资源管理器不同)发出显式的提交请求后，处理被拦截，并且错误状况被通知给事务处理管理器；错误状况被错误恢复服务拦截，错误恢复服务将如前面所描述的那样，处理错误状况。当部件发出显式的撤销请求时，该命令被执行，但是UOW保护服务向商务请求管理器和扩展资源管理器通知撤销事件，以便该事件被在任务终结阶段期间被后续处理。

任务恢复服务TSR

此服务负责处理任务恢复过程。

在用于处理商务请求的通用任务(未定的任务)的执行期间，可能发生被错误恢复服务ERR处理的错误，或者是被资源管理器协调器RMC协调的撤销请求。在这两种情况中，都激活任务恢复过程：在第一种情况下，如前面所描述的那样，由错误恢复服务ERR，在第二种情况下，由扩展资源管理器ERM，依次由资源管理器协调器RMC激活。

任务恢复过程还在系统故障或关闭之后的系统恢复过程(稍后描述)中的系统SYS启动时被激活，以允许标识商务请求的商务请求管理器和扩展资源管理器被激活或被再激活。特别是，商务请求管理器标识和启动/重新启动先前未定的或在等待的PCBR，而扩展资源管理器标识和启动/重新启动先前未定的或在等待的补偿商务请求(XBR)。为达到此目的，任务恢复服务把从日志服务LOG获取的信息与资源管理器协调器RMC提供的信息(用于未定的任务和用于未决补偿任务)合并，以收集(为每一个单个任务)恢复阶段必需的信息，在恢复阶段中，将涉及到扩展资源管理器。

在任务恢复过程期间，储存在日志档案文件中的数据被分析，以便为每一个单个任务标识当前的UOW，以及为每一个被标识的UOW标识相关的状态和涉及到的资源。

在此操作后，获得了先前未定的或未决的PCBR的完整列表，这些PCBR必须由商务请求管理器再激活，并且，对于扩展资源管理器，获得了用于补偿任何先前未定的商务请求的XBR/XOBR的完整列表和补偿未决商务请求的列表。

PCBR立刻由商务请求管理器再激活；EROBR的激活则被推迟到补偿阶段(如果有的话)完成之后。

扩展资源管理器依据编目服务CAT和目录服务DIR所提供的信息，或者在单个UOW的层次上激活补偿任务，或者在单个对应系统的层次上彼此连续地激活补偿任务。

系统恢复服务SYS-R

此服务处理系统恢复过程(示意性地在图6中示出)，该系统恢复过程在系统SYS启动时，针对目录服务DIRS所拥有的表DIR中定义的每一个对应系统被实行。在系统恢复过程中，主要涉及扩展资源管理器，尽管只要与PCBR有关，商务请求管理器也被部分地涉及到。

系统恢复过程允许在系统SYS和对应系统之间，例如系统C-SYS1、C-SYS2之间，建立单意同步点，从该点开始进行后续的服务请求的执行。

此外，当异常事件与一个或多个对应系统有关联地发生时，系统恢复服务还激活系统恢复过程；这样的异常事件，或者被应用部件拦截，或者被底层服务(扩展资源管理器)拦截，可能使得有必要将系统SYS与对应系统重新调校(re-align)，以建立一致点。在这种情况下，系统恢复过程被仅仅相应于其中发生了异常事件的对应系统选择性地实行。

系统恢复过程的目标是使对应系统的逻辑状态(根据目录DIR中的字段C-SYS、ST-UP STAT和SYS IN-FLGT STAT，对系统SYS来说是已知的)进入开(ON)，指示对应系统是可操作的，按照预定的步骤序列；为实现它，如果有必要，可以由扩展资源管理器将系统和应用功能都激活。

具体来说，系统恢复过程包括下列步骤：对应系统沉寂(counterpartsystem quiesce，在下面被简称为C-SYS QUIESCE)，对应系统停止(counterpartsystem stop，C-SYS STOP)，对应系统开始(counterpart system sign-on，C-SYSSIGN-ON)，对应系统存疑(counterpart system in-doubt，C-SYS IN-DOUBT)，对应系统撤回(counterpart system backout，C-SYS BACKOUT)，对应系统验证(counterpart system verify，C-SYS VERIFY)，对应系统就绪(counterpartsystem ready，C-SYS READY)。下面将先详细地讨论这些步骤。

在C-SYS QUIESCE步骤，扩展资源管理器ERM在逻辑上废能对应系统，把目录DIR中的各个状态设置为QUIESCE。以这种方式，指向对应系统的任何可能的新的商务请求被拒绝(如果是非受保护的)或推迟(如果是受保护的)，直到对应系统被扩展资源管理器返回到就绪(开，ON)状态为止。然后，等待由商务请求管理器或扩展资源管理器管理的、涉及对应系统的任何未定的操作的完成。

如果此步骤不能被成功地完成(例如，因为存在涉及到对应系统的未定的事务处理，所以不能被完成)，则整个系统恢复过程被推迟一个时间间隔，该时间间隔在目录DIR中定义(在超时时间字段TO)。在该时间间隔已经过去后，系统恢复过程被再次激活。

在C-SYS STOP步骤，在C-SYS QUIESCE步骤的成功结果的情况下进入此步骤，扩展资源管理器强迫对应系统的状态为目录DIR中指定的STOP。当对应系统的状态为STOP时，保证没有涉及该对应系统的行为正在系统SYS中运行；STOP状态还声明，对应系统不能用于处理服务请求。UOW的补偿被中断，并被推迟到后续的C-SYS BACKOUT步骤。对应系统的状态被自动地强迫为SIGN-ON。

对应系统还可以被系统SYS的系统管理器部件的命令强迫到STOP状态；在这种情况下，对应系统仍处于STOP状态，直到系统恢复过程被成功地再激活。

在C-SYS SIGN-ON步骤，系统SYS建立到对应系统的逻辑链接和/或与对应系统的一致点。基于目录DIR中的信息(字段SIGN-ON)，预期用于为该对应系统管理此行为的预定开始过程被标识，并被激活。如果在针对该对应系统的目录中没有特定的开始过程被声明，则扩展资源管理器执行缺省动作，由连接服务(即连接器部件)实施。被标识的开始过程可以要求对扩展资源管理器ERM的服务；这些具有NROBR形式的服务实行了下列阶段：使得系统SYS被对应系统标识(利用保护在目录字段USAUT/ACC中的信息)，协商对应系统资源，对应系统将必须分配这些资源，用于支持来自系统SYS的服务请求，获取/协商将来的OBR的标识代码。OBR标识代码可以仍在应用域(即，它们仅在连接器层已知)，或被向扩展资源管理器声明，以便随后被自动地与将来的OBR相关(在日志档案文件层)，将来的OBR指向对应系统；对于每一个OBR，调用服务的应用从而能够向扩展资源管理器ERM声明与被调用的服务请求相关联的标识符代码，并向接收到的回复声明，以便允许激活消息、回复消息和在对应系统上执行的任务之间的自动相关。

C-SYS SIGN-ON步骤的成功结果涉及到在目录DIR中指定的对应系统的状态的自动转换(从SIGN-ON到IN-DOUBT)。在不成功的结果的条件下，整个系统恢复过程被推迟了一个时间间隔，该时间间隔在目录DIR中的超时字段TO中定义。

在C-SYS IN-DOUBT步骤，从对应系统中出现的可能的存疑状况被检测到并被解决。存疑状况是扩展资源管理器还不能获取或单意地解决相应于对应系统所发出的通用OBR/XOBR的结果的那些状况。存疑状况的解决对成功的C-SYS BACKOUT步骤是必不可少的，在C-SYS BACKOUT步骤期间，未被解决的或暂停的UOW将被分析和细化，这些UOW与产生过错误的可恢复OBR相关联。例如，如果对应系统关闭，或到其的通信链接在OBR的执行期间断开，则扩展资源管理器将OBR看作存疑，直到对应系统的状态被确定为止(在C-SYS SIGN-ON步骤)。

存疑状况的解决为确定异常状况中所涉及的每一个OBR/XOBR的结果，以及获取依据上下文产生的回复消息(如果有的话)作了准备。通过异常状况，期望防止扩展资源管理器获取回复消息的任何事件：异常状况可能是在OBR/XOBR的处理中的故障所致，或是由对应系统引起的通用错误所致。

在目录DIR中存在的信息的基础上，用于管理存疑状况的解决的特定过程被标识和激活；如果没有标识特定的过程，则扩展资源管理器执行由连接服务所提供的缺省动作。为了存疑状况的解决，可用利用在C-SYS SIGN-ON步骤所协商的OBR/XOBR标识代码。

如果扩展资源管理器在日志档案文件中存在的信息的基础上能够确定，操作是否已经在对应系统上被执行，哪一个是结果，以及哪一个回复消息已经被产生，则认为存疑状况被解决。依据负责管理与对应系统的连接的连接器(例如在目录字段CNCT ID中指定)，为扩展资源管理器提供了用于解决存疑状况的不同模式；例如，使用OBR/XOBR标识符代码，连接器可以询问对应系统，以便知道对应系统所执行的最后操作，或者，如果OBR/XOBR已经被执行，当显式请求时，对应系统可能能够回复“完成”或“未完成”。

C-SYS IN-DOUBT步骤的成功结果引起对应系统的状态从IN-DOUBT自动改变到BACKOUT。在不成功的结果的情况下，整个系统恢复过程被推迟一个时间间隔，该时间间隔在目录中定义。当系统恢复过程被在所有的对应系统上执行时，并且存疑状况仅能针对一些对应系统被解决时，这些前进到下一步。

在C-SYS BACKOUT步骤，扩展资源管理器标识未决或未解决的UOW，这些UOW涉及相应于对应系统所发出的OBR。一旦这些UOW被标识，则尝试或不尝试其补偿，取决于编目服务CATS和目录服务DIRS所提供的信息。具体来说，对EROBR尝试补偿，而对于IROBR，不尝试补偿；此外，在栏目字段ST-UP STAT、IN-FLGT STAT中定义的XOBR的状态被验证：如果状态是关(OFF)，则不发出XOBR。

补偿任务的激活在任务恢复过程中发生，由任务恢复服务TSR管理。

每一个UOW被补偿的方式在下列变量的基础上确定：

-系统恢复过程激活的原因(系统SYS启动，或异常或存疑状况的发生)；这从系统SYS和调用系统恢复过程的部件的状态确定；

-系统SYS的重启动模式(冷或热)；

-在UOW中涉及到的每一个OBR的补偿形态(隐式的或显式的)；

-在任何单个UOW中涉及到的对应系统，以及处理恢复操作和问题逐步升级范例(ASYS、SSYS等)的各个形态；

-清除UOW/OBR的可能的单边命令，通过系统管理器部件发出；

-OBR的每一个补偿步骤的结果：依据先前的补偿步骤的结果，补偿行为可以继续、稍后被暂停和继续、被中断或被提早完成。

这些变量被分等级的获取：每一个OBR的属性(在栏目CAT中指定)从属于对应系统的属性(在目录DIR中指定)，并且，最高优先权被分配给通过系统管理器部件所强迫的所有内容。以这种方式，补偿过程被处理的方式可以被区分开来，以便使能较宽范围的行为，这些行为涉及控制和/或克服异常事件。

UOW可以包括NROBR、EROBR、和IROBR。通常，NROBR是查询服务请求，而不受显式补偿。

只要关于只具有EROBR的UOW，当所有的EROBR已经被补偿时(依靠XOBR)，认为它们被补偿过了。提供了下列补偿形态：

-ASYS形态：UOW的所有未决的OBR被以和原始执行次序相反的次序进行补偿；每一个补偿步骤受前一个补偿步骤的应用结果的影响。当由扩展资源管理器动态确定的序列被成功的完成时，声明UOW被解决。当所有相关的UOW被解决时，对应系统从BACKOUT状态变到VERIFY状态。在这个阶段检测到的不成功的结果或错误状况引起补偿过程暂停或中断；在这种情况下，UOW中涉及到的对应系统被声明出错，并且不能通过C-SYSBACKOUT步骤，除非发生了通过系统管理器部件的干涉，或者问题逐步升级序列被定义在目录DIR中(引起进入“SSYS”、“BSYS”或“BERR”形态，在后面描述)。

-“SSYS”形态(在系统重启动时间施加的缺省形态)：根据OBR指向的对应系统，对UOW的未决OBR进行分组；每一组OBR都以和原始执行次序相比相反的次序经受补偿，从属于每一个操作的结果。在由扩展资源管理器动态确定的序列成功地完成后，认为每一组OBR被解决。当所有组的OBR被成功地完成后，声明UOW被解决。然后，对应系统转到C-SYS VERIFY步骤。在这个阶段检测到的不成功的结果或错误状况引起补偿序列暂停或中断；在这种情况下，对应系统被声明出错，并且不能通过C-SYS BACKOUT步骤，除非发生了通过系统管理器部件的干涉，或者问题逐步升级序列被定义在目录中，导致转到“BERR”形态。

-“BSYS”形态：UOW的所有的未决OBR被以和原始执行次序相比相反的次序进行补偿，并且每一个补偿步骤从属于前一个补偿步骤的应用结果。当由扩展资源管理器动态确定的序列成功地完成时，声明UOW被解决。如果不成功的结果或异常事件发生，则序列被修改，以便推迟所有指向和引起不成功的结果的OBR相同的对应系统的OBR的补偿；这样的对应系统被声明出错，并且不能通过C-SYS BACKOUT步骤，除非发生了通过系统管理器部件的干涉。没有被声明出错的对应系统可以转到下面的C-SYS VERIFY步骤。

-“BERR”形态：在此形态中，补偿按单个操作进行，而不是按单个对应系统进行。UOW的所有未决OBR被以和原始执行次序相比相反的次序补偿，并且，每一个补偿步骤被独立于前一个补偿步骤的结果执行。当由扩展资源管理器动态确定的补偿步骤的序列成功地完成时，声明UOW被解决。如果一个补偿步骤给出了不成功的结果，或者发生了异常事件，则所涉及的OBR的补偿被推迟，并且，序列中下面的OBR得到了补偿。与出错的OBR相关联的对应系统被声明为出错，并且不能通过C-SYS BACKOUT步骤，除非发生了通过系统管理器部件的干涉；否则，对应系统转到下面的C-SYS VERIFY步骤。

对只包括IROBR的UOW，不采取直接的补偿操作；补偿被推迟到发出了NROBR或IROBR的商务请求的后续再激活。所有相关联的UOW被暂停。所涉及的对应系统可以转到下面的C-SYS VERIFY步骤。

只要关于EROBR，包括EROBR也包括IROBR的UOW经受前面描述的补偿的影响，而对于IROBR，不采取直接的补偿操作。如果所有的EROBR被成功地解决，则声明UOW被补偿或被暂停；在发生严重的异常的情况下，UOW被声明为错误。如果没有发生错误，IROBR的补偿被推迟到发出它们的商务请求的下一次再激活，如上面讨论的那样；所涉及的对应系统可以转到C-SYSTEM VERIFY步骤。出错的EROBR的存在使得补偿操作被推迟，并且相关联的对应系统不能转到C-SYS BACKOUT步骤，除非发生了通过系统管理器部件的干涉。

当所有的撤销操作被完成时，即，所有的未决UOW被解决或被系统管理器的干涉强迫，或者，如果不存在具有未决的OBR的未决UOW，这些未决的OBR的显式补偿要由对应系统执行，则对应系统可以转到C-SYSVERIFY步骤。不能转到C-SYS VERIFY步骤的对应系统受到C-SYSBACKOUT步骤的推迟的再激活的影响；如果再次产生了不成功的结果，则整个系统恢复过程被推迟一个时间间隔，该时间间隔在目录字段TO中定义。

在C-SYS VERIFY步骤，系统SYS验证相应于对应系统或OBR指向的系统被执行的操作的逻辑一致性。在储存在目录字段VER中的信息的基础上，用于管理C-SYS VERIFY步骤的特定过程(验证过程)被标识和激活。验证过程可以要求对扩展资源管理器的服务(具有NROBR的形式)，用于实行验证操作；这些操作可以包括：获取/协商指向对应系统的OBR的标识符代码，和把获取到/协商的标识符代码和在C-SYS SIGN-ON步骤获取到/协商的标识符代码进行比较，以验证系统SYS和对应系统仍是调校的(aligned)。或者，OBR标识符代码的获取/协商可以不在C-SYS SIGN-ON步骤实行，而仅在此步骤执行。每一个OBR可以向扩展资源管理器声明与请求和/或接收到的回复相关联的标识符代码，以便使能带有BRID的标识符代码的自动关联，或者接受由扩展资源管理器所实行的自动关联。如果在目录DIR中没有声明特定的过程，则扩展资源管理器进行缺省的操作，这些缺省操作由连接服务实施。

C-SYS VERIFY步骤的成功结果确定了对应系统的状态的自动转换，从VERIFY状态转换到READY(开，ON)状态。在不成功的结果的情况下，整个系统恢复过程被推迟预定的时间间隔，该时间间隔在目录字段TO中指定。

在已经确定了用于管理应用业务的对应系统的可用性之后，进入C-SYSREADY阶段，应用业务由通用OBR和XOBR形成。当达到READY状态后，对应系统的目录字段C-SYS IN-FLGT STAT被设置为开(ON)，并且对应系统处理全部新发出的OBR和任何等待被执行(因为先前被推迟，现在被扩展资源管理器再次请求)的内容；扩展资源管理器重新开始PCBR，这些PCBR仍在等待，或者因对应系统的不可用性而在先前被推迟了。具体来说，OBR被扩展资源管理器ERM转向到与对应系统相关联的连接器(在目录字段CNCT ID中指定)，并被监视器和日志服务监视。在错误的情况下，扩展资源管理器处理可能的补偿行为，该扩展资源管理器由资源管理器协调器RMC协调。对应系统仍处于READY状态，直到系统恢复过程的再激活，或者直到对应系统被通过系统管理器部件强迫到STOP状态为止，系统恢复过程的再激活由严重的错误操作、存疑情况、对应系统的不可用(例如因对应系统/链接故障所致)触发。

商务请求保护服务BRPR

商务请求管理器BRM利用此服务，用于自动地再激活PCBR。具体来说，此服务管理商务请求排队。

商务请求验证服务BRVR

商务请求管理器BRM利用此服务验证没有在无意中对同一个商务请求响应一次或多次，该商务请求与还未完成的PCBR不同。在编目服务CAT提供的信息的基础上，此服务能：使能任何情况下商务请求的处理(缺省状况)；中断商务请求的处理；如果因通用错误状况所致，先前的尝试被中断，则使能商务请求的处理；响应商务请求，返回先前的结果/回复消息。商务请求的标识可以是对上下文敏感的(输入消息数据)，或者是基于一个唯一的用户标识符，该用户标识符在商务请求被发出时与其相关联。

扩展资源管理器ERM也利用商务请求验证服务，用于在IROBR被再激活时管理它们。

连接服务CNCT

此服务包括多个连接器部件，扩展资源管理器ERM利用这些部件，用于和所需对应系统建立连接链路。在储存在栏目CAT和目录DIR中的信息的基础上，不时地确定合适的连接器。连接器执行几个功能，特别是管理系统SYS和对应系统之间的通信；连接器还可以执行通信协议和消息格式的转换。

具体来说，连接器输入和输出信息为：

a)  OBR调用的情况(导致连接器激活的操作序列是BRcall-＞ERM＞CNCT-＞OBRAPPLexec)：

连接器输入：目录数据、OBR ID、[OBR标识符/计数器]、[CTXT数据]

连接器输出：OBR回复消息、物理/逻辑结果、[OBR标识符/计数器]；

b)  XOBR调用的情况(导致连接器激活的操作序列是ERMcall-＞XBRcall-＞ERM-＞CNCT-＞XOBRAPPLexec)

连接器输入：目录数据、XOBR ID、XOBR输入数据、OBR输入/回复/结果数据、[OBR CTXT/ANNL数据]、[XOBR/OBR标识符/计数器]、[先前XOBR输入/回复/结果]

连接器输出：XOBR回复消息、XOBR物理/逻辑结果、[XOBR标识符/计数器]；

c)  在系统恢复过程的C-SYS SIGN-ON、IN-DOUBT和VERIFY步骤中的调用的情况(导致连接器激活的操作序列是：ERMcall-＞[目录中的UserProg-＞]CNCT＞[OBRAPPLexec])

对于在C-SYS SIGN-ON和VERIFY步骤中的调用：

连接器输入：目录数据、[本地OBR/XOBR标识符/计数器]

连接器输出：物理/逻辑结果、[协商的OBR/XOBR标识符/计数器]

对于在C-SYS IN-DOUBT步骤中的调用：

连接器输入：目录数据、OBR/XOBR：输入数据、[标识符/计数器]、[CTXT/ANNL数据]，

连接器输出：OBR/XOBR：物理/逻辑结果、[回复消息]、[标识符/计数器]

其中，方括号中的数据是可选的。

监视器服务MON

此服务拦截向事务处理器管理器发出的命令，并把命令路由到商务请求管理器；商务请求管理器BRM利用编目服务CAT来确定哪一个底层部件(商务请求管理器自身、用于OBR的扩展资源管理器，或者用于NCBR的事务处理器管理器)将处理此命令。

下面将讨论事务处理器管理器TM的操作。

当系统SYS被启动时，开始系统启动过程。系统启动过程激活商务请求管理器BRM和扩展资源管理器ERM，并通知事务处理管理器TM和资源管理器协调器RMC关于这些底层部件的可用性；服务提供器子系统SER也被激活。

启动过程还从资源管理器协调器RMC获取信息，特别是未决UOW的列表。在此列表的基础上，扩展资源管理器ERM扫描日志档案文件，并产生一个矩阵，其中，对于每一个未决的UOW，所涉及的XOBR和对应系统被指示。系统恢复服务SYS-R被调用：对于在矩阵中找到的每一个对应系统，激活一个系统恢复过程，该过程将在目录DIR中指定的信息的基础上被实行。一旦针对每一个对应系统实行上文所描述的预定次序的步骤，则系统恢复过程被完成。

任务恢复服务TSR被调用：对于在矩阵中的每一个UOW，激活一个系统恢复过程；但是，任务恢复过程被推迟到在UOW中涉及到的对应系统到达状态BACKOUT(如果UOW还涉及到EROBR)或状态READY(如果UOW涉及IROBR)的时间。

利用任务恢复服务TSR，用于再激活未决的任务；任务恢复服务实行的任务恢复过程使得商务请求管理器BRM能够在储存在日志服务LOG的档案文件中的信息的基础上，标识还未完成的PCBR，这些PCBR需要被再激活。

事务处理管理器TM可以以两种模式中的任意一种启动，这两种模式传统上被称为冷或热。在冷模式中，与热模式不同，在先前的系统关闭之后仍未决的任务不被处理，因而不被补偿；系统恢复过程的C-SYS BACKOUT步骤不相应于EROBR执行。

在热启动的情况下，商务请求管理器BRM重启动PCBR，这些PCBR在先前系统关闭时还没有被完成或被排队(延迟)。扩展资源管理器ERM管理在系统关闭时还没有被完成或解决的(即存疑)OBR。

一旦系统恢复过程被完成，则系统SYS和对应系统C-SYS1、C-SYS2被同步，并且未决的商务请求可以被重新发出，而且新的商务请求可以被接受。

在系统SYS关闭时，事务处理管理器TM向商务请求管理器BRM和扩展资源管理器ERM通知此关闭。商务请求管理器BRM和扩展资源管理器ERM或者可以拒绝新的服务请求，或者把其放入商务请求保护服务BRPS管理的队列中；如果新的商务请求是PCBR，则它被接受，被放入商务请求队列，并尽快地被服务；如果商务请求是NPCBR，则它被拒绝。

商务请求管理器BRM等待处理中的事务处理被完成。扩展资源管理器ERM等待可能的补偿行为的完成，补偿行为涉及先前出错或被撤销的UOW。

如果目录DIR中对应系统的超时时间过去了，或者在系统SYS被强迫关闭的情况下，并且，在处理中的事务处理，或先前出错或被撤销的UOW的补偿行为不能被完成，在系统SYS下一次启动时，系统恢复过程和任务恢复过程被重新执行，以使商务请求管理器BRM和扩展资源管理器ERM能够重新启动PCBR和未决的UOW(假设事务处理管理器TM被以热模式启动)。

在系统SYS运行期间，如果扩展资源管理器ERM不获取和在日志档案文件中储存由通用OBR所产生的回复/结果消息，则建立起存疑状况。在任何其他行为之前，要解决存疑状况。为了取回涉及导致存疑的每一个OBR的激活和完成的信息，扩展资源管理器ERM激活与该OBR相关联的连接器(在目录DIR中指定)。

具体来说，扩展资源管理器ERM利用OBR的标识符代码来实行下列检查：

首先，扩展资源管理器确定OBR已经被激活；在反面情况下(例如，作为上述排队机制的后果)，OBR被认为没有被执行，并且激活消息(如果有的话)被删除。这样就解决了存疑状况，使得系统在必要时能够执行补偿行为；如果存疑OBR是EXT-UOW内的唯一OBR，则补偿行为将甚至是不必要的。

反之，如果确定OBR已经被激活，则扩展资源管理器确定OBR是否仍在执行中；这在发出OBR的基本任务必须遵守一个超时时间时可能发生。在这种情况下，有可能等待OBR的完成和回复消息/结果的获取，或者，OBR可以被放弃，并被声明出错，以便取消撤销阶段的OBR的结果。这样就解决了存疑状况，使得系统能够执行补偿行为，在被强迫放弃的OBR使用不可恢复的资源的情况下，需要补偿操作。

在扩展资源管理器等待OBR的完成的情况下，其逻辑结果被验证。OBR回复消息/结果可以是可用的或是不可用的，取决于为OBR的补偿采用的协议的性质。回复消息/结果的获取对简化补偿行为的确定是有用的。

如果缺少回复消息/结果，尽管OBR正式地导致被正确地执行，但是没有关于处理逻辑结果和关于处理已经如何被对应系统进行分类的信息；此信息一般被包括在回复消息中。回复消息/结果的获取允许在应用或底层内部编码的基础上，确定服务请求的逻辑结果，逻辑结果被涉及到的连接器或XBR直接拦截。在该结果的基础上，可以确定OBR是否产生了期望的结果，因而需要补偿阶段，或在故障事件或撤销请求中，不需要补偿行为。

如果不能获取回复消息/结果，则OBR自动地得到补偿，或者开始系统恢复过程。

如果OBR被放弃，并且仅涉及到可恢复资源，则不需要补偿阶段。不同的是，如果OBR使用了不可恢复的资源，则存疑状况仅被部分地解决，因为OBR所操作的改变(甚至是部分的)可能存在。在这种情况下补偿阶段是必需的，在它之前可以有一个初步的验证，验证被放弃之前由OBR部分地完成的内容。在激活与XOBR相关联的连接器之后，此状况被扩展资源管理器通知。

通过激活系统恢复过程，可用获得对存疑状况的解决的间接支持，系统回复过程包括初步的C-SYS SIGN-ON步骤和最终的C-SYS VERIFY步骤，在这些步骤期间，有可能为每一个对应系统处理对应系统和系统SYS之间的重新调校。以这种方式，指向该对应系统的OBR的标识符代码被获取到/协商；利用获取到/协商的标识符代码，有可能从对应系统获取到有关指向其/完成的最后的操作的信息，从而自动地在从对应系统取回的信息的基础上，解决存疑情况。

在存疑状况不能被自动地解决的情况下，通用用户/系统管理器可以被直接涉及，通用用户/系统管理器在已经实行了必要的检验后，提供对每一个存疑状况要被系统如何处置的指示，即：因为OBR没有导致被执行，所以存疑状况要被视为被解决了，并且不需要补偿，或者，因为OBR甚至仅导致了部分地被执行，存疑状况要被视为被解决了，并且需要补偿。

尽管存疑状况被解决的方式对不同类型的OBR是相同的，但是每一个OBR的不同的性质影响了在后续补偿阶段(如果需要这样的阶段)中的系统行为。在已经确定了OBR的执行及其结果之后，补偿操作如下：

-NROBR：这些OBR，一般和查询服务请求相关联，不受到任何补偿操作。可能的存疑状况的解决是可选的；它可能对验证整个系统的正确运行有用，但是OBR执行的检验，以及如果可用的话，回复消息/结果的获取不触发任何后续的细化(elaboration)。

-IROBR：这些OBR与查询和修改服务请求都相关联；在后者情况下，可能的存疑状况的解决是强制性的。不采取直接的补偿操作。重新细化(re-elaboration)，被发出OBR的商务请求的可能的重新细化触发，涉及扩展资源管理器在回复消息/结果的获取阶段期间所记录(logged)的所有内容的获取，或者该OBR的直接激活，被对应系统指向其重新细化，以及这样的重新细化的回复消息/结果的管理。

-EROBR：这些OBR一般涉及对资源的改变。可能的存疑状况的解决是强制性的。补偿行为在相关联的XOBR的直接激活中，或者相关联的XBR的激活中一致。

-XOBR：这些OBR由涉及到的XBR发出，并由系统像IROBR那样处置。能的存疑状况的解决是强制性的。在XOBR的执行期间产生的错误被扩展资源管理器ERM隐式地补偿，或者，在XOBR或XBR的细化流(elaborationflow)中的中断被扩展资源管理器ERM自动地处理和再激活。先前被成功地终止的XOBR被认为被执行了，而各个回复消息/结果被用于确定后续的补偿操作。未执行的XOBR被再激活，以使对应系统能够细化它们，并产生期望的回复消息/结果。XBR的激活被要被补偿的OBR通知和先前被请求/被执行的内容的通知，以及相关的回复消息/结果伴随着。XBR可以通过特定操作的直接或被推迟的执行前进到补偿阶段，这些特定操作指向档案文件或过程。

EXT-UOW的正确管理要求与在传统的事务处理管理系统中所采用的标准不同的系统资源分配标准。

为了减少在EXT-UOW情况下完整性的问题，连接服务CNCT实施对行为的排队，专门用于不时地串行化定义在每一个任务的层次上的逻辑资源。依据排队的类型和其持续时间，任务能够获取对逻辑上相关的资源的控制，并保持这样的控制，直到该任务被完成为止，或者，如果是这个情况，直到补偿阶段被完成为止。

具体来说，商务请求管理器和扩展资源管理器允许定义逻辑实体，并管理对其的访问。一旦被定义，每一个逻辑实体可以在每一个任务所请求的访问的类型的基础上，被一个或多个任务获取。依据逻辑实体的类型，并依据被请求的访问的类型，下列排他/非排他使用权(LOCK)可用被分配给任务：

-分配给一个任务的排他访问权，以及其他任务的排队；例如，该排队是“先进先出”的类型；

-分配给一个任务的在修改的排他访问权，还有被分配给其他的任务的读访问权，和任何请求改变的其他任务的排队(例如FIFO)。

每一个LOCK有效的时间可以根据逻辑实体的类型和请求服务的任务的性质改变。具体来说，提供了下列时间窗：

-TASK时间窗：任务对逻辑实体的使用权，从请求被发出的时间直到任务的末尾保持活动；

-UOW时间窗：从请求被发出的时间直到特定UOW的完成是活动的；

-EXT-UOW时间窗：从请求被发出的时间直到所有被涉及到的UOW的完成是活动的，包括可能的补偿阶段。值得指出的是，扩展资源管理器ERM把构成由系统在商务请求的处理期间实施的EXT-UOW的UOW相关，即使每一个UOW作为服从单步或两步提交协议的UOW被事务处理管理器TM和资源管理器协调器RMC已知，但是不同的UOW不被直接相关；

-系统时间窗：从请求被发出的时间直到特定远程系统的被检测到的可用性为止是活动的，包括指向这样的系统的所有可能的补偿行为的完成；

-通用时间窗：从请求被发出的时间直到显式的解除排队命令被发出为止是活动的。

事务处理处理系统的操作的例子在图7中被示意性地绘出。假设：事务处理管理系统TM接收到事务请求BR，BR在栏目中作为分类的商务请求CBR被列出。用于为该商务请求服务的任务T1被激活，涉及工作单元UOW1(UOW UOW1)。在任务T1的处理期间，输出商务请求OBR1被首先发出，指向对应系统C-SYS1、C-SYS2其中之一；用于为输出商务请求OBR1服务的任务T2在对应系统中被激活，涉及工作单元UOW2。当任务T2成功地终止时，工作单元UOW2被提交。然后，任务T1发出第二个OBR OBR2，指向同一个或另一个对应系统。在该对应系统中，任务T3被启动，处理工作单元UOW3内的服务请求。当任务3被成功地完成时，工作单元UOW3被提交。

假设：此时，资源管理器协调器RMC接收到仍未定的工作单元UOW1的撤销请求。资源管理器协调器RMC调用扩展资源管理器ERM，其将管理撤销或补偿操作，用于把系统带回到初始状态，如果有可能，或者把系统带到另一个一致状态。还假设：事务处理管理器TM接收到的商务请求在栏目中具有相关联的补偿商务请求XBR。补偿商务请求XBR被调用，使得任务T4被激活，T4与工作单元UOW4相关联。为了实行对工作单元UOW2和UOW3的补偿，先前执行的操作被以相反的次序实行。XOBR OBR-2和OBR-1被依次发出，使得在对应系统中激活各个任务T5和T6；任务T5和T6的处理涉及补偿UOW XUOW5和XUOW6。当任务T5和T6都被成功地完成时，从而XUOW5和XUOW6被提交；工作单元UOW2和UOW3已经被补偿(在这个阶段出现的任何错误状况强迫补偿阶段的中断，等待的任务T1可以被积极地推迟，或被通知该事件，或被异常终止。只有补偿行为将被推迟，新的XBR将被实例化，失败的XOBR被启动，被系统像IROBR那样处置)。这样，直到目前为止还未定的工作单元UOW1已经被撤销，并被终止。

任务T1继续处理商务请求BR，进入新的工作单元UOW7。在工作单元UOW7期间，新的输出商务请求OBR3被任务T1发出，指向对应系统其中之一；在该对应系统中，开始任务T7，用于为工作单元UOW8内的输出商务请求OBR7服务。当任务T7被成功地终止时，工作单元UOW8和UOW7被提交。这样，商务请求BR已经被服务，并且，回复消息被返回到发出商务请求BR的应用。

概括地说，本发明提供了用于开发和管理新的商务流程的方法和系统，新的商务流程服从提交/撤销协议，允许利用已经存在的过程，这些过程单独地服从或不服从提交/撤销协议。具体来说，在新的商务流程的开发中，新的商务流程的部件应该被标识(商务请求、OBR、XBR、XOBR和连接器)。商务逻辑应该被放置在商务请求层；补偿商务逻辑(如果被指定)应该被放置在XBR层或连接器层；综合逻辑应该放置在连接器层；或者，它要被分散在XBR和商务请求层；数据分析(parse)应该被放置在商务请求层，或者，如果可能，放置在连接器层；在网络底层的通信结果应该被连接器处理；并且，商务请求的逻辑结果应该由商务请求、XBR或连接器产生。

尽管已经通过实施例的方式公开了本发明，但是，对本领域熟练技术人员来说很清楚，不偏离在所附权利要求中所定义的本发明的范围，对所描述的实施例以及本发明的其他实施例的几个修改是可能的。

Claims (24)

1.一种数据处理系统，包含：

至少一个资源管理器(RM)，用于依照提交/撤销协议，管理对各个系统资源的改变，和

资源管理器协调器(RMC)，用于协调至少一个资源管理器的提交/撤销行为，

特征在于包含

过程资源管理器(ERM)，用于管理不服从提交/撤销协议的非服从过程的执行，

过程资源管理器根据述提交/撤销协议由资源管理器协调器协调，并在接收到撤销请求后，自动地确定要被执行的补偿操作的序列，以撤销在非服从过程的执行期间执行的操作，并管理所述补偿操作的执行。

2.如权利要求1所述的数据处理系统，其中，所述补偿操作的序列由一系列逆操作构成，每一个逆操作都是在非服从过程的执行期间所执行的各个操作的逆操作。

3.如权利要求1所述的数据处理系统，其中，在接收到撤销请求后，补偿操作与资源管理器的撤销行为并行执行，由资源管理器协调器协调。

4.如权利要求1所述的数据处理系统，其中，在接收到撤销请求后，补偿操作被相对于资源管理器的撤销行为而推迟。

5.如权利要求1所述的数据处理系统，其中，过程资源管理器依靠至少一个任务来管理非服从过程的执行和补偿操作的执行，所述至少一个任务与一个工作单元相关联或与多个相关的工作单元相关联。

6.如权利要求1所述的数据处理系统，包含信息记录服务(LOG)，用于记录有关于在至少一个非服从过程的执行期间所执行的操作的信息，过程资源管理器在由信息记录服务所记录的信息的基础上，自动地确定补偿操作的序列。

7.如权利要求6所述的数据处理系统，其中，所述补偿操作的序列使数据处理系统进入第一系统状态和第二系统状态其中的一个，所述第一系统状态和在由非服从过程所执行的操作之前的系统的初始状态相对应，而所述第二系统状态与初始系统状态不同，所述第二系统状态由过程资源管理器在由信息记录服务所记录的信息的基础上确定。

8.如权利要求7所述的数据处理系统，包含过程分类服务(CATS、CAT、BRM)，用于对要被执行的过程进行分类，以及用于确定过程是否是非服从过程。

9.如权利要求8所述的数据处理系统，其中，所述分类服务包含过程栏目(CAT)，所述过程栏目提供了过程类型的栏目，并且对于在栏目中的过程类型，提供用于使得过程资源管理器能够在被记录的信息的基础上，自动地确定补偿操作的序列的信息。

10.如权利要求9所述的数据处理系统，其中，所述过程类型包括第一过程类型，对于第一过程类型，在接收到撤销请求后，过程资源管理器不直接激活补偿操作的序列，而是等待后续的过程的重新开始。

11.如权利要求6所述的数据处理系统，包含过程恢复服务(TSR)，所述过程恢复服务实施了过程恢复过程，用于管理在过程的执行期间发出的撤销请求。

12.如权利要求6所述的数据处理系统，包含错误恢复服务(ERR)，所述错误恢复服务实施例了错误恢复过程，用于管理在过程执行期间发生的错误状况。

13.如权利要求12所述的数据处理系统，其中，所述错误恢复过程依赖于由信息记录服务所提供的信息。

14.如权利要求13所述的数据处理系统，其中，所述错误恢复过程包含执行过程恢复过程。

15.如权利要求1所述的数据处理系统，其中，非服从过程包含下列过程中的至少一个：在至少一个不同的数据处理系统(C-SYS1、C-SYS2)上运行的过程，和在数据处理系统上运行，但是不服从提交/撤销协议的过程。

16.如权利要求15所述的数据处理系统，包含系统恢复服务(SYSR)，所述系统恢复服务实施了系统恢复过程，用于在数据处理系统和至少一个不同的数据处理系统之间建立同步点。

17.如权利要求16所述的数据处理系统，其中，所述系统恢复过程被过程资源管理器调用。

18.如权利要求17所述的数据处理系统，其中，所述系统恢复过程在数据处理系统的启动时被调用。

19.如权利要求16所述的数据处理系统，其中，所述系统恢复过程包括在数据处理系统和至少一个不同的数据处理系统之间的协商阶段，所述协商阶段包含协商指向不同的数据处理系统的过程的标识信息。

20.如权利要求15所述的数据处理系统，包含由过程资源管理器利用的连接服务(CNCT)，用于管理在数据处理系统和至少一个不同的数据处理系统之间的通信。

21.如权利要求1所述的数据处理系统，包含用于管理过程的自动重新执行的服务。

22.如上面权利要求中的任何一个所述的数据处理系统，包含事务处理管理器系统(TM)，用于管理事务处理。

23.一种用于管理事务处理的数据处理系统，该系统包含：

第一事务处理管理系统，包含：

多个资源管理器，每一个负责根据提交/撤销协议，管理各个系统资源；

资源管理器协调器，用于协调资源管理器的提交/撤销行为；

特征在于包含

过程资源管理器，起到资源管理器的作用，并且由资源管理器协调器相应于要被不同于第一系统的至少一个第二事务处理管理系统实行的事务处理来协调，过程资源管理器管理被至少一个第二系统实行的事务处理的撤销行为。

24.一种把服从提交/撤销协议的服从过程与不服从提交/撤销协议的非服从过程集成在一起的方法，包含：

提供至少一个资源管理器(RM)，用于依照提交/撤销协议，管理对各个系统资源的改变，和

提供资源管理器协调器(RMC)，用于协调至少一个资源管理器的提交/撤销行为，

特征在于包含

提供过程资源管理器(ERM)，用于管理非服从过程的执行，所述过程资源管理器根据述提交/撤销协议由资源管理器协调器协调，在接收到撤销请求后，所述过程资源管理器自动地确定要被执行的补偿操作的序列，以便撤销在非服从过程的执行期间执行的操作，并管理所述补偿操作的执行。

Images