CN105303287A

CN105303287A - 用于管理记录数据结构的方法和系统

Info

Publication number: CN105303287A
Application number: CN201510284799.6A
Authority: CN
Inventors: V·冯特布里德; C·卡瑞特; L·勒新; M·弗朗索瓦; P·伽德亚恩
Original assignee: This Simple And Easy Joint-Stock Co Of Emma's Enlightening
Current assignee: This Simple And Easy Joint-Stock Co Of Emma's Enlightening; Amadeus SAS
Priority date: 2014-05-30
Filing date: 2015-05-29
Publication date: 2016-02-03
Anticipated expiration: 2035-05-29
Also published as: JP6559469B2; KR101695544B1; KR20150138823A; JP2016006642A; CN105303287B; FR3021789A1

Abstract

本发明涉及用于管理记录数据结构的方法和系统。记录数据结构包括形式为标准数据容器的用于存储包括标准数据元素的记录的标准记录数据结构和形式为非标准数据容器的用于存储包括非标准数据元素的记录的非标准记录数据结构。扩展记录数据结构中的每个记录包括记录标识符，记录对应于扩展记录数据结构中共享公共记录标识符的相关数据元素，该方法包括，对于在扩展记录数据结构中为具有给定记录标识符的数据元素创建的每个记录，在辅助数据结构中创建条目。条目共享给定的记录标识符并且包括辅助数据容器，辅助数据容器包括关于共享记录数据结构中相同记录标识符的数据容器的一组属性。该方法基于在辅助数据结构中维护的数据管理扩展记录数据结构。

Description

用于管理记录数据结构的方法和系统

技术领域

本发明一般而言涉及数据管理，并且更具体而言涉及用于在内容管理系统中管理记录数据结构的方法、系统和计算机程序产品。

背景技术

内容管理系统可以向通过专用通信网络连接到系统的一个或多个客户端(例如，终端消费者)提供对具体内容的访问。

由于每个行业领域中大量内容分发提供商的出现，对于让每个客户能够通过唯一的内容管理系统访问多个内容提供商存在需求。

例如，在旅游业，旅游管理系统可以被用来向多个旅行社系统(内容消费者)分发从一组旅游提供商系统(内容提供商)获得的内容。旅游业在过去的几十年间显著增长并且与此同时由旅游业提供的服务已经显著变化，使得广泛各种服务现在可以提供给涉及异构内容的终端消费者。另外，旅游业现在涉及从旅游提供商到终端消费者的许多参与者，其结果就是有大量数据要在那些参与者之间被管理。在旅游提供商和终端用户之间，诸如全球分销系统(GDS)的旅游中介提供旅游管理系统，以允许旅行社从传统的旅游提供商(航线提供商)检索信息，或者在终端消费者和传统旅游提供商之间进行交易。

被用来主要集中在纯航空运输分销的旅行社商业模式在发展并且参与者现在由于非航空相关的内容而获取更高的利润。因此，来自新型旅游提供商的非常重要的各种服务在目的地被推荐。

利用这种备选分销通道的吸引力，除通常的GDS内容(例如，航班或火车内容)之外，旅行社趋于分销越来越多的非GDS内容(例如，宾馆、租车，等等)。

但是，常规的旅游管理系统不提供适当的手段来直接向旅行社提供与非GDS内容相关的信息。

如图1中所示，旅游管理系统1一般而言包括被称为“旅客名字记录(PassengerNameRecord)”数据结构900的记录数据结构，用于存储与直接从GDS内容提供商40接收到的GDS内容相关联的记录。每个记录(PNR)在数据库DB中由记录定位器标识。然后，PNR记录定位器可以被用来访问GDS内容并把它分销到客户端设备，诸如旅行社或终端消费者系统(60)。

PNR900数据结构与旅行数据相关联地维护记录定位器，其中旅行数据与给定的旅客或一起旅行的一组旅客相关联(记录定位器也被称为确认号、预约号、确认码、预订参考，等等)。例如，当为一个旅客或一组旅客进行预约时，在数据结构900中创建PNR，这个PNR包括对应于预约内容的记录定位器和数据(例如，诸如到达时间、起飞时间等等的航班数据)。

目前，由于标准化约束，旅游管理系统不能直接从非GDS旅游提供商50接收非GDS内容。

事实上，旅游管理系统与标准旅游提供商(40)交换的途径接受由IATA(InternationalAirTransportAssociation，国际航空运输协会)定义的规则，该规则是通过“ATA/IATAReservationsInterlineMessageProcedures-Passenger”(AIRIMP)定义的。具体而言，在标准旅游提供商40与旅游内容管理引擎30之间交换的消息要满足由IATA标准定义的消息交换格式TTY(电传格式)并且常规PNR900被配置为只处理以这种TTY格式接收的内容。

同样，没有为PNR900的布局和内容定义行业标准。但是，通过考虑AIRIMP的限制并且尤其是把PNR数据容易地映射成AIRIMP消息的需求，每个旅游管理系统(例如，计算机预约系统，CRS)定义其自己的用于PNR布局和内容的专有标准。因而，关于由不同旅游管理系统维护的PNR900的数据内容和格式，存在许多相似性。特别地，每个PNR数据结构900使得与记录定位器相关联的旅行数据满足对应于由IATA标准化的GDS内容(航班数据、火车数据，等等)的多种预定义类型。

因而，只有GDS内容(例如，航班、火车数据)可以以静态格式在PNR数据结构900中被维护，这种静态格式满足与IATA消息交换标准相关的约束。因此，不可能创建用于非GDS内容(汽车租赁、水上摩托艇，等等)的记录。

US2012259667提供了用于以注解、杂项或幻影片段的形式在PNR900中存储非GDS内容的解决办法。但是，这种解决办法不允许旅游管理系统动态且无缝地以结构化途径在PNR900中其它GDS元素前面直接存储从非标准旅游提供商接收的非GDS内容。

因此，常规的旅游管理系统1只能处理来自GDS旅游提供商，诸如航线提供商，的内容。常规的旅游管理系统包括使用大量应用的旅游内容管理引擎30，每个应用与具体的旅行服务(例如，预订、购物、定价，等等)关联。响应于来自给定旅行社Ai(70)的请求，旅游内容管理引擎30只能从GDS旅游提供商40检索内容、在PNR900中生成记录，并且把这样创建的PNR记录的表示返回给旅行社Ai。

如果旅行社需要访问非GDS内容，则每个旅行社必须直接连接到一组非GDS内容提供商50，而旅游管理系统1只能直接连接到GDS内容提供商40。另一方面，每个旅行社直接连接到具体的一组旅游提供商50，以获得非GDS旅游内容(出租车、娱乐门票，等等)。因此，旅游内容管理引擎30暴露n个旅游服务平台(每个旅行社A1至An有一个平台2.1、2.2…2.i、2.n)，同时只处理来自标准旅游提供商40的标准旅游内容(GDS内容)。

因而，如果给定的旅行社Ai希望来自非标准旅游提供商50的具体内容(例如，博物馆售票)，则这种内容必须由旅行社Ai自己实现。这种自实现对于旅行社来说特别昂贵并且复杂。

另外，在常规方法中，旅游管理系统100以本地格式(源PNR内容格式)存储PNR内容。但是，旅游管理系统可能需要与其它外部系统(旅游提供商，旅行社)交换来自PNR的数据，其中外部系统具有其自己对PNR数据的格式(目标PNR内容格式)。因而，依赖于目标系统，可以执行与旅游管理系统的PNR记录相关联的PNR内容到目标PNR内容格式的转换。以昂贵且静态的方法，这种转换目前涉及硬编码和重新编译。类似地，在旅游管理系统100中利用PNR内容的应用流中，应用流(链接的应用)中接收PNR内容的每个内容应用需要以应用格式转换PNR内容，以便操纵它。因此，链中的每个应用需要解码、验证和编码PNR内容，以便能够写或读它，这需要手工编码的组件并且昂贵。

因此，对用于动态且无缝地交换内容的改进内容管理系统、方法和计算机程序产品存在需求。

发明内容

为了解决这些和其它问题，提供了如在所附独立权利要求1中所定义的内容管理方法，以及如在所附权利要求15中所定义的内容管理系统。优选实施例在从属权利要求中定义。

因此，根据本发明各种实施例的方法和系统允许对标准记录数据结构和非标准记录数据结构的集中式管理。在中央管理数据结构中被维护的信息可以被用来以同步的方式对公共数据处理这两个领域。这种中央管理数据结构还允许清除(purge)标准和非标准记录数据结构或者管理对标准和非标准记录数据结构的访问冲突，就好像它们构成唯一的记录数据结构一样。

在附图和具体描述的审查之后，本发明的更多优点将对本领域技术人员变得清晰。预期任何附加优点都结合在本文当中。

附图说明

结合到本说明书中并构成其一部分的附图说明了本发明的各种实施例并且，与以上给出的本发明一般描述以及以下给出的实施例的详细描述一起，用来解释本发明的实施例。

图1是根据现有技术的常规内容管理系统的图解视图；

图2是根据某些实施例的内容管理系统的图解视图，该系统包括经由网络连接的多个计算系统；

图3是包括内容管理系统的示例性操作环境的图解视图；

图4是图2和3的示例性计算系统的示意图；

图5是绘出可以被执行以便在扩展记录数据结构中添加新内容的过程的流程图；

