4.2 The UDDI model

The UDDI Version 3 Feature List document, which was published by UDDI.org in mid-2002, starts off with this pithy (but uncharacteristically Web services “centric) description: UDDI Version 3 builds on the vision of UDDI: a ˜meta-service for locating Web services by enabling robust queries against rich meta-data. Note that the term meta gets used not once but twice in this somewhat short description, with the first mention, intentionally or otherwise , having two very appropriate and germane connotations in the context of UDDI.

Technical Webizens, whose lives revolve around the Web, will immediately interpret meta-data, in this context, as referring to it being machine readable ”in other words, data that are programmatically accessible, or in this case data that are programmatically searchable. This is consistent with the W3C s definition of meta-data, which happens to be: Metadata is machine-understandable information for the Web.

It also ties in with HTML s <META> tag, which enables one (among other things) to specify Web site identification and keyword information to help search engine Web crawlers to more easily categorize and index that Web page. Again, the concept here is that of automatic, programmatic searches. This programmatic aspect, as indicated by this meta-data reference, as should now be clear, is a fundamental plank of UDDI.

The prefix meta, however, has a more traditional, pre-Web connotation. It is used to denote a description that is one level higher than the word being prefixed. Thus, if x is some entity, then meta-x is a description of x. Therefore, a metasyntax is a syntax for describing other syntaxes. Similarly, a meta-language is a language that can be used to describe the makeup of other languages.

Hence, this is why XML is referred to as a meta-markup language. It allows one to describe the composition of other markup languages or, more commonly, to describe data that would otherwise be annotated with another, lower-level markup language. This now brings us to UDDI being a meta-service. Given that UDDI is modeled around APIs that generate SOAP messages, UDDI definitely falls into the category of machine-understandable service ”if one were to extrapolate the W3C meta-data definition to cover meta-service.

However, UDDI, being a meta-service, also alludes to it being a service for locating other services ”particularly Web services. Thus, this new mission statement, included with a UDDI Version 3 must-read overview document, hits the nail on the head quite squarely by highlighting the service about other services and programmatic aspects of UDDI. Relative to this backdrop, the initial UDDI model postulated with UDDI V1, in September 2000, is shown in Figure 4.6, whereas Figure 4.7 shows the multiregistry structure that is likely to be common in the future. This basic model still holds true for the UBR. The one big difference that has taken place since, particularly with UDDI V3, is the concept of the UBR being augmented by private and semiprivate UDDI registries. However, the non-UBRs also still conform to the overall precepts of the original model, albeit with less external entities participating in populating, categorizing, and interrogating a given private or semiprivate registry.

Figure 4.6: A simplified and rationalized version of the original How UDDI V1 Works model postulated by UDDI.org in September 2000.

Figure 4.7: Post-2003 UDDI scenarios, where the UBR will be complemented by affiliated private and semiprivate UDDI Registries.

4.2.1 UDDI data structures

The UDDI information model is composed of instances of persistent data structures. A persistent data structure is one that automatically preserves its old versions. With a persistent data structure, one can make changes to the structure without destroying the old version. Thus, all versions of the structure persist. This enables previous versions of the structure to be queried, in addition to the latest version. The use of persistent data structures by UDDI means that one could have access to different versions of a service rather than just to the most recent.

UDDI s persistent data structures are referred to as entities. An entity in XML is a special unit of storage. Entities are the basic building blocks of an XML document. Though UDDI does not make explicit reference to this connection, it is implied and will be appreciated by those familiar with XML. The UDDI information model is said to be composed of instances of six core entity types. These entity types, which are shown in Figure 4.2, are as follows :

businessEntity
businessService entity
bindingTemplate entity
tModel entity
publisherAssertion entity
subscription entity

All these entities are represented in XML, with each structure corresponding to predefined XML elements and XML attributes. They are stored, in a persistent manner, in one or more UDDI nodes. Each entity acquires the type of its outermost XML element.

There is a very definite and immutable hierarchy between these six UDDI data structures, as depicted in Figure 4.2, though if one wants to be ultra -pedantic, one would claim that this hierarchy relates to just the four original UDDI V1 structures, with publisherAssertion and subscription being more in the nature of flags or references that apply to the other structures. Each business or organization described in a UDDI Registry exists as a separate instance of a businessEntity data structure. Similarly, each service offered by a business or organization is maintained as a separate instance of data.

