SOA= 集成？

据 Jack Vaughn 在 SearchSOA报导，Yefim Natis 在上周 Gartner AADI 峰会上断言“SOA 是集成”。公平的讲，Yefim 并没有在 SOA 和集成之间划上等号：

你仅能在你有控制权的领域中实施 SOA。许多公司正在建立 SOA，但是在整个过程中却没有一个针对所有 IT 的整体架构蓝图。有些人开始试图基于遍布整个组织、公认的互操作协议和传输来建立他们的‘领域 SOA’联邦。

由此可见，虽然使用了‘集成’一词，但 Yefim 实际讨论的是 SOA‘联邦’。在这种情况下，某公司内各组 / 部门可以单独实施各自的 SOA，随后再将这些 SOA 进行集成 / 联邦，最后形成为一个整体。不过，他的言论立刻在 Yahoo! SOA 讨论列表中引发了一场讨论。该讨论以 Michael Poulin 提出以下问题作为开场：

我们怎样才能减缓这种集成 SOA 疯狂行为的蔓延？

Steve Jones并未理会 Michael 的问题，并断言 Natis 所描述的方法类似于 BSB（业务服务总线）/DSB（领域服务总线）：

• 我一直所讲的 BSB/DSB 模型正是 SOA 联邦模型。
• 它是重要的模型和集成的技术。

另一方面，Anne Thomas Manes 的回应关注在 SOA 和集成的不同：

许多组织错误地认为 SOA 是一种集成策略。可它不是。SOA 是关于架构的。要想实现 SOA，你必须重新架构你的系统。你必须剔除朽木。每个组织都有太多的废物——冗余的应用和数据源太多了。SOA 要整理内务。除非减少这些冗余，否则你无法简化你的环境、降低成本和获得敏捷……我认为区分集成性活动和架构性活动非常重要。使用面向服务的中间件实施集成项目是可取的，但接下来你就需重新调整你的预期……面向服务架构是块硬骨头。它具有破坏性。它是一个政治雷区。它涉及盘点应用组合，找出那些可由服务使之退役和代替的冗余应用。但是从来没有人愿意把这些还未解决的问题暴露出来。很多人都信奉一句老话，“如果没有坏，就不必修它”。有太多其他的事情都是以这种方式去做的。

Rob Eamon加入了这场讨论，他的观察是：

虽然我不会说“SOA 本质上就是集成”，但我却会说集成是 SO 方法的一个核心价值。服务有一个或者多个接口。与服务进行交互是通过（并且只能通过）这些接口进行的。服务（和其他诸如服务客户端这样的组件）都存在于独立所有权的领域中。这些特征是集成的核心。SO 要求提前而不是事后才考虑集成。

Miko Matsumura 分享了他在 Software AG 的经验，他写道：

在 Software AG/webMethods 工作的那些人在某种程度上是旧集成世界的肇事者，我们正在找寻真正的联邦需求，但它不单单涉及接口的一个维度。从集成转变到联邦自然是要从接口系统转变到接口部落组织。我们战略上的客户正在找寻管理成本、复杂度、异构、竖井主义、部落主义、咨询主义、供应商主义的方法。而他们正在跨业务流程、模式（schema）、接口、契约、策略、概要 (profiles)、资产、基础设施、VM 等方面做这件事。这是区域力量（以敏捷的名义）快速产生变种的自然模式，同时也是中央力量尽可能（有的时候更甚）巩固、规范化、治理并在其他方面控制区域力量的自然模式。

Michael Poulin 给这场讨论加入了以下内容：

集成和交互的区别何在？或许只有这样才能发现 SOA 是否讲的就是集成。当我们收集服务来编配一条流程时，这是集成还是交互？在我们找到上述问题的答案后，我就会同意“集成策略是在企业层面应用 SO 原则的一个副作用”。

Anne Thomas Manes继续这场讨论，解释了集成和 SOA 的区别：

集成由各个项目驱动，即完成很多小步骤，但是不会考虑“大局”。要是你把 SOI（面向服务的集成）跟强有力的应用程序组合管理工作结合起来，那么我会认为区别不是重点。具体到项目的执行过程都往往一样。

Rob Eamon 的评论再次强调了企业进行 SOA 的重要性：

