SOA 术语概述: 第 1 部分,服务、体系结构、治理和业务术语

级别: 初级

Bertrand Portier (bportier@ca.ibm.com), IT 架构师, IBM

2007 年 3 月 15 日

通 过本系列的第 1 部分了解一些基本的 SOA 术语。Bertrand Portier 将定义包括服务、体系结构、面向服务的体系结构、治理和业务流程在内的多个术语,并说明为何它们是 SOA 成功的基础。他还介绍了 IBM SOA Foundation 中的主要情况。

引言

在任何领域中,语义都非常重要,而在面向服务的体系结构(Service-oriented architecture,SOA)中更是如此。由于 SOA 涉及多个团队和组织,因此就相关术语达成一致至关重要。本系列将带着您开始 SOA 之旅,为您定义基础术语和主要概念。您将了解 SOA 领域中所使用的各个词汇。对于每个术语,将说明其为何对 SOA 重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。

关于组织方式的说明

以 下列出的术语并不是按照字母顺序排列的,也不是按照其重要性进行排列。我们将按照构建块的方式对其进行排列。首先讨论的是“服务”,因为这个术语可能是理 解 SOA 框架的最基本概念。我们将以服务为基础形成“体系结构”、“治理”和“业务”概念的定义。在很多情况下,我们都将较大的术语分解为较小的组成部分进行讨 论。

服务

服务显然是面向服务的体系结构的核心,术语服务 的使用非常广泛。不过,这个术语对于不同的人有不同的含义,“什么是服务?”这个问题经常会引发激烈的争论。我听到过人们讨论业务任务、业务服务、应用程 序功能、技术服务或基础设施服务。我将基于 IBM Rational® Method Composer Plug-in for SOA Governance 和 IBM Rational® Unified Process for Service-Oriented Architecture 给出一个定义。(有关更多信息,请参见参考资料部分。)

“服务是执行可重复任务的可发现资源,由外部化的服务规范进行描述。”

由于存在多种不同的定义,通过定义“服务”来开始本文的讨论比较困难。例如,您可能会认为上述定义过于偏重于技术。请记住,一定不要过于依赖于服务的正式定义,而要将重点放在服务背后的主要概念上,包括:

  • 业务一致性:服务并不基于 IT 功能,而是基于业务的需求。服务业务一致性由服务分析和设计技术提供支持。
  • 规范:服务是自包含的,采用接口、操作、语义、动态行为、策略和服务质量进行描述。
  • 可重用性:服务可重用性由服务粒度设计决策予以支持。
  • 协议:服务协议是实体(即服务提供者和使用者)之间就相关事项达成的一致意见。这些协议基于服务规范,而不是实现。
  • 承载和可发现性:随着生命周期的进展,将承载服务,并可以对其进行发现;这由服务元数据、注册中心和存储库提供支持。
  • 聚合:松散耦合的服务聚合为企业内部或企业间的业务流程或组合应用程序。

这些组合特征表明 SOA 并不仅与“技术”相关,而且也与业务要求和需求相关。

还 要务必注意,并非所有东西都是服务。例如,有些 IT 功能不应该作为服务公开。可以使用 IBM 的面向服务的建模和体系结构(Service-Oriented Modeling and Architecture,SOMA)等分析技术基于上面列出的概念标识恰当的服务列表。我们将在本文中详细讨论这些方面的内容(包括本部分中所有以粗体 显示的术语)。

体系结构

和 服务类似,很难得到一个大家一致认可的体系结构的定义。不过,与服务不同的是,人们在谈论 SOA 时有时候会忘记体系结构,而显然不应将其忘记!事实上,企业体系结构和面向服务的体系结构具有相同的目标,即通过集成的 IT 策略支持业务。例如,企业架构师是 SOA 成功的关键,因为他们将根据不断发展的业务需求和要求确定企业的 IT 系统的策略发展方向。

Open Group Architecture Forum (TOGAF) 根据上下文提供了两个体系结构定义:

  1. “系统的正式描述,或用于指导其实现的组件级别的系统详细计划。
  2. 组件的结构、它们相互间的关系以及控制其设计及将来发展的原则和指导方针。”

这两个定义都与理解 SOA 中的“A”相关。对其进行进一步细分,我们会发现体系结构对于进行以下工作必不可少:

  • 在不同的抽象级别进行设计和建模
  • 将规范与实现分离
  • 构建灵活的系统
  • 确保满足业务需求
  • 分析需求更改的影响
  • 确保遵循相关原则

企业体系结构

以下是维基百科 (Wikipedia) 中的定义:

“企业体系结构是这样一种做法,即应用描述组织的流程、信息系统、个人和组织子单元的全面而严格的方法,从而使其与组织的核心目标和策略方向保持一致。

创建企业体系结构的主要目的是为了确保业务策略与 IT 投资保持一致。通过这样,企业体系结构可支持从业务策略一直到基础技术的可跟踪性。”

可以将项目级别的“体系结构”和组织级别的“企业体系结构”与此进行比对。请注意对流程、信息系统、人员、目标、策略和业务 IT 一致性的参考信息。

面向服务的体系结构

面向服务

正如 IBM SOA Foundation 白皮书中所述“...面向服务是将业务作为一组有联系的服务集成的方法。”有关 IBM SOA Foundation 的更多信息,请参见参考资料

此处的关键词是“业务”。例如,面向服务可提供非常有用的灵活性,能使用来自一个业务部门(Line Of Business,LOB)、多个业务部门以及业务合作伙伴的服务灵活地实现业务流程。

SOA Foundation 参考模型

IBM SOA Foundation 中提供了一个 SOA 参考模型,如图 1 中所示,此模型说明了为了支持面向服务的体系结构所需的主要功能。

由于这个模型基于面向服务的概念,因此它允许从小项目做起,逐渐扩展在企业内的集成,从而在出现新业务需求时以增量的方式采用 SOA。有关 SOA Foundation 的更多信息,请参见参考资料


图 1. SOA Foundation 参考模型
IBM SOA Foundation 参考模型

面向服务的体系结构

IBM SOA Foundation 对 SOA 的定义如下:

“面向服务的体系结构 (SOA) 是一种用于创建企业 IT 体系结构的体系结构样式,利用了面向服务的原则来实现业务和支持业务的信息系统之间更为紧密的关系。”

SOA 具有以下特征:

  • 它加强了企业体系结构和业务之间的联系。
  • 它允许将组合应用程序作为一组集成服务进行构建。
  • 它提供了灵活的业务流程。

面向服务的体系结构是全新(与“革新”相对)的事物,意味着新的企业人员角色、新的协作方式、新的支持框架以及新的软件构件。

SOA 解决方案堆栈

如图 2 中所示,SOA 解决方案堆栈是一个 SOA 参考模型,描述 SOA 解决方案的运行时概念视图。

有时也将其称为“SOA 分层体系结构”,其中介绍了各个层次和概念(如业务流程、服务或服务组件)及其相互间的关系。

它不依赖于实现所使用的技术。这个分离非常重要,具体请参见本系列的第 2 部分中的模型驱动的体系结构(Model-Driven Architecture,MDA)的相关内容。


图 2. SOA 解决方案堆栈
SOA 解决方案堆栈

5 个层次分别如下(按照从下到上的顺序):

  • 可操作系统:表示现有 IT 资产,说明 IT 投资非常宝贵,应该在 SOA 加以利用。
  • 服务组件:实现服务,可能通过使用“可操作系统”层中的一个或多个应用程序来进行。如模型中所示,使用者和业务流程并不能直接访问组件,而仅能访问服务。现有组件可以在内部重用,或在合适的情况下在 SOA 中使用。
  • 服务:表示已部署到环境中的服务。这些服务由可发现实体进行治理。
  • 业务流程:表示将业务流程作为服务编排实现的操作构件。
  • 使用者:表示用于访问业务流程、服务和应用程序的通道。

治理

因为 SOA 具有跨组织的特征,其中的服务投资者、设计人员、实现人员、维护人员或客户并不位于相同的组织、业务部门、IT 部门、LOB、分支机构或企业中,因此治理对于以增量的方式成功采用 SOA 非常必要。

此 部分包含 IBM Rational Method Composer Plug-in for SOA Governance 中的相关定义。它定义了治理、IT 治理、SOA 治理及其与管理或遵从性之间的差别。它还描述了 SOA 治理所处理的各项挑战。有关 Rational Methode Composer 的更多信息,请参见参考资料部分。

治理

"治理是关于以下方面的概念:

  • 建立责任、授权和通信链,以对人员进行权利分配(决策权)。
  • 建立度量、策略和控制机制,以支持各个人员执行各自的角色任务和履行相关职责。

治理处理的是分配决策权力,并决定使用何种措施以及遵循哪些策略来进行这些决策。决策权分配给角色,而不是个人。另一方面,管理 则包括为角色分配人员以及监视策略的执行情况。

任何治理解决方案中都包含要符合组织的遵从性要求的目的。遵从性 是记录并证明治理已就位并得到了执行:会记录决策,并遵循有关决策的策略。”

IT 治理

