The importance of the UDDI standard in the future of SOA is highlighted in a new Burton Group Inc. report, "Registry Services: The Foundation for SOA Governance" by Anne Thomas Manes, research director at the analyst firm. In this interview, Manes explains why after being ignored for so long, the OASIS UDDI standard now at version 3.0, is finally moving up the adoption curve.
That's because UDDI was part of the management space. You never need management right at the start. At the beginning you need the development tools. That's the core. SOAP and WSDL gave you the core development tools to go out and build Web services. You don't have to do management until you have systems that are running in production. That's why UDDI is slowly, but surely gaining traction. I think it's a lot more accepted now than it was a year ago. Do you see drivers now that might speed the adoption of UDDI for SOA implementations?
Staring in 2004 the innovators were adopting UDDI. In 2005, it was the early adopters. And in 2007, we might cross the divide and get to the early majority. Is that because UDDI has become necessary for SOA?
I think so. You don't need UDDI to get started with Web services. You don't need UDDI to enable integration among applications. But if you want to do SOA, you have to start managing the environment and UDDI becomes the system that enables communication among multiple environments. UDDI is the foundation for governance. As people start deploying more and more services and their systems get further and further out of control, they realize that they need to do something. And they start by bringing in a registry. So is the need for a registry driving UDDI adoption?
Usually, they figure out pretty soon that a registry is not enough and then they have to bring in a repository and start contract management and policy management, but it's really only the innovators who have reached the true understanding of the meaning of governance. Why is UDDI important to the registry in SOA implementations?
The true value of UDDI is not for discovery of services. It's not like a developer uses UDDI to figure out where a service is. The purpose of UDDI is for the various components of your runtime infrastructure to be able to share information about services and dependencies and policies that apply to the services that are out there. So the value of UDDI is that it's a standard protocol to talk to a registry. The registry provides this information exchange. If I don't know how to talk to the registry, I can't get that information. So the protocol to talk to the registry is UDDI. It's a critical component of the system. Are there any competing technologies?
Well IBM has created a whole new API. It's called IBM WebSphere Registry and Repository and it's been shipping for about six months. So it's possible that IBM is going to turn around and say, "We've created a whole new format and everybody else should adopt our approach." Is everybody in the world is going to jump on the bandwagon and do it the way IBM says? I don't know about that.
I don't think there's an issue at all. There's a spec out there called ebXML Registry, but nobody's using it. What do you see as UDDI's strength as a standard, versus other proposals such as ebXML Registry or IBM's WebSphere Registry and Repository?
The problem is this: if I use AmberPoint for management, and I have Sonic ESB, and I have the Reactivity XML Gateway, and I'm still building services with WebSphere and .NET and Ruby on Rails, how do all those systems communicate with IBM's registry? It doesn't work. If I throw in the Systinet registry or the Infravio registry they all know how to talk to UDDI. They can all share the information. So will this be the year we see some real forward movement for UDDI?
Certainly, I've seen steady increase in interest in UDDI over the last two to three years. It's slowly gaining adoption.