CN1119000C - 在网络上的报文传输的方法 - Google Patents

Abstract

在应用程序间确保既不丢失也不重复发送信息的方法。该方法利用异步报文排队法。将队列管理程序100定位于各网络计算机，以控制从/到计算机的发送，待发送至不同队列管理程序被置于特定发送队列(120)。至相邻队列管理程序的发送包括靠本地队列管理程序从发送队列获取报文并将它们作为同步点管理控制工作单元内的成批报文进行发送的过程(130)。靠接收队列管理程序的接收过程(150)接收报文并将其在第二同步点管理程序控制的工作单元内排成队列(180)。

Description

在网络上的报文传输的方法

本发明涉及在面向事务的数据处理网络中应用程序之间的报文安全传送，使其既不丢失信息又无须多次传送。

人们已知：对计算机系统资源(诸如数据库或文件资源)修改时要使两个或更多资源连动，不是所有的都修改，就是不作任何修改。这样，避免了资源间的彼此不一致。若一组更新操作中的一个操作无效，则其它操作也必须不起作用。将可恢复资源的一致状态变换成另一种一致状态(不必在所有中间点保持一致性)的相关操作的一个序列称之为“一个工作单元”(“unit of work”)。事务处理是对存取和更新共用数据的离散工作单元的执行。在事务执行范围内同步修改资源的一致性的逻辑点(例如在终结处)，被称为提交点(commitpoint)或同步点(见下)。一个应用程序通过宣告一个同步点或通过终止该应用程序结束一个工作单元。事务处理作为一个整体完成或全部未完成的特征称之为“原子性”(“atomicity”)。

人们已知可通过使该事务处理范围内的资源更新在事务处理完成时宣告一同步点之前保持不确定(尚未提交)来实现事务处理的原子性。也就是说，仅对没有成功完成更新的应用程序，资源更新才是固定不变且是可见的。如果事务处理未成功完成，则消除在部分执行期间已对资源所作的所有变更-即所谓重新运行(或同义地称为回退)，将这些资源恢复到与事务处理开始前所处的相一致的状态。任何一方(例如一个应用程序或资源管理程序)对该工作单元感兴趣都可在通过指示尚未准备提交宣告一同步点时引起重新运行。

在容错数据传输方面的一个共同问题是怎样确定故障发生时不确定(即还没被提交)的信息的传送达到了什么阶段，以确保既无信息丢失也不会多次发送。不是所有的事务处理系统都能记录该不确定信息状态的。

若只有单一资源管理程序(控制资源的系统软件)负责对事务处理所作的变更的托付进行调整，则称提交(commit)程序为“单一阶段”程序。单一阶段提交处理在标准正向处理中是有效的，该处理简单地包括应用或资源管理程序发出COMMIT(提交)操作指令，然后指令接收器执行该操作过程。虽可包含有一个以上的资源管理程序，但协调程序仅在同步点时一次调用一个，以指示它们或是提交或是返回。在大多数情况下，在没有误差或中断情况下进行所有资源更新的提交。然而，若出现问题(例如系统或通信链路故障)致使不是所有资源管理程序都不能提交，则这些资源可在某些提交已完成而另一些还未完成的不一致状态下结束。这些不一致状态的资源要求再同步。考虑到单一阶段提交程序的效率，由该问题引起重建非临界资源的成本是可接受的。

反之，两步阶段提交程序往往要求防止临界资源出现这种不一致。例如，作金融业务应用时为实现从一个账户至另一帐户的资金传送要对关键资源执行两项基本操作：对一个帐目记入借方和另一帐目记入贷方。重要的是确保这两项操作或者两者都生效或者两者都不生效。在同步点管理程序控制下，两阶段提交程序包括下列步骤：

1.在准备阶段，每个共享资源由同步点管理程序轮询，以判定该资源是否准备确认并完成所有变更。若所有资源指示备用状态(即，若它们成功地完成了准备阶段)，则每个资源允许提交该资源更新；

2.在提交阶段，同步点管理程序指令所有资源完成更新，否则，如果任何一个资源都不能成功地完成准备阶段，则重新运行。

