面向服务：是噱头还是希望？

企业架构（EA）、面向服务的企业（SOE）、面向服务的架构（SOA）和面向服务的计算（SOC），这些术语如今出现在更加广泛、更加有影响力的受众面前。遗憾的是，与许多“新概念”一样，人们通

常对它们所依赖的想法和实践存在误解。难怪这些术语在有些人看来如同时髦术语或者宣传噱头

本文试图事先对这些术语作一基本、又有点超前的解释：为什么它们对我们很重要？它们来自何处？它们对业务和信息技术 （IT）意味着什么？正如大多数似乎突然带有偶然性地流行的新颖概念一样，这些概念除非得到大众的接受、成为企业的设计范例，否则很可能昙花一现。至于 EA、SOE、SOA和SOC，它们会在这种根本性转变当中发挥作用，这点可以相当肯定。

围绕这个议题而经常被问到的问题包括：SPA是什么？SOE是什么？SOA是什么？SOC是什么？它们之间有着怎样的相互关系？要回答这个涉及多方面的问题，我们先要得到适当的视角，那样才能领略企业架构的全貌。

面向服务环境下的企业架构

不过，要真正看清楚所谓的EA的轮廓及细部，并且从这个角度开始了解SOE和SOA如何能够实现EA，我们就要着眼于宏观角度，那样才能够看清 楚这些概念可以适用的整个环境。事实上，“企业”一词绝不仅仅是指一家公司，甚至不是指整个行业，也不是指组织生命过程当中的某个特定时间。“企业”涵盖 了组织或有机体的整个生命周期。

有了所需的观察范围之后，我们就可以运用这种视角即经济或者生态生命周期的视角，确保生命周期并不仅限于我们必然带来的单个生物实体模型。与文 化一样，企业的寿命要超过单个成员的寿命，而这种生命周期要求我们把眼光不能单单着眼于自己的生命。在我们生活的许多方面，譬如高等教育机构、家庭或者亲 属关系网和政府等，我们对这种视角习以为常。不过在EA方面，我们现在需要明确这样的机制并加以实施：能够不断的进行审视、执行质量保证作为理所当然的事 情，并且实际上把构建、使用、学习、评估、构建（调整/重新构建）、使用、学习……这一周而复始的周期实行制度化。那种机制。当然，这事先假定：这个过程 的“事实上”的起始点就是，企业或者组织恰好处在这样一个时间点：它决定开始构建及部署EA这个过程。起始阶段不需要某种全面的评审。实际上，获得正确的 视角应当可以让企业重新专注于当前问题，同时仍不忘更重要的问题。

噱头和希望的区别

在表明业务版本的扩展型企业架构框架（E2AF）的下面这张图当中，SPA、SOE、SOA、SOC和STP等概念位于框架上，可以帮助读者了 解与E2AF有关的这些概念的相对位置。E2AF上有四个关键成功因素（CSF），它们对于在贵组织实施面向服务取得成功起到了关键作用。到底是噱头还是 希望，完全取决于这四个CSF。

服务范例采用（SPA）

面向服务提供了一种理想的世界：里面的资源划分整齐，以服务这种形式加以一致地呈现。因此，企业想从服务方面设计企业架构，就一定要采用服务范 例。所以，企业在业务、信息、信息系统和技术基础设施的各个层面都要从功能服务方面加以分解。采用一致、合理的做法可以提供松散耦合的功能服务，它们可以 在所谓的共享服务中心里面进行外包、内包或者组合。

与不想采用服务范例的组织相比，采用服务范例、并且以合理方式进行实施的企业可以获得更大的灵活性、适应性及敏捷性。

面向服务的企业（SOE）

面向服务的企业其实以一种极其水平的方式连接业务流程。它采用的企业基础设施可以提供企业架构和安全基础，能够跨企业以一致的方式运行这些服务。

虽然在过去的三十年里，面向服务的架构这一概念被系统架构师奉为最佳实践，但现在它得到了各个地方许多组织的接受，被认为是获得业务敏捷性的关 键。但SOE和SOA既不是即开即用的成套系统，也不是什么单一技术，更不会让所有问题都能迎刃而解。尽管SOE能够带来甚至促进组织上的变化，但它也要 求主管人员、企业架构师及项目经理要有不同的思考和行事方式，否则完全会发现自己遇到新问题，根本得不到多少好处。

