敏态场景下,自研数据库如何做好技术演进和落地调优?点击预约直播 了解详情
写点什么

十年 SOA:当前的位置和未来的方向

  • 2009 年 12 月 31 日
  • 本文字数:5301 字

    阅读完需:约 17 分钟

很少有人记得微软 BizTalk 服务器曾经是 SOAP、WSDL 和 UDDI 发展的幕后主要推动者之一——它们主要作为一种跟 ebXML 标准竞争的 B2B 技术,“互操作性”一词在当时还未成为时髦用语。那个时候的许多专家和分析师都草率地得出结论

Web 服务是一种新型模型,其本质是基于 Web 的对象的面向对象编程。2000 年 4 月,SOAP1.1 规范朝着这个方向迈出了一步,规范中描述了如何将 XML 格式的消息用于请求和响应。在整个拼图中,UDDI 负责让业务可以发现这些服务。Web 服务描述语言(WSDL)则是描述服务和服务提供者的 XML 词汇。因此 [……]:Web 服务 = SOAP + UDDI + WSDL

十年过去了,我们仍然在纠结于服务或者基于Web 的对象的含义,甚至不去考虑 SOA 曾经对信息系统建设是多么的重要

2009 年,InfoQ 召开了一次虚拟研讨会,与会者都是在这十个年头中大多数时间内体验和实施过 SOA 的企业架构师,我们期望能借这次会议更好地理解 SOA 对于 IT 的意义。

会议的参加者包括 Jeff Andres、来自 MomentumSI 的 Eric Ballou、来自 Saber 的 Dave Hollander 和来自 Carlson Wagonlit Travel 的 William El Kaim。

InfoQ:我们已经花了 10 年来做 SOA。对此,您作何感想?未来十年,SOA 将会是个什么样子?

Eric:哇,我简直无法相信我们从事这个行当已经 10 年了,但这是千真万确。大体来讲,让我感到震惊的是,在厂商和大牛们在花了这么多精 力去教育人们之后,还有这么多的公司认为只要写个 Web 服务就是 SOA 了。那些尚未踏上 SOA 之路的企业将继续为了提升自己的成熟度而奋斗,由于缺乏坚实 的基础,他们的业务和信息服务团队将付出极大的努力:相对于他们那些已经走上 SOA 之路并且已经开窍的竞争对手而言,他们面临的是一个非常高的市场技术入 口。所幸,如 Gartner 指出的,SOA 正进入“启蒙的斜坡”

SOA 的未来将会是:随着厂商将焦点转移到以业务 / 用户为中心的服务和产品上,它开始被打上新方法论和实践的标签。这些标签,诸如 Web3.0、业务驱动 架构和给最终用户授权的用户中心(User Centricity),就是这个方向上的一个极为隐蔽的转变,又或象 Yahoo 给它贴上的:Y!ou。信息服务必须很到位(参见服务架构),才能使授权 到位,SOA/BPM/ 云只是这个方向上的一小步。

Jeff:看看 SOA,其本质非常类似于 80 年代就已经完成的功能设计和构造。回顾从当时到现在我们已经了解的事实,然后再对未来进行预 测,会发现“事件”驱动架构、基于流程的架构这些领域也跟着成熟起来,同时 SOA 也变得更轻量级——因为新语言、介质和设备要求它这样。那么,为什么我会 说是这些领域,以及如何到达这些领域呢?让我们先回过头来了解 SOA 今天所处的位置,以及它可能的方向和进入的领域。在我看来,SOA 目前并没有触及实时 和事件驱动领域,因此,“事件驱动”的语言和构造(中断、分支、汇合)以及类似需求就需要被考虑。这可能会引来争论,即这到底是基于语言的,还是它就是架 构。这暂且不管。其次,SOA 已经明确成为一个招牌,许多大厂商已经烙上它的印记(如 SAP)。然而,他们还遗漏了“流程”的交付。因此,可以肯定,在未 来几年,流程和服务的联姻及融合都需要做得更好。最后,技术总在变化。若干年前,象诸如 iPhones、iPods、Smartphones、 BookReaders 这样的设备都未曾出现。要是我们想在它们身上构建和交付功能,SOA 也需要变得更轻,成为精简版(SOA-lite)!就像敏捷改 变了瀑布或 OOP 的开发实践,SOA 需要针对新浮现的技术进行改变。

