随笔档案

分析和设计

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

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

分析会在较高的（概念级）抽象级别上对将要构建的系统进行描述。分析的输入是一组需求和现有的资产

（或是应用程序或系统）。输出则是对需要构建的各个方面的描述。分析对 SOA 来说是至关重要的，因

为通过分析，可以在服务标识期间使 IT 与业务保持一致。分析结果将作为输入在设计中使用。

大多数体系结构（在第 1 部分中有述）工作是在分析和设计的工作流中、在项目的细化阶段执行的。
面向服务的分析和设计利用了分析和设计原则（如面向对象的开发或基于组件的开发中的原则）。例如，

您也许还记得所谓的面向对象的分析和设计 (OOAD)。不过，必须注意的是，SOA 的工作重点始终在于服

务（而不是对象或组件）。

服务标识

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

。

自顶向下方法

业务体系结构工作从一组业务目标开始，标识出一个或多个应予关注的业务流程，这在 SOA 中是非常典

型的。通过业务建模工作，可能会出现已经过设计的业务流程（即未来的流程），对于正在设计中的系统

，它们可以被视为功能性的需求。

自顶向下方法旨在分解业务元素（主要是业务流程和用例），然后将它们细化为适合服务的粒度。在使用

自顶向下方法的过程中，您通常要在业务任务中标识出各种服务操作。这种做法的好处在于，您可以确保

标识的服务与业务保持一致。

自底向上方法

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

便重用它们。

重用是 SOA 的一个重要组成部分，对于 SOA 的成功是极为关键的。您可能知道，遗留应用程序（即已经

部署的应用程序）是您的公司最宝贵的资产，应该加以利用。例如，自底向上方法将分析现有的信息管理

系统 (IMS) 事务或 COBOL 程序。

对于自底向上的分析，有一句忠告：您必须谨慎从事，不要盲目地公开现有的 IT 功能。例如，用于创建

、读取、更新、删除 (CRUD) 数据的各项服务的粒度可能太小，无法与业务保持一致。

此外还要注意，您应使用现有的资产分析工具（如 IBM WebSphere Studio Asset Analyzer），这一点至

关重要，因为准确的部署和运行情况常常是无人知晓的。

中间相遇方法

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

中间相遇方法需要业务分析师、软件架构师和遗留应用程序专家彼此协作。注意，虽然在特定项目的上下

文环境之外进行的自底向上分析也是有价值的（例如，某个企业体系结构团队对候选服务进行编目），但

事实上，作为项目的一部分，在工作开始时通常会采用自顶向下方法，对一个或多个业务流程进行分解。

此后，会在这个上下文环境中进行自底向上的分析，试着为所需的服务找到与之匹配的项（中间相遇方法

）。

通过上述三种方法，可对服务集及其操作进行标识和验证（例如，通过验证，可以确保服务先前并不存在

，或服务与业务保持一致），并对它们分组，归入各个逻辑类别（如业务组件或业务功能区域）。另外还

要标识业务项（如策略或索赔），这些业务项主要来自现有的数据遗留应用程序。下一个步骤是完整地指

定这些服务及其操作，定义它们的结构和行为。

 

 

服务实现

服务实现旨在对如何实现服务进行设计。这一设计已经达到最为详细的程度（仅次于代码级）。它的目的

并不是实现（构造）服务，而是在设计级描述如何实现服务，至于实现（构造）服务，将在第 3 部分予

以介绍。服务实现是由软件架构师和设计师来完成的。

在规范和实现之间有一道明显的鸿沟。您可以用一个简单的方法看出它们的区别：如果说服务规范解决的

是是什么的问题，服务实现介绍的就是怎样做。

设计模型

由 RUP SOMA 定义的设计模型，是服务实现的核心输出工作产品。它描述了 SOA 的实现，是对实现（包

括代码）的抽象。服务实现的输出将被输入到服务的正式实现之中。

服务组件

您应当关注的主要设计模型组件是设计组件，它表示的是一个或多个服务规范是如何实现的，还描述了如

何处理所有的功能性/非功能性需求，以及结构和行为规范。

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

正如先前所说的那样，服务实现应当大量使用设计模式（如委托模式、独立模式和工厂模式），这些模式

一般是在服务实现期间被应用到各个类的。

 

服务设计原则

这一部分将列出您在设计 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 会同时包括细粒度（原子服务）和粗粒度

（组合服务）两种服务。