Why UDDI Sucks

Last week I shared my interview with Eugene Curiana, Leapfrog Enterprises’ Director of Systems Infrastructure. One look at his photo will tell you Curiana is not your typical suit. Ditto his approach to building a service-oriented architecture.

So I guess it should come as no surprise that some of the vendors with whom he associates are not cut from the pinstripe cloth, either. In fact, during the course of reporting his story, I took a briefing with Dave Rosenberg, the cofounder of MuleSource, whose Mule ESB plays a key role in Leapfrog’s SOA.

As we chatted about the various dimensions of the SOA universe, Rosenberg made a bold assertion. He barked, “UDDI sucks!” I was struck. Universal Description, Discovery, and Integration, the open OASIS standard designed to provide a platform-independent global Web service registry—the key to allowing SOAs the world over share and connect services over the Internet—sucks!

Rather than go off-topic and squander the remainder of our briefing time, I asked Rosenberg if he would mind sharing his reasoning (and by extension, MuleSource’s) with CIO.com’s readers in another column. He agreed.

Dave passed the job of articulating MuleSource’s position to SOA architect Dan Diephouse, project lead for Mule RESTpack and SOA Governance platform Mule Galaxy. Dan is also creator of the Xfire project, and co-founder of Apache CXF.

MuleSource’s position on UDDI follows. But this isn’t the end of the story. With MuleSource’s permission, I shared this piece with the folks at Microsoft. Microsoft is one of the driving forces behind UDDI, which first debuted in 2000 (it’s currently at v.3.x).

Separately, you can read the Microsoft counterpoint.

Meanwhile, here’s MuleSource’s Dan Diephouse articulating why UDDI sucks. I’ve made minor grammatical edits, but these are Diephouse’s words.

“The registry landscape needs to change. The unholy trinity of SOAP, WSDL and UDDI needs to go. While registry vendors, such as Systinet, have pioneered a number of good ideas in the field, they have failed to meet the needs of enterprise integration projects today, because they are based on these technologies. One should be able to guess this just by seeing the limited adoption, low success rate and high price tags of these solutions. Mass adoption is just not in the cards.

“If we’re to understand why this approach for registries has failed, we need to look to the bottom of the stack: SOAP/WSDL-based services. Over the last decade we’ve learned that they’re tightly coupled—making distributed, anarchic change highly difficult.

“Yes, your enterprise is a bit anarchic. Business needs change rapidly. To keep up with these changes, IT scales and evolves rapidly. To do this, enterprises have been adopting a RESTful approach to building highly scalable services. RESTful architectural principles are the ones behind HTTP, and allowed the Web to scale and evolve at such a rapid pace.

“Even if SOAP/WSDL was the right answer, we will never be able to adopt a single type of service. All technologies have tradeoffs associated with them, and we should never assume a homogenous enterprise environment (not to mention the massive cost of switching everything over). Because UDDI has been designed around the concepts of SOAP/WSDL, it has failed to evolve and address this problem.

“There are yet more problems with UDDI, though. A lot of effort has been spent on seldom-required use cases. For instance, it’s often recommended that people use it at runtime to dynamically look up services. In reality, this is often dangerous, and hardly ever done. You can easily end up with a service you don’t want, whether it’s because the functionality is slightly different, the service is slower, or it lacks redundant backups.

“On top of this, UDDI is also quite hard to use. It seems people were so confused, the technical committee had to write another long document explaining how it could be used as a registry with SOAP/WSDL services. Then Systinet had to write another long document called the Governance Interoperability Framework to make it actually possible for inter-vendor communication using UDDI.

“Where does this leave us? We need to leave this whole stack behind. Registries need to be more agile, easier to use, and focus on things that matter for SOA projects today. We’ve been pioneering a new approach with Mule Galaxy. It uses a simple, extensible services model which enables you to reap the benefits of registries—service visibility, contract management, policy management, etc.—while remaining in a heterogeneous environment.

“It also uses a new type of registry API based on the Atom Publishing Protocol (AtomPub). This API, which is built on Atom (the successor to RSS), enables integration using a simple, RESTful mechanism. This RESTful approach, combined with our flexible services model, reflects the way that enterprises actually do business, not some vendor-imposed theory.”

Do you think Diephouse’s remarks are inciteful or insightful? In any case, here’s Microsoft’s counterpoint. Read that, too, and tell us who has the right of it.