该附加的准备阶段的优点在于减小了不一致的可能性，但在处理过程中仍有一个周期，在该周期时，一旦出现误差即使两阶段提交仍在资源间留下不协调的可能性。而且，存在两阶段提交减小不协调概率的成本：由于所有更新后的资源必需被锁定，以防止在工作单元持续时间内进一步更新存取，故提交处理的附加步骤表现为资源更新处理操作的大量减少(尤其在包含许多资源时)。若这些资源围绕一个网络分布，则两阶段提交要求一个分布的工作单元，导致被长时期锁定的可能性，还要求极为复杂的恢复程序。三阶段其他多阶段提交程序可被执行，以进一步减小由故障所引起不协调的时限，但每个提交准备的附加步骤有一个损失并行操作的成本。

IBM系统网络体系结构中的SNA LU6.2同步点构造[由IBM公司出版的参考资料SC31-6808，第5.3章的图象显示业务一同步点动词(verbs)]即用于协调两个或多个受保护资源之间的提交。所提出的同步点构造即为一个由一个执行同步点和运行在单一应用程序环境下的相关恢复处理组成的同步点管理程序。某些应用可在此环境下同时运行。该LU6.2体系结构支持同步点管理程序(SPM)，该管理程序负责资源调整，同步点记录和恢复。

根据SNA LU6.2结构，在阶段1和阶段2，执行提交程序，而同步点管理程序记录同步点运行记录中的该阶段。同步点管理程序还记录对一个当前被处理的逻辑工作单元的识别。这种记录过程协助同步点管理程序的资源恢复工作或当两阶段提交程序期间出现问题(例如象通信路径故障或资源管理程序中的故障问题)时进行再同步。一旦在进入两阶段提交程序之后出现此类问题，则读出该记录并进行资源恢复处理以使所涉及提交的资源处于一致状态。这两阶段提交程序要求在使用分布式工作单元的不同计算机上保持同步。

本发明的第一方面是提供一种面向事务处理的数据处理网络中的程序间相互通信的方法，其中一发送器程序负责将信息从网络的第一结点发出而一接收器程序负责在网络的第二结点处接收信息，在该两结点间待发送的信息是根据第一同步点管理程序控制的工作单元中的发送器程序发送并由第二同步点管理程序控制的工作单元接收以使发送和接收操作保持在不确定(尚未提交)直至分别分辨第一和第二工作单元为止，本发明的特点是第一和第二工作单元被逻辑地链接，从而分辨工作单元时的提交处理包括以下两者之一：

响应接收机程序对报文的成功接收，提交所述第二工作单元，将接收的肯定的确认发送给发送器程序，并响应肯定确认提交第一工作单元；或

响应未成功接收报文，重新运行第二工作单元，给发送器程序发出否认接收的信息，并响应所述否认，重新运行第一工作单元。

本发明减轻了已知单阶段提交程序在提交处理期间因故障引起资源间的不一致性而要求再同步的问题，也避免了由已知两阶段提交程序中所增准备阶段带来的不必要的资源锁定处理。

若来自接收程序的确认由于系统或通信链路故障而丢失，那么这时最好将第一工作单元保持不确定。然后检查每一个由发送和接收程序完成的“取”和“存”操作的数据记录(log records)以判定接收端已提交哪个操作，从而决定在发送端应提交哪个操作和应重新运行哪个操作。

本发明可在一计算机网络中得以实施，其中应用程序利用报文和排队来通信，其中报文排队管理程序位于网络中各计算机处，在上述发送器和接收器程序之间的传输是在各自排队管理程序之间传输。网络结点不是信息队列管理程序，就是其上定位有一个或多个队列管理程序(queue managers)的计算机系统。队列管理程序之间的信息传输包含从队列获得应用程序起始信息并发送该信息的第一队列管理程序，和接收该信息并将其放入第二队列(或由本地应用程序处理，或用于在既不是第一也不是第二队列管理程序是目的地队列管理程序情况下传送至另一队列管理程序)的第二队列管理程序。报文(messaging)和排队描述于文件“IBM报文和排序序列一技术参考”(1993年SC33-0850-01)中，并与下面本发明的一个实施例相关。

