SOA 术语概述，第 3 部分: 分析和设计

引言

在任何领域中，语义都非常重要，而在 SOA 中更是如此。由于 SOA 涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始 SOA 之旅，为您定义各种基础术语和它们背后的重要概念。您将了解 SOA 领域中需要理解并用于沟通的各个词汇。对于每个术语，将说明它在 SOA 领域中有何重要性、在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。

第 1 部分中确定了业务的焦点，并通过定义服务、SOA 等术语为后续部分打好了基础。第 2 部分涵盖了开发流程、模型和资产。这一部分是本系列的第三期，在其中，您将探索各种术语和技术，它们有的与在高抽象级别（分析）下设计 SOA 有关，另一些则涉及如何推进到较低的抽象级别（设计），后一种级别的下面紧接着代码级。

关于组织方式的说明
以下列出的术语并不是按照字母顺序排列的，同时也未按照其重要性进行排列。相反，我们将按照构建块的方式对其进行组织。第 1 部分最先介绍的是服务，因为若要理解 SOA 框架，它大概是最重要的一个概念。本系列接下来的各部分是以服务概念为基础的，为了定义其他术语，它们对与特定原则有关的概念进行分组，如本文中的分析 和设计。


分析和设计

本系列的第 2 部分介绍了 IBM® Rational® Unified Process® (RUP®)，后者在需求和实现之间定义了一套被称为分析和设计 的原则。分析和设计的内容包括若干活动，通过这些活动，可根据功能和非功能需求集来指定初始的 IT 体系结构。其他一些活动也可作为分析和设计的基础，这些活动对初始的体系结构加以细化，使抽象级别由分析级进入设计级，这一细化程度足以让开发人员生成和编写出实现代码。

SOA 分析和设计也可以指以下术语中的一个或多个：

服务建模
面向服务的分析和设计
面向服务的建模和体系结构 (SOMA)
Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

分析会在较高的（概念级）抽象级别上对将要构建的系统进行描述。分析的输入是一组需求和现有的资产（或是应用程序或系统）。输出则是对需要构建的各个方面的描述。分析对 SOA 来说是至关重要的，因为通过分析，可以在服务标识期间使 IT 与业务保持一致。分析结果将作为输入在设计中使用。

设计会描述将要构建的系统，更重要的是，它还会对如何构建加以描述。

大多数体系结构（在第 1 部分中有述）工作是在分析和设计的工作流中、在项目的细化阶段执行的。

面向服务的分析和设计利用了分析和设计原则（如面向对象的开发或基于组件的开发中的原则）。例如，您也许还记得所谓的面向对象的分析和设计 (OOAD)。不过，必须注意的是，SOA 的工作重点始终在于服务（而不是对象或组件）。

注意：分析级模型常会发展为设计级模型，所以对于分析和设计而言只有一套 RUP 原则。

面向服务的分析和设计工作的主要输出是一个服务模型（即先前所说的服务规范）和一个设计模型，服务模型记录了面向服务的系统中所有重要的体系结构部件，而设计模型则进一步阐述了服务模型应如何实现的细节。这两个模型对 SOA 设计进行了全面说明，开发者可以据此明白无误地执行这一实现。

在下列各部分中将描述相关任务，为您介绍面向服务的分析和设计的相关术语。

注意：术语标识 和规范 适用于基于组件的开发中，而术语规范 和实现 则是由通用建模语言 (Unified Modeling Language, UML) 定义的。这三个术语构成了 RUP SOMA 的核心活动（术语的含义未变）。


服务标识

服务标识 是核心的面向服务的分析活动。服务标识的目的是将各个分组的概念化服务及其操作标识出来。

这些经过标识的服务对于业务而言是有意义的，业务需要这些服务。事实上，业务分析师会帮助软件架构师进行这项工作。下一部分将介绍服务设计原则，您会了解到对服务逻辑分组的需求、对服务及其操作的业务命名的需求。这些都是在服务标识期间决定的，其间使用了多种技术，RUP SOMA 中描述的那些技术也包括在内。

