据 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?
评论