图6是根据某些实施例在内容管理系统中执行的内部应用的结构的图解视图；

图7是基于业务模型对象(BusinessModelObject)类型的技术对象绘出内部应用的操作的示意图；

图8是绘出内部应用之间的示例性交互的内容管理系统的图解视图；

图9是由一组关键字-值定义的示例性非标准数据容器的示意图；

图10是示例性串行化格式的示意图；

图11是图9的示例性非标准化数据容器的示意图，具有包括在非标准化数据容器中的类型信息；

图12是与图11的非标准化数据容器相关的示例性结构描述文件的示意图；

图13是可以由应用执行的用于内容访问的过程的流程图；

图14是示例性内容交换单元的图解视图；

图15是可以被执行以便向客户端设备发送内容的过程的流程图；

图16是类型C的标准数据容器的XSLT转换的示意图；

图17是与图16标准数据容器相同类型C的非标准数据容器的XSLT转换的示意图；

图18是包括一组属性的类型D的标准数据容器的XSLT转换的示意图；

图19是类型E的非标准数据容器的XSLT转换的示意图，该容器具有与图18标准数据容器的属性完全相同的一些属性；

图20是可以被执行以便重排数据元素的过程的流程图；及

图21是根据某些实施例的扩展记录数据结构的图解视图。

具体实施方式

根据本发明实施例的方法、系统和计算机程序产品可以允许从内容提供商接收的任何类型内容(标准和非标准)的动态管理以及与这种内容关联的记录的集中式存储，而不管内容是什么类型。内容管理系统100可以基于启用客户端请求的接收的客户端/服务器体系架构。

参考图2，提供了内容管理系统100，通过其，多个用户客户端7可以通过独特的平台直接访问由一组内容提供商系统4、5提供的任何类型的内容。由内容管理系统100处理的内容可以从根据第一种类型的消息交换格式14，诸如预定义的标准化消息交换格式，与内容管理系统100通信的标准内容提供商系统4提供，或者从根据第二种类型的消息交换格式15与内容管理系统100通信的非标准内容提供商系统5提供。

内容管理系统100可以被连接到通信网络13，其中通信网络13可包括因特网、局域网(LAN)、广域网(WAN)、蜂窝语音/数据网络、一个或多个高速总线连接，和/或其它这种类型的通信网络。

内容管理系统100可以专用于一个或多个具体的服务领域(例如，旅游领域)。一个或多个客户端设备7每个都可以连接到通信网络13，使得用户可以初始化与旅游管理系统100的服务请求会话，并且响应于该服务请求而从旅游管理系统100接收内容。

本发明的实施例可以由包括一个或多个联网的计算机或服务器的计算系统来实现。该计算系统可以为内容管理提供处理和数据库功能。

每个客户端设备7可以是个人计算设备、平板计算机、瘦客户终端、智能电话，和/或其它此类计算设备。每个客户端设备7可以托管(host)web浏览器和/或定制的应用软件(例如，客户端系统)并且可以包括客户端用户接口。

每个内容提供商系统4或5可以连接到通信网络13。每个内容提供商系统4或5可以托管一个或多个网站和/或让托管服务托管一个或多个网站。

操作客户端设备7之一的用户(即，旅行者)可以在与应用相关的服务请求会话期间利用客户端设备7与内容管理系统100接口(例如，通过连接到web服务而被访问)。内容管理系统100包括内容管理引擎3，用于处理从客户端设备7接收到的服务请求。

内容管理引擎3可以利用根据IATA标准的标准化TTY消息交换格式(第一消息交换格式14)与标准旅游提供商4交换消息。

内容管理引擎3还可以通过数据交换单元11(在本描述中也被称为“内容访问单元”)与非标准提供商5交换消息。例如，响应于来自与旅行社实体(例如，旅行社运营商或旅行社系统)关联的用户客户端7的搜索、预订、定价、发布、取消请求，数据交换单元11可以使用根据诸如可扩展标记语言的数据描述语言(第二消息交换格式15)定义的消息来与非标准内容提供商通信。

用户可以由在客户端设备7输入信息通过在客户端设备7上生成的用户图形接口来向内容管理系统100提交服务请求，其中用户图形接口是由在内容管理系统100上执行的应用(例如，以web服务的形式)在客户端设备7上生成的。从用户接收的信息可以被累积，直到用户向内容管理系统100提交服务请求(例如，通过执行提交动作)。

响应于用户请求，内容管理引擎3可以根据消息交换格式14和/或15从内容提供商系统4和/或5请求并获得内容，并且在扩展记录数据结构9中存储与被检索内容相关的记录。响应于保存请求或者周期性地，扩展记录数据结构9可以被存储在上下文中并保存在一个或多个数据库8中。作为替代，在某些实施例中，扩展记录数据结构9可以直接存储在一个或多个数据库8中。

扩展记录数据结构9包括用于存储与标准数据相关联的记录的标准记录数据结构90以及用于存储与非标准数据相关联的记录的非标准记录数据结构91。

记录包括与相关数据元素相关联的记录标识符(也被称为“记录定位器”)。记录标识符可以是任何类型和任何格式，诸如数字。

标准记录数据结构90是静态的，因为它只适于存储用于具有一组预定义属性当中一个或多个属性的预定义类型的内容(称为“标准”内容)的记录。如在本文所使用的，术语“标准”指具有对应于标准记录数据结构90所支持格式和/或类型的预定义格式和/或类型的标准内容。

对于包括相关数据元素的所接收内容，如果所接收的内容只包括标准数据元素，则可以在标准记录数据结构90中添加记录。该记录包括与数据元素相关联的记录标识符。

作为替代，对于包括相关数据元素的所接收内容，如果所接收的内容只包括非标准数据元素，则可以向非标准记录数据结构91添加记录。该记录包括与至少一个包括所述非标准数据元素的非标准数据容器相关联的记录标识符。

另外，对于包括相关数据元素的所接收内容，如果所接收的内容包括非标准数据元素和标准数据元素，则可以向标准记录数据结构90并向非标准记录数据结构91添加记录。标准记录数据结构90中和非标准记录数据结构91中为所接收内容标准添加的两个记录都可以被指定相同的记录标识符(在下文中称为“公共记录标识符”)。公共记录标识符在标准记录数据结构90中的一个或多个标准数据元素(标准内容)和/或非标准记录数据结构91中的一个或多个非标准数据容器(包括非标准数据元素)之间共享。

通过在记录数据结构90和91中使用相同的记录标识符，以标识相关的标准和非标准数据元素，内容管理系统100可以透明地管理这两个记录数据结构，就好像它们构成独特的记录数据结构一样。

内容管理引擎3可以维护与不同服务关联的多个应用。内容管理引擎3可以依赖于从客户端设备7接收的服务请求而执行一个或多个应用，所述服务请求可以触发从内容提供商系统的内容检索以及与这种被接收内容相关的记录在扩展数据结构9中的存储。内容管理引擎还可以被配置为无论内容是什么类型都基于存储在扩展记录数据结构9中的记录利用记录在记录数据结构9中的内容向用户客户端返回对服务请求的响应。为了向客户端返回响应，内容管理引擎3可以使用数据交换单元11，用于在客户端设备7上生成内容的统一表示，无论从扩展记录数据结构9检索的记录中所包括的内容是什么类型。因此，内容管理引擎3充当向用户客户端7提供服务的应用聚集器。

在本发明的优选实施例中，内容管理系统100可以是旅游管理系统。旅游管理系统100可以由中间运营商(例如，在旅游领域是全球分销系统(GDS))实现，以允许旅游内容的集中式管理，例如，在GDS(“GlobalDistributionSystem，全球分销系统”的首字母缩写)中实现。

图3示出了在GDS1中实现的这种旅游管理系统100的示例性操作环境10。在这种实施例中，标准内容指由标准旅游提供商系统4提供的遵循IATA约束的GDS内容(诸如航班、火车内容)，而非标准内容可以是由非标准旅游提供商系统5提供的或者在GDS之外预订的不满足IATA约束的任何类型的非GDS内容(例如，汽车租赁)。标准记录数据结构90可以是被配置为存储标准内容的标准PNR数据结构(在下文中也被称为“标准PNR”，PNR是PassengerNameRecord(旅客名字记录)的首字母缩写)，而非标准记录数据结构91(在下文中也被称为“非标准PNR”)被配置为动态地记录任何类型的非标准内容，而无需通过硬编码数据映射和编译机制来预定义非标准内容的类型和属性。标准PNR90一般包括用于旅行行程安排的完整数据集，包括来自多个承运人的段，具有预定义的数据结构(类型、属性、系列)和/或包括该旅行的其它旅游服务，诸如宾馆和租车预约。

扩展记录数据结构9构成扩展旅游记录(下文中也被称为“ETR”)，其中，无论与记录相关联的内容是什么类型，每个内容记录都可以无缝地由内容管理引擎3操纵。

客户端设备7可以与多个通过各自的客户端接口2请求服务的旅行社系统700相关联。更一般而言，旅游管理系统100还可以由根据客户端/服务器方法提交不同类型请求的不同类型的客户端设备访问，诸如旅行者设备6通过相应的用户接口2或者甚至旅游提供商系统4或5(例如，为了交换存储在扩展旅游记录9中的内容)。

标准旅游提供商系统4可以包括多个承运人系统或旅行者系统。非标准旅游产品提供商系统5可以包括汽车租赁系统、博物馆预约系统，等等。当被实现时，承运人系统可以包括启用GDS1的用于相应航线的计算机预约系统(CRS)和/或计费系统。旅行社系统700可以被配置为预约并支付行程票和/或由非标准旅游提供商5提供的附加服务的费用。一些标准旅游提供商系统4还可以彼此交互，直接地或者通过GDS1，以便使验证方承运人能够出售由运营方承运人提供的座位票。然后，运营方承运人可以为了所提供的服务而向验证方承运人提供账单。

通过使旅行社、验证方承运人或其它间接供应商能够经GDS1搜索可用段并在一个或多个承运人系统4上预订预约并且搜索和预订附加服务(例如，汽车租赁、博物馆门票，等等)，GDS1可以被配置为方便旅游提供商4和5与旅行社系统700之间的通信。

每个旅行社系统70可以包括提供可公共访问的网站的web服务器。这个网站可以被配置为提供对旅行规划特征的访问，诸如搜索匹配旅游请求的旅游产品的能力。为此，旅行社系统70可以为旅行者提供对来自由GDS1、旅游提供商4和5以及旅行社系统70托管的一个或多个数据库的数据的访问。在本发明的备选实施例中，旅行社系统70可以是限制对旅游服务提供商或旅行社的访问的专属系统，在这种情况下，访问可以通过私有网站或其它应用提供。

旅行者或旅行社可以使用旅行社系统70来利用具体的旅游应用(例如，旅游规划应用)生成和/或搜索满足从旅行者接收的旅游请求的旅行游建议。

旅行者设备6可以通过公共或专用网络13(例如，因特网)直接连接到旅游管理系统100。旅行者设备6可以是被配置为经网络13与旅游管理系统100通信的任何合适的计算系统。例如，旅行者设备6可以包括台式、膝上型或平板计算机，智能电话，或者任何其它使旅行者能够经网络20搜索和预订旅游服务的计算设备。在本发明的实施例中，旅行者设备6可以包括与由旅游管理系统100的内容管理引擎3托管的web服务应用通信的web浏览器应用，以便依赖于web服务应用而提交旅游请求。

作为替代，旅行者设备6可以包括与由旅行社系统70托管的web服务应用通信的web浏览器应用。Web服务应用又可以与旅游管理系统100通信，以便依赖于旅游服务应用而提交旅游请求。

关于通过GDS1或通过另一GDS提供的旅游，旅游请求可以被提交，以便例如获得与可用行程段相关的数据、生成满足旅游请求的旅游建议和/或预订对应于由非标准提供商5提供的非标准内容的辅助服务(例如，汽车租赁、水上摩托艇预订、博物馆门票预订，等等)。

现在参考图4，GDS1、旅游管理系统100、旅游提供商系统4和5、旅行社系统70、操作环境10的旅行者设备6可以在一个或多个被统称为计算机的计算设备或系统，诸如计算机30，上实现。计算机30可以包括处理器32、存储器34、大容量存储存储器设备36、输入/输出(I/O)接口38以及人机接口(HMI)40。计算机30还可以经由网络22和/或I/O接口38操作地耦合到一个或多个外部资源42。外部资源可以包括，但不限于，服务器、数据库、大容量存储设备、外围设备、基于云的网络服务，或者可以被计算机30使用的任何其它合适的计算资源。

处理器32可以包括选自微处理器、微控制器、数字信号处理器、微型计算机、中央处理单元、现场可编程门阵列、可编程逻辑器件、状态机、逻辑电路、模拟电路、数字电路或者基于存储在存储器34中的操作指令的操纵信号(模拟的或数字的)的任何其它设备当中的一个或多个设备。存储器34可以包括单个存储器设备或多个存储器设备，包括但不限于只读存储器(ROM)、随机存取存储器(RAM)、易失性存储器，非易失性存储器、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、闪存存储器、高速缓冲存储器，或者能够存储信息的任何其它设备。大容量存储存储器设备36可以包括数据存储设备，诸如硬盘驱动器、光盘驱动器、磁带驱动器、非易失性固态设备，或者能够存储信息的任何其它设备。数据库44可以驻留在大容量存储存储器设备36上，并且可被用来收集和组织由本文所述各种系统和模块使用的数据。

处理器32可以在驻留在存储器34中的操作系统46的控制下操作。操作系统46可以管理计算资源，使得体现为一个或多个计算机软件应用，诸如驻留在存储器34中的应用48，的计算机程序代码可以具有由处理器32执行的指令。在备选实施例中，处理器32可以直接执行应用48，在这种情况下，操作系统46可被略去。一个或多个数据结构50也可以驻留在存储器34中，并且可被处理器32、操作系统46和/或应用48用来存储或操纵数据。

I/O接口38可以提供把处理器32操作耦合到其它设备和系统，诸如网络22和/或外部资源42，的机器接口。由此，应用48可以通过经由I/O接口38的通信与网络22和/或外部资源42协同工作，以提供包括本发明实施例的各种特征、功能、应用、过程和/或模块。应用48还可以具有由一个或多个外部资源42执行的程序代码，或者以其它方式依赖于由在计算机30外部的其它系统或网络部件提供的功能和/或信号。事实上，如果近乎无限的硬件和软件配置有可能，本领域普通技术人员将理解，本发明的实施例可包括位于计算机30外部、在多个计算机或其它外部资源42中分布或者通过被提供作为经网络22的服务，诸如云计算服务，的计算资源(硬件和软件)提供的应用。

HMI40可以以已知的方式操作地耦合到计算机30的处理器32，以允许计算机30的用户直接与计算机30交互。HMI40可以包括视频和/或字母数字显示器、触摸屏、扬声器，以及任何其它能够向用户提供信息的合适的音频和视觉指示器。HMI40还可以包括能够接受来自用户的命令或输入并且把录入的输入发送到处理器32的输入设备和控制装置，诸如字母数字键盘、指向设备、键盘、按钮、控制旋钮、麦克风等。

仅仅为了说明，以下描述将参考图3的内容管理系统100进行。

因此，通过各自的旅行社系统70连接到旅游管理系统100的不同旅行社可以通过独特的平台直接访问由一组旅游提供商系统(4，5)提供的任何类型的内容，无论内容是什么类型(诸如标准航线内容、出租车、娱乐门票，等等)。因此，旅游管理系统100提供存储不仅遵循标准PNR数据结构90的标准内容并且还有任何新类型内容(即，出租车路线、剧院门票、音乐会、美食，等等)的可能性，同时避免了让旅行社在GDS系统之外通过电话或者经互联网等等预订这种非标准内容的需求。

通过把非标准PNR91附加到标准PNR90，旅游管理系统可以动态并无缝地向旅行社系统70提供无限数量的旅行服务。

因此，扩展的扩展旅行记录9构成由任何旅游提供商系统4或5供给的内容的结构化表示(它可以对应于例如在GDS外部预订的产品)，同时在ETR9中维护的记录可以就好像标准PNR90和非标准PNR91构成独特记录数据结构一样被访问和管理。

标准PNR90中的标准数据元素(例如，产品)与可以根据由GDS1实现的遵循IATA标准的标准布局和格式被定性为可选或强制的一组属性关联。

在扩展旅游记录9中维护的数据可以被归类为多个系列，每个系列包括几个数据元素类型，诸如像表1中所表示的5个系列。ETR9适于支持任何数量的新数据元素类型和系列。

表1

行动	睡觉	吃喝	活动	服务
					飞机	宾馆	餐馆	体育活动	保险
渡船	公寓	酒吧&俱乐部	购物	Visa

乘船游览	野营	其它	演出&活动	美食
					火车	B&B	远足	证明文档
长途汽车	其它		参观	休闲装备
					城市交通		其它	当地服务
换乘车				会议
					出租车			疫苗
汽车				其它
					自行车
停车

内容管理引擎3被配置为管理ETR9的异构内容，这可以包括：

-对任何内容类型，在扩展旅游记录9中添加来自任何旅游提供商系统4或5的新数据元素，例如响应于来自旅行社系统70的请求；

-修改扩展旅游记录9中的数据元素(例如，通过改变对应于对博物馆的两张入场券的预先预订的“博物馆”产品的起始日期)；

-从扩展旅游记录9中删除数据元素(例如，如果用户决定从他到纽约的旅途中除去这个产品，则通过从扩展旅游记录中除去产品“博物馆”的预订)；

-从扩展旅游记录9中检索数据元素(例如，通过检索具体旅行记录中“博物馆”产品的所有结构化属性)。

扩展旅游记录9可以相应地既存储非标准内容又存储标准内容，就好像它们是唯一记录数据结构(PNR)的一部分一样。内容管理引擎3以透明的方式为用户客户端管理在扩展旅游记录9中维护的异构内容。扩展旅游记录9还是灵活的并且适于任何类型的新内容(出租车、地铁、公共汽车、博物馆购票，等等)，无论与新内容关联的属性是什么。

标准PNR90是根据IATA标准组织的。当给定的一组数据元素在与给定服务关联的应用流(例如预订管理流)中通过根据第一消息交换格式14的消息从标准旅游提供商系统4发送到内容管理引擎3时，可以由内容管理引擎3执行以下步骤：

i.数据可以由内容管理引擎3从由标准旅游提供商系统4发送的进入的消息中提取，及

ii.可以在标准PNR90中添加记录，该记录包括与对应于由内容管理引擎3提取的数据(内容数据)的数据元素相关联的记录标识符。

这样获得的数据可以被用来建立要发送到应用流中下一应用的另一个消息。

当应用流涉及一组链接的内部应用时，步骤i.可以由应用流中给定的内部应用执行，而步骤ii.可以由流中另一应用触发。

在标准PNR90中添加的数据只能具有有限数量的预定义属性并且要满足一个或多个预定义的类型和格式(标准化属性)。

非标准PNR91不遵循标准的规则和历史限制(IATA内容定义、TTY消息、IATA消息)。但是，非标准内容可以是扩展旅游记录9的一部分并且由内容管理引擎3执行的应用无缝且透明地访问。

因此，扩展旅游记录9可以以结构化的方式并且以通用的格式存储任何类型的标准内容(例如，诸如航班、宾馆、汽车、乘船旅行、保险、渡船的GDS内容)和非标准内容(诸如公共汽车/出租车/餐馆/等等)。

为了动态地管理任何类型的内容，内容管理引擎3被配置为响应于接收到的内容而创建非标准数据容器，其中所接收的内容包括从非标准内容提供商系统5发送到旅游管理系统100的非标准数据元素。由于非标准数据容器的自动串行化特性，非标准数据容器可以动态地适应内容管理系统中接收所述数据元素的内部应用的格式。当接收方内部应用是涉及一组链接的应用(内部应用)的应用流中的应用时，利用非标准数据容器的自动串行化特性，非标准数据容器可以动态地适应发送到其的每个内部应用的格式。

更具体而言，当旅游管理系统100连接到提供非标准内容类型的新旅游提供商5时，从非标准内容提供商系统5接收的非标准数据元素存储在这种被指定非标准内容类型的非标准数据容器中。然后，可以由内部应用在非标准记录数据结构91中添加记录(例如，在应用流中)。记录可以包括记录标识符和具有非标准内容类型的非标准数据容器。非标准数据容器可以包括属性列表，每个属性由关键字和值表示。每个属性自己可以包括子属性列表，每个子属性由关键字和值表示(对子属性也是类似地，等等)。每个属性关键字与名字和类型关联。非标准数据容器被配置为自实现其自身，无论它所代表的结构或者它所包含的数据是什么：对于作为非标准数据容器一部分的任何属性的任何值的只读访问或者读/写访问(即，获得或设置(get/set))，非标准数据容器使得经由既不依赖于关键字名字也不依赖于关键字类型的方法进行这种访问，而无需通过硬编码实现获得者/设定者(getter/setter)方法。

非标准数据容器可以相应地被用来在非标准PNR91中创建新纪录，无论内容是什么类型。对于任何类型的内容管理动作，这种记录可以被内容管理引擎3透明地访问，例如为了执行旅行应用、向客户端设备7生成服务请求结果的显示或者向外部设备(例如，旅游提供商系统或旅游设备)发送内容。

现在参考图5，给出了绘出用于响应于从一个或多个旅游提供商系统接收的内容而在扩展旅游记录9中创建新纪录的过程的流程图。

在方框501中，内容管理引擎3可以通过消息交换格式14和/或15从一个或多个旅游提供商4、5接收内容，例如，响应于来自诸如旅行社系统的客户端设备7的服务请求。

内容可以包括多个相关的数据元素，例如，与同一旅行相关的数据元素，诸如顺序接收的航班产品(标准数据元素)和出租车产品(非标准内容)。与公共内容关联的数据元素可以顺序地或者并行地接收。数据元素可以包括用于标识它们是同一公共内容的一部分的信息。

数据元素可以包括标准数据元素(例如，航班产品)和/或非标准数据元素(例如，出租车产品)。

标准数据元素(例如，GDS内容)可以根据诸如TTY的第一消息交换格式被接收。

非标准数据元素可以由数据交换单元11以根据标记描述语言定义的消息的形式被接收，其中标记描述语言诸如根据第二消息交换格式15的XML。对于旅游管理系统100与外部系统之间的数据互换，以下描述将参考XML消息(也被称为XML文档或文件)进行。数据交换消息可以包括结构描述文件，以描述消息的结构以及包含在消息中的数据的类型和格式。例如，对于类型XML的数据交换消息，XMLXSD架构可以被用作结构描述文件来提供XML消息的属性的结构的表示。

在方框502中，对于为公共内容接收的每个数据元素，内容管理引擎3可以提取数据元素。内容提取可以由内容管理引擎3的内部应用执行。

如果数据元素对应于标准内容(例如，航班产品)，则在方框503中内容管理引擎3利用标准数据容器(在下文中也被称为“标准容器”)在标准PNR(90)中创建用于标准内容(例如，航班产品)的具有该数据元素类型(例如，航班类型)的记录R。标准数据容器可以是被配置为用于预定义类型的数据元素(标准数据元素)的静态容器。在方框505中，记录R可以被指定记录标识符I并且可以与标准数据容器相关联。记录可以保存在临时上下文中和/或至少一个数据库8中。

如果数据元素对应于非标准内容(例如，出租车产品)，则在方框505中内容管理引擎3利用非标准数据容器(在下文中也被称为“非标准容器”)在非标准PNR(90)中创建用于标准内容(例如，航班产品)的记录R。步骤505可以由应用流的一个内部应用触发。触发ETR中记录创建的内部应用可以与从数据交换单元11接收非标准数据元素的内部应用不同。例如，第一内部应用A1可以以应用A1的格式F1接收非标准数据元素，该非标准数据元素可以发送到链中其它内部应用，直到它以应用An的格式Fn到达内部应用An，并且最终应用An触发在非标准记录数据结构91中创建记录(非标准数据容器具有格式Fn)。非标准数据容器可以被指定给所述数据元素的类型(例如，出租车类型)。

非标准数据容器适于包含任何类型的数据元素(非标准数据元素)。在方框506中，记录R可以被指定相同的记录标识符I并且可以与非标准数据容器关联。记录可以存储在临时上下文中和/或至少一个数据库中。

在一种实施例中，在方框507中，在方框506中创建的非标准数据容器还可以被指定标签。这种标签可以被内容管理引擎3在访问记录R时使用，例如为了标识不被发送到客户端设备7的数据元素。

因而，对于对应于公共内容的所有标准数据元素和非标准数据元素(相关的数据元素)，唯一记录标识符I可以在标准PNR90和非标准PNR91中创建。因此，这种公共记录标识符可以被共享，以操纵对应于异构数据元素的记录，就好像它们在独特的记录数据结构中被维护一样。例如，记录标识符I可以被内容管理引擎3使用，以允许应用读/写非标准数据元素，无论数据是什么类型。

在简化的例子中，扩展旅游记录9可以例如包括被指定公共记录标识符I1的几个记录，这种记录标识符ID1一般与以下数据元素关联：

-类型1的标准数据元素D1

-类型2的标准数据元素D2

-类型3的标准数据元素D3

-类型4加标签的非标准数据元素D4

-类型5的非标准数据元素D5

-类型2加标签的非标准数据元素D6

用于数据元素D1、D2、D3的记录与记录标识符ID1相关联地在标准记录数据结构90中维护。

用于数据元素D4、D5、D6的记录与记录标识符ID1相关联地在非标准记录数据结构91中维护(在非标准数据容器中)。

被用来包含标准数据元素的标准数据容器具体而言适于包含具有根据IATA标准的预定义类型和属性集合的数据元素。因此，标准数据容器只适于标准化的数据格式和数据类型。

非标准数据容器可以被创建，无论非标准数据元素是什么类型、属性和格式。每个属性自己可以包括多个子属性。

从而，内容管理引擎3使用非标准数据容器来动态地在扩展旅游记录(9)中创建新类型的内容，无论内容是什么类型。

非标准数据容器可以是多形态的数据容器，不像标准容器，它没有对给定的元素硬编码到代码中。相反，它必须采取的形式可以被动态定义。

非标准数据容器还可以具有自动串行化/反串行化属性。

在某些实施例中，非标准数据容器可以是由操纵其的内部应用的业务对象模型21表示的技术对象，这便于新内容在扩展旅游记录9中的集成。

图6示意性地表示根据本发明某些实施例的内容管理引擎3的内部应用的结构，其中非标准数据容器是业务对象模型21。内部应用可以是独立应用或者(构成相关应用的)应用链中的应用。

内部应用包括：

-结构化的接口2，

-业务对象模型21，

-业务层22。

结构化接口2代表应用彼此通信的方式。结构化接口可以传送要由应用处理的功能数据。它们可以映射到被业务层22使用的业务对象模型21，以执行验证动作并操作。除语法检查之外，验证动作还对应于由业务层22对数据执行的功能检查。在验证之后，数据元素可以以结构化的方式插入扩展记录数据结构9中。

因此，对扩展PNR9的数据结构的修改可以涉及对应用的业务对象模型21的修改以及对其结构化接口的修改。另外，为了受益于数据结构修改，可能的其它相关应用可能也需要修改它们的业务对象模型21、它们的结构化接口2并且在其它模块接口中集成新版本的数据模型。

本发明的各种实施例使得有可能通过使用非标准数据容器模型来限制与这种修改相关的成本。

