Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

August 12, 2002

UDDI at Midnight

The necessity of UDDI may be more fairy tale than reality

by Michael J. Hudson

When you were a kid, you probably begged your parents to buy some variation of Chef Boyardee's alphabet soup because it had a lot of weird-looking shapes and it seemed new, cool, and fun. However your parents knew, as you know now, that it was really just a bunch of glorified noodles in some broth and water. Today, in the grocery store of technologies, the same thing is occurring with Web services and its associated acronym soup. And although much of what it does isn't anything new, somehow Web services have caught the corporate world's kid sense of cool.

However, a number of things in this acronym soup aren't too bad, even if they're a little bulky and slow. You have XML, which isn't only used in this context but is also used to describe data in numerous other business domains. The somewhat successful standards bodies such as the World Wide Web Consortium and OASIS are betting their reputations on the success of XML as a worldwide standard.

However, whenever you think of Web services, it's always a certain holy trinity of acronyms that come to mind that are supposed to be its raison d'etre. Two of these components, Web services description language (WSDL) and simple object access protocol (SOAP), are actually relatively simple in their design and scope and currently used in many new strategic business applications. Then again, the concepts behind those two components make up the essential basics of any distributed framework, either to describe or invoke generic cross-language interfaces. However, another step-acronym is often heard about but not seen (or at least not often): universal description, discovery, and integration (UDDI), where a lot of Web services' current hype is still centered.

Cinderella Story?

Maybe it's just another Cinderella story, with UDDI currently being kept behind the scenes by its two evil stepsisters. And maybe one day, its crystal XML slipper will be found by some corporate prince, and it will be the centerpiece princess of Web services that it currently claims to be. That is, if it can get back home before the hands on the clock of hype strike midnight and it turns into a big, fat pumpkin. Or maybe it's because an official standards body hasn't really taken up UDDI or Microsoft and IBM don't really understand the needs of the masses. In either case, UDDI is starting to become a whole lot of nothing.

UDDI's main purpose is to be the glue between the companies themselves, their abstract notions of strategic business services, and the actual nitty-gritty plumbing that's supposed to make it all happen. The idea is that if a company needs some service, it can look the service up on a UDDI registry, find the one it needs, get the details of how the service works, and somehow dynamically start using and invoking this service without much fuss. So far, it's hardly been close to being that successful yet.

Something usually becomes a standard because of a need for interoperability. However, what's the big deal if one company decides to let its partners search for its services in a slightly different way or format from another company? You might argue that you need a universal registry interface so that any generic program can generically hit any UDDI registry, generically find the necessary interface file (WSDL), and then somehow generically be able to use only that and no other context to invoke a generic SOAP service. As you can see, we've hit the IT version of supermarket generic brands. And with most generics, you just don't get the same quality of service as with a name brand, one specifically built for a certain purpose.

And although you may believe that you can somehow dynamically get the interface for a service from a UDDI registry and then automatically — without any human developer — access that SOAP server through your back-end systems, it's simply not the case. If you have some weather service interface that takes two string variables and returns a float, you still don't know whether the string variables are longitude and latitude coordinates, city and ZIP code, temperature or humidity, or, if it's a temperature, whether it's Fahrenheit or Celsius.

The point is that a lot of semantic context and domain knowledge are necessary even after you know where a service is and what it looks like. It still takes a human developer to understand both your strategic business application and the details of this service and then write the appropriate code to create the appropriate translations that let each side effectively talk to each other.

The Pumpkin

So, in the end, you're just left with a big search engine. However, UDDI isn't really that great of a search engine either. It doesn't support distributed searches, and it doesn't have a general syntax for abstract querying. Essentially, you really can't do more than search for keywords that either exist in your business description or your service description. To top it all, to register your company with a UDDI registry, you must do a lot of business modeling, including the creation of a taxonomy about your domain, which ends up being a lot of work without a lot of results. And, registries are only as good as the data in them, so how do you trust that companies put in the effort to register their business and services properly? How do you know that the services are even worth the effort of investigating further?