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 clashes 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.
Cloud computing is a game changer. The cloud ...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
