问题：此反模式带来的问题是标识服务的方式。当根据独立的应用程序(而不是以企业策略为中心)对服务进行标识时，期望 SOA 实现所带来的好处将永远不能实现。

环境：此反模式主要出现在根据独立工作的具有塔状结构的功能模型进行组织的企业中。每个功能塔所享有的自治权将导致采用竖井方式进行工作。

症状：此反模式的一个症状是不同的小组使用不同的名称对相同的服务进行标识。没有标识公共服务，或未实现服务共享，同样也清楚地表明应用了此反模式。

结果：由于采用竖井(silo)方法会导致服务被多次标识和实现，不必要的昂贵开发成本或服务重复使得采用 SOA 所能带来的好处大打折扣。而且，由于使用此反模式，会使不同应用程序的受益人间的重用减少或完全消失。

根本原因：在大多数情况下，组织的边界和约束是此反模式的根本原因。在某些企业中，缺乏对“服务公开决策”的有所控制的方法也是根本原因。

解决方案：此反模式的解决方案是建立一个控制框架，以确保跨功能塔进行服务标识和通信。另外，还应当进行以标识公共服务为目的的相关工作。这可以通过使用 SOMA 等好的服务建模方法来完成。

解决方案示例：标识公共服务

像大多数企业一样，一家大型银行是按照业务塔进行的组织，这些业务塔为不同类型的银行客户提供类似的业务功能。SOMA 用于开发服务模型，以促进业务塔间的重用和了解此类重用机会。从更高的角度来看，在支持业务功能所需的业务服务中，约有 90% 都具有相似性，这是潜在的重用领域。

I3:反模式名称:注册中心行为不正常

问题：在没有一致的 SOA 控制模型的情况下采用 UDDI 将导致流程和设计的效率低下。特别是重复的注册中心可能导致效率低下，使得性能下降，并可能产生安全和遵从性漏洞。

环境：没有注册中心控制协议，但却尝试建立 UDDI 用途的企业将经常遇到此反模式。

症状：考虑到 UDDI 是标准而不是产品，如果使用不恰当，可能导致建立重复的服务注册中心和重叠的、不明确的关系。这将表现为不正确的、容易引起误会的服务接口信息，特别在共享服务模型内的组合服务场景的发现操作期间表现得十分明显。尽管注册中心中单个服务接口的描述是正确的，但重复的条目将导致整个服务的发现不正确。而且，缺乏控制模型可能是由于服务在生命周期流程的各个阶段注册，当不具有一对一的所属关系转换时被遗弃而造成的。例如:假定某个开发人员向内部 UDDI 添加了三个服务。然后，服务管理员可能会将其中两个迁移到生产 UDDI 中。这就产生了孤立服务。服务组件也可能出现类似的情况。

结果：在试图确定注册中心中哪个服务导致无法满足 SLA 时，重复的注册中心将导致控制灾难和运行时混淆。此外，此类重复还会导致性能下降和安全漏洞及遵从性漏洞。此类反模式的另一个结果就是由于重复而会产生计划外成本。

根本原因：缺乏设计时一致性(SOA 控制模型)是导致此反模式的主要原因。具体来说，此问题的核心是服务注册中心所属关系不清楚且没有建立和执行企业级 SOA 参考体系结构。

解决方案：为了避免此反模式，公司必须建立 SOA 控制模型，以定义和采用服务注册中心最佳实践、所属关系以及相关团队间的通信。这将消除重复条目和不正确的接口信息，并最小化包含孤立服务的结果。由于只有一个服务描述源(其中包含关联的 SLA 和策略)，因此还可以消除运行时混淆。使用 SOA 企业级参考体系结构间建立和执行遵从性应是 SOA 控制模型制度化的第一步。

SOA 实现反模式

此类反模式捕获实现服务的最差实践。

R1:反模式名称:通信较多的服务

问题：此反模式描述开发人员通过实现一系列 Web 服务(这些服务彼此需要就一小部分数据进行通信)来实现服务的情况。同一个反模式的另一表现是服务实现最后会进行大量的微型信息通信，而不是采用将数据组合到全面的类似于文档的格式中。

环境：如果组织中的开发人员急于在没有恰当的建模的情况下开始进行实现，这些组织将最终受到此反模式的困扰。在某些情况下，开发人员被要求在没有了解如何从 SOA 获得最大利益的情况下使用 Web 服务替代 API，将通常会导致此反模式。

症状：如果有实现大量过分细粒度服务的需求，则表明应用了此反模式。

结果：性能下降和开发成本增加是此反模式的主要结果。此外，使用者必须进行额外的工作以对这些过分细粒度的服务进行聚合，以实现相关优势和获得如何将这些服务一起使用的知识。

