CN103443790A - 用于多服务器预定系统上的同步机制的方法和系统 - Google Patents

Abstract

根据本发明的优选实施例的用于允许以高效且一致的机制在多服务器（可能为多平台）预定系统间同步PNR值的方法和系统。该机制由于其版本化和其懒惰行为（同步仅在需要时发生）而解决了一致性和性能的问题。它能够被用作在以应用共用数据的渐进式迁移进行的系统这之间的迁移阶段中的解决方案，并且还用作用于不同平台间的分布式应用的永久性解决方案。根据本发明的一种优选实施例，预定服务分布于两个不同的平台（如大型机和开放性平台）之间，它们需要在读和写模式中共用相同的旅客姓名记录（PNR）环境数据，以执行其业务功能。本发明的一种优选实施例的方法和系统允许在读和写模式中于不同平台间以及于通信协议（如TPF大型机和开放性系统）间共用的数据（如PNR数据）的同步，使得系统能够共用相同的最新PNR环境数据。

Description

用于多服务器预定系统上的同步机制的方法和系统

技术领域

本发明涉及旅行预定系统领域，更特别地涉及用于使用分布式环境的同步机制来处理在多个服务器上的旅行预定的方法和系统。

背景技术

现代的旅行公司（例如，航空公司）通常采用用于处理客户的预定请求的复杂应用。越来越常见的情况是：在整个公司系统中使用多个体系结构。在这样情况下，在设计和规划预订系统时应当考虑兼容性和同步问题。一个实例是预定管理的一部分在基于因特网的应用或通信设施上执行。另一个实例是系统（并不一定是预订系统）必须从遗留大型机系统（例如，TPF）迁移至新的系统（例如，开放性系统）。我们将这后一个实例称为退役，即，应用将被从例如TPF大型机迁移至例如开放性系统时。为了避免预定系统中的服务中断，可取的是逐渐地执行该迁移，而不是在单独一次移动中关闭现有系统并切换到新的系统，具有能够引起以下情形的所有可能问题：除了在旧系统与新系统之间切换时的大激活过程的复杂性之外，我们还应当在新系统处于构造中并且旧系统继续进化时考虑软件在这两个平台上的双重维护的需要。可能必须开发新的功能，并且这需要双重的工作，然而，如果两个系统能够一起工作，则所有开发工作都能够致力于新的平台。由于这些原因，渐进式迁移比所谓的“大震动（big bang）”迁移策略更好，但是必须考虑某些困难。特别地，当预定服务分布于两个不同的平台（例如，大型机和开放性平台）之间时，它们需要在读和写模式中共用相同的旅客姓名记录（PNR）环境数据，以便执行它们的业务功能。应当考虑的一个问题是在读和写模式中共用于不同的平台间以及于通信协议（例如，TPF大型机和开放性系统）间的数据（例如，PNR数据）的同步，使得系统能够共用相同的最新PNR环境数据。对于“环境（context）”，我们意指与活动（终端）用户会话链接的购物会话环境。它表示由系统使用以便该具体用户在例如旅行预定系统（与活动终端用户会话链接的预定（购物）会话环境）中执行所请求的功能的所有功能和技术信息。

发明内容

本发明的一个目的是减轻至少某些与现有技术的系统相关的问题。

根据本发明的一个方面，本发明提供了一种用于在多服务器系统上操作的预定方法中的同步机制的方法，用于确保在多服务器系统的至少两个服务器间的用户交易期间使用最新的PNR记录，其中PNR的本地环境版本保持于多服务器系统的每个服务器内，这些服务器通过系统总线互连，该机制包括以下步骤：在可由多服务器系统的所有服务器访问的共用的环境存储区中保持有关PNR的最后更新版本的信息；响应于用户请求而促使所选择的一个服务器执行下列动作来修改PNR的本地环境版本：在共用的环境存储区上检查哪个服务器最后更新PNR；如果最后更新PNR的服务器不同于所选择的服务器，则获得PNR的最新版本；修改PNR的本地环境版本以满足用户请求；更新共用的环境存储区以反映PNR的最后更新版本。

根据本发明的一种优选实施例的方法允许以高效且一致的机制在多服务器（可能为多平台）系统间同步PNR值。该机制由于其版本化和其懒惰行为（同步仅在需要时发生）而解决了一致性和性能的问题。它能够被用作在以共用数据的应用的渐进式迁移进行的从一个系统到另一个系统的迁移阶段中的解决方案，并且还用作用于不同平台间的分布式应用的永久性解决方案。

根据本发明的第二方面，本发明提供了包括适用于执行以上所述的方法的一个或多个部件的系统。

根据本发明的另一种实施例，本发明提供了包括用于在所述计算机程序在计算机系统上执行时执行以上所述的方法的指令的计算机程序。

附图说明

现在将以示例的方式来参考附图，在附图中：

图1是根据本发明的一种实施例的库存系统的示意图；

图2示意性地示出了在本发明的一种优选实施例中使用的分布式环境相关器的可能结构；

图3以用例形式示出了在共用的环境中具有关联的值变化的不同平台上的请求处理；

图4是适用于支持本发明的一种优选实施例的方法的通用计算机系统的示意图；

图5至9（a和b）示出了具有根据本发明的一种优选实施例的EDIFACT结构（a图）和用例示意图（b图）的分布式环境同步的五种服务；

图10是根据本发明的一种实施例的处理的方法步骤的流程图。

具体实施方式

这部分描述所基于的实例是从用于预订系统的复杂的TPF体系结构到开放性系统结构的迁移。如同以上所提及的，由于许多原因，在单次移动中进行迁移是不可取的。因此，对于过渡时期（该过渡时期可能持续几个月或几年），预定系统分布于国际商业企业的大型机、E.G.TPF或MVS系统以及开放性平台（例如，Unix或Linux系统）当中。预定系统能够在例如Amadeus体系结构上实现。但是，本发明可应用于在具有不同平台的多个服务器间工作的预订系统的任何实现方式。

在从大型机到开放性平台的迁移的实例中，在TPF大型机上，PNR应用共用存储器内的相同的PNR环境，并且能够在读和/或写模式中直接经由API来存取数据。由于TPF的重建以及在TPF大型机之外的PNR应用的迁移，所以出现了PNR环境在不同平台之间共用的问题。实际上，我们拥有具有在不同类的平台间共用的用户环境的单个系统的概念，这些平台需要分布于不同平台上的应用来访问相同的PNR数据，从而确保在平台间执行的业务功能动作的一致性。

图1的示意图表示具有2个应用（一个取决于由另一个提供的PNR信息）的实例。它表明：两个本地PNR环境必须被同步，以便能够执行业务功能。两个应用（App1和App2）在预定系统中合作：App1（仅作为预定应用的示例）运行于系统101上，而App2（例如，定价应用）运行于系统103上。系统101在我们的实例中为TPF大型机，而系统103为开放性系统，例如，Unix系统。更一般地，这两个系统101和103能够是在两个不同平台上的任何已知的系统。这两个系统101和103通过同样可由用户通过终端107来访问的企业服务总线（ESB）105彼此连接。在终端107与ESB105之间的连接能够以任意适合的网络布局（例如，TCP/IP）来完成。此外，ESB是一种实现方式的示例，但是作为代替还能够使用其他已知的结构，例如，路由器（Router）、门户（Portal）或请求代理（Request Broker）。每个系统101和103都可以访问PNR信息保持于其内的本地存储区（分别为109和111）。本地PNR信息对于本地系统将是最新的，但是对于另一系统，它可能是过期的。在本实施例中，我们已经使用了具有在两个不同平台上工作的两个系统101和103的实例，但是本领域技术人员应当意识到，其他实现方式对于几种不同的系统是可能的。在图1的示例中，用户通过终端107和ESB105来请求（步骤1）对在PNR109的本地版本上工作的App1的预定；PNR根据由App1进行的加工（elaboration）来更新（步骤2）。当控制权被传递给App2（步骤3）时，应用在PNR111的本地版本上工作（步骤4）。在这样做之前，有必要验证本地PNR是否是最新的版本（在本例中，它不是），否则必须更新。App2能够访问外部系统113（例如，定价数据库）以完成其加工（步骤5）。