服务是什么？

服务就是指实现的定义明确的业务功能，它可以独立于系统里面定义的其他任何服务的状态而工作。服务有一系列定义明确的接口，可以通过服务用户和服务本身之间事先定义的契约（contract）进行工作。

服务有着不同性质。一项业务服务可能意味着“getAccountBalance”；一项业务交易服务可能意味着“makeCreditCardPayment”；一项系统服务可能会提供“deleteAFile”之类的一些操作。

自上而下与自下而上的服务定义

理想情况下，在面向服务的企业（SOE）里面，服务在企业层采用自上而下的方法进行定义及描述。通过对定义明确的业务功能进行功能分解，我们就 能确认业务功能“Financial Services（金融服务）”。这项业务功能又可以分解成较低层的服务，譬如Invoicing、Payements和Banking等。

在面向服务的架构里面，系统作为服务集合体来运行。每个服务可能会与其他不同服务进行联系，共同完成某项任务。某个服务的使用可能要结合几个低层功能。这种情况下，这些低层功能不被认为是服务。

自上而下：SPA / SOE / SOA

1、按照需要的业务转型：对现有的业务模型进行全面的业务转型，或者部署新的业务模型（SOE）。

2、整个企业内的IT转型：企业设计实施方案，实现跨整个企业的业务功能进行集成（SOA/SOE）。

自下而上：SOC / SOA

1、对业务功能实行面向服务的集成：跨企业内外的多个应用集成服务，以实现业务目标（SOI/SOA）。

2、实施单项Web服务：利用新的或者现有的应用里面包括的任务创建服务（SOC/SOA）。

在对适合组件化（模块化）及服务提供的现有遗留资产进行自下而上的分析的同时，也进行自下而上的域分解（domain decomposition），即流程建模及分解、面向差异的分析、策略和业务规则分析，以及域特定的行为建模（使用语法和图表）。为了了解项目背后的业 务目标、让服务和这种业务目标相一致，就要进行目标－服务建模。

如何识别服务？

从技术上来说，你可以把任何一项功能变成一项服务，但这样做的话，会让组织的IT系统杂乱无章、难以维护。识别服务的优点在于，可以把服务当作一系列合理组织的功能。服务必须代

表有形的业务概念。譬如，getAccountBalance就是有形的业务流程，但convertStringToNumber不是可以识别的业务概念，因而不适合作为一项服务。

识别潜在服务的过程绝非易事。在现阶段，我看到许多组织迷恋于现有的技术，却忘了这一点：技术不该驱动业务。虽然识别服务是在整个组织进行一系列分析的过程，但还是可以运用某些分析模式，找出潜在服务。以下是决定识别服务时应当考虑的一些方面：

·分析组织业务流程的某一个部分，然后把它们分解成几个比较小的业务流程。譬如说，一家组织的订单处理系统可以分解成几个比较小的业务流程，譬如checkInventory、processPayment和updateInventory等。

·确认是否有没有比较小的业务流程可重复使用，或者是否有可能重复使用于组织的其他业务流程。譬如说，checkInventory也可以供组织里面的库存管理应用使用。可重复使用的业务流程非常适合作为服务使用。

·为这些业务流程拟订所需的输入，然后定义它们必须得到什么样的特定输出。一定要注意确保这些输入及输出的通用性，以便服务依然可以重复使用、能够提供给不断变化的业务模型。譬如说，目前的processPayment服务也许只能接受支票付款，但应当足够灵活，以便以后支持信用卡支付，从而支持不断变化的业务需求。因而，必须以通用的方式定义processPayment服务的输入。

·确认这些业务流程是否已经作为组织里面的IT系统加以实施。如果是这样，那么为所有现有的应用分析业务关键因素，确认哪些应用需要转换成SOA。譬如说，如果某服装零售商再也不接受退货/换货，我们就用不着考虑分析Refund/Exchange应用。

·确认哪些服务可以协同工作、不同服务之间有着怎样的依赖关系。

