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服务、基于标准的集成解决方案变得更受欢迎。