在根据本发明的一种优选实施例的方法和系统中，PNR环境的本地存储器内副本在每个平台上被复制；更新在本地执行并且同步在另一个平台需要存取最新的环境数据时发生。这是我们所称的分布式环境同步。同步机制的复杂性将确定本地副本是否已过期，并且确定最新的PNR数据位于何处以得到它。这种机制在所有类型的用户查询上工作，无论什么通信协议，并且它不取决于平台技术特性，例如，数据的表示（例如，高位优先或低位优先）。

用于PNR环境同步的本方法以最优的方式符合了所有这些要求，因为同步仅在需要时执行，并且仅提供待在本地环境副本上完成的更新。本发明的关键要件是用于确保所共用的参数的最新值可在过程中的任何时候使用的机制。在根据本发明的一种优选实施例的方法和系统中，使用分布式的共用的环境相关器。作为在所描述的Amadeus预定系统中的实例，这称为DCX（分布式环境相关器）。DCX传递有关所有类型的通信协议的在来自同一用户会话的每个消息之上的附加信息，用于表示在不同平台和应用上的应用环境的分布。

该DCX实体被创建并被存储于ESB上，并且以会话报头的方式传递于Amadeus基础设施内的所有消息上。图2示出了根据本发明的一种优选实施例的DCX结构200的实例。它含有对不同平台上的环境的引用，意味着它不含有环境数据本身。它以XML来格式化，并且包括图2所示的3个部分：一个为用于路由及其他用例的ESB环境信息而保留（201），另一部分专用于安全性和用户认证（203），而最后，第三部分是其中应用能够添加它们的环境引用以及与它们关联的状态指示器的应用部分（205）。在应用部分中，环境同步过程存储与分布式PNR环境相关的信息，并且它基于它工作所必备的机制。

DCX提供为同步机制所需的两个其他特征，这两个特征是在不同通信协议之间共用的亲和力及环境。亲和力是每当相同的服务被调用时为了靶向完全相同的应用服务器所需的，并且它是必需的，因为PNR环境是在应用服务器本地的。优选地，与亲和力相关的信息包含于关键字内，这些关键字能够称为“亲和力关键字”，所述关键字包含于DCX内。环境信息在协议间的共用是确保调用不同协议的PNR服务的用户将会仍然工作于完全相同的PNR环境上所需要的。

环境的寿命时间受在ESB和开放性系统（或大型机）之间所建立的会话控制。DCX提供了用户活动的全局观点，意指如果用户通过一个具体的会话（例如，EDIFACT会话）来工作，则其他协议会话将被保留以确保在协议间的一致性。当用户（由具体的会话关闭或者由不活动超时）与ESB断连时，与开放性系统及大型机的会话将同样被关闭，并且将触发环境的清理。关于DCX的描述还可在同一申请人提交的且具有本发明相同的优先权日期的共同未决的申请“METHOD ANDSYSTEM FOR PROVIDING A SESSION INVOLVING A PLURALITYOF SOFTWARE APPLICATIONS”和“METHOD AND SYSTEMFOR PROVIDING A SESSION IN A HETEROGENEOUSENVIRONMENT”中获得。在本发明的描述的实例中，在服务器当中的连接通过ESB来实现，但是本领域技术人员应当意识到，作为代替能够使用能够将交易路由至适当的应用服务器的本技术领域的路由装置的任何其他状态，例如，路由器（Router）、门户（Portal）或请求代理（RequestBroker）。分布式环境的同步机制使用共用的环境（DCX）实体的应用部分在不同的平台上存储有关本地环境状态的信息，也称为机器或应用服务器。每个平台都需要引用其本地环境并且在意味着环境的改变的每次交易时都更新状态。与环境相关的数据被构造如下：

在分布式的PNR环境同步中所涉及的所有平台将会具有在相同应用类型（在此称为“SBR”）下存储于DCX内的它们的环境关键字。

字段“平台”对应于通常用来指定系统的3个字母的首字母缩略词，例如，TPF或RES开放性系统。

字段“环境版本”对应于存在于关联的平台上的环境的版本，这是每次环境被修改时就增加的数字。

字段“环境关键字”，也称为应用环境关键字，对应于允许在关联的平台上检索环境的唯一标识符。

字段“环境状态”对应于在关联平台上的环境的状态。环境状态能够表示环境为活动、不活动、中断的事实以及它是否是最后更新的环境。