·弄清楚服务只能在内部使用还是也可以提供给外部使用者。这将对服务的定义带来影响。

·确认服务是以同步方式使用还是以异步方式使用。服务所能允许的响应时间是多长？

这些准则来自我们为业界的好几家组织成功提供基于SOA的解决方案时得到的实际经验。这份列表绝不完整，但我认为，不可能有完整的一套方法可以确认有待实施的正确的一系列服务。这始终是个不断变化的过程，因为一直会有新的需求产生。不过本文的主旨是，你要特别注意识别可以部署在组织里面的那一系列服务。

面向服务的建模

现在有许多重要的活动和决策不仅仅影响集成架构，还会影响企业和应用架构。它们包括来自使用者和提供者这两个关键视图的活动。

活动通常由提供者和使用者这每个角色来开展。请注意：提供者的活动包括使用者的活动（譬如，提供者也会关注服务的识别和分类等操作）。在许多情况下，角色差异来自这一事实：使用者明确规定了他们需要的服务，往往会寻找它，一旦他们相信自己所寻找的服务和服务提供商提供的服务相互匹配，他们就会按需要绑定及调用服务。反过来，提供者需要发布他们愿意支持的服务：不但要确保功能，还要确保更重要的使用者所要求的服务质量（QoS）。使用者和提供者之间这种不明显的契约就有可能变成服务级别协议（SLA）方面的明显的契约。通过电子方式或者通过业务和法律途径进行协商。

上述活动被描述成在面向服务的建模里面流动的活动。

面向服务的建模和架构这一过程包括三个基本步骤：识别、说明及实现服务、组件及流动（通常称为服务编排）。

服务识别

这过程结合了域分解、现有资产分析及目标－服务建模的自上而下、自下而上和中间向外等方法。在自上而下视图中，业务使用实例的蓝图提供了业务服务的规范。这个自上而下的过程往往被称为域分解，它包括把业务域分解成功能区域和子系统，包括流动或者流程分解成流程、子流程和高级业务使用实例。这些使用实例往往非常适合作为在企业边缘提供的业务服务，或者非常适合作为在企业里面跨业务部门使用的业务服务。

在这过程的自下而上部分或者现有系统分析当中，现有系统经分析后，被选择作为适合提供低成本的解决方案，以实施支持业务流程的底层服务功能。在这个过程中，你可以分析及利用来自遗留和套装应用程序的应用编程接口（API）、事务和模块。在某些情况下，需要对遗留系统进行组件化处理，以便重新对支持服务功能的现有资产进行模块化处理。

中间向外视图包括目标－服务建模，以验证及发现没有被自上而下或者自下而上的服务识别方法所发现的其他服务。它把服务同目标与子目标、关键业绩指标及衡量尺度联系在一起。

服务分类

服务识别后就开始这项活动。开始把服务分类成分层服务很重要，这体现了服务的组合或者不规则性：服务可以也应当由粒度更细的组件和服务组成。分类有助于确定组合和分层，还可以根据服务层次来协调构建相互依赖的服务。另外，这还有助于缓解服务激增的现象：越来越多的细粒度服务被定义、设计及部署，却几乎没有多少管理，导致性能、扩展性及管理方面出现严重问题。更重要的是，服务激增无法提供对业务有用、并且便于实现规模经济的服务。

子系统分析

这项活动获得在上述域分解期间发现的子系统，然后明确规定这些子系统之间的相互依赖关系和流动。它还把域分解期间识别的使用实例作为通过子系统接口提供的服务。对子系统的分析包括创建对象模型，以呈现将提供服务、实现服务的包含子系统的内部工作原理和设计。然后实现“子系统”的设计构件，作为实现以下活动的服务的粗粒度组件的实施构件。

组件分类

在下一个重要活动中，明确规定了实施服务的组件的细节：

·数据

·规则

·服务

·可配置的简档

·差异

消息传送及事件规范和管理定义出现这一步骤中。

服务分配

服务分配包括把服务分配给目前识别的子系统。这些子系统拥有的企业组件能够实现已发布的功能。你经常会进行简单化假定：子系统与企业组件拥有一对一的关系。用以下组合方式利用模式构建企业组件时，就会出现组件构建：

