“示例不是另一种学习的方法，而是学习的唯一方法。”——阿尔贝特·爱因斯坦
模式和模式语言捕获并正式地将良好设计和基于经验的最佳实践系统化，以供其他人员对其进行重用。它们成功而清楚地表述了常见问题及其解决方案。总的来说，常见概念、描述这些概念的词汇以及将其联系在一起的语言是所有采用这些设计和实践的学科和领域的基础。
Christopher Alexander 关于建筑物和城市设计的研究通常被认为是基于模式的思维最早的成果（请参阅参考资料）。他提出了术语“模式语言”，以此代表他认为人类进行设计的能力和使用语言的能力都是天生的这一信念。
很多学科都在使用模式和模式语言的概念，包括从生理学和流程到项目管理和软件工程等领域。在 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides（经常将他们称为 Gang of Four）的“Design Patterns: Elements of Reusable Object-Oriented Software”一书出版后，软件设计模式得到了广泛的认可和使用。
软件社区目前正使用模式来解决在软件生命周期中遇到的不断重复的问题，包括软件体系结构和设计，以及近来的软件开发流程和拓扑。这些模式全面捕获了一个知识体系，以标识我们对可以实现设计良好的软件解决方案的结构和机制的理解。
模式经常被定义为“泛型化的、命名的问题到解决方案的映射”。它捕获在特定环境中重复出现的问题的成功解决方案。
通常使用与表 1“模式模板”中描述的模板类似的模板来记录软件模式。
表 1. 模式模板
| 内容 | 说明 |
|---|---|
| 名称： | 用于进行标识的名称 |
| 问题： | 在领域中重复出现的问题 |
| 解决方案： | 该问题的最佳实践解决方案 |
| 结果： | 所建议的解决方案的优点和缺点 |
| 示例 | 一些已经应用了所建议的解决方案的示例 |
软件模式提供了一个在架构师和设计人员中捕获知识和经验的机制。它们提供了一种公共语言，可促进对其他地方成功应用的方法的重用，从而为软件项目带来以下方面的好处：风险更低、质量更好且交付时间更短。
而在另一方面，反模式则记录出现错误的情况。对数百个软件开发项目的各种调查勿庸置疑地证明了软件开发会出现错误（实际上经常是这样）。研究表明每六个项目中就有五个会不成功：交付远远超过预期预算、严重滞后或被取消。这就表明可能（至少）值得投入精力研究一下老是失败而很少成功的原因（注意 Bitter Java 的作者 Bruce Tate 在他的 developerWorks 文章中说明了为什么反模式是设计模式的必要和互补的同伴——有关更多信息，请参阅参考资料）。
应该对这些重复失败的软件开发项目或“反解决方案”加以研究，以收集关于出现了什么问题以及为什么会这样的有用知识。很显然，只对错误的原因进行分类并不一定非常有用，而还应研究如何加以避免以及出现时如何恢复。系统化后，这个知识集合可以提供软件模型的有价值的扩展（归类为反模式）。
反模式 使用非常频繁，但主要是问题的无效解决方案。这个术语最初是用于指示设计模式出现了错误。与模式类似，反模式的使用也扩展到了软件开发的各个阶段，并深入到了其他领域中。反模式记录常见的对效率有负面影响的重复解决方案。它们通常捕获重构解决方案描述，说明如何更改反模式，以得到更为稳定的解决方案。反模式通常使用模板进行描述，在其中标识症状、结果、根本原因和可能的解决方案。尽管与模式相比，反模式的研究并不很广泛，相关文档也不多，但软件领域对其中一些具有引人瞩目的反模式（如分析停顿、Blob、意大利面条式代码和“烟囱”系统）已耳熟能详。表 2 提供了一些这些示例的概述，这些示例均摘自 Brown 等的关于反模式的书中（有关更多信息，请参阅参考资料部分）。
表 2. 已知反模式的示例
| 错误类别 | 反模式 | 描述 |
|---|---|---|
| 设计 | Blob | 一个大型类具有太多的属性，且是系统的“核心”所在 |
| 设计 | Poltergeists | 非必要类且抽象过多 |
| 结构 | 意大利面条式代码 | 程序代码没有结构（很多 goto 语句） |
| 结构 | “烟囱”系统 | 应用程序是唯一的也是孤立的 |
| 技术 | Wolf ticket | 声明具有开放性的技术并与标准测试不相符 |
| 技术 | 不断退化模式 | 试图使用最新的版本 |
| 重用 | 剪切与粘贴 | 软件错误被复制 |
| 重用 | Golden hammer | 强制所有内容适应一个选定的工具 |
反模式为什么重要？反模式是用于防止问题的工具，可在问题出现之前对其进行标识，并能提供关于如何防止其发生的知识。通过将错误原因正式地系统化，我们可以更容易对其加以理解。一旦出现问题，反模式可以提供帮助，能说明如何从其进行恢复。
简要总结一下，反模式包括以下元素：
- 关于不能工作的方案的记录
- 常见术语表
- 详细的修复方法
- 环境的描述和备选解决方案
- 可能成为将来的反模式的热门解决方案
图 1 说明了模式和反模式之间的区别。模式从试图解决的问题开始，记录针对此问题的可重复成功解决方案。此解决方案可带来一些好处、相应的结果以及可能会有一些问题。反模式说明对效率具有负面影响的常用的问题解决方案。它描述导致出现问题的原因，并说明如何防止或对解决方案进行修正。
图 1. 模式与反模式（摘自 Brown 等的“AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”）
  |
