我的组织正在进入SOA世界（有点晚，但这就是它的样子！），我们正在研究ESB Toolkit 2.0（我们已经有BizTalk Server 2009）。UDDI最佳实践
我们热衷于实现UDDI（特别是随BTS 2009发布的UDDI服务v3.0），但我们对实际的UDDI体验并不满意。我们希望管理我们在所有环境中拥有的数量日益增长的Web服务。
实现UDDI的最佳实践是什么？例如： -
IBM has stopped using UDDI，并且正在为其WSRR使用HTTP和REST接口。 甲骨文没有使用UDDI在大部分的解决方案，但他们有一个支持UDDI v3的（这是OEM）
我不能看到Microsoft Azure platform使用UDDI注册中心和仓库，我不确定在这里？
我并不是说这是一个死标准......但others are
问：你想实现承载所有的服务和绑定，包括测试环境的版本一个高度可用的弹性UDDI服务器？或者你会为测试和生产环境实施单独的UDDI存储库吗？
a：我可能会做一个测试，一个用于生产。
问：我知道关于WSDL和UDDI的Oasis Technical Note v2.0，但有没有人真的实现了这一点？即WSDL的抽象部分作为tModels，WSDL的实现部分作为绑定？
a：是的，jUDDI同时具有WSDL到UDDI技术说明的Java和.NET实现。 WS02也是如此。
问：您是否会努力在UDDI中捕获非Web服务端点，或仅将其用于WSDL？
a：是的，但你打算如何使用这些数据？ UDDI v3定义了用于访问注册表信息的REST接口，因此REST服务可能会利用。 jUDDI v3.2除了有一个时尚的用户界面，还实现了REST界面，为什么不呢？真正的问题是，你将如何使用这些数据？答案将有助于推动您的决定。
问：什么是“陷阱”？
a：在UDDI中有很多'开放式结构'，特别是有许多方法可以使用tModels。该规范定义了一堆，但它取决于你使用和解释它们。规范中还有一些相互冲突的陈述，使得很难决定如何实现它。规范中的一些事情并没有完全通过。