·中介者

·外观

·规则对象

·可配置的简档

·工厂

服务分配还包括为SOA里面的几个层分配服务及实现服务的组件。分配组件和服务给SOA里面的层是一项重要任务，需要记录及分析重要的架构决策，这些决策不仅与应用架构有关，而且与设计用来在运行时支持SOA实现的技术操作架构。

服务实现

这一步认识到，必须选择或者定制实现某项服务的软件。现在可以获得的其他方案包括：利用Web服务集成、转换、订购及外购部分功能。在这一步当中，你需要决定将利用哪个遗留系统模块来实现某项服务、通过自下而上的方法构建哪些服务。实现服务而不是业务功能的其他决策包括：服务的安全、管理及监控。

服务迁移方案（STP）

你的SOE、SOA和SOC完全在发展当中，你向面向服务迁移的过程将经历很长一段时间，并且分成多个阶段。因而，迁移管理是在通向面向服务的漫长道路当中最关键的问题之一。

尽管迁移至面向服务的平台意义重大、关键的Web服务标准继续面临不确定性，加上大规模部署SOA往往会产生重大影响，现在是开始考虑迁移的时候了。成功迁移的关键在于，在有关SOA的　暴风骤雨般的活动当中找到一个平静点，然后制订直观的方案，指导贵组织走过面临技术障碍、组织阻力及不断变化的行业趋势的道路。

制订迁移方案前先进行影响分析

为了评估向面向服务迁移的可行性，你先要估计这样一种迁移会产生什么样的实际影响。因而，你在最初的影响分析完成之前，暂时不要考虑各种规划。利用影响分析结果作为你的主要指导原则，并且把预算限制因素、相关的项目需求及其他外部驱动因素（如战略性业务目标）考虑进来，你应当能够确定规划迁移的范围。SOA迁移方案只适用于一小部分的组织技术环境，这并不罕见。譬如说，企业里面也许有几个遗留方面无法保证不会受到服务封装的影响。也许你的目标就是构建专用的主机托管环境，不仅仅旨在支持新的面向服务的应用。不过，集成需求往往会推动SOA迁移。这种情况下，你项目的范围很容易看到：SOA的引入会影响你IT企业的大部分。

不过，面向服务的原理本身并不复杂，但运用这些原则会导致相对复杂的自动化解决方案。如果共享及组合来自不同解决方案的服务，以支持新的或者经过改动的业务流程，更是如此。如果你想处在面向服务的环境下，你的项目队伍就要改变对通用架构的根本层面进行考虑的方式，譬如组件化、集成和流程自动化。

面向服务的成熟度

不同公司在采用及融合面向服务模式（SO）方面的成熟度各不相同。有些只是刚开始使用SO的技术实例：Web服务，探究SO世界。它们对遗留功能进行包装，然后加以提供，供第三方、客户和业务合作伙伴使用。这样一来，它们随之进入了状态：扩大开发队伍规模、开始改变企业文化，以便更好地支持SO，并且向探究新技术和可能受影响的业务功能迈出了头几步。这是第一个阶段。

SO采用的第二个阶段是，Web服务的初始测试成功地得到了解决；如今组织开始使用服务集成系统和应用。随着专有协议、粘合代码和点对点连接让位于更加开放、基于标准的协议以及基于每个系统外部化的服务描述的相互关系，我们进入了面向服务的集成（SOA）领域。在这个世界，企业服务总线取得了主导权：SOA是中介、路由及转换服务调用的一种机制，不管目标服务提供商是谁。它有助于解决与点对点连接有关的许多不足。

面向服务的成熟度模型

这个SOA成熟度模型为IT用户和业务用户就SOA在组织里面的适用性和优点进行探讨提供了框架，采用成熟度分为五个级别。

服务编排

随着面向服务的架构（SOA）和Web服务越来越流行，这些不同的资产可以作为单个企业服务来提供。那么我们如何构建及把它们作为服务来提供呢？我们如何在构建基于服务的新应用或者业务流程时利用它们呢？这就是业务流程编排所要解决的问题。

