+

Search Tips   |   Advanced Search

Inquiry API for the UDDI Version 3 registry

The Inquiry API provides four forms of query that follow broadly used conventions that match the needs of software that is traditionally used in registries.

The four forms of query are:


Browse pattern for the UDDI registry

Software used to explore and examine data, especially hierarchical data, requires browse capabilities. The browse pattern characteristically involves starting with some broad information, performing a search, finding general result sets, then selecting more specific information for drill-down patterns.

The UDDI API specifications accommodate the browse pattern with the find_xx API calls. These calls form the search capabilities that the API provides. The calls are matched with summary return messages that return overview information about the registered information associated with the inquiry message type and the search criteria specified in the inquiry.

A typical browse sequence might involve finding whether there is any information registered for a business you know about. This sequence starts with a call to find_business, perhaps passing the first characters of the business name that we know. This action returns a businessList result. This result is overview information, including keys, names, and descriptions, derived from the registered businessEntity information, matching on the name fragment that we provide. If the business we are looking for is in this list, we can use the find_service API call to drill down into the corresponding businessService information, and look for specific technical models, such as purchasing or shipping. Similarly, if we know the technical fingerprint, that is, the tModel signature, of a particular software interface, and we want to see if the business we are looking for provides a web service that supports that interface, we can use the find_binding inquiry message.


Drilldown pattern for the UDDI registry

When we have a key for one of the four main data types that a UDDI registry manages, we can use that key to access the full registered details of a specific data instance. The UDDI data types are businessEntity, businessService, bindingTemplate, and tModel. We can access the full registered information for any of these structures by passing a relevant key type to one of the get_xx API calls.

Continuing the example from the previous section, one data item that is returned by all of the find_x return sets is key information. For the business we are interested in, the businessKey value that is returned in the contents of a businessList structure can be passed as an argument to the get_businessDetail message. The successful return to this message is a businessDetail message containing the full registered information for the entity with the key value that is passed. This information will be a full businessEntity structure.


Invocation pattern for the UDDI registry

For an application to take advantage of a remote web service registered in the UDDI registry by other businesses or entities, prepare that application to use the information found in the registry for the specific service being invoked.

The bindingTemplate data that is obtained from the UDDI registry represents the specific details about an instance of a given interface type, including the location at which a program starts interacting with the service. The calling application or program caches this information and uses it to contact the service at the registered address whenever the calling application needs to communicate with the service instance.

In remote procedure technologies that were previously popular, tools automate the tasks associated with caching, or hard coding, location information. However, there are problems when a remote service moves and the callers do not know about the move. There are many reasons why a remote service might move, for example, a server upgrade, disaster recovery, service acquisition, or a change to the business name.

When a call fails using cached information previously obtained from a UDDI registry, the correct behavior is to query the UDDI registry for fresh bindingTemplate information. If the data that is returned is different from the cached information, the service invocation can automatically try the invocation again, using the fresh information. If the result of this retry is successful, the new information replaces the cached information.

By using this pattern with web services, a business that uses a UDDI registry can automate the recovery of a large number of partners without unneccessary communication and coordination costs. For example, if a business activates a disaster recovery site, most of the calls from partners fail when they try to invoke services at the failed site. By updating the UDDI information with the new address for the service, partners who use the invocation pattern automatically locate the new service information and recover without further administrative action.

  • UDDI Version 3.0.2 Specification