公共 UDDI 运动是死了还是曾经存在过？

Question

我正在尝试寻找一些公共 UDDI 注册中心进行交互，以达到学习目的。但好像没有可用的。我弹出了以下内容 问题 上 SO 看看是否有人知道仍然托管的任何公共注册表，但没有得到答案。

IBM、Microsoft 和 SAP 公共注册中心是对 UDDI 技术的测试。我引用自 这里: UBR 的主要目标是通过公共实现来证明 UDDI 规范的互操作性和稳健性。这个目标已经实现并且远远超出了。

他们现在继续在其产品中支持 UDDI 规范（因此，不同的公司可以托管其 UBR 供私人使用）。

现在，我将原来的问题改为： 公共 UDDI 运动是死了还是曾经存在过？

你怎么认为？如果您的答案是否定的，您能否提供一个现有公共 UDDI UBR 的示例？

Answer 1

我收到了回复 约翰·桑德斯 关于我最初的问题，我的一位 评论, ，我认为他是对的。

总结一下：

公共 UDDI 运动已经消亡，因为 IBM、Microsoft 和 SAP 公共注册中心 是 UDDI 运动。

Answer 2

公共 UDDI 确实已经消亡，但它却在企业内部的私有注册中心中生存了下来。

UDDI注册表的功能目的是代表有关Web服务的数据和元数据。注册表，无论是在公共网络上使用，还是在组织的内部基础架构中使用，它提供了一种基于标准的机制来对Web服务进行分类，编目和管理，以便可以被其他应用程序发现和消费。

• http://uddi.org/pubs/uddi-tech-wp.pdf

这对于定义和目的来说还不错，不幸的是它是在网络级别应用的。

UDDI 被认为是 Web 服务的“黄页”。如果您想找到提供某种功能的 Web 服务，您可以在 UDDI 中查找。

这个想法是使用标准（通用）机制来实现 SOA 业务组件之间的在线交互。然后，您可以动态查找服务、连接到它们并自动开展业务。在类似服务之间进行选择的决定应该基于 UBR 中发现的元数据（所有这些元数据都位于一个非常复杂的模型中，这阻碍了采用），而无法检查该服务是否确实按照您的预期进行。

但让每一次互动都达到共同点是不可能的，因为业务高度异构。企业仍然以人、人类活动和人类决策为中心。

业务是在合作伙伴之间进行的，只有在经过彻底的分析和谈判后，选择相互开展业务的合作伙伴才能最终达成业务交易并就所有条款和条件达成一致。只有这样他们的基础设施才能连接起来。此时 UDDI 定义确实开始有意义，因为在企业内部 UDDI 允许您：

• 在没有任何客户端失败的情况下重新定位服务；
• 支持负载均衡；
• 通过减少基础设施内的人工干预来提高效率；
• 管理冗余（如果一项服务失败，客户端将搜索提供相同功能的另一项服务）；
• ETC

..但所有这些都在一组有限的预定服务中，这些服务的功能已得到很好的建立和认可。

Answer 3

没有死。

阿帕奇JUDDI有一个公共的快照可在线

http://uddi-jbossoverlord.rhcloud.com/

Answer 4

UDDI确实已经死了。三件事杀死了它：

1. 过于雄心勃勃的复杂性
2. 忽视安全性
3. 管理和收取小额支付的困难仍然困扰着我们

如果 UDDI 代理动态地为我选择服务提供商，我就没有机会对服务的安全性进行任何尽职调查。为了确保我的安全，经纪人会费多大的劲？我建议不要太多。

Web 服务通常在防火墙后面用于 SOA 目的、将应用程序与业务合作伙伴集成以及调用众所周知的 API。对于这些目的来说，UDDI 完全是多余的。大型组织应该拥有其 Web 服务的目录，但这可以像 wiki 页面一样简单。寻找潜在有用的 Web 服务的开发人员需要一段对其功能的描述、一名联系人以及一些 WSDL 和技术文档。对于这些，UDDI 都不是必需的。