One of the chief advantages of a private registry is access control. Only the members that share the private registry can/will typically have access to a private registry. This means that the members can divulge a limited amount of potentially confidential data to be shared among the members. Sharing of such data may be essential for functioning facilitated by the registry.

The UBR has specified its own set of operational and functional policies. These policies are specified in the Operator Specification document. A UBR operator is bound by a contractual agreement to abide by these policies. These policies may not always be suitable for a company or a solution it is trying to put in place. A private UDDI instance will enable the organization to set and enforce its own policies to use the registry. For example, by default, the Microsoft UBR instance does not allow multiple business entity registrations per user account. A private registry owner, on the other hand, may not enforce such a restriction at all or may allow business entity registrations up to a certain limit.

A private registry owner can define its own set of organization rules above and beyond those specified by UDDI. This can ensure that the organization is commensurate with the needs of the community or solution using the registry. For example, a private registry that is used among several companies may have an organization structure where the name of the service or tModel must be in the for-mat company name:location:functionality name:version. Using such a hierarchical structure, it will be easy to find all the services that cater to a specific zip code or all versions of a certain interaction specification. Note that on UBR it is possible to create such a naming scheme, but it is not enforceable. The other use of customizable organization is creating synonyms for resources, as discussed in Section 10.2.

Currently, several companies including Microsoft, IBM, and Oracle provide a private UDDI registry that a company can implement.

The UBR today suffers from a lot of data that is stale. Since any registered user is allowed to publish business entities and services, there are several registrations that are phony, i.e., being used for testing purposes. A private registry can enforce information sanity by ensuring a strict process for registering any resource on the registry — even by the members. The process through its checks and balances can ensure that the data available on the registry (such as access points to services) are fresh and may enforce the freshness of data through contractual agreements.

When a service-user organization needs certain functionality and has decided on the service provider (and the service instance within), the reference to concerned entities can be imported from the UBR or other UDDI registry. The reference can then be kept in a local private UDDI registry.

Reference import functionality also lets the service-user organization organize the references in a way suitable to its usage model. It could, potentially, create its own taxonomies, tModels, and other data structures and save the references using that organization. For example, if there are multiple specifications defined for interacting with a 401(k) service, a user can search services that comply by different specifications and save the found services under its own my401kTModel. It could also save the found services under its own naming scheme. Of course, the real data must kept as well to resolve the synonym to the real resource.

This private registry can be thought of as a repository of all the services that an organization uses during its day-to-day operation. Figure 10.1 depicts this scenario.

Figure 10.1. Reference importing.

Just as a service-user can import the service reference from another UDDI registry, a publisher can export service references to other registries.

A reference export mechanism is somewhat less intuitive than the reference import mechanism. One application of this mechanism could be the way a publisher manages its services. All the deployed services can be published within the publisher’s private registry and appropriate instances could be exported as they are made public. Reference export could be used for versioning and service migration, as explained in the next section. Figure 10.2 depicts this scenario.

Figure 10.2. Reference exporting.

In the previous examples, we use taxonomies that are built in the UBR registries. For example, the business entities are classified under ntis-gov:naics:1997 taxonomy, which represents North American Industry Classification System (NAICS). The service interaction specification TM401k uses the uddi-org:general_keywords taxonomy, which represents the generic taxonomy where keyword values are used to classify resources. As discussed in Chapter 6, when designing a registry-based solution, the designer must decide if the existing set of taxonomies and identifier systems are sufficient for the solution. If required, a new set of taxonomies and identifier systems must be designed, published, and employed in the proposed solution.

The ubiquitous tModel resource is used to register taxonomies and identifier systems as well. Given the multi-faceted role of tModels, it is essential to distinguish the tModels from each other. UDDI provides a special taxonomy to classify the tModels themselves. This taxonomy, uddi-org:types, is commonly referred to as the UDDI Type Taxonomy.

The UDDI Type taxonomy defines a predefined set of categorizations that can be used to denote what a tModel being registered is associated with. When registering a tModel, the UDDI Types taxonomy must be associated with key values that signify the type of tModel. For a taxonomy tModel, the value categorization should be used during registration. The corresponding XML message will be as follows:

<tModel authorizedName="..." operator="..." 
   tModelKey=""> 
  ... 
  <categoryBag> 
    <keyedReference 
       tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" 
       keyName="uddi-org:types" 
       keyValue="categorization"/> 
  </categoryBag> 
</tModel> 

The UUID mentioned in the XML segment is associated with the UDDI Types taxonomy. Table 10.1 describes all the types defined in the UDDI Types taxonomy. When registering a tModel, corresponding values can be used to classify it appropriately. Note that it is not mandatory for a publisher to use the UDDI Types taxonomy for categorization. However, doing so helps in the proper representation of the tModel in the UDDI registry. Also, other users of the registry get a more refined view of the tModel.

UDDI specification provides further refinement of taxonomies registered through the UDDI Types taxonomy — checked and unchecked. This provides a clear distinction between tModels that are more formal than others. A checked taxonomy undergoes more scrutiny and has a more formal set of requirements than an unchecked taxonomy.

<categoryBag> 
  ... 
  <keyedReference 
     tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" 
     keyName="uddi-org:types" 
     keyValue="unchecked"/> 
  ... 
