如何识别服务?
从技术上来说,你可以把任何一项功能变成一项服务,但这样做的话,会让组织的IT系统杂乱无章、难以维护。识别服务的优点在于,可以把服务当作一系列合理组织的功能。服务必须代
识别潜在服务的过程绝非易事。在现阶段,我看到许多组织迷恋于现有的技术,却忘了这一点:技术不该驱动业务。虽然识别服务是在整个组织进行一系列分析的过程,但还是可以运用某些分析模式,找出潜在服务。以下是决定识别服务时应当考虑的一些方面:
·分析组织业务流程的某一个部分,然后把它们分解成几个比较小的业务流程。譬如说,一家组织的订单处理系统可以分解成几个比较小的业务流程,譬如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 SOE SOA SOC
信息 服务 面向 面向 面向 服务
信息系统 范例 服务的 服务的 服务的 迁移
技术基础设施 采用 企业 架构 计算 方案
图二:
企业成熟度 服务编排 服务质量 服务粒度
业务 SPA SOE SOA SOC STP
信息 服务 面向 面向 面向 服务
信息系统 范例 服务的 服务的 服务的 迁移
技术基础设施 采用 企业 架构 计算 方案
图三:
企业成熟度 服务编排 服务质量 服务粒度
业务 SPA SOE SOA SOC STP
信息 服务 面向 面向 面向 服务
信息系统 范例 服务的 服务的 服务的 迁移
技术基础设施 采用 企业 架构 计算 方案
图四:
规划-层次 EA和面向服务 SOE
战略级别 服务定义 面向服务企业
战术级别 自上而下 SOA
操作级别 方法 面向服务 服务定义
SOC 自下而上
面向服务的计算 方法
信息提供
图五:
图六:
识别 域分解 目标-服务建模 现有系统分析
组件流动说明 子系统分析 服务说明 服务流动说明
说明 信息说明 组件说明 消息和事件说明
服务实现决策
实现 服务分配给组件 组件层
图七:
企业成熟度 服务编排 服务质量 服务粒度
业务 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
信息 服务 面向 面向 面向 服务
信息系统 范例 服务的 服务的 服务的 迁移
技术基础设施 采用 企业 架构 计算 方案
|
|