0148] 根据某些实施例的本发明通过使用B0M类型的非标准数据容器的自串行化特性 改善了所述条件。
[0149] 具体而言，响应于从非标准内容提供商5接收数据元素D1、D2和D3,非标准数据 容器可W由链中第一个应用A1创建。运种非标准内容不能存储在标准PNR90中，因为诸 如它不包括遵循PNR90的标准结构的数据类型和属性。非标准内容可W采取各种形式并 且可W与各种类型和属性关联。
[0150]第一个应用A1可第一内部应用A1 (例如协议缓冲区）的格式F1为每个非标 准数据元素化创建例如非标准容器。然后，第一个应用A1利用非标准容器的自动串行化/ 反串行化特性利用消息Ml把非标准容器传递到链中下一个应用。消息Ml可W是携带自动 串行化/反串行化信息的blob。然后，第二个应用A2可内部应用A2的格式F2提取非 标准数据容器。类似地，第二应用可利用携带自动串行化/反串行化信息的消息M2、M3等 等向链中其它应用发送非标准容器，直到应用An触发在ETR9中创建记录。
[0151]因而，通过使用非标准数据容器，不需要代码变化来向ETR9添加新数据结构，W便在内部应用链中更新数据结构或者发送数据元素。另外，不需要修改现有的数据结构。无 需提取其并且将其从一种格式转换成另一种格式，就可W使由非标准数据容器所包含的数 据可用。因此，可W减少中间/手工编码的层。
[0152] 如图9的例子中所绘出的，非标准数据容器50可W由描述可被应用操纵的业务 对象模型的一组关键字-值来定义。每个关键字51定义B0M的属性并且包括关联的值 52 (在图9中也被称为"数据"）。例如，由关键字"City(城市）"定义的非标准数据容器 与值"Paris(己黎）"关联。数据容器可W包括复杂的结构并且与任何种类的数据关联。 例如，数据容器的一个或多个关键字可W进一步与参考53(在图9中被称为"REF")关 联，W便把给定的数据容器与一组相关数据容器关联。例如，由关键字/值对"phone(电 话）/+335551213"指定的数据容器包括对W下数据容器的参考（"REF") :"mobile(手 机）/+336123456"和"home(家庭电话）/+335551213"。
[0153] 对于非标准数据容器中所包含的任何数据元素，非标准数据容器50允许在写模 式下对内容管理引擎3的访问，而无需开发访问器来允许运种访问。运确保灵活性和调整 性。
[0154] 另外，通过使用根据诸如Xpath之类的合适查询语言的查询，对非标准数据容器 中所包含的数据元素的访问可W由内容管理引擎3在应用处理的任何时间执行。
[0155] 非标准数据容器可W编程性地向后和向前兼容。从编程的角度，不需要代码变化 来使用与非标准数据容器关联的新版本的数据元素结构。
[0156] 非标准数据容器被配置为支持串行化/反串行化。特别地，串行化可W在非标准 内容的一个或几个属性被创建和修改时执行，W便W可扩展的格式编码数据容器，并且反 串行化可W在每次应用需要读非标准内容的至少一个属性时被执行。
[0157] 具体而言，通过把代表非标准数据容器的技术对象（例如，B0M)的状态翻译成可 W被反串行化机制存储和重构的格式（例如，二进制表示）W便把数据容器恢复到其原始 状态，非标准数据容器关键字和值可W在任何时候被串行化。从而，非标准数据容器可W被 变换成任何目标格式，无论数据容器中所包含的是什么数据。串行化和反串行化机制不需 要硬编码。串行化信息可W嵌入在与数据容器关联的库中。因此，运种B0M的使用自然地 提供了可W对由非标准数据容器的关键字定义的任何种类结构被支持的串行化机制，而无 需具体的编码。在某些示例性实施例中，被用来根据串行化/和反串行化机制翻译其状态 的非标准数据容器的表示格式可W基于例如XML、ASCII、JS0N、二进制格式，如图10中所说 明的。
[0158] 非标准数据容器的值的验证可W只在由非标准数据容器对象表示的数据元素被 创建和修改时需要。因而，不需要读过程来重新验证关联到关键字的数据元素。
[0159] 通过使用非标准数据容器，与内容类型相关的信息（例如，飞机、出租车、体育节 目、停车、城市交通，等等）可W被传送到非标准数据容器本身当中。非标准数据容器的类 型可W作为关键字直接存储在非标准数据容器中。
[0160] 在一些实施例中，在给定的非标准数据容器创建或修改时的验证机制可W基于作 为关键字存储在非标准数据元素中的功能类型，而不是像常规方法中的C++类型。
[0161] 在某些实施例中，每种类型的非标准数据容器可W与描述数据元素的属性结构 (属性布局、属性依赖性W及属性格式，等等）的结构描述文件（例如，XSD)关联。
[0162] 结构描述文件（例如，XSD)还代表表示为技术对象（例如，XML对象）的非标准数 据容器的属性和元素之间的相互关系。在与非标准数据容器关联的XSD架构中，非标准数 据容器的不同关键字/值W及应用到其的辅助约束可W利用一组XML标签来描述。结构描 述文件可W在非标准数据容器创建和修改时被使用。此外，辅助约束可W利用结构描述文 件（例如，XSD)应用到非标准数据容器。
[0163] 与每个非标准数据容器关联的结构描述文件可W被用来在非标准数据容器创建 或修改时验证非标准数据容器属性。验证机制可W包括检验由非标准数据容器表示的非标 准数据元素是否遵守内容被放在其中的数据元素的描述。在某些实施例中，验证机制可W 实现为，通过使用与非标准数据容器关联的结构描述文件，验证存储在非标准数据容器中 的数据是否匹配目标格式。
[0164] 旅游管理系统100可W维护用于存储与和非标准数据容器关联的结构描述文件 一致的非标准数据容器的数据类型的表。该表可w是在过程运行时被更新。
[0165] 内容管理引擎3可W被配置为，通过更新描述非标准数据容器结构的结构描述文 件（例如，XSD)，把新数据添加到非标准数据容器中，诸如新属性。
[0166] 在无需硬编码变化和重新编译代码的情况下，定义非标准数据容器的结构描述文 件（例如，XSD)可W被修改。因此，非标准数据容器的修改是动态的并且在运行时可更新。
[0167] 图11是图9的示例性非标准数据容器的示意图，示出了它们各自的类型：电话 fhone)类型、地址（AcMress)类型、GPS类型。信息类型可W作为属性存储在非标准数据 容器中。运种信息可W被用来检索与非标准数据容器关联的结构描述文件。
[0168]图12说明了用于具有不同类型（叩11〇]16了7口6"、"4(1化633了7口6"、"6口5了7口6")的 示例性非标准数据容器的XSD描述文件。
[0169] 根据某些实施例，内容管理引擎3还可W在由旅游管理系统100向客户端设备7 暴露的独特平台中生成一组内部服务接口 2,无论返回到客户端设备7的内容的类型和由 内容管理引擎3维护的应用是什么。
[0170] 扩展旅游记录9可W被大量应用使用。例如，内容管理引擎3可W包括一组应用 (例如，旅游应用），用于根据从标准旅游提供商系统4 (例如，飞行产品）和从任何其它旅 游提供商系统5 (例如，非飞行产品）接收的外部内容向客户端设备7交付不同类型的旅游 服务，无论内容是什么类型。运种服务可W包括例如购物、预订、定价、发行、退款服务。
[0171] 运种服务应用可W响应于来自通过客户端设备7连接到旅游管理系统100的系 统（例如，旅行社系统70)的服务请求而被执行，而无需通过硬编码使每个应用适应添加到 ETR9的N种类型的数据。
[0172] 结果可W利用诸如XML消息的给定格式的响应消息通过数据交换单元11返回。因 此，由旅游管理系统（100)生成的内部服务接口 2可W是XML类型的。
[0173] 为了避开记录并重新编译每个应用W便支持任何数量新类型的非标准数据容器 的需求，可W使用具有独特类型（通用元素类型）的通用元素。通用元素是被配置为包含 任何类型的非标准数据容器的大型数据容器。通用元素可W被所有服务应用看作独特类型 (在下文中被称为"通用元素类型"）的容器，同时通用元素可W包含无限数量N个非标准 数据类型。
[0174] 因此，每个应用可W把通用元素实例化为能够独立于数据容器中所包含的数据元 素的类型而无缝地操纵非标准容器。因而，每个应用不需要实例化像新数据类型那么多的 非标准数据容器。
[0Π5] 因此，新内容类型向非标准PNR91的添加不影响或不需要为了确保向后兼容性 而适应由内容管理引擎3处理的应用（例如，通过硬编码）。
[0176] 图13是绘出由应用从具有给定记录标识符I的ETR9对记录进行访问的流程图。 例如，记录标识符I可W包括：
[0177]-类型T1的标准数据元素SD1
[0178]-类型T2的标准数据元素SD2
[0179]-类型T3的非标准数据元素NSD3,包含在非标准数据容器中
[0180]-类型T4的非标准数据元素NSD4,包含在非标准数据容器中
[0181] 在方框600中，与记录标识符I关联的记录从ETR9被检索。记录可W与具有各 自类型T1、T2、T3、T4的标准数据元素（SD1、SD2)和非标准数据元素NSD3、NSD4(非标准数 据容器）相关联。
[0182] 然后，每个数据元素SD1、SD2、NSD3和NSD4被单独处理。
[0183] 具体而言，对于每个数据元素，诸如像NSD3,如果数据元素是非标准数据元素（方 框601)，则在方框602中类型T3的非标准数据元素被变换成包含类型T3的非标准数据元 素的唯一通用元素类型的通用元素。作为大型数据容器的通用元素可W自己包含具有具体 类型的非标准数据容器。通用元素可W被实现为诸如B0M的技术对象，并且可W基于与非 标准数据容器相同的技术。
[0184] 如果数据元素是标准数据元素（方框603)，诸如像SD1，则在方框604中类型T1 的标准数据元素可W被转换为相同类型T1的非标准数据容器。
[0185] 在方框602中，运样获得的非标准数据元素被变换成包含对应于非标准数据元素 NSD1的类型T1的非标准数据元素的独特通用元素类型的通用元素。
[0186] 通用元素构成非标准数据元素的过渡状态，运使得应用有可能无缝地操纵标准数 据元素和非标准数据元素，无论它们是什么类型。因此，应用可W操纵ETR9的数据元素， 而无需明确知道非标准内容的类型，就像它们具有独特的类型一样。
[0187] 在方框605中，如果应用的执行需要一个或多个数据元素被发送到发起服务请求 的客户端设备7的接口，则应用可W内省（introspect)通用元素，W访问数据元素的类型。 [018引在本发明的某些实施例中，非标准数据元素可W与各自的标签相关联。在运种实 施例中，在方框601中，只有与各自标签相关联的非标准数据元素可W由应用选择并变换 为通用元素。
[0189] 因而，通用元素抽象非标准数据元素的类型：代替在每次新类型的内容必须被应 用处理时（新内容在ETR9中添加时）定义新元素类型，每个应用可W因此实例化能够支 持任何新内容类型和属性的独特通用元素。
[0190] 返回图3,旅游管理系统100可W适于通过内部接口 2与任何外部客户端设备，诸 如旅行社系统70、非标准旅游提供商系统5或者同一GDS内部的任何其它后端服务器，交换 任何类型的内容（标准的和非标准的内容）。
[0191] 在常规方法中，通过实现到由目标客户端设备支持的标准格式的硬编码转换，旅 游管理系统100可W与对于PNR内容的格式（目标PNR内容格式）具有其自己的标准的其 它目标客户端设备（例如，旅游提供商系统、旅行社系统）交换来自标准PNR的数据。运需 要在旅游管理系统100的编码机制和在目标设备的解码/验证机制。事实上，每个旅游管 理系统可W对PNR内容的格式（源PNR内容格式）具有其自己的标准并且由此目标设备的 接口只支持运种格式。W昂贵并且静态的方法，运种转换（编码/解码/验证）目前设及 硬编码和重新编译。
[0192] 数据交换单元11允许根据第二数据交换格式15从外部客户端设备接收或发送数 据交换消息，W交换任何类型的内容。在优选实施例中，第二数据交换格式15是诸如XML的 标记描述语言。对应于非标准数据元素的每个数据交换消息包括定义数据元素的属性（属 性布局和格式）的结构描述文件，诸如用于XML消息的XSD，W及对应于属性值的一组值。
[0193] 图14更详细地表示根据某些实施例的数据交换单元11的结构。
[0194] 数据交换单元11可W被用来与诸如非标准旅游提供商5、旅行社系统或另一非 GDS系统的外部客户端设备交换数据元素。特别地，数据交换单元11可W被用来：
[0195]-从客户端设备接收非标准数据元素；或者
[0196] -把数据元素从ETR9发送到客户端设备。
[0197] 数据交换单元11可W包括结构变换引擎111，诸如用于把诸如XSD的结构描述文 件从源结构描述文件XSD1变换成目标结构描述文件XSD2的XSLT引擎，W及用于W根据诸 如XML的描述语音定义的消息的形式发送数据的数据交换消息发生器112。XSLT引擎