UDDI provides an API that allows for the discovery of businesses, the services they offer, and technical binding information, using a request/response approach. UDDI also supports the registration of business entities, services, bindingTemplates, and tModels. Two types of APIs are available. The first is a Publishers API, which is used for interaction between applications and the UDDI registry and provides the ability to create, modify, and delete data contained in the registry. The second is an Inquiry API, which allows applications to query the registry for information.
The Inquiry API provides three patterns that can be used to query a registry: the browse, drill-down, and invocation patterns.
The browse pattern allows users to provide general search criteria, generate a result set, then select one or more of the entries in the result set and drill down into specific entries. In UDDI, a browsing scenario may be to search for information on a particular business you know about to see if it is registered. Maybe you want to search a public UDDI registry to see what services Flute Bank has available to the public. The result set will contain overview information, such as the businessEntities that match the search criteria that were found using the find_ business API.
If you find that the Flute Bank result set returns thousands of services, you can drill deeper into the businessService information, seeking particular categories of services (e.g., investments, loans, calculators, etc.) using the find_service API call. If you happen to know the tModel signature of a product, such as news version 1.2.a1.06, and you want to see if Flute Bank has a compatible service interface, you can use the find_binding API.
UDDI uses the drill-down pattern to locate entities. For example, if you wanted to locate a binding template (get_bindingDetail), you would start your search by locating the appropriate business entity (find_business). From the business entity, you would use the entity's UUID to search for services the entity provides (find_service). If you happen to know the business service's UUID, you can use the find_binding API to locate binding templates for a business service.
When searching for compatible service interfaces using the find_binding API, you could take the returned service key and pass it to get_serviceDetail to learn additional information about the service.
This pattern is typically used through the UDDI Web interface, in which you can click the "find service" action usually displayed as part of finding the appropriate business. The find service will execute in the context of a particular business entity. Likewise, the Web interface allows you to drill deeper, locating entities within the current context as you navigate the registry.
Before Web Services, a typical software development approach for developing cross-application access was to define the interfaces in two locations. In many languages, it could also require copying stub code to various locations. In a Web services paradigm, services can be discovered dynamically and do not require stub code on the client. Instead, a client will search for particular service information and seek its bindingTemplate that contains instance-specific information for the service.
The J2EE blueprints (available at http://java.sun.com/j2ee/blueprints) mention the use of the Service Locator pattern. If we take the best practices and extend them to Web services, we would modify the Service Locator pattern and use an invocation pattern. Ideally, upon querying the UDDI registry for service information, the service locator could cache the bindingTemplate and bindingKey information.
Upon a failed invocation of a service, the invocation pattern could take the cached bindingKey, call the get_bindingDetails API, and get a new bindingTemplate. If the bindingTemplate that is returned is different, the invocation pattern can automatically retry invocation of the service and should update the cache. Using the invocation pattern in this manner allows services to become portable, survive migrations by their service provider in situations such as disaster recovery, and provide high availability. By using the invocation pattern, callers of the service automatically locate new service information without administrative intervention. Caching also helps in optimizing the service environment, by reducing unnecessary round trips to locate services and binding information in the UDDI registry.
The invocation pattern can be extended to support other situations where the basic approach will not suffice. The first scenario that breaks in a Web services paradigm using the invocation pattern is when either an application service provider or network market maker needs to control the values of the binding information.
In the Flute Bank scenario and its order execution system, Flute typically sends information about a particular order to the floor of the New York Stock Exchange. When the floor executes the trade, the exchange may decide to direct Flute to the Web service of the selling broker, to handle the clearing process. In addition, when the stock market is open, Flute always sends orders to the floor. However, when the market is closed, Flute has the desire to be directed to an electronic communication network (ECN), a facility that matches customer buy and sell orders directly through a computer, that currently has the best price to execute an after-hours trade. In scenarios where routing may be based on the time of day or identity of the caller, using retry logic and caching is not sufficient.
One of the benefits of using UDDI in service-oriented architecture is to provide a single point of reference to determine a particular service's location. When the bindingTemplate needs to be controlled by another server in scenarios of routing logic, disaster recovery, or a change of invocation address, you may need to use the accessPoint information in the bindingTemplate structure (provided you have it cached) to determine an alternative partner service.
Figure 6.12 shows the relationships of a bindingTemplate to other UDDI models. The bindingTemplate contains an element named hostingRedirector. An implementation of the invocation pattern inspects the hostingRedirector element, which points to another bindingTemplate that points to the address of a redirector service that will fulfill a get_bindingDetail message.