分析

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

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

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

来更实际地分析一下：

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

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

比如微信支付API文档、高德地图API文档，现在基本上大企业的服务文档都是图文并茂、目录清晰、相互链接... 因为很多服务的调用流程之复杂，文档不得不这么做。

收费问题：企业是需要盈利的，提供的服务一定会有收费的需求，收费是一件复杂且重要的事，收费之后用户还需要看到服务的使用情况，余额等，这种定制化很强的功能是集成不到UDDI中的。

现在读企业文档有问题很方便就能进行反馈，和客服在线沟通等。这些要是放在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"被抛弃"，这种失败方式也印证了互联网是在往好的方向发展