Overview of UDDI

UDDI stands for Universal Description, Discovery, and Integration. The UDDI Project is an industry initiative aims to enable businesses to quickly, easily, and dynamically find and carry out transactions with one another.

A populated UDDI registry contains cataloged information about businesses; the services that they offer; and communication standards and interfaces they use to conduct transactions.

Built on the Simple Object Access Protocol (SOAP) data communication standard, UDDI creates a global, platform-independent, open architecture space that will benefit businesses.

UDDI and Web Services

The owners of Web Services publish them to the UDDI registry. Once published, the UDDI registry maintains pointers to the Web Service description and to the service.

The UDDI allows clients to search this registry, find the intended service, and retrieve its details. These details include the service invocation point as well as other information to help identify the service and its functionality.

Web Service capabilities are exposed through a programming interface, and usually explained through Web Services Description Language (WSDL). In a typical publish-and-inquire scenario, the provider publishes its business; registers a service under it; and defines a binding template with technical information on its Web Service. The binding template also holds reference to one or several tModels, which represent abstract interfaces implemented by the Web Service. The tModels might have been uniquely published by the provider, with information on the interfaces and URL references to the WSDL document.

A typical client inquiry may have one of two objectives:

To find an implementation of a known interface. In other words, the client has a tModel ID and seeks binding templates referencing that tModel.

To find the updated value of the invocation point (that is., access point) of a known binding template ID.

UDDI and Business Registry

As a Business Registry solution, UDDI enables companies to advertise the business products and services they provide, as well as how they conduct business transactions on the Web. This use of UDDI complements business-to-business (B2B) electronic commerce.

The minimum required information to publish a business is a single business name. Once completed, a full description of a business entity may contain a wealth of information, all of which helps to advertise the business entity and its products and services in a precise and accessible manner.

A Business Registry can contain:

Business Identification - Multiple names and descriptions of the business, comprehensive contact information, and standard business identifiers such as a tax identifier.

Service Description - Multiple names and descriptions of a service. As a container for service information, companies can advertise numerous services, while clearly displaying the ownership of services. The bindingTemplate information describes how to access the service.

Standards Compliance - In some cases it is important to specify compliance with standards. These standards might display detailed technical requirements on how to use the service.

Custom Categories - It is possible to publish proprietary specifications (tModels) that identify or categorize businesses or services.

UDDI Data Structure

The data structure within UDDI consists of four constructions: a businessEntity structure, a businessService structure, a bindingTemplate structure and a tModel structure.

The following table outlines the difference between these constructions when used for Web Service or Business Registry applications.

Table 11-1 UDDI Data Structure

Data Structure

Web Service

Business Registry

businessEntity

Represents a Web Service provider:

Company name

Contact detail

Other business information

Represents a company, a division or a department within a company:

Company name(s)

Contact details

Identifiers and Categories

businessService

A logical group of one or several Web Services.

API(s) with a single name stored as a child element, contained by the business entity named above.

A group of services may reside in a single businessEntity.

Multiple names and descriptions

Categories

Indicators of compliancy with standards

bindingTemplate

A single Web Service.

Technical information needed by client applications to bind and interact with the target Web Service.

Contains access point (that is, the URI to invoke a Web Service).

Further instances of standards conformity.

Access points for the service in form of URLs, phone numbers, email addresses, fax numbers or other similar address types.

tModel

Represents a technical specification; typically a specifications pointer, or metadata about a specification document, including a name and a URL pointing to the actual specifications. In the context of Web Services, the actual specifications document is presented in the form of a WSDL file.

Represents a standard or technical specification, either well established or registered by a user for specific use.

WebLogic Server UDDI Features

UDDI 2.0 Server

The UDDI 2.0 Server is part of WebLogic Server and is started automatically when WebLogic Server is started. The UDDI Server implements the UDDI 2.0 server specification at http://uddi.xml.org.

Configuring the UDDI 2.0 Server

To configure the UDDI 2.0 Server:

Stop WebLogic Server.

Update the uddi.properties file, located in the WL_HOME/server/lib directory, where WL_HOME refers to the main WebLogic Server installation directory.

Note:

If your WebLogic Server domain was created by a user different from the user that installed WebLogic Server, the WebLogic Server administrator must change the permissions on the uddi.properties file to give access to all users.

Restart WebLogic Server.

