我的组织正在进入 SOA 世界（有点晚了，但这就是这里的情况！），我们正在研究 ESB Toolkit 2.0（我们已经有了 BizTalk Server 2009）。
我们热衷于实施 UDDI（特别是 BTS 2009 附带的 UDDI 服务 v3.0），但我们缺乏实际的 UDDI 经验。我们希望管理我们所有环境中不断增长的 Web 服务数量。
实施 UDDI 的最佳实践是什么？例如：-
- 您是否会实现一个托管所有服务和绑定（包括测试环境版本）的高可用弹性 UDDI 服务器？或者您会为测试和生产环境实施单独的 UDDI 存储库吗？
- 我知道关于 WSDL 和 UDDI 的 Oasis 技术说明 v2.0，但有人真正实现它吗？即 WSDL 的抽象部分作为 tModel，WSDL 的实现部分作为绑定？
- 您会努力捕获 UDDI 中的非 Web 服务端点，还是仅将其用于 WSDL？
- 有哪些“陷阱”？
My organisation is getting into the SOA world (a bit late, but that's what it's like here!) and we're looking into the ESB Toolkit 2.0 (we already have BizTalk Server 2009).
We're keen on implementing UDDI (specifically, the UDDI Services v3.0 that ships with BTS 2009), but we're low on actual UDDI experience. We want to manage the ever-burgeoning number of web services we have across all our environments.
What are the best practices for implementing UDDI? For example:-
- Would you implement a single highly-available resilient UDDI server that hosts all services and bindings, including test environment versions? Or would you implement separate UDDI repositories for test and production environments?
- I'm aware of the Oasis Technical Note v2.0 on WSDL and UDDI, but does anyone actually implement that? I.e. the abstract parts of the WSDL as tModels, the implementation parts of the WSDL as bindings?
- Would you go to the effort of capturing non-web service endpoints in UDDI, or just use it for WSDL?
- What are the "gotchas"?
发布评论
评论（2）
IBM 已停止使用 UDDI，并为其 WSRR 使用 HTTP 和 REST 接口。
Oracle 在其大多数解决方案中并未使用 UDDI，但他们有一个支持 UDDI v3 的注册表和存储库（这是 OEM）
我看不到 Microsoft Azure 平台，我在这里不确定吗？
我并不是说这是一个死标准...但 其他是
IBM has stopped using UDDI, and is using a HTTP and REST interface for their WSRR.
Oracle is not using UDDI in most of their solution, yet they have a registry and repository that supports UDDI v3 (this is OEM)
I cant see UDDI used in the Microsoft Azure platform, I am unsure here?
I am not saying that it is a dead standard... but others are
问：您会实现一个单一的高可用弹性 UDDI 服务器来托管所有服务和绑定（包括测试环境版本）吗？或者您会为测试和生产环境实施单独的 UDDI 存储库吗？
a：我可能会做一个用于测试，一个用于生产。
问：我知道关于 WSDL 和 UDDI 的 Oasis 技术说明 v2.0，但是有人真正实现它吗？即 WSDL 的抽象部分作为 tModel，WSDL 的实现部分作为绑定？
答：是的，jUDDI 有 WSDL 到 UDDI 技术说明的 Java 和 .NET 实现。 WS02 也是如此。
问：您会努力捕获 UDDI 中的非 Web 服务端点，还是仅将其用于 WSDL？
a：是的，但是你打算如何使用这些数据呢？ UDDI v3 定义了一个用于访问注册表信息的 REST 接口，因此 REST 服务可以利用。 jUDDI v3.2 除了拥有时尚的用户界面之外，还实现了 REST 接口，为什么不呢？真正的问题是，您将如何使用这些数据？答案将有助于推动您的决定。
问：“陷阱”是什么？
答：UDDI 中有很多“开放性”，特别是有很多使用 tModel 的方法。规范定义了其中的一些，但使用和解释它们取决于您。规范中还存在许多相互矛盾的陈述，因此很难决定如何实现它。规范中的某些内容并未完全完成。
q: Would you implement a single highly-available resilient UDDI server that hosts all services and bindings, including test environment versions? Or would you implement separate UDDI repositories for test and production environments?
a: I'd probably do one for test, one for production.
q: I'm aware of the Oasis Technical Note v2.0 on WSDL and UDDI, but does anyone actually implement that? I.e. the abstract parts of the WSDL as tModels, the implementation parts of the WSDL as bindings?
a: Yes, jUDDI has both a Java and .NET implementation of the WSDL to UDDI technical note. WS02 does as well.
q: Would you go to the effort of capturing non-web service endpoints in UDDI, or just use it for WSDL?
a: Yes, but how are you going to use the data? UDDI v3 defines a REST interface for access registry information so REST services may be able to take advantage. jUDDI v3.2, aside from have a sleek user interface, implements the REST interface, so why not? The real question is, how are you going to use the data? The answer to that will help drive your decision.
q: What are the "gotchas"?
a: There's a lot of 'open ended-ness' in UDDI, specifically there are many ways to use tModels. The spec defines a bunch of them, but its up to you to use and interpret them. There's also a number of conflicting statements within the spec that makes it difficult to decide on how to implement it. Some things in the spec just weren't through all the way through.