UDDI is based upon several established industry standards, including HTTP, XML, XML Schema (XSD), SOAP, and WSDL. The latest version of the UDDI specification is available at: http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3.
The UDDI specification describes a registry of Web services and its programmatic interfaces. UDDI itself is a set of Web services. The UDDI specification defines services that support the description and discovery of:
Businesses, organizations and other providers of Web services;
The Web services they make available;
The technical interfaces which may be used to access and manage those services.
The basic information model and interaction framework of UDDI registries consist of the following data structures:
A description of a service business function is represented as a businessService.
Information about a provider that publishes the service is put into a businessEntity.
The service's technical details, including a reference to the service's programmatic interface or API, is stored in a bindingTemplate.
Various other attributes, or metadata, such as taxonomy, transports, and policies, are stored in tModels.
These UDDI data structures are expressed in XML and are stored persistently by a UDDI registry. Within a UDDI registry, each core data structure is assigned a unique identifier according to a standard scheme. This identifier is referred as a UDDI key.
A business entity represents an organization or group of people responsible for a set of services (a service provider). It can also represent anything that overreaches a set of services; for example a development project, department or organization. The business entity structure contains the following elements:
Names and Descriptions. The business entity can have a set of names and descriptions, in a variety of languages if necessary.
Contacts. The list of people who are associated with the business entity. A contact can include, for example, a contact name, addresses, phone numbers, and use type.
Categories. Set of categories that represent the business entity's features or quantities. For example the business entity can be associated with the category California to say that the business entity is located in that geographical area.
Identifiers. The business entity can be associated with arbitrary number of identifiers that uniquely identify it. For example, the business entity can be identified by a department number or D-U-N-S number.
Discovery URLs are additional links to documents describing the business entity.
Business entities can be linked to one another using so-called assertions that model a relationships between them.
Business services represent functionality or resources provided by business entities. A business entity can reference multiple business services. A business service is described by the following elements:
Names and descriptions. The business service can have a set of names and descriptions, in a variety of languages if necessary.
Categories. A set of categories that represent the business service features and quantities. For example, the business service can be associated by a category that represents service availability, version, etc.
A business service in a UDDI registry does not necessarily represent a Web service. The UDDI registry can register arbitrary services such as example EJB, CORBA, etc.
A business service can contain one or more binding templates. A binding template represents the technical details of how to invoke its service. Binding templates are described by the following elements:
Access point represents the service endpoint. It contains endpoint URI and specification of the protocol.
tModel instance infos can be used to represent any other information about the binding template
Categories. The binding template can be associated with categories to reference specific features of the binding template, for example certification status (test, production) or versions.
The tModel provides a reference to an abstraction describing compliance with a specification and concepts. TModels are described by the following elements:
Name and description. The tModel can have a set of names and descriptions, in different languages if required.
An overview document is a reference to a document that specifies the tModel's purpose.
Categories. Like all the other UDDI entities, tModels can be categorized.
Identifiers. The tModel can be associated with an arbitrary number of identifiers that uniquely identify it.
UDDI entities are categorized through tModels via taxonomies. Business entities, business services, and binding templates declare associations to a certain category by presence of specific tModels in their categoryBags.
UDDI provides a foundation and best practices that help provide semantic structure to the information about Web services contained in a registry. UDDI allows users to define multiple taxonomies that can be used in a registry. Users can employ an unlimited number of appropriate classification systems simultaneously. UDDI also defines a consistent way for a publisher to add new classification schemes to their registrations.
Taxonomies are used for representing various UDDI entity features and qualities (such as product types, geographical regions or departments in a company).
The UDDI specification mandates several standard taxonomies that must be shipped with each UDDI registry product. Some are internal UDDI taxonomies such as the UDDI types taxonomy or geographical taxonomy. A taxonomy can be marked as specific to business, service, binding template or tModel or it can be used with any type of the UDDI entity
Enterprise taxonomies are taxonomies that are specific to the particular enterprise or application. These taxonomies reflect specific categories like company departments, types of applications, and access protocols.
BEA AquaLogic Service Registry allows definition of enterprise taxonomies. Users can also download and upload any taxonomy as an XML file. BEA AquaLogic Service Registry offers tools for creating, modifying and browsing taxonomies on both the web user interface and SOAP API levels.
There are two types of taxonomies: checked and unchecked. Checked taxonomies are rigid, meaning that the UDDI registry does not allow the use of any categories other than those predefined in the taxonomy. Checked taxonomies are usually used when the taxonomy author can enumerate all distinct values within the taxonomy. A checked taxonomy can be validated using the internal validation service that is available in BEA AquaLogic Service Registry or by using an external validation service.
Unchecked taxonomies do not prescribe any set of fixed values and any name and value pair can be used for categorization of UDDI entities. Unchecked taxonomies are used for things like volume, weight, price, etc. A special case of the unchecked taxonomy is the general_keywords taxonomy that allows categorizations using arbitrary keywords.
UDDI specification does not define an access control mechanism. The UDDI specification allows modification of the specific entity only by its owner (creator). This does not scale in the enterprise environment where the right to modify or delete a specific UDDI entity must be assigned with more identities or even better with some role.
BEA AquaLogic Service Registry addresses this issue with the ACL (Access Control List) extension to the UDDI security model. Every UDDI entity can be associated with the ACL that defines who can find (list it in some UDDI query result), get (retrieve all details of the UDDI object), modify or delete it. The ACL can reference either the specific user account or user group.
The UDDI v3 specification provides support for digital signatures. In BEA AquaLogic Service Registry, the publisher of a UDDI structure can digitally sign that structure. The digital signature can be validated to verify the information is unmodified by any means and confirm the publisher's identity.
The UDDI v3 specification introduces notification and subscription features. Any UDDI registry user can subscribe to a set of UDDI entities and monitor their creation, modification and deletion. The subscription is defined using standard UDDI get or find API calls. The UDDI registry notifies the user whenever any entity that matches the subscription query changes even if the change causes the entity to not match the query anymore. It also notifies about entities that were changed in a way that after the change they match the subscription query.
The notification might be synchronous or asynchronous. By synchronous, we mean solicited notification when the interested party explicitly asks for all changes that have happened since the last notification. Asynchronous notifications are run periodically in a configurable interval and the interested party is notified whenever the matched entity is created, modified, or deleted.
Content of the UDDI registry can be replicated using the simple master-slave model. The UDDI registry can replicate data according to multiple replication definitions that are defined using UDDI standard queries. The master-slave relationship is specific to the replication definition. So one registry might be master for one specific replication definition and slave for another. The security settings (ACL, users, and groups) are not subject to replication but you can set permissions on replicated data.
The core data management tools functions of a UDDI registry are:
Publishing information about a service to a registry.
Searching a UDDI registry for information about a service.
The UDDI specification also includes concepts of:
Replicating and transferring custody of data about a service.
Registration key generation and management.
Registration subscription API set.
Security and authorization.
The UDDI specification divides these functions into Node API sets that are supported by a UDDI server and Client API Sets that are supported by a UDDI client .
Technical Notes (TN) are non-normative documents accompanying the UDDI Specification that provide guidance on how to use UDDI registries. Technical Notes can be found at http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm. One of the most important TNs is "Using WSDL in a UDDI Registry".
The most important features include:
User-friendly identifiers facilitate reuse of service descriptions among registries.
Support for digital signatures allows UDDI to deliver a higher degree of data integrity and authenticity.
Extended discovery features can combine previous, multi-step queries into a single-step, complex query. UDDI now also provides the ability to nest sub-queries within a single query, letting clients narrow their searches much more efficiently.