在第 1 部分中，您将了解到解决方案堆栈参考模型和它的各个功能层次：处于顶端的是使用者和业务流程，服务位于中间，操作系统和组件在最底层。在这一模型的基础上，您可以采取不同的方法标识服务（具体方法取决于您是从示意图的顶部还是底部开始）。我们来深入了解一下：

自顶向下方法

业务体系结构工作从一组业务目标开始，标识出一个或多个应予关注的业务流程，这在 SOA 中是非常典型的。通过业务建模工作，可能会出现已经过设计的业务流程（即未来的流程），对于正在设计中的系统，它们可以被视为功能性的需求。

自顶向下方法旨在分解业务元素（主要是业务流程和用例），然后将它们细化为适合服务的粒度。在使用自顶向下方法的过程中，您通常要在业务任务中标识出各种服务操作。这种做法的好处在于，您可以确保标识的服务与业务保持一致。

自底向上方法

自底向上方法旨在分析现有的 IT 资产（如遗留的应用程序和系统），找出可以作为服务公开的功能，以便重用它们。

重用是 SOA 的一个重要组成部分，对于 SOA 的成功是极为关键的。您可能知道，遗留应用程序（即已经部署的应用程序）是您的公司最宝贵的资产，应该加以利用。例如，自底向上方法将分析现有的信息管理系统 (IMS) 事务或 COBOL 程序。

对于自底向上的分析，有一句忠告：您必须谨慎从事，不要盲目地公开现有的 IT 功能。例如，用于创建、读取、更新、删除 (CRUD) 数据的各项服务的粒度可能太小，无法与业务保持一致。

此外还要注意，您应使用现有的资产分析工具（如 IBM WebSphere® Studio Asset Analyzer），这一点至关重要，因为准确的部署和运行情况常常是无人知晓的。

中间相遇方法

中间相遇方法在需求（由自顶向下的分析标识出来的服务）和现有的 IT 资产提供的功能之间进行协调。

中间相遇方法需要业务分析师、软件架构师和遗留应用程序专家彼此协作。注意，虽然在特定项目的上下文环境之外进行的自底向上分析也是有价值的（例如，某个企业体系结构团队对候选服务进行编目），但事实上，作为项目的一部分，在工作开始时通常会采用自顶向下方法，对一个或多个业务流程进行分解。此后，会在这个上下文环境中进行自底向上的分析，试着为所需的服务找到与之匹配的项（中间相遇方法）。

通过上述三种方法，可对服务集及其操作进行标识和验证（例如，通过验证，可以确保服务先前并不存在，或服务与业务保持一致），并对它们分组，归入各个逻辑类别（如业务组件或业务功能区域）。另外还要标识业务项（如策略或索赔），这些业务项主要来自现有的数据遗留应用程序。下一个步骤是完整地指定这些服务及其操作，定义它们的结构和行为。

服务规范

服务规范和实现是核心的面向服务的设计活动。服务规范 旨在为那些在体系结构方面具有重要意义的服务元素设计它们的结构和行为。

服务模型

服务规范的主要输出是一项 RUP SOMA 工作产品，叫做服务模型，它包含多种构件，如服务规范（接口）、服务提供者和服务协作。服务模型必须足够完善，以使服务提供者和使用者能明确地知道该服务是怎样的。

对服务的指定，包括以下各项设计：

服务规范

在服务模型中，服务规范构件是一个接口，用来描述由某个服务提供的各项操作。

此外，还可以通过设计，让服务消息充当操作输入、输出或故障参数。

您可能会认出源自面向对象范例的接口和各种操作概念。对消息、协作和策略（在本文的稍后部分有述）的重视，这可以被看成是由面向服务带来的一项进步。

服务规范充当了服务提供者和服务使用者之间的协议。它定义了服务的结构和行为。

服务提供者

在服务模型中，服务提供者构件会将相关的多个服务集中起来，进行分组。

服务提供者中包括：

必需的服务规范（如果该服务如下列部分描述的那样，是一个组合服务，且属于某个协作的一部分）。
提供的服务规范。
提供的服务。

例如，有一个名为 Sales Management 的粗粒度服务提供者，它支持销售管理功能区域。这个服务提供者可以提供两个服务，分别称作 Account Activation 和 Application Inquiry，其中 Account Activation 服务的类型为 Account Activation 服务规范。

在服务提供者的设计中，应利用那些来自基于组件开发中的原则。通常，服务提供者是由 UML 组件表示的，服务将作为这些组件的 UML 端口。注意：服务（端口）的类型是由服务规范定义的。

服务协作

在服务模型中，服务协作构件代表两个或多个服务之间的通信。服务协作规定了服务在与其他服务组成的环境中的动态行为。

与协作相关以及意义相近的术语有编排、协调或组合。

原子服务是指不需要其他服务的细粒度服务。组合服务的粒度较大，需要其他服务为其提供服务。因此，组合服务充当了服务使用者的角色，它总是需要相关的服务协作。

在第 1 部分中，您已经了解到，业务流程执行语言 (Business Process Execution Language, BPEL) 可以用于指定某个业务流程流的可执行版本。它在服务协作领域也扮演着重要角色，因为它可以用来实现一个组合服务，后者是由多个原子服务通过协作构成的。

注意，服务使用者和服务分区（即 SOA 的结构）也需要利用设计来处理；本文不会深入探讨这一问题，因为它属于细节内容。

服务质量方法

如果使用的是传统的（非 SOA 的）方法，则设计需要处理功能性（如用例和业务流程）和非功能性（如服务质量，即 QoS）需求。

QoS 描述应当成为服务规范的一部分。此外，您还应使用被证明有效的设计模式来处理它们。（在服务实现期间，通常会频繁地使用设计模式。）

与服务需求使用状况有关的策略也需要在设计级进行处理。对于策略，将在本系列后面的部分予以介绍。



为了让设计明确、完整、没有歧义，您应当借助 UML（请参阅第 2 部分）等建模语言来设计服务。例如，您应记住，服务提供者通常是由带有 UML 端口的 UML 组件来表示的。此外，UML 协作或序列关系图也支持服务协作的建模。更确切地说，您应当使用 UML 概要来进行面向服务的设计，如第 2 部分中介绍的 UML 2.0 profile for Software Services。

MDD 允许您在不同抽象级别对元素进行建模和指定。您可能已经注意到，在这一系列活动的进展过程中，是逐渐向较低的抽象级别深入的。先是业务级，然后是分析级，现在则到了设计级。在本系列以后的各篇文章中，您将了解代码级的实现。MDD 提供了各抽象级别之间的半自动转换。例如，您会发现，您可以根据服务模型工作产品生成 Web 服务描述语言 (Web Services Definition Language, WSDL) 文件。而且，您最终还可生成代码（通常是根据设计模型生成的），作为 SOA 实现的基础。

MDD 方法还支持可跟踪性，通常是从低抽象级到高抽象级的跟踪。例如，您可以将某个设计决策与它处理的需求联系起来。这可以快速分析需求变化对您的设计造成的影响。

支持
在这一领域，我强烈建议您了解下列术语，它们在本系列前面的部分中有述。您还可以在本文的参考资料部分找到更多有关它们的信息。

Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA) 流程
IBM Rational Software Modeler (RSM) Rational Software Architect (RSA) 工具
UML 2 Profile for Software Services
developerWorks RAS 存储库中可供使用的 SOA 设计资产和模式
业务服务建模，它能提供业务流程建模元素和 UML 元素之间的映射


服务实现

服务实现旨在对如何实现服务进行设计。这一设计已经达到最为详细的程度（仅次于代码级）。它的目的并不是实现（构造）服务，而是在设计级描述如何实现服务，至于实现（构造）服务，将在第 3 部分予以介绍。服务实现是由软件架构师和设计师来完成的。

在规范和实现之间有一道明显的鸿沟。您可以用一个简单的方法看出它们的区别：如果说服务规范解决的是是什么的问题，服务实现介绍的就是怎样做。

