【SOAP-WebService系列】UDDI退出的原因分析

·  阅读 304

这是我参与8月更文挑战的第25天,活动详情查看:8月更文挑战


分析

UDDI的落幕我总结为两个原因

==① 定制化不强== UDDI注册中心需要兼顾所有的web服务,这必然就造成了他定制化不强的特点

定制化不强,体现在两个方面:功能、UI 功能:就像有的人,在CSDN、博客园等写了一段时间的文章,慢慢地发现公共写作平台满足不了自己的某些需求。但是平台也不能只为你考虑,每个人的需求都是不一样的,还有的人就想简单一些,用不上别人需求的东西 UI:涉及到UI,一是众口难调,二是艺术:五颜六色的黑?五彩缤纷的白?这些事,还是交给企业来做吧,公共平台休想统一艺术

来更实际地分析一下:

从使用者的角度来看,在UDDI上能得到的一个服务的信息是非常有限的 UDDI的重点是发布、搜索、调用服务。它解决不了:哪些服务更好,是不是更该推荐优质服务,怎么更好地展示服务更多的信息等,这些问题非常不好解决(定制化不强是所有一对多平台的通病),而且UDDI还是免费的,就更不想去解决了

从提供商的角度来看也同样,在UDDI上能展现的信息是有限的,满足不了定制化需求 web服务发展之迅速,企业提供服务需要展示的信息几乎必须要定制化。举几个例子

  1. 比如微信支付API文档高德地图API文档,现在基本上大企业的服务文档都是图文并茂、目录清晰、相互链接... 因为很多服务的调用流程之复杂,文档不得不这么做。
  2. 收费问题:企业是需要盈利的,提供的服务一定会有收费的需求,收费是一件复杂且重要的事,收费之后用户还需要看到服务的使用情况,余额等,这种定制化很强的功能是集成不到UDDI中的。
  3. 现在读企业文档有问题很方便就能进行反馈,和客服在线沟通等。这些要是放在UDDI要怎么展示怎么进行? 在这里插入图片描述

可能有的人也会这么想:定制化的东西就放在企业自己的网站上好了 那么结果就是,使用者和提供者需要同时关注企业网站和UDDI两个平台,这种体验显然不好

==② REST的出现==

上述分析的只是UDDI的定制化不强,平台不好用是一个内部因素。 还有一个非常重要的外部因素:REST。REST催化了UDDI的凋落,使得UDDI无力回天

和REST产生直接冲突的是SOAP,UDDI是为 SOAP-WebServices设计的 REST和SOAP的"斗争"就发生在2000-2005年间,REST用5-6年的时间发展起来,将SOAP变成了时代产物

延申阅读: 杂谈:REST发展初期的坎坷之路(技术环境分析、REST vs SOAP) # REST vs SOAP

REST直接使用HTTP来作为通信协议,并充分利用HTTP自身的特性,RESTfulAPI 使用语义化的URL+HTTP Mothed操作资源,结构清晰、十分简洁。这使得服务调用不再需要SOAP这种复杂的协议、复杂的调用方式,不再需要通过UDDI来发布WSDL文件。 SOAP迅速被REST取代,使得为SOAP服务设计的UDDI也变得毫无用处,这也是IBM和Microsoft在2006年将UDDI关闭的重要因素

UDDI是有积极意义的吗?

或许我们不能忽略UDDI提出时的初衷。如果把重点放在 "UDDI是一项运动" 来看,或许可以找到一些乐观的答案

本文开头有提到:

UDDI 最初是于2000年9月由IBM、Microsoft和Ariba共同提出的一个项目,用他们的话说,这是一个“想要推动Internet计算的相关事务的联合行动”

他们想推动的事务是什么呢?

(大胆猜测一下) 互联网在2000年左右开始进入井喷式发展,各种web服务层出不穷,此时如果有一种方式能够推动这些web服务的标准化、促进web服务之间的联系,是不是对互联网健康标准发展的一种支撑?

而UDDI就是这种支撑。尽管这个方案在现在看来并不怎么样,实际上也没有好好发展多少年。但是它对web服务的标准化起到了良好的引导作用。 也是由于web服务的快速发展,使得UDDI"被抛弃",这种失败方式也印证了互联网是在往好的方向发展

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改