BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

SOA=集成?

| 作者 Boris Lublinsky 关注 1 他的粉丝 ,译者 胡键 关注 0 他的粉丝 发布于 2009年1月9日. 估计阅读时间: 9 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT