基于服务的建模和架构

基于服务的建模和架构

如何为你的 SOA 鉴别、指定和实现服务

级别: 初级

Ali Arsanjani, Ph.D., 首席架构师, SOA and Web services Center of Excellence, IBM

2004 年 11 月 01 日

本文讨论了基于服务的建模和架构的重要部分，以及构建面向服务体系结构（SOA）所需的分析和设计的关键活动。作者着重强调了选择鉴别、制定和实现 服务所需的技术，它们的 流程和组合，以及实现和确保 SOA 所需的服务质量的企业级 组件。

引言

目前，关于由 Service-oriented Architectures（SOA）和它的 Web 服务实现所表现的时机有许多传言 -- 有一些是有事实根据的，但是一些却没有什么事实依据。分析家已经预言，博学者已经声称，教授已经讲演，公司已经匆忙的卖他们的产品，作为 SOA 产品 -- 经常失去 SOA 不是一个产品的要点。它是业务和 IT 之间的桥梁，通过一系列使用一些设计原则、模式和技术的依赖于业务的 IT 服务来实现。

ZDNet 最近报道说，“Gartner 预言到了 2008 年，至少 60% 的企业将使用 SOA 作为创建任务苛刻的应用程序和过程的“指导原则”。

开发和实现 SOA 有很大的需求。因此如果 SOA 不仅仅和产品和帮助实现它的标准相关（比如通过 Web 服务），那么为了实现 SOA 你还需要什么附加的元素吗？ 基于服务的建模需要其他的行为和构件，这些在传统的基于对象的分析和设计（OOAD）中是不存在的。“ 基于服务的分析和设计的元素”这篇文章描述了一些最初的原因，解释了为什么你需要 OOAD 之外更多的内容。它同样描述了业务流程管理或企业架构（EA）和 OOAD 为什么不是管理分析和设计的适当手段。同样，在 IBM Redbook 中名为 “ 模式：Service-Oriented Architecture 和 Web Services”的文章中，我举例说明了基于服务的建模方法的主要活动。

然而，你还需要重视一些额外的重要的需要考虑的事项。首先，目前的 OOAD 方法没有定位 SOA 三个重要的元素： 服务， 流，和实现服务的 组件。你同样需要可以明确定位鉴别、制定和实现服务所需的技术和过程，它们的流程和组合，以及实现和确保所需服务质量的企业级组件。

第二，需要进行范例的替换，以便更好的区分 SOA 的两个关键角色之间的截然不同的需求：服务提供者和服务消费者。第三，假设为一个企业或者业务线构建的应用程序，现在必须被提升到一个供应链中使用，并且公开给合作伙伴，这些合作伙伴可能组合、联合和封装应用程序到一个新的应用程序中。这是服务生态系统或者服务价值网的概念。

这是仅从“分布式对象”的一个微小的进步。它是关于通过网络作用创造的价值：例如，当合作伙伴利用了 Amazon.com 与 Google 搜索的联合，并且与 eBay 服务结合在一起，来构建他们自己的混合解决方案。或者当旅行社深入到机票预订系统，并且与汽车租赁公司以及宾馆相互协调，更新他们的记录并且将旅行计划发送到你的电子档案中。无论什么样的应用程序，你如果想成功地创建 SOA，需要的都不仅仅是好的工具和标准。你需要一些规范的步骤来支持你的 SOA 生命周期；用来分析、设计、实现服务、流程和组件的技术。因此，对于任何对企业应用程序开发感兴趣的人来讲，理解基于服务的建模和架构中包含的细节步骤是非常重要的。

在我详细描述这些步骤以前，我们首先应理解你打算要做什么： 什么是 SOA，以及它看起来像是什么？在定义了 SOA 后面的概念和观点以后，我将描述 SOA 的层和你如何去记录每个层中的关键架构决策，这些层帮助你为 SOA 构建蓝图，这些 SOA 正是那些你试图同一系列实现了 SOA 服务、流程和组件集成以及出现的项目、业务线、企业级成果和价值链所需要的。

 

 

