指南:服务组件模式
本指南说明可用于服务实现中的服务组件开发的一组模式。
关系
主要描述

简介

通过将服务组件分解成功能和技术的组件,我们已委派了由服务组件提供以承担子系统功能职责的功能。功能组件提供所需的业务功能,而技术组件提供以可操作性和非功能性为主的一般功能,例如,认证、错误处理、审计和日志记录等。

服务模型是设计时间工件。因此,它不直接处理服务的实施。 但是,服务或服务集的实际实施都由服务组件对服务规范的实现来严格执行。服务规范提供了实施合同;只要履行了合同,用于实施服务的技术是无关紧要的。在概念面向服务的体系结构中,我们引入了下图来说明所确定服务之间的关系,以及实施这些服务的组件和对象。

 通过关联的文本对图进行描述

通过此方式,我们可了解如何使用 RUP 设计模型来捕获组件和对象层的设计,其中实施模型和工件可捕获对象层及相关联的实施和部署工件的详细信息。服务模型与组件设计模型之间关系的重要方面是:这组服务规范代表必须满足的约束,规范中所确定的操作必须按原样实施,服务的使用者使用这一模型来了解他们期望使用的服务的接口和行为。因此,服务规范与某些作为服务的实施初始入口点的实施工件之间有直接且通常是一对一的关系。

例如,考虑服务提供者的下图,它显示了在其定义中使用的模型元素的详细信息。

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

使用服务组件的关键是它对于服务模型应该是直接可跟踪的。实现这一点最容易的方法是利用服务规范元素是可由服务组件实现的 UML 接口这一事实,因而确保其与结构规范的一致性。用此方法,我们将得到以下结果:

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

现在,定义提供结果组件行为的组件和类集合是组件实施者的职责。

服务组件的种类

功能组件

将这些功能组件组合成大粒度的服务组件,这种组合不仅是结构性的,而且涉及到流程定义,即:功能组件进行协作以提供用以支持业务流程的功能。正如我们前面所见,这些业务相关组件的功能通过已定义的服务(由组件的更细粒度的对象或由旧系统结构实施)启用。

重要的是要注意到此步骤包含传统的 OOAD 活动。我们具备有重点且合理分区的范围来指导对象设计。在传统的面向对象的设计中,我们倾向于创建更大且依赖性更强的对象图,而如果在确定了业务中的功能区域后进行子系统分析,则我们具有可作为重点的定义非常清晰的范围,并将设计工作引向该范围。这样将形成联系较为松散的一组对象模型(由系统用例触发的类图和时序图)。

技术组件

技术组件组合成大粒度的服务组件,方式与功能组件相同。 可以在业务流程之间使用诸如认证、日志记录和报告之类的技术组件。需要使用这些常见组件来形成用以支持功能组件的基础结构。业务流程间的主要差异之一是由于业务规则而引起,如下图“企业组件模式”所示。 通常在面向差异的设计期间捕获这些差异。

服务组件模式

前面已经说过服务组件只是实现服务规范,但这样的表述并没有向下列操作的实施者提供很多帮助:从粗粒度(详细程度较低)的服务定义转为提供服务行为所必需的一组细粒度(详细程度较高)的实施类和工件。在这点上,通常依赖为结果服务组件提供结构的模式,该模式作为满足特定策略需求的开始框架或特定模式。

由 NFR、体系结构驱动的模式选项 [更多]

注意,此处介绍的其他构造型在工件:服务组件中有所描述。

基本服务组件模式

在定义服务的初始结构时,提供了以下模式作为定制和完成的起点。

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

模式的元素是:

  • 外观组件;外观实现与服务组件本身相同的界面,并在将请求传递到操作组件以执行之前提供消息验证的基本功能。在此情况下,我们将组件的构造型定为<<外观>>以便分类。
  • 操作组件;给定服务的详细程度,在大多数情况下,实施服务提供的每个操作都有一个独立的组件/类是很有用的。

以下内容说明了此模式的组合结构视图。在此情况下,外观由服务组件本身代表。因此,对服务组件调用操作的使用者实际上由外观组件提供服务。请注意,可以使用 UML 2.0 端口,也可以显露界面并使用接口使该代表明确。

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

单操作服务组件模式

在某些情况下,当服务由多个操作在服务模型中确定时,将操作作为分隔逻辑服务和物理服务视图的独立服务单独实施更合适。这样的模式优点是来源灵活、高可用性、版本控制和演进,但作为一组相关的操作却失去了服务接口的概念。

按照此模式对服务组件建模有一个<<服务组件>>用单个操作实现单个接口,都根据常用约定命名,如下所示。

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

在此情况下,正如我们提到的,用以上模式中的任何一个元素都不能直接实现原始的服务规范。因此,在该模型中引入一个能提供可跟踪性回到服务规范的元素看来是值得的。在以下示例中,我们引入了一个组件,构造型为<<子系统>>,它被记录为实现服务规范并且还拥有以上描述的元素。

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

此模式也未引入<<外观>>组件,因为服务的使用者负责确定他们使用的服务。

调解的操作模式

当服务使用者的请求可以被路由至某个所选的操作组件以供执行时,就可以用介体将那个模式扩展为路由这些消息,如下所示。 请注意,我们将组件/类的构造型定为<<介体>>以便分类。用于调解的确切机制未被定义。可以提前知道实施的静态集,某种类型的注册表也可用于映射到基于使用者的特定实施、请求消息的内容等。此模式并非旨在用于以上所示的单操作模式。

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

这还影响了服务组件的组合结构视图;如以下所示,从外观显示了介体连接,该外观用它直接调用操作组件。

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

如果使用了介体本身外部的注册表,则不能显示从介体到操作组件的静态使用依赖关系或者组合结构图中各部分之间的接口。因此,我们如何能从介体到调解的操作组件对依赖关系建模呢?在下图中,我们介绍了将由每个操作组件实施的接口。然后,如下所示,我们就能从介体到接口对用途建模了。

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

我们还更改了组合结构图中的关系,包括接口输入的新部分,还表示了接口上介体和操作组件之间的多重性,如下所示。

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

数据访问组件

此外,当服务操作共享公共的数据需求时,突出显示为实施提供数据管理功能的特定组件可能很有用。请注意,我们将组件/类的构造型定为<<数据访问>>以便分类。

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

企业组件模式

以下企业组件模式显示的服务组件充当底层功能组件和技术组件的外观。在服务组件边缘的组件外观上显现服务。将外观上的服务请求转发到介体,然后通过介体将消息路由到相应的功能组件或技术组件。

通过关联的文本对图进行描述

企业组件模式

下面以租车为例来描述功能组件对技术组件的依赖关系和需求。

通过关联的文本对图进行描述

使用企业组件模式的租车预订服务组件

这组子系统组件模型将组成功能组件模型,功能组件模型显示了功能组件对于技术组件的依赖性以及功能组件自身之间的相互关系。需要将分配给子系统外观的叶级别子流程指定为子系统提供的服务。通过封装在子系统结构中的详细程度较高的一组系统用例来支持和实施这些子流程。用例实现取决于功能组件。接着,功能组件又依赖于技术组件和实用程序以满足其基础结构需求。