Browse Pattern

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.

Drill-Down Pattern

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.

Invocation Pattern

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.