</categoryBag> 

With continuation of service offering being the most important aspect of versioning, having new and old versions compatible on a common set of terms and values is most logical. In practice, it is always a balancing act to keep two versions compatible at a very granular level. The Versioning Taxonomy and Identifier Systems introduces the notion of upward compatibility among versions of a tModel repre-senting a taxonomy or an identifier system. This upward compatibility is based on the codes associated with the concerned specification.

The best practice behavior is to always keep taxonomy or identifier system upward compatible. In such a case, the associated tModel is simply updated to reflect the new version and republished under the same key. In reality, however, there will be situations when this is not possible at some times. In such a case, several migration steps can be taken to ensure operational continuation.

Through these mechanisms, tModel versioning can be made a smoother experience. Note, however, that for a smooth transition, the tModel provider needs to implement these steps diligently.

Service versioning issues are similar to the tModel versioning issues discussed previously. The operational continuance has a rather broader impact, due to contractual bindings around quality-of-service specifications.

The tModel versioning scheme discussed above could be modified for service versioning. Since, unlike tModel, services can have a much wider range of purpose, the precise steps in the process will be highly dependent upon the functionality provided by the service.

Service or tModel versioning can be facilitated through reference exporting. As explained in Section 10.2, a tModel or service provider can export references to the concerned resource to a UBR or other publicly available registry. When introducing anew version, the provider can first make it available on the local registry and then once it is tested and ready for use, publish it to the public registry. If the new version is upward compatible, the new version will register under the existing registration key, otherwise a new registration key can be requested. The older version can then be supported only at the local registry for interested customers.

As explained in Section 5.2.1, currently the UBR provides a “public UDDI infrastructure” that can be used as a means to test drive registry-based business processes. Figure 10.3 depicts this scenario.

Figure 10.3. UDDI Registry as UBR.

The UBR cloud of registries provides a uniform view across all registrations made at any node within the UBR. Note that this current usage pattern of the UBR is not likely to be the final usage pattern. As UDDI security policies and information sanity policies evolve, more sophisticated usages of the UBR may result.

The notion of UDDI as a meeting point between service providers, service consumers, consortiums, and other standards bodies, is the basis for UDDI as a market exchange. However, the market exchange is a specialized and focused instance of private registries that are deployed to facilitate a specific industry.

Policies and information specific to the industry can be loaded into the exchange to ensure a smooth and efficient exchange of information. Market exchanges are likely to restrict access to only certain entities, for example, industry participants. Focusing on a specific industry or segment makes the market exchange a magnet for those trying to reach that particular audience. Thus, a service user will find a host of industry-specific services and businesses for its service portfolio. To ensure efficient querying within a market exchange, industry-specific taxonomies and search qualifiers may be deployed that “speak the industry jargon.” An example of a market exchange could be a chemical exchange that brings together chemical industry traders and buyers. Figure 10.4 depicts the market exchange scenario.

Figure 10.4. UDDI as a market exchange.

Market exchanges can also provide additional services that make interacting with the exchange more useful. For example, rating services that allow third party agencies to rate various service providers might be important in certain industries.

In Section 10.2, we discuss the concept of caching (import and export) a reference to a specific service found in an external registry. A private registry instance can be deployed within an ecosystem to house either the services meant for export or to house those cached entries for quick access to these frequently used services. Figure 10.5 depicts this usage pattern.

Figure 10.5. Reference caching.

Portals have become a common component of most companies’ technology landscape. Two main flavors of portals exist: intranet and Internet. Intranet portals often house information specific to the employees of the company. Internet portals often house company information specific to interested external parties, i.e., customers, press, and so on. Another type of Internet portal is a service-aggregating portal. The my.yahoo.com portal, for example, collects several types of services and allows users to customize their portal experience. A third flavor, which is essentially a hybrid of the intranet and Internet portals, is that of a virtual private portal. This type of portal is often external to the company but allows only limited access to partners, for example.

A UDDI registry can provide the services that are offered through these various portals. Figure 10.6 depicts this usage pattern. Chapter 11 expands on the concept of UDDI-powered intranet portals.

Figure 10.6. UDDI as a portal facilitator.

Web services promise to assist corporate Information Technology (IT) departments in linking their numerous enterprise applications. A typical large enterprise might have upward of eight hundred different applications. Imagine trying to deploy or orchestrate a business process on this infrastructure. While many enterprise application integration vendors exist to solve this problem, Web services also provide a technology to integrate these applications. The role that UDDI plays in this scenario is two-fold. As Web services are deployed within corporate boundaries, they can be published to the UDDI registry. The UDDI registry then acts as the library that applications are written to interact with to ensure the appropriate services are used.

A second role the UDDI registry plays is that of business-to-business integrator. Services ready for external consumption (by authorized parties) can be exported from the UDDI library and imported into an external facing UDDI registry deployed as part of a virtual private portal. Figure 10.7 depicts this usage pattern.

Figure 10.7. UDDI as EAI and B2B facilitator.

We have viewed UDDI from various perspectives: that of a service publisher, a service consumer, and of a solution deployer. Understanding these perspectives is critical in deploying any UDDI-based solution. However, it is also important to see how UDDI solves critical business problems. In the next part of the book, we offer case studies and delve into how UDDI fits into larger business solutions.