公共UDDI运动是死了还是活着?

时间:2009-10-06 11:32:12

标签: discovery uddi

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

IBM,Microsoft和SAP公共注册管理机构是对UDDI技术的测试。我引用here UBR的主要目标是通过公共实现来证明UDDI规范的互操作性和健壮性。达到并远远超过了这个目标。

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

现在,我正在改变我的原始问题:公共UDDI运动是否已经死亡,或者它是否还活着?

你怎么看?如果您的答案为否,您能否提供现有公共UDDI UBR的示例?

4 个答案:

答案 0 :(得分:6)

公共UDDI确实已经死了,但它能够在企业内的私有注册管理机构中生存下来。

  

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

     

这对于定义和目的来说并不坏,遗憾的是它已在网络级别应用。

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

我们的想法是使用标准(通用)机制进行SOA业务组件之间的在线交互。然后,您可以动态查找与之相关的服务并自动开展业务。在类似服务之间进行选择的决定应该基于UBR中的元数据(所有这些都在一个非常复杂的模型中阻止采用),而无法检查服务是否实际上做了你期望它做的事情。

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

业务是在合作伙伴之间进行的,这些合作伙伴只有在经过彻底的分析和谈判后才能选择彼此开展业务,然后才能最终达成商业协议并就所有条款和条件达成一致。只有这样他们的基础设施才能相互联系。在这一点上,UDDI定义确实有意义,因为在企业内部UDDI允许您:

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

..但所有这些都在一组有限的预定服务中,这些服务的功能已得到很好的建立并达成一致。

答案 1 :(得分:5)

我收到了John Saunders关于原始问题的答案,我收到了comments之一,我认为他是对的。

总结一下:

公共UDDI运动已经死亡,因为IBM,Microsoft和SAP公共注册管理机构 UDDI运动。

答案 2 :(得分:2)

没死。

Apache jUDDI在线提供公共快照

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

答案 3 :(得分:1)

UDDI确实死了。有三件事让它死了:

  1. 过于复杂的
  2. 忽略安全性
  3. 管理和收集小额支付的困难仍在我们身上
  4. 如果UDDI代理商为我动态选择服务提供商,我就没有机会对服务的安全性进行任何尽职调查。经纪人为确保我的安全而需要多少麻烦?不是很多,我建议。

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