已知的例外情况

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

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

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

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

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

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

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

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

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

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

    总结

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