Enterprise Software

Understanding UDDI

Wondering how to use UDDI to interact with Web services? We'll give you the basics, with examples in VB.NET.


Web services are designed to be accessed via the Internet or other network connections. However, there has to be a way of advertising a service’s existence, its purpose, and protocols. For example, if you want to add a stock ticker to your Web site you can get this feature via a Web service, but how do you know it’s available, what its features are, how much it costs (if anything), and where and how to access it? UDDI (Universal Description, Discovery and Integration) is the answer.

A "phone book" for Web services
UDDI began as a protocol—a specification describing how a directory of Web services should look, and providing a list of people who offer the directories. The UDDI technology also now includes the UDDI Business Registry (UBR)—also sometimes called cloud services. This registry is similar to a phone book, a place where consumers can search listings of companies that have registered their Web services.

Each Web service listed in a UDDI Registry can be described three ways. First, the White pages offer overall background information about the company behind the Web service—products, contact information, and so on. Second, the Yellow pages make it easy to locate similar Web services by dividing them into categories such as PDA’s, telecommunications, sports scores and so on. Finally, the Green pages provide details about each Web service that are useful in contacting and consuming the service, such as a URI address of a SOAP or WSDL file describing the service and its behaviors. The Green pages’ contents are left up to the Web service provider. They can range from nothing more than a Web page address offering further information, to a lengthy Java RMI description.

Separate Registry “nodes” are hosted by various vendors, including one by Microsoft. If you’re interested in seeing further information about nodes, and other aspects of Web services publication, visit the OASIS site. It is an industry organization devoted to the “development, convergence, and adoption of structured information standards in the areas of e-business, Web services, etc.”

Viewing the UDDI registry
You can easily browse UDDI nodes from within Visual Studio. It works the same way from within any Visual Studio language, but I’ll illustrate the process from Visual Basic. Start a VB.NET project and choose Project|Add Web Reference.

You see an offer to use the Add Web Reference dialog box as a “starting point to find Web services.” You can either type in a URL to a service, or click one in the list of hyperlinks it presents to you:
  • Web services on the local machine
  • Browse UDDI Servers on a local network (remember it’s possible to consume Web services on intranets as well as the Internet)
  • Query the UDDI business registry to find companies and production Web services
  • Test Microsoft UDDI Directory

This fourth link is for testing purposes. The Microsoft directory maintains some services that you can use to learn how to access and incorporate Web services in your applications.

Let’s experiment, however, with the third link, querying the UDDI business registry. (Note: To make the examples work, you will have to have VS.NET.) Click that link and you’re connected to http://uddi.microsoft.com/visualstudio, an Internet site maintained by Microsoft. It’s a node that allows you to search by service type (i.e., weather), provider (i.e., XYZ Weather Services), or select from a list within the “categorization scheme,” which is, in effect, a small set of UDDI “Yellow pages.”

Try entering w% in the Service Name field (% is a wild card that behaves like *, meaning show all entries starting with w.) I get 29 hits—though your results may differ (Web services, like Internet sites, come and go).

Now locate and click VS Web Service Search Categorization in the categorization scheme listing. Click Calendar in the subcategory list, then click the Search button. You’ll see several listings offering date/time or other calendar-related Web services (along with a Euro-converter that found its way into this category somehow). Click the + to expand one of the entries that interests you, and you will see a form displaying several items of UDDI data: Service Description, Bindings (view the access point or points within a service), Access Point (the address to which you send a message activating a particular service, or an individual method within a service), Description, and Interface Definitions (any parameters that must be passed to the service, and what to expect as a response).

The most important data here is the description, which might be something like this: Provides the local weather for any zip code in the US.

Next in importance is the Access Point which is the equivalent of a procedure name in an ordinary application procedure call. You provide the name of the function (in this case, let’s say it’s LocalWeather) and the Web service responds. Finally, click the Interface Definitions. Here’s where you’re likely to find the necessary parameters and their data types that you must supply when accessing the Web service, for example:
LocalWeather(ZipCode As Integer)

And also the response you’ll get back and its data type:
Returns: Forecast As String

Some descriptions are complete, intelligent and clear. Some are not clear at all. Most of the services on this node were evidently published merely as tests, and have been left unworkable, or unreachable. Some do work, however, so if you’re interested in learning how to consume Web services programmatically, this is a good place to conduct tests.

You can also access Web services via a different process from within the Visual Studio IDE. Choose Help|Show Start Page, then click the Online Resources tab. Click the XML Web Services link in the left pane. You see options here to both find and register Web services.

Within the Find page, click the Search option in UDDI Production Environment, then under the Category drop-down list, choose Miscellaneous. Click Go and find a service that interests you. You can examine the bindings, descriptions, and interface details by clicking various tabs and links.

Whither WSDL?
The notion of self-description—metadata, discovery, reflection, whatever you want to call it—is all the rage. You may suspect that the descriptive sections of UDDI listings (the service description and, in particular, interface descriptions) have been viewed by academics and others as a likely target for the creation and application of self-description protocols. And sure enough, yet another XML-derivative has been created by committees. It’s called WSDL (Web Services Description Language) and its purpose is to set rules by which the description of error processing, object members, messaging, and other Web service behaviors can be standardized.

Even though such metalanguages have been notably difficult to enforce in recent history, hope springs eternal. As you no doubt noticed if you looked through some of the UDDI registries described earlier in this article, there is hardly any current standardization in the service descriptions, much less a wide acceptance of WSDL as the solution. Nonetheless, .NET can generate WSDL documents for you, should you decide to use them with any Web services you create. And if you’re interested in further exploring WSDL, you can find exhaustive, jargon-rich information from the W3C.

Editor's Picks

Free Newsletters, In your Inbox