Build a Client Application to Access a UDDI Registry

n the first article in this series, you saw how the Universal Description, Discovery, and Integration (UDDI) specification and protocol work together to define messages, application programming interfaces (APIs), and data structures for building distributed registries of Web services. You also saw how to store the business and technical information associated with these services. See the sidebar on this page for a review of UDDI's high-level architecture.

In this article, you'll see how to build a client application that uses your UDDI registry to locate businesses and services stored there, how to anticipate and handle some common errors, and how to understand some standard details about UDDI SOAP messages.

The Sample Application
To illustrate how to use UDDI from a client application, this article uses a simple sample application in which you can retrieve an authentication token from the registry and list the businesses stored within it.

Any secured access to a UDDI registry must be executed within the realm of authorized permissions defined by an authentication token. This token is passed back to the registry whenever a secured operation is requested.

The UDDI Authentication Model
When a UDDI registry operation requires a user to authenticate, an authentication token must be obtained from the registry. An authentication token is retrieved using the get_authToken message.

The get_authToken message can operate on against any backend security scheme, such as a directory service, operating system, or a simple table of UserIDs and passwords.

The example in Listing 1 illustrates how the sample application uses the org.apache.juddi classes to obtain an authToken.