Service-Oriented Architecture：概念模型

这个概念基于一种架构样式，该样式在三个主要参与者之间定义了交互模型：服务提供者，公布服务描述并且实现服务，服务消费者，他既可以使用统一资源标记符（URI）来直接使用服务描述，也可以在服务注册中心来查找服务描述并且绑定和调用服务。服务代理提供和维护服务注册中心，然而现在并没有通用公共注册中心。

图 1 是一个显示了这些关系的元模型。

图 1：SOA 架构样式的概念模型

 

架构样式和原理

定义 SOA 的架构样式描述了一系列模式和指导方针来创建 松耦合，依赖业务的服务，由于描述、实现和绑定之间关系的分离，为新业务迹象和机会提供了空前的灵活性。

SOA 是企业级的 IT 架构，用来按需连接资源。在 SOA 中，资源对于价值网、企业、业务线内的参与者时可用的（典型的是在一个企业内或多个企业之间跨越多个应用程序）。它由一系列依赖业务的 IT 服务组成，这些服务共同满足了组织的业务流程和目标。你可以将这些服务设计成合成的应用程序并且通过标准协议来调用它们，如下面的 图 2所示。

服务是一种有具体服务描述的软件资源（可发现）。服务消费者可以搜索、绑定和调用服务描述。服务提供者实现服务描述的功能并且向服务消费者提供所需的服务质量。理论上服务应该统一由公布的方针来管理，并且因此支持动态的 可配置架构样式。

图 2: SOA 的属性

灵活的业务通过灵活的 IT 系统可以实现，主要通过接口、实现和 SOA 提供的绑定（协议）的分离，基于新业务需求，允许在及时给定的点延期 选择 服务提供者，（功能和非功能（例如，性能、安全、可伸缩性等）需求）。

你可以在内部业务单元之间或者在业务伙伴之间的价值链之间以 不规则的实现模式来重用此服务。不规则的实现引用了架构样式的能力来在他的交互模型中通过合成的方式来应用与参与者关联的模式和角色。你可以在架构中的一层上应用它，也可以在贯穿企业架构的多个层上来应用它。在项目之间，它可以通过统一的、概念上可升级的方式在价值链内部的业务单元和业务伙伴之间。

 

上下文

在本文中，我介绍了鉴定、指定和实现的高级别的行为和一些基于服务建模的构件。基于服务的建模是基于服务的分析和设计（SOAD）过程，来建模、分析、设计和生产依赖业务分析、过程和目标的 SOA。

首先我将看一下你想要构建什么，也就是 SOA 和它的层。接下来我将通过讨论创建 SOA 所需主要的活动和技术来描述如何构建 SOA。

作为一个示例，我们假设你正在开发一个项目，并且目标是将一部分具有自服务帐目系统的银行业务线移植到 SOA上。

为了移植到 SOA，你需要一些超出服务建模的附加元素。它们包括：

• 采用和成熟模型。在 SOA 和 Web 服务的采用上你的企业处在那个成熟的相对级别上？采用的每个不同的级别都与它自己的唯一的要求。
• 评估。你有一些领导者吗？你已经涉足 Web 服务了吗？作为结果的架构好到什么程度？你应该继续维持同样的方向吗？这将衡量企业 SOA 吗？你已经考虑了所有应该考虑的事情了吗？
• 策略和规划活动。你如何规划到 SOA 的移植？你需要考虑的步骤、工具、方法、技术、标准和培训是什么？你的路线图和远景是什么？你如何达到目的？计划是什么？
• 管理方法。现有的 API 和能力是否应该变成服务？如果不是，哪个是符合条件的？每个服务都应该以通过某种方式为业务带来价值为目的来创建。你如何样毫无妨碍的来管理这些过程？
• 实行最佳实践。什么是可靠和经过测试的方式来实现安全，确保性能，遵从互操作性标准，设计来作改变？

