服务标识 是核心的面向服务的分析活动。服务标识的目的是将各个分组的概念化服务及其操作标识出来。
这些经过标识的服务对于业务而言是有意义的，业务需要这些服务。事实上，业务分析师会帮助软件架构师进行这项工作。下一部分将介绍服务设计原则，您会了解到对服务逻辑分组的需求、对服务及其操作的业务命名的需求。这些都是在服务标识期间决定的，其间使用了多种技术，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等建模语言来设计服务。例如，您应记住，服务提供者通常是由带有 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 元素之间的映射