我同意关于“关注”的观点。关注既定形势的正确层面。关注需要构建 / 暴露的正确服务，而不是把应用绑在一起。不论集成是否是 SOA 的核心内容，我都认为这不会改变。SO 的原则是关于服务定义以及它们跟“外部”世界交互的接口。同样，在我看来，我同意集成不是那个需要付诸关注的事情，但它却是 SOA 相关的。

通过试图分离 SOA 的架构性和实施性关注点，Steve Jones 给这场讨论增加了一个新的维度：

……争论似乎更多的在关注什么是集成，比如流程和编排是否算作是集成，以及更动态的交互模型是否算作是集成。我相信在这个列表上的大多数人都同意 SOA 是一种卓越的治理 / 组织 / 业务 / 思想产物，但是我认为还有直接跟实施相关的 SOA 技术。在本讨论组内正面临的一项挑战就是 SOA 的两个不同世界。

Mike Nibeck引用了 Zapthink 来解释集成和 SOA 的区别：

Zapthink 对于 SOA 和集成有独到的见解。他们是这么说的： - SOA 的一个目标：集成作为服务组合的副产品。

• 遗留集成的一个目标: 为了支持这一目标而去构建服务，并非出于实现特定的业务需求而将系统链接起来

他们主要的观点是：在 SO 架构上，集成仅仅是组合的一个步骤或者部分，它不再被视为截然不同的流程或技术集合。在许多情况下，集成工作意在以某种方式“联结”至少两个不同系统。然而，如果交互点是一个高层业务服务契约，那么单独的集成点就变得不那么相关了。你总会需要跟远程系统交互，并且低层细节依旧跟传统集成工作类似。但是这些工作会存在于一个更大的上下文中，服务模型有望不直接被各个集成工作所影响。

Loraine Lawson 在其博客上，Yahoo 讨论组的讨论之外讨论了这个问题：

要是你还没有留意的话，我得告诉你，这 [SOA 和集成的关系] 可是 SOA 的一个热点问题。争论的内容是：SOA 是一个架构，并且很大程度上是关于把事物捆绑在一起……但事实是：很多公司并不是为了彻底重建而引入 SOA 的。许多公司是因为 SOA 对简化集成实在是太有用了而部署 SOA 的……尽管 David Linthicum 和其他人相信敏捷是 SOA 的 ROI，但是许多公司还是通过集成来实现 SOA 的 ROI……许多 SOA 从业者都通过“否认集成是 SOA 真正的原因”来伤害自己和 SOA。嗨，SOA 为集成而工作。为何不拥抱这个呢？……这样，或许就不再说“不，SOA 不是集成，”并进而鼓吹一个彻底的大翻修，也许 SOA 专家们可以尝试这样说:“当然，太棒了！为集成而部署 SOA”，然后六个月后回到我面前，这样我们就能讨论使用这个方法你还能做些什么。

那么 SOA 和集成到底是什么关系？从架构来看，企业应用集成（EAI）是：

……为了最大化扩展简化和自动化业务流程的可能，同时避免对现有应用程序或数据结构带来彻底改变，而把一个组织内部的应用连接到一起的过程。

而 SOA 则是：

……提倡将向业务看齐的企业服务作为设计、构建、组合企业业务解决方案基本单元的架构风格。

在 SOA 的定义里并没有陈述检查现有 IT 系统的需求。相反，大多数成功的 SOA 实现都是以重用现有应用（通过集成）和在它们之上引入轻薄的一层（服务）原则为基础的。集成和 SOA 的基本区别在于：

尽管 EAI 和 SOA 的目标通常是类似的——用现有应用组合支持企业业务流程——但它们的实现方法却完全不同。EAI 关注于通过集成服务暴露应用功能，有效地把现有应用组合暴露成一个企业业务模型。相反，SOA 关注于隐藏现有应用，取而代之是暴露一系列应用无关的业务服务，凸现关于现有应用组合的一个企业业务模型。

从实现角度看，借助把 Web 服务作为传输解决方案的技术这一当前优势，它们常被视为基于标准的集成解决方案。这让它们相对于 EAI 实现成为了极具吸引力的（并且独立于供应商的）替代品。企业服务总线（ESB）产品的引入让基于 Web 服务、基于标准的集成解决方案变得更受欢迎。

查看英文原文： SOA equals Integration?