8

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

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

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

现在，我将原来的问题改成这样：公共 UDDI 运动是否已经死去，或者，它还活着吗？

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

4

4 回答 4

6

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

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

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

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

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

但是，将每一次互动都带到一个共同点是不可能的，因为企业是高度异构的。企业仍然围绕着人、人类活动和人类决策。

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

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

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

于 2012-11-11T18:14:04.660 回答
5

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

总结一下：

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

于 2009-10-08T15:53:54.133 回答
2

没死。

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

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

于 2013-12-31T01:02:43.363 回答
1

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

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

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

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

于 2010-10-27T12:13:50.233 回答