用于多服务器预订系统上的集中预订上下文管理的方法和系统与流程

本发明涉及旅行预订系统的领域，更具体地涉及用于使用预订服务拦截器架构的多服务器上的集中预订上下文（context）管理的方法和系统。

背景技术：
现代旅游公司（例如，航空公司）通常利用复杂的应用程序来处理客户请求的预订。越来越常见的情况是在整个公司系统内使用多于一个架构。在这种情况下，当设计和规划预订系统时应该考虑兼容性和同步问题。一个示例是在基于互联网的应用程序或者通信基础设施上执行部分预订管理时的情形。另一示例是一系统（并不必是预订系统）必须从遗留主机系统（例如，TPF）迁移到新系统（例如，开放系统）时的情形。为了避免预订系统中的服务中断，可取的是渐进地执行这一迁移，而不是一步到位地关闭现有系统并且切换到新系统，这会产生除了在老与新系统之间切换时的大的激活过程的复杂性以外的所有可能问题，应该在新系统正在构建而老系统继续演变的同时还考虑两者上的软件的双重维护的需求。也许必须开发新的功能而这需要双重努力，尽管如果两个系统可以一起工作，全部开发努力会专用于新平台。出于这些原因，对于所谓的“大爆炸式”的迁移策略来说，渐进迁移是优选的，然而必须考虑到某些困难。具体而言，当预订服务分布在两个不同平台（例如，主机和开放平台）之间时，它们需要在读和写模式下共享相同的旅客订座记录（PNR）上下文数据，以执行它们的业务功能。一个要考虑的问题在于在读和写模式下跨不同服务器和平台并且跨通信协议（例如，TPF主机和开放系统）共享的数据（例如，PNR数据）的同步，以使得系统可以共享相同的最新的PNR上下文数据。由相同申请人提交并且具有与本申请相同优先权日的共同待决的专利申请“METHODANDSYSTEMFORSYNCHRONIZATIONMECHANISMONMULTI-SERVERRESERVATIONSYSTEM”解决了跨多个服务器（或平台）的同步问题。在该申请中公开的方法实现了以高效且一致的机制跨多平台系统地同步PNR值。该机制由于其版本化和其偷懒行为（同步仅在需要时发生）而解决了一致性和性能问题。其可以用作从在一个系统到另一系统的迁移阶段（其中共享数据的应用程序渐进迁移）过程中的解决方案，并且也可以用作跨不同平台的分布式应用程序的永久性解决方案。同步仅在需要时执行，并且仅提供要对本地上下文拷贝完成的更新。以上方法的关键要素是确保共享参数的最新数据值在过程期间的任意时间被使用的机制。在根据以上发明的方法和系统中，使用了分布式共享上下文相关器。这称为DCX（分布式上下文相关器）。DCX在来自相同用户会话的每个消息之上传输关于所有类型的通信协议的附加信息以表示可应用的上下文在不同平台和应用程序（也称为机器或应用程序服务器）上的分布。这一DCX实体构建并且存储在连接各个服务器的企业服务总线（ESB）上，并且在会话头中在Amadeus基础设施内的所有消息上传输。其包含对不同平台上的上下文的引用，意味着其不包含上下文数据本身。其格式为XML并且由三部分构成：一部分为用于路由和其他用例的ESB上下文信息保留，另一部分专用于安全和用户认证，以及最后第三部分是可应用部分，在这里应用程序可以添加它们的上下文引用和与它们相关联的状态指示符。在该可应用部分中，上下文同步过程存储与所分布的PNR上下文相关的信息，并且其是该机制的基础。DCX提供了同步机制所需的两个其他特征，它们是不同通信协议之间的亲和性和上下文共享。需要该亲和性以在每次调用相同服务时靶定完全相同的应用程序服务器，并且在PNR上下文对于应用程序服务器是本地的时需要该亲和性。优选地，与亲和性有关的信息包括在密钥中，其可以称为“亲和性密钥”，所述密钥包括在DCX中。需要跨协议的上下文信息的共享以确保在不同协议上调用PNR服务的用户将仍然在完全相同的PNR上下文上工作。上下文的寿命持续时间由ESB与开放系统（或主机）之间建立的对话控制。DCX提供了用户活动的全局视图，意味着如果用户通过一个特定对话（例如EDIFACT对话）工作，其他协议对话将被保持以确保跨协议的一致性。当用户（通过特定的对话关闭或者通过无活动超时）断开与ESB的连接时，与开放系统和主机的对话也将关闭并且将触发上下文的清除。在由相同申请人提交并且具有与本申请相同优先权日的共同待决的申请“METHODANDSYSTEMFORPROVIDINGASESSIONINVOLVINGAPLURALITYOFSOFTWAREAPPLICATIONS”和“METHODANDSYSTEMFORPROVIDINGASESSIONINAHETEROGENEOUSENVIRONMENT”中也可获得DCX的描述。虽然基于DCX的同步机制在实现跨多平台的系统时共享的预订数据方面是非常有利的，但是在一些情况下，例如，当在高度分布式开放后端平台内处理并交换信息时，可能优选的是具有预订数据的集中处理，这可以改进上下文处理。在高度分布式环境中，同步机制将意味着所有服务器都是至关重要的（因为它们全部将预订数据本地存储在存储器中）并且它们全部不得不从其他服务器获得数据，并且这会对系统性能造成影响。