[size=small]设计模型

由 RUP SOMA 定义的设计模型，是服务实现的核心输出工作产品。它描述了 SOA 的实现，是对实现（包括代码）的抽象。服务实现的输出将被输入到服务的正式实现之中。

服务组件

您应当关注的主要设计模型组件是设计组件，它表示的是一个或多个服务规范是如何实现的，还描述了如何处理所有的功能性/非功能性需求，以及结构和行为规范。

在服务实现期间会创建大量的新类，对服务组件和服务进行细化。此外还会定义这些类的结构和行为。

正如先前所说的那样，服务实现应当大量使用设计模式（如委托模式、独立模式和工厂模式），这些模式一般是在服务实现期间被应用到各个类的。

WSDL 和 XML 模式

在实现期间，您将针对各种技术作出决策。事实证明，Web 服务对于 SOA 而言是一个可靠的平台。MDD 工具（如 IBM Rational Software Architect）可以根据服务模型为服务提供者生成 Web 服务描述语言 (WSDL)，以及相关的 XML 模式文件 (.xsd)，后者会定义在服务提供者和使用者之间流动的消息。无疑，WSDL 和 XML 模式既可以是服务实现的输出，也可以是实际的服务实现过程的初始输出之一。

QoS 和服务分区

选择采用什么技术，对服务质量有巨大的影响。某些技术可能不支持您的某些需求。在可靠的消息传递或性能（如吞吐量）方面就有这样一个例子。对于传统（非面向服务的）设计而言，您最好将各个供选择的技术映射到分区。而对于 SOA，在服务实现期间，可能需要对在服务规范期间定义的服务分区进行修改，以便让特定的技术来处理相关的服务策略（访问途径、安全、性能等等）。例如，您可以想一想某些性能需求和互操作性需求，前者要求在内存中处理事务，而后者可能会使用 SOAP 和 Web 服务，或在某些情况下改用本地调用。

在您完成了服务设计之后，下一个步骤就是根据这一设计实现（构造）服务，这将在本系列的下一部分中介绍。


服务设计原则

这一部分将列出您在设计 SOA 解决方案时必须牢记的四项服务设计原则。不过请注意，这并不是一份官方的正式列表，而且也并不全面，其中一些概念来自于其他范例，如面向对象。这些原则在面向服务的解决方案设计中是十分重要的。

重用
在设计服务时，请把重用这一原则随时记在心中。通常，在设计时，特定的服务使用者会有特定的要求。不过，如果您想从 SOA 中获益，您会希望那些需求略有不同的其他使用者会重用自己设计的服务。而在您创建设计时，并不知道这些使用者，也不知道它们有什么需求，因此这并不是一项轻松的任务。

下面是您可以考虑的事项：

根据业务域（而不是技术）为服务及其操作提供一个有意义的描述性名称。
提供完整的、可由人工阅读或计算机处理的规范，并将其公布给服务注册中心，使服务可以被发现（详细信息，请参阅本系列后续的部分）。
各个使用场景的服务质量与初始场景不同，例如，如果服务被频繁使用，需求和工作负载提高，可以制订相应的计划。
是否有可能对服务提供的初始功能（是根据初始需求集提供的）进行扩展，以便完善服务。
是否有可能在多种不同的平台上实现某个服务规范。
松散耦合

耦合是指实体或系统彼此间的依存程度。在 SOA 的上下文中，您可以考虑服务规范与它的提供者或实现之间的耦合，或服务提供者与服务使用者间的耦合。如要支持 SOA 应有的灵活性，必须采用松散耦合。

服务提供者无需了解服务使用者的某个特定实例，反之亦然。如果要替换某个服务提供者或服务的实现，必须保证这样做对使用者造成的影响可忽略不计，或不会对其造成干扰。

如果要帮助实现松散耦合，请考虑下列事项：

