UDDI Data Model Basic Concepts of the UDDI Specification

• 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. tModel 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 tModels 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.

1.3.2. Taxonomic Classifications

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 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. Oracle Service Registry allows definition of enterprise taxonomies. Users can also download and upload any taxonomy as an XML file. Oracle Service Registry offers tools for creating, modifying and browsing taxonomies on both the web user interface and SOAP API levels. Checked and Unchecked Taxonomies 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 Oracle 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. Page 156 Checked and Unchecked Taxonomies

1.3.3. Security Considerations

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. Oracle 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 Oracle 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 publishers identity.

1.3.4. Notification and Subscription

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.

1.3.5. Replication

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.

1.3.6. UDDI APIs

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 . Page 157

1.3.6. UDDI APIs