UDDI at a Glance

The UDDI is a registry and a protocol for publishing and discovering Web services. As Web services are a standards-based, open, and platform-independent means of accessing the functional capabilities of other companies, UDDI is the associated standards-based, open, and platform-independent means of publishing and locating these services. The latest information about UDDI and the UDDI community can be found at http://www.uddi.org.

As more and more companies start driving toward a services-oriented architecture, and Web services in particular, for their enterprise application infrastructure, the issue of locating Web services becomes increasingly important. When companies initially began experimenting with Web services behind the firewall, there was no question of locating or discovering services as each company controlled everything both the services and the consuming applications.

As these experimental applications were migrated across the firewall, the services they consumed were augmented to include Web services from a handful of partner companies. All of the necessary information about these services was known a priori, and still the need to discover services was unnecessary.

As these applications were further scaled, there emerged a need to answer questions such as: Which business partners have this service? What types of services do these partners offer? As more business partners adopted Web services, the process of obtaining these answers became difficult, not to mention time consuming. The old methods of jointly agreeing on services and their interfaces were no longer feasible. Neither was manually calling up business partners to get a list of their latest service offerings.

There emerged a need for a registry where service providers could publish not only a list of their services but also information necessary to use the services. At the same time, businesses could search through the registry to discover these service providers and their services. These are the underpinnings of UDDI.

Analogies with Telephone Directories

UDDI shares some striking similarities with telephone directories (e.g., yellow pages). As such, the analogy is an effective vehicle for describing the capabilities and usefulness of UDDI.

A phone book allows people to search for other people and businesses, get their contact information, and then directly contact the person or business. Phone books allow various modes of searching, whether it be an alphabetical listing of people or business names (as in the white pages) or through categories of businesses.

Anyone can view the listings of a phone directory; in fact, the more people who view and use the phone book, the more valuable it is. However, only the phone company or its authorized agent publishes the phone book. When adding or updating entries, the requester must validate his or her identity and provide evidence that he or she has the right to add or change the information.

The importance of phone books grows as the need to locate more people and businesses increases. When there are just a handful of people and businesses and few new additions, phone books are not as important. It is easy to keep track of contact information, or gather the information when necessary. However, as the base of people and businesses becomes large and there are continuous changes both in people and businesses being added or removed from the listings or their contact information changes phone books become critical. They provide a centralized source for contact information.

UDDI is quite similar. Instead of a directory of telephone numbers, UDDI is a directory of Web services that are available from different vendors. UDDI provides a means of adding new services, removing existing services, and changing the contact (i.e., endpoint) information for services.

Most UDDI implementations also have some of the same constraints as phone books. Only authenticated users (e.g., service providers) can add or change their information on the UDDI registry. Non-authenticated users are not allowed to change any information on a UDDI registry, and only authenticated users can change their own information. This policy prevents maliciously motivated changes to UDDI entries. Any user can access a UDDI registry for read-only purposes.

Both telephone directories and UDDI registries provide a means to locate a vendor or provider of a particular service. For telephone directories, contact information is basically a phone number and perhaps may also include an address. Contact information in a UDDI registry consists of information about the service provider as well as technical information about the Web service itself. Conceptually, the information available in an UDDI registry is similar to that in the white, green, and yellow pages of the phone book. In UDDI, the segmentation of information that is available and searchable can be thought of as follows:

• White Pages: Contact information about the service provider company. This information includes the business or entity name, address, contact information, other short descriptive information about the service provider, and unique identifiers with which to facilitate locating this business.

• Yellow Pages: Categories (taxonomies) under which Web services implementing functionalities within those categories can be found.

• Green Pages: Technical information about the capabilities and behavioral grouping of Web services.

How are people supposed to use an UDDI registry? First, let's look at how people use telephone books. When using the phone book to contact a business, the user has a product or service in mind. From her past purchases, she may also have a few businesses in mind that sell that product. The user looks up these business names to find their contact information. Otherwise, the user searches through product categories to locate a vendor. Once she has identified a suitable vendor, she looks up the corresponding phone number and contacts the vendor.

What if there are multiple possible vendors? How does a user determine the winner? The winning vendor may be chosen based on price. The user may prefer to do business with a particular vendor if she has done a lot of business with the vendor in the past. The user may shy away from a vendor because the vendor has been unreliable or has delivered shoddy product.

Using a UDDI registry is similar to using a standard telephone directory. Users will search through the UDDI registry for an appropriate Web service that meets their needs. The search may involve a straightforward name lookup, or may involve searching through the taxonomies (service provider categories) provided by the UDDI registry. What do you do when there are multiple Web services that may potentially meet your needs? You have to pick a winner based on whatever metrics are important to you. These may be cost, personal preferences, or other business relationships.

Figure 4-1 depicts the similarities between telephone directory books and UDDI registries.

Figure 4-1. Similarities between (a) telephone directory books and (b) UDDI registries.

Although there are strong similarities between these, there are some places where the analogy breaks down. First, each Web service implements a unique API. Although this is not by specification, it is statistically unlikely that two independent programmers will define and implement the same programmatic interface. Unlike different phone numbers that merely provide unique identification or routing information for phone calls, different Web service APIs are more analogous to using a different and unique phone number for communicating with each person or business.

Second, people will not typically interact directly with UDDI registries as they do with phone books. This is because the information available on UDDI is not people-friendly. Instead, portals and software tools facilitate access to UDDI registries. Many of the same middleware and application development tools that support Web service development allow users to easily add new services to the UDDI registry. These and other tools also allow browsing through the services on UDDI, and many augment the information available on UDDI with their own analysis. This analysis may include quality-of-service information and additional information helpful in using the Web services.

Another key difference is that within organizations, UDDI will probably be accessed by two different groups of people. Unlike phone books, interactions with UDDI require an understanding of more issues. For example, which Web service to use for a particular application is not only based on technical needs and QoS requirements, other strategic and business issues also come into the mix. There may be existing relationships between two companies that require the use of a particular company's Web service over that of another. Or, it may make strategic sense for a company to use a particular Web service, even if other technically superior Web services exist. As such, a unique interaction of business issues together with technical issues comes together to determine which Web service to use for a particular application. Since most technical programmers are usually not party to such information, business analysts with an understanding of strategic business issues typically will select Web services by searching through UDDI registries and other related information portals. A programmer will then search the UDDI registry for that particular Web service's API, and implement the communications between the application and that Web service, as depicted in Figure 4-2.

Figure 4-2. The typical roles played while interacting with an UDDI registry.

A critical point to remember is that business issues are quite fluid. The dynamics of most business environments result in rapidly changing relationships. This, in turn, results in continuously changing or at least evolving business-driven requirements. Flexibility in selecting and consuming Web services is important.

It is a common misconception that applications can themselves dynamically select and consume Web services. Although one day software may become sufficiently smart to do this, today selecting and consuming Web services requires some degree of human intervention. Some simple cases of automation do certainly exist, but automating the process in a general sense is not available today. Why not? Because each Web service implements a unique API that requires programmatic and perhaps architectural changes to the consuming application. Moreover, automating the process of selecting the appropriate Web service to consume is difficult and dynamic. Some newer tools support the use of business rules to automate (at a higher level) the process of service selection. Nonetheless, some level of human intervention is necessary.