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的流程都是略有不同。

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

1 2 3 4 5 下一页>>