对于许多 IT 计划来说，面向服务的体系架构（SOA） 是一种事实上的架构方法。因此了解在哪些情况下不适合使用该模式非常重要，因为这会给 IT 程序的交付带来重大影响。本文重点介绍了两个 SOA 反模式，它们定义了执行 SOA 交付时发生的问题。首先以一个分层参考架构的形式引入一个简单的 SOA 参考框架。然后使用该参考框架说明发生反模式的深层原因。对于每个反模式，都会提供一个说明问题根本原因的描述和重构解决方案的方法，从而促进成功的交付。

简介

传统交付方法以系统开发生命周期为基础，不同的组织负责实现不同的生命周期部分。此外，在这种方法中，强调一个供应商交付一个完整的系统或子系统。下文图 1 展示了一个简单的交付生命周期视图和一个典型的组织职责分配。

SOA 的出现推导出一个分层架构模型。这为实现多种交付方法提供了机会，从而由不同的部门负责交付服务层的特定元素。这种协作 SOA 约定体验确定了可能出现的问题场景。在本文中以反模式的形式描述。

第一个反模式是 Interface Bloat，其中过份强调的是概括从特定架构层传入传出的数据结构。结果导致接口 “膨胀”，在层之间传递了不必要的数据。

第二个反模式是 Architecture Redundancy，其中忽略了不同架构层的职责。结果导致有些层没有实现架构价值，而仅仅起到数据传输通道的作用。

参考架构定义

SOA 参考架构如图 2 所示。它代表了一个概念级企业架构，一个面向服务解决方案。它为组织内的架构服务提供了框架。参考架构的基本前提在于，它使架构本身提升为底层服务集合。所有这些服务都可以看成为一个 Architectural Building Block (ABB)。构建初步解决方案定义和确定范围时，Architectural Building Block 的概念可以参见 TOGAF 8.1（Open Group Architecture Framework，见 参考资料）中提供的定义。

SOA 参考架构的目的在于：

• 为相关架构服务提供一个逻辑分组
• 在架构构建块职责之间可以实现一个清晰的关注点分离
• 提供一个架构服务集合的综合分类

可以用多种方式使用参考架构。示例有：

• 澄清架构原则，说明所选原则的架构影响
• 说明给定业务场景的企业架构解决方案，使用协作架构构建块（ABB）定义该场景
• 作为企业架构路线图规划的工具，说明在给定时间点需要哪些架构服务来支持业务程序
• 说明架构服务的映射或特定技术实现的构建块
• 说明多供应商交付环境中组织的职责范围，在这种环境下，每个供应商负责不同的端到端交付部分。

在本文中，使用参考架构来说明如何在 IT 交付合作伙伴之间分配工作，这也是为了便于解释反模式引起的深层缺陷。

反模式 1. 接口膨胀

这种反模式（也称为 Data Tsunami）与 Presentation Services 层和 Process Services 层之间的接口额外规定有关。

描述

该反模式的环境是协作 IT 交付，其中客户组织和系统集成商交付合作伙伴（本例为 IBM）负责交付一个完整解决方案的组件。这是一种非常常见的情况，对于 SOA 计划尤其如此。

IT 合作伙伴负责提供 Web 门户，而客户组织负责生成业务组件和支持数据服务。因此，按照图 2 中展示的参考架构，按层划分的组织交付职责如下：

• IT 合作伙伴在 Channel Services 架构层交付服务
• 客户组织在 Process、Business 和 Data Services 层交付服务

这种跨参考架构的职责分配是导致反模式的根本原因。具体来说，客户组织在它的设计流程中不够成熟，无法有效地支持 SOA 交付，表现在以下几个方面：

• 正式宏设计流程的概念相对较新，因此未在组织中验证。
• 在编码没有完成之前生成组件间接口的正式规范。
• 无法实现特定的集中规范，采用的是较宽松、额外指定的接口。

此外，要实现 SOA 的关键好处之一，需要构建能够重用的服务。这导致对参考架构的 Process Services 层中构建可重用服务的过度强调。这导致 Portal 应用程序（Channel Services 层）和 Process Services 层的组件之间的接口变得过于一般化。

尝试一般化这些层之间的连接被认为是次优选择。支持用户界面的特定 Process Services 不可能能够一般化为 B2B 通道，其中交互操作的动力本质上是不同的。一个更好的方法实际上是提供一般化的 Process Services 来支持该通道的特定需求，本例中是一个基于 Web 的门户。整个参考架构层的重用重点如图 3 所示。

