面向服务(SOA)噱头还是希望

面向服务：是噱头还是希望？企业架构（EA）、面向服务的企业（SOE）、面向服务的架构（SOA）和面向服务的计 算（SOC）,这些术语如今出现在更加广泛、更加有影响力的受众面前。遗憾的是，与许多 “新概念”一样，人们通常对它们所依赖的想法和实践存在误解。难怪这些术语在有些人看来 如同时髦术语或者宣传噱头。本文试图事先对这些术语作一基本、又有点超前的解释：为什么它们对我们很重要？它 们来自何处？它们对业务和信息技术（IT）意味着什么？正如大多数似乎突然带有偶然性地 流行的新颖概念一样，这些概念除非得到大众的接受、成为企业的设计范例，否则很可能昙 花一现。至于EA、SOE、SOA和SOC，它们会在这种根本性转变当中发挥作用，这点可 以相当肯定。围绕这个议题而经常被问到的问题包括：SPA是什么？ SOE是什么？ SOA是什么？ SOC是什么？它们之间有着怎样的相互关系？要回答这个涉及多方面的问题，我们先要得 到适当的视角，那样才能领略企业架构的全貌。面向服务环境下的企业架构不过，要真正看清楚所谓的EA的轮廓及细部，并且从这个角度开始了解SOE和SOA 如何能够实现EA,我们就要着眼于宏观角度，那样才能够看清楚这些概念可以适用的整个 环境。事实上，“企业”一词绝不仅仅是指一家公司，甚至不是指整个行业，也不是指组织生 命过程当中的某个特定时间。“企业”涵盖了组织或有机体的整个生命周期。Mini t/iinr?阳u 口匕_=工工tiL三/訂肿fjy .亏匸二h?'可占_ jij_6l-<h：XInfnua-ictjnJ十彈鋼岸HnwdVHIt： Wlir-7r jirhTrs3! rai1'G 1 J fahiurviVAW30E韦erviG电5Fwnlrd 牡nt.qHi在.B«-. ak'：.'.序7宦上?儿°SPAPnrariiEiRir-H i r L?rIrteapr泌 Airhtezti蛇勿鬥2/ 卞i DmFWl y 仝ZfeelcpfttEnEsSOAJ.帕 N *0me- ai Bi i:有了所需的观察范围之后，我们就可以运用这种视角即经济或者生态生命周期的视角， 确保生命周期并不仅限于我们必然带来的单个生物实体模型。与文化一样，企业的寿命要超 过单个成员的寿命，而这种生命周期要求我们把眼光不能单单着眼于自己的生命。在我们生 活的许多方面，譬如高等教育机构、家庭或者亲属关系网和政府等，我们对这种视角习以为 常。不过在EA方面，我们现在需要明确这样的机制并加以实施：能够不断的进行审视、执 行质量保证作为理所当然的事情，并且实际上把构建、使用、学习、评估、构建（调整/重 新构建）、使用、学习这一周而复始的周期实行制度化。那种机制。当然，这事先假定: 这个过程的“事实上”的起始点就是，企业或者组织恰好处在这样一个时间点：它决定开始构 建及部署EA这个过程。起始阶段不需要某种全面的评审。实际上，获得正确的视角应当可 以让企业重新专注于当前问题，同时仍不忘更重要的问题。噱头和希望的区别在表明业务版本的扩展型企业架构框架（E2AF）的下面这张图当中，SPA、SOE、SOA、 SOC和STP等概念位于框架上，可以帮助读者了解与E2AF有关的这些概念的相对位置。 E2AF上有四个关键成功因素（CSF），它们对于在贵组织实施面向服务取得成功起到了关 键作用。到底是噱头还是希望，完全取决于这四个CSF。服务范例采用（SPA）面向服务提供了一种理想的世界：里面的资源划分整齐，以服务这种形式加以一致地呈 现。因此，企业想从服务方面设计企业架构，就一定要采用服务范例。所以，企业在业务、 信息、信息系统和技术基础设施的各个层面都要从功能服务方面加以分解。采用一致、合理 的做法可以提供松散耦合的功能服务，它们可以在所谓的共享服务中心里面进行外包、内包 或者组合。.lectrMxigFfh*tfrri£JTiAc.rijcJItmg鮎q典打HEMg HrtU?rfe-iBMl liM* JfBil i.1-f .r-> b7r- 身prate Arc hftezture!翅理出 J为呦 B 迤匚二严E 旨严亠十严 p讯仙卜*L> mgg ；.v-ta-5=BSPAPfiracliRHibuauji.I： LTE5费孑轉趣爭卡 匚 日肖忌-E-L留 口 ?总巴古-3./ 声弘!r与不想米用服务范例的组织相比，米用服务范例、并且以合理方式进行实施的企业可以 获得更大的灵活性、适应性及敏捷性。面向服务的企业（SOE）面向服务的企业其实以一种极其水平的方式连接业务流程。它采用的企业基础设施可以 提供企业架构和安全基础，能够跨企业以一致的方式运行这些服务。"咋哄“”怙-：'t-wpris-e Archerturejm/J.JJ1Jld£l：/ 匸j £三理.2；耳山：UevelcpmE 仃亡；pii.Mr5* T和H 与冲 « r飙*I. fli «rli d*i:irT .ill:n阳£如鼻iVIhh WhWf «V¥W» 廿虫iT-tl SfflfljJJ li 血皈1立1*1化30EServicesCFMFHlriJlnrerpnqel-kwi?EEJ II WC-1 nrE-MHagn tii茁1】寸2沁' 皿；I 仙 jili Li A-vnwiir3Mirn-S.hzWpJJLJ虽然在过去的三十年里，面向服务的架构这一概念被系统架构师奉为最佳实践，但现在 它得到了各个地方许多组织的接受，被认为是获得业务敏捷性的关键。但SOE和SOA既 不是即开即用的成套系统，也不是什么单一技术，更不会让所有问题都能迎刃而解。尽管 SOE能够带来甚至促进组织上的变化，但它也要求主管人员、企业架构师及项目经理要有 不同的思考和行事方式，否则完全会发现自己遇到新问题，根本得不到多少好处。服务是什么？服务就是指实现的定义明确的业务功能，它可以独立于系统里面定义的其他任何服务的 状态而工作。服务有一系列定义明确的接口，可以通过服务用户和服务本身之间事先定义的 契约（contract）进行工作。服务有着不同性质。一项业务服务可能意味着'getAccou ntBala nee”； 一项业务交易服 务可能意味着''makeCreditCardPayment”； 一项系统服务可能会提供“deleteAFile”之类的一 些操作。自上而下与自下而上的服务定义理想情况下，在面向服务的企业（SOE）里面，服务在企业层采用自上而下的方法进 行定义及描述。通过对定义明确的业务功能进行功能分解，我们就能确认业务功能'F inan cial Services （金融服务）”。这项业务功能又可以分解成较低层的服务，譬如Invoicing、Payements 和 Ban ki ng 等。EA & Services OrienticmStrategicLev日LmlBervites DriniUun I cp-Lio(wn Appr«?vhCpsnaLiuitelLeeiTHSff 帀 dEnLerpriat- AnhiainFtntFmfltinrii Prow is innSeivtctsHfrUrififin!3<mori-p Approach J在面向服务的架构里面，系统作为服务集合体来运行。每个服务可能会与其他不同服务 进行联系，共同完成某项任务。某个服务的使用可能要结合几个低层功能。这种情况下，这 些低层功能不被认为是服务。自上而下：SPA / SOE / SOA1、按照需要的业务转型：对现有的业务模型进行全面的业务转型，或者部署新的业务模型 (SOE)。2、整个企业内的IT转型：企业设计实施方案，实现跨整个企业的业务功能进行集成(SOA/SOE)。自下而上：SOC / SOA1、对业务功能实行面向服务的集成：跨企业内外的多个应用集成服务，以实现业务目标(SOI/SOA)。2、实施单项Web服务：利用新的或者现有的应用里面包括的任务创建服务(SOC/SOA)。 在对适合组件化(模块化)及服务提供的现有遗留资产进行自下而上的分析的同时，也进行 自下而上的域分解(domain decomposition),即流程建模及分解、面向差异的分析、策略 和业务规则分析，以及域特定的行为建模(使用语法和图表)。为了了解项目背后的业务目 标、让服务和这种业务目标相一致，就要进行目标一服务建模。一项功能变成一项服务，但这样做的话，会让组织的IT系统杂乱无章、难以维护。识别服 务的优点在于，可以把服务当作一系列合理组织的功能。服务必须代表有形的业务概念。譬 如，getAccountBalance就是有形的业务流程，但convertStringToNumber不是可以识别的 业务概念，因而不适合作为一项服务。识别潜在服务的过程绝非易事。在现阶段，我看到许多组织迷恋于现有的技术，却忘了这一 点：技术不该驱动业务。虽然识别服务是在整个组织进行一系列分析的过程，但还是可以运 用某些分析模式，找出潜在服务。以下是决定识别服务时应当考虑的一些方面：分析组织业务流程的某一个部分，然后把它们分解成几个比较小的业务流程。譬如说， 一家组织的订单处理系统可以分解成几个比较小的业务流程，譬如checkinventory、 processPayment 和 updatelnventory 等。确认是否有没有比较小的业务流程可重复使用，或者是否有可能重复使用于组织的其 他业务流程。譬如说，checkInventory也可以供组织里面的库存管理应用使用。可重复使用的业务流程非常适合作为服务使用。为这些业务流程拟订所需的输入，然后定义它们必须得到什么样的特定输出。一定要 注意确保这些输入及输出的通用性，以便服务依然可以重复使用、能够提供给不断变化 的业务模型。譬如说，目前的processPayment服务也许只能接受支票付款，但应当足 够灵活，以便以后支持信用卡支付，从而支持不断变化的业务需求。因而，必须以通用 的方式定义processPayment服务的输入。确认这些业务流程是否已经作为组织里面的IT系统加以实施。如果是这样，那么为 所有现有的应用分析业务关键因素，确认哪些应用需要转换成SOA。譬如说，如果某服 装零售商再也不接受退货/换货，我们就用不着考虑分析Refund/Exchange应用。确认哪些服务可以协同工作、不同服务之间有着怎样的依赖关系。弄清楚服务只能在内部使用还是也可以提供给外部使用者。这将对服务的定义带来影 响。确认服务是以同步方式使用还是以异步方式使用。服务所能允许的响应时间是多长？ 这些准则来自我们为业界的好几家组织成功提供基于SOA的解决方案时得到的实际经 验。这份列表绝不完整，但我认为，不可能有完整的一套方法可以确认有待实施的正确 的一系列服务。这始终是个不断变化的过程，因为一直会有新的需求产生。不过本文的 主旨是，你要特别注意识别可以部署在组织里面的那一系列服务。面向服务的建模现在有许多重要的活动和决策不仅仅影响集成架构，还会影响企业和应用架构。它们包 括来自使用者和提供者这两个关键视图的活动。Rai*(ivities In this rmeCansumar 忻日wService id&nlflicaEioriService calBgorizaliDHService expusure dacES-lo-nsChoreography r co Epos 也 anDu日Bty oiMrvkiGProvIdEfComponent cdonlillcatiDnComponentService raallzaHi' ISe-rvice ini jiiieuiIL . - r |StandardE implE-mBntBUonService IldCHtli口db to CDnipanenteLayering the SOApr-oCDfyp-ingsolocti 口 nrad曲也临ho啊 dependencies!)活动通常由提供者和使用者这每个角色来开展。请注意：提供者的活动包括使用者的活 动(譬如，提供者也会关注服务的识别和分类等操作)。在许多情况下，角色差异来自这一 事实：使用者明确规定了他们需要的服务，往往会寻找它，一旦他们相信自己所寻找的服务 和服务提供商提供的服务相互匹配，他们就会按需要绑定及调用服务。反过来，提供者需要 发布他们愿意支持的服务：不但要确保功能，还要确保更重要的使用者所要求的服务质量 (QoS)。使用者和提供者之间这种不明显的契约就有可能变成服务级别协议(SLA)方面的 明显的契约。通过电子方式或者通过业务和法律途径进行协商。上述活动被描述成在面向服务的建模里面流动的活动。dentificaOQnDHnaind=GOrpo&itiariEwstlng bysiernanalysisSpecificBHronSenrice ailoGauqn toOompGnenlsspecificalicincompan&nt 1law speciritaiianGoal-service modelingservice flow specificalianmessage & event 沖 jejficaljonService nealiialiE.ns一"SubsvslemSefticas pedBcationRealizationMfnfKuienc layer面向服务的建模和架构这一过程包括三个基本步骤：识别、说明及实现服务、组件及流 动（通常称为服务编排）。服务识别这过程结合了域分解、现有资产分析及目标一服务建模的自上而下、自下而上和中间向 外等方法。在自上而下视图中，业务使用实例的蓝图提供了业务服务的规范。这个自上而下 的过程往往被称为域分解，它包括把业务域分解成功能区域和子系统，包括流动或者流程分 解成流程、子流程和高级业务使用实例。这些使用实例往往非常适合作为在企业边缘提供的 业务服务，或者非常适合作为在企业里面跨业务部门使用的业务服务。在这过程的自下而上部分或者现有系统分析当中，现有系统经分析后，被选择作为适合 提供低成本的解决方案，以实施支持业务流程的底层服务功能。在这个过程中，你可以分析 及利用来自遗留和套装应用程序的应用编程接口（API）、事务和模块。在某些情况下，需要 对遗留系统进行组件化处理，以便重新对支持服务功能的现有资产进行模块化处理。中间向外视图包括目标一服务建模，以验证及发现没有被自上而下或者自下而上的服务 识别方法所发现的其他服务。它把服务同目标与子目标、关键业绩指标及衡量尺度联系在一 起。服务分类服务识别后就开始这项活动。开始把服务分类成分层服务很重要，这体现了服务的组合 或者不规则性:服务可以也应当由粒度更细的组件和服务组成。分类有助于确定组合和分层， 还可以根据服务层次来协调构建相互依赖的服务。另外，这还有助于缓解服务激增的现象： 越来越多的细粒度服务被定义、设计及部署，却几乎没有多少管理，导致性能、扩展性及管 理方面出现严重问题。更重要的是，服务激增无法提供对业务有用、并且便于实现规模经济 的服务。子系统分析这项活动获得在上述域分解期间发现的子系统，然后明确规定这些子系统之间的相互依 赖关系和流动。它还把域分解期间识别的使用实例作为通过子系统接口提供的服务。对子系 统的分析包括创建对象模型，以呈现将提供服务、实现服务的包含子系统的内部工作原理和 设计。然后实现“子系统”的设计构件，作为实现以下活动的服务的粗粒度组件的实施构件。组件分类在下一个重要活动中，明确规定了实施服务的组件的细节：数据规则服务可配置的简档差异消息传送及事件规范和管理定义出现这一步骤中。服务分配服务分配包括把服务分配给目前识别的子系统。这些子系统拥有的企业组件能够实现已 发布的功能。你经常会进行简单化假定：子系统与企业组件拥有一对一的关系。用以下组合 方式利用模式构建企业组件时，就会出现组件构建：中介者外观规则对象可配置的简档工厂服务分配还包括为SOA里面的几个层分配服务及实现服务的组件。分配组件和服务给 SOA里面的层是一项重要任务，需要记录及分析重要的架构决策，这些决策不仅与应用架构 有关，而且与设计用来在运行时支持SOA实现的技术操作架构。服务实现这一步认识到，必须选择或者定制实现某项服务的软件。现在可以获得的其他方案包括： 利用Web服务集成、转换、订购及外购部分功能。在这一步当中，你需要决定将利用哪个遗 留系统模块来实现某项服务、通过自下而上的方法构建哪些服务。实现服务而不是业务功能 的其他决策包括：服务的安全、管理及监控。服务迁移方案（STP）你的SOE、SOA和SOC完全在发展当中，你向面向服务迁移的过程将经历很长一段时间， 并且分成多个阶段。因而，迁移管理是在通向面向服务的漫长道路当中最关键的问题之一。附2廨如 3屮浓fll DZtevelapmEndi iiire .口亡一丄!汕左"灯匸宀号:-nli'rfTHriizt'mli frirr .ill :n尽管迁移至面向服务的平台意义重大、关键的Web服务标准继续面临不确定性，加上大规模 部署S0A往往会产生重大影响，现在是开始考虑迁移的时候了。成功迁移的关键在于，在有 关SOA的 暴风骤雨般的活动当中找到一个平静点，然后制订直观的方案，指导贵组织走过 面临技术障碍、组织阻力及不断变化的行业趋势的道路。制订迁移方案前先进行影响分析为了评估向面向服务迁移的可行性，你先要估计这样一种迁移会产生什么样的实际影 响。因而，你在最初的影响分析完成之前，暂时不要考虑各种规划。利用影响分析结果作为 你的主要指导原则，并且把预算限制因素、相关的项目需求及其他外部驱动因素（如战略性 业务目标）考虑进来，你应当能够确定规划迁移的范围°SOA迁移方案只适用于一小部分的 组织技术环境，这并不罕见。譬如说，企业里面也许有几个遗留方面无法保证不会受到服务 封装的影响。也许你的目标就是构建专用的主机托管环境，不仅仅旨在支持新的面向服务的 应用。不过，集成需求往往会推动SOA迁移。这种情况下，你项目的范围很容易看到：SOA 的引入会影响你IT企业的大部分。不过，面向服务的原理本身并不复杂，但运用这些原则会导致相对复杂的自动化解决方 案。如果共享及组合来自不同解决方案的服务，以支持新的或者经过改动的业务流程，更是 如此。如果你想处在面向服务的环境下，你的项目队伍就要改变对通用架构的根本层面进行 考虑的方式，譬如组件化、集成和流程自动化。面向服务的成熟度不同公司在采用及融合面向服务模式（SO）方面的成熟度各不相同。有些只是刚开始使 用SO的技术实例：Web服务，探究SO世界。它们对遗留功能进行包装，然后加以提供，供 第三方、客户和业务合作伙伴使用。这样一来，它们随之进入了状态：扩大开发队伍规模、 开始改变企业文化，以便更好地支持SO,并且向探究新技术和可能受影响的业务功能迈出 了头几步。这是第一个阶段。SOA采用的第二个阶段是，Web服务的初始测试成功地得到了解决；如今组织开始使用 服务集成系统和应用。随着专有协议、粘合代码和点对点连接让位于更加开放、基于标准的 协议以及基于每个系统外部化的服务描述的相互关系，我们进入了面向服务的集成（SOA） 领域。在这个世界，企业服务总线取得了主导权:SOA是中介、路由及转换服务调用的一种 机制，不管目标服务提供商是谁。它有助于解决与点对点连接有关的许多不足。为IT用户和业务用户就SOA在组织里面的适用性和优点进行探讨提供了框架，采用成熟度 分为五个级别。Measured Business SanfleftsBENEFITSOptimizationaZ0usineisServicesCDllatxrgiivyServicssAcliitecled ervic&sFnitidl ServfcesRe$pcn$ivene$Cost EffectivenessFunctionalityTransformation服务编排随着面向服务的架构（SOA）和Web服务越来越流行，这些不同的资产可以作为单个企 业服务来提供。那么我们如何构建及把它们作为服务来提供呢？我们如何在构建基于服务的 新应用或者业务流程时利用它们呢？这就是业务流程编排所要解决的问题。Web服务编排接口（WSCI）是基于XML的一种接口描述语言，它描述了由参与跟其他编 排服务进行联系的Web服务交换的消息的流动情况。WSCI描述了通过重复使用为静态接口 定义的操作来参与某个消息交换的动态接口。它描述了 Web服务的可观察行为。这通过所交 换消息之间的临时和逻辑的依赖关系来表示，采用了排序规则、相互关联、异常处理及事务 处理。WSCI还描述了相互联系的Web服务之间的集体消息交换，从而为这种相互关系提供 了面向消息的全局视图。服务粒度服务是SOA和SOE的核心部分，这种说法恐怕不会引起人们的异议。但识别服务的方法 在慢慢出现。谈论SOA时，服务往往被视为只要少须努力的任务一一努力少得我们几乎都懒 得谈论。描述这项任务的细节通常专注于是采用从自上而下的方法还是采用自下而上的方 法。实际上，你可能会结合使用两者，但应当偏重于自上而下的方法一一为了控制服务之间 的一致性，这方法必不可少。mt1Why?Ei申卩右 Mwfrv :H«»FCOHtelkAil LfrRrtf冊 AnrhihKhjrt- Fr-am twjrfr'F .'匕扛必曲知jy"3弓MF比曲'2j:口虫 Tlufonnationwith wn&?Vaim* irt Rwwl u iF»FE 1->a i Zs 1 3E*i E*ti r AxWhat?Aeo-Ic±vArq>irm>fl beSPASQE'-a”"IJl«ronndUon-T«hfio4ogy ； infrastructureServicesPnradismAtioplionj.ServicesOrientedEnterpriseInstit-ute-ForEnterprise Ar-chitecttireDevelopmentsT.粽W 4 f 2 2 - g机时:F« ! EWt：f-r4 A-肚£卜 i-i :曲念;嵌佥.起幣How?wim what?When?is gne-31L站丽LPr*>SOAsocIsmServie Oriented ComputingServiceOricntc-d Srfiiteciir.y/ujj uJij/Jry dj .5 勺了 刃竺 mmCRTtHTI-a I ItSTFServicesTrwtBifio*!但我们实际上如何识别自己的服务呢？这无疑是通常在EA的抽象层上成进行的一项工 作。在SOE里面，我们需要一种方法来识别服务，这种识别方法还要支持SOE的范例、并且 利用EA方面的经验。这里的一个重要概念就是：我们不是从头开始做起！ 如果你在处理SOE、SOA和EA方面有了经验，对你来说预计不会出现任何革命一一这实际上 是一种非常简单的方法。但这只是我们所看到的这种方法具有的强项。一个简单的信息就是:你在识别服务时，不要一开始开发解决方案！随时关注进度，每次识别一个抽象层上的服务。 图一：企业架构服务模型企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案图二：企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案图三：企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案图四：规划一层次EA和面向服务SOE战略级别服务定义面向服务企业战术级别自上而下SOA操作级别方法面向服务服务定义SOC自下而上面向服务的计算方法信息提供图五：角色相应角色的活动使用者视图服务识别服务分类服务提供决策编排或组合服务质量提供者视图组件识别组件识别服务实现服务管理标准实施服务分配给组对SOA分层技术原型产品选择架构决策（状态、件流动及相互关系）图六:识别说明域分解组件流动说明信息说明目标一服务建模 子系统分析服务说明组件说明现有系统分析 服务流动说明 消息和事件说明服务实现决策实现服务分配给组件组件层图七:企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案图八：企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案图九：经优化的优点 优化业务服务经评估的业务服务转型业务服务协作服务响应力经过设计的服务成本效益初始服务功能图十：企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案图十建模层：流程/协作定义WSCI动态、编排过的Web服务接口WSCI动态、编排过的Web服务接口WSCI动态、编排过的Web服务接口WSDL 静态的Web 服务接口WSDL 静态的Web 服务接口WSDL 静态的Web 服务接口WSDL 静态的Web服务接口图十二:企业成熟度服务编排服务质量服务粒度业务SPASOESOASOCSTP信息服务面向面向面向服务信息系统范例服务的服务的服务的迁移技术基础设施采用企业架构计算万案