在DCX中的应用关键字的实例，在TPF上处理的1个用例以及然后在RES OBE（开放性后端（OPEN BACK END））上处理的1个用例之后能够是：

<Application=SBR>

<TPF，1，Key1，ACT>

<RES，1，Key2，ACT/Last>

</Application>

本地环境的版本化是实现懒惰同步机制（它仅在需要时执行）的关键，如同我们将在关于算法的下一章节中看到的。“最后更新者（LastUpdater）”的指示器同样是确定哪个平台具有最新环境的关键，从而与该平台完成同步。

除了在DCX实体中于所有消息上传递的分布式PNR环境的当前状态之外，每个平台都具有与其环境关联的所存储的本地同步状态。该本地同步状态表示在其他平台上的分布式PNR环境于最后执行的同步时的状态。它允许确定本地环境与其他平台相比是否已过期，这是同步的触发条件。实际上，如果已经在一个精确的环境上进行了几个连续的更新，则同步将不会每次都执行，因为本地环境与其他平台环境相比将是最新的。

以上所述的数据结构是可能的替代方案之一，但是也能够实现其他实现方式来确保相同的共用参数的不同实例的一致性。这样的数据结构的要求是，有关PNR的最新版本的位置的信息能够在全部应用当中于由系统使用的所有平台间共用。

如图3所示，对于同步部分在共用的环境（在本例中为DCX）内对应用关键字进行的修改的全局流程采用称为系统1和系统2的两个平台（例如，一个运行于大型机上，而另一个运行于开放性系统上）的示例来解释。在图3的示意图中，描述了在具有于共用的环境中的关联的值变化的不同平台上的用例处理。在共用的环境中传递的当前状态以及不同平台的本地同步状态被示于该图中，以显示它们之间的差异。

在第一步骤（在图3上的步骤1）中，用户将经由ESB登录到系统中；在该阶段，将为其会话创建空的共用环境，并且将其存储于ESB上（步骤2）。

然后，用户开始工作，发送将由位于系统1上的服务处理的业务查询（步骤3）。ESB将会自动地将具有用户查询的共用环境传递到系统1。由于系统1在本地和共用的环境中都没有发现同步信息，因而它直接处理所接收到的用户查询（步骤4）。如果预定环境已经由查询的处理创建了，则本地同步数据以新的状态来更新，该新的状态是系统1已经取得在版本1中的预定环境并且是它的最后更新者（步骤5）。然后，业务应答被发回给用户，连同以同步数据更新的共用环境一起；在给用户发送应答之前，共用环境被存储于ESB上，使得它能够用于由用户执行的下次查询上（步骤6）。然后，用户发送将由位于系统2上的服务处理的另一个业务查询（步骤7）。ESB将会自动地将具有用户查询的共用环境传递到系统2。在系统2上，没有所存储的本地同步状态，并且与以查询接收到的存在于共用环境内的同步数据的比较表明，需要与系统1同步，因为它持有新的预定环境（步骤8）。所以系统2将向系统1索要其预定环境（步骤9），以将其存储于本地，并且允许用户查询的处理（步骤10）。连同预定环境的存储一起，本地同步状态以表示情形的不同应用关键字来初始化。然后，进行对查询的处理（步骤11）；一旦它完成了，如果预定环境已被更新，则本地同步被更新以表示这样的事实：系统2现在是预定信息的最后更新者，并且其环境现在具有版本1（步骤12）。业务应答被发送回给用户，连同以同步数据更新的共用的环境一起；在将应答发送给用户之前，共用的环境被存储于ESB上，使得它能够在由用户执行的下次查询上使用（步骤13）。

它能够继续进行用户的后续查询的相同动作序列，不管靶向系统1还是系统2。取决于本地同步状态与共用环境的比较，系统将确定是否需要同步。

例如，在系统1的平台上，当在读或写模式中使用预定环境（例如，PNR）的服务被调用时，下列算法将被应用以确定是否需要与另一系统同步：

0-接收请求

1-在用户请求上所接收到的当前共用环境中取得应用关键字（例如，System1v1/System2v2Last）

2-取得存储于本地的之前的同步状态（例如，System1v1/System2v1Last）

3-运行一致性检查：