William:SOA 将真正的把数据和业务流程当作服务来关注。在今后几年中,SaaS 供应商将关注自动化和可配置的业务流程,这些流程 将导致产生随需应变的世界,驱动企业的业务价值链。SOA 还将用来让诸如安全(认证、联邦、身份认证),日志、监测、分析等这样的 IT 服务变得灵活和可持 续。门户将成为面向服务企业的入口点。

Dave: 谈到 SOA 的未来,这让我想起了一个形容词:淹没的。SOA 将会像客户端 - 服务器曾经的情形一样,无处不在。新的架构方法会引人注目,但更有可能的是,它们都将构建在 SOA 的原则之上。

InfoQ:在 2004 年左右,SOA 治理成了 SOA 一个主要组成部分,您认为它是促进还是阻碍了 SOA?

Jeff:绝对有帮助!但我们要看到任何事物总存在着两面性。首先,治理(取决于它的力度)已经为服务的创建和管理以及生命周期管理提供了 某种控制级别和结构。要是没有治理,混乱就会到处肆虐,我们只会得到大量“闲置(即无法重用)的”服务。它也让开发者、管理层和其他人明白,监督很重要。 在事物的另一面,它也暗示,由于官僚主义,创新会被扼杀。再次强调,这完全取决于治理水平以及它对组织的意义。我相信,赞同治理有积极影响的比率会是 65/35。

William: SOA 管理当然阻碍了 SOA。治理不是仅靠安装个工具或是创建一打 Web 服务就能搞定的。你需要管理组织变更、培训人 员、改变人们的思想。根据公司业务、技术能力和成熟度,差距会很大。然而,值得注意的是,SOA 治理的开源工具已经从纯粹的一个存储库 / 注册库的单独应 用,演变成了一个面向工作流的平台……治理在未来会变得越来越重要,因为对服务使用、结算、访问和集成的控制需要会变得越来越重要。

Eric: 随着企业试图实现 SOA 愿景,他们很快会发现一两的预防要比一斤的治疗好得多。治理正是我们保证工作成熟的手段。SOA 治理的 学习曲线最终会克服人们所说的障碍,“哦,我还没有这么做过,也没有大师可供参考”。因为任何改变,为了支持 SOA 而对公司治理和软件开发生命周期进行修 改都不会那么容易进行——即使公司有老练的 SOA 专家帮助安全地走过这个阶段。这种组织学习曲线对于不怎么能适应变化的公司会伤害 SOA 的成果,但是那些 坚持下来的公司会发现它对 SOA 成果还是有价值的。总的说来,正确地运用 SOA 治理会对 SOA 有帮助,因为它促进了业务的可见性以及项目成果 ROI 的可追 溯性。我曾经一同工作过的很多架构师已经被治理授权,真正贴近业务,并让开发团队的生活变得更加舒心。

Dave:SOA 治理肯定对 SOA 有帮助。优秀的治理不是 SOA 治理,而是将 SOA 治理包含到现有和可能需要增强的治理进程。

InfoQ:服务治理常被吹捧成让业务 /IT 更好对齐的一种方法。您如何看待服务治理中 **** 业务的参与?

Jeff:因为刚通过 ITIL 考试,我会对这一概念和服务支持保持警觉,因为从 IT 角度看,它会被滥用和过度利用。然而,至于 SOA 服务治 理,我相信在开发对彼此都有价值的组件时,它为业务和 IT“合二为一”提供了机会。还没有其他情况(好吧,业务流程中可能有)能让 IT 和业务一起合作,而 双方彼此互利。通常,IT 去找业务的目的只是为了理解需求,接着他们就会开始试验,开发解决方案。在服务治理中,他们实际有机会在一个开放的论坛中从对方 的角度进行讨论,抛开“老子天下第一”的念头。这时,业务可以了解一些 IT 的运作,而 IT 则赢得了业务的援助,以及对他们目前所从事的事情的支持。

