The UDDI Data Structures

The UDDI Data Structures

UDDI (Universal Description, Discovery, and Integration) is a specification for creating a registry service that catalogs organizations and their Web services. An implementation of the UDDI specification is called a UDDI registry. A UDDI registry is a database that supports a set of standard data structures defined by the UDDI specification. The data structures model information about organizations (corporations, business units, government agencies, etc.) and the technical requirements for access to Web services hosted by those organizations. You can search a UDDI registry for specific kinds of companies or Web services. You can also register your own business and Web services in a UDDI registry. The usual analogy is that a UDDI registry is like an electronic "Yellow Pages" that businesses can search to find other organizations, and specific types of Web services. You can access the data in a UDDI directory using SOAP, which makes a UDDI registry a Web service.

Microsoft, IBM, and Ariba originally developed the UDDI specification, first published in September of 2000. Shortly thereafter they formed and invited 12 other companies to participate in the development of versions 2.0 and 3.0. was responsible for managing the specification and ancillary documents. In the summer of 2002, turned over management of the UDDI specifications to OASIS (Organization for the Advancement of Structured Information Standards). UDDI products based on the UDDI specification are offered by a number of vendors, including IBM, Microsoft, Sun, Oracle, Fujitsu, Systinet, and others. Although most UDDI products today run on a relational database management system, they can be implemented using other technologies, including LDAP servers and XML databases.

A UDDI registry must provide access to its data by way of a set of SOAP-based Web services. The UDDI specification describes about thirty different SOAP operations that allow you to add, update, delete, and find information contained in a UDDI registry. Most UDDI products also provide a Web interface for access to information in the registry.

Anyone can set up a UDDI registry for private use within an organization or market place. For example, the U.S. Navy is establishing a UDDI registry that provides centralized management for tens of thousands of applications. The navy's UDDI registry is being used to help reduce duplication across the entire organization. ISEC (the Integrated Shipbuilding Environment Consortium) is using UDDI to build a trading partner network for U.S. shipbuilders, which is hosted by NIIIP (the National Industrial Infrastructure Protocols Consortium). ISEC's registry will be used to manage an organization-wide supply-chain system for shipbuilders. Private and marketplace UDDI directories are not usually accessible to the general public; they are used by one organization, which might be a single company, a consortium of companies, or a government entity.[1]

[1] Anne Thomas Manes, Web Services: A Manager's Guide. Boston: Addison-Wesley, 2003.

In addition to private UDDI registries, which are the main focus of UDDI development today, there is a massive public UDDI registry called the UDDI Business Registry (UBR), which is run jointly by IBM, Microsoft, NTT, and SAP, under an umbrella organization called the UBR Operators Council. This registry allows any organization to register its business and Web services, or peruse the registry, for free. The UDDI Business Registry is currently running on four main operator sites hosted by IBM, Microsoft, SAP, and NTT. These sites are synchronized, so that if you register your business and Web services with one of them, the information is copied to the others. Anyone can look up your organization and learn about your Web services using any of the four registries, but you can modify data only through the operator site where you originally submitted it.

Many people think of UDDI as a good way of cataloging a corporation's software applications, in order to provide a centralized source for documentation and discovery. UDDI is getting attention in electronic marketplaces, where companies of a common ilk organize and share data in the pursuit of commerce. The UBR has not, however, gained as much momentum as originally hoped. Although the UBR is free (all you need to do is register with the operator site), organizations have yet to see value in the idea of registering with a global UDDI registry. David A. Chappell, author of Understanding .NET,[2] summed up the degree of success of the UBR with the quip "There are literally dozens of corporations registered with the UBR worldwide!"

[2] David A. Chappell, Understanding .NET. Boston: Addison-Wesley, 2002.

UDDI defines five primary data structures, which are used to represent an organization, its services, implementation technologies, and relationships to other businesses:

  1. A businessEntity represents the business or organization that provides the Web service.

  2. A businessService represents a Web service or some other electronic service.

  3. A bindingTemplate represents the technical binding of a Web service to its access point (its URL), and to tModels.

  4. A tModel represents a specific kind of technology, such as SOAP or WSDL, or a type of categorization system, such as U.S. Federal Tax ID numbers or D-U-N-S numbers. The tModels that a bindingTemplate refers to reveal the type of technologies used by a Web service. Most of the data structures also use tModels to indicate the categorization system of an identifier assigned to the structure.

  5. A publisherAssertion represents a relationship between two business entities.

Figure shows how these data structures are related.

Entity Relationship Diagram of the Primary UDDI Data Structures


The Self-Organizing Myth

When UDDI was first introduced, the concept of self-organizing systems was high on the list of motivations for creating the registry standard. The idea was that software applications could look up Web services and integrate with them automatically, without any human intervention. In other words, your software would choose which services you used and create B2B partnerships on the fly. Sounded pretty good, but in reality it doesn't work.

When you decide to integrate with some other organization's Web service, you need to define the terms of that integration in a contract, or at least a general set of guidelines. You need to establish some form of business partnership with the other organization before they use your service or you use theirs. Another possibility is that you are using Web services to integrate stovepipe applications within a single organization.

In either case, you are going to choose these integration points purposefully and with deliberation—no one is going to trust software to choose business partners and integrate with foreign systems dynamically. The myth of self-organizing systems that automatically choose business partners and integrate on the fly is one that has been around for a while. Similar motivations were behind the CORBA Trading Service. The truth is that integration is an up-front design decision that is made by management and executed by developers; it's not something that software can do effectively at this point. The level of artificial intelligence required to make the heuristic decisions involved in choosing new business partners and integrating with foreign systems simply doesn't exist yet.

Actually, Figure oversimplifies the relationship between the tModel and the other data structures. The tModel data structure and its relationship to all the other data structures are addressed in more detail later in the chapter. The five primary data structures are not the only data types defined by UDDI, but they are the most important ones, and the only ones assigned unique keys that allow them to be stored separately, yet still refer to each other. There are also data structures that represent address information, categories, contact information, URLs, and other common business data. All the standard data structures in UDDI are defined as XML schema complex types in a single XML schema document.

Currently there are three versions of UDDI, versions 1.0, 2.0, and 3.0. Version 2.0 is the one that is supported by J2EE Web Services and sanctioned by the Basic Profile, so it's the topic of this part of the book. The rest of this chapter provides you with a detailed understanding of the standard data structures used to store information about organizations and their Web services. Chapters 7 and 8 describe precisely the structures and purposes of the SOAP messages that can be sent and received from a UDDI registry.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows