How UDDI Is Playing Out

Now that we have an understanding of the need that UDDI aims to fill, some of the core data structures of UDDI, as well as the variety of the means of communicating with an UDDI registry, it's worth taking a step back to see how UDDI is really playing out. How UDDI will truly be used by companies will determine how, when, where, and why businesses will register their Web services.

Up until now our discussion of UDDI has focused on its analogous behavior with standard telephone directory books: UDDI provides a listing of businesses and the services each business offers as well as a means of searching and discovering Web services to use within consuming applications. Since this usage of UDDI is during the design of applications, it can be referred to as the design-time use.

But, will people really use the UDDI APIs during design time? Are people using it today? The answer is not really, and it does not look like it'll change any time in the foreseeable future. Most developers don't programmatically search UDDI for Web services to consume.

Will this change in the future? Most likely not, because selecting which service to consume is difficult. It's not technical issues, but instead business and strategic issues that make the selection process difficult.

In selecting a Web service to use, there may exist business relationships and legal agreements that have to be honored. This may sometimes involve selecting a technically inferior service in order to meet such obligations. There may be pending customer deals that can be closed by using a particular vendor's Web services. A company may attempt to pressure another company by withholding patronage of the latter company's Web services.

Basically business, strategic, and sometimes political issues come into the service selection process. Replacing human intervention through a programmatic API is usually insufficient, and oftentimes grossly so. Because of the wide mix of issues that are often involved, technologists alone will also be insufficient. Accordingly, business analysts, consultants, and other such people (possibly in conjunction with technologists) will usually be responsible for the Web services selection process. These business analysts and consultants will not use the direct programmatic interface of UDDI to search for available services, but instead will use more human-friendly means. These include Web services portals, the home pages provided by some of the UBR node operators, and standard search engines. Of course, word-of-mouth and other such non-technical means will also be prevalent. So, for all intents and purposes, UDDI's programmatic API will probably play a minor role during the design of applications.

If not in the design of applications, where will UDDI play a larger and more prominent role? Although seldom mentioned and even less understood, UDDI has a role larger than just at design time; UDDI is also useful at run time.

UDDI and Lifecycle Management

To understand the usefulness of UDDI at run time, consider the issues that developers and companies have to grapple with after they have developed a Web service or an application that consumes Web services.

Once a Web service has been developed and deployed, it not only has an interface specification but also a network location (usually a URL) associated with it. Over time, the deployment that had sufficed when the service was new and relatively under used, may require changes. This could include migration of the service to a new server. Multiple geographical mirror servers may also be deployed as the need to scale the service increases, or a new server location may be launched while the original one is taken offline for maintenance. The organization or division maintaining the Web service may be relocated or sold, thereby necessitating an update to its access endpoint information. How can these changes be propagated to applications that have already been designed to consume the original Web service? Without appropriate dissemination of such changes, applications consuming the original service can malfunction or produce erroneous transactions.

An application that consumes Web services has to contend with similar issues. Once an application has been written to use a specific Web service for a particular part of its functionality, the application's capability with respect to that part of its functionality is dependent on the Web service. If the Web service goes down or is unavailable for some time, that part of the application will also not function, possibly causing erroneous behavior throughout the application.

Applications based on Web services need a mechanism to stay updated with the latest access endpoint information, including changes to older endpoints, for a particular Web service. It is precisely in this need for lifecycle management of applications and Web services where UDDI can play a critical role. Web services need to disseminate changes to applications that call them. Applications need to be made aware of these changes. UDDI can play the runtime broker or middleman in handling and propagating these changes. The steps in this lifecycle management scenario proceed as follows:

1. Locate a Web service that fulfills the application's needs using whatever means that are useful, including portals, service aggregators, or programmatically with an UDDI registry directly.

2. If the Web service was not initially discovered within an UDDI registry, locate the same service within an UDDI registry and save (e.g., in a database) the bindingTemplate information.

3. Develop the application to consume the Web service using the information from the saved bindingTemplate information.

4. If the Web service call fails or exceeds an application-specified time-out, query the UDDI registry for the latest information on that Web service.

5. In case the original Web service call failed, compare the latest binding information for that Web service with the saved information. If the latest binding information for the Web service is different from the saved information, then save the new binding information, and retry the Web service call.

6. In the case that the original Web service call exceeded a time-out, compare the latest binding information for that Web service with the saved information. If the information is different or newer access endpoints are available, select another endpoint. The selection procedure may be manual in which the application allows the user to manually choose, or it may be automatic.

In this scenario, UDDI plays a critical role in maintaining the reliability and quality-of-service of both applications and the Web services they consume throughout their lifecycle.

The subset of a simple application that demonstrates the use of UDDI at runtime is shown in Figure 4-8. This code snippet uses the UDDI4J client-side Java API, does not do any error checking and also assumes a simple binding described by the UDDI registry.