The fixed hierarchy between the UDDI data structures also results in an automatic, corresponding containment relationship between these structures. Thus, the businessEntity structure contains one or more unique businessService structures, whereas each businessService structure, in turn , contains specific instances of bindingTemplate data. The bindingTemplate structures will contain information that includes pointers (or references) to specific instances of tModel structures.

Within the UDDI hierarchy, no single instance of one of the core structure types is ever contained by more than one parent structure. Thus, as clearly depicted in Figure 4.2, only one specific businessEntity structure will ever contain information about a specific instance of a businessService structure. At this juncture it is best to look at a specific data structure in detail so as to reinforce what has been discussed so far ”as well as to provide a basis for discussing a set of new UDDI concepts and constructs. Figure 4.8 shows the detail composition of the businessEntity structure. Figure 4.9 shows how an instance of data for a particular service provider (in this case IBM), as maintained per this structure, would be presented to a user of a UBR node.

 <element name="businessEntity" type="uddi:businessEntity" />  <complexType name="businessEntity">    <sequence>      <element ref="uddi:discoveryURLs" minOccurs="0" />      <element ref="uddi:name" maxOccurs="unbounded" />      <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />      <element ref="uddi:contacts" minOccurs="0" />      <element ref="uddi:businessServices" minOccurs="0" />      <element ref="uddi:identifierBag" minOccurs="0" />      <element ref="uddi:categoryBag" minOccurs="0" />    </sequence>    <attribute name="businessKey" type="uddi:businessKey" use="required" />    <attribute name="operator" type="string" use="optional" />    <attribute name="authorizedName" type="string" use="optional" />  </complexType>

Figure 4.8: The businessEntity structure, as defined in the UDDI V2.03 Data Structures Specification, in relatively easy-to-follow XML schema notation, showing which elements or attributes are required (i.e., use= required ), those that can be repeated (i.e., maxOccurs= unbounded ), and those that are optional (i.e., minOccurs= 0 ).

Figure 4.9: The business provider information for IBM, as it appears in Microsoft s UBR node, illustrating how data maintained in a businessEntity structure, as shown in Figure 4.8, get utilized. The long, hexadecimal Provider Key, which appears near the middle of the Web page, corresponds to the unique business key identifier for this entry. Also note the tabs for services, contacts, identifiers, categories, and discovery URLs, which correspond directly to elements within the businessEntity structure. The Name entry, which appears after the first blocked-out horizontal bar, in this instance, only has one entry ” and that is in English, as denoted by the (en). It would have been possible to have multiple entries here.

Most of the elements in the businessEntity structure, such as name, contacts, discoveryURLs, businessServices, and so forth, are self-explanatory. Some, in particular identifierBag and categoryBag, can, however, be somewhat obscure or misleading. The postfix Bag, in this case, was probably not the best word to use in this context. The term bag in this context strives to convey that it is possible to have a mixed list (i.e., a mixed bag) of identifiers or categories ”albeit with both of these lists being optional. What is listed in the identifierBag are accepted industrial identification numbers as D-U-N-S, nine-digit identification codes. Figure 4.10 shows the D-U-N-S identifier for IBM as it appears in Microsoft s UBR node.

Figure 4.10: The D-U-N-S, nine-digit identification for IBM shown in the Identifiers tab as it appears within IBM s entry at Microsoft s UBR node.

Business or organization categories as they relate to a yellow-page taxonomy are listed in the categoryBag. Figure 4.11 shows the start of the list of 170 categorizations that IBM lists for itself using a combination of NAICS and UNSPSC codes. IBM s comprehensive list of categorizations of what it does ranges from optical jukebox server software to sales financing. It also includes the UNSPSC codes for spreadsheet software, word processing software, and presentation software.

Figure 4.11: The start of the 170 categorizations IBM lists for the services and products it offers using a combination of NAICS and UNSPSC codes. On the other hand, Microsoft, uncharacteristically self-effacing, only lists one category ”that being the NAICS 51121 code for a software publisher.

All of these categorizations are germane, and one has to applaud IBM for its diligence in coming up with all of these codes. However, if you look at Microsoft s listing of categories, you will be surprised just to find one! That is the NAICS code for a software publisher. IBM happens to list that one, too. This highlights one of the unintended , but inevitable, shortfalls of UDDI. UDDI is unregulated, self-policing, and essentially unaudited.

The completeness and accuracy of the entries are left entirely to the discretion, professionalism , and motivation of the business or organization entering the data about itself. Until Microsoft gets around to updating its list of categorizations, there will be the irony that somebody doing a UDDI query for providers of word processing software will find IBM as a search result, but not that of the undisputed market leader Microsoft!

