工作产品:服务模型
服务模型是由面向服务的体系结构(SOA)的核心元素构成的模型。在实施和测试任务时,服务模型被用作必需的输入。
用途

服务模型是对企业内实施的且支持开发一个或多个面向服务的解决方案的 IT 服务的抽象。 它用于构思和记录软件服务的设计。它是全面的组合工作产品,包含所有服务、服务提供者、规范、分区、消息、协作及它们之间的关系。所需操作如下:

  • 确定候选服务,并捕获关于实际将显现哪些服务的决策
  • 指定服务的提供者和使用者之间的合同
  • 将服务与实现这些服务所需的组件相关联
关系
角色负责人: 修改者:
输入至必需: 可选:
外部:
描述
简述

服务模型通常是一组不同种类的实际资产,包括 UML 模型和文档,并且还可能包括需求管理工具中的各项。然而,服务模型必须包含下列逻辑元素(请参阅主要描述)。

  • 服务组合
  • 服务层次结构
  • 服务显现
  • 服务依赖关系
  • 服务组合和流程
  • 服务非功能需求
  • 服务消息
  • 状态管理决策
  • 实现决策
主要描述

服务模型通过多个迭代捕获一组服务的详细信息,这些迭代对详细信息进行渐进式的精化。服务模型可用于不同级别的范围:

  • 服务范围的开发,其中项目的范围是使服务的开发(尽可能地)独立于其他服务。因此,建模时应当将用例、体系结构、设计和实施模型包含为该项服务的垂直切片(vertical slice)。
  • 项目范围的开发,其中项目涉及到指定许多服务以支持一组应用程序需求,在此情况下,范围放宽到应用程序级别,并且可能涉及许多服务。实际上有一组应用程序级别模型针对用例和体系结构,然后有一组特定于服务的设计和实施模型。
  • 企业范围的开发(或:服务组合管理),其中仅在企业范围捕获服务规范和逻辑分区。这使设计人员和架构设计师能够对整个服务组合作出广泛的决策,而开发已确定服务(和客户机应用程序)的设计和实施模型仍需要独立的项目。

下图说明了服务模型的主要方面(抽象)以及它们与“确定”、“规范”和“实现”活动之间的关系。

 

确定元素

第一次精化始于活动:现有资产分析期间使用诸如流程分解(请参阅概念:业务流程分解)之类的技术在服务组合中创建的一系列候选服务。这些服务根据其功能区域以及用于确定它们的技术进行分类。重要的是要注意到:此处所述的服务组合是特定于项目的组合,它包含使用活动:现有资产分析中所述的不同分析技术所确定的候选服务。此阶段所确定的服务提供时通常只有名称,可能还有功能描述,通常包含这一服务列表的简单文档可能就已足够,然而,如果使用 UML 方法,那么该组合将作为一组工件:服务规范进行维护,并且可能使用报告:服务组合生成。

将使用功能分类方案(通常基于领域分解期间确定的功能区域)尽可能快地将列表中的服务组织成层次结构。此类层次结构说明了服务的主要分类方案 - 流程调用依赖关系的层次结构,因此将对了解分解活动期间所确定的服务之间的关系起重要作用。同样地,层次结构的表示方法可以是文档、电子表格或 UML 模型(在这类情况下,我们倾向于使用工件:服务分区对功能区域建模)。

请注意:术语“服务组合”也可能表示企业范围的服务组合(如概念:服务组合中所述),它具有超出特定于项目的组合的生命周期。实际上,企业组合和项目组合之间存在某种关系,如下图所示。

规范元素

活动:执行服务规范中首先要执行的步骤之一是确定并记录服务的显现 - 即:将这些要开发并显现的候选服务作为真实服务进行记录。一个主要技术是任务:应用服务石蕊测试,它提供了关于如何评估服务显现的具体指导信息。就服务模型的 UML 表示方法而言,“确定”期间开发的服务规范将在模型中使用状态属性标记为:待显现,随后作进一步详述。分析服务显现期间,可以着手将服务分组为逻辑服务提供,并且可以使用 UML 通过工件:服务提供者对此进行建模。

记录服务规范时,重要的是出于各种目的捕获所有的服务依赖关系,例如:具有很多依赖关系的服务在不同环境中的复用将更加困难,而具有很多依赖对象的服务则指示了核心能力。可通过文本捕获服务依赖关系,通常采用表格形式(请参阅报告:服务依赖关系),或者可以使用服务模型的 UML 表示方法对服务依赖关系建模。一些依赖关系是由于服务间的通信而产生的,因此就有与该依赖关系相关联的具体详细信息(所需的通信协议、安全性等),可使用 UML 模型(具体而言,对于协作模型是工件:服务通道)进行记录 - 认识到这一点也是很重要的。

定义服务时,通常要识别组合服务,其存在只是为了对一组粒度更精细(即:详细程度更高)的服务进行安排,该组合和流程 应描述组合服务和组成服务之间的关系以及通过服务间的流程所表示的服务间依赖关系。在 UML 表示方法中,该组合可(通过组合类)得到很好描述,流程也可(通过活动、交互)得到很好描述,概念:服务组合和安排中描述了这些技术。

还要捕获服务的非功能需求(而上述主题中有许多将重点更多地放在功能需求上),并捕获关于服务质量和策略等的尽可能多的详细信息,这一点很重要。在这方面,可使用文本文档表示这些需求,直接用 UML 表示会比较困难,但是用需求管理产品来表示可能更容易。使用服务模型的 UML 表示方法时,建议同时使用现有 RUP 工件:软件体系结构文档工件:补充规范来捕获非功能需求。非功能解决方案体系结构的一个方面关注于服务的分发和可用性,可使用 UML 模型(具体而言,工件:服务分区工件:服务网关)进行记录。

显然,详述服务消息对于开发可使用的服务规范是很重要的。这些消息可从高级别模型中派生得到,或者可通过某种特定于技术的形式(例如 XML 模式)直接表示。无论消息描述是使用文本方式、模式语言,还是 UML 模型,这些消息定义都应注意到任务:消息设计及相应的指南:消息附件中记录的主要注意事项。

虽然在 SOA 中我们确实努力使服务保持无状态,然而并非始终可能(甚至希望)使之成为固定目标;提供了主题状态管理决策,以使设计人员有时间考虑两者的权衡(即:服务状态管理的成本和收益)。作为对这些决策的支持,主题指南:服务状态管理提供了通常必须由服务维护的各种状态的示例。

实现元素

服务实现主要关注于三个方面:关于服务实际实现的决策,确定用于实现服务规范的子系统和组件,最后是这些组件的开发。

记录实现决策时,重要的是使来源和开发方法的选择具备合理而详细的理由,如任务:记录服务实现决策中所述。同样地,与上述非功能需求的情况类似,通常难以通过 UML 表示方法来(相当详细地)表示这些决策,因此我们希望分别记录对每项服务所作的选择。

属性
可选
已计划Yes
图示
定制
不具有的影响如果没有该产品,将难以正确定义服务并指定实现它们所需的组件。这会引发下列情况:服务组合中存在差距,不需要的服务数量激增,服务显现的方式存在不一致,实现服务所需组件的设计中存在不一致。
不需要的原因如果不需要在重要组织边界的边缘(例如:在企业内某一重要业务线的边缘,或者在企业的边缘)使服务描述具体化,则不需要该产品。
说明选项

服务模型是一个大型工作产品,通常是使用许多技术开发的,例如:使用 UML 模型来描述服务元素,然而工作产品的表示方法可以是一个文档,它包含 UML 模型中的图。特定项目对 UML 模型的依赖程度将取决于所涉人员的技能和背景,还可能取决于项目干系人的期望。总体而言,我们建议模型在开发时尽可能多地使用 UML 表示方法,并与其他内容(特别是描述性文本)集成,展示模型时使用文档作为它的最终格式。

关于 UML 表示方法,请参阅模板:用 UML 表示的服务模型

关于文档表示方法,请参阅模板:用 Word 表示的服务模型

更多信息