根本原因：由于不知道任何更好的办法，很多开发人员采用的方法就是采用 Web 服务的形式模拟 API 的实现。这与我们在最开始采用面向对象的编程技术时的情况(开发人员使用面向对象的语言来开发过程型的程序)十分相似。另外，急于采用这项新技术，可能会导致所有内容都成为 Web 服务，却不能带来任何好处，而且成本会急剧增加。

解决方案：为了避免此反模式，需要集中精力进行设计重构，以将各个数据片断组合到一个文档中，以消除通信量过多的服务。另外，就 API 和服务之间的区别进行培训(并强调恰当的服务粒度)，也会有用。不过，避免此反模式的最有效办法是定义映射回业务目标的服务。可以通过引入和使用好的服务建模技术来为业务解决方案确定恰当的粗粒度服务，从而完成此工作。这将最小化服务通信过多的行为，因为此行为已在 SOA 中正确的粒度级别得到了标识。应用 Service Litmus Test (SLT) 也可以帮助确定要公开的正确服务级别。SLT 的一个例子是考虑服务是否提供了支持业务流程和目标所需的业务功能单元。

R2:反模式名称:点到点服务

问题：基本问题是开发人员在不考虑使用环境的情况下尝试使用点到点 Web 服务作为集成方法替代中间件。

环境：此模式出现在缺乏长期系统集成远景而强调短期结果的组织中。

症状：此反模式的一个表现是在内部应用程序之间使用 SOAP over HTTP。

结果：由于使用此反模式，点到点集成解决方案将作为企业的事实上的集成模式出现。这将对任何实现恰当 SOA 实现的所有优势的可能带来负面影响。

根本原因：此模式的主要根源是缺乏对总体系统的长期维护和发展的考虑(可能是由于强调短期解决方案而造成的)。在某些情况下，急于在别处使用服务也可能导致此类点到点服务方法使用的增多。

解决方案：为了避免采用此反模式的结果，应该考虑将智能连接器(如服务总线)作为正式集成方法使用。使用服务总线，应用程序可以简单有效地一起工作，以支持业务需求，并同时保持协作系统和应用程序间的松散耦合。

已知的例外情况

有一些例外的情况，在这些情况下此反模式解决方案是可以接受的。例如，为了解决即时的业务问题以及可以使用点到点服务的情况下，就需要采用快速的短期集成方案。不过，这些解决方案有可能会在生产中长时间存在。因此，应用此反模式时应当小心地进行监视，并应当配备相应的控制，以防止长期采用此反模式。

R3:反模式名称:无组件的服务(也称为“逻辑分层已过时”)

问题：用于服务建模的最佳实践将促进已标识的服务与其所属的组件相关联。此反模式带来的问题是，开发人员趋于在没有与所属组件明确关联的情况下直接进行 Web 服务的开发和实现。

环境：此反模式出现在体系结构模式未得到应用或考虑的环境中，例如，分层体系结构模式。缺乏体系结构规则使得环境极易出现此类反模式的应用。

症状：对服务进行检查，将会发现系统可以在不遵循任何体系结构的结构要求就可以直接达到系统的任何部分。在这些情况下，Web 服务是在不考虑任何分层和分离概念的情况下开发的。

结果：最值得注意的结果是服务接口之外非常不灵活，因为模块设计、信息隐藏和逻辑结构原则均未得到遵循。这将导致仍然保留了现有应用程序和软件包的遗留限制，从而可能导致在将来不能进行重新设计。

根本原因：与违反了最佳操作的任何其他情况一样，此反模式的根本原因在于缺乏良好的设计。

解决方案：组件和 SOA 的真正潜能仅在同时具有两者的情况下才能实现。解决的办法是采用由基于组件的灵活应用程序支持的一致服务接口。这将要求开发人员继续利用 J2EE 和常见 EAD 最佳实践及分层模式，将其作为克服此反模式的缺陷的方法。

解决方案示例:理解组件对于 SOA 的价值

服务最好使用组件实现。如果没有组件，服务接口后端就没有灵活性可言，并可能要担心实现的可伸缩性和可移植性。现有应用程序和软件包将保留其遗留限制，这将最大程度降低地提供支持不断变化的业务需求所需的灵活性的能力。组件可使用其松散耦合和重用功能提供支持服务接口所需的可伸缩性和灵活性。

总结

在本文中，我们了解了一些通过观察所得的 SOA 反模式，并介绍了一些影响 SOA 的采用、标识和设计及实现的 SOA 项目。

(责任编辑：铭铭)