公共 UDDI 运动是死了还是，它还活着吗？

Question

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

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

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

现在，我将原来的问题改成这样：公共 UDDI 运动是否已经消亡，或者，它曾经存在过吗？

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

Answer 1

公共 UDDI 确实已经死了，但它设法在企业内部的私有注册中心中存活下来。

UDDI 注册中心的功能目的是表示有关数据和元数据的 网页服务。注册表，用于公共网络或内部 组织的内部基础设施，提供基于标准的分类机制， 目录和管理 Web 服务，以便它们可以被发现和使用 其他应用。

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

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

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

这个想法是使用标准（通用）机制在 SOA 业务组件之间进行在线交互。然后，您可以动态查找服务、连接到它们并自动开展业务。并且在类似服务之间进行选择的决定应该基于在 UBR 中找到的元数据（所有这些都在一个非常复杂的模型中，不鼓励采用），而无法检查服务是否真的做了你期望它做的事情.

但由于业务高度异构，因此不可能将每一次互动都带到一个共同的基础上。企业仍然围绕着人、人类活动和人类决策。

只有在经过彻底的分析和谈判，最终达成商业交易并同意所有条款和条件之前，才选择彼此开展业务的合作伙伴之间开展业务。只有这样他们的基础设施才能连接起来。在这一点上，UDDI 定义开始变得有意义，因为在企业 UDDI 中允许您：

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

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

Answer 2

我收到了John Saunders 对我最初的问题的回答，我的一个comments，我认为他是对的。

总结一下：

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

Answer 3

没有死。

Apache jUDDI 有一个在线可用的公共快照

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

Answer 4

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

1. 过于雄心勃勃的复杂性
2. 忽略安全性
3. 仍然存在管理和收取小额付款的困难

如果 UDDI 代理为我动态选择服务提供商，我将没有机会对服务的安全性进行任何尽职调查。经纪人会花多少麻烦来确保我的安全？不多，我建议。

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