For this .NET UPDATE, I had planned to discuss namespaces and how .NET applications logically organize information, but late in July, the Universal Description, Discovery, and Integration (UDDI) committee released version 3 of the UDDI specification. I'd like to show you what's new in this version and give you a little background about how the new features will affect the way UDDI functions.
The new specification contains six main changes from previous versions: support for publisher-assigned keys; support for digital signatures; a new UDDI policy schema for determining how UDDI should operate in different environments; changes to the information model and the discovery model; changes to the way UDDI subscribers can find out about changes to a UDDI registry; changes in the way UDDI registries are managed. Let's examine support for publisher-assigned keys.
The new naming scheme represents a change in the way UDDI can share data between registries and in the way UDDI entity keys (identifiers) are generated. As you'll recall from our original discussion of UDDI in the February 21, 2002, issue of .NET UPDATE, one way to make services available to .NET applications is to publish them in a UDDI registry. Each service, represented by an entity, must have a unique key that follows the standard for Uniform Resource Identifiers (URIs). In other words, you have a registry of services, and all the services in the registry have unique keys according to the naming scheme specified in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2396.
In previous UDDI versions, only the UDDI node can generate keys. One consequence of this restriction is to render it effectively impossible for one entity to exist in more than one registry—in effect, for registries to share data. A publisher can't truly import or export data between registries because the publisher can't preassign a key to the entity to let the entity keep its unique name. The same service published in multiple registries is a different entity in each registry because the service has a unique key in each registry.
UDDI 3.0 supports entity promotion, a device that lets a publisher propose a new key for an entity. Assuming that the publisher has write privileges to the registry, he or she can insert the key and its entity into the registry. Such additions needn't occur on an entity-by-entity level; a publisher can potentially publish a registry's entire contents into another registry, effectively mirroring the data. Alternatively, the publisher can copy only a portion of a registry into another registry.
Of course, when you allow keys to be created by proposal, rather than assigned according to established rules, you increase the chances that keys will be duplicated—a problem that can keep service registries from functioning properly. UDDI 3.0 presents two measures to avoid key duplication. First, publishers must follow RFC 2396 to name entities, and the UDDI specification suggests a hierarchical naming scheme that correlates with DNS records to create the keys. Second, the specification outlines rules for the way the UDDI node will name new elements in existing entities when those elements are added programmatically. This DNS-based naming scheme has an added advantage: It's much more human-friendly than the previous naming system. To avoid name conflicts in registries, the earlier system suggested a hierarchical structure of an authoritative root registry that subordinate affiliate registries support. That is, the original entities go into the root but can be imported into other affiliate registries. Thus, the publisher knows which registry has the original—and definitive—entry. The current specification suggests the UDDI Business Registry (UBR) as a good example of a root registry because this registry has policies that let publishers generate unique keys.
Want more details? You can find the complete specification for UDDI 3.0 at http://uddi.org/pubs/uddi_v3.htm .
