概念:解决方案分区
在此概念中,我们讨论基于各种组织考虑将系统分区为元素的逻辑集群的原则。那些考虑可以反映业务边界、物理边界或更抽象的边界主题。
关系
主要描述

简介

关于将软件设计分解为组件或子系统,已经有很多著作。关于需要在应用程序生命周期的早期了解它所需的部署拓扑以便作出正确的体系结构决定这方面,也已经有了不少著作。但是,当今很少有机制被确定或被用于在体系结构分析期间帮助对系统进行逻辑分区,以便在生成详细的设计和实施工作产品之前的模型级别就能很容易地作出关于解决方案逻辑拓扑的决定,并满足非功能需求所施加的约束。以下页面概述了证明此观点的一组简单的模型元素。虽然它们是用 面向服务的解决方案开发的,但这些技术适用于任何软件体系结构建模。

分区和层

以下定义取自 Rational Unified Process(RUP)词汇表,并与层和分区的概念对比。有趣的是,在描述解决方案的逻辑体系结构方面常见的术语层(tier)在 RUP 词汇表中却没有出现。

(1) 对模型中同一抽象级别的进行分组的一种特定方法。
(2) 在同一抽象级别,分类器的组织。层是对体系结构的横向划分,而分区是对体系结构的纵向划分。
分区
(1) 活动图:活动图中用于组织操作职责的部分。 另请参阅:泳道(swimlane)
(2) 体系结构:同一抽象级别上分类器或包的子集。分区表示对体系结构的纵向划分,而层表示对体系结构的横向划分。

所以,分区包含代表体系结构某部分的一组元素,但软件设计人员如何分解模型呢?答案看起来很简单:分区和层是组织结构;在体系结构级别,它们仅代表逻辑组织。那么,您希望代表解决方案组织的哪些方面?例如,如果您正在开发的模型视图与安全性有关,则您可能希望代表可信区域 [JOHNSTON]。

有关更多信息,请参阅概念分层分发模式

分区能代表什么?

正如我们以上所述,分区可用于代表架构设计师希望侧重的任何特定的组织问题。以下内容是在模型中构建的共同观点。请注意,分区的一个重要方面是它们不意味着所有权/包含,因此一个服务可以同时出现在多个分区中。

逻辑解决方案组织;在此情况下,分区代表给定解决方案中元素的逻辑集群。例如,在业务应用程序中,我们可以使用分区来表示用户交互服务、业务服务和基础结构服务的分离。这样的观点对应于在 RUP 中使用层来描述应用程序中的层。但是,因为对服务分层不象在基于组件或对象的解决方案中那么容易,所以我们使用分区。有关这些服务分类的更多信息,请参阅概念:服务组合

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

高级别物理分发;在此情况下,至少当物理距离对体系结构施加约束时,分区可用来表示本地和远程服务。例如,当我们发现数据中心之间的宽带连接是受管的并且我们必须小心地控制这些分区之间的通信时,注意到客户、帐户和订单服务都托管于我们的主数据中心,而电子数据交换(EDI )网关托管于副数据中心是很重要的。
业务应用程序/所有权边界;在此情况下,分区用于代表业务领域或应用程序领域对服务的所有权。例如,我们可以表示某些服务由人力资源部“拥有”,某些服务由销售部“拥有”,还有某些服务由市场营销部“拥有”。现在,虽然这不是体系结构问题,但大多数项目都必须解决不涉及技术或体系结构而是涉及组织的社会和政治的方面的问题。在此方面,通过要求项目干系人支持跨组织的更改,分区使我们能查看服务之间的交互如何跨越这类边界,并可能影响开发流程。在此情况下,业务分析期间已确定的工件:业务系统将形成此模型的类别。
业务流程边界;在此情况下,我们用分区代表端到端的流程领域,实际上,通过服务支持的流程将服务分组。下图将流程视图(阴影部分)与业务系统视图(用垂直条表示)进行对比。在很多情况下,将这两个已经部署的服务视图与项目规划的服务相关联是很重要的。

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

要理解每个业务领域如何为实际运行业务的流程提供服务,垂直业务领域和跨业务流程之间的这种关系是很重要的。对于我们的示例,此视图将我们先前确定的服务重新分组为以下显示的新分区。

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

有关流程建模和服务确定之间的关联的更多信息,请参阅活动:现有资产分析

服务模型中的分区

服务模型中,使用一个特定模型元素(服务分区)对逻辑分区进行建模。分区的 UML 2.0 表示方法基于类模型元素的使用(而有些用户希望使用类的子类型(例如组件或节点)以更好地满足他们的需要),并使用组合结构以定义分区中的服务及它们之间的通信。上图显示出服务分区元素,它可能既包含服务提供者的实例,又包含其他分区的实例,并在适用的情况下可能进一步包含其他的实例。服务分区也可以指定一个或多个服务网关,这些网关是已命名且具有类型的 UML 2.0 端口。这些端口的类型由服务规范按与服务相同的方式提供,因此可视作用于指定分区接口的虚拟服务。

所以,例如在上图中,我们会注意到订单管理流程区域由与订单输入服务提供者相同的接口来访问。我们将这称为将接口从服务中提升到分区。下图描绘了这一情况,并显示了订单输入服务提供者如何与分区中的其他服务通信。

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

服务网关的其中一个功能是调解分区外部的客户机和分区内部的服务之间的通信绑定。这允许服务只处理分区内特定的协议绑定,例如,使用边界内更高的性能或更安全的协议,并通过不同的协议向客户机显示特定的功能。有关更多信息,请参阅指南服务协调

另请注意,因为分区基于 UML 2.0 组合结构的使用,所以在分区和服务之间没有“包含”关系,如以上所示,可以用多个分区或视图代表相同的服务。如果这一灵活性与服务网关的功能有联系,则软件设计人员可以在逻辑分组中集群服务,并允许服务网关对客户机仅显现相关的接口。

指定严格的分区

在严格的分区中,所有服务都由分区外的客户机/服务通过服务网关访问。这意味着服务分区有其自己的接口集,因此可以将它看作逻辑高级服务提供者。这对于代表业务应用程序边界或业务流程边界的分区特别有用。它还允许被代表的流程确定它对其余业务显现的接口,以及公开提供哪些支持流程领域的服务。以上的订单管理分区是严格的分区,但“严格”的概念只能通过评估分区来评定,并且不是模型元素本身的属性。

在下面的示例中,由于客户机(在分区外)只能通过网关与订单输入提供程序(在分区内)通信,因而可以认为左侧的分区严格。另一方面,由于客户机与分区内的订单输入提供程序直接通信,因而不能认为图右侧显示的分区是严格分区。

重要的是意识到严格分区的建模(甚至网关的使用)是可选的,只需视为能够对分区间的显式通信进行建模的工具(无论分区自身代表什么),并且出于许多目的,可能认为额外开销是不必要的。

引用

[JOHNSTON] Simon Johnston,Modeling Security Concerns in Service-Oriented Architecture。IBM developerWorks 2004。