Who Cares About UDDI?
David Chappell - April 25 , 2002
Web services are the most important thing happening in distributed computing today. And since distributed computing has become the norm, that puts them high on the list of important things, period. As usually described, the trinity of Web services technologies includes SOAP for invoking remote operations, WSDL for specifying what those operations look like, and UDDI for . . . well, what, exactly? What is UDDI actually good for?
Theoretically, UDDI stores information that helps clients select and use a web service. This might mean information about the kind of service provided, who provides it, and potentially even how much it costs. UDDI is a very open-ended technology, and so it can store all kinds of data. Pragmatically, however, the main thing required to access a Web service is its WSDL definition. Tools such as Microsoft’s Visual Studio.NET and IBM’s WebSphere Studio can read a WSDL file and generate the client proxy required to invoke the operations described in that file. While there are UDDI servers available on the Internet today, there’s not much in them. In particular, they don’t contain many WSDL files.
This isn’t really too surprising. After all, the primary application of Web services today is enterprise application integration (EAI). Connecting existing code is a pressing business problem, one solved quite effectively by Web services, and staying inside the firewall lessens the challenging authentication and privacy issues that can accompany SOAP today. For both of these reasons, EAI has proven to be the killer app for Web services. Yet EAI interconnections are quite static, and they don’t generally require Internet access. Accordingly, today’s Internet-based UDDI servers are largely irrelevant to the problem. There are simpler ways to discover the WSDL interface of the desired Web services, such as having it sent to you via email by your fellow developer on the project.
The next most important category of Web services applications today is probably business-to-business, or B2B, integration across the Internet. Internet-based UDDI servers could potentially be more useful here. Once again, though, today’s B2B interactions are generally quite static–business partners agree in advance to communicate–so there’s no need for the very general service that UDDI can provide.
So when would UDDI be useful? One possibility is applications running in a world of widely available Internet-based Web services, with searches and frequently changing connections the norm. Here, UDDI’s very general capabilities to describe what’s available and to provide the information needed to choose and communicate with the appropriate service might be useful. But don’t hold your breath waiting for this world to arrive: it won’t be here anytime soon. Dynamically discovered Web services face a host of problems, including security, market demand, and charging mechanisms. While some Web visionaries tout the inevitability of this world, I confess to some skepticism. It may never arrive.
UDDI might also be useful as an intranet-based service, one that could be used to learn about locally available services. This is a more plausible alternative, but still not one for which any substantial need exists today. Intranet-based projects typically don’t change that often, and so a specialized directory service is probably more trouble than it’s worth.
Given UDDI’s problems, it’s fortunate that a more recent specification produced jointly by Microsoft and IBM provides a simpler, cleaner answer to the core problem of finding WSDL definitions. Called WS-Inspection, it defines a straightforward XML document structure for finding either a WSDL file for a particular Web service or its UDDI description. While WS-Inspection isn’t yet widely supported, it looks likely to become an important part of the Web services technology arsenal. And while UDDI may one day be a useful standard, it has so far remained the least important of the big three Web services technologies.