现代航空零售基础知识。本系列短文将为您解读MAR——相关术语、架构，以及当航空公司从PNR系统转向订单系统时会发生哪些变化。
前几篇文章介绍了OOSD在理论层面的概念——包括其模式、结构和标准。本文则将探讨实际基于OOSD进行开发是怎样的体验。
简而言之：情况很复杂，仍在持续发展，而且规范与实现之间的差异比你想象的要频繁得多。
双语体系的问题
构建现代交付管理系统面临的核心挑战之一在于，传统系统并未消失。航空公司仍在使用以PNR、SSR和六位数预订参考号为核心构建的系统。地勤、行李处理及APIS系统均运行在传统标识符的基础上。你无法简单地用新系统取代旧系统；必须同时兼顾两者。
一种方法是构建所谓的“双语系统”：与其在旧系统和新系统之间进行转换，不如在同一个系统内并行维护这两种表示形式。该系统既能处理旅客预订记录（PNR），也能处理订单；它可以在两者之间双向通信，且不会丢失任何信息。
实际上，这种趋于分化的趋势确实存在。新世界有着不同的约束条件——或者在某些情况下，当旧世界存在硬性限制时，新世界却没有任何约束。 一架飞机的载客量可达200人，而传统的PNR预订系统通常上限仅为20人。一个基于20人规模构建的系统，最终必须重构才能处理200人的需求。尽可能长时间地保持两个系统的同步虽能争取时间，但无法永远维持下去。
与OrMS并行开发
还有个额外的问题：在许多实现方案中，订单管理系统和配送管理系统是由不同的团队同时开发的，且都基于同一套不断演进的标准。当其中一方发生变化时，另一方也必须随之调整。结果就是，双方不得不根据不断变化的规范进行协同开发，而当规范本身发生变化时（这种情况确实会发生），双方都必须做出相应调整。
这并非对标准制定流程的批评，而是对“早期实施者”这一身份的真实写照。标准由委员会设计并经过漫长过程最终获得批准；那些边缘情况和实际矛盾往往要等到有人尝试构建时才会显现出来。
规格未涵盖的内容
作战态势图中的某些部分完全超出了OOSD框架的范围，但仍然是运行出发控制系统（DCS）日常工作的一部分。时刻表消息、MVT、SSIM和ASM虽不属于OOSD范畴，但DCS仍需存储时刻表数据。目前而言，这意味着即使在其他方面已实现现代化，系统仍需继续接收来自OrMS的此类传统消息。
同样，联运和代码共享也增加了复杂性，而该模式在概念层面对此进行了处理；虽然“报价责任航空公司”、实际承运人和营销承运人之间存在区别，但在实际操作中界限并不清晰，往往需要根据具体情况逐案处理。
卖方与配送服务商的区别
如果您正在该领域进行开发，有一个概念值得了解：该架构将“卖家”（向订单中添加商品的实体）与“配送服务商”（负责更新配送状态码的实体）区分开来。这两者是具有不同访问权限的不同角色。卖家无法查看订单中其他卖家的商品。 配送服务商则需要查看完整的订单信息：包括所有商品和所有服务，无论由谁销售，因为他们负责为乘客提供全程服务。
如果您正在构建一个DCS，那么您就是服务提供商。这意味着您的访问模式、数据要求以及职责与销售系统有所不同。
问：基于 OOSD 进行开发是否遇到了诸如乘客数量限制不匹配之类的重大挑战？
是的。订单标准本身没有乘客数量限制，但旧版DCS系统可能会有20人的硬性上限。这只是此类不匹配问题层出不穷的一个例子。 这种情况随处可见：体现在识别码的工作原理中，体现在航班时刻数据的建模方式中，也体现在联程预订的处理方式中。坦率地说，构建此类系统是一个需要数年时间的项目，其中大量工作都用于弥合新旧系统之间的差距。
问：这些集成挑战和边界情况是否有相关记录？
他们确实应该这样做。记录规范要求与实际运行情况之间的差异具有真正的价值，这既可作为内部资源，也能为整个行业提供有用的参考。讽刺的是，最适合记录这些差异的团队，恰恰是最忙于开发工作的团队。这是一个众所周知的缺口。