航显、行李等其它应用系统可通过信息交互层向应用整合层订阅航班计划，一旦订阅成功，则每当生产系统发布了航班动态，航显、行李等系统将会自动接收到该航班动态信息的副本，而对于这些系统也无需知道该消息的源头。

请求/回复模式

请求/回复模式包括两个过程：一是发送消息并期待回复（换言之，就是发送请求消息，也可通过发布过程发送请求），另一则是在收到请求消息后发送回复消息。系统或应用程序发出请求消息并等待回复消息。响应方使用请求消息，生成一个回复消息，再将其送回发起方。发起方收到回复消息时就标志着消息流的完成。

请求/回复模式在本架构的应用，MQSeries 提供了利用关联性ID 识别请求消息及其回复消息的便利。关联性ID 由发出请求消息的应用程序进行设置。生成回复消息的应用程序将关联性ID 从请求消息中拷贝到回复消息中，并将其送回原先发出请求消息的应用程序。发送请求消息的应用程序可以利用关联性ID 将回复消息映射到请求早先发出的消息上。

在这个模式中，请求和响应是单个请求／答复操作内定义的两条消息，并作为两个独立无关的传输层传送发送。

图 7 请求/回复模式

该应用模式作为发布/订阅模式的补充，将有效解决特定情况下可能产生的消息丢失或信息不同步而给应用系统带来的影响。以航班状态为例，生产系统针对当天的某一航班会根据航班状态发布多条状态信息，此时，对于当前的应用系统（如航显）即可逐条接收航班状态信息，也可通过请求的方式向信息交互层发送请求信息，生产系统收到该请求信息后，将会把该航班的最新的航班动态发送至该应用系统。该模式可有效解决机场内各应用系统数据不同步等问题。

4.3可定制的服务单元模式

为了使机场业务环境具有灵活的基础架构和处理环境，EAI平台还需要支持面向SOA扩展的能力，为此，自需求分析、信息交互平台的设计、消息格式的定义都必须考虑到未来的扩展，达到机场各应用系统之间最大程度的松耦合，我们可运用WebSphere MB高效的消息格式转化、消息路由等功能，采用面向服务的设计思想，将现有业务定义为一个个独立的“原子服务”（最小功能集），通过对“原子服务”进行组合构造“组合服务”，通过“服务字典”查询相关服务的定义，随着业务的更改或者客户对服务需求的变更，原先定义的原子服务并不需要变更，只需将变化后的服务重新组装、或在现有组合服务的基础之上修改成为新的“组合服务”既可。

如：将生产系统的进港航班和出港航班动态发布分别定义为一个独立的原子服务，航班动态发布定义为一个包含进港航班和出港航班的组合服务。对于只关心出港航班的应用系统（如行李系统）只需请求一个原子服务，即出港航班动态发布，而对于即关心出港，又关心进港航班的应用系统