Private UDDI Registries

Many organizations may not use external Web services for years to come. Instead, they will use Web services for providing integration between legacy systems, customer relationship management applications, and other internal systems. In this scenario, it makes sense for an enterprise to consider implementing its own private UDDI registry.

A private implementation of a UDDI registry is useful for organizations that need to service-orient their systems. Once legacy systems are service-oriented, they can provide functionality to a specific group of authorized users who may be located within an intranet, extranet, or private network. Implementing a private registry has many benefits, including improving testing and quality assurance and providing a catalog of services for consumption by internal users and a mechanism for discovering services over a private network between business partners.

Private UDDI registry implementations are available from BEA, IONA, Microsoft, Systinet, and the Mind Electric.

Many large organizations and independent software vendors (ISVs) have hundreds, if not thousands, of reusable application components. By creating a private UDDI registry, an organization can register components that can be shared by internal resources. UDDI's success will most likely occur in private usage before widespread adoption of a public registry. Public registries have larger hurdles to overcome, in that they must accept registrations from multiple organizations, provide quality of service and assurance levels, and find methods to collect revenue from the registered applications. Internal registries will most likely be under the control of a single internal IT organization, which makes issues of revenue collection go away. (The authors will ignore internal chargeback models, as we are not bean counters.)

Having your own private registry brings many other benefits. Sometimes it is advisable to restrict who is allowed to view service description information, especially for sensitive services. The organization can not only control who publishes information but can also require authentication. Furthermore, auditing capabilities can be built into a private UDDI registry that allow the administrator to enumerate all clients who have executed the specified find criteria.

A public UDDI registry holds business and service information about organizations from a broad range of industry verticals. The vast majority of the businesses and the services they offer will not be of interest to most clients executing a search. Standard taxonomies used in UDDI may allow you to find a listing of businesses within a particular industry vertical but will not provide you with useful selection criteria. One example may be to search for backup stock quote Web services providers for Flute Bank. We all know that not all providers are created equally and that a simple search based on a classification scheme will not yield the right business results.

Sometimes, for legal or process reasons, you may not want to trust the information in a registry and instead may wish to maintain your own. For business partners where contractual relationships need to be established in advance before using services, it may be a better idea to maintain the registry internally. Many organizations may want to consider using UDDI to ensure that only services from approved and verified business partners are entered in the registry. When a new partner is approved, the appropriate UDDI entries are created. Likewise, when businesses decide to no longer partner, their UDDI entries are removed.

Furthermore, a private UDDI registry, unlike its public counterpart, can be altered to change the basic behavior of many UDDI operations. One example may be a private UDDI registry that requires all find operations to contain a WS_Security, SAML (discussed in Chapter 15) or other authentication header. A private UDDI registry can be further extended to support the following business scenarios:

• Marketplace registries

• Portal registries

• Enterprise application integration registries

Marketplace Registries

Marketplace registries are hosted by industry consortiums that collaborate and compete in a particular industry vertical. Many businesses are cooperating and forming consortiums that allow them to conduct business more easily. Several examples in the market exist today where a marketplace registry would be useful. The Big Three automakers—Ford, General Motors, and Daimler/Chrysler—might want to unify their purchasing power on commodity parts. They could have their suppliers register their businesses in a marketplace registry, to promote competition. The advantage to the big three automakers in doing this is to have only qualified, prevalidated businesses appear as part of their search criteria.

Flute Bank may use a similar tactic to expose its services to previously registered external customers, such as free real-time quotes. The bank can assign each customer an authentication token. When a user visits the Web site, this token is stored as a cookie in the user's Web browser. When a user wants to invoke a Web service, the token is sent along in the SOAP header with any find operation. By taking this approach, Flute Bank can also extend the service to noncustomers. The authentication token can be used to support subscription services based on a number of factors, including, but not limited to

• Number of find operations conducted within a specified period

• Number of results returned as part of the search criteria

• Total amount of data returned in bytes of the search criteria

• Restricting the search to specific times of day

Using a registry in this manner is appropriate when you require metadata about services to be validated in advance. It is limited to a particular industry or group of users.

Portal Registries

The Internet as used today was primarily meant for humans. Only in specific instances do the Internet and its underlying protocols enable computer-to-computer interaction. Many Internet standards have been extended to support interoperability at the protocol level, which is really how bits are transmitted on the wire. However, computers today do not understand the meaning of the bits. One of the goals is to solve this dilemma by creating the semantic web. The semantic web provides guidance on how to facilitate integrating human and computer tasks and how to incorporate the meaning and context in which a transaction belongs. Interoperability of tasks such as searching would be more useful if computers being used understood the semantic knowledge of the data. Additional information on the semantic web is covered in Chapter 17.

Flute Bank currently maintains a presence on the World Wide Web at www.flutebank.com. The bank has also decided to maintain a presence on the semantic web by exposing its private UDDI registry at www.flutebank.com/services/uddi. It uses the portal metaphor.

The bank has exposed its UDDI registry by placing it in a DMZ segment, such that it can be queried by outside parties. In this scenario, Flute wants to allow only find operations to occur over the Internet and wants to restrict any publish operations from occurring. The bank has registered in its private UDDI registry several additional taxonomies to support the organization's procurement policies. External partners can query the bank's private UDDI registry to determine the format of purchase orders as well as the WSDL for the purchase-order service.

Flute Bank has registered itself in multiple public registries. It also populated the discoveryURL element in its businessEntity registration with the location of its private UDDI registry. A partial businessEntity registration example is shown below:

 <businessEntity authorizedName="..."   businessKey="BAB3C425-A2C3-22E1-FA23-AB2324D3BC8" ... >   <discoveryURLs>        <discoveryURL useType="businessEntity">             http://www.publicuddi.com/uddiget?businessKey=BC234221 ...        </discoveryURL>        <discoveryURL useType="urn:uddi-inquiry-api">             http://www.flutebank.com/services/uddi        </discoveryURL>     </discoveryURLs>     <name>Flute Bank</name> ... </businessEntity> 

Using the portal approach to private UDDI registries allows Flute Bank to maintain control over how metadata for the services it offers is used. The bank can extend this approach by restricting who can do find operations based on who the requestor is, such as an authorized vendor specified by the procurement department. In this scenario, Flute Bank can also learn about other organizations and who has expressed an interest in rendering services for them.

Enterprise Application Integration Registries

Enterprise Application Integration registries are used in the same manner as partner registries, except that they contain services available from other departments or divisions within an organization. This form of registry is used primarily by businesses that want to restrict creation of new tModels, businessService entries, and bindingTemplates to a centralized group. This type of registry should never be exposed for external Internet access and should be restricted to internal users only.

Considerations

Here are some of the recommendations and considerations an architect of a Web services initiative should consider before implementing an in-house registry:

• The vast majority of Web services applications will not use a public registry.

• A private registry makes sense for large organizations, such as the Fortune 500, where the number of services created are used across the enterprise and/ or divisional boundaries.

• A private registry makes little sense for a small IT shop, where the number of services will be small and/or used by a few applications.

• If you have either a small number of services and/or small user community, it may make better sense to publish a URL to a WSDL document instead of supporting a registry.

• When implementing a private registry, it is imperative that an organization standardize on a single vendor, hopefully in the same manner as on other corporate standards.