这些是阻碍或延迟客户和业务的 SOA 采用进程的反模式。

A1:反模式名称:技术带宽(另请参阅:Web 服务 = SOA)

问题：我们发现，很多公司从 IT 的角度开始着手 SOA 工作，而不是从业务角度看待问题。实现可能从技术角度而言是可行的，有时候也能成功，但由于首先没有考虑业务，因此其对业务的影响可能无法实现。

环境：此反模式主要出现在建立了良好的 IT 部门的大型企业中，此部门主要雇佣的是技术人员，决策方面受到技术层面的影响更多。

症状：此反模式的常见症状表现为发起人不能清楚地阐释采用 SOA 的价值主张。此外，另一个症状可能表现为缺乏针对 SOA 实现的业务/项目一致性。

结果：由于此反模式，IT 成本将会上升，却没有实现任何投资回报 (ROI)。此外，公司可能会失去为 IT 投资组合注入灵活性的机会。

根本原因：在大多数情况下，此反模式的根本原因在于，为了赶上通过采用此技术可能实现领先地位的竞争者所宣称的能力，公司因此而承受压力。由于这个原因，公司可能发现开展基于技术的工作来引入 SOA 更为容易，而不会花时间和精力将其与业务需求结合。

解决方案：处理此反模式的最佳方法是建立没有浮夸的 SOA 价值主张，可以通过标识和描述特定于客户的难点或业务挑战来实现这一点。此方法可以通过开发用于在业务的支持下恰当地引入技术的路线图来进行互补。

解决方案示例:根据没有浮夸的 SOA 价值主张开发 SOA 平台

一家全球汽车租赁公司了解可支持其关键业务动力的 SOA 解决方案的价值主张:

• 可提供一个灵活的业务模型，以提高交付新业务服务的速度和灵活性
• 通过简化流程来降低操作成本，从而使成本下降
• 通过为其客户提供率先推向市场的创新服务来缩短外部业务流程的周期和成本
• 通过允许方便灵活的集成来支持多个交付渠道，从而在整个企业范围内进行集成

A2:反模式名称:老调重谈

问题：此反模式描述的情况是这样的:公司置疑 SOA 不过是相同的旧技术的一个名称而已，SOA 并不能提供任何它们尚未提供的新功能。从表面上来看，似乎可能是这样，但过去已经提供的功能和通过恰当实现 SOA 可以提供的功能相比，Web 服务和 XML(以及其他相关的标准)的出现则是一个重大的区别。

环境：这个反模式主要出现在那些习惯其已经长期使用的技术，而不愿意引入或考虑进行改变的 IT 专业人员身上。当 IT 部门经历了大费周折的技术转换后，或新技术并不能实现最初的承诺时，也可能出现此反模式。

症状：最明显的症状就是公司中的一些技术管理人员强烈反对将 SOA 作为处理合法业务问题的正式方法。反对可表现为强烈而明显的争辩，反对采用 SOA;或者可以表现为隐含的被动的方式，在讨论业务问题的解决方案时完全忽略 SOA。

结果：此反模式很可能会导致缺乏 SOA 支持，而最终会导致失去实现将支持业务难点的 SOA 价值主张的机会。

根本原因：尽管 SOA 构建于其他计算范例(例如，面向对象和基于组件的开发)所引入和支持的相同原则之上，很多有经验的 IT 团队仍然不能真正理解 SOA 与这些其他计算范例之间的区别。缺乏理解是此反模式的一个基本根源。另一个根本原因则是 IT 团队在实现太多的“范例转换”方面的经验不丰富(而不愿尝试新的技术)的直接结果。

解决方案：处理此反模式的一个方法就是强调 SOA 与早期解决方案的不同之处。例如，应对 API 和服务之间的区别加以讨论，应对开发标准依赖性及其区别属性进行说明。另一个主要不同点在于作为 SOA 主要组件的企业服务总线 (ESB) 的出现。ESV 提供的工具(如传输服务、中介服务和事件服务)就是一些通过采用 SOA 所提供的新服务的例子。不过，最有效的解决方案则是提供一些成功的示例，以突出区别和演示实现 SOA 解决方案的成功案例和可行性。

解决方案示例：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 服务。