William:业务不会对服务治理感兴趣,除非你能证明它能给公司带来效益或能加快推向市场的时间。截至到今天,对齐并不存在。业务的快 速发展和它的需求让 IT 现在就跟它对齐不太可能。当前的 IT 流程和技术还不够成熟。这就是我们为什么要就地改变 IT 范式的原因。业务制定的规范应该被重 用,以业务的形式创建出软件。这是模式驱动的方式。新语言和平台也能进一步的加快这一进程。我们唯一不能加快的变量就是人。

Eric:我在上一个问题中曾经提到,SOA 治理的工作真的能让架构师更接近业务。这种亲密性为业务所有者在决策制订过程中培育出了一种更 好的控制感,通过架构师交付实际所需要的一种更好的能力。治理成功的手段是在业务或架构师分别代表自己提出新想法和新需求时,将两者在一系列快速“自然 的”公司运营步骤中拉到一起,然后将验证 / 审批作为交付的保证。尽管这听起来很简单并且‘容易’,但是要实现这样的沟通和流程级别,要求公司大量的自我评 价和批判指导。我还没有在市面上看到有多少成熟度提供在该领域下实做的指导,因此,业务所有者仍然会因为发现他们所察觉的应该属于信息服务的内部事务而感 到沮丧。

Dave:这种参与至关重要,另一方面,服务和 SOA 仍会继续节省成本和提高效率。当然,在我们跟业务打交道时,还是不要明确点出服务和 SOA,但是它们必须驱动系统提供价值的方式。

InfoQ:业界有很多关于“重用”的争论,您认为重用在行业内取得成功了么?

Jeff:“圣杯”是重用。怎样才能让构建和制造项目更有效和高效呢?当技术人员能够通过 SOA 的手段在此基础上交付的时候,价值是巨大 的!然而,重用通常不会马上被发现,在部署多年后才能开始看到结果。此外,要让此发生还得要有好的“架构师”和“工程师”。顶级管理层时常期望在 18 月内 就看到结果,不幸的是结果通常不会那么快就自动现身。服务治理能帮点忙,但这需要好的领导,以及从组织(文化)到真正“采用”SOA 的大宗买进。前面说 过,倘若 SOA 和重用只是耍耍嘴皮子,那么它们注定要失败。不管治理是否有帮助,因为它不会在一个“积极的”状态下进行考虑或具有价值提供能力。

William: 在讨论重用时,说明其困难程度的最好例子就是 Portlet。在 Portal 中,我们要构建多个 Portlet。但是大 多数 Portlet 在 Portal 首页中只会使用一次。这里,并未发生重用,但是 Portlet 必须具有可移植性。我想说的是,重用越来越不重要了。真正 重要的是在企业中创建可持续的资产。这些资产是公司的知识产权,具有内在价值。

Eric:由于不止一个,你需要澄清这里讨论的是哪个“重用”。总的来讲——每个企业都关注用尽可能有效的方式来使用他们的资源。然而,由 于业务和 IT 都不清楚他们拥有的哪些属于 IT 资产,这严重阻碍公司最大化重用的好处,使重用的成功故事成为空白。服务治理已经强调了可见性的需求,并造就 了了解在用 IT 资产、使用人、有意使用者,以及未来使用存在的障碍等需求。在回答可见性问题时,存在有很多风格和技术使用,但是成功故事已经大大增加了, 不仅仅是重用,而且是以一种可理解、可度量的方式将资产度量指标反映到业务上。

Dave:我不确定。我们避免将重用作为一个主要卖点,因为它太难衡量和量化了。

InfoQ:您能否介绍一下 SOA 或者服务治理组织成功的元素?