在内容管理引擎3中运行的旅游服务应用可以根据图7的图来操作。BOM21代表用来表示由应用使用的内部数据模型的业务对象模型21。

服务210代表由旅游管理系统100从可被应用作为目标的客户端设备7、非标准旅游提供商5或者旅行者设备6接收的任何结构化消息(诸如XML或Edifact消息)。

上下文服务器211代表在与其它应用的异步交互之间由应用使用的数据的上下文存储(也被称为“上下文”)。

来自上下文的数据可以响应于请求、周期性地或者依赖于某些条件而保存在数据库8中。

图8说明了根据某些实施例在内容管理引擎3中链接的应用A1至AN之间的交互。当旅游管理系统100以分布式体系架构操作时，负责该过程的链接的内部应用A1至AN可以彼此调用，这会导致图7的体系架构的几个副本进入多个应用服务器30(也被称为后端服务器)，每个应用服务器30与各自的链接的应用Ai关联。在过程链当中每一步，在常规的方法中，在过程中从服务器30传递到另一个服务器之前，从用于应用A1的第一后端服务器30传送到用于应用An的最后一个服务器30的数据以不同的方式被变换、编码和解码。在访问数据元素之前，每个后端服务器30还解码进入的数据元素并且为其专用过程验证数据。然后，数据被编码，以便发送到链中下一个应用A_i+1。另外，业务对象模型21可以涉及在把信息填充到结构化接口2和从其检索信息的过程中并且可以被用来写/读数据。在常规的方法中，需要手工编码的部件把数据写入结构化接口2和中央记录存储库/从结构化接口2和中央记录存储库读数据。因而，到数据模型的单个变化可能是昂贵的。另外，应用在操纵的数据元素一般具有许多功能约束，使得每个应用可能需要确保所操纵的数据是以与行业约束(验证)兼容的合适格式。

因此，在常规方法中，每次当数据元素必需在这种链接的应用中被修改时，该过程的所有步骤会受影响，因为每个过程都必须向下一个过程发送新数据并且因此将必须解码它、验证它和编码它。另外，当新内容要添加到现有应用时，每个过程还必须向下一个过程发送新内容并且链中的每个过程必须解码、验证和编码新元素。

根据某些实施例的本发明通过使用BOM类型的非标准数据容器的自串行化特性改善了所述条件。

具体而言，响应于从非标准内容提供商5接收数据元素D1、D2和D3，非标准数据容器可以由链中第一个应用A1创建。这种非标准内容不能存储在标准PNR90中，因为诸如它不包括遵循PNR90的标准结构的数据类型和属性。非标准内容可以采取各种形式并且可以与各种类型和属性关联。

第一个应用A1可以以第一内部应用A1(例如协议缓冲区)的格式F1为每个非标准数据元素D_k创建例如非标准容器。然后，第一个应用A1利用非标准容器的自动串行化/反串行化特性利用消息M1把非标准容器传递到链中下一个应用。消息M1可以是携带自动串行化/反串行化信息的blob。然后，第二个应用A2可以以内部应用A2的格式F2提取非标准数据容器。类似地，第二应用可利用携带自动串行化/反串行化信息的消息M2、M3等等向链中其它应用发送非标准容器，直到应用An触发在ETR9中创建记录。

因而，通过使用非标准数据容器，不需要代码变化来向ETR9添加新数据结构，以便在内部应用链中更新数据结构或者发送数据元素。另外，不需要修改现有的数据结构。无需提取其并且将其从一种格式转换成另一种格式，就可以使由非标准数据容器所包含的数据可用。因此，可以减少中间/手工编码的层。

如图9的例子中所绘出的，非标准数据容器50可以由描述可被应用操纵的业务对象模型的一组关键字-值来定义。每个关键字51定义BOM的属性并且包括关联的值52(在图9中也被称为“数据”)。例如，由关键字“City(城市)”定义的非标准数据容器与值“Paris(巴黎)”关联。数据容器可以包括复杂的结构并且与任何种类的数据关联。例如，数据容器的一个或多个关键字可以进一步与参考53(在图9中被称为“REF”)关联，以便把给定的数据容器与一组相关数据容器关联。例如，由关键字/值对“phone(电话)/+335551213”指定的数据容器包括对以下数据容器的参考(“REF”)：“mobile(手机)/+336123456”和“home(家庭电话)/+335551213”。

对于非标准数据容器中所包含的任何数据元素，非标准数据容器50允许在写模式下对内容管理引擎3的访问，而无需开发访问器来允许这种访问。这确保灵活性和调整性。

另外，通过使用根据诸如Xpath之类的合适查询语言的查询，对非标准数据容器中所包含的数据元素的访问可以由内容管理引擎3在应用处理的任何时间执行。

非标准数据容器可以编程性地向后和向前兼容。从编程的角度，不需要代码变化来使用与非标准数据容器关联的新版本的数据元素结构。

非标准数据容器被配置为支持串行化/反串行化。特别地，串行化可以在非标准内容的一个或几个属性被创建和修改时执行，以便以可扩展的格式编码数据容器，并且反串行化可以在每次应用需要读非标准内容的至少一个属性时被执行。

具体而言，通过把代表非标准数据容器的技术对象(例如，BOM)的状态翻译成可以被反串行化机制存储和重构的格式(例如，二进制表示)以便把数据容器恢复到其原始状态，非标准数据容器关键字和值可以在任何时候被串行化。从而，非标准数据容器可以被变换成任何目标格式，无论数据容器中所包含的是什么数据。串行化和反串行化机制不需要硬编码。串行化信息可以嵌入在与数据容器关联的库中。因此，这种BOM的使用自然地提供了可以对由非标准数据容器的关键字定义的任何种类结构被支持的串行化机制，而无需具体的编码。在某些示例性实施例中，被用来根据串行化/和反串行化机制翻译其状态的非标准数据容器的表示格式可以基于例如XML、ASCII、JSON、二进制格式，如图10中所说明的。

非标准数据容器的值的验证可以只在由非标准数据容器对象表示的数据元素被创建和修改时需要。因而，不需要读过程来重新验证关联到关键字的数据元素。

通过使用非标准数据容器，与内容类型相关的信息(例如，飞机、出租车、体育节目、停车、城市交通，等等)可以被传送到非标准数据容器本身当中。非标准数据容器的类型可以作为关键字直接存储在非标准数据容器中。

在一些实施例中，在给定的非标准数据容器创建或修改时的验证机制可以基于作为关键字存储在非标准数据元素中的功能类型，而不是像常规方法中的C++类型。

在某些实施例中，每种类型的非标准数据容器可以与描述数据元素的属性结构(属性布局、属性依赖性以及属性格式，等等)的结构描述文件(例如，XSD)关联。

结构描述文件(例如，XSD)还代表表示为技术对象(例如，XML对象)的非标准数据容器的属性和元素之间的相互关系。在与非标准数据容器关联的XSD架构中，非标准数据容器的不同关键字/值以及应用到其的辅助约束可以利用一组XML标签来描述。结构描述文件可以在非标准数据容器创建和修改时被使用。此外，辅助约束可以利用结构描述文件(例如，XSD)应用到非标准数据容器。

与每个非标准数据容器关联的结构描述文件可以被用来在非标准数据容器创建或修改时验证非标准数据容器属性。验证机制可以包括检验由非标准数据容器表示的非标准数据元素是否遵守内容被放在其中的数据元素的描述。在某些实施例中，验证机制可以实现为，通过使用与非标准数据容器关联的结构描述文件，验证存储在非标准数据容器中的数据是否匹配目标格式。

旅游管理系统100可以维护用于存储与和非标准数据容器关联的结构描述文件一致的非标准数据容器的数据类型的表。该表可以是在过程运行时被更新。

内容管理引擎3可以被配置为，通过更新描述非标准数据容器结构的结构描述文件(例如，XSD)，把新数据添加到非标准数据容器中，诸如新属性。

在无需硬编码变化和重新编译代码的情况下，定义非标准数据容器的结构描述文件(例如，XSD)可以被修改。因此，非标准数据容器的修改是动态的并且在运行时可更新。

图11是图9的示例性非标准数据容器的示意图，示出了它们各自的类型：电话(Phone)类型、地址(Address)类型、GPS类型。信息类型可以作为属性存储在非标准数据容器中。这种信息可以被用来检索与非标准数据容器关联的结构描述文件。

图12说明了用于具有不同类型(“PhoneType”、“AddressType”、“GPSType”)图11的示例性非标准数据容器的XSD描述文件。

根据某些实施例，内容管理引擎3还可以在由旅游管理系统100向客户端设备7暴露的独特平台中生成一组内部服务接口2，无论返回到客户端设备7的内容的类型和由内容管理引擎3维护的应用是什么。

扩展旅游记录9可以被大量应用使用。例如，内容管理引擎3可以包括一组应用(例如，旅游应用)，用于根据从标准旅游提供商系统4(例如，飞行产品)和从任何其它旅游提供商系统5(例如，非飞行产品)接收的外部内容向客户端设备7交付不同类型的旅游服务，无论内容是什么类型。这种服务可以包括例如购物、预订、定价、发行、退款服务。

这种服务应用可以响应于来自通过客户端设备7连接到旅游管理系统100的系统(例如，旅行社系统70)的服务请求而被执行，而无需通过硬编码使每个应用适应添加到ETR9的N种类型的数据。