除了本文中描述的鉴别、制定和实现之外，基于服务的建模方法还包含了支持完整 SOA 生命周期的部署、监视、管理和控制所需的技术。

上面的关于移植到 SOA 和实现以后附加活动的讨论应该得到它们自己的文章，本系列中我将在随后的列中接触到这个。目前，让我们假设你为项目定义了范围，并且决定了集中在什么地方：已经定义了一个焦点，用来将现有的系统或服务转化到一系列新的系统和服务。现在你可以开始基于服务建模来构建你的基于服务的架构。

 

SOA 的一个架构模板

SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。

服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。

图 3：SOA 层

对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 SOA，你可能应该创建文档，由每个层相应的部分所组成。

这里是为你的 SOA 架构文档设计的模板：

1.    范围 <此架构适用于企业的哪个领域>

2.    操作系统层

1.    打包的应用程序

2.    自定义应用程序

3.    架构决策

3.    企业组件层

1.    企业组件支持的功能范围

2.    <这个企业组件支持业务领域、目标和过程>

3.    关于控制的决策

1.    <作为这个客户端组织内部企业组件来选择某物的标准>

4.    架构决策

4.    服务层

1.    服务分类表

2.    架构决策

5.    业务过程和合成层

1.    业务过程可以表现为舞蹈编排（choreographies）

2.    架构决策

1.    <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>

6.    访问或者表现层

1.    <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>

7.    集成层

1.    <包含 ESB 因素>

2.    <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>

3.    安全问题和决策

4.    性能问题和决策

5.    技术和标准的局限性以及决策

6.    服务的监控和管理

1.    描述和决策

现在，让我们更加仔细的描述一下每一层以及每一层之间的合成。

层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。

层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。

层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。

层 4：业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。

层 5：访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。

层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为 ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB 为集成提供了位置独立机制。

层 7：QoS。这一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。

 

通过什么步骤来进行基于服务的建模和架构

本节描述了如何利用遗留的投资，来 联合自顶向下的，业务驱动的手段和自底向上的手段。

基于服务的建模手段提供了建模、分析、设计技术和活动来定义 SOA 的基础。它通过在 SOA 的每一层定义元素以及在每一层作严格的架构决策来起到帮助作用。它通过联合服务鉴别的自顶向下、业务驱动方式和通过利用遗留资产和系统引导服务鉴别来实现这一点。

这样，高级别的业务过程功能性为大粒度的服务更加的具体化。小粒度的服务 -- 这些可以帮助实现高级别的服务 -- 通过检查遗留功能性和决定如何创建适配器、封装器，或者组合遗留系统来具体化系统内经常调用的期望功能性可以来鉴别。

最后，使用 针对服务的建模，你使用 跨部分手段来削减候选的可能已经被确定的服务的绝对数量。一个比较明智的手段应该是首先按照自顶向下来做，接下来进行目标服务建模，最后是自底向上的现有资产的遗留分析。消息是：你将项目的范围定义至一个可管理、实现的集合越快，你就能更快的通过聚焦在关键服务来公开组成 SOA 基础的服务描述来实现价值。

这个功能性业务需求和遗留系统中现有投资利用的结合，为那些想要快速赢得和移植他们的企业到一个现代的 SOA 的组织提供了有效的解决方案。通过基于服务的集成的软件应用程序的联合因此变得具备可能性。

基于服务的集成是 Enterprise Application Integration（EAI）的一个进化，在 EAI 中，所有的连接通过位置透明的 ESB 概念被基于标准的链接替换，并提供了一系列灵活的路由、中介和转化能力。

 

基于服务的建模：服务的分析和设计

迄今为止，我已经通过描述 SOA 设定了阶段。我同样展示了要想构建 SOA，你需要在你 SOA 的每个层中做关键架构决策，并且你的设计必须反映一系列依赖业务的服务和关于他们如何通过编排来合成到应用程序的决策。

