面向服务的构架.docx

面向服务的构架.docx

《面向服务的构架.docx》由会员分享，可在线阅读，更多相关《面向服务的构架.docx（11页珍藏版）》请在冰豆网上搜索。

面向服务的构架

ServiceOrientedArchitecture

1SOA简介

1.1概述

●SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构。

它尝试给出在特定环境下推荐采用的一种架构

●相对于传统的COA（ComponentOrientedArchitecture）,InterfaceBasedDesign,以及分布式系统是一次革命性的更新，将彻底改变软件行业的结构与运营模式

●当下的热点话题，但是很遗憾，目前并没有公认的参考模型对其进行精确的定义

●主要公司及产品

ØIBM

ØBEA

✧BEATuxedo业界交易的第一中间件

✧BEAWebLogic适合企业级客户复杂IT应用环境的完整的产品，包括WebLogicPlatform、WebLogicCommunicationPlatform等

✧BEAAquaLigic：

BEA在06年6月推出的全新产品线，用于管理SOA全生命周期

●主要盈利模式：

出售通用软件；具体为每个公司设计SOA改造方案。

1.2SOA的具体化描述

1.2.1传统COA分布式模型举例

COA模型的优点是代码复用性高，维护方便。

进一步提高复用性同样是驱使公司采用SOA的原因。

1.2.2SOA的基本特征

目前有大量的案例都声称自己符合SOA的要求，以下是对它们共有概念的总结。

●服务

●服务描述

●广告及发现

●相关数据模型的规范

●服务合同

1.3SOA的框架

1.3.1SOA概念图（conceptmap）

独立于语义和技术，以图形化的方式揭示各种概念之间的关系。

1.3.2基本SOA参考模型

1.3.3扩展的SOA参考模型

1.3.4SOA模式

以服务为中心的企业整合－案例分析

1.案例背景

某航空公司的IT系统已有好几十年的历史。

该航空公司的主要的业务系统构建于上世纪七八十年代，以IBM的主机系统为主－包括运行于TPF上的订票系统，和运行在IMS上的航班调度系统等。

在这些核心系统周围也不乏基于Unix的非核心作业系统，和基于.Net的简单应用。

这些形形色色的应用，有的用汇编或COBOL编写，运行于主机和IMS之上，有的以PRO*C编写，运行在Unix和Oracle上；这些应用虽然以基于主机终端的界面，但是基于Web和GUI的应用也为数众多。

近年来，该公司在企业集成方面也是煞费苦心－已经在几个主要的核心系统之间构建了用于信息集成的信息HUB（informationHUB），其他应用间也有不少点到点的集成。

尽管这些企业集成技术在一定程度上增进了系统间的信息共享，但是面对如此异构的系统，技术人员依然觉得企业集成困难重重：

因为大部分核心应用构建在主机之上，所以InformationHub是基于主机技术开发，很难被开放系统使用；

InformationHub对Event支持不强，被集成的系统间的事件以点到点流转为主，被集成系统间耦合性强；

牵扯到多个系统间的业务协作以硬编码为主，将业务活动自动化的成本高，周期长，被开发的业务活动模块重用性差；

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

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

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

2.业务环境分析

在航空业中，RampCoordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。

通常每个航班都有一个人负责RampCoordination,这人通常称为RampCoordinator。

由RampCoordinator协调的业务活动有，检查机位环境是否安全，卸货，装货，补充燃料等。

图2是一个RampCoordination的业务流程图。

由图可见，RampCoordination流程依次有下列活动

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

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

3）检查卸货；（人工活动）

4）检查装货；（人工活动）

5）检查关门；（人工活动）

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

图2所示的流程主要针对降落后不久就起飞的航班，这种类型的航班我们称之为shortturnaround航班。

除了shortturnaround航班，我们还有其他两种类型的航班，如图3所示，ArrivalOnly的航班指降落后需要隔夜才起飞的。

DepartureOnly的航班是指每天一早第一班飞机。