结果可以利用诸如XML消息的给定格式的响应消息通过数据交换单元11返回。因此，由旅游管理系统(100)生成的内部服务接口2可以是XML类型的。

为了避开记录并重新编译每个应用以便支持任何数量新类型的非标准数据容器的需求，可以使用具有独特类型(通用元素类型)的通用元素。通用元素是被配置为包含任何类型的非标准数据容器的大型数据容器。通用元素可以被所有服务应用看作独特类型(在下文中被称为“通用元素类型”)的容器，同时通用元素可以包含无限数量N个非标准数据类型。

因此，每个应用可以把通用元素实例化为能够独立于数据容器中所包含的数据元素的类型而无缝地操纵非标准容器。因而，每个应用不需要实例化像新数据类型那么多的非标准数据容器。

因此，新内容类型向非标准PNR91的添加不影响或不需要为了确保向后兼容性而适应由内容管理引擎3处理的应用(例如，通过硬编码)。

图13是绘出由应用从具有给定记录标识符I的ETR9对记录进行访问的流程图。例如，记录标识符I可以包括：

-类型T1的标准数据元素SD1

-类型T2的标准数据元素SD2

-类型T3的非标准数据元素NSD3，包含在非标准数据容器中

-类型T4的非标准数据元素NSD4，包含在非标准数据容器中

在方框600中，与记录标识符I关联的记录从ETR9被检索。记录可以与具有各自类型T1、T2、T3、T4的标准数据元素(SD1、SD2)和非标准数据元素NSD3、NSD4(非标准数据容器)相关联。

然后，每个数据元素SD1、SD2、NSD3和NSD4被单独处理。

具体而言，对于每个数据元素，诸如像NSD3，如果数据元素是非标准数据元素(方框601)，则在方框602中类型T3的非标准数据元素被变换成包含类型T3的非标准数据元素的唯一通用元素类型的通用元素。作为大型数据容器的通用元素可以自己包含具有具体类型的非标准数据容器。通用元素可以被实现为诸如BOM的技术对象，并且可以基于与非标准数据容器相同的技术。

如果数据元素是标准数据元素(方框603)，诸如像SD1，则在方框604中类型T1的标准数据元素可以被转换为相同类型T1的非标准数据容器。

在方框602中，这样获得的非标准数据元素被变换成包含对应于非标准数据元素NSD1的类型T1的非标准数据元素的独特通用元素类型的通用元素。

通用元素构成非标准数据元素的过渡状态，这使得应用有可能无缝地操纵标准数据元素和非标准数据元素，无论它们是什么类型。因此，应用可以操纵ETR9的数据元素，而无需明确知道非标准内容的类型，就像它们具有独特的类型一样。

在方框605中，如果应用的执行需要一个或多个数据元素被发送到发起服务请求的客户端设备7的接口，则应用可以内省(introspect)通用元素，以访问数据元素的类型。

在本发明的某些实施例中，非标准数据元素可以与各自的标签相关联。在这种实施例中，在方框601中，只有与各自标签相关联的非标准数据元素可以由应用选择并变换为通用元素。

因而，通用元素抽象非标准数据元素的类型：代替在每次新类型的内容必须被应用处理时(新内容在ETR9中添加时)定义新元素类型，每个应用可以因此实例化能够支持任何新内容类型和属性的独特通用元素。

返回图3，旅游管理系统100可以适于通过内部接口2与任何外部客户端设备，诸如旅行社系统70、非标准旅游提供商系统5或者同一GDS内部的任何其它后端服务器，交换任何类型的内容(标准的和非标准的内容)。

在常规方法中，通过实现到由目标客户端设备支持的标准格式的硬编码转换，旅游管理系统100可以与对于PNR内容的格式(目标PNR内容格式)具有其自己的标准的其它目标客户端设备(例如，旅游提供商系统、旅行社系统)交换来自标准PNR的数据。这需要在旅游管理系统100的编码机制和在目标设备的解码/验证机制。事实上，每个旅游管理系统可以对PNR内容的格式(源PNR内容格式)具有其自己的标准并且由此目标设备的接口只支持这种格式。以昂贵并且静态的方法，这种转换(编码/解码/验证)目前涉及硬编码和重新编译。

数据交换单元11允许根据第二数据交换格式15从外部客户端设备接收或发送数据交换消息，以交换任何类型的内容。在优选实施例中，第二数据交换格式15是诸如XML的标记描述语言。对应于非标准数据元素的每个数据交换消息包括定义数据元素的属性(属性布局和格式)的结构描述文件，诸如用于XML消息的XSD，以及对应于属性值的一组值。

图14更详细地表示根据某些实施例的数据交换单元11的结构。

数据交换单元11可以被用来与诸如非标准旅游提供商5、旅行社系统或另一非GDS系统的外部客户端设备交换数据元素。特别地，数据交换单元11可以被用来：

-从客户端设备接收非标准数据元素；或者

-把数据元素从ETR9发送到客户端设备。

数据交换单元11可以包括结构变换引擎111，诸如用于把诸如XSD的结构描述文件从源结构描述文件XSD1变换成目标结构描述文件XSD2的XSLT引擎，以及用于以根据诸如XML的描述语音定义的消息的形式发送数据的数据交换消息发生器112。XSLT引擎可以使用定义用于以接收模式变换源结构描述文件XSD1的变换规则的预定义的本地映射规则113(例如，XSLT样式表)或者定义以发送模式变换源结构描述文件XSD1的变换规则的预定义的客户端映射规则117(例如，XSLT样式表)。

旅游管理系统100可以在运行时动态地维护或加载一个或多个与不同内容类型相关联并且对应于要由旅游管理系统100本地应用的结构描述文件的预定义的本地结构描述文件115。

在接收模式，数据交换单元11可以从外部客户端设备7接收符合由外部客户的设备7定义的源结构描述文件XSD1的进入的数据交换消息XML1。进入的消息XML1包含给定类型Ti的非标准数据元素。

每次当这种进入的数据交换消息XML1被包括非标准数据元素的旅游管理系统100接收时，变换引擎111可以利用与包含在数据交换消息XML1中的数据元素的类型相关联的本地映射规则113把进入的消息的结构描述文件XSD1变换成目标结构描述文件XSD2。然后，目标结构描述文件XSD2被添加到本地结构描述文件115的集合。

在把源结构描述文件XSD1变换成目标结构描述文件XSD2之前，数据交换单元11还可以向进入的消息XML1应用验证机制，以验证与结构描述文件XSD1的属性相关的多个条件(例如，强制属性的存在)。

然后，类型Ti的非标准数据容器可以通过把数据交换消息XML1的字段映射到非标准数据容器的原语而生成。然后，非标准数据容器与存储在115中的用于类型Ti的目标结构描述文件(XSD2)相关联地被添加到ETR9，如关于图5所描述的。ETR9中新内容的任何更新或添加可以在运行时进行。

因此，数据交换单元11的使用使得有可能动态地把从内容提供商系统4、5接收的任何进入的数据交换消息转换成代表要添加/修改的元素的几个非标准数据容器对象，而无需任何代码改变。

在发送模式(虚线)，旅游管理系统100可以通过数据交换单元把任何数据元素从ETR发送到外部客户端设备7的目标接口中。

在发送模式，数据交换单元11接收非标准数据容器作为输入(包含之前被转换成非标准数据容器的类型为Ti的非标准数据元素或标准数据元素)。

类型为Ti的非标准数据容器与包括非标准数据容器的属性、属性布局以及属性格式的描述的结构描述文件(被称为源结构描述文件)，诸如XSD文件(115)，关联。非标准数据容器还与对应于属性的值的关键字值关联。

如果要被旅游管理系统100发送的数据元素包括来自ETR9的给定类型Ti的非标准数据容器，则变换引擎111可以利用与非标准数据元素的类型相关联的客户端映射规则117把与本地结构描述文件115中的非标准数据容器相关联的结构描述文件XSD3变换成目标结构描述文件XSD4。客户端映射规则117朝目标客户端设备7的接口的格式定义变换规则，例如，用于向目标客户的设备7的图形用户接口(GUI)显示。

如果要发送到客户端设备7的数据元素是类型为Ti的标准数据元素(例如，GDS元素)，则标准数据元素可以事先利用数据容器转换器12被转换成相同类型的非标准数据容器。然后，标准数据元素可以以非标准数据容器的形式被发送到数据交换单元11，用于发送到目标客户端设备7。

图15绘出了根据某些实施例用于把类型Ti的数据元素发送到客户端设备7的目标接口(图形用户接口GUI)的流程图。

如果数据元素是标准数据元素(方框700)，则在方框701中类型Ti的标准数据元素可以被转换成相同类型Ti的非标准数据容器(类似于图12的方框604)。然后在方框703中，与结构描述文件XSD1和关键字值Vi相关联，标准数据元素以类型Ti的非标准数据容器的形式被处理。

如果数据元素是形式为与结构描述文件XSD1和关键字值Vi相关联的类型Ti的非标准数据容器的形式(方框700)，则在方框703中类型Ti的非标准数据元素被直接处理。

在方框703中，与非标准数据容器关联的源结构描述文件XSD1被检索。