Once a Web service invocation fails, the application tries to determine whether the binding information for the service has changed. If it has changed, the new binding information can be incorporated into the Web service call and the service can be retried. Otherwise, an error has to be thrown notifying the user that the service is unavailable.

The application begins by retrieving the binding information for the saved binding key by using the get_bindingDetail method. From the BindingDetail object, the program extracts the latest access point URL for the Web service. By comparing the latest access point information stored in newAccessPoint with the original access point information stored in accessPoint, the program is able to determine whether the cause of the service invocation failure was due to a change in the service's binding information. If new binding information is available, the program updates the accessPoint variable with the latest information and sets the retryService to true indicating that the service call can now be retried. If no new binding information is available, then the service is unavailable and there is no need to retry the service call. The program sets retryService to false.

Figure 4-8. Retrying Web service invocations based on dynamic UDDI information.

 // The Web service invocation failed, so check to see //  whether new binding information is available. If so, //  retry the Web service call. BindingDetail bd = proxy.get_bindingDetail ( bindingKey ); Vector btvect = bindingDetail.getBindingTemplateVector (); BindingTemplate bt = ( BindingTemplate )                                  btvect.elementAt ( 0 ); newEndpoint = bt.getAccessPoint ().getText (); if ( thisEndpoint.equalsIgnoreCase ( newEndpoint ) ) {    // In this case, the endpoint information has changed    //  so we should retry the Web service invocation with    //  with the new endpoint    thisEndpoint = newEndpoint;    retry = true; } else {    // In this case, the endpoint information has not    //  changed so there no reason to retry the Web    //  service invocation    retry = false; } 

UDDI and Dynamic Access Point Management

As we've already alluded to, UDDI at runtime can be used not only to get an updated access point URL, but also to dynamically manage and select the most appropriate access point. Oftentimes, a Web service will be deployed on multiple machines that have different characteristics. These characteristics can differ by geographical locations and amount of server resources, including type of network connectivity.

Usually, this variety of service deployments is dynamic, that is, the Web service is initially deployed on a single server. Later, as the service becomes more popular and demand increases, additional access points are deployed. These deployments may be a cluster of servers in close proximity to each other, a geographically distributed set of servers, or both.

A client application that consumes the Web service may have been developed before the additional access points were deployed. Or the best service at the time the application was developed is no longer the best or the most appropriate. For example, the client application may have been developed in one country and later used in another country. Hardwiring the service access point to the one that was selected at design time (in a country other than where the application is being used) will needlessly increase the latency of the service invocation. Mobile applications are most vulnerable to this situation as the application may be best suited to a different access point as the mobile user moves from location to location.

Managing the Web service access points used by a client application becomes increasingly important. It's not that the application will not work with a hardwired access point (assuming the access point remains operational for the life of the application). Instead, the application may potentially work better.

Selecting and managing access points is analogous to downloading files from different mirror sites. A user can certainly download all her content from a single site. But, by judicious selection of different mirror sites, the user can achieve improved performance. The selection of Web service access points can be manual in which the application user is given the ability to choose the actual access point, or the application may automatically select an access point by consulting an UDDI registry. Alternately, the user may specify the high-level characteristics and metrics that are most important to him, with the application using those characteristics as hints in determining the most appropriate service access points. Refer to Chapter 10 for a more in-depth discussion of quality-of-service issues and Web services.

The careful reader will have recognized that some of the benefits of UDDI at run time can also be obtained from alternate means. Using databases, configuration files and other registries are some obvious alternatives. Although other solutions are possible, using UDDI is preferable as it is a standards-based solution with tremendous support from the software industry. The most important benefit of using a standards-based solution with industry-wide support such as UDDI is that almost all Web services can be used. With non-standard solutions, the Web service vendor must also publish its information using the same means used by the application vendor. In cases where a single vendor owns and has administrative control over both the services and the applications, such a solution is manageable. When the service vendors and application vendors are different, a standard solution fosters the use of a variety of Web services.

Figure 4-9 summarizes the use of UDDI at both the design time as well as the run time of Web services-based applications. As the figure depicts, interactions with UDDI at design time will usually include manual intervention from a variety of sources, such as business analysts, consultants, strategists, and technologists to determine the most appropriate Web service. It is important to note that the "most appropriate" service may not be the highest performance service. At run time, however, there is plenty of opportunity to leverage the direct programmatic access of UDDI to build applications that dynamically select the "best" service deployment (from the "most appropriate" service that was determined in the design phase).

Figure 4-9. The use of UDDI at both design time and run time.

In this section, we have discussed just a few uses of UDDI at application run time. Many more uses are possible. In particular, as UDDI matures and more information is made available through UDDI registries, additional opportunities to build more robust and flexible applications will emerge. When developing applications that consume Web services, if developers find themselves hardwiring information particular to a specific service into their applications, alarm bells should immediately sound. They must ask themselves whether it is possible to eliminate the direct dependency on a particular service with an indirect and flexible "brokered" access through UDDI.