This project has retired. For details please refer to its Attic page.
Chapter 11. Using the UDDI Technology Compatibility Kit

JBoss.orgCommunity Documentation

Chapter 11. Using the UDDI Technology Compatibility Kit

Table of Contents

11.1. Using the TCK Runner
11.1.1. Configuration
11.1.2. Running the TCK Runner
11.2. Analyzing the Results

Since UDDI is a specification with many complex rules in it, we (the jUDDI team) have had to write test cases to exercise each of the rules and restrictions in UDDI. Knowing that there are a number of open source and commercial UDDI v3 implementations, the jUDDI team took this as an opportunity to create a reusable benchmark for testing the compatibility of UDDI v3 implementations.

Important

Although the TCK covers a large number of test cases, the UDDI specification is long and complex. It’s more than possible that we missed a few scenarios or test cases. If you run across any, please let us know.

11.1. Using the TCK Runner

The TCK Runner requires a few files to operate:

  1. juddi-tck-runner-version.jar - This is the executable
  2. uddi.xml - This file sets the location of the UDDI services
  3. tck.properties - This file controls what tests are ran.
  4. truststore and keystore.jks - These files are for digital signature tests

Tip

Do not use usernames and passwords that already have data associated with it.

A few of the test cases, such as RMI transport, are not identified by the UDDI specification, therefore the results may be skewed if unsupported tests are attempted. In addition, the UDDI specification identifies a number of APIs and features that are considered optional.

Although it is possible to run the TCK against a UDDIv2 registry using the UDDIv2 transport adapters, this is not supported. The TCK’s test cases and rules apply to the business rules defined in UDDIv3. Unsupported and unmapped functions defined in UDDIv3 that are not supported in UDDIv2 fail ultimately fail.

The TCK properties file contains settings for all of the TCK tests.

  1. Credentials - You’ll need credentials for a number of user accounts
  2. jUDDI optional tests - If you’re running the tests against jUDDI, there’s a number of additional tests ran to exercise things like user accounts.
  3. Load testing - These settings enable you to tweak or disable the load testing.
  4. Key stores - These are needed to run the digital signature tests
  5. Supported transports - jUDDI supports a number of transports, such as RMI and HTTP (for UDDI service interaction) and SMTP and HTTP for subscription callbacks. RMI is actually not in the spec and SMTP is considered optional, so you’ll want to adjusted these based on the available documentation from the vendor.

The only parts used from uddi.xml are the following

  1. The endpoints of the UDDI services
  2. The client subscription callback settings

Executing the TCK runner is simple.

java (options) -Duddi.client.xml=uddi.xml -jar juddi-tck-runner-{VERSION}-SNAPSHOT-jar-with-dependencies.jar

Optional parameters

11.2. Analyzing the Results

There are two ways to identify the result of the tests.

The results are summarized in the uddi-tck-results file along with the specific error conditions and stack traces that will enable you to find out the root cause of the failure. It may be necessary to obtain UDDI server logs to help with root cause identification.