In research conducted by the SIIA (Software and Information Industry Association), ComputerWorld and Systinet, which will be published in October, 2002, we found that among the 800 developers and IT managers we interviewed, over 68% planned to deploy Web services applications in the next 12 months. As Web services enter the mainstream, we should expect them to proliferate and become more sophisticated and interdependent, which begs a question: If my organisation has many Web services, how do I discover them and consume them? If I've just built the 'killer app' using Web services, how do I let all my colleagues, business partners and the boss know that it exists?
Along with SOAP and WSDL, UDDI (Universal Description, Discovery and Integration) is one of the core technologies that enable Web services. A UDDI implementation is a Web service registry that provides a mechanism to advertise and discover Web services. A UDDI registry contains categorized information about businesses and the services that they offer, and it associates those services with technical specificiations of the Web service. These technical specifications are usually defined using WSDL. WSDL describes what a Web service does, how it communicates, and where it lives. A Web service consumer queries the UDDI registry to find the WSDL descriptions to determine how to use the Web service. A UDDI registry is itself a Web service. The UDDI specification defines an API based on SOAP messages, with a WSDL description of the registry service. Most UDDI registries also provide a browser-based human interface.
The UDDI Project operates a global public registry called the UDDI Business Registry (UBR). This registry is available to everyone at no charge (see http://www.uddi.org), and all information registered in the public registry is available to the general public. All information in any one UBR registry node is automatically replicated to all other UBR nodes within 24 hours.
Organizations can also set up a private registry to support the requirements of an enterprise or a private community. A private registry can impose additional security controls to protect the integrity of the registry data and to prevent access by unauthorized users. A private registry might contain only private information, it might contain a subset of the public registry information, or it might contain a combination of public and private information.
Basically there are two mechanisms that you can use to interact with a UDDI Registry. The first one is to use an HTTP browser-based interface. You can check out these UDDI registries on the Internet:
- Microsoft Public UDDI Registry
- IBM Public UDDI Registry
- Hewlett Packard Public UDDI Registry
- SAP Public UDDI Registry
- Systinet Live UDDI Registry
The purpose of this article is to introduce the basic structure of UDDI, explain how it works and how it might be useful, then explore using a live UDDI registry. We begin by outlining the data model used in a UDDI registry, then describe the UDDI API. Using a publicly available UDDI implementation at freedb.org, along with a Web services runtime server, we'll provide examples of discovering and publishing information. At the end of this article readers should be familiar with the basic concepts of UDDI, and understand how to work with a UDDI registry.
We've created our examples using a free set of tools and a runtime environment (details on how to access and download this software is in the Installing Software chapter at the end of this article). You don't have to use these products to understand the examples, but we strongly recommend it. The concepts we introduce and the code we create are generally applicable and relatively independent of the tools used. We assume some knowledge of XML, but none of Web Services.
Quick Introduction to the UDDI Data Model
The UDDI specifications are being developed by the UDDI Project. The UDDI Project is an industry initiative lead by Accenture, Ariba, Commerce One, Compaq, Fujitsu, Hewlett-Packard, i2 Technologies, IBM, Intel, Microsoft, Oracle, SAP, Sun Microsystems, and Verisign. More than 300 other companies participate in the UDDI Advisors Group. The UDDI V2 specification is in final draft and complete; a final draft of the UDDI V3 is expected later this year. (see http://www.uddi.org/specifications.html).The specifications have been widely adopted and several companies have UDDI implementations available.W
A UDDI Registry contains information about businesses and the services they offer. The information is organized as follows:
- Business Entity. A business entity contains information about a business including its name, a short description, and some basic contact information. Each business can also be associated with unique business identifiers, including a Thomas Register identifier and a D-U-N-S number, and with a list of categorizations that describe the business. UDDI provides built-in support for a number of taxonomies, including SIC (Standard Industrial Classification codes), NAICS (North American Industry Classification System), UNSPSC (Universal Standard Products and Services Codes), and a geopolitical taxonomy. Businesses and industry groups can create additional taxonomies to categorize their businesses and services.
- Business Service. Associated with the business entity is a list of business services offered by the business entity. Each business service entry contains a business description of the service, a list of categories that describe the service, and a list of binding templates that point to technical information about the service. Each business service can be associated with a list of categorizations that describe the service.
- Binding Templates. Associated with each business service entry is a list of binding templates that provide information on where to find the service and how to use the service. For example, a binding template may contain the access point of the service implementation and a pointer to information on how to use the service. The binding template also associates the business service with a service type.
- Service Types. A service type, defined by a construct called a tModel, defines an abstract service. Multiple businesses can offer the same type of service, all supporting the same service interface. A tModel specifies information such as the tModel name, a list of categories that describe the tModel, and pointers to technical specifications for the tModel. For example, a tModel may point to a WSDL document that describes the abstract service type.
Figure 1: The UDDI Data Model
UDDI is a general-purpose registry. It can be used to register any type of service, not just Web services. UDDI doesn't require that the services registered within it support SOAP interfaces or that they be described using WSDL. In fact, there are no dependencies among any of the three Web services technologies. But the system works best when the three technologies are used together. This best practices white paper explains how to use UDDI and WSDL together (see http://www.systinet.com/techres/files/uddiwsdl.pdf).
When looking for a Web service, a developer queries the UDDI registry, searching for a service offered by a business. From the Binding Template entry for the specific service, the developer can obtain the service access point and a pointer to the tModel that describes the service type. From the tModel, the developer can obtain the WSDL description describing the service interface. Using the access point and the WSDL description, the developer can construct a SOAP client interface that can communicate with the Web Service.
Using the UDDI API
The UDDI API consists of two interfaces: a publishing API and an inquiry API. We will first use the publishing API to register the FreeDB Web service in the Live UDDI Registry. The FreeDB Web service lets you search the Free DB music database for CD and song titles. Next we'll use the inquiry API to find our service.
Registering with UDDI
Since the UDDI publishing API requires security, we will first need to become a registered user of the UDDI registry. Please use the UDDI registration form (login is on the left menu bar) and register yourself with the Live UDDI Registry. Please use a valid e-mail address because you'll need it later for account confirmation. (Don't worry. We won't use your e-mail address for any marketing purposes.) After registration, please check your e-mail for the account creation confirmation. You'll need to follow a link inside the incoming message in order to activate your UDDI account.
Choosing a demo business name
In order to execute the following demos properly, you'll need to choose a unique demo business name. You can check to see if your intended business name is available by performing a UDDI business entity query in the Live UDDI Registry Browser (choose Find Business from the Main UDDI menu).
Publishing the Music Service
NOTE: We're using MS Windows notation for our command-line commands. If you have a Unix-based environment, please use the appropriate
.sh script instead of the Windows
We will now publish our music search Web service in the UDDI registry using a simple registration tool. Run the
run.bat make_register and
run.bat run_register commands in the bin subdir of the tutorials directory. Provide your UDDI user name and password and the demo business name from the previous steps. Push the Publish button to publish the music search service under your new business entity. You might want to verify that your business entity was successfully published using the Live UDDI Registry Browser again.
Figure 2: The UDDI Publishing Form
The complete source code for this registration tool is in the
srcdemouddiUDDIPublish.java Java source files. You may also want to look at the Systinet UDDI API JavaDoc.
Web Service Discovery
At this point we have our music search Web service registered in UDDI. Now we can use the UDDI inquiry API for Web service discovery. The music search UDDI application demonstrates how to use the UDDI inquiry API. You can start the application by invoking the
run.bat make_uddi and
run.bat run_uddi commands from the tutorial bin directory. It will prompt you for your demo business name and the name of an artist or CD album title that you'd like to search for. The application will query UDDI to discover the music search web service and then dynamically use the service to search for the music.
Figure 3: The UDDI Discovery Form
You can find the source code of this example in
srcdemofreedbUDDIMusicServiceFactory.java Java source files. This simple example queries the UDDI registry before each invocation. A real-life application would normally cache the service information, and so would only query UDDI once at startup or only if the Web service connection parameters (URL) expire.
In this tutorial we learned how to publish and discover Web services using a UDDI registry. We first introduced the basic UDDI data model, including Business Entity, Business Service, Binding Template, and tModel, and explained how they work together. Then we showed an example of programmatically interacting with UDDI using the publishing and inquiry APIs.
REQUIREMENTS: We assume that you have a Java 1.4 or later SDK and a standard HTTP browser installed on your system and the JAVA_HOME system variable points to the Java root directory.
If you want to follow along with the demo, you'll need to download WASP Server for Java, 4.0. You'll need to register but WASP Server is FREE for trail and test, and a single CPU licence is also free for end-user commercial use. Unpack the downloaded package to a local disk and run the
install script from the bin subdirectory of the WASP Server installation. You'll need to agree to the product license and then please answer with default options to all installation questions (simply press Enter multiple times).
IMPORTANT: Please set the WASP_HOME environment variable to point to the WASP Server root directory.
You'll also need to download the tutorial sources and unpack it on the local disk.