Bringing Order to Enterprise Service Proliferation

http://webservices.sys-con.com/read/39869.htm

UDDI has been around for almost three years now. It has gone from an initial proposal by three companies (Ariba, IBM, and Microsoft), to a consortium effort (www.uddi.org) with a community of hundreds, and finally into the hands of the OASIS standards body. Along the way, the original specification has gone through two additional revisions. Perhaps more important, with each new revision the business value of UDDI has shifted from being a registry of public services to a central fixture in private EAI and partner-integration efforts.

The most recent version of UDDI, V3, continues this trend by making UDDI more usable as a common service registry inside an extended enterprise and between partners. Thus this technology, originally designed for publishing and discovering Web services, can today be leveraged by enterprises to provide a complete solution for managing access to Web services including subscription control and endpoint indirection.

Is UDDI Only for the Public Internet?
Along with SOAP and WSDL, UDDI is considered one of the three "pillars" of Web services technologies. Unfortunately, it is probably the least understood, at least initially. At the root of the various misconceptions about UDDI is the schizophrenic nature of the specification. The UDDI idea initially (and to this day) encompasses two very distinct concepts. The first one is the concept of a universal, online business registry, the Universal Business Registry (UBR), maintained and operated by a set of impartial operators along the lines of the DNS infrastructure. It is hoped that this UBR will act as some form of universal, multilayered "phone book" for registering businesses and the services they provide across the world, (for good or bad, this "universality" is baked into the UDDI name). This is the concept most people know about, and the one that is the most discussed, at least by the various UDDI naysayers. It is also perhaps the one least relevant to business, and just one incarnation of the more important concept behind UDDI: that of a generic services registry based on a set of open, standards-based, data structures and a set of SOAP-based APIs to programmatically register, organize, and find services and their descriptions.

Where UDDI is seeing its greatest adoption and showing greatest value is inside the enterprise. There, with some minor enhancements, it can bring security and flexibility to the process of publishing, discovering, and subscribing to internal services. The alternative is a disorganized soup of services that are published by local teams without any central organization, security, or management. With UDDI V3, the necessary functionality now exists for UDDI to take its place as core enterprise integration infrastructure.

UDDI Basics
When UDDI was first released, the concept of registries was by no means new. Corporate IT departments had been using naming and directory services for some time and several vendors had commercial registries on the market. The difference was that UDDI proposed an open collaborative effort to produce a standards-based registry that was not controlled by any vendor. Requirements for a registry are well understood: a data model for the metadata and a set of CRUD operations on these structures. The data model has to enforce ownership and containment requirements; a logical, consistent referencing system for the containment relationships; and a classification taxonomy to simplify searching. The CRUD API has to enforce security or authentication for operations that change data, and provide a query language for searching and retrieving data. The requirements that went into designing UDDI are no different.

UDDI has been described in detail in many articles and books but it would be helpful for us as a baseline to go over its structures and API. The UDDI data model has four main elements: businessEntity, businessService, bindingTemplate, and tModel. Use of the word "business" in two of the elements is unfortunate, but it should not be a deterrent since the pattern of registering and querying entities and the services they provide is useful, regardless of the name of the elements. Actually, with the proper XML transformations, the UDDI data model can be reused for a variety of purposes by changing the names of the elements.

The containment model is very simple: business entities can contain a set of business services; business services have binding templates that provide implementation details for the various implementation flavors of the business service (e.g., Web browser-based or e-mail- based implementation of the same basic service); and finally tModels provide the reference or namespace mechanism used in the description of how to access these services.

The tModel concept is extremely important in understanding UDDI. You can think of it as a set of technical signatures that are assigned to services to facilitate searching and categorization. A set of tModels has already been established to represent some of the more important technical concepts such as HTTP or SOAP. As an example of how they are used, consider a service that is accessible through SOAP over SMTP: it would be labeled, among other tModels, with the SOAP and SMTP tModels. When searching for a particular service to access through SOAP over SMTP, the search can be restricted to entries labeled with those two tModels.

Another important use of the tModel is as a namespace. An industry group, for example, can create their own tModels to designate business processes and services that are provided by their members; in this case, searches can be restricted to services within that namespace by using the appropriate tModel as a qualifier.

The UDDI API has two subsets: an authenticated Publishers' API to save, update, delete, and manage entries with security token management; and an open Inquiry API to find entries and get detailed content from them. In addition to the data model and the API, the UDDI specification allows the use of taxonomies for organizing the entries space and searching through it. Three taxonomies, for businesses, products and services, and geographic location, were originally specified.

UDDI V2: Becoming Enterprise Friendly
The UDDI v2 specification provided some additional flexibility in the UDDI usage model, mainly in providing the capability to add third-party taxonomies to the three that were already part of the specification. This provides enormous flexibility for organizations, whether private companies or consortia, for example, to define their own taxonomies and overlay them over other taxonomies. Another important concept introduced in v2 is that of business relationships through so-called publisher assertions. This allowed businesses (or organizations) to indicate that they are related through a partnership or other affiliation. Along with the additions to the data model, V2 introduced some changes to the API to handle the new data structures and relationships.

