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

　　简介

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

图 1. 传统交付生命周期和组织职能分配
 

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

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

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

　　参考架构定义

　　图 2. SOA 参考架构

　　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 所示。

　　图 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合作伙伴之间的协作约定，且缺少模式的实践经验。交付组织应该意识到这些反模式并做好防范措施。在实际交付中，他们应该能够发现表明出现这些反模式的各种表现，正如本文所述。

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