UDDI Best Practices

My organization enters the SOA world (a little late, but what I like here!), And we are studying ESB Toolkit 2.0 (we already have BizTalk Server 2009).

We are committed to implementing UDDI (in particular, UDDI Services v3.0, which ships with BTS 2009), but we know little about the experience of UDDI. We want to manage the ever-growing number of web services that we have in all of our environments.

What are the best practices for implementing UDDI? For instance: -

  • Would you use one highly available stable UDDI server that hosts all services and bindings, including test environment versions? Or will you implement separate UDDI repositories for test and production environments?
  • I know Oasis Technical Note v2.0 on WSDL and UDDI, but does anyone really implement this? That is, the abstract parts of WSDL as tModels, the parts of the WSDL implementation as bindings?
  • Could you try to capture endpoints without a web service in UDDI or just use it for WSDL?
  • What is the "gotchas"?
+4
source share
2 answers

IBM has stopped using UDDI and is using the HTTP and REST interface for its WSRR. Oracle does not use UDDI in most of its solutions, but they have a registry and repository that supports UDDI v3 (this is OEM)

I do not see the UDDI used in the Microsoft Azure platform , am I not sure here?

I'm not saying it's a dead standard ... but others

+3
source

q: Do you deploy one highly available stable UDDI server that hosts all services and bindings, including test environment versions? Or will you implement separate UDDI repositories for test and production environments?

a: I would probably do one for the dough, one for the production.

q: I know Oasis Technical Note v2.0 on WSDL and UDDI, but does anyone really implement this? That is, the abstract parts of WSDL as tModels, the parts of the WSDL implementation as bindings?

a: Yes, jUDDI has both Java and .NET WSDL implementation for UDDI technical note. WS02 also does.

q: Could you try to capture the endpoints without a web service 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 can take advantage. jUDDI v3.2, except for 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 this will help make your decision.

q: What is "gotchas"?

a: There are many β€œopen windows” in UDDI, in particular, there are many ways to use tModels. A specification defines a group of them, but it is up to you to use and interpret them. There are also a number of conflicting statements in the specification, which makes it difficult to decide how to implement it. Some things in the spec just didn't go all the way.

0
source

All Articles