Simeon Simeonov

Subscribe to Simeon Simeonov: eMailAlertsEmail Alerts
Get Simeon Simeonov via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Introduction To UDDI

Introduction To UDDI

As we look at the evolution of both object and component programming models it's clear that the concept of an object or component registry is an essential element that facilitates the discovery and use of components. Imagine trying to write Java code without access to a browsable set of JavaDocs. If we consider the Web services concept as an evolution of component programming, then for the purpose of service discovery it's necessary to have access to registries of business and service descriptions that can be browsed and queried.

Previous XML in Transit columns discussed the role of Web service discovery from the point of view of both basic and sophisticated Web service usage. Now it's time to look at Universal Description, Discovery, and Integration (UDDI), the specification that governs Web service discovery and the behavior of service registries.

In a marked departure from previous columns that have been a product of my own effort, this and my next few columns will be based on the UDDI chapter in a book I'm writing, Building Web Services, with a great team of Web services experts: Doug Davis, Steve Graham, Yuichi Nakamura, and Ryo Neyama from IBM; Toufic Boubez from Saffron Technology; and Glen Daniels from Macromedia.

In a service-oriented architecture (see Figure 1) the service registries are operated by brokers. Service providers publish service descriptions to the registries; service requesters query service registries to retrieve one or more service descriptions that meet certain criteria. Service descriptions contain sufficient information to allow service requesters to bind to and invoke Web services.

Service Discovery at Design Time and Runtime
Note that service discovery can happen at application design time or runtime. At application design time a designer, through a browser or other user interface, performs a query on a service registry, examines the results, and incorporates the returned service description into application logic.

In many cases the service interface definition is used to build a proxy that the application logic uses to invoke the Web service and consume its response. The actual service implementation, including network location and other properties such as which network protocol to use, is left unbound at design time to be determined at runtime. At runtime, then, the application issues a query operation against the service registry to locate one or more service implementation definitions that match the service interface definition used by the application. Based on application logic, such as best price or best terms, the application chooses which Web service to invoke, extracts network location and other information from the service implementation definition, and invokes the Web service.

The preferred approach to Web service registries is UDDI (www.uddi.org). It provides sophisticated publish-and-find capabilities and includes much more information than just the service description, including business metadata and taxonomies of businesses and services.

Intoduction to UDDI
In early 2000 as the idea of Web services started gaining momentum within the community, it became clear that Web services registries would be essential for the concept to become practical. Furthermore, in view of the movement toward open standards in the community, anything but a standard interface and search mechanism for these registries would be unacceptable. Such a registry standard would have to be endorsed by several, if not all, of the large software providers and adopted by the various industries. Thus the UDDI initiative, the result of several months of collaboration between representatives from Ariba, IBM, and Microsoft, was born in the spring of 2000 and formally announced on September 6, 2000.

Support for UDDI has expanded beyond the original three companies. Currently, the UDDI project (www.uddi.org) involves a community of over 280 companies as of this writing. Version 2.0 of the UDDI specification was released on June 18, 2001.

The purpose of UDDI is to facilitate service discovery both at design time and dynamically at runtime. Consequently, the UDDI project runs a public online business (and corresponding services) registry, which first went live on May 2, 2001. This registry is referred to as the UDDI Business Registry. It consists of three replicated registries currently hosted by three companies, Hewlett-Packard, IBM, and Microsoft, called the UDDI Operators. More registry Operators are expected to join the Operators group.

Becoming a UDDI Registry Operator involves some strict agreements on data replication, data privacy, and policies. From both a registered business and a user perspective, the requirement is that different Operator registries should be theoretically indistinguishable. Businesses can register with any UDDI Operator, and their information will get replicated to the other Operators' registries. As a result users can search any Operator site and find businesses regardless of which Operator these businesses used to register. There are, however, some subtle issues involved when deciding which Operator to register your business with. For example, some Operators might ask for additional information not required by UDDI (e.g., surveys or marketing). This information is not replicated to other Operators. Also once you register with an Operator, all updates to your information have to be performed through that Operator. The reason is that since different Operators implement different security and authentication policies, authentication information can't be easily replicated.

UDDI is more than a business and services registry, however. It also defines a set of data structures and an API specification for programmatically registering and finding businesses, services, bindings, and service types. In typical Web services scenarios, Web service providers will want to publish their business and service descriptions to a registry; and service requesters, whether at design time or runtime, will want to query the registry for service descriptions. The UDDI API specification provides a set of Publication APIs to register services and Inquiry APIs to find services.

In addition to providing a programmatic API, UDDI Registry Operators provide a Web-based user interface for registering, managing, and finding businesses and services in the registry. As of this writing, IBM had their UDDI Web site at www.ibm.com/services/uddi and Microsoft at http://uddi.microsoft.com. Of course, all the Operator nodes are accessible from www.uddi.org.