Jeff:拥抱这一变化的上层领导的大力支持和认可。愿意抓住这次机会进入该领域成为变革推动者的工作人员!开发流程的修改,类似面向对象 开发 VS 瀑布模型:服务设计上的前期工作对于有意义并有机会在将来重用的服务的界定和构架至关重要。随着时间日渐“成熟”的治理模型;设置一个它要达到的认识水 平,完成之后再改变,然后再来执行。不要一开始就搞专制,否则你不会有任何追随者。

William:我们需要:

  • 关于现有服务的一个清晰服务分类,并将其在注册库中实现,以始终提供准确的服务目录;
  • 服务的任何配置都通过保存在具体存储库中的元数据来完成;
  • 管理服务全生命周期(设计时、运行时、终结)和发布;
  • 每个服务都有针对其消费者的 SLA 契约,并有工具可以对其进行度量;
  • 公司内有一个集成能力中心来管理 SOA,并有相关的专门预算。

Eric:我在公司中看到的成功元素首先是拥有灵活思维和能够适应流程变化的人。他们大多数都拥有技术,这让他们能够自动治理流程并能得到 IT 资产的联合视图——不 仅限于 SOA 资产,而是整个企业的视图——人、流程和技术 / 服务。最大的成功因素——具备强大业务本领以及与最高层及高级经理有政治关系的拥护者。

Dave:我会建议将它包含到其他 IT 和开发治理中,并且建立一套统一的标准来进行考量。

InfoQ:要是您能改变 SOA 中一个事物,您会选择哪一个?

Jeff:标准……我个人没有太密切关注过这个领域,但是我能确认我们需要将采用过程变得简单。此外,这跟其他领域没什么不同,我们需要建 立一个路线图,明确指出我们要前进的方向。不幸的是,我认为 SOA 标准是“老鼠洞”。对不起…如果我参与了委员会,可能我不会这么想——不幸的是,我不 是,因此我还是会这么看。

技术也是一个它可以发挥作用的领域。没人会喜欢在微软和 Java 之间来一场战争的想法。因而,折磨世界的不是观点统一而是分歧。尽管我知道有好几种方法能让它们一起工作,但没有必要将世界统一成一个 SOA。

William:我会说服大家采用契约优先的方法并定义描述服务 SLA 的唯一标准。我很想有一个 Web 服务管理平台的开源实现。

Eri:我们能否更早地把它创造出来?;) 说实话,要是能改变 SOA 中的一个事物,我会选择一开始就击中靶心。企业承受的任何改变都会导致 公司的成本。尽管 SOA 现在 10 岁了,对于大多数信息服务和企业而言,他们仍然将 SOA 看成开销而不是节约。MomentumSI 已经反复给客户证明了这 一点。

Dave: 我会不惜代价阻止市场炒作和夸大其词对 SOA 品牌的消弱。

你已经看到的,即便 10 年过后,SOA 的某些方法和预期收益方面还是很容易产生不同观点。你对这些问题的答案又是什么呢?

查看英文原文: A Decade of SOA: Where are we, Where are we Going?


感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2009 年 12 月 31 日 00:053236
用户头像

