UDDI Registry terminology

Throughout the UDDI documentation in this Information Center the directory location of WAS is referred to as install_root. The default locations are:

  • C:\Program Files\IBM\WebSphere\AppServer\

  • /opt/IBM/WebSphere/AppServer/

  • /usr/IBM/WebSphere/AppServer/

 

UDDI Definitions

bindingTemplate

Technical information about a service entry point and construction specifications.

businessEntity

Information about the party who publishes information about a family of services.

businessService

Descriptive information about a particular service.

Customized UDDI node

This is a UDDI node that is initialized with customized settings for the UDDI properties and UDDI policies; in particular this kind of node will have non-default values for those properties that are read-only after initialization.

A customized UDDI node is recommended for anything other than simple testing purposes (for which a default UDDI node is sufficient). We can set up a customized UDDI node by following the instructions in Setting up a customized UDDI node.

When a customized UDDI node is first started, 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 need to be set control characteristics of the UDDI node that cannot be changed after initialization.

An advantage of using a customized UDDI node is that it allows you to set these properties to values that are suitable for your environment and usage of UDDI.

After a customized UDDI node has been initialized, it differs from a default UDDI node only in that it uses customized UDDI property and policy values.

Default UDDI node

This is a UDDI node which has been 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 test purposes and as a simple way to become familiar with the behavior of the UDDI Registry.

You can set up a default UDDI node in two ways. The first is to specify the 'default' option when you run the uddiDeploy.jacl script, in which case the UDDI database will be a Cloudscape database. The second is to run the supplied SQL script insert_default_database_indicator against the UDDI database, in which case the UDDI database can be Cloudscape, DB2 or Oracle

After a default UDDI node has been initialized, it differs from a customized UDDI node only in that it uses default UDDI property and policy values.

Policy profile

A set of UDDI policies. The default policy profile is the profile created when the default UDDI node is created. In this instance, the nodeID and root key generator are set to read only and are unchangeable after installation.

publisherAssertion

Information about a relationship between two parties, asserted by one or both.

tModel

Short for technical model.

A tModel 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 within a service description are a technical "fingerprint" that use to trace the compatibility origins of a given service. They provide a common point of reference that allows you to 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 facilitate discovery along a number of dimensions. This additional data is captured in keyedReferences that reside in category Bags, 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 actual values from that value set. In some cases keyNames are significant, such as for describing relationships and when using the general keywords value set. In all other cases, however, keyNames are used to provide a human readable version of what is in the keyValue.

UDDI Application

The IBM WebSphere UDDI Registry J2EE application.

UDDI entitlement

An entitlement that a UDDI user or publisher has within 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 will have 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's set of 'user entitlements'.

UDDI Node

A set of Web Services supporting 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

The process of node initialization 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 has been initialized.

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). The state of a UDDI node can be one of not initialized, initialization pending, initialization in progress, activated or deactivated.

UDDI NodeId

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 via policy values for the various policies defined in the UDDI VSpecification.

UDDI property

A value for a property which controls the personality or behavior of a UDDI node.

UDDI publisher

A WebSphere 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 simply as a 'publisher' when used in a UDDI context.

UDDI Registry

A UDDI Registry comprises one or more UDDI nodes. The IBM WebSphere UDDI Registry in WAS v6 only supports single-node UDDI registries.

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 will be assigned (either by default or explicitly by a UDDI administrator) to a particular tier, and will not be able to 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 simply as a 'tier' when used in a UDDI context.

V2 UDDI Registry

A shorthand term used to refer to an IBM WebSphere UDDI Registry implementation which supports V2 of the UDDI specification (and also V1). A V2 UDDI Registry is included in WAS Network Deployment V5.x.

V3 UDDI Registry

A shorthand term used to refer to an IBM WebSphere UDDI Registry implementation which supports V3 of the UDDI specification (and also Versions 1 and 2). A V3 UDDI Registry is included in WebSphere Application Server v6. It should be noted that the term 'V3 UDDI Registry' does not indicate a registry which only supports UDDI version 3 requests.

The following table shows how the various versions of the IBM UDDI Registry relate to the relevant OASIS specification and WebSphere Application Server level:

IBM UDDI Registry Version OASIS UDDI specification levels supported Supported on WebSphere Application Server version
1.1

  • UDDI V1

  • UDDI V2

4.0.2
1.1.1

  • UDDI V1

  • UDDI V2

4.0.3 and later
2.0.x

  • UDDI V1

  • UDDI V2

5.0.x and later
2.1.x

  • UDDI V1

  • UDDI V2

5.1.x and later
3.0.2

  • UDDI V1

  • UDDI V2.0.4 (APIs), V2.0.3 (data structures)

  • UDDI V3.0.2

6.0