The UDDI Registry Requirements
Registries in general, whether for software components, services, or otherwise, have some basic requirements:

  • A set of data structure specifications for the metadata to be stored in the registry
  • A set of CRUD (Create, Read, Update, Delete) operation specifications for storing, deleting, and querying the data in the registry

    Common registry requirements for the metadata are:

    • Ownership and containment: I usually own the data I publish and all the subdata contained
    • Categorization: Data can be classified in one or more categories, mainly to facilitate searching and organization
    • Logical referencing mechanism: I can use references as pointers to other parts of the registry
    Common registry requirements for the operations are:
    • Authentication for the operations that change information and for public registries
    • Open access for read and query operations
    The registry part of UDDI is no different: it has an information model that represents the data structure specifications and an API for the operation specifications. The UDDI information model was designed to be flexible and extensible to allow for any user-defined service description models. The information model uses XML and is described in XML Schema. The APIs are based on SOAP 1.1 for maximum interoperability.

    UDDI Data Structures
    UDDI allows entities such as businesses and organizations to register public information about themselves and details of the services they offer. It also allows entities, such as businesses, standards bodies, and industry groups, to register information about the types of services that they've defined, about standards and abstractions, and to refer to them by their assigned identifiers.

    Business entity information is conceptually divided into what's commonly known as White, Yellow, and Green Pages. White Pages contain general contact information about the entity. An entry would contain a business name, address, and contact information such as phone, fax, and e-mail. Yellow Pages contain classification information about the types and location of the services the entity offers. A fictitious SkatesTown company could be classified as a sports equipment manufacturer and retailer, and as a skateboard manufacturer and retailer. Green Pages contain information about how to invoke the offered services. If SkatesTown were to offer their catalog online, their Green Pages entry would have a reference to their catalog URL. It's important to note that this is a conceptual model only, and that UDDI doesn't specify any particular storage model for implementing relationships. Conceptually, however, an entity's White Pages entry will contain classification information that points to its place in the various Yellow Pages, and an entity's business service entries will contain implementation information that points to entries in the Green Pages.

    This is reflected in the details of the UDDI data structures (see Figure 2). The root structure - businessEntity - is used to represent information about an entity or a business. It's also used as a container for business services and, indirectly, for the corresponding implementation and binding details of all the services that an entity provides. The businessService structure describes a logical business service, such as a stock quote service or a securities buying service.

    Different implementation details and bindings for the same logical service, if offered, are grouped under the same businessService element as a collection of binding templates. In a certain sense, the bindingTemplate structure is the end goal of UDDI. Other structures allow us to get information about businesses, their descriptions, contact information, categorization and taxonomy information, and what kind of services they offer.

    After a decision is made about using a particular service from a particular provider, however, the bindingTemplate subtree holds the necessary technical information for the service to be invoked. The same logical service can have more than one binding (e.g., SOAP-based, HTTP browser-based, and e-mail SMTP). Each of these bindings is described in its own bindingTemplate structure. This is generally a combination of access-point information and references to predefined technical models. Entries in the Green Pages, where invocation details are described, are actually business-specific binding details for service types and other abstractions defined elsewhere. These reusable abstractions are referred to as technical models and their corresponding UDDI data structure is the tModel. This structure allows industry groups, standards bodies, and individual businesses to specify reusable abstract definitions of service types that others can use and combine, creating in effect a signature for a service.

    Let's look at the structure of these in a little more detail.

    Business Entity

    • Operator: The certified name of the Operator that owns the UDDI node to which the entity is registered.
    • Authorized name: The name of the business entity provided by the Operator.
    • Discovery URLs: Optional URLs that provide alternate means for discovering the services; for example, businesses may provide a Web site to their services or use a convention such as the eCo Framework (www.oasis-open.org/cover/ecoFramework.html) service description convention.
    • Contacts: Optional contact information for the entity; contact information can specify categories such as technical support and marketing.
    Business Service
    • Name: Name of the service, as provided by the business
    Binding Template
    • Access point: The network address of the service to be invoked; the type of address is specified through a URL type. The allowed URL types are mailto, http, https, ftp, fax, phone, and other.
    • Hosting redirector: Typically used instead of an access point in cases where an entity is exposing a service hosted by another entity, such as an ASP. In addition to the information described above, UDDI data structures have a number of common properties:
    • Descriptions: Human-readable, multilanguage descriptions of the structure.
    • Keys: Unique identifiers assigned by UDDI upon initial registration of a new piece of data; in addition, according to the UDDI containment scheme, each instance of a contained structure (businessService and bindingTemplate) holds a key reference to its containing entity (in this case, businessEntity and businessService, respectively) in a strict parent-child relationship. These identifiers are Universal Unique Identifiers (UUIDs) that follow the OSF Distributed Computing Environment (DCE) conventions. They follow the familiar 8-4-4-4-12 pattern (e.g., F775A3A6-FF3E-4B85-B1DE-F0F99D0E2C6D). In addition, tModel references are given the "uuid:" URN qualifier to their keys.
    • Classification and categorization information: Collections of pointers that organize the UDDI data structures into a semantic network for convenient search and traversal; these are stored in the identifierBag and categoryBag parts of the UDDI data structure and they all point to tModels (see Figure 2). More on this later.
    Finally, it was deemed important that private (that is non-Operator but otherwise UDDI-compatible) UDDI registries be able to extend the businessEntity structure to include data for their own purposes. To this end the businessEntityExt structure was specified. UDDI registry Operators, however, won't provide extensions in their publicly available business entity data.

    In addition to defining the data structures to be stored in the registry, the UDDI specification provides two main types of API operations, Publication and Inquiry. In version 1.0 these APIs defined a set of 20 SOAP messages over HTTP or HTTPS that has to be understood by any UDDI conformant registry. (Version 2.0 APIs will be discussed in a later column.) The SOAP body of the API messages and responses are XML structures defined in the UDDI specification.

    The Publication API is an authenticated set of operations that allows organizations to publish information, whether business, service, implementation, or service-type specification, to the UDDI registry. Aside from requiring an authentication token and the use of the HTTPS protocol in the authenticated operations, UDDI does not specify an authentication method. Each Operator must provide a mechanism. The Inquiry API is a nonauthenticated public set of operations that allows users to extract information out of the UDDI registry. Inquiries can follow two different patterns: a browsing pattern to find general information (the find operations) usually followed by a drilldown pattern to find specific detail information (the get_Detail operations).

    Corresponding to the four structure types (businessEntity, businessService, bindingTemplate, and tModel), UDDI provides four save operations (save_business, save_service, save_binding, and save_tModel), four delete operations (delete_business, delete_service, delete_binding, and delete_tModel), four find operations (find_business, find_service, find_binding, and find_tModel) and four get_Detail operations (get_businessDetail, get_serviceDetail, get_bindingDetail, and get_tModelDetail) as shown in Table 1.

    The save operations can be used to create a new entry or to update an existing one. To create a new entry, the entry identification key parameter is not supplied in the call, but is assigned by the Operator and returned in the Operator's response. To update an existing entry this Operator-assigned key is supplied in the call. The delete operations take the Operator-assigned keys as parameters and remove the corresponding entries from the registry.

    The find operations are passed a set of search criteria and generally return a (possibly empty) list structure containing information about entries that match the search criteria. The get_detail operations are passed a list of identifiers and return detailed information about the entries referred to by the supplied keys. The API provides one additional get_detail operation, get_businessDetailExt, to allow the retrieval of extended business information from non-Operator nodes that implement these extensions. In addition, since the Publication API is a set of authenticated operations, where authentication is token-based, the API provides two authentication operations, get_authToken and discard_authToken. Finally, the getRegisteredInfo is an authenticated operation that returns all the businessEntity and tModel keys registered by an accredited user.

    Note that it's possible to perform most of the Publication and Inquiry API functions (some find and get_Details operations) through the individual Operator's Web sites. In addition to being more complete and powerful than what's available through browsers, the API is intended to allow businesses to perform all the operations programmatically to facilitate dynamic (runtime) service discovery.

    As we've seen, all Publication API operations need to be authenticated. Privacy, security, and authentication are crucial for the UDDI Operators to build a trusted relationship with UDDI users. However, since there is not one clearly universal and widely accepted standard for authentication, various Operators have different authentication policies. Because of this, the UDDI authentication mechanism involves getting an opaque authentication token by means specified by the UDDI Operator, using it in the authInfo attribute, then, optionally, discarding it. In addition, all Publication API messages are SSL encrypted. UDDI Operator nodes can list their own specific mechanism for getting a token. In case no Operator-specific mechanism is provided, Operators are required to implement the get_authToken API. Authentication in this case is performed by first getting an opaque authentication token from the UDDI registry through the get_authToken call, supplying that token in the authInfo element in the subsequent calls, and finally discarding the token through the discard_authToken call.

    Before being allowed to publish information to an Operator node, a prospective user will need to establish some credentials through an initial preregistration step, which is Operator-dependent. As a result of this initial step, each registering entity is either issued an authentication token (e.g., a certificate) or a user ID and password.

    To establish appropriate security context to access a registry, a preregistered user has to issue the following message over SOAP to a UDDI Operator:

    <get_authToken generic="1.0" xmlns="urn:uddi-org:api"
    userID="{userID assigned by Operator}"
    cred="{password chosen at registration}"/>

    The result of the get_authToken operation is an authToken structure identifying the Operator and providing a token, usually in the form of a UUID, for example,

    <authToken generic="1.0"

    All authenticated operations must include the authInfo element as part of their message over SOAP. For example, a save_business operation for the SkatesTown company might look something like Listing 1.

    Finally, the discard_authToken operation is used to inform the token issuer that the token is no longer valid and can be discarded. Subsequent Publishing API calls using the same token should be rejected. The token received in the get_authToken operation is passed as a parameter.

    <discard_authToken generic="1.0"

    This has been a whirlwind introduction to the core data structures and APIs of UDDI. The next XML in Transit will look in detail at the magic of tModels and the mechanisms for classification and categorization in UDDI. This is where the true power of service registries lies.

  • More Stories By Simeon Simeonov

    Simeon Simeonov is CEO of FastIgnite, where he invests in and advises startups. He was chief architect or CTO at companies such as Allaire, Macromedia, Better Advertising and Thing Labs. He blogs at blog.simeonov.com, tweets as @simeons and lives in the Greater Boston area with his wife, son and an adopted dog named Tye.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.