该反模式的最后一个因素就是交付的时间压力。也就是说，无法在详细的技术设计和代码编写之前得出正确的分析。

这些情况的最后结果是，Presentation Service 组件和 Process Services 组件之间传递了过量的数据。它的影响包括：

• 需要更多的查询和数据传输时间。
• 需要大量处理工作来解析 Presentation Services 层的数据，以及提取特定操作所需的数据子集。
• 由于数据的编组和传递，降低了响应时间，导致了性能问题。

反模式 2. 参考架构冗余（Reference Architecture Redundancy）

第二个反模式（也称为传递包裹（Pass the Parcel））与以下情况有关：每个架构层的组件设计中指定了相同的传输对象和方法。它的影响在于，大量处理逻辑将推入到一个架构层，让其他层完全冗余，而仅仅起到数据 “传输” 的作用。

描述

出现该反模式的环境是，SOA 模式对于客户组织相对较新。这种情况常常出现，因为很多组织现在才开始实施它们的第一个 SOA 计划。

在这种环境下，SOA 参考架构可能已经明确定义或者隐含。但是，客户组织还没有深入理解参考架构及其实践应用程序。

这种情况的结果是，错误地理解参考架构中每个层的职责。这又表明：

• 相同的方法签名出现在每个参考架构层的不同服务上。
• 层之间传递的输出对象过于一般化
• 业务逻辑层推入 Data Services 组件而不是驻留在 Business Services 层的组件中

结果导致：

• 有些参考架构层显得多余，它们没有任何附加值，仅仅向架构的另一个中间层 “传递” 数据。
• 没有实现 Business Services 的重用。
• 否定了 SOA 模式的好处。

重构解决方案是以应用参考架构的方式支持灵活性。灵活性的程度可以根据任何参考架构都有的架构原则集来确定。例如，仅仅检索或更新数据的数据服务操作如果没有应用业务逻辑，那么不应该允许直接从 Channel Services 层调用。在这种环境中不需要穿过 Business Services 层。该原则应该作为参考架构定义的一部分嵌入。

评注

基本的误解导致这两个反模式都需要在 Channel Services Layer 中应用一个通用数据格式。这通常不是一个合理的设计目标。Channel Services 层之间的连接应该利用特定于该通道的数据格式。

因此理想的方法是在 Process 和 Business Services 中仅使用 “规范化” 数据。例如，如果通道包含一个提供更新业务数据视图的 Web 应用程序，那么应该优化数据的传输，使之仅返回和更新视图中提供的数据。类似地，如果通道是使用特定行业数据标准的 B2B 网关，那么应该使用中间件将特定于通道的数据格式转换为 Process 和 Business Services 层中所选的规范化数据形式。这种首选 “规范数据区域” 如 图 3 所示。

重构解决方案应该允许各种不同的服务调用 Channels Services 层，而不是尝试一般化。这又会在 Business Services 层而不是 Process Services 层提升服务重用。这种方法还更好地遵从了面向服务架构的易组合性原则，因而可以利用现有的细粒度服务组成新的粗粒度服务。

结束语

本文展示了两个交付 SOA 计划的过程中可能产生的反模式。这些反模式的影响是巨大的，导致交付延迟、性能降低和缺乏重用。在严重的情况下，可能失去对模式的信心，从而取消 SOA 计划。

这些环境导致出现这些反模式，即在许多 SOA 工作中都存在客户和 IT 合作伙伴之间的协作约定，且缺少模式的实践经验。交付组织应该意识到这些反模式并做好防范措施。在实际交付中，他们应该能够发现表明出现这些反模式的各种表现，正如本文所述。

重构和确定清晰的架构原则链接集是避免这些反模式的关键所在。设计的开放性和强大的解决方案治理、广阔的商业范围也可以防止发生这些反模式。

参考资料

• 有关反模式的更多内容，请阅读书籍 Anti-Patterns: Re-factoring Software, Architectures and Projects in crisis（Brown et al、Wiley 和 sons，New York，1998）。
• 进一步了解 Open Group Architecture Framework (TOGAF) 。
• 借助 My developerWorks 个性化您的 developerWorks 体验。
• developerWorks Web development 专区：通过专门关于 Web 技术的文章和教程，扩展您在网站开发方面的技能。
• developerWorks 技术活动和网络广播：随时关注 developerWorks 技术活动和网络广播。