4.2.2 UDDI keys

Each entity in a UDDI Registry, whether a business, a service, a service binding information, or a tModel, is assigned a specific UDDI identifier or UDDI key. An example of a UDDI key, which is actually my consulting services “ related entry in the UBR, would be:

 uddi:E05BE6A0-C043-11D7-9B41-000629DC0A53

Figure 4.12 is a screen shot from IBM s UBR node showing the businessEntity entry for Anura Guruge, with the above key prominently displayed as the first item of information ”albeit not showing the mandatory UDDI key. Compare this businessEntity presentation la IBM with that shown in Figure 4.9, which depicts how such information is presented by Microsoft. This is something that you have to get used to when dealing with UDDI implementations ”including the global UBR.

Figure 4.12: A businessEntity presentation for another service provider, in this case for Anura Guruge, as displayed on IBM s UBR node, showing the 32-digit hexadecimal key for this entry. Compare this presentation with how Microsoft displays businessEntity information, shown in Figure 4.9, and note that although IBM just refers to the UDDI key as the key, Microsoft calls it the Provider Key and uses lowercase to display the hexadecimal code, whereas IBM opts for the more traditional uppercase.

The UDDI specification only deals with the information models, the APIs, the XML schema, and the SOAP messages. It does not talk about implementation details, so each UDDI implementation, including the various nodes that make up the global UBR, can have a different look and feel. However, all nodes of the UBR, given that they are working with the same set of information, uniquely identified by the UDDI keys, will always present the same information content ”as well as information instances.

The UDDI key uniquely identifies that entity, for the duration of its existence, within the UDDI Registry. The persistence of UDDI data is related to the use of these unique keys. In the case of the UBR, all the nodes that make up the UBR will use and reflect the same UDDI key for a specific instance of information, given that all the nodes that make up the UBR work in concert when it comes to the information maintained by the UBR.

The Provider Key in Figure 4.9 is also an example of a UDDI key ”in this case the key to this particular instance of IBM s businessEntity information. Figure 4.13 shows IBM s entry, as displayed on IBM s UBR node as opposed to Microsoft, to confirm that the provider key is still the same irrespective of the UBR node being used ”though it looks different because Microsoft displays the hexadecimal digits in lowercase per the wont of XML and the Internet, whereas IBM, the godfather of hexadecimal notation since the early 1960s, opts for the more common uppercase-only representation. This is another example of how implementation details will vary from node to node, thus giving some users pause for thought if they skip from one implementation to another. UDDI keys, as with all XML-related entities, are, nonetheless, case sensitive, though this case sensitiveness does not apply to whether hexadecimal digits appear in lowercase or uppercase, given that these are in reality numeric digits, though shown using letters .

Figure 4.13: BusinessEntity display for IBM, at IBM s UBR node, confirming that the UUID key for this entry is exactly the same as that shown in Microsoft s UBR node, per Figure 4.9, with IBM, however, displaying the hexadecimal digits in uppercase versus the lowercase depiction preferred by Microsoft. Also note that IBM s presentation includes the business description, as well as the categorizations (i.e., Business Locator[s]), and that these categorizations are listed in the same order shown in Figure 4.11.

A UDDI Registry assigns one of these unique identification keys when a new registry entry is first published (i.e., saved). Once assigned, a UDDI key can be used at any later time to incisively access that specific instance of data ”on demand. Prior to UDDI V3, all UDDI keys had to be generated by the publishing UDDI node to ensure the uniqueness of each key. UDDI nodes generated these unique keys in the form of Universally Unique Identifiers (UUID). A UUID, also called a Globally Unique Identifier (GUID), is a scheme that permits resources to be uniquely named over time and space.

UUIDs were originally created for use with remote procedure call (RPC) mechanisms in the context of the Network Computing System (NCS) initiative of the 1980s. This RPC mechanism was later adopted by the Open Group s Distributed Computing Environment (DCE) and further formalized by ISO within the framework of the once-rampant Open Systems Interconnection (OSI) model as ISO standard: ISO/IEC 11578:1996.

A UUID is 128 bits long. It can thus be represented by 32 hexadecimal digits, given that each hexadecimal digit corresponds to 4 bits. The UUIDs used as UDDI keys are depicted as 32-digit hexadecimal sequences by the current UBR implementations, as illustrated in Figures 4.9, 4.12, and 4.13. A UUID is guaranteed to be different from all other UUIDs generated until 3400 A.D., or, worst case, still likely to be extremely different from any other even if the UUID generation algorithm is not optimally implemented.