技术实现要素：
本发明的目的在于缓解与现有技术的系统相关联的问题中的至少一些并且当信息在相同的分布式环境内处理和交换时提供改进的PNR数据的处理。根据本发明的一个方面，提供了一种预订方法，在包括多个开放后端服务器（OBE）的分布式预订系统上操作，每个OBE适于提供服务，用于跨至少两个OBE控制用户事务期间PNR记录的一致性，该方法包括以下步骤：预订拦截器模块，接收包括数据结构的用户请求，所述数据结构包括对于至少一个服务的请求和对PNR记录的引用；所述预订拦截器模块以包括PNR记录的内容的信息充实所述数据结构；所述预订拦截器模块根据所述用户请求中请求的至少一个服务，将已充实的数据结构转发至第一至少一个OBE；响应于第一至少一个OBE返回已充实的数据结构的最新版本，所述预订拦截器模块进而将已充实的数据结构转发至其他OBE，直到已经提供所述用户请求中包括的所有请求的服务；返回与由用户请求的至少一个服务关联的响应。根据本发明优选实施例的方法实现了确保PNR记录在由预订拦截器模块控制并且包括多个OBE的子系统内处理时的一致性。还获得了系统安全性的改进。利用本发明的方法，仅需保护持有中央预订数据的服务器（例如经由备份），并且需要预订数据以处理用户请求的不同服务器将无缝地访问嵌入在查询内的这些数据，从而不需要附加的附带交换。根据本发明的第二方面，提供了一种预订子系统，其包括一个或多个适于执行上述方法的部件。根据本发明的又一实施例，提供了一种计算机程序，其包括在所述计算机程序被在计算机上执行时用于执行上述方法的指令。附图说明现将通过示例的方式参照附图，其中：图1是根据本发明实施例的系统的图示；图2是根据本发明另一实施例的系统的图示；图3是适于支持本发明优选实施例的方法的通用计算机系统的图示；图4是根据本发明的一个实施例的过程的方法步骤的流程图。具体实施方式如图1所示，对开放系统上的PNR上下文进行集中以避免其在分布式环境中的碎片化，因为对所有上下文部分的收集意味着性能问题。另外，代替实施事务会话协议以处理PNR上下文上的事务的开始、中间更新和最后提交或退回，服务拦截器架构的原理在于以当前用户PNR上下文委托功能查询，该当前用户PNR上下文将仅在整个功能用例结束时的响应时间处在PNR上下文的中央储存库中被修改。这样的集中化仅限于在所有预订服务器之间共享的预订数据，并且PNR上下文在称为GCX（通用上下文容器）的实体中传输，该GCX不是永久性数据结构。一旦对用户提供答复，则不再需要保持GCX。图1表示根据本发明优选实施例的系统的可能实现方式。功能部件与数据结构（DCX和GCX）一起示出；用户请求的可能服务的通信步骤在图中以标记1-8指示。根据Amadeus基础设施（例如Amadeus预订服务拦截器）建立该示例。如参照图1解释的，用户101通过例如计算机与预订系统连接。要求在读或写模式下访问用户PNR上下文的服务的全部功能查询不得不通过预订服务拦截器OBE105（也称为预订拦截器），以使得这些查询能够由包含PNR上下文数据的GCX实体进行充实。随后，这些查询被委托给真实功能服务以便执行业务请求。通过传输有功能答复的GCX中的功能服务提供上下文更新。答复再次通过预订服务拦截器，其将更新集成到用户PNR上下文中，去除GCX并且将功能答复转发给用户。在这一架构中，使用了两种ISAP（集成服务访问点）：用于外部用户的外部ISAP103以及用于内部服务和调用其他服务的应用程序的内部ISAP107。ISAP是ESB的实体，其允许用户或应用程序靶定服务而不必知道服务拓扑的细节。根据本示例中描述的实施例，DCX实体被创建和存储在外部用户连接到的外部ISAP103上。其被添加在用户查询之上并被传输在Amadeus基础设施内的所有消息上。DCX和GCX实体两者可以通过内部ISAP，其允许这样的实体在查询和答复中并且不在它们的上下文中存储它们。使用预订服务拦截器的路由，将功能服务公布在的外部ISAP上，以使它们首先通过拦截器。使用到功能开放系统的真实路由，还将相同的功能服务公布在服务拦截器之后的唯一的内部ISAP上，使得可以处理业务请求。这样，路由仍然由ESB处理，而无需在服务拦截器内复制路由逻辑，其仅关注PNR上下文附加或去除。由于DCX和GCX实体处于协议级别，功能客户端应用程序不会看到由通信中间件自动去除和留置的这些实体。将委托接口传递给功能客户端应用程序以访问来自GCX的PNR数据，好像上下文是本地存储的一样。功能服务接口不受DCX或GCX的影响，因为它们不是消息语法的一部分。在这样的情况下，对用户PNR上下文的访问对于服务器应用程序来说是无缝的，因为其不需要发送查询以获得上下文。在响应中，功能服务器应用程序可以提供PNR上下文更新以及待在服务拦截器上执行的动作。当前，可能的动作是简单地将功能答复转发给用户，或者以PNR显示答复用户，这需要从拦截器到PNR显示服务的新的客户端调用，和/或在预定义事件（诸如忽视用户PNR上下文）时要通知的请求。在这一示例中，用户101发送对于定价服务的请求（步骤1）。通过外部ISAP103接收该查询，外部ISAP103如上所述地检索最新DCX，并且将DCX信息与用户查询一起传递（步骤2）给预订拦截器OBE105。预订拦截器OBE访问用于该用户的集中的PNR上下文（在该情景中其在开放系统上是最新的）并且将其在GCX中添加到功能请求之上。随后，将完整的数据结构（DCX+GCX+查询）通过内部ISAP107转发给托管定价功能的定价OBE109（步骤3和4）。一旦已经执行了业务过程，定价OBE109以上下文更新答复（5和6，再次通过内部ISAP107）预订拦截器105，预订拦截器105将致力于通过外部ISAP103答复用户101（7和8）。该答复中的上下文更新通过拦截器集成到集中的PNR上下文中并且该答复被转发给用户。该机制用于提供功能服务的远程开放系统并且也用于预订开放系统直接提供的本地服务。图1中示出的示例为了易于描述而有意简化，然而本领域技术人员将理解，若干服务OBE可以由相同的预订拦截器OBE105设置和控制。存储在GCX上的用户PNR将从一个步骤传递至下一步骤，确保其总是最新的：仅在会话终止时，PNR返回给用户并且可以丢弃和删除GCX的临时数据结构。图2示出更加完整的示例，其中两个服务OBE工作在预订拦截器105的基础设施内。在该示例中，用户101通过外部ISAP103发送对于定价服务的请求，外部ISAP103如上所述地检索最新DCX，并且将DCX信息与用户查询一起传递（步骤2）给预订拦截器OBE105。预订拦截器OBE访问用于该用户的集中的PNR上下文并且将其在GCX中添加到功能请求之上。将完整的数据结构（DCX+GCX+查询）通过内部ISAP107转发给托管定价功能的定价OBE109（步骤3和4）。一旦已经执行了业务过程，定价OBE109以上下文更新答复（5和6，再次通过内部ISAP107）预订拦截器105。在这一情况下，预订拦截器105将随后调用显示服务以通过将查询发送给显示OBE203的另一内部ISAP201格式化对于用户的答复（步骤7和8）。在这种情况下，再次使用相同的委托模式以确保显示服务具有对正确的PNR数据的访问，从而格式化相关联的显示。一旦将此完成，该答复中的上下文更新被发送回到预订拦截器105（步骤9和10）并且通过拦截器集成到集中的PNR上下文中，并且将显示答复通过外部ISAP103转发给用户101（步骤11和12）。该机制用于提供功能服务的远程开放系统并且也用于预订开放系统直接提供的本地服务。当查询消息离开子系统时，即，其通过预订拦截器105通信到外部时，GCX结束其功能并且其被删除。PNR信息的一致性则由以下事实确保，即仅在对用户服务请求的最后响应上，更新被集成在集中的上下文内，该最后响应表示与整个服务调用链相对应的一致的更新集。提供给用户的答复由仅在预订系统（例如，Amadeus基础设施）内交换的所有附加信息（DCX和/或GCX）释放。根据在此描述的本发明优选实施例的方法涉及具有基于DCX（如也在上述共同待决申请中描述的）的同步机制的预订系统。然而，本领域技术人员将理解，也可以代替地使用其他基础设施，而对如何确保不同平台之间的同步没有任何限制（如果完全需要同步）。根据本发明的方法的结果在于实现了子系统的分类，其中对应于用户（例如，用户PNR）的预订上下文由上述预订拦截器模块严格控制。这样的控制的“范围”甚至可以延伸到远程服务提供商（OBE），并且效果在于，在这样的范围内，即直到查询未传输到子系统外部，PNR总是一致的并且在没有预订拦截器（其是OBE本身）的控制的情况下无法被修改。若干不同系统结构和复杂性是可能的，然而必须考虑信息的安全性/一致性与系统性能之间的平衡。根据目前讨论的优选实施例，DCX（分布式上下文相关器）的目的在于，在来自相同用户会话的每个消息之上，传输关于所有类型的通信协议的附加信息以表示可应用的上下文在不同平台和应用程序上的分布。GCX（通用上下文容器）的功能在于，在来自相同用户会话的每个消息之上，传输关于所有类型的通信协议的附加信息以表示可应用的上下文在不同平台和应用程序上的分布。GCX仅在一个查询上或者在一个答复上传输，并且包含上下文数据本身而不是对它们的引用（如使用DCX的情况）。并非意图在所有消息上传输上下文数据；这是GCX不是永久性实体的原因。GCX包含一组对（密钥、值），使得随后调用的若干应用程序可以在已经存在的数据之上添加它们自身的上下文数据。GCX可以在EDIFACT和XML消息两者上传输，并且其位于消息的结尾处以方便消息痕迹的日志记录。预订服务拦截器接收诸如定价查询的用户功能查询以利用最新的用户PNR上下文数据来充实它们。由于分布式上下文同步机制，如果需要，预订拦截器从TPF中检索最新的PNR上下文数据，并且在将定价查询委托给功能定价OBE之前将它们附加在GCX内。当由功能服务执行该过程时，具有关联的PNR上下文更新的功能答复被发送回到预订服务拦截器。服务拦截器将去除并且集成在预订OBE的内存中存储的用户PRN上下文内的上下文更新，并且将功能答复转发给用户。预订服务拦截器连同DCX一起接收功能查询。使用分布式内容同步机制，其检查DCX内容并且利用本地PNR上下文信息分析是否需要与TPF主机的同步。一旦对于当前用户已经检索到最新的PNR上下文数据，则使用委托库以便将PNR上下文编码到GCX实体中。服务拦截器随后连同DCX和GCX一起委托功能查询。当预订服务拦截器接收到功能答复时，其使用委托库来对已经提供的GCX进行解码。从GCX中，提取PNR上下文更新以便将其集成到预订OBE上的集中的用户PNR上下文内，并且将相应地更新DCX密钥（更多细节，参见分布式上下文同步机制）。从GCX中，也将提取动作，并且预订拦截器将执行它们：例如，在前的附图示出功能答复的简单转发的动作，所以预订拦截器将仅仅以接收到的功能答复答复用户。委托机制包括用于从应用程序中调用其他服务的客户端接口以及用于允许也调用该应用程序的其他服务的服务器接口。在本发明的优选实施例中，委托机制已被设计为回答以下若干要求：-对于多平台委托和结构的易于演变的支持（可以具有不同OBE上的不同版本的委托库，委托消息将使用上下文数据的向前兼容的EDIFACT系列化，因为其必须是老版本的语法可读的）-支持上下文的若干类型-支持委托的若干模式（全模式、delta模式）-支持若干后续委托，从而允许应用程序链委托给彼此部分功能性-支持在委托的答复中的上下文更新和后处理动作（动作可以是转发功能答复或者请求PNR显示作为对于用户的响应）-支持委托的答复中的功能应用程序的注册以在诸如忽视上下文的事件时通知它们。附加地，由于委托数据，可以利用功能消息同时传输若干上下文。如在下一部分将看到的，这些要求对于在GCX中传输的上下文信息的内容具有直接影响。关于DCX机制，其功能性的完整描述可以在由相同申请人提交的并且具有与本申请相同提交日的共同待决的申请“METHODANDSYSTEMFORSYNCHRONIZATIONMECHANISMONMULTI-SERVERRESERVATIONSYSTEM”中找到。根据优选实施例，PNR上下文的本地内存中的拷贝在每个平台上复制；本地执行更新并且在另一平台需要访问最新上下文数据时发生同步。这即是所谓的分布式上下文同步。同步机制的复杂性在于确定本地拷贝是否过时，并且确定最新PNR数据位于何处以便得到它。这一机制对于所有类型的用户查询有效，无论通信协议如何，并且其不依赖于诸如数据的表示（大或小端（endian））的平台技术特性。对于PNR上下文同步的本解决方法以优化方式回答了所有这些要求，因为同步仅在需要时执行，并且仅提供要在本地上下文拷贝上完成的更新。在本发明描述的示例中，服务器之间的连接是通过ESB实现的，然而本领域技术人员将理解，也可以使用能够将事物路由至合适应用程序服务器的现有技术的路由装置的任何其他状态，例如，路由器、门户或请求代理。参照图3，以350表示该系统的通用计算机（例如，任意计算机、预订服务器、TPF主机、开放系统服务器、数据库管理子系统、路由器、网络服务器）。计算机350由并行连接至系统总线353的若干单元形成。详言之，一个或多个微处理器356控制计算机350的操作；RAM359由微处理器356直接用作工作内存；以及ROM362存储用于计算机350的引导程序的基本代码。外围单元聚集在本地总线365周围（通过各自的接口）。具体而言，大容量存储器包括硬盘368和用于读取CD-ROM374的驱动器371。另外，计算机350包括输入装置377（例如，键盘和鼠标）以及输出装置380（例如，监视器和打印机）。网络接口卡383用于将计算机350连接至网络。桥单元386使系统总线353与本地总线365接口连接。每个微处理器356和桥单元386能够作为主代理进行操作以请求访问系统总线353用于传送信息。仲裁器389管理互斥地访问系统总线353的准予。如果系统具有不同拓扑，或者其基于其他网络，类似考虑也是适用的。可替换地，计算机具有不同结构，包括等效单元，或者包括其他数据处理实体（诸如，PDA、移动电话等）。优选实施例的方法还表示在图4中示出的图示中。该方法在包括多个开放后端服务器（OBE）的分布式预订系统上操作，每个OBE适于提供服务，用于跨至少两个OBE控制用户事务期间的PNR记录的一致性；该方法开始于黑圆圈401并且随后行进到框403，其中在预订服务拦截器处接收用户请求。在步骤405，创建一结构，从而以用户请求的信息充实该数据结构，其通常包括PNR（或者包含正在请求的用户的预订信息的类似数据结构）。这样的结构（在此称为GCX）已经在本申请中以一定程度的细节进行了描述，然而本领域技术人员将理解，也可以使用若干不同的实现方式。仅作为示例，可以将附加信息构建为分离的数据结构，其在OBE之间的事物中伴随着用户查询和/或PNR。在步骤407，已充实的数据结构（包括GCX）随后从预订拦截器转发至一个OBE以接收一个所请求的服务（如在用户请求中详述的）。当响应返回至预订拦截器（步骤409）时，预订拦截器验证是否需要其他服务（步骤411）。如果需要，则将已充实的数据结构转发至另一OBE并且过程返回到步骤407。当已经提供了用户请求的所有服务时，预订拦截器将与已经由用户调用的服务关联的响应返回给用户；与用户关联的一致的PNR上下文被保持用于将来的请求。应理解，在不偏离本公开的范围的情况下可以对以上内容作出替换和修改。自然，为了满足局部和特定要求，本领域技术人员可以对上述解决方案进行许多修改和替换。具体而言，虽然已经具体参照优选实施例在一定程度对本公开进行了描述，但是应该理解，形式和细节上的各种省略、置换和改变，以及其他实施例也是可能的；并且，其明确的意图在于，与本公开的任意公开实施例相关地描述的具体元件和/或方法步骤可以结合到任意其他实施例中作为设计选择的一般事项。如果程序（其可用于实现本公开的每个实施例）以不同方式构造，或者如果提供附加的模块或者功能，则类似的考虑也是适用的；同样，存储器结构可以是其他类型的，或者可以由等效实体（并非必然包括物理存储介质）替代。并且，所提出的解决方案适合于以（具有类似或者附加的步骤，甚至以不同顺序的）等效方法实现。在任意情况下，程序可以采用任何适合由任意数据处理系统使用或者与任意数据处理系统相关的方式，诸如外部或常驻软件、固件或者微代码（在对象代码中或者在源代码中）。并且，程序可以提供在任意计算机可用的介质上；介质可以是任何适合包含、存储、通信、传播或者转存程序的元件。这样的介质的示例是固定盘（程序可以预先加载在其上）、可移除盘、磁带、卡、导线、纤维、无线连接、网络、广播波等；例如，介质可以是电子的、磁的、光学的、电磁的、红外的或者半导体类型的。在任意情况下，根据本公开的解决方案适合以硬件结构（例如，集成在半导体材料的芯片中）执行，或者以软件和硬件的结合执行。