Web服务编排接口（WSCI）是基于XML的一种接口描述语言，它描述了由参与跟其他编排服务进行联系的Web服务交换的消息的流动情况。WSCI描述了通过重复使用为静态接口定义的操作来参与某个消息交换的动态接口。它描述了Web服务的可观察行为。这通过所交换消息之间的临时和逻辑的依赖关系来表示，采用了排序规则、相互关联、异常处理及事务处理。WSCI还描述了相互联系的Web服务之间的集体消息交换，从而为这种相互关系提供了面向消息的全局视图。

服务粒度

服务是SOA和SOE的核心部分，这种说法恐怕不会引起人们的异议。但识别服务的方法在慢慢出现。谈论SOA时，服务往往被视为只要少须努力的任务――努力少得我们几乎都懒得谈论。描述这项任务的细节通常专注于是采用从自上而下的方法还是采用自下而上的方法。实际上，你可能会结合使用两者，但应当偏重于自上而下的方法――为了控制服务之间的一致性，这方法必不可少。

但我们实际上如何识别自己的服务呢？这无疑是通常在EA的抽象层上成进行的一项工作。在SOE里面，我们需要一种方法来识别服务，这种识别方法还要支持SOE的范例、并且利用EA方面的经验。这里的一个重要概念就是：我们不是从头开始做起！

如果你在处理SOE、SOA和EA方面有了经验，对你来说预计不会出现任何革命――这实际上是一种非常简单的方法。但这只是我们所看到的这种方法具有的强项。一个简单的信息就是：你在识别服务时，不要一开始开发解决方案！随时关注进度，每次识别一个抽象层上的服务。

图一：企业架构服务模型

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOESOA　　　SOC

STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案

图二：

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOE　　　　　SOA　　　SOC 　　　 STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案

图三：

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOE　　　　　SOA　　　SOC 　　　 STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案

图四：

规划－层次　　EA和面向服务　 　SOE

战略级别　　　服务定义　　　　　面向服务企业

战术级别　　　自上而下　　　　　SOA

操作级别　　　方法　　　　　　　面向服务　　　　　　　　服务定义

SOC　　　　　　　　　　自下而上

面向服务的计算　　　　　方法

信息提供

图五：

角色

相应角色的活动

使用者视图

服务识别

服务分类

服务提供决策

编排或组合

服务质量

提供者视图

组件识别

组件识别

服务实现

服务管理

标准实施

服务分配给组件

对SOA分层

技术原型

产品选择

架构决策（状态、流动及相互关系）

图六：

识别　　　　　域分解　　　　目标－服务建模　　　　　现有系统分析

组件流动说明　　子系统分析　　服务说明　　服务流动说明

说明　　　　信息说明　　　组件说明　　　　　　　　　消息和事件说明

服务实现决策

实现　　　　　　服务分配给组件　　　　　　　　组件层

图七：

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOE　　　　　SOA　　　SOC 　　　 STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案

图八：

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOE　　　　　SOA　　　SOC 　　　 STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案

图九：

优点

经优化的　　　　　　　　　　　　优化

业务服务

经评估的业务服务　　　　　　　　　　转型

业务服务　　　协作服务　　　　　　　　响应力

经　过　设　计　的　服　务　　　　　　成本效益

初　　　　始　　　　服　　　　务　　　　　　 功能

图十：

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOE　　　　　SOA　　　SOC 　　　 STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案

图十一：

建模层：

流程/协作定义

WSCI                 WSCI                WSCI

动态、编排过的　　　　动态、编排过的　　　动态、编排过的

Web服务接口　　　　　Web服务接口　　　　Web服务接口

WSDL　　　　WSDL　　　　　WSDL　　　　　WSDL

静态的Web　　静态的Web　 　静态的Web 　　静态的Web

服务接口      服务接口       服务接口       服务接口

图十二：

企业成熟度　　　服务编排　　　服务质量　　　服务粒度

业务　　　　　　SPA　　　　 　SOE　　　　　SOA　　　SOC 　　　 STP

信息　　　　　　服务　　　　　面向　　　　　面向　　　面向　　　　服务

信息系统　　　　范例　　　　　服务的　　　　服务的　　服务的　　　迁移

技术基础设施　　采用　　　　　企业　　　　　架构　　　计算　　　　方案