“IT 治理指属于组织的信息技术流程以及这些流程支持业务目标的方式的治理方面的内容。”

IT 治理可以通过分配 IT 流程的决策权和措施进行描述。

SOA 治理

“SOA 治理是 IT 治理的扩展,具体关注服务和其他 SOA 构件的生命周期。”

具体来说,SOA 治理关注的是有关服务标识、资金投入、设计、实现、部署、重用、发现、访问、监视、管理和退役的方法和流程。

“SOA 治理处理以下这些类型的挑战:

  • 哪些新组织角色和结构可促进服务标识、设计和共享?
  • 哪些标准支持服务的投资、维护、使用和共享?
  • 业务部门如何决定在服务创建和维护方面进行投资?
  • 企业的面向服务的成熟度如何?
  • 需要进行哪些训练、培训或指导?"

生命周期

服务生命周期

服务生命周期由服务可能处于的状态以及触发状态间转换的事件组成。

在其生命过程中,服务将度过很多阶段(和我们一样 :))。将服务的生命周期视为具有状态(位置)和转换的业务状态机;服务可能处于其中的某个状态,而转换使其从一个状态发展到另一个状态。

SOA 治理考虑的是有关服务生命周期的计划、定义、启用和测定。SOA 治理定义服务状态的含义、从一个状态发展到另一个状态需要发生的操作(转换)、如何进行(流程和方法)以及由谁进行(角色)。

例如,SOA 治理可以将服务状态定义为标识、投入资金、指定、实现、审批、操作、发布、弃用和退役。

基 础 SOA 框架则将需要通过生命周期支持服务,并确保遵循了配备的流程。例如,服务注册中心和存储库需要允许用户进行相应的操作,以便服务在生命周期中逐渐发展。协 作和投资组合管理工具需要能够允许用户(仅限于具有权限的用户)作出将使得服务从一个状态过渡到另一状态的决策,并在需要进行操作时通知用户。

SOA 生命周期

IBM SOA Foundation 在其 SOA 生命周期的定义中使用了四个阶段:

  • 建模包括业务分析与设计(要求、流程、目标和主要性能指标)及 IT 分析与设计(服务标识和规范)。
  • 组装包括服务实现和组合应用程序的构建。
  • 部署包括应用程序和运行时(如企业服务总线——Enterprise Service Buses,ESB)的部署。
  • 管理包括操作环境维护、服务性能监视和服务策略执行。

正如上面定义的,SOA 治理和流程为这四个阶段提供支持。此情况如图 3 中所示。


图 3. SOA 生命周期
SOA 生命周期

业务

现 在的企业需要能够识别更改,并快速对其作出反应,而且还要同时维护其由雇员、合作伙伴、客户组成的生态系统。正如 IBM On Demand Business 所述,需要全面利用先进技术,以实现此目标。有关 IBM On Demand Business 的信息,请参见参考资料部分。

由于客户和法律法规遵从之类的外部要求和竞争与市场之类的变化,业务必须具有灵活性和敏捷性。面向服务的体系结构可帮助实现此目标,允许业务根据变化快速调整。

业务一致性

SOA 成功的关键在于,对遗留应用程序等现有 IT 资产的重用。不过,SOA 允许企业将其技术工作的重点放在将支持其业务功能或流程的服务上——例如,能够与业务任务对应的服务操作——而不是基于竖井 (silo) 式信息体系的服务。业务一致性涵盖范围更全面,且能促进业务和 IT 之间更好地进行沟通。在本系列后面的部分中,我们将讨论 SOA 分析和设计的自顶向下、自底向上及中间相遇方法,从而了解如何将业务模型细化为 IT 模型,以及可以如何利用主要的现有功能。

不过,与业务保持一致并不意味着让业务功能和 IT 实现紧密耦合。关键的 SOA 概念之一就是松散耦合以及规范(业务模型、接口)和实现(技术)之间的分离,通过这样可将更改(如替换服务提供者)的影响降到最低。

业务组件化

IBM Component Business Model® 是一种策略方法,允许企业将重点放在核心竞争力上(使得企业从竞争者中脱颖而出的部分),了解如何使用资源,从而更好地保持业务和 IT 之间的一致性。有关 Component Business Model 的更多信息,请参见参考资料部分。非常需要这些业务组件交互的集成以及灵活性(如外包组件),而这通过面向服务得到了实现:业务组件具有独特的业务用途,通过其提供或使用(来自其他组件)的服务进行协作。这可以被视为“业务体系结构”的一部分。

业务建模

IBM Rational Unified Process® 对业务建模的定义如下:

“Rational Unified Process Business Modeling 规程提供了具体的指导信息,说明如何使用各种不同的方法和技术在不同的正式级别描述“原始”或“将来”业务。”

业务建模引入了一系列概念、交付内容和角色;它将描述和组织有关业务策略、业务远景、业务目标、业务目的、业务词汇、业务体系结构、业务分析与设计、业务规则、业务价值、业务用例、业务实体以及业务流程的任务。下面的部分对此进行了更为详细的说明。

SOA 是有关重新组织业务和 IT 系统的长期策略,其目的是为了快速对变化作出响应。参考资料部分提供了 IBM Systems Journal 第 44 卷第 4 期有关 SOA 的链接,其中更为详细地说明了面向服务的思维方式中业务所处的位置。

业务流程

业务流程由一系列能产生有价值的结果的活动组成。

业务流程具有贯穿其中的相关业务项目(数据),包括作为流程的输入和输出使用的项目。

业务和任务

业务活动和任务是通过连接能组成业务流程的元素。

您可以将持续时间、成本、收益、资源、输入和输出与业务活动相关联。这些是用于对业务流程进行分解的元素。服务标识技术包括将业务流程分解为活动和任务的技术,将通过这些活动和技术对现有的或将要开发的服务(及其操作)进行标识。这些服务有时称为“业务服务”。

建模业务流程

组织的业务流程(当前的、“原始”流程)可能很复杂,因为这些流程经常是对最初开发的流程进行了大量的更改之后得到的。理解、正式定义并记录业务流程的工作非常重要。另外,通过建模和模拟“原始”和“将来”业务流程,将能够确定成本、延迟或能实现自动化的方面。

建模业务流程不仅提供了可视表示形式,而且,当在框架中进行此工作时,还能提供基础元数据(我们将在本系列的第 2 部分进行讨论),从而支持稍后将业务流程模型的元素细化为(或链接到)IT 设计元素。

人工任务

很 多时候在流程中都会需要人工交互(如出差审批或贷款审批)。在业务流程建模期间,会将人工任务标识为手工任务,并为每个人工任务分配不同的角色。部署后, SOA 环境将需要把人工任务作为流程执行的一部分进行支持。例如,IBM WebSphere Process Server 之类的产品将为用户提供等待其处理的人工任务的列表。通过与此类产品组合,IBM WebSphere Portal 和 Lotus Sametime 之类的产品还将允许用户在需要的情况下与同事进行协作,并就他们的决定向系统发出通知,以便继续执行流程。人工方面对于 SOA 的成功非常重要。

BPEL

IBM、Microsoft 和其他业界企业已经将业务流程执行语言(Business Process Execution Language,BPEL)作为 Web 服务规范提交,以用于正式地指定业务流程和交互协议。

1.1 版于 2003 年发布,目前已经发布了 2.0 版本 OASIS 提交草案,称为 Web 服务业务流程执行语言(Web Services Business Process Execution Language,WSBPEL)。请参见参考资料部分中提供的相关链接。

行业

业 务流程可以特定于某个领域或行业,如保险索赔流程。行业联盟定义行业业务流程。例如,电信管理论坛 (TeleManagement Forum) 为电信行业定义增强的电信运营图(Telecom Operations Map,eTOM)。除此之外,企业可以通过在内部采用经过验证的业务流程(如来自 IBM Industry Models 的流程)来使自己获得优于竞争者的优势。请参见参考资料部分提供的 IBM Insurance Application Architecture (IAA) 的链接,这就是 IBM Industry Models 中提供的流程之一。

业务流程管理

业务流程管理(Business Process Management,BPM)从业务流程整个生命周期的角度看待它,以便提高其效率、灵活性和控制。

BPM 讨论的是进行建模、模拟、优化、部署、运行、管理和监视,然后将结果提交回去,以改进模型,从而进行一个持续的改进循环。IBM WebSphere 提供了 BPM 所需的各种产品。

结束语

在 SOA 术语系列的第 1 部分中,我们定义了核心 SOA 术语,即服务、SOA 以及 SOA 如何与体系结构相关。我们定义了 SOA 的两个核心元素,服务生命周期和 SOA 治理。最后,我们讨论了 SAO 和业务的关系,并对业务流程进行了说明。这仅是开始。本系列的后续部分将定义与 IT 设计、开发、运行时和管理相关的 SOA 术语。欢迎您继续阅读 developerWorks 上本系列的其他文章!

致谢

我要感谢我的 IBM 同事,他们为本文所述面向服务的体系结构和概念作出了大量贡献。我特别要感谢 Richard D. Johnson 和 Steve Kinder 对本文进行了审阅。



参考资料

学习
 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值