UDDI Best Practices

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"?

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

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.