信息系统架构设计-以服务为中心的企业整合实践

生命周期

1. 业务分析
2. 服务建模
3. 架构设计
4. 系统开发

案例背景

某航空公司的信息系统已有好几十年的历史。该航空公司的主要业务系统构建于20世纪七八十年代，以IBM的主机系统为主。

近年来，该公司已经在几个主要的核心系统之间构建了用于信息集成的信息Hub(Information Hub)，其他应用间也有不少点到点的集成。尽管这些企业集成技术在一定程度上增进了系统间的信息共享，但是面对如此异构的系统，技术人员依然觉得企业集成困难重重：

1. 因为大部分核心应用构建在主机之上，所以Information Hub是基于主机技术开发，很难被开放系统使用。
2. Information Hub对Event支持不强，被集成的系统间的事件以点到点流转为主，被集成系统间耦合性强。
3. 牵扯到多个系统间的业务协作以硬编码为主，将业务活动自动化的成本高，周期长，被开发的业务活动模块重用性差。

为了解决这些企业集成中的问题，该公司决定以Ramp Control系统为例探索一条以服务为中心的企业集成道路。

本文将以Ramp Control系统中的Ramp Coordination流程为例，说明如何用以服务为中心的企业集成技术一步步解决该公司IT技术人员面临的企业集成问题。

业务分析

在航空业中，Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。通常，每个航班都有一个人负责Ramp Coordination，这人通常称为Ramp Coordinator。

由Ramp Coordinator协调的业务活动有：

• 检查机位环境是否安全
• 卸货
• 装货
• 补充燃料是否方便和安全

实际上，Ramp Coordination的流程因航班类型的不同，机型的不同有很大的差异。

上述流程主要针对降落后不久就起飞的航班，这种类型的航班称为short turn around航班。

还有其他类型的两种航班：

• Arrival Only航班指降落后需要隔夜才起飞的。
• Departure Only航班是指每天一早第一班飞机。

==这些航班的流程，大部分业务活动是相似的。==这三种航班根据长途/短途，国内/国外等因素还可以进一步细分。每种细分的航班类型的Ramp Coordination流程都是略有不同。

很明显，如此多的流程之间共享着一个业务活动的集合，如此多种类型的流程都是这些业务活动的不同组装方式。以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务，并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型，来降低流程集成成本，加快流程集成开发效率的。

以服务为中心的企业集成，通过服务建模过程发现这些可重用的服务，并通过流程模型将这些服务组装在一起。

服务建模

使用两种方法：

1. 组件业务建模（Component Business Model）
2. 面向服务的建模和架构（Service-Oriented Model and Architecture）

建立以下模型：

1. 组件模型
2. 服务模型
3. 流程模型

服务模型是服务建模的主要结果。Ramp Coordination相关的服务模型和Ramp Coordination流程相关的有两个业务组件：

• Ramp Control负责Ramp Control相关各种业务活动的组件
• Flight Management负责航班相关信息的管理，包括航班日程，乘客信息等

以上两个业务组件分别输出如下服务：

1. Retrieve Flight BO:由Flight Management输出，主要用于提取和航班相关的数据信息
2. Ramp Coordination:由Ramp Control输出，主要用于Ramp Coordination流程的编排
3. Check Spot:由Ramp Control输出，用于检测机位安全信息
4. Check Unloading:由Ramp Control输出，用于检查卸货状况
5. Check Loading:由Ramp Control输出，用于检查装货状况
6. Check Push Back:由Ramp Control输出，用于检查关门动作

服务建模确定了系统相关的服务输出后，还需要确定服务在当前环境下的实现方式。

• Retrieve Flight BO被实现为信息服务
• Ramp Coordination被实现为流程服务，通过BPEL4WS（Business Process Execution Language for Web Services）方式实现。
• 其他4个服务都是Staff Service（人工服务）

需要注意的是，因为环境的不同和随着系统的演化，我们可能会改变服务的实现方式，如Check Push Back现在通过Staff Service即人工服务实现。将来随着自动化程度的增强，Check Push Back完全可能通过自动化的系统实现。到那时，只需重新实现这个服务，而无需改变整个流程。这是服务可替换性的一个典型实例。

IT环境分析

在构建Ramp Control系统之前，该航空公司已经有大量的信息系统。作为架构设计的重要步骤对现有IT环境调研，描绘了和Ramp Control相关的IT系统的状况，包括周围应用和应用提供的接口，这些应用和Ramp Control交互的类型和数据格式。简化的IT环境视图，描绘了Ramp Coordination流程和周围系统交互的状况。目前Ramp Coordination流程需要4中类型的外围应用交互：

1. 从乘务人员管理系统提取航班乘务员的信息
2. 从订票系统中提取乘客信息
3. 从机务人员管理系统中提取机务人员信息
4. 接收来自航班调度系统的航班到达事件

通过主机应用中的信息集中为粗粒度的业务对象，并通过信息服务输出，为该公司的核心系统提供了更加通用的连接能力，同时为IT系统的平滑演进提供了必要的条件。

架构设计

根据需求和设计阶段的业务模型和现有IT环境调研结果Ramp Coordination的架构设计如下所示：

本案例中的主要结构元素以及它们之间的工作关系如下：

1. 信息服务。Federation Service是Ramp Coordination流程中需要从已有系统重提取3类信息（乘务人员+机务人员+订票信息），在Service建模阶段这3类信息被聚合为Flight BO（Business Object）。Retrieve Flight BO被实现为一个EJB，外部访问通过RMI/IIOP绑定访问这个服务。在Retrieve Flight BO内部，Flight BO以SDO来表示
2. 企业服务总线中的事件服务。Event Service是在检查机务环境安全（Check Spot）前，Ramp Coordiator需要被通知航班已经到达。这个业务事件由航班调度系统激发，Fight Arrival是典型事件发现服务（Event Detect Service），它通过MQ将事件传递给Message Broker，通过JMS的Pub/Sub，这个事件被分发给Check Spot。这里的Event Service是ESB的重要组成部分。通过ESB上通用事件服务，现有Information Hub的缺陷得到了克服。应用程序间的事件集成不再需要点到点的方式，而是通过ESB的事件服务完成订阅发布，应用程序间的耦合性得到了极大的缓解。
3. 流程服务。
4. 企业服务总线中的传输服务。RCMS是即将新建的系统，用于提供Ramp Control的功能。