The algorithm used to generate UUIDs relies on a combination of hardware addresses (derived from IEEE 802 MAC addresses uniquely assigned to each and every LAN adapter), timestamps, and random seeds . It is the use of timestamps that results in the caveat that the uniqueness of UUIDs is only guaranteed up until 3400 A.D.! The 32-hexadecimal digit UUIDs, the only type of keys available with UDDI V1 and V2, are not well suited for use by people. They are arbitrary, unwieldy, and impossible to remember. With UDDI V3, it is possible to have keys that are considerably better suited for use by people. The creator (i.e., publisher) of a UDDI entity can even request a particular key or a type of key. These so-called publisher-assigned keys are one of the major new features of UDDI V3.

With V3 it is now possible to have so-called domainKeys in addition to the prior uuidKeys. Domain keys are based on the now-commonplace Internet domain names. Since domain names have to be unique, keys based on domain names can also maintain UDDI s requisite individualism . A domain name “based UDDI key would look like this:

 uudi:acmecompany.com:businessRegistration

Thus, a domain name “based UDDI key for my businessEntity could be:

 uddi:inet-guru:AnuraGurugeBusinessName

Domain name “based UDDI keys are obviously much more flexible and meaningful than uuidKeys. However, the UDDI specification leaves as an implementation option whether a given UDDI Registry has to support domainKeys. In addition to these two orthogonally different key types, it is now also possible to have what are referred to as derived keys. A derived key has either a uuidKey or a domainKey as its base (i.e., its start), but has in addition an alphanumeric ASCII character string, or arbitrary length, appended to it. This, especially in the case where a uuidKey is the base, provides further flexibility when it comes to UDDI key assignment.

The growing trend toward having enterprise UDDI registries, whether private or semiprivate, augmenting the UBR, does complicate the management of UDDI keys ”especially if domainKeys are in use. The issue has to do with UDDI publishers that wish to copy the entire contents of a UDDI entity entry from one UDDI registry (e.g., private) to another while preserving the key assigned to the original entity. UDDI V3 includes a capability known as entity promotion to cater to such scenarios. With entity promotion, a UDDI publisher is permitted to propose the existing key for an entity as the preferred key for that entry. It is, however, left to the implementation and the exact policies of a given registry as to whether the new registry has to acquiesce to this request.

To facilitate publisher-assigned keys, in particular entity promotion scenarios, V3 introduces the concept of root and affiliate UDDI registries. The use of a root UDDI registry by multiple affiliate registries ensures that the affiliate registries can readily share data among themselves , relative to that root, and still make sure that they maintain unique UDDI keys, since this would be arbitrated by the root. It is suggested that the UBR should be considered , whenever possible, as the root registry in such distributed registry scenarios. In this case the UBR, through the use of either uuidKeys or domainKeys, will ensure the uniqueness of the necessary UDDI keys.

4.2.3 UDDI APIs

The UDDI inquiry and publication APIs, as mentioned earlier, are key to any UDDI implementation. They control the core functions related to publishing and locating entities in a UDDI Registry. Though presented so far as single APIs for simplicity, the UDDI specification treats all APIs as consisting of sets. It then further splits these sets into node versus client API sets. The API sets specified in V3 are thus as follows:

UDDI Node API Sets	UDDI Client API Sets
1. UDDI Inquiry	1. UDDI Subscription Listener
2. UDDI Publication	2. UDDI Value Set
3. UDDI Security
4. UDDI Custody Transfer
5. UDDI Subscription
6. UDDI Replication

The functionality made possible by these UDDI API sets can be characterized as follows:

UDDI Inquiry: This API set is what a programmer would use to locate and obtain details on specific entries stored in a UDDI Registry. This API set supports three distinct patterns of inquiry to address all germane inquiry modes for this type of data. The three types of inquiry patterns supported are referred to as browse pattern inquiry, drill-down pattern inquiry, and invocation pattern inquiry. A browse pattern inquiry, as the name alludes, permits one to conduct an inquiry starting with a broad categorization and then refining the inquiry to more specific criteria as each set of search results is displayed. A drill-down inquiry involves using a UDDI key, obtained via a browse pattern inquiry or by other means (e.g., using a domain-Key), to access a specific entity. An invocation pattern inquiry is typically used in the context of bindingTemplate entries for Web services. As suggested by the name, it is used when the application invoking this search is happy to have the Web service located by the search to be dynamically invoked at the end of the search, so this becomes a search-and-activate operation.
UDDI Publication: This API set is used to publish, update, and delete information contained in a UDDI Registry. It is left to the implementation policies of a particular registry to decide which node of a particular UDDI registry is used by a publisher to publish a given set of data. UDDI per se does provide an automated mechanism to check and reconcile information that may be published on different nodes of the same registry at different times. This again is an implementation issue.
UDDI Security: This API set is currently used to obtain and manage authentication information.
UDDI Custody (and Ownership) Transfer: The publisher who initially creates an entry has ownership of that entity. A custodial UDDI node (typically the one at which the entry was published) has to maintain a rigid relationship between an entity and its owner to ensure the integrity of the information in a UDDI Registry. In the case of a multinode registry (e.g., UBR), every node must guarantee the integrity of an entity s ownership and custody. Consequently, a node cannot permit changes to an entity unless it is the custodial node for that entity. The Custody (and Ownership) Transfer API set enables one node to transfer custody of certain entities to another node or to transfer ownership of an entity from the current owner to a new one ”in an authorized and cooperative manner.
UDDI Subscription: This is the API set that facilitates the subscription scheme introduced with UDDI V3. This API set enables clients , referred to in UDDI argot as subscribers, to register their interest in being notified if and when changes are made to specific entries in a registry.
UDDI Replication: Used to replicate entries within a UDDI Registry.
UDDI Value Set: This API set permits authorized third parties to validate certain information being published in a UDDI Registry based on registered value sets.

4.2.4 UDDI nodes and UDDI registries

A software system that supports at least one of the UDDI node API sets described earlier is considered to be a UDDI node. The UDDI V3 specification tries to put some self-serving spin into this definition by stating : A set of Web services supporting at least one of the node API sets is referred to as a UDDI node. What is noteworthy here is the introduction of the concept of Web services supporting the UDDI API sets. That is the self-serving part, since one can justifiably argue that it is not necessary to include Web services in this definition. On the other hand, some technocrats will argue that this is indeed a valid and necessary distinction, based on the fact that UDDI relies on SOAP.

The UDDI APIs, by definition, operate by generating SOAP interactions. Thus, any software system that supports a UDDI API set, by default, has to be able to accommodate SOAP. SOAP is considered by most, including the nascent W3C Web Services Architecture, to be a fundamental (if not a prerequisite) building block of Web services. When one subscribes to this SOAP-centric view of Web services, one could then go the next step and describe any SOAP-based piece of software as being a Web service.

At a minimum, one could claim that any piece of software that communicates using SOAP is Web services ready. At this juncture, all that is important to note is that the UDDI definition for a UDDI node calls for the node to support at least one of the node API sets. Whether the software that makes this possible is a set of Web services or not is not that critical, provided there is an appreciation of what is being alluded to here.

In addition to supporting at least one node API set, the three other criteria to which a UDDI node has to conform are as follows:

It interacts with UDDI data via the appropriate UDDI API sets.
A UDDI node can only be a member of exactly one UDDI Registry.
A UDDI node, at least conceptually, has full access to and can manipulate data structures of a complete logical copy of the total data managed by the registry of which they are a part. All interactions made via that node s query or publish API sets must always apply to these data ”and no other (i.e., the UDDI APIs should only be used to access and manipulate the data associated with the UDDI Registry).

A UDDI Registry is made up of one or more UDDI nodes. When a registry is comprised of multiple nodes, all the nodes have to work in a collaborative manner to ensure that all nodes have access to the same logical set of data. The nodes making up a registry are collectively responsible for managing the UDDI data associated with that registry. The nodes will typically achieve this goal by using UDDI replication between the nodes using the UDDI Replication API set.

As previously stressed, the UDDI specification does not specify any implementation criteria for realizing a UDDI node or a UDDI Registry. Thus, the UBR was implemented, from day one, as a multinode registry. However, most private (if not semiprivate) registries are likely, at least to begin with, to just consist of one node. How a given registry implements policy decisions (e.g., authentication, integrity, support of digital certificates, and so forth) is also left as an implementation option. However, the necessary policy decisions have to be implemented in a consistent manner at each and every applicable point within the registry. A registry, however, has the option of delegating certain policy decisions to individual nodes ” which is true in the case of the UBR.

Figure 4.14 brings this architecture-related section to a close by showing, in a stack -oriented depiction, how and where UDDI fits in relative to the other Web services “related methodologies.

Figure 4.14: The Web services stack showing the basic relationship between the various Web services enabling technologies and UDDI.