最好，每个信息发送或信息接收工作单元可包括许多报文，每次对接收(或，若被接收的报文是依次排列时，为接收和贮存)的确认可与这多个报文有关。以一批信息作为一个工作单元的这种发送方法大大提高了处理效率，因为传送连接方向(报文发送向前，接收的确认向后)仅在每一批的终点处被转向。这正是与先有技术发送方法的不同之处，先有技术方法将队列信息作为各个工作单元发送并在每次发送操作之后提交，这使得发送端的资料有可能处于与接收端资源不一致的状态，并在采用两阶段提交情况下要求每次发送之后和每次确认之后均需改变信息流的方向。这种将发送和接收程序间的信息作为应用程序间信息的一个发送阶段的成批发送还明显区别于本领域众所周知的通过应用程序的批处理过程。

这样，可作为一个批处理发送的信息可以是逻辑上不相关的并可被指定用于不同应用程序(它们可通过不同队列管理程序而起作用)，要在第一和第二队列管理程序之间作为成批发送的信息所必需的信息之间的唯一共同因素(common factor)是第二队列管理程序即为从通道上的第一队列管理程序到每个信息目的地队列管理程序的下一队列管理程序。先有技术的信息传输方法不能将指定用于不同应用程序的信息成批地传输(批处理的大小大于1)，因此不能得益于本发明所提供的处理效率。对于许多数据库系统，就计算设备而论，提交处理是处理过程中的花费较大的阶段，特别是与RAM处理相比，磁盘存取设备是昂贵的，因此人们非常期望改善提交处理的效率。

该处理最好有一提交该批处理和确认其对接收程序发送的接收的请求，因此提交处理是由通信的发送端协调的。若信息太长，以致为输送的传送连接不能一次完成时，可将信息分成多段发送。在有分段的地方，确认请求将与该程序组中最后分段有关。在接收端成功接收到批处理报文时，确认请求是通过提交接收和传送对成功接收的确认来起作用的。

就第二方面而言，本发明提供一种在面向事务处理的数据处理网络中进行程序间相互通信的方法，在该网络中，待传送报文被送至第一计算机的发送应用程序队列，然后从该队列异步地获取，并由一个接收应用程序处理，其特点是：

将报文发送至队列或从队列获取报文的每一步骤均是在报文队列管理程序控制下实现的，其中至少一个报文队列管理程序定位于网络中的每一计算机处；

待传送至本地应用程序的报文被置于由本地应用程序服务的本地队列；而

对每一个传送队列，待传送至远距计算机的远程应用程序的报文被置于本地传输队列上，用于分别发送至到达各自目的地远程报文队列管理程序通路上的下一报文队列管理程序，其中放在特定传输队列上的所有报文，(这些报文可被指定用于不同目的地报文队列管理程序)，可被送到所述下一信息队列管理程序作为同步点管理程序控制的工作单元内的批处理报文。

现将参照诸附图更详细地描述本发明，附图中：

图1是构成一个报文的数据区显示图；

图2是利用通信联系和排队互相通信的两个程序的概略显示图；

图3是根据本发明一个实施例的报文通信中所包含两个相邻计算机系统的显示及该系统实体间的相互关系；

图4是根据本发明一个实施例的应用程序之间的信息通信方法的概要流程图；

图5是根据本发明一个实施例在应用程序间通信方法中的标准正向处理期间两次处理之间的信息流程显示图；

信息队列是一种程序间通信报文，它允许程序在没有建立直接连接的情况下发送和接收应用一专用数据。在描述本发明在通信和排队网络中特定实施例以前，说明利用通信联系和排队的程序间通信的一般方法将是有益的。

正如图1所示，一个报文包括两部分：应用数据1和包含控制信息3的报文描述符2。一个信息中的应用数据是由发送该信息的具体应用来定义和供给。对该报文中的数据性质没有任何限制(例如，它可包括一位或多位串(bitstrings)，字符串，二进制整数，压缩十进制整数，浮点数)。应用程序将构成一个信息的位和字符串看作包含各有特定数据类型和含义的一系列项目。例如，若报文涉及一项金融事务处理，则第一项4可为包含帐号的四字节无符号二进制整数，而第二项5可为包括一用户姓名的二十字节字符串。这种数据称为应用数据。

一个报文除了应用数据以外还有与其相关的一些辅助数据。这是规定该信息性质的数据，并为信息排队服务所利用，以确定应怎样处理该信息。这种数据中的一些数据必须由具体用途来规定。这种辅助控制数据包含在称为报文描述符2的数据结构中。