UDDI V3: Built for the Enterprise
The original UDDI specification was mainly concerned with enabling a set of central universal registries and some of the constraints reflect these concerns. For example, the original specification required operators to issue unique identifiers for every registry entry. These identifiers took the form of UUIDs, and could only be generated by the operators, in order to avoid *****es and inconsistencies in the identifier namespace. This is a perfectly acceptable restriction in the case of one universal registry, but becomes unworkable when several independent registries need to share information as is common inside the extended enterprise.

An example enterprise scenario facilitated by UDDI V3 but not its predecessors occurs when Web services are being developed internally and published to a test registry. Once these services become operational, they have to be migrated to one or more operational registries, whether internal or external. Once propagated, the integrity of these registry entries needs to be ensured against tampering, since the single UBR, with its trusted operators, is not being used. This scenario touches on several important requirements that were taken into account for V3, namely the ability to share entries between registries, while maintaining the referential integrity of the assigned keys; and the ability to sign and certify registry entries.

The V3 specification provides many new features, but the significant ones are geared towards making UDDI registries into more of an enterprise-class IT infrastructure by addressing some of the issues above. These improvements can be grouped under three main categories:

General extensions:

Publisher-assigned keys: In versions 1 and 2, the role of assigning unique keys for every entry in UDDI fell to the registry operators. While essential for the integrity of the registry, this constraint made copying entire entities from one registry to another, while maintaining the unique key, impossible. V3 does away with that constraint, in order to support multi-registry environments. Using the Publishers' API, publishers can propose their own keys while publishing entries to new registries. This is called entity promotion from one local UDDI registry to another, and depending on its policies, a registry might not accept the suggested keys. Of course this creates its own complexities in terms of referential integrity of the keys. That's why three new and important concepts were introduced: support for root and affiliate registries; support for human-friendly URI-based keys; and support for digitally signed entries.

Federation of registries: In order to support inter-registry data sharing while avoiding key collision, V3 now supports the concept of federated UDDI nodes, with a root registry and a set of affiliate registries. Publisher assigned keys are now scoped only within a hierarchy of UDDI nodes. Data from within the hierarchy can be freely moved around while conserving the uniqueness quality of the keys.

Human-friendly, URI-based keys: in order to facilitate inter-registry data copying, the restriction for generating unique identifiers (UUIDs) for entries was relaxed, and a new format of identifiers was introduced, similar to the DNS format.

Support for digital signatures: Although the Publishers' API (allowing the creation, deletion, and editing of entries) has been authenticated since V1, entries can be misrepresented by third parties, or errors introduced by copying them to other registries now that entries can be moved about within a set of federated registries. V3 allows entries to be signed digitally, for an enhanced level of security and integrity. Digitally signing an entry allows users who receive the entry to be certain of its origin, and that it hasn't been tampered with.

Support for policies: V3 registries now support policies that outline authorization models, audit policies, and confidentiality policies, among others.

Information model extensions

Improved WSDL support: Until V3, a WSDL document had no special status in describing a service. Through the introduction of the useType attribute to the accessPoint element, WSDL documents can now be queried and retrieved directly.

Added categorization capability for the bindingTemplate element: Implementation details can now be searched using the same taxonomies used for businesses and services.

Extended discovery

Support for complex queries to be consolidated into single queries through the use of nested queries

New and extensible find_qualifiers with extended wildcard support

Management of large results sets

So What's Still Missing?
Taking all these improvements into consideration, the UDDI V3 specification provides an infrastructure that, in keeping with the spirit of UDDI, provides a flexible and extensible framework for Web services without actually specifying the detailed scenarios. However, two important issues have not been addressed by the specification. Consider the scenario where an organization is using a private UDDI registry to provide internal services for its IT department, and to provide a registry of interfaces for trusted business partners for the purposes of integration. This is probably the most common use of UDDI today and for the foreseeable future. For security and functionality, such usage would have to be through a proxied UDDI registry and would impose two additional requirements on any UDDI implementation.

Access control on the Inquiry API: In keeping with the original intent of a "universal" registry, the current Inquiry API is completely open, and only the Publishers' API is authenticated. In the scenario above, the organization will require an authenticated Inquiry API to control access to its registry, whether the requests are coming from inside or outside the firewall. This is a relatively simple requirement that can be added to the existing specification by adding an access control layer to the implementation.

Customization of the query returns to the requester: Even an access controlled UDDI registry is not completely functional in the scenario above. Typically, different departments will have access to different services. And even when they have access to the same services, they might have different endpoints or they might expose different interfaces. This is even truer in the case of external partners. In these cases, providing some access control to the UDDI registry is only the first, and simplest, step in proxying it in terms of security. What is required is a mechanism to present different results to the same query based on the requester. For example, as a result of the same binding detail query, platinum-level partners will get a WSDL that exposes a richer interface on a particular service than gold level partners, and might even expose a different endpoint.

While these capabilities may seem minor they represent the bedrock of creating a secure and flexible Web services infrastructure. Without these capabilities there is no way of controlling and personalizing access to the various services published on the UDDI v3 registry, an important aspect of current and future Web services usage. The good news, however, is that when combined with a Web services security and personalization technology capable of proxying both WSDL and UDDI, UDDI v3 can be employed by enterprises to manage the entire service publishing and subscription lifecycle at the center of service oriented integration.

Published September 26, 2003 — Reads 960
Copyright © 2005 SYS-CON Media. All Rights Reserved.