Introducing UDDI 3.0: Changes to the Information Model

Let's continue our examination of new features in Universal Description, Discovery, and Integration (UDDI) 3.0. In version 3.0, UDDI's information model has changed to include new data structures and elements, making directories more flexible in the way they categorize and present data in the registry—and thus making searches more flexible as well.

More Granular Searches
The bindingTemplate element contains technical descriptions of Web services in a UDDI registry and describes the Web services' network location (URL) settings and parameters. In UDDI 3.0, the categoryBag structure can contain a list of categorizations that describe a specific aspect of the bindingTemplate element—for example, to categorize bindingTemplate as "production," or "France," or "gadgets." The categorizations within categoryBag apply only to a particular bindingTemplate, not to other technical descriptions of Web pages. In other words, whereas in earlier UDDI versions applications could search a registry according to the technical information in bindingTemplate, in UDDI 3.0, applications can search for a categorization within categoryBag's technical description—thus facilitating more granular searches.

The categorizations in categoryBag are effective because UDDI 3.0 supports complex categorization, a standardized set of codes that identify countries or products. Categories can identify single elements (e.g., showing that a certain entity supports selling power supplies) or groups of elements (e.g., showing that a certain entity supports selling power supplies to buyers in the United States).

Separation of Metadata and Data
Because UDDI 3.0 supports digital signing of entities (as I discussed in the August 8, 2002, .NET UPDATE) and uses metadata to generate digital signatures, this version of the specification needs to be able to separate metadata and data. To do so, UDDI 3.0 includes a new data structure, operationalInfo, which stores the date and time of data creation or modification, the identity of the node that has custody of the entity, and (optionally) the identity of the data's owner.

Support for Multiple Overview Documents
Technical Models (tModels) describe UDDI entries; applications can more easily find the data they need by using tModels. An optional part of the tModel is the overviewDoc element, which describes how applications should use the tModel. UDDI 3.0 supports multiple overviewDoc elements, making it possible for one tModel to contain multiple descriptions to apply to various situations.

Enlarged and Enhanced Schema
The UDDI 3.0 schema is enhanced to define syntax requirements, which decrease the likelihood of syntax errors. Users can also now customize the UDDI schema by developing extensions to it. Doing so isn't a complication-free process—anyone who develops extensions will need to build in support for registries and users who aren't set up to use the extensions. Also, if you move entities into registries that don't use the extensions you develop, you might need to modify or delete the extensions. However, in UDDI 3.0, you can extend the schema.

International Language Support
UDDI 3.0 supports internationalized character sets and languages. Other capabilities exist to support internationalized searches.

Improved WSDL and Redirection Support
UDDI 3.0 supports a new useType attribute to the accessPoint, overviewURL, discoveryURL, contact, address, email, and phone elements. Depending on its value, this attribute can point users to external Web services at a particular URL, invoke a Web Service Description Language (WSDL) document within the entity, send users to another location in the UDDI registry, or even send users to a hidden location to let them use a particular service without necessarily knowing where the attribute is redirecting them.

You can learn more about the UDDI 3.0 specification at http://uddi.org/pubs/uddi_v3.htm

End of Article