旅游记录中除去产品"博物馆"的预订）；
[0094] -从扩展旅游记录9中检索数据元素（例如，通过检索具体旅行记录中"博物馆" 产品的所有结构化属性）。
[0095] 扩展旅游记录9可W相应地既存储非标准内容又存储标准内容，就好像它们是唯 一记录数据结构（PNR)的一部分一样。内容管理引擎3W透明的方式为用户客户端管理在 扩展旅游记录9中维护的异构内容。扩展旅游记录9还是灵活的并且适于任何类型的新内 容（出租车、地铁、公共汽车、博物馆购票，等等），无论与新内容关联的属性是什么。
[0096] 标准PNR90是根据IATA标准组织的。当给定的一组数据元素在与给定服务关联 的应用流（例如预订管理流）中通过根据第一消息交换格式14的消息从标准旅游提供商 系统4发送到内容管理引擎3时，可W由内容管理引擎3执行W下步骤：
[0097] i.数据可W由内容管理引擎3从由标准旅游提供商系统4发送的进入的消息中提 取，及
[009引 ii.可W在标准PNR90中添加记录，该记录包括与对应于由内容管理引擎3提取 的数据（内容数据）的数据元素相关联的记录标识符。
[0099] 运样获得的数据可W被用来建立要发送到应用流中下一应用的另一个消息。
[0100] 当应用流设及一组链接的内部应用时，步骤i.可W由应用流中给定的内部应用 执行，而步骤ii.可W由流中另一应用触发。
[010。 在标准PNR90中添加的数据只能具有有限数量的预定义属性并且要满足一个或 多个预定义的类型和格式（标准化属性）。
[0102] 非标准PNR91不遵循标准的规则和历史限制（IATA内容定义、TTY消息、IATA消 息）。但是，非标准内容可W是扩展旅游记录9的一部分并且由内容管理引擎3执行的应用 无缝且透明地访问。
[0103] 因此，扩展旅游记录9可结构化的方式并且W通用的格式存储任何类型的标 准内容（例如，诸如航班、宾馆、汽车、乘船旅行、保险、渡船的GDS内容）和非标准内容（诸 如公共汽车/出租车/餐馆/等等）。
[0104] 为了动态地管理任何类型的内容，内容管理引擎3被配置为响应于接收到的内容 而创建非标准数据容器，其中所接收的内容包括从非标准内容提供商系统5发送到旅游管 理系统100的非标准数据元素。由于非标准数据容器的自动串行化特性，非标准数据容器 可W动态地适应内容管理系统中接收所述数据元素的内部应用的格式。当接收方内部应用 是设及一组链接的应用（内部应用）的应用流中的应用时，利用非标准数据容器的自动串 行化特性，非标准数据容器可W动态地适应发送到其的每个内部应用的格式。
[0105] 更具体而言，当旅游管理系统100连接到提供非标准内容类型的新旅游提供商5 时，从非标准内容提供商系统5接收的非标准数据元素存储在运种被指定非标准内容类型 的非标准数据容器中。然后，可W由内部应用在非标准记录数据结构91中添加记录（例 如，在应用流中）。记录可W包括记录标识符和具有非标准内容类型的非标准数据容器。非 标准数据容器可W包括属性列表，每个属性由关键字和值表示。每个属性自己可W包括子 属性列表，每个子属性由关键字和值表示（对子属性也是类似地，等等）。每个属性关键字 与名字和类型关联。非标准数据容器被配置为自实现其自身，无论它所代表的结构或者它 所包含的数据是什么：对于作为非标准数据容器一部分的任何属性的任何值的只读访问或 者读/写访问（即，获得或设置（get/set))，非标准数据容器使得经由既不依赖于关键字 名字也不依赖于关键字类型的方法进行运种访问，而无需通过硬编码实现获得者/设定者 (getter/setter)方法。
[0106] 非标准数据容器可W相应地被用来在非标准PNR91中创建新纪录，无论内容是 什么类型。对于任何类型的内容管理动作，运种记录可W被内容管理引擎3透明地访问，例 如为了执行旅行应用、向客户端设备7生成服务请求结果的显示或者向外部设备（例如，旅 游提供商系统或旅游设备）发送内容。
[0107] 现在参考图5,给出了绘出用于响应于从一个或多个旅游提供商系统接收的内容 而在扩展旅游记录9中创建新纪录的过程的流程图。
[010引在方框501中，内容管理引擎3可W通过消息交换格式14和/或15从一个或多个 旅游提供商4、5接收内容，例如，响应于来自诸如旅行社系统的客户端设备7的服务请求。
[0109] 内容可W包括多个相关的数据元素，例如，与同一旅行相关的数据元素，诸如顺序 接收的航班产品（标准数据元素）和出租车产品（非标准内容）。与公共内容关联的数据 元素可W顺序地或者并行地接收。数据元素可W包括用于标识它们是同一公共内容的一部 分的信息。
[0110] 数据元素可W包括标准数据元素（例如，航班产品）和/或非标准数据元素（例 如，出租车产品）。
[0111] 标准数据元素（例如，GDS内容）可W根据诸如TTY的第一消息交换格式被接收。
[0112] 非标准数据元素可W由数据交换单元11W根据标记描述语言定义的消息的形式 被接收，其中标记描述语言诸如根据第二消息交换格式15的XML。对于旅游管理系统100 与外部系统之间的数据互换，W下描述将参考XML消息（也被称为XML文档或文件）进行。 数据交换消息可W包括结构描述文件，W描述消息的结构W及包含在消息中的数据的类型 和格式。例如，对于类型XML的数据交换消息，XMLXSD架构可W被用作结构描述文件来提 供XML消息的属性的结构的表示。
[0113] 在方框502中，对于为公共内容接收的每个数据元素，内容管理引擎3可W提取数 据元素。内容提取可W由内容管理引擎3的内部应用执行。
[0114] 如果数据元素对应于标准内容（例如，航班产品），则在方框503中内容管理引擎 3利用标准数据容器（在下文中也被称为"标准容器"）在标准PNR巧0)中创建用于标准内 容（例如，航班产品）的具有该数据元素类型（例如，航班类型）的记录R。标准数据容器 可W是被配置为用于预定义类型的数据元素（标准数据元素）的静态容器。在方框505中， 记录R可W被指定记录标识符I并且可W与标准数据容器相关联。记录可W保存在临时上 下文中和/或至少一个数据库8中。
[0115] 如果数据元素对应于非标准内容（例如，出租车产品），则在方框505中内容管理 引擎3利用非标准数据容器（在下文中也被称为"非标准容器"）在非标准PNR巧0)中创建 用于标准内容（例如，航班产品）的记录R。步骤505可W由应用流的一个内部应用触发。 触发ETR中记录创建的内部应用可W与从数据交换单元11接收非标准数据元素的内部应 用不同。例如，第一内部应用A1可应用A1的格式F1接收非标准数据元素，该非标准 数据元素可W发送到链中其它内部应用，直到它W应用An的格式化到达内部应用An,并且 最终应用An触发在非标准记录数据结构91中创建记录（非标准数据容器具有格式化）。 非标准数据容器可W被指定给所述数据元素的类型（例如，出租车类型）。
[0116] 非标准数据容器适于包含任何类型的数据元素（非标准数据元素）。在方框506 中，记录R可W被指定相同的记录标识符I并且可W与非标准数据容器关联。记录可W存 储在临时上下文中和/或至少一个数据库中。
[0117] 在一种实施例中，在方框507中，在方框506中创建的非标准数据容器还可W被指 定标签。运种标签可W被内容管理引擎3在访问记录R时使用，例如为了标识不被发送到 客户端设备7的数据元素。
[0118] 因而，对于对应于公共内容的所有标准数据元素和非标准数据元素（相关的数据 元素），唯一记录标识符I可W在标准PNR90和非标准PNR91中创建。因此，运种公共记 录标识符可W被共享，W操纵对应于异构数据元素的记录，就好像它们在独特的记录数据 结构中被维护一样。例如，记录标识符I可W被内容管理引擎3使用，W允许应用读/写非 标准数据元素，无论数据是什么类型。
[0119] 在简化的例子中，扩展旅游记录9可W例如包括被指定公共记录标识符11的几个 记录，运种记录标识符ID1 -般与W下数据元素关联：
[0120] -类型1的标准数据元素D1
[0121] -类型2的标准数据元素D2
[0122] -类型3的标准数据元素D3
[0123] -类型4加标签的非标准数据元素D4
[0124] -类型5的非标准数据元素D5
[01巧]-类型2加标签的非标准数据元素D6
[0126] 用于数据元素D1、D2、D3的记录与记录标识符ID1相关联地在标准记录数据结构 90中维护。
[0127] 用于数据元素D4、D5、D6的记录与记录标识符ID1相关联地在非标准记录数据结 构91中维护（在非标准数据容器中）。
[0128] 被用来包含标准数据元素的标准数据容器具体而言适于包含具有根据lATA标准 的预定义类型和属性集合的数据元素。因此，标准数据容器只适于标准化的数据格式和数 据类型。
[0129] 非标准数据容器可W被创建，无论非标准数据元素是什么类型、属性和格式。每个 属性自己可W包括多个子属性。
[0130] 从而，内容管理引擎3使用非标准数据容器来动态地在扩展旅游记录巧）中创建 新类型的内容，无论内容是什么类型。
[0131] 非标准数据容器可W是多形态的数据容器，不像标准容器，它没有对给定的元素 硬编码到代码中。相反，它必须采取的形式可W被动态定义。
[0132] 非标准数据容器还可W具有自动串行化/反串行化属性。
[0133] 在某些实施例中，非标准数据容器可W是由操纵其的内部应用的业务对象模型21 表示的技术对象，运便于新内容在扩展旅游记录9中的集成。
[0134] 图6示意性地表示根据本发明某些实施例的内容管理引擎3的内部应用的结构， 其中非标准数据容器是业务对象模型21。内部应用可W是独立应用或者（构成相关应用 的）应用链中的应用。
[0135] 内部应用包括：
[0136] -结构化的接口 2，
[0137] -业务对象模型21，
[013引-业务层22。
[0139] 结构化接口 2代表应用彼此通信的方式。结构化接口可W传送要由应用处理的功 能数据。它们可W映射到被业务层22使用的业务对象模型21，W执行验证动作并操作。除 语法检查之外，验证动作还对应于由业务层22对数据执行的功能检查。在验证之后，数据 元素可结构化的方式插入扩展记录数据结构9中。
[0140] 因此，对扩展PNR9的数据结构的修改可W设及对应用的业务对象模型21的修改 W及对其结构化接口的修改。另外，为了受益于数据结构修改，可能的其它相关应用可能也 需要修改它们的业务对象模型21、它们的结构化接口 2并且在其它模块接口中集成新版本 的数据模型。
[0141] 本发明的各种实施例使得有可能通过使用非标准数据容器模型来限制与运种修 改相关的成本。
[0142] 在内容管理引擎3中运行的旅游服务应用可W根据图7的图来操作。B0M21代表 用来表示由应用使用的内部数据模型的业务对象模型21。
[0143] 服务210代表由旅游管理系统100从可被应用作为目标的客户端设备7、非标准旅 游提供商5或者旅行者设备6接收的任何结构化消息（诸如XML或Edifact消息）。
[0144] 上下文服务器211代表在与其它应用的异步交互之间由应用使用的数据的上下 文存储（也被称为"上下文"）。
[0145] 来自上下文的数据可W响应于请求、周期性地或者依赖于某些条件而保存在数据 库8中。
[0146] 图8说明了根据某些实施例在内容管理引擎3中链接的应用A1至AN之间的交互。 当旅游管理系统100W分布式体系架构操作时，负责该过程的链接的内部应用A1至AN可 W彼此调用，运会导致图7的体系架构的几个副本进入多个应用服务器30(也被称为后端 服务器），每个应用服务器30与各自的链接的应用Ai关联。在过程链当中每一步，在常规 的方法中，在过程中从服务器30传递到另一个服务器之前，从用于应用A1的第一后端服务 器30传送到用于应用An的最后一个服务器30的数据W不同的方式被变换、编码和解码。 在访问数据元素之前，每个后端服务器30还解码进入的数据元素并且为其专用过程验证 数据。然后，数据被编码，W便发送到链中下一个应用Aw。另外，业务对象模型21可W设 及在把信息填充到结构化接口 2和从其检索信息的过程中并且可W被用来写/读数据。在 常规的方法中，需要手工编码的部件把数据写入结构化接口 2和中央记录存储库/从结构 化接口 2和中央记录存储库读数据。因而，到数据模型的单个变化可能是昂贵的。另外，应 用在操纵的数据元素一般具有许多功能约束，使得每个应用可能需要确保所操纵的数据是 W与行业约束（验证）兼容的合适格式。
[0147]因此，在常规方法中，每次当数据元素必需在运种链接的应用中被修改时，该过程 的所有步骤会受影响，因为每个过程都必须向下一个过程发送新数据并且因此将必须解码 它、验证它和编码它。另外，当新内容要添加到现有应用时，每个过程还必须向下一个过程 发送新内容并且链中的每个过程必须解码、验证和编码新元素。
[