Never edit the uddi.properties file while WebLogic Server is running. Should you modify this file in a way that prevents the successful startup of the UDDI Server, refer to the WL_HOME/server/lib/uddi.properties.booted file for the last known good configuration.

To restore your configuration to its default, remove the uddi.properties file from the WL_HOME/server/lib directory. Oracle strongly recommends that you move this file to a backup location, because a new uddi.properties file will be created and with its successful startup, the uddi.properties.booted file will also be overwritten. After removing the properties file, start the server. Minimal default properties will be loaded and written to a newly created uddi.properties file.

The following section describes the UDDI Server properties that you can include in the uddi.properites file. The list of properties has been divided according to component, usage, and functionality. At any given time, you do not need all these properties to be present.

Configuring an External LDAP Server

The UDDI 2.0 Server is automatically configured with an embedded LDAP server. You can, however, also configure an external LDAP Server by following the procedure in this section.

Note:

Currently, WebLogic Server supports only the SunOne Directory Server for use with the UDDI 2.0 Server.

To configure the SunOne Directory Server to be used with UDDI, follow these steps:

Create a file called 51acumen.ldif in the LDAP_DIR/Sun/MPS/slapd-LDAP_INSTANCE_NAME/config/schema directory, where LDAP_DIR refers to the root installation directory of your SunOne Directory Server and LDAP_INSTANCE_NAME refers to the instance name.

DiscoveryURL prefix that is set for each saved business entity. Typically this is the full URL to the uddilistener servlet, so that the full DiscoveryURL results in the display of the stored BusinessEntity data.

auddi.inquiry.secure

Permissible values are true and false. When set to true, inquiry calls to UDDI Server are limited to secure https connections only. Any UDDI inquiry calls through a regular http URL are rejected.

auddi.publish.secure

Permissible values are true and false. When set to true, publish calls to UDDI Server are limited to secure https connections only. Any UDDI publish calls through a regular http URL are rejected.

auddi.search.maxrows

Maximum number of returned rows for search operations. When the search results in a higher number of rows then the limit set by this property, the result is truncated.

auddi.search.timeout

Timeout value for search operations. The value is indicated in milliseconds.

auddi.siteoperator

Name of the UDDI registry site operator. The specified value will be used as the operator attribute, saved in all future BusinessEntity registrations. This attribute will later be returned in responses, and indicates which UDDI registry has generated the response.

security.cred.life

Credential life, specified in seconds, for authentication. Upon authentication of a user, an AuthToken is assigned which will be valid for the duration specified by this property.

pluggableTModel.file.list

UDDI Server is pre-populated with a set of Standard TModels. You can further customize the UDDI server by providing your own taxonomies, in the form of TModels. Taxonomies must be defined in XML files, following the provided XML schema. The value of this property a comma-separated list of URIs to such XML files. Values that refer to these TModels are checked and validated against the specified taxonomy.

Table 11-3 UDDI User Defaults

UDDI Property Key

Description

auddi.default.lang

User's initial language, assigned to user profile by default at the time of creation. User profile settings can be changed at sign-up or later.

auddi.default.quota.assertion

User's initial assertion quota, assigned to user profile by default at the time of creation. The assertion quota is the maximum number of publisher assertions that the user is allowed to publish. To impose no limits, set a value of -1. A user's profile settings can be changed at sign-up or later.

auddi.default.quota.binding

User's initial binding quota, assigned to user profile by default at the time of creation. The binding quota is the maximum number of binding templates that the user is allowed to publish, per each business service. To impose no limits, set a value of -1. A user's profile settings can be changed at sign-up or later.

auddi.default.quota.entity

User's initial business entity quota, assigned to user profile by default at the time of creation. The entity quota is the maximum number of business entities that the user is allowed to publish. To impose no limits, set a value of -1. A user's profile settings can be changed at sign-up or later.

auddi.default.quota.messageSize

User's initial message size limit, assigned to his user profile by default at the time of creation. The message size limit is the maximum size of a SOAP call that the user may send to UDDI Server. To impose no limits, set a value of -1. A user's profile settings can be changed at sign-up or later.

auddi.default.quota.service

User's initial service quota, assigned to user profile by default at the time of creation. The service quota is the maximum number of business services that the user is allowed to publish, per each business entity. To impose no limits, set a value of -1. A user's profile settings can be changed at sign-up or later.

