New UDDI V3 Beta 1 Features

This Beta of the Universal Description, Discovery and Integration (UDDI) Business Registry Version 3 provides much of the functionality described by the UDDI Version 3.0 Specification which is available at uddi.org.

The V3 beta has been updated with a vast array of enhancements – including:

• Multi-Registry Topologies:
  • Human-friendly, URI-based Keys
  • User-Owned Keyspaces
  • Entity Promotion
• Security Features:
  • Digital Signatures
  • Operational Policy
• Core Informational Model Advances:
  • Operational Information
  • Multiple Overview Documents
  • Categorization Grouping
  • CategoryBags on BindingTemplates
  • Improved Language Support
  • Information Model Extensibility
• Improved WSDL Support
  • Improved Access Point Definition
• Improved Query Support
  • New Find Qualifiers and Sort Orders
  • Extended Wildcard Support
  • Management of Large Results Sets
  • Complex Queries
• External Value Set Validation

Multi-Registry Topologies

Human-friendly, URI-based Keys

Alongside the ability to promote keys across registries is a new format for UDDI keys. Prior versions of UDDI mandated that keys had to be a formatted Universally Unique Identifier (UUID). Version 3 removes this restriction and recommends the usage of a key scheme based on DNS names. This allows publishers to establish a key partition from a DNS record and then generate keys based on that partition.

For example, a valid Version 3 key might look as follows:

• uddi:example.com:1
• uddi:example.com:sales-division:53

These human-friendly keys allow organizations to manage their own key space using internally established conventions and structures.

User-Owned Keyspaces

UDDI Version 3 allows for a user to request that UDDI generate unique Keyspaces which they own and only they can use as a prefix on entity keys when publishing new Businesses, Services, Service Bindings and Technical Models. Therefore, all entities owned by the same person or group can have a uniquely identifiable set of identifer keys (because they are prefixed by the same keyspace).

Entity Promotion

Version 3 of UDDI approaches the issue of key generation in a significantly different fashion and, as such, the possibility of publishing an entity to another UDDI registry while preserving the key is allowed. This behavior is known as entity promotion. With this version of UDDI, a publisher is permitted to propose a new key for an entity, and, given the policies of a registry, that key and the entity associated with that key may be inserted into the registry.

In order to support this more broadly distributed environment, UDDI Version 3 introduces the notions of root and affiliate registries as part of its guidance on inter-registry associations. The existence of a root registry enables its affiliates to share data with the root registry and among themselves with the knowledge that keys remain unique. The notion of registry topologies is thus enabled – multiple UDDI registries that are interrelated in complex ways.

Security Features

Digital Signatures

A major advancement in the Version 3 specification is the support for digital signatures. By allowing UDDI entities to be digitally signed, a new level of data integrity and authenticity is delivered by UDDI.

Inquirers of a registry can now filter their queries, only requesting data that has in fact been signed. When an inquirer then retrieves and verifies data from a registry, the inquirer can be confident that the data is exactly as the publisher intended it.

Publishers to a registry now have the assurance that they are not being misrepresented by someone claiming to own a UDDI entity. Once publishers have signed data, they can have confidence in the integrity of that data.

These assurances for both the inquirer and publisher are transitive: given V3’s support of entity promotion, data can be copied between registries and guaranteed to not have changed during the process of being copied. As such, the multiple registry environment discussed above can be achieved with a high level of data integrity.

Operational Policies

The Version 3 specification acknowledges and enables UDDI to be employed in a diverse set of environments for different UDDI registry implementations – internet, extranet, intranet, development, test, production, etc. – there is a need to provide flexibility for implementations to support vastly different operational policies.  With this in mind, significant work was undertaken to identify all the policy decisions that each UDDI registry and/or node must make.  Using the policy guide that is now part of the Version 3 specification, different UDDI implementations can mold a particular registry given its context.

The Version 3 specification also outlines mechanisms for representing these policy decisions both through a new UDDI policy schema and through normative modeling behaviors within UDDI itself.  As such, policies can be established and consistently determined by inquirers of a UDDI node.

Some UDDI aspects that have been identified as policy decisions include the following: authorization models, data custody and confidentiality, key generation, value set validation, subscription, user publication limits, and audit policy. The specification outlines the goal for each policy and provides recommendations for each policy decision.

Core Informational Model Advances

Operational information

Version 3 adds a new data structure, operationalInfo. This structure is used to convey the operational information for the UDDI core data structures: Business Entity, Business Service, Binding Template and Technical Model.

Such operational information includes:

• Creation Date and Time
• Last Modified Date and Time
• UDDI Node where the publish operation took place
• Publisher's Identity

Multiple Overview Documents

The ability to define multiple Overview Document elements for the Technical Model entity and the Technical Model Instance Details structure (within a Binding Template) is supported. This provides the capability to specify the description of both Web services and Web service types in different formats.

Categorization Grouping

UDDI now provides the ability to use complex categorization in attributing UDDI entities (i.e. Businesses, Services, Techincal Models and Service Bindings).

For example, Geodetic typing can now be modeled through the use of geographical coordinates in order to specify where a specific business or service is physically located. Geographical latitudes and longitudes can be grouped together in a keyedReferenceGroup.

Also, UDDI now provides the ability to extend categorization systems through derivation. In such a way, the same value set might be reused in different contexts. For example, a category system used to classify the service area of a business might be re-used to classify the physical location that business.

CategoryBags on BindingTemplates

The ability to classify bindingTemplates with categoryBags now allows metadata to be attributed directly to the technical details of a Web service, enabling more granular searches to be performed on the specific technical metadata for a given service.

Improved Language Support

UDDI Version 3 allows users to enter multiple Names and Descriptions on any UDDI data element with the same language code.

In addition, UDDI Version 3 now supports the publishing and querying of Business, Services, and Technical Models with and without diacritic marks on characters. Therefore international busineses which has a name that contains a diacritic adorned character can now be found on a name query with either the unadorned character or the character adorned with the diacritic.

Information Model Extensibility

UDDI Version 3 allows publishers to use XML Schema’s derivation mechanism to extend the information model. It provides clear rules and guidelines regarding the treatment of extended data structures.

Improved WSDL Support

Improved Access Point Definition

The UDDI AccessPoint data element has been updated to support a more extensible typing ability through the addition of the useType attribute. This now enables WSDL files to be more easily registered and consumed from UDDI. It also simplifies the indirection mechanisms (hostingRedirector) that were explained in prior versions.

Improved Query Support

New Find Qualifiers and Sort Orders

UDDI has created new normative find qualifiers to improve the effectiveness of queries. Version 3 also recognizes that different registries might support different find qualifiers and sort orders for a given API. With this in mind, a given registry can create and model new find qualifiers and sort orders.

The UDDI V3 registry supports the following Find Qualifiers and Sort Orders:

Extended Wildcard Support

Management of Large Results Sets

UDDI now provides a mechanism to enable paging through large result sets.  This effectively allows the data to be “chunked” into multiple response messages from the server.

Complex Queries

UDDI V3 now provides the ability to nest sub-queries within a single query, reducing the number of round trips a client must make to a UDDI registry. By allowing nested queries for tModels within queries for services, clients can narrow in on the types of service they are searching for much more efficiently.

External Value Set Validation

Registries that support external validation now have the option of caching external value set values. This helps minimize the number of calls to external validation web services.

UDDI Version 3 gives registries two options for obtaining the set of valid values. One is to accumulate the valid values from successful calls to validate_values. The other is to obtain the set of valid values with a call to get_allValidValues, where supported by the validation service. The get_allValidValues API is new with UDDI Version 3.