UDDI registry terminology
Some terms specific to the UDDI registry are explained. Also, the relationship between the versions of the UDDI registry, the Organization for the Advancement of Structured Information (OASIS) specification, and the WebSphere Application Server level are shown.
Throughout the UDDI information in this information center, the directory location of WAS is referred to as app_server_root.
(iSeries) Throughout the UDDI information in this information center, the directory locations of WAS are referred to as app_server_root and profile_root.
UDDI Definitions
- bindingTemplate
- AbindingTemplate is technical information about a service entry point and construction specifications.
- businessEntity
- A businessEntity is information about the party who publishes information about a family of services.
- businessService
- A businessService is descriptive information about a particular service.
- customized UDDI node
- A customized UDDI node is a UDDI node that is initialized with customized settings for the UDDI properties and UDDI policies. In particular, this type kind of node does not have default values for those properties that are read-only after initialization.
Use a customized UDDI node for anything other than simple testing purposes (for which a default UDDI node is enough). To set up a customized UDDI node, see the topic about setting up a customized UDDI node.
When we first start a customized UDDI node, we must set values for certain properties, and then initialize the node (using the administrative console or UDDI administrative interface), before the node is ready to accept UDDI requests. The properties that we must set control characteristics of the UDDI node that cannot be changed after initialization.
An advantage of using a customized UDDI node is that can set these properties to values that are suitable for the environment and usage of UDDI.
After a customized UDDI node is initialized, it is the same as a default UDDI node except that it uses customized UDDI property and policy values.
- default UDDI node
- A default UDDI node is a UDDI node that is initialized with default settings for the UDDI properties and UDDI policies, including the properties that are read-only after initialization. A default UDDI node is intended for use for testing and to provide a simple way to become familiar with the behavior of the UDDI registry.
We can set up a default UDDI node in two ways. The first is to run the uddiDeploy.jacl script, specifying the 'default' option, in which case the UDDI database will be an Apache Derby database created for you automatically.
The second is to create the database ourself, specifying the default option, which for Apache Derby is the DEFAULT parameter when using the UDDIDerbyCreate.jar file, and for DB2 or Oracle the SQL script insert_default_database_indicator.
(ZOS) The second is to make sure the PDS member INSERT is included in the JCL used to create the database, in which case the UDDI database can be Apache Derby or DB2.
After a default UDDI node is initialized, it is the same as a customized UDDI node except that it uses default UDDI property and policy values.
- policy profile
- A policy profile is set of UDDI policies. The default policy profile is the profile created when the default UDDI node is created. In the default policy profile, the nodeID and root key generator are set to read-only and cannot be changed after installation.
- publisherAssertion
- A publisherAssertion is information about a relationship between two parties, asserted by one or both.
- tModel
- A tModel (short for technical model) is a data structure representing a reusable concept, such as a web service type, a protocol used by web services, or a category system.
tModel keys in a service description are a technical "fingerprint" we can use to trace the compatibility origins of a given service. They provide a common point of reference so that we can identify compatible services.
tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels that represent value sets such as category, identifier, and relationship systems are used to provide additional data to the UDDI core entities to aid discovery along a number of dimensions. This additional data is captured in keyedReferences in categoryBags, identifierBags, or publisherAssertions. The tModelKey attributes in these keyedReferences refer to the value set that relates to the concept or namespace being represented. The keyValues contain the values from that value set. In some cases, keyNames are significant, for example, to describe relationships and when using the general keywords value set. In all other cases, keyNames provide a version of the keyValue that people can read.
- UDDI application
- The UDDI application is the UDDI registry enterprise application.
- UDDI entitlement
- A UDDI entitlement is an entitlement that a UDDI user or publisher has in a UDDI registry, such as the capability to publish keyGenerators, or the tier to which the publisher is assigned (in other words, the number of entities that the publisher is entitled to publish). Each UDDI publisher has a range of settings for the various UDDI entitlements. A UDDI entitlement is sometimes referred to as a 'user entitlement', or as the UDDI publisher set of 'user entitlements'.
- UDDI node
- A UDDI node is a set of web services that supports at least one of the UDDI API sets, which supports interaction with UDDI data through the UDDI APIs. There is no direct mapping between a UDDI node and a WAS node. A UDDI node consists of an instance of the UDDI application running in an application server (or a cluster of UDDI application instances running in a cluster of application servers), together with an instance of the UDDI database containing UDDI data.
- UDDI node initialization
- UDDI node initialization is the process that sets up values in the UDDI database, and establishes the "personality" of the UDDI node. A UDDI node cannot accept UDDI API requests until it is initialized.
- UDDI node state
- The UDDI node state describes the current state of the UDDI node, as opposed to the state of the UDDI application (which is either stopped or started). A UDDI node can be in one of the following states:
- not initialized
- initialization pending
- initialization in progress
- migration pending
- migration in progress
- value set creation pending
- value set creation in progress
- activated
- deactivated
- UDDI NodeId
- The UDDI NodeId is a unique identifier of a UDDI node.
- UDDI policy
- A UDDI policy is a statement of required and expected behavior of a UDDI registry, specified using policy values for the various policies defined in the UDDI Version specification.
- UDDI property
- A UDDI property is a value for a property that controls the personality or behavior of a UDDI node.
- UDDI publisher
- A UDDI publisher is a WAS user who is entitled to publish UDDI entities to a specified UDDI registry. A UDDI publisher is sometimes referred to as a 'UDDI user', or just as a 'publisher' when used in a UDDI context.
- UDDI registry
- A UDDI registry comprises one or more UDDI nodes. The UDDI registry in this version of WAS supports single-node UDDI registries only.
- UDDI tier
- A UDDI tier determines the number of UDDI entities of each type (business, services per business, bindings per service, tModel, publisher assertion) that a UDDI publisher is entitled to publish. Each UDDI publisher is assigned (either by default or explicitly by a UDDI administrator) to a particular tier, and cannot publish more entities than are allowed for that tier. There are some predefined tiers supplied with the UDDI registry, and a UDDI administrator can create additional tiers. A UDDI tier is often referred to just as a 'tier' when used in a UDDI context.
- v2 UDDI registry
- A v2 UDDI registry is a UDDI registry implementation that supports v2 of the UDDI specification and also Version 1. A v2 UDDI registry is included in WAS ND v6.1.
- Version 3 UDDI registry
- A Version 3 UDDI registry is a UDDI registry implementation that supports Version 3 of the UDDI specification, and also Versions 1 and 2. A Version 3 UDDI registry is included in WAS. Note that Version 3 UDDI registry does not indicate a UDDI registry implementation that supports only UDDI Version 3 requests.
The following table shows how the various versions of the UDDI registry relate to the relevant OASIS specification and versions of WAS:
UDDI registry Version OASIS UDDI specification levels supported Version of WAS that supports the UDDI registry 3.0.2
- UDDI Version 1
- UDDI v2.0.4 (APIs), v2.0.3 (data structures)
- UDDI Version 3.0.2
6.1 and later (ZOS) 3.0.2 (ZOS)
- UDDI Version 1
- UDDI v2.0.4 (APIs), v2.0.3 (data structures)
- UDDI Version 3.0.2
(ZOS) 6.1 and later
Set up a customized UDDI node