|
在过去五年中，有大量的文章谈面向服务、SOA，而最近几乎所有的东西都可以面向服务了。但我们所说的服务和面向服务到底指什么？
有很多不同的定义，而这些定义在不断地发生变化，以反映行业和 SOA 实践的成熟。我们将在此给出一些本文中将要使用的基本定义。这些定义在图 2 中得到了反映。
图 2. SOA 的定义
- 首先，什么是服务？服务是业务任务的可重复逻辑表现形式。此处有必要强调的是，我们所谈的是业务流程的一部分，而不是软件或 IT 的一部分。
通过技术实现后，“服务”这一术语则应用到使用外化规范的软件资源（可发现的）。此服务规范可以供服务使用者进行搜索、绑定和调用。服务提供者对服务规范实现进行实现，并向服务使用者交付服务质量要求。服务将由声明性策略进行控制，因此支持可动态重新配置的体系结构样式。
- 第二，什么是面向服务？以我们的服务定义为基础，面向服务是一种将业务作为一组相关联的服务集成的方式。我们谈的仍然不是技术；我们谈论的是一种看待业务及其操作方式的新方法。
- 什么是 SOA？SOA 是一种支持面向服务的体系结构样式。SOA 是一种用于根据需要对资源进行关联的企业级 IT 体系结构。这些资源被表示为与业务一致的服务，这些服务可以参与和包含到价值网、企业或业务线中，以满足业务需求。
- 最后，什么是组合应用程序？它是一组集成的服务。组合应用程序是为了支持业务的各项功能而装配和组合到一起的实际运行的服务。SOA 应用程序的主要结构化元素是服务，而不是子系统、系统或组件。
|
|
SOA 反模式是通过使用以下方法标识的：
- 已发布反模式的调查文献
- 作者在与客户会谈中发现而记录下的反模式
- 通过调查 SOA CoE 和 CoP 成员的经验而得到的反模式
- 已使用的被认可的反模式模板/语言
- 本文中包含的得到了三位作者一致认可的反模式
反模式是使用以下模板/语言进行描述的：
- 名称
可表达反模式的特征的简洁名称
- 问题/错误解决方案
与反模式相关的经常出现的错误或错误解决方案
- 症状
问题的表现或标志
- 结果
应用此反模式的结果
- 根本原因
此项提供反模式的环境，即模式应用不正确而导致问题或解决方案失败的情况
- 建议的解决方案
可以解决问题并确保能带来更多好处的重构解决方案
已标识的反模式分为三类：
- SOA 采用反模式：此类为阻碍或延迟客户和业务的 SOA 采用进程的反模式。讨论的属于此类的反模式有：
- A1. 技术跟风
- A2. 老调重谈
- A3. 大爆炸
- 服务标识和设计反模式：此类反模式是技术先驱在作为 SOA 活动的一部分对服务进行标识和设计时遇到的反模式。讨论的属于此类的反模式有：
- I1. Web 服务 = SOA
- I2. 竖井( Silo) 方法
- I3. 注册中心行为不正常
- 服务实现反模式：此类反模式捕获实现服务的最差实践。很多此类反模式主要关注 Web 服务实现（最常见的 SOA 实现）。在本文中，我们给出的是不关注 Web 服务的 SOA 实现反模式的部分列表，因为对于以 Web 服务为中心的 SOA 实现反模式在 Web 服务专门论坛上已经进行了大量的讨论。讨论的属于此类的反模式有：
- R1.通信较多的服务
- R2.点到点服务
- R3.无组件的服务
随着 SOA 越来越成熟，其应用越来越多，则有希望标识越来越多的反模式。
表 3. 反模式列表
| 类别 ID | 反模式 | 描述 |
|---|---|---|
| 采用-A1 | 技术跟风 | 一种非常值得注意的常见趋势，在此情况下，企业决定采用流行的新技术，而没有仔细考虑此技术是否对业务有所帮助。 |
| 采用-A2 | 老调重谈 | 缺乏对 SOA 和以前的计算范例之间区别的了解，从而使其提出置疑，认为 SOA 不过是同样的旧技术的一个名称而已。结果是，即使采用 SOA 能为业务带来好处，也反对采用它。 |
| 采用-A3 | 大爆炸 | 此反模式也称为“囫囵吞枣”。当将 SOA 视为万能的，而立即对所有企业系统和体系结构进行全面更改时，采用的就是此反模式。这样急于求成地采用 SOA 会导致一些会不公平地归咎于 SOA 的错误。 |
| 标识和设计-I1 | Web 服务 = SOA | 当架构师将 SOA 与 Web 服务划上等号时，他们实际上在冒险，可能会使用不具有合适体系结构的 Web 服务替换现有 API。这样将导致标识很多与业务不一致的服务。 |
| 标识和设计-I2 | 竖井方法 | 在此反模式中，服务是根据独立的应用程序标识的，因此不同的小组可能会使用不同的名称标识同样的服务。因此，不能实现公共服务或服务共享。 |
| 标识和设计-I3 | 注册中心行为不正常 | 重复的服务注册表项，所属关系重复、不清楚，从而由于重复而导致管理灾难和运行时混淆、潜在的性能低下和计划外成本。 |
| 实现-R1 | 通信较多的服务 | 此反模式描述了一个常见错误，开发人员在通过实现很多 Web 服务（这些服务彼此需要就一小部分数据进行通信）而实现服务时，通常可能犯这个错误。这将导致实现大量服务，从而导致性能下降，开发成本增加。 |
| 实现-R2 | 点到点的服务 | 在应用程序间使用 XML 或 SOAP over HTTP 代替点到点 Web 服务的中间件，将导致点到点集成的出现，而成为事实上的集成模式。 |
| 实现-R3 | 无组件的服务 | 不清楚与所属组件关联的情况下就直接进行 Web 服务的开发和实现，将会导致未结构化、不受约束的体系结构（没有严格的分层机制）。这将导致服务接口后端和保留现有应用程序和软件包的遗留限制方面的灵活性低下。 |
|
|
这些是阻碍或延迟客户和业务的 SOA 采用进程的反模式。
A1：反模式名称：技术带宽（另请参阅：Web 服务 = SOA）
- 问题
我们发现，很多公司从 IT 的角度开始着手 SOA 工作，而不是从业务角度看待问题。实现可能从技术角度而言是可行的，有时候也能成功，但由于首先没有考虑业务，因此其对业务的影响可能无法实现。
- 环境
此反模式主要出现在建立了良好的 IT 部门的大型企业中，此部门主要雇佣的是技术人员，决策方面受到技术层面的影响更多。
- 症状
此反模式的常见症状表现为发起人不能清楚地阐释采用 SOA 的价值主张。此外，另一个症状可能表现为缺乏针对 SOA 实现的业务/项目一致性。
- 结果
由于此反模式，IT 成本将会上升，却没有实现任何投资回报 (ROI)。此外，公司可能会失去为 IT 投资组合注入灵活性的机会。
- 根本原因
在大多数情况下，此反模式的根本原因在于，为了赶上通过采用此技术可能实现领先地位的竞争者所宣称的能力，公司因此而承受压力。由于这个原因，公司可能发现开展基于技术的工作来引入 SOA 更为容易，而不会花时间和精力将其与业务需求结合。
- 解决方案
处理此反模式的最佳方法是建立没有浮夸的 SOA 价值主张，可以通过标识和描述特定于客户的难点或业务挑战来实现这一点。此方法可以通过开发用于在业务的支持下恰当地引入技术的路线图来进行互补。
- 解决方案示例：根据没有浮夸的 SOA 价值主张开发 SOA 平台
一家全球汽车租赁公司了解可支持其关键业务动力的 SOA 解决方案的价值主张：
- 可提供一个灵活的业务模型，以提高交付新业务服务的速度和灵活性
- 通过简化流程来降低操作成本，从而使成本下降
- 通过为其客户提供率先推向市场的创新服务来缩短外部业务流程的周期和成本
- 通过允许方便灵活的集成来支持多个交付渠道，从而在整个企业范围内进行集成
- 问题
此反模式描述的情况是这样的：公司置疑 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 与过去的范例转换的不同之处。
- 问题
此反模式可以看作“老调重谈”反模式的对立面。此处的问题在于，支持者将 SOA 视为万能的，而立即对所有企业系统和体系结构进行全面更改。
- 环境
此反模式和“技术跟风”反模式的环境一样。特别在其主要股东具有很强的技术背景，且比对应的业务方面的人员更有影响力的企业中，他们就很可能会采用“囫囵吞枣”的方式，而完全不考虑对业务的影响。
- 症状
如果业务单位对采用 SOA 所带来的更改十分担心，则清楚地表明此采用了此反模式。
- 结果
应用此反模式后，将会出现严重的错误，无法提供 SOA 所承诺的好处（可以从现有体系结构获得回报），从而延迟（甚至消除） SOA 所具有的任何潜在优势。采用此反模式的另一个结果就是可能会将任何交付错误归咎于 SOA，而不是查找问题的根本原因。
- 根本原因
任何企业中的狂热技术支持者都可能是此类反模式的根源所在，特别在这些技术支持者处在可以优先于业务考虑做出 IT 决策。
- 解决方案
为了消除此反模式，一种解决方案是指定一个业务支持路线图，以采用增量的方式逐步采用 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 服务。
- 问题
此反模式带来的问题是标识服务的方式。当根据独立的应用程序（而不是以企业策略为中心）对服务进行标识时，期望 SOA 实现所带来的好处将永远不能实现。
- 环境
此反模式主要出现在根据独立工作的具有塔状结构的功能模型进行组织的企业中。每个功能塔所享有的自治权将导致采用竖井方式进行工作。
- 症状
此反模式的一个症状是不同的小组使用不同的名称对相同的服务进行标识。没有标识公共服务，或未实现服务共享，同样也清楚地表明应用了此反模式。
- 结果
由于采用竖井(silo)方法会导致服务被多次标识和实现，不必要的昂贵开发成本或服务重复使得采用 SOA 所能带来的好处大打折扣。而且，由于使用此反模式，会使不同应用程序的受益人间的重用减少或完全消失。
- 根本原因
在大多数情况下，组织的边界和约束是此反模式的根本原因。在某些企业中，缺乏对“服务公开决策”的有所控制的方法也是根本原因。
- 解决方案
此反模式的解决方案是建立一个控制框架，以确保跨功能塔进行服务标识和通信。另外，还应当进行以标识公共服务为目的的相关工作。这可以通过使用 SOMA 等好的服务建模方法来完成。
- 解决方案示例：标识公共服务
像大多数企业一样，一家大型银行是按照业务塔进行的组织，这些业务塔为不同类型的银行客户提供类似的业务功能。SOMA 用于开发服务模型，以促进业务塔间的重用和了解此类重用机会。从更高的角度来看，在支持业务功能所需的业务服务中，约有 90% 都具有相似性，这是潜在的重用领域。
- 问题
在没有一致的 SOA 控制模型的情况下采用 UDDI 将导致流程和设计的效率低下。特别是重复的注册中心可能导致效率低下，使得性能下降，并可能产生安全和遵从性漏洞。
- 环境
没有注册中心控制协议，但却尝试建立 UDDI 用途的企业将经常遇到此反模式。
- 症状
考虑到 UDDI 是标准而不是产品，如果使用不恰当，可能导致建立重复的服务注册中心和重叠的、不明确的关系。这将表现为不正确的、容易引起误会的服务接口信息，特别在共享服务模型内的组合服务场景的发现操作期间表现得十分明显。尽管注册中心中单个服务接口的描述是正确的，但重复的条目将导致整个服务的发现不正确。而且，缺乏控制模型可能是由于服务在生命周期流程的各个阶段注册，当不具有一对一的所属关系转换时被遗弃而造成的。例如：假定某个开发人员向内部 UDDI 添加了三个服务。然后，服务管理员可能会将其中两个迁移到生产 UDDI 中。这就产生了孤立服务。服务组件也可能出现类似的情况。
- 结果
在试图确定注册中心中哪个服务导致无法满足 SLA 时，重复的注册中心将导致控制灾难和运行时混淆。此外，此类重复还会导致性能下降和安全漏洞及遵从性漏洞。此类反模式的另一个结果就是由于重复而会产生计划外成本。
- 根本原因
缺乏设计时一致性（SOA 控制模型）是导致此反模式的主要原因。具体来说，此问题的核心是服务注册中心所属关系不清楚且没有建立和执行企业级 SOA 参考体系结构。
- 解决方案
为了避免此反模式，公司必须建立 SOA 控制模型，以定义和采用服务注册中心最佳实践、所属关系以及相关团队间的通信。这将消除重复条目和不正确的接口信息，并最小化包含孤立服务的结果。由于只有一个服务描述源（其中包含关联的 SLA 和策略），因此还可以消除运行时混淆。使用 SOA 企业级参考体系结构间建立和执行遵从性应是 SOA 控制模型制度化的第一步。
|
|
此类反模式捕获实现服务的最差实践。
- 问题
此反模式描述开发人员通过实现一系列 Web 服务（这些服务彼此需要就一小部分数据进行通信）来实现服务的情况。同一个反模式的另一表现是服务实现最后会进行大量的微型信息通信，而不是采用将数据组合到全面的类似于文档的格式中。
- 环境
如果组织中的开发人员急于在没有恰当的建模的情况下开始进行实现，这些组织将最终受到此反模式的困扰。在某些情况下，开发人员被要求在没有了解如何从 SOA 获得最大利益的情况下使用 Web 服务替代 API，将通常会导致此反模式。
- 症状
如果有实现大量过分细粒度服务的需求，则表明应用了此反模式。
- 结果
性能下降和开发成本增加是此反模式的主要结果。此外，使用者必须进行额外的工作以对这些过分细粒度的服务进行聚合，以实现相关优势和获得如何将这些服务一起使用的知识。
- 根本原因
由于不知道任何更好的办法，很多开发人员采用的方法就是采用 Web 服务的形式模拟 API 的实现。这与我们在最开始采用面向对象的编程技术时的情况（开发人员使用面向对象的语言来开发过程型的程序）十分相似。另外，急于采用这项新技术，可能会导致所有内容都成为 Web 服务，却不能带来任何好处，而且成本会急剧增加。
- 解决方案
为了避免此反模式，需要集中精力进行设计重构，以将各个数据片断组合到一个文档中，以消除通信量过多的服务。另外，就 API 和服务之间的区别进行培训（并强调恰当的服务粒度），也会有用。不过，避免此反模式的最有效办法是定义映射回业务目标的服务。可以通过引入和使用好的服务建模技术来为业务解决方案确定恰当的粗粒度服务，从而完成此工作。这将最小化服务通信过多的行为，因为此行为已在 SOA 中正确的粒度级别得到了标识。应用 Service Litmus Test (SLT) 也可以帮助确定要公开的正确服务级别。SLT 的一个例子是考虑服务是否提供了支持业务流程和目标所需的业务功能单元。
- 问题
基本问题是开发人员在不考虑使用环境的情况下尝试使用点到点 Web 服务作为集成方法替代中间件。
- 环境
此模式出现在缺乏长期系统集成远景而强调短期结果的组织中。
- 症状
此反模式的一个表现是在内部应用程序之间使用 SOAP over HTTP。
- 结果
由于使用此反模式，点到点集成解决方案将作为企业的事实上的集成模式出现。这将对任何实现恰当 SOA 实现的所有优势的可能带来负面影响。
- 根本原因
此模式的主要根源是缺乏对总体系统的长期维护和发展的考虑（可能是由于强调短期解决方案而造成的）。在某些情况下，急于在别处使用服务也可能导致此类点到点服务方法使用的增多。
- 解决方案
为了避免采用此反模式的结果，应该考虑将智能连接器（如服务总线）作为正式集成方法使用。使用服务总线，应用程序可以简单有效地一起工作，以支持业务需求，并同时保持协作系统和应用程序间的松散耦合。
- 已知的例外情况
有一些例外的情况，在这些情况下此反模式解决方案是可以接受的。例如，为了解决即时的业务问题以及可以使用点到点服务的情况下，就需要采用快速的短期集成方案。不过，这些解决方案有可能会在生产中长时间存在。因此，应用此反模式时应当小心地进行监视，并应当配备相应的控制，以防止长期采用此反模式。
- 问题
用于服务建模的最佳实践将促进已标识的服务与其所属的组件相关联。此反模式带来的问题是，开发人员趋于在没有与所属组件明确关联的情况下直接进行 Web 服务的开发和实现。
- 环境
此反模式出现在体系结构模式未得到应用或考虑的环境中，例如，分层体系结构模式。缺乏体系结构规则使得环境极易出现此类反模式的应用。
- 症状
对服务进行检查，将会发现系统可以在不遵循任何体系结构的结构要求就可以直接达到系统的任何部分。在这些情况下，Web 服务是在不考虑任何分层和分离概念的情况下开发的。
- 结果
最值得注意的结果是服务接口之外非常不灵活，因为模块设计、信息隐藏和逻辑结构原则均未得到遵循。这将导致仍然保留了现有应用程序和软件包的遗留限制，从而可能导致在将来不能进行重新设计。
- 根本原因
与违反了最佳操作的任何其他情况一样，此反模式的根本原因在于缺乏良好的设计。
- 解决方案
组件和 SOA 的真正潜能仅在同时具有两者的情况下才能实现。解决的办法是采用由基于组件的灵活应用程序支持的一致服务接口。这将要求开发人员继续利用 J2EE 和常见 EAD 最佳实践及分层模式，将其作为克服此反模式的缺陷的方法。
- 解决方案示例：理解组件对于 SOA 的价值
服务最好使用组件实现。如果没有组件，服务接口后端就没有灵活性可言，并可能要担心实现的可伸缩性和可移植性。现有应用程序和软件包将保留其遗留限制，这将最大程度降低地提供支持不断变化的业务需求所需的灵活性的能力。组件可使用其松散耦合和重用功能提供支持服务接口所需的可伸缩性和灵活性。
|
|
在本文中，我们了解了一些通过观察所得的 SOA 反模式，并介绍了一些影响 SOA 的采用、标识和设计及实现的 SOA 项目。
作者希望感谢以下同事对本文的贡献：
- JeanPierre Paillet
- Kerrie Holley
- Kyle Brown
- Mike Ellis
- Olaf Zimmermann
- Prathap Gangula
- Rick Robinson
- Rolando Franco
- Sri Ramanathan
扫一扫
246
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