3a-当前的系统1的版本是否与本地所存储的先前版本相同？关键字是否相同？（如果是，则确定（OK））

3b-当前的系统2的版本是否高于或等于本地所存储的先前版本？（如果是，则确定（OK））

4-运行同步检查：当前的系统2的版本是否高于本地所存储的版本，并且是否存在“最后更新者（Last updater）”的标记？（如果是，则需要同步）

5-如果需要同步

5a-运行同步（在系统2的平台中取得环境）

5b-如果成功，则系统1以值——System1 v1/System2 v2（它意指现在系统1上，环境与System2 v2同步）来更新本地所存储的先前同步状态

6-在系统1上处理业务查询

7-如果在预定（PNR）环境上进行修改，则更新系统1的版本

7a-在当前的共用环境中更新系统1的版本（System1 V2 Last/System2 v2）。该共用环境将被发送回给ESB，以保持它用于下次用户查询

7b-在本地所存储的先前同步状态中以值：System1 V2/System2 v2来更新System1的版本

8-应答

在该算法中可以看出，我们需要比较两组环境关键字，以便能够确定从同步的角度来看必须完成什么。当多于两个平台具有PNR环境时，需要“最后更新者”标记，以确定具有环境的最后版本的那个平台。对于两个平台，该机制能够在没有“最后更新者”标记的情况下工作。

这种机制的一个附加优点是，我们能够在下一同步阶段检测共用环境传输错误。实际上，由于一致性检查以及由于本地所存储的同步信息，可以确定是否已发生错误。本地平台的版本不匹配或者环境关键字不同的事实表明共用环境的内容冲突，并且这很可能是错误的结果。由于通信和间接交换，错误处理可以是很复杂的，所以在此将不对其进行详述，但是本领域技术人员应当意识到，本技术领域的方法的几种状态都能够被用来实现该任务。

参考图4，系统的通用计算机（例如，任意计算机、预定服务器、TPF大型机、开放性系统服务器、数据库管理子系统、路由器、网络服务器）以450指示。计算机450由与系统总线453并行连接的若干单元形成。详细地，一个或多个微处理器456控制计算机450的操作；RAM459由微处理器456直接用作工作存储器，而ROM462存储用于计算机450的引导的基本代码。外围单元聚集于本地总线465周围（通过各自的接口）。特别地，大容量存储器包括硬盘468以及用于读取CD-ROM474的驱动器471。而且，计算机450包括输入设备477（例如，键盘和鼠标）以及输出设备480（例如，监视器和打印机）。网络接口卡483被用来将计算机450连接至网络。桥接单元486使系统总线453与本地总线465接口。每个微处理器456和桥接单元486都能够作为请求访问系统总线453以便传输信息的主代理来操作。仲裁器489管理对系统总线453的互斥访问的授权。如果系统具有不同拓扑结构或者它基于其他网络，类似的考虑可以应用。作为选择，计算机具有不同的结构，包括等效单元，或者包括其他数据处理实体（例如，PDA、移动电话等）。

在PNR环境同步机制中使用的并且用于传输PNR数据的EDIFACT服务包括下列信息：

-请求或提供PNR环境数据的平台的本地同步状态。该信息是确定必须在本地环境上检索和应用的用户交易的数量所需的。它还允许优化以减少在平台之间交换的数据量。

-能够在第一同步的情形中完成的或者能够包括在请求环境的最新版本的平台已经具有本地环境副本时的环境更新的串行化的PNR环境。串行化的环境是作为EDI消息本身的PASBCQ。

环境被串行化成EDI消息的事实允许去除提供它的平台的数据表示特异性。实际上，数据内容被标准化，并且独立于平台数据表示。

分布式环境同步基于能够在平台TPF或OBE上实现的或者是主/从平台所专用的5个不同服务。

每个服务将连同消息一起来传递DCX，尤其是因为DCX将允许待在环境同步的状态上运行的一致性检查。每个服务在此参考EDIFACT结构（请求和应答）以及用于示出交换数据的用例示意图来描述。

取得环境：PCSGRQ/R

如图5a和5b所示，该服务被用来从远程平台中检索出其环境的最近版本。它将会在其中环境能够被读出的所有平台上实现。

所交换的数据