在方框704中，利用映射引擎110(例如，XSLT引擎)，源结构描述文件XSD1被转换成目标结构描述文件XSD2，以解析源结构描述文件XSD1并且利用映射规则113(例如，XSLT样式表)把解析后的字段转换成目标结构描述文件XSD2。映射规则113是根据客户端设备7的目标接口的格式定义的。

在方框705中，包含要发送到客户端设备的数据元素的XML消息是通过添加与非标准数据容器相关联的值Vi生成的。

在方框706中，XML消息通过网络13被发送到客户端设备7的目标接口。该目标接口可以响应于XML消息的响应而被动态和透明地修改。

外部客户端设备7还可以提取包含在XML消息中的数据元素并且根据其自己的标准存储，而无需对数据应用解码和复杂的验证机制，无论数据的类型和目标接口的格式是什么。

通过使用与结构描述文件相关联并且具有以任何格式15(例如，XML)作为数据交换消息串行化它们自己的能力的非标准数据容器，新型接口2可以这样被建立。

在一种实施例中，利用尽可能少的手工编码软件，数据交换单元11可以被内容管理引擎3用来向客户端设备7(例如，旅行社系统)的接口动态地生成请求结果的一致表示，无论内容是什么类型(标准的、非标准的、混合的内容)。

服务应用可以直接使用同构数据结构在接口2中存储数据。这避开了在接口层与BOM层之间交换还有另一格式的数据结构的需求。这进一步允许通过独特的平台减少存储在扩展旅游记录中的数据与暴露给客户端设备7(例如，旅行社系统)的服务接口中的数据表示之间的开销。

具体而言，图13的方法可以被用来响应于来自客户端设备7(例如，旅行社系统70)的服务请求而生成结果的表示以及这种表示在与客户端设备接口上服务相关联的用户图形接口上的显示，同时确保表示是同构的，无论内容是什么类型(标准内容或非标准内容)。

当与非标准内容和/或标准内容关联的记录标识符在扩展记录数据结构9中被添加时，服务应用适于动态并同构地生成记录的表示，无论新类型是什么。

对应于服务请求的内容管理引擎3的应用可以利用通用元素根据图12的访问方法访问对应于从ETR获得的结果的记录。

无论要返回到客户端设备7的内容是什么类型，基于唯一的通用元素对非标准数据容器(50)的访问的实现允许每个应用支持来自非标准内容提供商系统5的任何类型的内容。因此，内容管理引擎3中的应用独立于内容的类型。

为了把结果返回到旅行社系统70的接口，应用可以内省通用元素，以访问非标准数据容器(图6的方框605)。因此，这样被访问的非标准数据容器可以根据图14的方法返回。

因此，内容管理引擎3适于向包括每个服务(例如，旅行服务)一组接口的所有客户端设备7提供唯一的平台，该平台代表独立于要被操纵的产品类型的唯一响应(例子：典型GDS飞行产品(航班)/GDS汽车租赁/非GDS出租车/非GDS餐馆…)。

为了方便新内容在应用中的集成，与应用关联的内部服务接口2可以具有用于每个内容系列的一组公共属性。这使得已经存在的内容系列的新元素受益于可用于该系列的所有显示功能。

具体而言，非标准数据容器(50)的底层数据结构可以在具体的元素分类中共享公共格式。例如，用来表示类型为航线段的数据元素的格式描述文件XSDi可以是相同的，不管是通过旅游管理系统(100)预订的还是经另一外部预订系统预订的。还可以与来自另一类(例如，运输类)的元素共享一组公共数据。

特别地，变换引擎111可以被定义为使得，对于ETR9中与非标准数据元素和标准数据元素都关联的给定记录标识符I1，如果非标准数据元素和标准数据元素都是相同的一般类型(例如，“宾馆”)，则通过把与非标准数据元素关联的结构描述文件XSD1和与标准数据元素关联的结构描述文件XSD2映射到符合目标接口的公共类型的相同结构描述文件，相同的表示可以在外部客户端设备7(例如，旅行社系统)的目标接口为两种数据元素都生成。

例如，如图16中所绘出的，类型为TYPEC的标准数据元素首先被转换为与相同类型TYPEC关联的非标准容器(图7的方框701)，然后利用变换引擎111和在客户端设备用于TYPEC的映射规则117(样式表)向客户端设备生成对TYPEC的表示(XSD2)。如图17的例子中所示，相同的表示(XSD2)将被用于类型TYPEC的非标准容器。

而且，变换规则117可以定义为使得任何数据元素中相同类型的属性将被映射到相同的子表示，无论(在目标描述文件中)包括所述属性的是什么内容类型(非标准的或标准的)。

在图18中所绘出的例子中，包括一组属性A1、A2、A3、A4的类型TYPED的标准容器(如在源结构描述文件XSD1中所定义的)首先被转换为与相同类型TYPED关联的非标准容器(图1的方框701)，然后利用变换引擎111向客户端设备生成用于TYPED的表示XSD2(目标结构描述文件)，表示XSD2包括对应于源属性{A1,A2,A3,A4}的表示属性{E1,E2,E3,E4}。如图19的例子中所示，通过对源结构定义文件XSD的相似属性应用相同的映射规则117，相同的表示{E2,E3}可以为包括属性集{C1,A1,A3,C4}的另一种类型TYPEC的非标准容器的属性A2、A3生成。因此，映射引擎11将为属性A2和A3分别生成具有相同表示E2和E3的表示XSD3＝{F1,E2,E3,F4,F5}。

因而，内容管理引擎3对(与例如旅行社系统关联的)所有客户端设备7提供为每个应用包括一组接口的独特平台，通过这些接口，可以独立于要被操纵的内容的类型(例如，GDS航班产品、GDS汽车租赁、非GDS出租车、非GDS餐馆，等等)生成唯一响应。

因此，服务应用可以直接使用同构的数据结构在接口中存储数据。这避开了在接口层与BOM层之间交换数据结构的还有另一种格式的需求。通过独特的平台，这进一步允许减小存储在扩展旅游记录9中的数据与暴露给客户端设备7(例如，旅行社系统)的服务接口2中的数据表示之间的开销。

因而，数据交换单元11使得有可能利用尽可能少的手工编码软件动态地生成结果的一致表示，无论内容是什么类型(标准的、非标准的、混合的内容)。

特别地，用来把结果返回到客户端设备7的数据交换消息具有接近内部结构(例如，XML)的格式并且这种格式是从用来在通用元素中定义元素本身的结构描述文件(例如，XSD)继承来的。

因此，内容管理系统100为每种旅游服务提供一组接口，代表独立于要被操纵的产品类型(例如：典型的GDS飞行产品(航班)/GDS汽车租赁/非GDS出租车/非GDS餐馆…)的独特响应。

图20绘出了根据某些实施例的内容重新安排方法的流程图。与ETR9中的公共记录标识符关联的内容包括与同一旅行相关的一组数据元素。在被应用访问时，依赖于需要ETR9中特定记录标识符的应用，应用可能需要与给定记录定位器关联的不同数据元素根据预定义的重排标准(例如重新排序标准)被安排(例如，排序)。

内容重排方法可以被实现为根据由应用预定义的预定义重排标准，诸如时间顺序、排名标准等等，重排数据元素。重排方法可以基于抽象元素把标准的和非标准的数据元素合并到抽象排名模型中。抽象元素可以被用来根据重排标准把数据元素排序。因此，应用可以返回根据目标接口约束排序的合并后的数据元素。这会导致例如聚合的行程文档，其中PNR段和扩展元素(非标准内容)可以在相同的视图中合并。

具体而言，对于每个数据元素，如果数据元素是非标准数据元素(方框801)，则在方框802中类型Ti的非标准数据元素被变换成独特类型的抽象元素，该独特类型包含类型Ti的非标准数据元素的属性的子集。非标准数据容器的属性根据过滤规则被过滤，其中过滤规则是例如基于重排标准(例如，过滤标准将选择日期属性的时间顺序)生成的。抽象元素可以实现为诸如BOM的技术对象，并且可以基于与非标准数据容器和/或通用元素相同的技术。应当指出，通用元素和抽象元素都允许数据元素的类型的抽象。

如果数据元素是类型为Ti的标准数据元素(方框803)，则在方框804中它可以被转换为相同类型Ti的非标准数据容器(类似于图6的步骤604)。

在方框805中，这样获得的非标准数据元素的属性根据过滤标准被过滤。

在方框806中，在步骤804中获得的非标准数据元素被变换成抽象元素，该抽象元素包含对应于类型Ti的标准数据元素的类型Ti的非标准数据元素的过滤后的属性集合。

类似于通用元素，所获得的抽象元素构成非标准数据元素的过渡状态，这使得有可能抽象数据容器类型。通过内省抽象模型并且根据重排标准具体地安排它们，这还使得能够由应用对过滤后的数据元素属性进行全局操纵，无论它们是什么类型。

在旅游领域，标准PNR90可以被存储在在多个系统之间共享的存储区域中。在标准PNR90中维护的标准数据元素可以是不同的类型并且每个元素可以具有其自己的串行化格式。如果数据元素是相关的(例如，同一乘客或行程公共的)，则标准数据元素可以共享相同的记录标准。