将服务规范（本文中所述的服务和模型）与服务实现分离开来。正如第 2 部分有关 MDD 的那一节所描述的那样，对于服务而言，拥有完整的规范是十分重要的，规范不会依赖于某个特定的实现。而且，服务契约应处于规范级别（而非实现级别）。
使用工具，以一种人机可读的标准格式（如 WSDL 和 WS-Policy）描述服务规范，以使代码生成器能帮助您实现服务（ 本系列的第 4 部分将提供这一方面的详细信息）。
当开发服务使用者的代码时，请记住，可能存在服务中间层或其他提供者，请不要对某个提供者的实例的任何信息进行硬编码。

无状态性

事务状态意味着服务必须具有关于某些发生的事件的信息，这些事件是一个在服务提供者和服务使用者各自的特定实例间长期运行的事务的一部分。例如，如果服务操作已被调用，或在调用某个操作前需要先调用另一个操作，在这两种情况下调用服务操作的结果是不同的。虽然在基于组件的开发中可以找到事务状态的身影，但对于 SOA 来说，事务状态却是应该避免的。

数据（信息）状态意味着需要对数据实例的状态进行管理。某些服务通常需要管理数据的状态。以保险业中的索赔服务为例。该服务必须管理索赔实例的状态，因为多个用户会通过不同的业务事务访问这些实例。注意，保持状态不变的服务通常是原子（细粒度服务）。如要处理状态需求，您应依靠一些在实现中运用的基础技术，如 Java™ 平台、使用状态会话 Bean 的 Enterprise Edition (Java EE) 等等。

粒度

对于面向服务的设计，您可以对粒度进行考虑，如服务提供者级或服务规范级的粒度（对于前者而言，要考虑应提供多少服务）。服务规范是一个针对服务操作的逻辑分组。在此处，逻辑表示它在业务方面的合理性。例如，在保险领域中，一个索赔处理接口将提供使用索赔处理的场景中所需的所有操作。这在 IT 实现方面也是合理的。例如，服务中所有被标识出的操作都可以通过同一种开发迭代实现。

在设计服务操作时，请考虑协作、使用场景，以及在服务提供者和使用者之间流动的消息的数目和大小。粗粒度的操作可以提供更高的业务价值，而且使对实现的修改变得更容易了。粗粒度操作的参数（使用消息作为输入、输出和故障参数）出错率较低。不过，使用细粒度的参数（而不是消息）通常具有更好的描述性。例如，如果某个操作服务签名为 determineEligibility(application: ApplicationMessage)，则您需要查看 ApplicationMessage 的定义。如果签名为 determineEligibility(customer : Customer, product : Product, date : Date, amount : Amount)，则该签名的描述性更好。此外，Customer 或 Product 参数类型（举例来说）可以在其他操作中重用，这与 ApplicationMessage 不同。

对于服务粒度，请务必记住，服务是可组合的。这涉及到重用和在现有功能基础上提供新功能的能力。某一粒度级别的一组服务可以通过编排，形成另一个具有较粗粒度的服务。您可以想想这个例子：多个服务提供各种业务任务，然后将这些业务任务排成序列（一个业务流程），以提供另一个服务。

最终，如果要在设计决策中确定服务粒度，应当在性能（如在高效实现的前提下，用于交换的消息的大小和数目）和重用的可能之间作出折衷。而且，一个典型的 SOA 会同时包括细粒度（原子服务）和粗粒度（组合服务）两种服务。

结束语
本文介绍了与 SOA 解决方案的 IT 体系结构和设计相关的术语。您已经了解了在进行面向服务的分析期间，IT 满足业务需求的过程，您沿着抽象级别路径逐级向下，对设计进行进一步细化。您从一组需求开始，逐步了解在设计符合需求的 SOA 时发生的各项活动（以及与之相关的术语）。您最终得到的是一个详细而明确的设计，可以在实现的过程中加以运用，这是本系列的第 4 部分所要介绍的主题。 请继续关注 developerWorks，以获取更多信息（您可以使用参考资料部分中的 RSS feed 链接，以便在下一期文章发布的第一时间抢先阅读）。