引言

本文是“以服务为中心的企业整合”系列文章第二部分。在本文的姊妹篇 "以服务为中心的企业整合"中 ，我们探讨了以服务为中心的企业集成的理论知识，本文以一个经过简化的实际案例为例，介绍了以服务为中心的企业集成的基本步骤，从业务分析，到服务建模，到架构设计，到系统开发的整个生命周期。以服务为中心的企业集成涉及到的主要技术被穿插在各个步骤中进行了详细的讲解。

1. 案例背景

某航空公司的 IT 系统已有好几十年的历史。该航空公司的主要的业务系统构建于上世纪七八十年代，以 IBM 的主机系统为主 － 包括运行于 TPF 上的订票系统，和运行在 IMS 上的航班调度系统等。在这些核心系统周围也不乏基于 Unix 的非核心作业系统，和基于 .Net 的简单应用。这些形形色色的应用，有的用汇编或 COBOL 编写，运行于主机和 IMS 之上，有的以 PRO*C 编写，运行在 Unix 和 Oracle 上；这些应用虽然以基于主机终端的界面，但是基于 Web 和 GUI 的应用也为数众多。

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

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

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

为了便于说明，示例中的业务系统和业务流程都进行了必要的简化。

2. 业务环境分析

在航空业中， Ramp Coordination 是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。通常每个航班都有一个人负责 Ramp Coordination, 这人通常称为 Ramp Coordinator 。由 Ramp Coordinator 协调的业务活动有，检查机位环境是否安全，卸货，装货，补充燃料等。

 

图 2 是一个 Ramp Coordination 的业务流程图。由图可见， Ramp Coordination 流程依次有下列活动

1) 从提取协调过程中所需要的主要信息，通常会以工作单给 Ramp Coordinator;( 自动活动 )

2) 检查机位环境是否安全； ( 人工活动 )

3) 检查卸货； ( 人工活动 )

4) 检查装货； ( 人工活动 )

5) 检查关门； ( 人工活动 )

 

实际上， Ramp Coordination 的流程因航班类型的不同，机型的不同有很大的差异。图 2 所示的流程主要针对降落后不久就起飞的航班，这种类型的航班我们称之为 short turn around 航班。除了 short turn around 航班，我们还有其他两种类型的航班，如图 3 所示， Arrival Only 的航班指降落后需要隔夜才起飞的。 Departure Only 的航班是指每天一早第一班飞机。这些航班的 Ramp Coordination 的流程和 Short Turn Around 类型的流程大部分的业务活动是相似的。这三种类型的航班根据长途 / 短途，国内 / 国外等因素还可以进一步细分。每种细分的航班类型的 Ramp Coordination 的流程都是略有不同。

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

3. 服务建模

IBM 推荐使用组件业务建模 (Component Business Model) 和面向服务的建模和架构 (Service-Oriented Model and Architecture) 两种方法学建立业务的组件模型，服务模型和流程模型。关于服务建模方法学已经超出本文范围，这里就不在累述。

服务模型是服务建模的主要结果。 Ramp Coordination 相关的服务模型如图 4 所示。和 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 方式实现；其他四个服务都是 Staff Service 。需要注意的是，因为环境的不同，和随着系统的演化，我们可能会改变服务的实现方式，比如 Check Push Back 现在通过 Staff Service 即人工服务实现。将来随着自动化程度的增强， Check Push Back 完全可能通过自动化的系统实现。到那时，我们只需重新实现这个服务，而无需改变整个流程。这是服务的可替换性的一个典型实例。

4. IT 环境分析

IT 环境分析是调查现有应用技术特点的重要手段。在我们的示例中， IT 环境分析主要用于调查现有应用，为决定服务模型中服务的实现方式提供技术依据。同时，它也是架构设计的重要依据。

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

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

如图所示，象航班调度信息和定票信息都存储在 IMS 和 TPF 这些相当封闭的主机系统之上。尽管主机系统提供一定的面向开放系统的集成能力，如 MQ 和 Socket 。但是因为主机本身的特殊性，使得这些集成方法的使用都不是那么方便。所以如何方便地集成主机系统的信息成为 Ramp Coordination 中一个重要的技术问题，同时也是整个 IT 系统集成面临的主要问题。以服务为中心的企业集成为我们提供了更为开放的集成手段。在 Ramp Coordination 中，我们把这些主机上的数据进行了集中，并通过信息服务的形式输出给开放系统使用。如图 6 所示，来自 IMS 的航班信息和机务人员信息，来自 Oracle 的乘务人员信息和来自 TPF 的乘客信息都被汇集为一个业务对象 Flight BO 。 Retrieve Flight BO 服务提供访问这种业务对象的手段。 Retrieve Flight BO 服务隔离了底层实现的复杂性。外面的应用系统看到的是前面开放的接口，而不是后面封闭的主机系统。即使将来后台主机被开放系统替代，外面的应用依然可以运行依旧。

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

5. 高层架构设计

根据需求和设计阶段的业务模型和现有 IT 环境调研结果，再结合传统的 IT 应用开发方法， Ramp Coordination 系统的高层架构被设计了出来，如图 7 所示。

如下四点简要介绍了本案例中的主要架构元素以及它们间的工作关系。

1) 信息服务－ Federation Service: Ramp Coordination 流程中需要从已有系统中提取四类信息，在 Service 建模阶段这四类信息被聚合为 Flight BO （ Business Object ）。如上文所述， Retrieve Flight BO 服务用于从已有系统中提取 Flight BO 。它实际上是一个 Federation Service ，将来自乘务人员管理系统、机务人员管理系统和订票系统中的信息聚合在一起。从这三个已有系统来的 Crew Info, Cockpit Info 和 Passage Info 是在已有系统中已经存在的业务逻辑或业务数据，它们属于可接入服务 (on-ramp service) ，接入的协议分别为 JDBC, IMS J2C Connector 和 socket 。乘务人员管理系统基于 Oracle 数据库， Crew Info 可以直接通过 JDBC 获得。机务人员管理系统基于 S/390 上的 IMS, IBM 已经提供了 IMS 的 J2C Connector ， 所以 Cockpit Info 可以通过 J2C connector 获得。订票系统构建在 IBM TPF 之上，由于实时性的要求， socket 是比较好的接入方法。 Retrieve Flight BO 被实现为一个 EJB ，外部访问通过 RMI/IIOP 绑定访问这个服务。在 Retrieve Flight BO 内部， Flight BO 以 SDO 来表示。

2) 企业服务总线中的事件服务－ Event Service: 在检查机务环境安全 (Check Spot) 前， Ramp Coordiator 需要被通知航班已经到达。这个业务事件由航班调度系统激发， Flight Arrival 是典型事件发现服务 (Event Detect Service) ，它通过 MQ 将事件传递给 Message Broker, 通过 JMS 的 Pub/Sub ，这个事件被分发给 Check Spot 。这里的 Event Service 是本例中 ESB 的重要组成部分。通过 ESB 上的通用事件服务，现有 Information Hub 的缺陷得到了克服。应用程序间的事件集成不再需要点到点的方式，而是通过 ESB 的事件服务完成订阅发布，应用程序间的耦合性得到了极大的缓解。

3) 流程服务－ Process Service: Ramp Coordination 被实现为一个 Process Service ，它被 WBI SF 的 BPEL4WS 容器执行， BPEL4WS 容器提供 Choreograph Service, Transaction Service 和 Staff Service 支持。 Ramp Coordination 通过 RMI/IIOP 协议调用，在 BPEL4WS 容器中 WSIF 被用于通过各种协议调用服务 , 它成为 ESB 中 Transport Service 的一部分。 Ramp Coordination 中的人工动作被实现为 Staff Service 而集成到流程中。这里 Staff Service 通过 Portlet 实现，运行在 Websphere Portal Server 上。 Portal Service 实现部分 Delivery Service 支持 PDA 设备， Ramp Coordinator 通过 PDA 设备访问系统。

4) 企业服务总线中的传输服务－ RCMS 是即将新建系统用于提供包括 Ramp Coordination 在内的 Ramp Control 的功能。 RCMS 通过由 WSIF 实现的 Transport Service 以 SOAP/HTTP 调用 Ramp Coordination 服务。

6. 开发过程

尽管以服务为中心的企业集成在开发阶段和普通的应用开发并没有本质的区别，但是它在角色，职责、工具和方法还是有不少自己的特色。下图汇总了本文示例中开发角色，职责，开发方法和工具，仅供大家参考。

7. 结束语

本文通过一个简单的案例，讲解了以服务为中心的企业集成的主要步骤和涉及的技术。这些集成的技术，无论是方法学，体系结构，还是编程模型都在不断的发展中。随着这些技术的不断完善，以服务为中心的企业集成方案的实施将更加简单高效。