The keys to UDDI - from nonsense Hex-digits to meaningfull URIs

UDDI version 3 is new to me even though it's not a new standard. A classic approach to new versions is to look for the what's new section. The specification doesn't give that (UDDI Version 3.0.2). A quick search lead me to PerfectXML's The Evolution of UDDI. Looking at the date's on history table I was surprised to see that it's in fact more than five years old. A couple of minor revisions lead me to believe i wasn't that old, but it is from the summer of 2002:

Update!: Today I found the announcement "UDDI Version 3.0 Beomes an OASIS Standard" dated February 03, 2005! It would had been nice with a formal version, with the label standard and the correct date, and I can't remember any other OASIS Standard without such an officially labeled specification. I conclude that it took approximately 2.5 years and 2 minor revisions for version 3 to become an real standard.

Version	Date for Committee draft
3.0.2	19 October 2004
3.0.1	14 October 2003
3.0	19 July 2002

UDDI Keys

One of the central new things are the keys used in UDDI, which has always be central but with the shift of focus to federation, this is even more important. The article gives a short description in "Creating and Managing Registration Keys". But first a look at how it was defined in version 2.

UDDI Keys in version 2

In UDDI version 2 section "4 API Reference" the keys are described:

uuid_key

Access keys within all UDDI defined data elements are represented as universal unique identifiers (these are sometimes called a GUID). The name of the element or attribute designates the particular key type that is required. These keys are always formatted according to an algorithm that is agreed upon by the UDDI Operator Council with the one exception being tModelKey values, which are prefixed with a URN qualifier in the format "uuid:" followed by the UUID value.

and further down under tModelBag All tModelKey values are always expressed using a Uniform Resource Identifier (URI) format that starts with the characters "uuid:" followed by a formatted Universally Unique Identifier (UUID) consisting of Hexadecimal digits arranged in the common 8-4-4-4-12 format pattern.

According to Richard Monson-Haefel's book J2EE Web Services in section "6.5 UUID Keys": The UUID is a hexadecimal-encoded number taht is about 30 charaters long and is generated using the DCE UUID-generation algorithm.

UDDI Keys in version 3

In version 3, the section "4.4 About uddiKeys" gives the change:

..All UDDI keys are URIs that conform to RFC 2396 but not all URIs are valid UDDI keys. The URIs that are valid as UDDI keys correspond to a subset of the opaque part alternative of the absoluteURI rule in RFC 2396. Further, registries MUST use keys from the scheme "uddi" following the syntactic and semantic rules for that scheme as given in this section,..

and "9.4.2 Registry General Keying Policy":

UDDI Version 3 introduces the ability for publishers to generate entity keys. This feature preserves the requirement for distinct keys while enabling keys to be created in a safe, efficient manner.

A registry MUST have a policy on key format and key generation. The registry MUST have a policy on data integrity or how the keyspace is protected from unauthorized modification.

Registries MAY use whatever keying policies they wish subject only to the constraints that keys MUST be URIs, and the registry MUST have policies that prevent key collisions.

Update: Today I found the UDDI Version 3 Features List where "2.2 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.

So now all keys in UDDI are URI's and the publisher can suggest them. I haven't really used UDDI so I can't tell any story from the trenches about the problems with opaque keys, but sometimes it's sure nice to make some meaning out of them, Though it's also some times seen as best practice not to put any meaning into keys since things have a tendency to change.