一个报文队列是一个有名字的客体，报文在其内存储并在后来从中取出。每一队列属于一个特定的队列管理程序，负责维护该队列。一个队列管理程序可拥有许多队列，但每一队列必需有一个在拥有该队列的队列管理程序实例范围内是唯一的名称。一个报文队列不仅仅是一个栈式存储器：当报文被加到队列时，是在末端添加它们，而当从队列取出报文时，一般是从前部取出(虽然确实存在除FIFO先进先出次序以外的阅读报文的设备一例如，它对于要求恢复成高优先级的应答的报文可能是所期望的)。

报文队列的物理显示取决于环境，但可为主存储器中的一个或多个缓冲器，一个或多个磁盘文件或其他永久性存储装置，或它们中的两者结合。然而，报文队列的物理管理完全由队列管理程序完成(提供由应用(程序)所用的报文一排队设备的系统服务)，而这些细节对应用程序并不是显而易见的。应用程序可将报文队列简单地视为累积报文的“黑盒”。应用程序借助报文排队请求完成报文排队(诸如从队列取报文的MQGET和将报文发送到队列的MQPUT)。应用程序通过使用报文一排队请求获得报文排队服务，以同安装在该应用同一系统上队列管理程序(即本地队列管理程序)进行通信。

为使报文排队服务有效，在一个系统上必须至少有一个队列管理程序。也可要求一个以上的队列管理程序，例如为保持开发工程与生产工程隔开。每一个不同队列管理程序情况由其名称得知，该名称通常必须是在互连队列管理程序的网络范围内是唯一的，以使一个队列管理程序能明确识别任一已知报文应送往的目标队列管理程序。

应用程序通过答应使用特定名称的报文队列，将报文发至应用程序已答应由此读出的特定目标队列。发报文的应用程序无需明白这些队列的定位；每个应用程序仅仅同其本地队列管理程序相互作用，而且正是互连的队列管理程序的网络负责将报文移送至予定队列。由于交叉网络通信对话是建立在队列管理程序之间而不是单个程序之间，故程序与某些其他类型的程序间通信相比几乎没有网络故障损害，若处理器之间的链路发生故障，队列管理程序的工作是从故障状态恢复到原状。已生效的处理器程序不会因这类事件而暂停，即无需理会已发生过的事件。

图2表示一对一通信的简单实例中一个报文队列网络中两个通信程序间的信息流。两程序10、20在各自的队列管理程序50、60控制下通过队列30、40互相传送信息。第一程序10在程序间没有建立专用逻辑连接的情况下将信息置于第二程序的队列30上(这种信息流由图2中箭头f1，f2，f3和f4表示)。队列管理程序50、60确保信息在网络上移动，以使程序本身受保护而不受网络变化和复杂性的影响。这由图2中的网络链路70表示。在维持报文队列、处理网络故障和重新起动和围绕网络移送报文过程中所涉及的所有工作均可由队列管理程序处理。接着当其准备好而不是选择发送程序10时程序20从队列30取出报文以处理它们。为能恢复资源而通过传送报文并随之进行处理所作的任何变更被记录在恢复记录80、90中，以供于后续故障中使用。

正如图3所示，队列管理程序100可将报文贮存到一系列不同队列上。若这些报文最后要由本地应用程序处理，则队列管理程序将它们贮存在本地目的地(local destination)队列110；若这些报文最后由远距应用程序处理，则队列管理程序将它们存入称为传输队列120的专用本地队列中。传输队列含有待发送到属于远程队列管理程序的队列的报文并使该报文能在相邻队列管理程序之间的阶段中完成移送至远程队列这种报文传输配置(将在下面详述)对通信中所包含的应用程序是不可见的。正如以下将解释的，可能存在由特定队列管理程序控制的多个本地目的地队列和多个传输队列。

传输队列的报文通过队列管理程序扩展，除了应用报文(该数据由应用程序传送)外，还包括传输队列首标。传输队列首标是一种包含目的地队列名称和报文描述符的结构化(architected)描述符。有关目的地队列的报文包括应用数据和规定控制信息的报文首标。

