解决方案示例：SOA 培训

    对业务部门和 IT 部门进行培训，阐释 SOA 的概念、其价值主张，并说明其在提供支持业务所需的 IT 灵活性方面的好处。促进对 Web 服务和 XML 标准及实现 SOA 中的新兴标准的重要性的理解，这些内容正是 SOA 与过去的范例转换的不同之处。

    A3:反模式名称:大爆炸(也称为:囫囵吞枣)

    问题：此反模式可以看作“老调重谈”反模式的对立面。此处的问题在于，支持者将 SOA 视为功能较多的，而立即对所有企业系统和体系结构进行全面更改。

    环境：此反模式和“技术跟风”反模式的环境一样。特别在其主要股东具有很强的技术背景，且比对应的业务方面的人员更有影响力的企业中，他们就很可能会采用“囫囵吞枣”的方式，而完全不考虑对业务的影响。

    症状：如果业务单位对采用 SOA 所带来的更改十分担心，则清楚地表明此采用了此反模式。

    结果：应用此反模式后，将会出现严重的错误，无法提供 SOA 所承诺的好处(可以从现有体系结构获得回报)，从而延迟(甚至消除) SOA 所具有的任何潜在优势。采用此反模式的另一个结果就是可能会将任何交付错误归咎于 SOA，而不是查找问题的根本原因。

    根本原因：任何企业中的狂热技术支持者都可能是此类反模式的根源所在，特别在这些技术支持者处在可以优先于业务考虑做出 IT 决策。

    解决方案：为了消除此反模式，一种解决方案是指定一个业务支持路线图，以采用增量的方式逐步采用 SOA。不要采用试图通过使用 SOA 进行全面更改的方式解决所有企业问题，更好的做法是首先构建一个试验性业务案例，当试用成功后，则使用路线图选择下一个可能从 SOA 获益的目标业务领域。如果可为组织中那些负责 SOA 推广的人员提供 SOA 入门培训，也将十分有用。

    解决方案示例:开发实现 SOA 的路线图。

    一家大型银行在考虑到其业务策略后，确定其正确的体系结构方向是 SOA 解决方案，此解决方案可以帮助其实现其业务目标。该银行首先对其服务集成方面的成熟度水平进行了评估。然后，开发了路线图来帮助银行以增量的方式迁移到 SOA 环境，以在继续提供必要的业务功能的同时最小化风险。该银行选择了一个试验性项目来验证 SOA 体系结构样式，并找出在迁移到 SOA 范例过程中可能出现的任何技术和组织问题。

    SOA 标识和设计反模式:

    此类反模式是技术先驱在作为 SOA 活动的一部分对服务进行标识和设计时遇到的反模式。

    I1:反模式名称:Web 服务 = SOA(也称为服务增殖综合症)

    问题：对于很多人而言，SOA 不过是 Web 服务的另一个名称而已。尽管实现 Web 服务是采用 SOA 过程中的一个合理的入口点，但企业不应将 Web 服务和 SOA 划上等号。

    环境：目前的大部分生产 Web 服务系统都不是 SOA。它们只是通过 SOAP 或结构良好的集成体系结构的远程过程调用或点到点消息传递而已。各种组织发现，通过仅实现 Web 服务而宣称迁移到 SOA 的方式更为简单。

    症状：在不采用恰当的体系结构的情况下使用 Web 服务替代 API，并实现不与业务一致的服务是此反模式的明显症状。

    结果：Web 服务的增殖是应用此反模式的直接结果。这个结果是将任何接口都作为 Web 服务实现，而不管这些服务是否是 SOA 价值主张的一部分而造成的。另外，最终的系统也可能没有反映服务请求方要求的接口。

    根本原因：此反模式的根本原因有两种。首先是操之过急，意在走捷径，以快速廉价的方式开展 SOA 方面的工作。其次是缺乏对 SOA 和 Web 服务的区别的认识，不理解对好的服务建模技术的需求。

    解决方案：处理此反模式的一个方法是制定可行的 SOA 转换计划，此计划要求组织对其 SOA 价值主张进行定义。实现 SOA 价值主张要求同时使用 SOA 和 Web 服务。这将要求对 SOA 和 Web 服务的区别进行培训，并应用好的服务建模方法，如面向服务的建模和体系结构(Service-Oriented Modeling and Architecture，SOMA)。

    解决方案示例:应用服务建模以标识粗粒度的服务和将 Web 服务作为 SOA 解决方案的实现技术加以利用

    引入和采用良好的服务建模技术来确定供业务解决方案使用的恰当粗粒度服务，并利用 Web 服务来实现 SOA 解决方案。恰当服务粒度水平将帮助尽可能减少过分细粒度服务的增加。实现 SOA 价值主张要求同时使用 SOA 和 Web 服务。