http://www.ibm.com/developerworks/cn/webservices/ws-soi1/
http://www.ibm.com/developerworks/cn/webservices/ws-soi2/
以服务为中心的企业整合－案例分析 |
 |
|
级别： 初级 生 毛新, IBM 中国软件开发实验室 IBM软件部企业集成解决方案大中华区首席架构师 2005 年 12 月 23 日 本文是“以服务为中心的企业整合”系列文章第二部分。在本文的姊妹篇"以服务为中心的企业整合"中，我们探讨了以服务为中心的企业集成的理论知识，本文以一个经过简化的实际案例为例，介绍了以服务为中心的企业集成的基本步骤，从业务分析，到服务建模，到架构设计，到系统开发的整个生命周期。以服务为中心的企业集成涉及到的主要技术被穿插在各个步骤中进行了详细的讲解。
某航空公司的IT系统已有好几十年的历史。该航空公司的主要的业务系统构建于上世纪七八十年代，以IBM的主机系统为主 － 包括运行于TPF上的订票系统，和运行在IMS上的航班调度系统等。在这些核心系统周围也不乏基于Unix的非核心作业系统，和基于.Net的简单应用。这些形形色色的应用，有的用汇编或COBOL编写，运行于主机和IMS之上，有的以PRO*C编写，运行在Unix和Oracle上；这些应用虽然以基于主机终端的界面，但是基于Web和GUI的应用也为数众多。 近年来，该公司在企业集成方面也是煞费苦心－已经在几个主要的核心系统之间构建了用于信息集成的信息HUB(information HUB)，其他应用间也有不少点到点的集成。尽管这些企业集成技术在一定程度上增进了系统间的信息共享，但是面对如此异构的系统，技术人员依然觉得企业集成困难重重：
为了解决这些企业集成中的问题，该公司决定以Ramp Control系统为例探索一条以服务为中心的企业集成道路。本文将以Ramp Control系统中的Ramp Coordination流程为例说明如何用以服务为中心的企业集成技术一步步解决该公司IT技术人员面临的企业集成问题。 为了便于说明，示例中的业务系统和业务流程都进行了必要的简化。
在航空业中，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的流程都是略有不同。 很明显，如此形形种种的流程之间共享着一个业务活动的集合，如此多种类型的流程都是这些业务活动的不同组装方式。以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务，并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型，来降低流程集成成本，加快流程集成开发效率的。以服务为中心的企业集成通过服务建模过程发现这些可重用的服务，并通过流程模型将这些服务组装在一起。
IBM推荐使用组件业务建模(Component Business Model)和面向服务的建模和架构(Service-Oriented Model and Architecture)两种方法学建立业务的组件模型，服务模型和流程模型。关于服务建模方法学已经超出本文范围，这里就不在累述。  服务模型是服务建模的主要结果。Ramp Coordination相关的服务模型如图4所示。和Ramp Coordination流程相关的有两个业务组件：
这两个业务组件分别输出如下服务： 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完全可能通过自动化的系统实现。到那时，我们只需重新实现这个服务，而无需改变整个流程。这是服务的可替换性的一个典型实例。
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系统的平滑演进提供了必需的条件。
根据需求和设计阶段的业务模型和现有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服务。
尽管以服务为中心的企业集成在开发阶段和普通的应用开发并没有本质的区别，但是它在角色，职责、工具和方法还是有不少自己的特色。下图汇总了本文示例中开发角色，职责，开发方法和工具，仅供大家参考。 
本文通过一个简单的案例，讲解了以服务为中心的企业集成的主要步骤和涉及的技术。这些集成的技术，无论是方法学，体系结构，还是编程模型都在不断的发展中。随着这些技术的不断完善，以服务为中心的企业集成方案的实施将更加简单高效。
|
||||||||||||||||||||||||||||||||||||||||||||
以服务为中心的企业整合 |
|
|
级别： 初级 生 毛新, IBM 中国软件开发实验室 IBM软件部企业集成解决方案大中华区首席架构师 2005 年 12 月 27 日 本文讨论企业整合(集成)的新发展：以服务为中心的集成（Service-Oriented Integration，简称 SOI）。 您将了解到什么是 SOI，推动 SOI 发展的因素以及SOI 带来的价值。作者讨论了 SOI 解决方案所涉及的要素，和这些要素相关的技术、标准以及IBM的产品支持，最后作为总结将它们包括在 IBM 的集成参考架构中，指出如何实现各种集成需求。本文还讨论了在企业集成实践中需要重点注意的事情，如战略规划和IT管理。本文的姊妹篇"以服务为中心的企业整合－案例分析"，用一个实际案例来说明基于 IBM 产品的实际 SOI 应用，帮助读者感性地理解 SOI。
"以服务为中心的集成"是英文词语"Service-Oriented Integration"的中文翻译，简称 SOI。 它可以定义为：在"以服务为中心的体系架构"（Service-Oriented Architecture，SOA）中，通过服务的交互来集成各企业的 IT 资源，如分布的应用或者数据，帮助企业 IT 部门将已有但老旧而不灵活的系统集成起来，释放其中功能或数据为可重用的服务与业务流程。 企业集成的推动因素。推动"企业应用集成"（Enterprise Application Integration, EAI ）的因素，来自商务和技术两个方面。从商务的角度，今天企业要在全球化的经济环境中求生存和发展，就必须努力适应越来越强的竞争和越来越快的变化，这意味着一个企业的业务模型要变得灵活以快速应变，也就是随需应变。在一个企业的业务模型变得灵活的转型过程中，需要将业务流程不断地自动化，然后跨部门横向集成它们，并且管理和优化它们，这意味着支撑这些流程的技术基础，即 IT 应用和数据资源等，需要在企业范围内集成。所以，业务灵活应变的能力是 SOI 的驱动因素之一。 在技术方面，IT 部门面临着业务部门越来越高的期望值，就是用更少的钱做更多的事情，但要做得更快、更好，这迫使 IT 部门考虑如何最大程度地重用已有应用的功能和数据资源，来支持新应用的开发。但这种重用面临着如何将高度异构、分布的各个应用集成起来的难题，SOI是目前最有效的解决之道。在 SOI 中，首先各个应用的功能被封装为基于标准来描述和供访问的服务；其次，借助于 SOI 的通用连接能力，这些来自不同应用的服务，不需要关心对方的位置和实现技术，以松散耦合的方式相互交互来完成集成，所以只要服务的接口描述不变，服务的使用者和提供者双方可以自由发生变化而互不影响；最后，通过服务组合，服务可以按不同的方式来组合成为不同的业务流程。当某个业务流程发生变化的时候，大多数时候，我们调整组装服务的方式来满足这种变化。总之，这种通过重用粗粒度服务而不是在底层编程来开发新应用以满足业务新需求的方法，使得 IT 组织能够以更少的投入、更快的速度、更好的质量来开发应用。综上所述，可以灵活应变的重用方式，是 SOI 的另一个驱动因素。 集成解决方案的发展沿革。集成企业应用的方法各种各样，初级一点的借助于简单的机制如应用编程接口，管道、共享目录和文件，或者某些传输协议如 FTP 来交换数据和互操作；高级一点的则使用各种消息中间件来提供消息的传输、转换、合并、路由和分发、事件的发布和订阅等；分布式计算技术，如 CORBA，COM 等，也有较广的使用。 在初期实践中，应用之间的连接拓扑大多数情况下是点对点的，硬编码的，所使用的协议是非标准的，功能的提供者和使用者之间是紧耦合的，功能的粒度通常较细，数据的表示也不统一。随着集成复杂度的增长，和实践经验的总结，开始出现一些从好的实践中总结出来的集成模式，如消息中枢（Message Backbone）、信息总线、应用集成中心（Application Integration Hub），这些模式从不同的角度以不同的方式来管理集成的复杂性，但都或多或少地尝试提供一个集成基础设施来简化应用之间日趋复杂的连接拓扑，提供异构数据和功能访问方式之间的转换，甚至提供一致的数据和功能表示与访问方式。通过元数据和应用相关的领域知识，这些集成基础实施提供了很多中介和转换的机制与模式来实现高级的功能，如路由、动态选择等能力。 随着互联网络技术的发展、普及和应用，相关技术和标准，如 XML 和 Web Service，被广为接受，这给应用集成带来了新的发展。企业应用架构的风格开始朝着以服务为中心的方向发展，而企业应用集成也转向以服务为中心的集成，服务的描述和访问基于开放一致的标准（如 WSDL），连接应用的基础设施继承了过去发展的成果，并通过支持开放标准，来提供通用的连接服务，包括基本的服务如消息传输、转换，事件的发布和订阅，服务的中介（选择、路由），和高级的服务如安全、事务、服务质量，以及可管理性，来使得服务在一个标准、开放、可靠、安全、可管理、满足服务质量要求的环境下，以松散耦合的方式相互交户，根据需求动态地进行企业应用集成，达成非常高程度的灵活应变能力和重用能力。SOI 是对现有集成技术与实践的总结和标准化。 SOI 的好处。SOI 继承和发展了传统的 EAI，比较而言，SOI 的好处在于:
通常，完整的SOI 解决方案包括如下要素：
IBM的 Websphere 业务集成参考架构(见图1，以下称参考架构)是典型的以服务为中心的企业集成架构，本文接下来的讨论都将以此参考架构为背景进行。  以服务为中心的企业集成采用"关注点分离"(Separation of Concern)的方法规划企业集成中的各种架构元素，同时从服务视角规划每种架构元素提供的服务，以及服务如何被组合在一起完成某种类型的集成。这里架构元素提供的服务既包括狭义的服务（WSDL描述），也包括广义的服务（某种能力）。从服务为中心的视角看来，企业集成的架构按图1所示的方式划分为六大类：
企业服务总线(Enterprise Service Bus)，以下简称ESB, 是过去消息中间件的发展，ESB 采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态地互联互通。 ESB 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。 ESB 所提供的基于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB 中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是 ESB 借助于服务注册管理以及问题域相关的知识（如业务方面的一些规则等）自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础，使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。 所以，ESB 采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOI 解决方案是一个松散耦合、灵活的架构。 需要注意的是，ESB 是一种架构模式，不能简单地等同于特定的技术或者产品，但实现 ESB 确实需要各种产品在运行时和工具方面的支持。IBM 有很好的产品支持，运行时支持包括 WebSphere ESB 和 WebSphere Message Broker；而工具方面 IBM 则有 WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务，使用各种模式，转换消息，定义路由等等。 整合已有应用 - 应用和信息访问服务。已有应用和信息是实现业务逻辑和业务数据的重要资产。通过集成已有的应用和信息将可以在已有企业系统上实现更多增值服务，所以集成已有应用和信息是企业集成中重要的一环。 以服务为中心的企业集成通过应用和信息访问服务(Application and Information Access Service)来实现对已有应用和信息集成。它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线，这些被包装起来的业务逻辑和数据就可以方便的参与上层的业务流程，从而已有应用系统的能力可以得以继续发挥。这里的已有应用包括遗留应用、预包装的应用和各种企业数据存储。在参考架构中，主要有两类访问服务：
整合新开发的应用 - 业务应用服务。和已有应用和数据类似，新开发的应用也作为重要的业务逻辑成为企业集成的目标。以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。一方面业务应用服务帮助程序员开发可重用、可维护和灵活的业务逻辑组件，另一方面，它也提供运行时的集成提供对业务逻辑组件的自治管理。在参考架构中，有三类业务应用服务：
整合客户和业务伙伴（B2C/B2B）－伙伴服务。以服务为中心的企业集成通过伙伴服务提供与企业外部的B2B的集成能力。因为业务伙伴系统的异构性，伙伴服务需要支持多种传输协议和数据格式。在参考架构中，提供如下服务：
数据整合－信息服务。企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生，用于提供对分布式数据和异构数据的透明访问。 以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务：
流程整合- 流程服务。企业部门内部的IT系统通过将业务活动自动化来提高业务活动的效率。但是这些部门的业务活动并不是独立的，而是和其他部门的活动彼此关联的。勿容置疑，将彼此关联的业务活动组成自动化流程可以进一步提高业务活动的效率。业务流程集成正是在这一背景下诞生的。 以服务为中心的企业集成通过流程服务来完成业务流程集成。在业务流程集成中，粒度的业务逻辑被组合成业务流程。流程服务提供自动执行这些业务流程的能力。在参考架构中，流程服务包括如下内容：
用户访问整合 - 交互服务。将适当的信息，在适当的时间，传递给适当的人是一直是信息技术追求的目标。用户访问集成是实现这一目标的重要一环，它负责将信息系统中的信息传递给客户，不管它在那里，它以什么样的设备接入。 以服务为中心的企业集成通过交互服务来实现用户访问集成。参考架构中的交互服务包括如下类型：
企业集成涉及面很广，不仅需要开发新的应用并使其成为可以被用于企业集成的功能组件，而且需要将被包装的已有的应用和数据用于集成；不仅有企业内部的集成，而且需要和企业外部的系统集成；不仅有交互集成和数据集成，还有功能和应用集成。考虑到这其中的每部分在技术上都会涉及到各种平台和中间件，企业集成的技术复杂性是普通应用开发不可比拟的。这种技术复杂性需要更强有力的开发工具支持。企业集成的开发工具需要有标准的工具框架，这些工具能够以即插即用方式支持来自多家厂商的开发工具。同时，企业集成的开发工具需要支持整个软件开发周期，以提高开发过程中各种角色的生产力。 在以服务为中心的企业集成中，除了需要支持整个软件开发周期和标准的工具框架以外，开发服务需要提供和服务开发相关的技术：
开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中开发者角色和职责的不同，有如下四类服务：
一方面，以服务为中心的企业集成通过各种集成提高信息流转速度，从而提高生产效率。另一方面，以服务为中心的企业集成也为业务创新和优化提供了支持平台－业务创新和优化服务。 业务创新和优化服务以业务性能管理(BPM)技术为核心提供业务事件发布、收集和关键业务指标监控能力。具体而言，业务创新和优化服务由以下服务组成：
业务创新和优化服务与开发服务是紧密相关联的。在建模阶段被确定的业务流程的关键性能指标被转为特别的事件标志被构建到业务流程中，建模过程中的业务流程也被转换为用于监控服务的监控上下文。在业务流程执行过程中，这些事件标志激发的事件被公共事件框架服务截获，经过采集服务的过滤被传递给监控服务用于计算关键性能指标。关键性能指标作为重要的数据被用于重构或优化业务流程。这种迭代的方法使得业务流程处于不断的优化中。 为业务流程和服务提供安全、高效和健康的运行环境也是以服务为中心的企业集成重要的部分，它由IT服务管理来完成。IT服务管理包括如下两部分： 安全和目录服务(Security and Directory Service)：企业范围的用户、认证和授权管理，如单点登录(SSO)；系统管理和虚拟化服务(System Management and Virtualization Service)：用于管理服务器，存储、网络和其他IT资源。 IT服务管理中相当一部分服务是面向软硬件管理的，而另外一部分服务，特别是安全和目录服务，以及操作系统和中间件管理，会通过企业服务总线和其他服务集成在一起，用于实现业务流程和服务的非功能性需求，如性能、可用性和安全性等。 下面的表格列出乐SOI架构元素中的技术标准，和IBM的产品如何支持这些架构元素。 表 1：SOI架构元素中的技术标准以及支持架构元素的IBM的产品 
企业集成首先是一个战略性的活动，在我们的经验中，有很多的企业将重点放在集成技术上，这导致了很多失败的案例。作为一个战略性的活动，企业集成首先要从全局出发，制定整个企业集成的策略。这种策略包括业务目标，集成路线图，技术规范，和对开发管理提出的新要求。 企业集成的目的是为了整合 IT 资源，形成一个灵活的 IT 基础设施，来满足业务随需应变的要求。所以要充分考虑业务面的压力和痛点，未来发展和转型对 IT 带来的新需求，以确定集成的战略目标。在环境发生变化时，要随业务面的调整作必要的修改。在我们的观察中，企业 IT 组织往往由于缺乏高级业务管理人员的参与，而无法制定与业务对齐的集成战略，失去企业集成赖以成功的最重要的基础。 在制定集成的战略目标后，要根据目标的优先级，考察当前 IT 环境，确定集成远景，分析差距，定义集成路线图。考察当前可得到的技术、产品、相关技能和服务的可获得状况，定义高层技术规范，包括集成方法、参考架构、技术和产品的选择标准、所遵循的业界标准等等。然后结合人力、物力和资金的投入情况，导出项目群。在我们的观察中，很多企业为了应付业务需求，匆忙上马，缺乏统一规划，导致企业 IT 架构越来越混乱，不能适应业务的变化而日渐被动。 由于集成是一个企业范围内的活动，一个集成项目往往影响若干个部门，其结果也由多个部门所共享使用，所以需要企业级的协调机制。这要求企业调整其已有的 IT 管理（IT Governance）机制，要有一个角色来协调集成项目，并被授权，利用 IT 开发管理的过程，保证相应集成规范得到执行。 另外值得注意的是关于成熟度的考虑，不同企业有不同的成熟度，包括业务本身、IT 系统、IT 组织自身在技能和管理方面，它们的成熟度，对企业集成的成功与否，也都有很大的影响。对成熟度的考察，会帮助我们制定更稳健、实际的集成策略。 服务建模（Service Modeling）是 SOI 活动中至关重要的活动。它包括如何找到和确定服务，如何处理服务的粒度，如何通过服务体现和实现业务目标，如何详细说明服务，如何确定服务与已有系统的关系等。在我们的实践中，这对很多 IT 组织机构都是一个难题，可以考虑一些专业公司的培训，如 IBM SOA 设计中心基于丰富的实践所提供的各种服务。
以服务为中心的企业集成方法是对以往企业集成技术的继承与发展。它基于关注点分离、松散耦合等源自最佳实践的架构原则，继承了EAI，消息总线，流程集成，数据集成等优秀技术，结合以服务为中心（Service Orientation）的先进思想，正在给企业集成领域带来巨大的变化。随着SOI及相关技术的逐渐成熟，SOI正在成为企业集成的新方向。本文的姊妹篇"以服务为中心的企业整合－案例分析"，将用一个实际案例来说明基于 IBM 产品的实际 SOI 应用，帮助读者感性地理解 SOI。
|
||||||||||||||||||||||||||||||||