两个队列管理程序之间的传送关系通称为信道。定义一个信道的关键因素是传输队列的名称，有关在该信道上发送或接收报文的传送处理过程或程序130，150的信息(这些处理是队列管理程序的组成部分，通称为报文信道工具-此后称MCAS)和用于传输队列上的报文要发送的目标通信协议和目标系统信息。图3中用虚线表示出一个特定信道限定和报文通信中涉及的不同数据模式实体(entities)之间的联系。每个命名的信道以发送结点和接收结点两种方式加以定义。信道名称在发送器和接收器之间传输过程中使用，以识别通往接收器的信道或用于作为请求从一特定信道发送报文的接收器信道。信道定义具有某些对所有环境是公共的信息及某些取决于操作系统环境和所用主要通信协议的信息。

队列管理程序间的报文通信是通过跨接专用信道(一个发送器130和一个接收器150)以成对方式工作的MCAS实现的。一对MCA程序使用诸如VTAMAPPC对话(session)等的传送连接170或TCP/IP连接作为传送层。以相反方向进行的报文通信量在不同信道上的发送器160和接收器140之间流动，这些信道有效地用作结点间的单向管路。有四种类型的MCAS：发送器-从传输队列取报文并将它们发至接收器或请求器；接收器-接收报文并将它们排成队列；请求器-发送单一信息，以使发送机或服务器(server)被遥控地起动；服务器-被来自请求器的一信息起动，然后成为发送器。

一个MCA130使一些报文离开(dequeues)传送队列并通过传送连接线170发送这些报文。接收MCA150将这些报文排成以报文首标命名的目的地队列180。这两种工作单元即，解除队列和排成队列的执行，使协议中任一点出现的任何故障均能被探测和纠正，致使每一报文被发送一次而且仅为一次。在目的队列离原始发送队列多于一个过渡段(hop)的情况下，接收MCA将为下一过渡段在另一发送队列上排列该报文，这为可靠存储提供了保证，并在下一连接失效情况下，必要的不同步使这第一发送阶段的工作仍可被完成。报文格式和安全移动协议独立于传送层，从而MCAs能在不同信道上支持不同的传送协议。这些通过MCA使用的记录描述如下。

一个信道可以若干不同方式起动：1.一个终端操作器可发出一起动信道(START CHANNEL)命令；2.该信道能被触发，当一报文到达传输队列上时，一发送器MCA被队列管理程序自动地起动；或3.借助网络请求一通信传输被构成在接收到来自网络的请求时，便自动起动一MCA。接收机、服务机和发送机信道也可以用这种方式构成。

在任何报文或数据能流过(flow down)一信道之前，要用的两MCAs必需首先商定它们将要进行通信的方式。这样，信道初始化包括对某些协议参数的协定，例如哪个通信方将要做任何有关控制和报头数据的必要变换。两个MCAs可在使用两种不同数据格式的系统上运行。例如，一个可用ASCII，而另一个用EBCDIC。一个可为从左到右的编码号，而另一个编码号从右到左。该控制信息的报头数据必须从发送器的表示法变换成接收机的表示法。数据在信道上的变换仅仅适用于控制信息(诸如目标队列名称，控制区长度等等)：因为当MCAs发送报文中的应用数据时，MCAs不必与应用数据相互作用，因此没有一个应用数据变换是由MCAs实现的。

在不同计算机系统的应用之间传递报文的方法包括参考图4和5所描述的下列诸步骤：

一个应用程序发送一报文至目标收报队列以便由通过发送出MQPUT命令(200)的另一应用程序进行处理。本地队列管理程序读出由报头中应用程序规定的收报队列名称并判定(210)将该报文置于何处。若收报队列是本地队列，则本地队列管理程序将报文送(220)入本地队列。在该报文可用于其他应用程序以前，必须将报文送至完成队列操作的处理单元。然后服务那个本地队列的应用程序可异步地发出MQGET(230)，以便从队列取出报文供处理之用。MQPUT和MQGET操作处于两个分离的工作单元内。

若目的地队列不承担本地队列管理程序的任务，则本地队列管理程序将报文置于本地传输队列(240)上，以便传送至另一队列管理程序。可能存在多个为每个队列管理程序所限定的传输队列，但传输队列与远距目的地队列无需一一对应。可以将待通过两个相邻队列管理程序间的所有报文(即，要从第一队列管理程序发出的，沿其各自目标收报队列管理程序方向上有一个公共最邻近队列管理程序的所有报文)置于同一传输队列中。同样可将用于报文的若干传输队列送到同一邻接接点。为限制因故障必须重发的报文数，规定了最大批量(例如为50件报文)。将报文送到传输队列的工作单元300必须在报文可用来作其他处理以前提交。