发布了 255 篇内容, 共 50.7 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
  • SOA= 集成?

    SOA的存在已经有些年头了,但就“SOA到底是什么”这个问题而言,在SOA从业者中依旧未形成一个统一意见。最近在Gartner AADI峰会上由Yefim Natis发表的演讲引发了一场关于SOA/集成之间关系/区别的无尽争论。

  • SCA 访谈

    自从SCA于2005年发布面世以来,它已成为许多热门讨论的主题。在2007年,这些规范被捐献给OASIS并且创建了OpenCSA论坛。最近,这些OpenCSA成员举行了第一次全体大会,同时举行了首次标准工作组的面对面会议。我们有机会就SCA、标准化和应用这些话题采访部分与会者。

  • 2011 SOA 虚拟研讨会

    在本次虚拟研讨会上,SOA专家们分享了他们对于SOA现状以及未来趋势的观点及看法。

  • 争论:SOA 已死?

    Burton Group的Anne Thomas Manes为SOA写了一篇讣告,宣布SOA于2009年元旦遭遇死亡,经济衰退的灾难性影响彻底摧毁了它。InfoQ收集了业界对此的各种反应。

  • 第 194 讲 | 刘俊强:2019 年云计算趋势对技术人员的影响

    学会有条理的梳理工作、对数据安全敏感、持续学习等良好的工作习惯,相信面对云计算带来的挑战也将游刃有余。

    2019 年 3 月 27 日

  • 《SOA 治理最佳实践》用户调查

    这次调查的一个关键收获是:在很大程度上,SOA是真实的而且正在发生。91%的反馈者认为治理非常或较为重要。调查还对最流行的SOA标准进行了抽样调查。InfoQ对Software AG的VP和副CTOMiko Matsumura进行了采访,请他谈谈对这次调查反馈的看法。

  • 我们高呼的下一代微服务 Service Mesh 到底是什么?

    考虑到有的同学之前可能没有接触过 Service Mesh 这个概念,所以这里我先对 Service Mesh 做一个简单介绍,作为后续内容的基础。

    2018 年 3 月 17 日

  • 移动 SOA 的门柱

    在过去几年内,业界试图多次定义和重定义SOA,整个过程中往往自相矛盾。到底是SOA真的发生了大变化,还是这一切的发生只是由于仍然缺乏对SOA本质的理解?

  • 你的架构应该关注 SOA,还是 BPM?

    SOA在时髦术语标签云里面风光无限的同时,BPM的名气正变得越来越响。当组织逐渐明白想从IT投资中获得收益需要驯服组织间各种各样的流程时,BPM在IT圈内圈外正得到重视,认同和关注。对你的构架来说,哪一个更重要呢?

  • SOA 与云计算有多大关联?

    在最近的ebizQ的云QCamp大会上有一个分会场讨论了云计算的当前状态以及它与SOA之间的关系等话题。与会成员达成的共识是云能够加强SOA所承诺的那些优势,并促使其为业务提供更坚实的基础。

  • SOA 吸纳 WOA?

    Dion Hinchcliffe讲述了为何SOA与WOA是互补而不是竞争的关系。根据Dion的说法,采用一种基于WOA的方法,不仅给开发者降低了门槛,而且较传统SOA方法更具优势。Dion认为WOA并不是REST的同义词,反WOA的争论主要归咎于SOA供应商和专家们“保护自己的地盘”。

  • 遗留系统要想加入 SOA 需要服务么?

    Joe McKendrick在对Oracle印度公司Oracle Fusion Middleware副经理Shailender Kumar的一次采访中问到SOA能否用在无服务的应用中。

  • 是否该重新衡量 SOA 产品了?

    Gartner分析师Roy Schulte是SOA方面的专家,他参与编写了1996年那份为业界引入SOA这一术语的Gartner报告。前不久Susan Hall对他进行了采访。此次采访试图回答这样一个问题,即是否应该重新调整对SOA的期待了?

  • 桌面开发篇:回顾与总结

    学业务架构最好的方式是“做中学”。做是最重要的,然后要有做后的反思,去思考并完善自己的理论体系。

    2019 年 8 月 16 日

  • 可扩展架构案例(一):电商平台架构是如何演变的?

    这一讲,我会针对最近十几年电商平台的架构变化过程,具体说明为了支持业务的快速发展,架构是如何一步步演进的。

    2020 年 2 月 28 日

  • 大咖对话 | 童剑:用合伙人管理结构打造完美团队

    白山推崇“合伙人管理结构”理念,创立之初就组建了一个13人规模的合伙人团队,其理念不是打造巨轮而是编成联合舰队,每个合伙人都是舰船的掌舵人。

    2018 年 8 月 10 日

  • SOA 已死—现状依旧?

    Anne Thomas Manes在博客中引证软件开支和SOA软件基础设施销售额的下降,以及专家们声讨SOA的经济性以及实施方法,继续证明SOA已死。

  • 面向服务架构的技术不可知方法:回归 SOA 的本质?

    SOA常常是按照技术工具和软件解决方案的方式被理解。Dan North认为这会妨碍架构师关注问题的本质:核心业务过程的彻底映射和建模。他展示了如何以“技术不可知”的方式去设计SOA,这样业务就可在识别SOA需求中扮演一个重要的角色,而不会受限于技术决定。

  • 7 种微服务反模式

    在这篇文章里,Asurion首席架构师Vijay Algarasan讨论了他和他的同事如何在各种活动中遇到了微服务以及他们汲取的经验教训。这使他们构建出了一系列的反模式和一些相关模式。Vijay认为,这些内容适合所有的微服务实践者。

  • 从软件工程的角度看微服务、云计算、人工智能这些新技术

    技术服务于架构设计,架构设计服务于业务,业务服务于商业。

    2019 年 6 月 15 日

发现更多内容

缘起短视频APP系统开发介绍

☕️【Java技术之旅】【ConcurrentHashMap】深入浅出核心源码分析(JDK1.8版本)

洛神の殇

Java 源码分析 ConcurrentHashMap 6月日更

百度关于微前端架构EMP的探索:落地生产可用的微前端架构

百度开发者中心

百度 大前端

Redis入门七:分布式锁

打工人!

redis 分布式锁 redis分布式锁

前几年写的自己团队管理内容,如果你想做研发管理,可以看一下

安宇|Way

管理 考核 团队 文化 价值观

Tubacle挖矿系统APP开发搭建

企业资产数据大屏,打破固有管理思维僵局,杜绝资产无效流失

一只数据鲸鱼

数据可视化 资产管理 金融资产 金融大屏

BTQQ挖矿/比特全球/BT全球系统APP开发简介

积分商城设计思考

林一

幂等性 设计实践 重试 积分商城

工程师必知的代码重构指南

百度开发者中心

代码重构

分布式图计算引擎

6979阿强

分布式计算 图计算

覆盖80%以上Java性能调优场景,三年开发经验以下慎入

Java架构师迁哥

腾云视界APP开发|腾云视界软件系统开发

MongoDB磁盘清理那些事儿

循环智能

mongodb 集群 主从 GridFS 磁盘清理

革故鼎新:企业数字化转型繁荣互联网生态建设,驱动ICT设施升级

科技热闻

看CarbonData如何用四招助力Apache Spark

华为云开发者联盟

spark Apache Spark ACID CarbonData 分布式集群计算框架

INS视频怎么保存 (2021最新图文教程)

资源君

方法 经验分享 教程 资源分享 Instagram

阿凡达公链AC系统APP开发

Ipfs矿机收入如何?IPFS矿机一天收益多少?

区块链 数字货币 IPFS

区块链的正确应用方式与前景

CECBC

Redis入门六:集群

打工人!

redis 缓存穿透 缓存击穿 缓存雪崩 redis集群

在C++中,你真的会用new吗?

华为云开发者联盟

c++ 内存 new new operator operator new

蜜蜂圈软件开发|蜜蜂圈APP系统开发

火艺极速版短视频系统APP开发搭建

DOLLAR CAT/Dcat币挖矿系统开发

中国大学MOOC Android 客户端开发提效之页面信息

有道技术团队

android 服务端 客户端

你不知道的 Linux 使用技巧

学神来啦

Bi Token质押挖矿软件系统开发方案

「腾讯面试题」兔子试毒

Java架构师迁哥

大佬讲【暴力破解】漏洞的原理、利用和防范

网络安全学海

网络安全 安全 信息安全 漏洞 漏洞修复

CloudQuery 使用教程之 No.3 数据查询(中)

CloudQuery社区

云计算 dba 开发运维 数据库管控工具 国产数据控

十年SOA:当前的位置和未来的方向_SOA_Jean-Jacques Dubray_InfoQ精选文章