这些航班的RampCoordination的流程和ShortTurnAround类型的流程大部分的业务活动是相似的。

这三种类型的航班根据长途/短途，国内/国外等因素还可以进一步细分。

每种细分的航班类型的RampCoordination的流程都是略有不同。

很明显，如此形形种种的流程之间共享着一个业务活动的集合，如此多种类型的流程都是这些业务活动的不同组装方式。

以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务，并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型，来降低流程集成成本，加快流程集成开发效率的。

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

3.服务建模

IBM推荐使用组件业务建模（ComponentBusinessModel）和面向服务的建模和架构（Service-OrientedModelandArchitecture）两种方法学建立业务的组件模型，服务模型和流程模型。

关于服务建模方法学已经超出本文范围，这里就不在累述。

服务模型是服务建模的主要结果。

RampCoordination相关的服务模型如图4所示。

和RampCoordination流程相关的有两个业务组件：

RampControl：

负责RampControl相关各种业务活动的组件

FlightManagement：

负责航班相关信息的管理，包括航班日程，乘客信息等

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

1）RetrieveFlightBO:

由FlightManagement输出，主要用于提取和航班相关的数据信息；

2）RampCoordination:

由RampControl输出，主要用于RampCoordination流程的编排；

3）CheckSpot：

由RampControl输出，用于检测机位安全信息；

4）CheckUnloading：

由RampControl输出，用于检查卸货状况；

5）CheckLoading：

由RampControl输出，用于检查装货状况；

6）CheckPushBack：

由RampControl输出，用于检查关门动作；

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

在我们的案例中，RetrieveFlightBO被实现为信息服务，RampCoordination被实现为流程服务，通过BPEL4WS方式实现；其他四个服务都是StaffService。

需要注意的是，因为环境的不同，和随着系统的演化，我们可能会改变服务的实现方式，比如CheckPushBack现在通过StaffService即人工服务实现。

将来随着自动化程度的增强，CheckPushBack完全可能通过自动化的系统实现。

到那时，我们只需重新实现这个服务，而无需改变整个流程。

这是服务的可替换性的一个典型实例。

4.IT环境分析

IT环境分析是调查现有应用技术特点的重要手段。

在我们的示例中，IT环境分析主要用于调查现有应用，为决定服务模型中服务的实现方式提供技术依据。

同时，它也是架构设计的重要依据。

如上所述，在构建RampControl系统之前，该航空公司已经有大量IT系统。

作为架构设计的重要步骤的现有IT环境调研描绘了和RampControl相关的IT系统的状况，包括周围应用和应用提供的接口，这些应用和RampControl交互的类型和数据格式。

图5是简化的IT环境视图，它描绘了RampCoordination流程和周围系统交互状况。

目前，RampCoordination流程需要四种类型的外围应用交互：

从乘务人员管理系统提取航班乘务员的信息；

从订票系统中提取乘客信息；

从机务人员管理系统中提取机务人员信息；

接收来自航班调度系统的航班到达事件；

如图所示，象航班调度信息和定票信息都存储在IMS和TPF这些相当封闭的主机系统之上。

尽管主机系统提供一定的面向开放系统的集成能力，如MQ和Socket。

但是因为主机本身的特殊性，使得这些集成方法的使用都不是那么方便。

所以如何方便地集成主机系统的信息成为RampCoordination中一个重要的技术问题，同时也是整个IT系统集成面临的主要问题。

以服务为中心的企业集成为我们提供了更为开放的集成手段。

在RampCoordination中，我们把这些主机上的数据进行了集中，并通过信息服务的形式输出给开放系统使用。

如图6所示，来自IMS的航班信息和机务人员信息，来自Oracle的乘务人员信息和来自TPF的乘客信息都被汇集为一个业务对象FlightBO。

RetrieveFlightBO服务提供访问这种业务对象的手段。

RetrieveFlightBO服务隔离了底层实现的复杂性。

外面的应用系统看到的是前面开放的接口，而不是后面封闭的主机系统。