类似地，如果数据元素是相关的，则非标准PNR91中的数据元素可以与非标准PNR91或标准PNR中的另一数据元素共享相同的记录标识符。非标准PNR91可以存储在与标准PNR相同的存储区域中。作为替代，标准PNR90和非标准PNR91可以存储在不同的存储区域中。这两个区域可以由全局管理机制管理，以允许公共数据的同步。关于需要操纵整个扩展旅游记录9的每个查询，全局管理机制可以被实现为把专用于非标准PNR91的存储区域链接到专用于标准PNR90的其它存储区域。

即使ETR9被分割成两个记录数据结构90和91，ETR9也可以基于标识相关数据元素的公共记录标识符、辅助容器数据和/或记录数据结构信息被全局管理。

辅助数据容器数据可以包括关于每个数据容器的控制信息(例如，创建日期、最后修改日期，等等)。在常规方法中，这种信息与记录标识符0关联地直接存储在每个标准数据容器中并且可以被访问，以管理标准PNR(例如，为了周期性地清除标准PNR)。但是，这种方法不允许对两个记录数据结构90和91的优化管理。

图21代表根据某些实施例的ETR9的结构。如图所示，为了优化两个记录数据结构90和91的全局管理，在一些实施例中，扩展旅游记录9还可以包括用于维护关于在ETR9中创建的每个数据容器的辅助容器数据的辅助数据结构92(也被称为“中央管理数据结构”或“中央管理区域”)，诸如数据容器的创建日期、数据容器的最后修改日期，等等。在辅助数据结构92中维护的信息可以被用来以同步的方式管理两个区域。辅助数据结构92中的每个条目可以共享与在ETR9中创建的数据容器相同的记录标识符。另外，辅助数据结构92中的每个记录可以与关联到在ETR9中维护的数据容器的一组辅助容器数据关联(具有相同的记录标识符)。辅助数据结构92可以利用在标准记录数据结构90和非标准记录数据结构91中包含的数据容器信息填充。

在一些实施例中，辅助数据结构92的每个条目可以包括关于在扩展记录数据结构(9)中共享相同记录标识符的数据容器的辅助属性集合。每个条目可以包括用于存储关于ETR9中共享相同记录标识符的记录的辅助容器数据集合的辅助数据容器。辅助容器数据集合可以包括代表关于ETR9中共享记录标识符的记录的控制信息的控制属性，诸如前一个记录清除日期。

在一些实施例中，关于给定记录数据结构90或91的所有记录的数据容器信息可以在这种记录数据结构(90或91)中的专用记录(也被称为“容器信息记录”)中维护并且可以被指定特定的记录标识符(例如，记录标识符0)。标准记录数据结构90的容器信息记录和/或非标准记录数据结构91的容器信息记录可以以不同的时间间隔拷贝到非辅助数据结构92，例如周期性地或者响应于查询或者作为替代在每次ETR9在一个或多个数据库8中保存时。

辅助数据结构92还可以维护关于标准记录数据结构和/或非标准记录数据结构的记录数据结构信息，诸如标识数据库中标准记录数据结构90和/或非标准记录数据结构91的最后版本的版本信息。

旅游管理系统100可以包括ETR控制单元18，该单元18用于基于包括在辅助数据结构92中的数据(辅助容器数据信息和/或标准记录数据结构信息90和/或非标准记录数据结构信息91)管理ETR9。

在一种实施例中，ETR控制单元18可以包括清除模块180，该模块被配置为，利用公共记录标识符、在辅助数据结构92中维护的辅助容器数据和/或记录数据结构信息，以同步的方式对公共数据周期性地从标准PNR90和从非标准PNR91清除记录。

在某些实施例中，ETR控制单元18可以包括访问管理器181，以便基于在辅助数据结构92中维护的数据处理对标准PNR90中和非标准PNR91中相同记录标识符的同时访问。在这种实施例中，辅助数据结构还可以维护标识标准记录数据结构90和非标准记录数据结构91在数据库8中的最后版本的版本信息。例如，每次当ETR9从上下文保存到数据库中时，版本信息在辅助数据结构92中被更新。访问管理器18可以被配置为基于在辅助数据结构92中维护的版本信息管理对ETR9的访问。

体现本文所述的本发明任何实施例的程序代码能够单独地或者共同地作为程序产品以各种不同形式分发。特别地，程序代码可以利用计算机可读介质来分发，所述介质可以包括计算机可读存储介质和通信介质。固有地是非临时性的计算机可读存储介质可以包括在用于诸如计算机可读指令、数据结构、程序模块或其它数据之类的信息存储的任何方法或技术中实现的易失性和非易失性以及可移除和不可移除的有形介质。计算机可读存储介质还可以包括RAM、ROM、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、闪存存储器或其它固态存储器技术，便携式光盘只读存储器(CD-ROM)或其它光学存储器，磁带盒、磁带、磁盘存储或其它磁存储设备，或者可被用来存储所需信息并且可被计算机读取的任何其它介质。通信介质可以体现计算机可读指令、数据结构或其它程序模块。作为例子但不是限制，通信介质可以包括诸如有线网络或直接连线连接的有线介质，以及诸如声学、RF、红外线和其它无线介质的无线介质。以上所述的任意组合也可以包括在计算机可读介质的范围内。

本文所描述的方法可以由提供给任何类型计算机的处理器的计算机程序指令实现，以产生一种具有处理器的机器，该处理器执行指令，以实现本文规定的功能/动作。这些计算机程序指令还可以存储在可以指导计算机以特定方式工作的计算机可读介质中。为此，计算机程序指令可以被加载到计算机上，以引起一系列操作步骤的执行并由此产生计算机实现的过程，使得所执行的指令提供用于实现本文规定的功能/动作的过程。

虽然本发明的实施例已经通过各种例子的描述进行了说明，并且虽然这些实施例已经相当详细地进行了描述，但申请人的意图并不是要限制或者以任何方式把所附权利要求的范围限定到这种细节。另外的优点和修改将是本领域技术人员很容易想到的。因此，在其更广泛的方面，本发明不限于所示出并进行了描述的具体细节、代表性方法和说明性例子。特别地，虽然抽象元素已经描述为用于重排内容，但也可以更一般地由内部应用来访问用于不同类型操作的内容。应用到数据容器的过滤属性的过滤规则可依赖于预期的操作而变。

Claims

1.一种在内容管理系统(100)中管理扩展记录数据结构(9)的方法，所述记录数据结构包括形式为标准数据容器的、用于存储包括预定义标准类型的标准数据元素的记录的标准记录数据结构(90)和形式为非标准数据容器的、用于存储包括具有与所述预定义标准类型不同类型的非标准数据元素的记录的非标准记录数据结构(91)，所述扩展记录数据结构(9)中的每个记录包括记录标识符，记录对应于扩展记录数据结构(9)中共享公共记录标识符的相关数据元素，该方法包括，对于在扩展记录数据结构(9)中为具有给定记录标识符的数据元素创建的每个记录，在辅助数据结构(92)中创建条目，所述条目共享所述给定的记录标识符并且包括辅助数据容器，所述辅助数据容器包括关于共享记录数据结构中相同记录标识符的数据容器的一组属性，该方法基于在辅助数据结构(92)中维护的数据来管理所述扩展记录数据结构(9)。

2.如权利要求1所述的方法，其中该方法包括响应于扩展记录数据结构在数据库(8)中的保存而更新辅助数据结构(92)。

3.如前面任何一项权利要求所述的方法，其中扩展记录数据结构(9)以不同的时间间隔保存在数据库(8)中，并且其中该方法包括基于在辅助记录数据结构(92)中维护的数据容器的属性周期性地从在所述数据库中维护的扩展记录数据结构中清除记录。

4.如权利要求3所述的方法，其中共享给定记录标识符的每个辅助数据容器包括控制属性，该控制属性代表关于扩展记录数据结构(9)中共享相同记录标识符的记录的控制信息。

5.如权利要求4所述的方法，其中所述控制属性包括扩展数据结构(9)中共享相同记录标识符的记录的清除日期。

6.如前面任何一项权利要求所述的方法，其中所述辅助数据结构(92)还包括关于标准记录数据结构和非标准数据结构的记录数据结构信息。

7.如权利要求6所述的方法，其中记录数据结构信息包括标识所述至少一个数据库中标准记录数据结构(9)的和非标准数据结构的最后版本的版本信息。

8.如权利要求7所述的方法，其中该方法包括基于所述版本信息管理对扩展记录数据结构的访问。

9.一种在内容管理系统(100)中管理扩展记录数据结构(9)的系统，所述记录数据结构包括形式为标准数据容器的、用于存储包括预定义标准类型的标准数据元素的记录的标准记录数据结构(90)和形式为非标准数据容器的、用于存储包括具有与所述预定义标准类型不同类型的非标准数据元素的记录的非标准记录数据结构(91)，所述扩展记录数据结构(9)中的每个记录包括记录标识符，记录对应于扩展记录数据结构(9)中共享公共记录标识符的相关数据元素，管理扩展记录数据结构的系统被配置为，对于在扩展记录数据结构(9)中为具有给定记录标识符的数据元素创建的每个记录，在辅助数据结构(92)中创建条目，辅助数据结构(92)中的所述条目共享所述给定的记录标识符并且包括辅助数据容器，所述辅助数据容器包括关于共享记录数据结构中相同记录标识符的数据容器的一组属性，该系统还被配置为基于在辅助数据结构(92)中维护的数据管理所述扩展记录数据结构(9)。