据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 Lhicum和其他人相信敏捷是SOAROI但是许多公司还是通过集成来实现SOAROI……许多SOA从业者都通过“否认集成是SOA真正原因”来伤害自己和SOA嗨SOA为集成而工作为何不拥抱这个呢？……这样或许就不再说“不SOA不是集成”并进而鼓吹个彻底大翻修也许SOA专家们可以尝试这样说:“当然太棒了！为集成而部署SOA”然后 6个月后回到我面前这样我们就能讨论使用这个思路方法你还能做些什么         那么SOA和集成到底是什么关系？从架构来看企业应用集成(EAI)是:

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

        ……提倡将向业务看齐企业服务作为设计、构建、组合企业业务解决方案基本单元架构风格         在SOA定义里并没有陈述检查现有IT系统需求相反大多数成功SOA实现都是以重用现有应用(通过集成)和在它们的上引入轻薄层(服务)原则为基础集成和SOA基本区别在于:

        尽管EAI和SOA目标通常是类似——用现有应用组合支持企业业务流程——但它们实现思路方法却完全区别EAI关注于通过集成服务暴露应用功能有效地把现有应用组合暴露成个企业业务模型相反SOA关注于隐藏现有应用取而代的是暴露系列应用无关业务服务凸现有关现有应用组合个企业业务模型         从实现角度看借助把Web服务作为传输解决方案技术这当前优势它们常被视为基于标准集成解决方案这让它们相对于EAI实现成为了极具吸引力(并且独立于供应商)替代品企业服务总线(ESB)产品引入让基于Web服务、基于标准集成解决方案变得更受欢迎