即使将来后台主机被开放系统替代，外面的应用依然可以运行依旧。

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

5.高层架构设计

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

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

1）信息服务－FederationService:

RampCoordination流程中需要从已有系统中提取四类信息，在Service建模阶段这四类信息被聚合为FlightBO（BusinessObject）。

如上文所述，RetrieveFlightBO服务用于从已有系统中提取FlightBO。

它实际上是一个FederationService，将来自乘务人员管理系统、机务人员管理系统和订票系统中的信息聚合在一起。

从这三个已有系统来的CrewInfo,CockpitInfo和PassageInfo是在已有系统中已经存在的业务逻辑或业务数据，它们属于可接入服务（on-rampservice），接入的协议分别为JDBC,IMSJ2CConnector和socket。

乘务人员管理系统基于Oracle数据库，CrewInfo可以直接通过JDBC获得。

机务人员管理系统基于S/390上的IMS,IBM已经提供了IMS的J2CConnector，所以CockpitInfo可以通过J2Cconnector获得。

订票系统构建在IBMTPF之上，由于实时性的要求，socket是比较好的接入方法。

RetrieveFlightBO被实现为一个EJB，外部访问通过RMI/IIOP绑定访问这个服务。

在RetrieveFlightBO内部，FlightBO以SDO来表示。

2）企业服务总线中的事件服务－EventService:

在检查机务环境安全（CheckSpot）前，RampCoordiator需要被通知航班已经到达。

这个业务事件由航班调度系统激发，FlightArrival是典型事件发现服务（EventDetectService），它通过MQ将事件传递给MessageBroker,通过JMS的Pub/Sub，这个事件被分发给CheckSpot。

这里的EventService是本例中ESB的重要组成部分。

通过ESB上的通用事件服务，现有InformationHub的缺陷得到了克服。

应用程序间的事件集成不再需要点到点的方式，而是通过ESB的事件服务完成订阅发布，应用程序间的耦合性得到了极大的缓解。

3）流程服务－ProcessService:

RampCoordination被实现为一个ProcessService，它被WBISF的BPEL4WS容器执行，BPEL4WS容器提供ChoreographService,TransactionService和StaffService支持。

RampCoordination通过RMI/IIOP协议调用，在BPEL4WS容器中WSIF被用于通过各种协议调用服务,它成为ESB中TransportService的一部分。

RampCoordination中的人工动作被实现为StaffService而集成到流程中。

这里StaffService通过Portlet实现，运行在WebspherePortalServer上。

PortalService实现部分DeliveryService支持PDA设备，RampCoordinator通过PDA设备访问系统。

4）企业服务总线中的传输服务－RCMS是即将新建系统用于提供包括RampCoordination在内的RampControl的功能。

RCMS通过由WSIF实现的TransportService以SOAP/HTTP调用RampCoordination服务。

6.开发过程

尽管以服务为中心的企业集成在开发阶段和普通的应用开发并没有本质的区别，但是它在角色，职责、工具和方法还是有不少自己的特色。

下图汇总了本文示例中开发角色，职责，开发方法和工具，仅供大家参考。

7.结束语

本文通过一个简单的案例，讲解了以服务为中心的企业集成的主要步骤和涉及的技术。

这些集成的技术，无论是方法学，体系结构，还是编程模型都在不断的发展中。

随着这些技术的不断完善，以服务为中心的企业集成方案的实施将更加简单高效。

参考资料

IBMSOAHomepage,

IBMProcessIntegrationHomepage,

Patterns:

SOAwithanEnterpriseServiceBusinWASV6,IBMRedbook,

WebSphereBusinessIntegrationServerFoundationV5.1Handbook,IBMRedbook,

Service-OrientedArchitectureCompass,IBMPress,

EnterpriseApplicationIntegration,WilliamA.Ruh

EnterpriseInteration,BethGold-Bernstein,WilliamRuh,ISBN0-321-22390-X

NextGenerationApplicationIntegration,DavidS.Linthicum,ISBN0-201-84456-7