auddi.default.quota.tmodel

User's initial TModel quota, assigned to user profile by default at the time of creation. The TModel quota is the maximum number of TModels that the user is allowed to publish. To impose no limits, set a value of -1. A user's profile settings can be changed at sign-up or later.

Table 11-4 General Server Configuration

UDDI Property Keys

Description

auddi.datasource.type

Location of physical storage of UDDI data. This value defaults to WLS, which indicates that the internal LDAP directory of WebLogic Server is to be used for data storage. Other permissible values include LDAP, ReplicaLDAP, and File.

auddi.security.type

UDDI Server's security module (authentication). This value defaults to WLS, which indicates that the default security realm of WebLogic Server is to be used for UDDI authentication. As such, a WebLogic Server user would be an UDDI Server user and any WebLogic Server administrator would also be an UDDI Server administrator, in addition to members of the UDDI Server administrator group, as defined in UDDI Server settings. Other permissible values include LDAP and File.

Table 11-5 Logger Configuration

UDDI Property Key

Description

logger.file.maxsize

Maximum size of logger output files (if output is sent to file), in Kilobytes. Once an output file reaches maximum size, it is closed and a new log file is created.

logger.indent.enabled

Permissible values are true and false. When set to true, log messages beginning with "+" and "-", typically TRACE level logs, cause an increase or decrease of indentation in the output.

logger.indent.size

Size of each indentation (how many spaces for each indent), specified as an integer.

logger.log.dir

Absolute or relative path to a directory where log files are stored.

logger.log.file.stem

String that is prefixed to all log file names.

logger.log.type

Determines whether log messages are sent to the screen, to a file or to both destinations. Permissible values, respectively, are: LOG_TYPE_SCREEN, LOG_TYPE_FILE, and LOG_TYPE_SCREEN_FILE.

logger.output.style

Determines whether logged output will simply contain the message, or thread and timestamp information will be included. Permissible values are OUTPUT_LONG and OUTPUT_SHORT.

Logger's verbosity level. Permissible values (case sensitive) are TRACE, DEBUG, INFO, WARNING and ERROR, where each severity level includes the following ones accumulatively.

Table 11-6 Connection Pools

UDDI Property Key

Description

datasource.ldap.pool.increment

Number of new connections to create and add to the pool when all connections in the pool are busy

datasource.ldap.pool.initialsize

Number of connections to be stored at the time of creation and initialization of the pool.

datasource.ldap.pool.maxsize

Maximum number of connections that the pool may hold.

datasource.ldap.pool.systemmaxsize

Maximum number of connections created, even after the pool has reached its capacity. Once the pool reaches its maximum size, and all connections are busy, connections are temporarily created and returned to the client, but not stored in the pool. However, once the system max size is reached, all requests for new connections are blocked until a previously busy connection becomes available.

Password for the datasource.ldap.manager.uid, establishes connections with the LDAP directory used for data storage.

datasource.ldap.server.url

"ldap://" URL to the LDAP directory used for data storage.

datasource.ldap.server.root

Root entry of the LDAP directory used for data storage (e.g., dc=acumenat, dc=com).

Note:

In a replicated LDAP environment, there are "m" LDAP masters and "n" LDAP replicas, respectively numbered from 0 to (m-1) and from 0 to (n-1). The fifth part of the property keys below, quoted as "i", refers to this number and differs for each LDAP server instance defined.

For more information about using the UDDI Directory Explorer, click the Explorer Help link on the main page.

UDDI Client API

WebLogic Server includes an implementation of the client-side UDDI API that you can use in your Java client applications to programmatically search for and publish Web Services.

The two main classes of the UDDI client API are Inquiry and Publish. Use the Inquiry class to search for Web Services in a known UDDI registry and the Publish class to add your Web Service to a known registry.

WebLogic Server provides an implementation of the following client UDDI API packages:

For detailed information on using these packages, see the UDDI API Javadocs.

Pluggable tModel

A taxonomy is basically a tModel used as reference by a categoryBag or identifierBag. A major distinction is that in contrast to a simple tModel, references to a taxonomy are typically checked and validated. WebLogic Server's UDDI Server takes advantage of this concept and extends this capability by introducing custom taxonomies, called "pluggable tModels". Pluggable tModels allow users (UDDI administrators) to add their own checked taxonomies to the UDDI registry, or overwrite standard taxonomies.