与对象不同，你在 SOA 中需要考虑两个观点；他们是服务消费者和服务提供者。服务代理目前不是主流，并且在后面的部分终将被涉及到。

SOA 的设计策略并不从“自底向上”开始，这是 Web 基于服务途径常有的事情。你必须记住，SOA 更加有战略意义，并更加依赖于业务。Web 服务是 SOA 的巧妙实现。许多关键的活动和决策存在不仅仅影响集成架构，而且还影响企业和应用程序架构。他们包含两个 图 4 中描述的消费者和提供者的活动.

图 4：基于服务建模的活动

图 4显示了通过提供者和消费者的每个角色来管理的活动。注意，提供者的活动是消费者活动的父集（例如，提供者同样参与服务鉴别、分类等）。在许多情况下，角色的区别来自如下的事实，消费者指定他们想要的服务，经常的搜索它，并且一旦他们确信和他们寻找的服务规范相匹配，并且是由服务提供者提供，他们就会根据需要绑定和调用服务。提供者需要依次发布他们想要支持的服务；即在功能方面，更重要的是在消费者所需的 QoS 方面。这个在消费者和提供者之间的隐含的契约可能在 SLA 方面成熟为明确的契约；自动的或者通过业务和合法区域来处理。

上面描述的活动可以被描述为在基于服务的建模和架构方法内流动，如下面的 图 5 所示。

图 5：基于服务的建模和架构方法

基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程（典型地，服务的编排）的鉴别，指定和实现。

Service 鉴别

这个过程由域分解、现有资产分析和目标服务建模的自顶向下、自底向上、中间向外技术的联合组成。在 自顶向下视图中，业务用例的蓝图提供了业务服务的规范。这个自顶向下的过程作为 域分解来被引用，域分解由业务领域到它的功能区域和子系统的分解组成，包含它的流程或过程分解成过程、自过程和高级别业务用例。很多情况下，这些用例是公开在企业边缘的业务服务，或者在贯穿业务线企业边界内所用的非常好的候选。

在过程的 从下到上的部分或者 现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，你分析和利用了来自遗留和打包应用程序的 API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。

中间向外视图由 目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。

服务分级和分类

这个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。

子系统分析

这个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面的活动中实现服务。

组件指定

在下面的主要活动中，实现服务的组件的细节将指定：

• 数据
• 规则
• 服务
• 可配置概要
• 变更

消息和时间指定以及管理定义出现在这一步骤中。

服务分配

服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。 结构化组件在你使用模式来构造 企业组件时会通过以下几点的联合的形式出现：

• 中介体
• Facade
• 规则对象
• 可配置概要
• 工厂

服务分配同样由服务的指派和在 SOA 层中实现他们的组件组成。组件和服务向 SOA 层中的分配是一个关键的任务，需要关键架构决策的文件和决议，这些决策不仅仅同应用程序架构有关系，也同在运行时设计和用来支持 SOA 实现的技术操作架构有关的。

服务实现

这个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用 Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同于业务功能包括：服务的安全、管理和监视。

事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。

自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。

 

结束语

本文中，我以基于服务架构、它的层和架构决策的相关类型的基础知识来开始。接下来，我通过一种方法，描写了基于服务建模的活动，以及从服务消费者和提供者角度来看活动的重要性（服务代理将在后面的文章中涉及到）。这种方式为决定基于服务架构的三个基础方面提供了在分析和设计活动方面详细的指导：服务，流程和实现服务的组件。我还描述了一个模板，你可以用它来在 SOA 的每个层上为你的架构进行决策。

我提到了，对于服务鉴别，自顶向下、自底向上和跨部分、目标模型分析三种手段的结合非常重要。接下来我关注了一下服务指定和实现的主要活动。

这一系列的下一篇文章中，我将应用该方法到帐户管理的空领域中，并且用例子来描述每个步骤。除鉴别、指定和实现之外，我还将讨论基于服务建模手段的其余活动，包含用来支持完整的 SOA 生命周期的部署、监视、管理和控制。