任务:将组件分配到层
本任务指定了实现设计子系统的服务组件的详细信息。
用途

详细阐述一个或多个工具:设计子系统(已在任务:子系统设计(SOA)过程中描述)并提供详细的工件:服务组件设计。

关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

基于 SOA 的解决方案中所使用的服务是通过工件:服务组件实现的,它们属于满足特定业务功能的子系统。 每个服务组件都有责任确保它将实现的服务的 QoS。 作为企业级的资产,每个服务组件都具有与自身关联的筹资、管理和维护方面的资格。基础结构管理必须到位以确保服务组件的可用性、负载均衡、安全性、性能,版本控制以及整体运行状况,它们将负责实施一组服务的功能并确保其服务质量。 功能组件和技术组件可以在多个服务组件中使用。

步骤
将组件分配到层

分层具有以下益处:

  • 层有助于为 IT 系统的可修改性和可移植性带来高质量的属性。对低层的更改如果不影响该层的接口,则无需更改高层。 例如,任何符合 J2EE™ 标准的 J2EE™ 兼容应用程序服务器都可以自由替换而无需更改应用程序级别的软件。 对于从低层获取设施的高层的更改,不会影响任何低层。 通常情况下,如果对分层软件系统进行的更改不影响接口,则这些更改限于单层。
  • 在构造系统时,体系结构起到蓝图的作用,而层则是该蓝图的一部分。通过了解软件所在的层,开发人员可了解在编码环境中可依赖什么服务。层可以为开发团队定义工作分配(虽然并非始终如此)。
  • 层是体系结构扮演的通信角色的一部分。在大型系统中,模块之间的依赖关系数量会迅速增长。将软件组织为具有接口的层是管理复杂性和将结构传达给开发人员的重要手段。
  • 层有助于体系结构扮演的分析角色。它们可用于分析对设计的更改所产生的影响。

分层可以是严格的,也可以是非严格的。严格的分层模式表示组件只能够使用同一层中的组件或其直接下层中的组件。 非严格的层模式表示组件可以使用同一层中的组件或任何下层中的组件。但是请注意,一般而言,不应允许组件使用其上层中的组件。如果组件依赖于高层中的组件,则很难在不更改低层组件的情况下替换高层组件。 关于更多信息(包括对层进行建模的技术),请参阅概念:解决方案分区

需注意的很重要的一点是软件层(layer)不同于层(tier)。向分布式环境中机器的分配、元素间的数据流以及通信信道的存在性和利用情况均倾向于以层(tier)图来表示,而如果以软件层(layer)图来表示,则可能无发辨别。 层(tier)图倾向于显示双向箭头,这些箭头表示特定种类的双向通信。 双向(对称)通信在层(layer)图中并不是一件好事。而且,向层分配组件是基于定义操作体系结构时拟定的安排规则,且是由系统的必需服务级别特性定义的。软件层(layer)图与层(tier)图的主要区别在于前者没有安排的概念,而后者则明确具有该概念。

分层通用规则

  • 提供不依赖于应用程序的业务功能的所有组件都可以放入同一层。 不依赖于应用程序的业务功能与“客户管理”和“产品管理”类似,适用于很多不同的应用程序。
  • 提供技术功能(如错误处理,认证、日志记录以及审计)的所有组件都可以放入另一(逻辑)层。 这些组件既是不依赖于业务的,也是不依赖于应用程序的。在某些情况下,技术组件与功能组件的接近性可能要求将它们放在公共层中。这些是体系结构决策,因此需要如此记录。
  • 中间件组件(如消息排队和相关的 DBMS 软件)位于另一层。这也称为“结构层”(Fabric)。

示例

以下是 SOA 的分层视图,显示了对应于解决方案中不同元素的典型层(并且实际上是推荐的层)。

现在在此分层模式中,很容易了解我们的组件将要所在的位置,可以将“租车”示例的相关组件放入“服务组件”层,如下所示。 请注意,我们希望在模型中采用严格的层,这样就可以利用 UML 组合在“服务组件”层中包含我们的组件,并且只使用委派端口显现服务组件的功能,其中,端口提供与服务组件本身相同的接口。

属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息