UDDI: The Directory Mechanism for XML Web Services

The third leg of XML Web Services, Universal Description, Discovery, and Integration (UDDI), is a directory-service mechanism for finding existing Web Services. I described the other two legs of XML Web Services—Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL)—in the January 24, 2002, and February 7, 2002, editions of .NET UPDATE, respectively.

The best way to describe UDDI is to compare it to a telephone directory. For example, service businesses such as dry cleaners often advertise where people searching for specific services look: the Yellow Pages. You might say that UDDI functions as the Yellow Pages of Web Services. An excellent white paper ("UDDI Technical White Paper") that appears on the UDDI Project Management team's Web site (see the first URL at the end of this article) carries the telephone-book comparison further by stating that a UDDI entry has three parts: a "White Pages" entry that describes the contact information for the company offering the Web Service, a "Yellow Pages" entry that organizes the Web Services based on standardized industrial categories, and a "Green Pages" entry that describes the Web Service for the benefit of applications trying to connect to the service. A UDDI Type Model (tModel) XML document defines the service and often contains a WSDL file describing the SOAP interface to the XML Web Service's messaging capabilities.

The main point here isn't that "you" can search for these services—you currently can use tools such as Yahoo! Yellow Pages or Google to search—but that .NET applications can perform the searches. UDDI can eliminate some human busywork in locating Web Services on the Internet. For example, if you're a developer writing an application to pay a vendor, and the vendor publishes its Accounts Receivable information as a Web Service, then the party using your application doesn't need to manually look up the Accounts Receivable contact information. Instead, UDDI can locate the information, which will save the user time (especially when you consider the difficulty of finding contact information on some Web sites). An added benefit to using UDDI can result when a connection to a Web Service lets the user format the information in a way that the vendor requires. UDDI lets people and applications search for Web Services based on many criteria, such as business type or geographical location, or to search by company name to determine which services a company offers.

The UDDI XML schema defines four core types of information that you must know to use a partner's Web Services: business information, service information, binding information, and information about specifications for services. You use the UDDI business registry to find the business information registered by or for the appropriate business partner advertising the Web Service. After you have that information, you can get more details about a specific business service or about the business in general. Using the binding information, you can write an application to connect to the published Web Service. When the application runs, it uses the cached location and binding information to invoke the Web Service and to format the information in the way that the Web Service requires.

In the March 7, 2002, edition of .NET UPDATE, I'll begin to explore how XML Web Services fit into the greater framework of .NET. For more information about using UDDI in XML Web Services, check the following links.

The UDDI Project Management team:
http://www.uddi.org

Microsoft's "XML Web Services Basics" document:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/webservbasics.asp