指南:服务
本指南详细描述了服务的定义:有具体化服务规范的可发现的软件资源。
关系
相关元素
主要描述

简介

服务是面向服务的体系结构中的关键工件,但是什么是服务呢?以下是 Rational Unified Process(RUP)词汇表中的条目。

服务是有具体化服务规范的软件资源(可发现的)。此服务规范可供服务使用者进行搜索、绑定和调用。服务提供者实现了服务规范实施,还为服务使用者交付服务需求的质量。 服务应该由说明性策略管理,因此支持可动态重配置的体系结构样式。

而且,虽然以下部分概述了以上条目中的一些主要声明,但值得注意服务的另一方面将其与先前技术中的设计元素确实区分开来;服务所处的详细程度级别使它们能从业务级别中被确定出来。所以,我们下面还将讨论服务的业务符合特性。

可发现的

服务不是整个应用程序体系结构的一部分。它们相对于给定解决方案中的任何和所有服务独立地存在于运行时。这意味着我们需要一种基于条件(例如它所实现的工件:服务规范、它的工件:服务提供者以及其他的业务和技术分类)的方法以定位和发现服务。此发现过程可能在开发期间发生,以将给定服务与支持服务匹配,或者它可能在运行时发生,以启用动态服务供应(调解的调用)。要能被发现,服务必须提供一组允许分类的元数据。该元数据是外部规范的一部分。

有关更多信息,请参阅概念:服务组合指南:服务协调

外部指定

外部规范允许服务公布其详细信息,如接口、位置、策略、分类等,以无需客户机即可访问服务本身。这种信息通常存储在已知位置或支持查询元数据的特别服务注册表中。当前,在 Web Service 领域,被接受的对服务接口的描述标准是 WSDL(Web 服务描述语言),该语言出自万维网协会。

服务规范工作产品实际上是三个部分的组合:接口、行为和策略规范。因此,实现这些不同的方面不只是需要 WSDL 提供的接口定义。

有关服务注册表的更多信息,请参阅概念:服务组合

基于合同

在以上的词汇表定义中,我们注意到服务规范为服务提供者和服务使用者都提供了一个视图。这些视图对应于允许明确分隔规范和实施的合同的两半。

下表描述服务规范的不同方面如何同时影响规范的提供者和使用者。

角色 接口规范 行为规范 策略规范
供应商 通知服务必须响应的操作和消息集。所有操作必须响应并用正确的消息答复。 通知此服务必须支持的行为。如果这样的行为规范正式且完整,则可以测试实施是否与规范一致。 通知服务实施可能遵循的一组约束以及必须实现的一组服务质量。
使用者 通知可能调用的一组操作。 通知使用者必须实现的协议需求(操作顺序、数据流等)。还指示使用者必须实施以支持协作的所有操作。 通知使用者在与此服务通信时必须认识的约束,如安全需求。它还标识了使用者可从给定供应商处获得的服务质量。

这样的服务规范可看作根据合同设计的应用程序,但它是获得可发现的和动态可重配置服务的必要步骤。

业务对准

通常,代表业务操作的业务模型与支持 IT 应用程序的设计模型之间的连接非常松散。在大多数情况下,它们完全断开连接。虽然 RUP 在从业务模型到系统用例模型的转换中的确提供了指导(请参阅指南从业务模型到系统),但当详细程度和抽象程度从业务更改为 IT 透视图时,连接需要一些转换。

通常很清楚,服务可能被分类到业务或基础结构服务中。有关服务分类的讨论,请参阅概念:服务组合

SOA 的一个重要方面是,面向服务的解决方案中所述服务的详细程度使得服务提供的操作通常可在业务级别确定。在支持 IT 的详细程度方面的该提高意味着,在许多情况下,在业务流程模型中标识的任务可作为服务的操作直接实现。所以,IT 解决方案的商业用户变得不仅仅是分析和设计流程的一部分。另外,有趣的是注意到这种与业务流程模型更紧密的连接还更直接地将服务作为 IT 工作产品与 RUP 业务建模规程中建模的业务目标关联。

有关业务模型与服务模型之间关系的更多详细信息,请参阅活动:现有资产分析

对服务建模

对服务进行建模时,使用软件服务的统一建模语言(UML)概要文件和概要文件中为每个元素提供的指导信息。通常,组成服务静态视图的元素和服务模型中的服务规范显示在下图中。

通过文本内容对图进行描述。

  • 服务提供者“UpdateCustomerAddressLegacyProvider”提供了服务“UpdateCustomerAddress”。
  • 服务“UpdateCustomerAddress”实施了服务规范“IUpdateCustomerAddress”。
  • 服务规范“IUpdateCustomerAddress”有一个操作“execUpdateCustomerAddress”。
  • 操作“execUpdateCustomerAddress”获取单个输入消息“UpdateCustomerRequest”。
  • 操作“execUpdateCustomerAddress”返回一个输出消息“UpdateCustomerResponse”。

模型的结构和组合视图捕获了服务和解决方案分区之间的通信。这在概念:服务组合和编排概念:解决方案分区中进行了描述。

备选方法

建模通常发生的情况是:对同一逻辑结构进行建模时存在几种备选方法,在一些情况下,可使用一些方法来表示更多的技术详细信息。例如,对已提供的和所需的服务能力的概念进行建模时,我们可以选择将描述这些能力的接口构造为服务规范,并使用未构造的类表示综合类型,或者可以选择对类本身(而不是接口)进行构造。下图将显示这两种选择。

总体而言,如果这些接口本身要由另一环境中的其他服务使用,则应构造这些接口。因此根据经验,无论考虑哪个元素,均应构造可复用的描述。在服务提供者(在 UML 术语中,则为类或组件上的端口)上创建服务时,将 ServiceType 或 MyService 类选为构造端口的类型,如下所示。

注意,对于 ServiceType 或 MyService,生成的结构完全相同,端口表示所需的接口和已提供的接口 - 可能是要求客户机提供的回调接口。但是在有些情况下,使所需的能力和已提供的能力显式分离,并编入各自的服务描述中,这将非常有用。在此情况下,我们需要两个类来实现上述服务规范。下图将说明这些类。

现在,创建服务提供者时需要两个构造型端口(如下所示),其中一个表示调入能力,而另一个表示回调能力。

至于何时需要这种额外的灵活性,则很大程度上取决于手头的任务以及需要包含到模型中的正式性级别。最后的示例非常清楚地说明对于调入和回调接口有着不同的概念;然而,如果同一提供者实施很多服务端点,将会发生什么情况呢?端口数量的激增可能使最终结果难以读取和理解。

有关服务设计和实施的更多信息,请参阅任务:记录服务实现决策