BT

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

REST能够解决系统集成难题吗?

| 作者 Boris Lublinsky 关注 1 他的粉丝 ,译者 吴宇 关注 0 他的粉丝 发布于 2010年6月30日. 估计阅读时间: 7 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

Steve Jones在其最新一篇博文中写到,IT并未成为企业的驱动力,而往往适得其反:

......现代世界大都由计算机来驱动,正是计算机使经济体正常运行,而计算机之间的集成在网络世界中很重要。IT在解决企业方案方面的不成熟以及以技术为中心的方式使得IT完全没有成为引领业务需求的助推器,相反往往恰恰是IT在企业发展过程中拖了后腿。固执地沉醉于为根本不存在的问题寻找最纯粹的解决方案无异于在意淫,而这会对发达经济体造成很大的伤害。

在Jones看来,目前IT所处的境地比五年前更糟糕,主要基于以下事实:即关注于那些新鲜的“酷的”工具和技术,并始终在企业支持中错失良机,使IT越发变成自证预言。

Jones认为在企业架构中最困难的事情之一就是系统集成,这也是有待解决的最复杂的任务之一。尽管如此,解决集成问题仍然是艺术多于科学:

......REST未以任何显著的方式改进企业的这种现状。自REST被炒作以来已经5年有余了,而关于它与WS-*标准给企业带来的益处的比较也有5年了,期间它终究是海市蜃楼子虚乌有。

尽管REST被吹捧为应对所有集成难题的灵丹妙药,但是:

  • 对大型集成,进行大规模编程还是和5年前一样困难。
  • 厂商还得使用他们自己的设备,这就意味着创新更少、挑战更小,而成本更高,因为开源社区的人们花费时间在其中意的项目上,而这些项目往往并不能削减企业预算。

Jones描述的问题是指包括SAP,Oracle和IBM在内的厂商都仍然十分支持Web Services,而主流的开发者却正埋头尝试切换到REST。结果是:

没人把他们真当回事儿。随着所有那些有头脑又有型的玩家们远离REST……我们面临着企业IT内部的知识真空,IT厂商所填补其中的是那些只有他们自己才懂的玩意儿。也就是不断增加私有扩展和软件的数量,各自为阵推行自身的计划。

Jones给出的关于这种情况的一些例子包括:

......Siebel的Web Service技术堆栈包括OASIS规范之前的WS-Security标准,该标准最后一次更新是在2006年......而IBM仍然把MQSI老马车作为“高级ESB”来推动。

他继续指出,除了一些规范和一些较小的改进外,实际上在Web Services领域过去的5年中没有任何创新。反观REST也并未取得多大的成就。他认为问题是两方面的:

  1. 大部分IT人员似乎对其根本一无所知。现在我仍然惊讶于如此之少的IT从业人员明白它到底怎么回事儿,但真正让我吃惊的是REST拥有的推进力如此之少。
  2. “所有事情”都是人工完成的,而且仍然没有标准的方式了解你到底在团队间搞了些啥。

即便如此,REST社区仍在努力改进这种情况,但成效不大,Jones是这样说的:

那些热衷于REST的粉丝们会跳出来高谈阔论他们所做的有关WEB的那些东西有多棒。不管那真的有多棒多精彩,那都不是我的世界,我的世界是面对300个系统,从20多年前就存在的到最近新建的都有,并且我需要让它们一起协同工作起来。即便REST是正确的“架构”方案,其“程序”方案仍旧是错误的,因其会带我们走向深渊。尽管我的世界相对来说有较大的预算支持,但是……你知道吗,如果想赚取真金白银,针对IT市场最富有的部分不是很好吗?

Jones总结道:WS,而不是REST,才是系统集成的方案:

……过去5年是企业IT惨淡的5年。WS-*标准是唯一可行的针对大规模编程的系统到系统的集成机制,但是它正处于停滞状态。REST在前端有一些很酷的玩意儿可以提供给那些只投资最高端卓越人才的人,但是对一般企业环境而言那不是什么好玩意儿。

Jones的这篇博文引发了相当强烈的反响。Joel Potisch认为不应拿WS的方式来解读REST:

我所注意到的唯一REST可能对企业IT所造成的伤害在于人们原本是想开发、部署那些正在运行的、可维护的、分布式系统的,结果却恰恰远离了企业IT并盲从于WS-*标准听命于厂商…...用WS*-标准的方式来使用REST必然会使你倒退5年。REST拥趸们并不会盲从于新鲜酷炫的玩意儿,而是认可REST,恰当地使用它,来消除分布式系统中90%的共通性,使各种各样的问题顿时烟消云散。

Christopher Atkins相信虽然REST是系统集成一个极佳的方法,但是在大多数情况下使用它需要仔细的规划:

......对我而言在企业IT系统集成中运用REST架构形式的主要挑战在于没有任何一个需要集成的系统是事先以REST的理念构建的......至少你需要......提供REST语义,例如,通过超文本定义内部状态机的明确的方法……通过同时定义简单协议以及暴露内部状态机的超媒体来消除集成接口的歧义,这对于网络来说绝对是扭转局面的事。我就是无法相信REST可以有效地应用于大多数IT商店的集成场景中;也不相信无论是TPS系统无FSM可暴露(例如,直接的OLTP/RDBMS应用)还是IT“天才”无法意识到REST的益处。

Dan Creswell认为主要的问题不是技术或者标准的使用,而是人员:

九成以上的IT从业人员并不那么聪明,大部分的甚至算不上好……这才是症结所在,而不在于他们所使用的什么……REST、WS-*标准、数据库、Java等,无论他们使用什么最终产生的结果都是废物。

尽管存在很多吹嘘空谈,我们很难去反对Jones的说法,不可否认的是IT行业目前正处于停滞不前的状态,而集成问题的难度不亚于从前或者被解决的速度并不比5-6年前快。时间能证明我们到底是回过头去使用WS-*标准,还是REST最终追赶上企业计算的步伐。


查看英文原文:Is REST Capable of Solving Systems Integration Issues?

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

REST不是问题的全部 by liu tom

当前有太多的架构,太多的冗余。WS-*给人最大的诟病,就是庞大,在相当大的场合下,她太重了。我一直觉得REST就是为了解决庞大的问题的,简洁而不简单,才是我们追求的目标。

结果却恰恰远离了企业IT,并盲从于WS-*标准听命于厂商…… by 周 柏民

关键在于:“没有任何一个需要集成的系统是事先以REST的理念构建的”
所以:“用WS*-标准的方式来使用REST必然会使你倒退5年。”

我深深感受着我所在的企业IT部门的这种切肤之痛,而其他人却在这些冗余、笨重且部署缓慢的项目架构中越陷越深,竟或是浑然无知、竟或是闭目塞听、竟或是坐井观天……

Re: REST不是问题的全部 by a d

这要从两方面来看。理论与实际。“重”在理论上并无问题,相反,企业集成在理论上只有WS-*唯一的解(reliable massage,end-to-end security,transaction...),别说REST,它只是个style,什么也没有。在实际上,“重”确实很伤人,我认为DSL for web services是很好的办法。

Re: 结果却恰恰远离了企业IT,并盲从于WS-*标准听命于厂商…… by 朱 敏

我认为只有:
1、重建系统;
2、重用数据。
才能从技术上根本解决问题。

您觉得呢?

?? by a d

谁能详细解释下“用WS*-标准的方式来使用REST”这一让我茫然的说法。我怀疑发言者是否花了2个小时研究WS-*。

随着所有那些有头脑又有型的玩家们远离REST……我们面临着企业IT内部的知识真空 by Wong Peter

从上下文来看,这里的REST应该是Web Services。

Jones认为WS-*标准是针对系统集成的唯一可行方案,但是它正处于停滞状态。包括SAP,Oracle和IBM在内的厂商在使用着旧的Web Service标准,不断增加私有扩展和软件的数量,各自为阵推行自身的计划。使得WS-*在过去5年里没有任何创新。而主流的开发者却正埋头尝试切换到REST,却并未取得多大的成就。

但我认为以下才是症结的所在
在企业IT系统集成中运用REST架构形式的主要挑战在于没有任何一个需要集成的系统是事先以REST的理念构建的。
九成以上的IT从业人员并不那么聪明,大部分的甚至算不上好。

允许的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通知我

6 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT