Accessing UDDI

UDDI is itself a Web service and as such, applications can communicate with an UDDI registry by sending and receiving XML messages. This makes the access both language and platform independent.

Although it's possible, it is unlikely that programmers will deal with the low-level details of sending and receiving XML messages. Instead, client-side packages for different languages and platforms will emerge that facilitate programmatic access to UDDI.

Two such packages are UDDI4J and Microsoft's UDDI SDK, which are client-side APIs for communicating with UDDI from Java and .Net programs, respectively. UDDI4J was originally developed by IBM and released in early 2001 as an open source initiative. Later, HP joined and contributed to the initiative, developing much of the version 2 release. With the support of IBM and HP (as well as others), UDDI4J has become the de facto standard Java package for communicating with UDDI registries. More information about UDDI4J, including the latest releases and download bundles, can be found at the UDDI4J Project Web site at http://www-124.ibm.com/developerworks/oss/uddi4j/.

Figure 4-5 shows how UDDI4J facilitates programmatic access to an UDDI registry. With UDDI4J, programmers don't have to concern themselves with either the UDDI API or with forming and parsing XML messages. Instead, a new Java object, UDDIProxy, is instantiated to act as a proxy and represent the actual UDDI registry. Using setter methods, the proxy object is configured with the URLs of the actual registry location, as well as optional transport information. Essentially, using UDDI4J and just a few, simple lines of code, a Java application can open a communications channel to any UDDI registry.

Figure 4-5. Opening a connection to an UDDI registry using UDDI4J.

// Create a new UDDIProxy object to connect to a registry UDDIProxy proxy = new UDDIProxy (); // Set the inquiry and publish URLs proxy.setInquireURL (INQUIRE_URL); proxy.setPublishURL (PUBLISH_URL);

Once we've created the proxy object and set its inquire and publish URLs to the desired UDDI registry locations, we can use the methods that are defined for the UDDIProxy object to access and set various elements within the registry. Usually, programmers will use the find_business, find_service, and find_tModel methods to locate service providers, services, and tModels, respectively, based on search criteria, such as name (including partial names with wildcards) and categories.

Figure 4-6 shows a complete application using UDDI4J to connect to Microsoft's UDDI Business Registry (UBR) inquiry node and locate service providers whose name includes the string "abc". After an UDDIProxy proxy object for Microsoft's UBR inquiry node is set up, the find_business method is invoked to search for available business names that contain the substring "abc". The wildcard character '%' is used to specify that the substring may occur anywhere in the business name. Qualifiers, such as case-sensitive string matching, could have been added to the find_business method to further limit the search.

Figure 4-6. Using UDDI4J to access an UDDI Registry to print out 21 providers that include the string "abc" in their names.

Once the results of the search are returned from the UDDI registry, additional method calls are used to extract the business name, business description, and service names for all matching businesses. This information is then displayed on the standard output. Figure 4-7 shows a selected subset of the output of the application shown in Figure 4-6.

Figure 4-7. A subset of the result of running the application shown in Figure 4-6.

Looking at the output of Figure 4-7, we can see some of the positive as well as some of the negative points of using the UDDI UBR. First, there are many service providers available within the UBR providing an even larger number of services. These are global providers, and some only offer their services in certain locations. Many of the fields of service providers or services are either unfilled or filled inappropriately. Moreover, many of these service providers or services are either non-existent or simply test deployments.

The UBR is a powerful resource that brings together thousands of providers and services in one easy-to-access location. Sifting through this large (and constantly growing) list to weed out useful providers and services from those that are less than useful (or completely useless) is the difficult part. Although client-side packages such as UDDI4J make developing programs to access and interact with UDDI registries easier, the more important difficulty still remains: how to select the right service and service provider for a given task.