在查询时，客户端应当给出其同步状态。它包括3个值的列表<平台（Platform），环境关键字（Context Key），版本（Version）>。

在应答时，服务器应当给出它的具有其版本的与串行化环境关联的同步状态。由于可能会遇到错误，因而应答应当含有描述问题的错误分组。

取得环境串行化版本PCSVRQ/R

如图6a和6b所示，该服务被用来检索与环境的串行化相关的所有版本。该服务应当在OBE上实现。在OBE上，环境基于SBR模型，该环境被串行化成称为PASBCQ的EDIFACT消息。PASBCQ包括具有关联版本的若干二进制大型对象（blob）。由于TPF是PASBCQ的版本的主机（master），因而OBE在它不清楚当前的串行化版本时必须从TPF中检索它们，以便能够写入一致的消息。这种情况在外部系统直接在OBE上请求未经请求的更新时发生。

所交换的数据

在查询时，客户端应当不需要提供任何数据。

在应答时，服务器应当给出它的用来串行化PASBCQ EDIFACT消息的版本。它应当包括含有被用来连同二进制大型对象（blob）版本一起串行化的所有版本的二进制大型对象（blob）。由于可能会遇到错误，因而应答应当含有描述问题的错误分组。

PUSH环境：PCSPUQ/R

该服务（参见图7a和7b）被用来将本地环境的最近版本推送给远程平台以便在远程平台上更新环境。它将被实现于不是环境的主机的平台上。该服务是对同步机制的优化，以具有最新环境的主机。在这种情况下，主机将不使用取得环境服务。由于TPF客户端调用是昂贵的，因而这能够帮助降低在其上的资源消耗。

所交换的数据

在查询时，客户端应当提供它的与具有其版本的串行化环境关联的同步状态。

在应答时，服务器应当只提供确认。由于可能会遇到错误，因而应答应当含有描述问题的错误分组。

PUSH&EOT环境：PCSEUQ/R

该服务（图8a和8b）被用来将本地环境的最近版本推送给远程平台以便在远程平台上更新环境，并且在该环境上调用在该环境上的交易处理结束。它应当被实现于更新PNR环境的并且调用在这些修改上的交易处理结束的所有平台上。该服务是管理处理实体（例如，来自外部系统的票证打印请求（TTP）或者票证确认）所需要的。

所交换的数据

在查询时，客户端应当提供它的与具有其版本的串行化环境关联的同步状态。

在应答时，服务器应当只提供确认。由于可能会遇到错误，因而应答应当含有描述问题的错误分组。

IGNORE环境播送：PCSINQ/R

该服务被用来忽略已经在流程所涉及的不同平台间的对SBR进行的所有修改。TPF将接收“IG”条目，并且然后，它将播送对具有在DCX上注册的SBR环境的OBE的查询，使得它们能够清除它们的环境。它示出于图9a和9b中。

所交换的数据

在查询时，客户端应当不需要提供任何数据。

在应答时，服务器应当只提供确认。由于可能会遇到错误，因而应答应当含有描述问题的错误分组。

以上所述的方法同样表示于图10所示的示意图中。该方法以在多服务器系统上操作的预定方法来实现同步机制，用于确保在多服务器系统的至少两个服务器间的用户交易中使用最新的PNR记录，其中PNR的本地环境版本保持于多服务器系统的每个服务器内，这些服务器通过系统总线互连。该方法在黑色圆圈1001处开始，并且然后进行到其中PNR的最新的版本保持于可由该交易所涉及的全部服务器访问的存储区内的方框1003。需要PNR的更新动作的用户请求被多服务器预定系统（例如，在服务器“A”处）接收（步骤1005）。系统总线（例如，ESB，但是更一般地为任何路由装置）确定并选择哪个服务器是处理该请求所需要涉及到的。在步骤1007和1009，所选择的服务器通过将本地环境PNR与信息比较来检查可在ESB上的共用环境PNR上获得的本地环境PNR是否是最新的：如果本地环境PNR不是最新的（即，另一个服务器自从最后更新（若存在）起已经被由所选择的服务器修改），则所选择的服务器获得PNR的最新版本（步骤1011）。然后，所选择的服务器执行所请求的活动，并且修改同样成为了最新版本的本地环境PNR（步骤1013）：该信息然后在ESB上被传递（步骤1015）给共用的环境PNR，以便可由多服务器系统的所有其他服务器使用。有关信息在服务器、ESB和用户当中传输的方式的细节已经在前面的段落中进行了讨论。