本地队列管理程序(或一终端用户)引起发送程序MCA将报文发送至下一队列管理程序。然后发送程序MCA从由该队列管理程序拥有的传输队列获得报文(250)(发出MQGET)并将它们成批发送到在目的地队列管理程序或队列管理程序的通路上的下一队列管理程序。每个报文或是以一个传输段发送或是以多次传送方式发送此时报文规格太大以致为发送所作的传送连接不能一次完成(例如报文可能为4兆字节长而最大传送规格为32千字节。获取和发送报文的这些步骤是在同步点管理程序控制的处理单元330中执行，在此阶段，通过发送程序保持其不确定。规定资源更新的不确定状态(in-doubt state)被写入运行记录。该批处理程序组具有为确认对该程序组接收而附加其上的请求：这是通过该程序组的最后报文(或上一报文的最后传输段)在其传输段首标中设有一请求确认控制标记来实现的。

每一报文有一与其相关的报文序号-单值递增的序号之一，唯一指配给一信道上的一个应用报文。报文序号用于当链路故障或程序故障时使发送程序与接收程序之间恢复同步。该程序组中的最高报文序号取作逻辑处理单元标识符(LUWID)-定义在同步点管理程序控制下的一信道上一批报文的唯一值。

接收机MCA接收(260)报文，接收机队列管理程序判定(210)各报文要发往何处(如先前发送队列管理程序的做法一样)。接收机队列管理程序将报文放在(利用MQPUT)同步点管理程序控制的工作单元360内，以将属于接收计算机系统的队列管理程序排成队列，该队列可以是对一特定报文的实际应用的限定目的地队列或与目标系统的下一行程相关的传输队列。

由MCAs传送的报文程序组中的所有报文或被成功接收并由接收队列管理程序排队，或该程序组整个被拒收并且不被安全存贮在接收机(工作单元被返回)。若程序组被成功接收和排队，则接收机发送接收和贮存的应答信号(发送指示“无误差”的状态段)，该应答信号记录LUWID并提交报文程序组，完成原子动作(atomic action)。一旦接收到肯定应答，发送机也提交使用LUWID的报文程序组，MQGET操作的这一提交从传输队列删除了这些报文。然后可开始下一个批处理程序组。若传输队列未留下任何报文(并且予定的时间间隔已期满)或已接收到一个关闭该信道的请求，则终结连接。

若该批程序组被拒收，则给发送机发送一拒收回答(一个状态段指示误差-它可包括该误差的细目)，发送机将其可疑报文重卷至传输队列准备好重答，然后终止该信道，若报文程序组被重卷，则也必须重卷序号或LUWID，至最后成功提交的程序组的值。若由于传送或通信对方故障而未接收到确认则通过重卷发送和接收MCA的处理单元而终止该信道。若发送器还未发出确认请求，则发送MCA也应返回。若已发出确认请求，则必须检查其运行记录和接收器程序记录，以确定其应被提交还是应返回。MCAs自动执行该判定：第一工作单元应被提交还是被返回(除非不能重新形成接触，在此情况下操作员可作出决定)。紧接返回之后，发送MCA可试图重建一信道并与发送MCA重新同步，以便重新发送该曾有故障的程序组。

信道再同步是在信道初始化期间实现的。发送MCA从其运行记录检索不确定的LUWID，或已发了确认的最后报文的报文序号。接收MCA将检查其记录的LUWIDs或序号，以判定它是否与发送器同步。作为比较的结果，它将确认或拒收返回一适当状态段的再同步请求，该状态段包含最后成功提交的报文或在其末端的报文程序组的LUWID或序号。若该值与发送器的相配，则发送器可提及该在先发送报文并开始发送下一报文。若接收机的值与在先LUWID或序号匹配，则发送器返回并重新发送在先报文或程序组。

这样，MCA利用同步点管理程序去控制作为逻辑处理单元的每个程序组。包括发送机报文队列管理程序的MQGET的该工作单元和包含接收机报文队列管理程序的MQPUT的工作单元被逻辑链接使两者处于不确定直至接收机准备好提交，报文在发送端用单阶段提交协议删除它们之前在接收端被提交，两阶段提交不需要发送程序充当提交协调程序。在发送或接收程序处，程序组末端之前所发生的任何系统故障可能在再同步阶段期间需要退出工作单元。

对不同系统采用工作单元的逻辑连接的单阶段避免了两阶段需要同步(锁定)一个分布单元中的所有共享资源的缺点。在本发明中，诸资源管理程序实际上不必彼此同步。从应用角度来看资源间不一致有一定时限是可以接收的，但由于原子事务处理是有保证的故也确保了最终一致性。

为完成对报文的可靠传送，服务目的地队列的目标应用程序能发出MQGET，以在其本地同步点管理程序控制下，从队列获得报文作为处理单元390的组成部分，使得应用程序在故障时将报文送回队列重新处理，或提交一个成功处理了的报文，以删除它。

Claims (7)

1.在面向事务处理的数据处理网络中进行程序间通信的方法，其中发送器程序是负责从网络第一结点发送报文，而接收机程序负责在网络第二结点处接收报文，两结点间待发送报文通过第一同步点管理程序控制的处理单元中的发送机程序发送，并通过第二同步点管理程序控制的处理单元中的接收程序接收，以使发送和接收操作保持不确定直至分别解决第一和第二工作单元为止，其特征在于第一和第二工作单元作逻辑链接，从而解决工作单元时的提交处理过程包括：

响应通过接收机程序对报文的成功接收，提交所述第二工作单元，给发送机程序发送一接收的肯定确认，并响应该肯定确认，提交第一处理单元；或

响应报文的不成功接收，重新运行第二处理单元，给发送机程序发送一接收的否定确认，并响应所述否定确认，回退第一工作单元。

2.根据权利要求1的方法，其特征在于所述发送机和接收机程序定位于一个网络范围内的相邻结点上，其中为不同目的地结点指定的报文在通往它们各自目的地结点的通道上的相邻结点之间发送，作为一个工作单元范围的一批报文，包括所述发送和接收操作的工作单元被保持在不确定状态，直至该批报文终止。

3.根据权利要求2的方法，其特征在于一批报文中的最后报文是与提交和确认该批报文的请求一起发送的，所述第二工作单元的提交和所述肯定或否定确认的发送即是响应所述请求的结果。

4.根据1至3任一权利要求的方法，其特征在于：编写运行记录，以记录所述处理单元的不确定状态，供所述处理单元进行处理期间产生故障后的恢复处理过程而用，该值班记录在恢复处理期间读出，以确定哪个工作单元应被提交，而哪个应被回退。

5.根据权利要求1的方法，其特征在于实现应用程序间通信方面的通告和排队，这些应用程序将报文发送到报文队列，接收机应用程序可从这些队列不同步地取出报文，供处理或继续传送。

6.根据权利要求5的方法，其特征在于：应用程序间在网络的不同计算机系统上进行的通信至少包括以下步骤：

第一应用程序在计算机系统中同步点管理程序控制下，发出一个放置报文指令，以便将报文发送到报文队列；

发送机和接收机传输程序，作为两个逻辑链接的工作单元，利用发送和接收计算机系统中的同步点管理程序，在计算机系统之间传送报文，和

第二应用程序在接收计算机系统中的同步点管理程序的控制下，发出一获取报文指令，用以从队列取出报文；

其中放置报文、传送和取得报文的工作单元各保持在不确定状态直到解决各工作单元时为止。

7.面向事务处理的数据处理网络中的程序间通信方法，其中待传送报文从第一计算机的一个发送应用程序被发送到一队列，然后从该队列不同步地被取出，由一个接收应用程序进行处理，该方法的特征在于：

将一报文发送到队列或从队列取出报文的每一步骤是在位于该网络中报文队列管理程序的控制下实现的；

待传送到本地应用程序的报文被放置在由本地应用程序服务的本地队列上；而

对每个传送队列，待传送到远距计算机上远程应用程序的报文被分别置于本地传输队列，用于分别发送至到达各自目的地远程报文队列管理程序通路上的下一报文队列管理程序，其中为不同目的地报文队列管理程序所指定的所有放在一特定传输队列上的报文可传送到同所述下一报文队列管理程序，作为同步点管理程序控制的工作单元范围内的一个或多个报文组。

Images