应当意识到，在不脱离本公开内容的范围的情况下，可以进行变更和修改。自然地，为了满足本地和具体的要求，本领域技术人员可以对以上所描述的解决方案进行许多修改和变更。特别地，虽然本公开内容已经在某种具体程度上参考本发明的优选实施例进行描述，但是应当理解，在形式和细节上的各种省略、替换和更改以及其他实施例都是可能的；而且，应当明确指出，结合本公开内容的任何公开实施例来描述的具体元件和/或方法步骤都可以作为通用的设计选项被并入任何其他实施例中。

类似的考虑可应用于：程序（该程序可以被用来实现本公开内容的每个实施例）是否以不同的方式来构造，或者附加模块或功能是否被提供；同样地，存储器结构可以是其他类型的，或者可以等效的实体来替换（不一定包括物理存储介质）。而且，所提出的解决方案促使其自身以等效的方法（具有类似的或附加的步骤，甚至以不同的顺序）来实现。在任何情况下，程序都可以采用适用于由任何数据处理系统（例如，外部或常驻软件、固件或微代码（或者为目标代码或者为源代码））使用的或者结合它们使用的任何形式。而且，程序可以被提供于任何计算机可读介质上；介质能够是适用于含有、存储、通信、传播或传输程序的任何元件。此类介质的实例为固定磁盘（其中程序能够被预加载）、可移动磁盘、磁带、磁卡、导线、光纤、无线连接、网络、广播波段等；例如，介质可以是电子的、磁的、光的、电磁的、红外线的或者半导体类型的。

在任何情况下，根据本公开内容的解决方案促使其自身以硬件结构（例如，集成于半导体材料的芯片内）或者以软件和硬件的组合来实现。

Claims (10)

1.一种在多服务器系统上运行的预定方法中的同步机制，用于确保在多服务器系统的至少两个服务器间的用户交易期间使用最新PNR记录，其中PNR的本地环境版本保持于所述多服务器系统的每个服务器内，所述服务器通过路由装置互连，所述机制包括以下步骤：

在可由所述多服务器系统的所有服务器访问的共用的环境存储区中，保持关于PNR的最后修改版本的信息；

响应于用户请求而促使服务器中被选择的一个执行下列动作来修改PNR的所述本地环境版本：

在所述共用的环境存储区上检查出哪个服务器最后修改所述PNR；

如果最后修改所述PNR的服务器不同于被选择的服务器，则获得PNR的所述最新版本；

修改PNR的所述本地环境版本以满足所述用户请求；

更新所述共用的环境存储区以反映PNR的所述最后修改版本。

2.根据权利要求1所述的同步机制，其中所述多服务器系统的服务器通过面向服务的体系结构（SOA）系统与所述路由装置和所述用户交换信息。

3.根据权利要求2所述的同步机制，其中所述消息包括含有关于PNR的所述最后修改版本的信息的消息报头。

4.根据任一前述权利要求所述的同步机制，其中关于PNR的所述最后修改版本的信息包括PNR的所述最后修改版本的位置。

5.根据任一前述权利要求所述的同步机制，其中关于PNR的所述最后修改版本的信息包括指向PNR的所述最后修改版本的指针。

6.根据任一前述权利要求所述的同步机制，其中所述路由装置包括系统总线，例如，企业服务总线（ESB）。

7.一种计算机程序，包括用于在所述计算机程序于计算机上执行时执行根据任一前述权利要求所述的方法的步骤的指令。

8.一种计算机程序产品，包括采用权利要求7所述的计算机程序的计算机可读装置。

9.一种预定多服务器数据处理系统，包括用于确保在所述多服务器系统的至少两个服务器间的用户交易期间使用最新的PNR记录的同步机制，其中PNR的本地环境版本保持于所述多服务器系统的每个服务器内，所述服务器通过路由装置互连，其中所述系统包括适用于执行权利要求1至6任一项所述的方法的一个或多个部件。

10.一种部署于用于实现权利要求1至6任一项所述的方法的数据处理系统内的服务。

Images