UDDI registry client programming

The UDDI registry provides several APIs we can use to access the UDDI registry programmatically.

The UDDI Version 3 registry supports multiple versions of UDDI. It supports UDDI Version 1, v2, and Version 3.

For details of the Version 1 and v2 API, refer to the UDDI Version 2 Specifications.

For details of the UDDI Version 3.0.2 API, refer to the UDDI Version 3.0.2 Specification.

The UDDI registry information in this information center defines the support that the UDDI registry provides for the UDDI Version 3.0.2 specification and associated addenda.

The following UDDI Version 3 API sets are supported:

• The UDDI V3 Inquiry API

• The UDDI V3 Publish API

• The UDDI V3 Custody and Ownership Transfer API

• The UDDI V3 Security API

Restriction: In DB2 for zSeries v7, the length of publish and inquiry strings are limited to 255 characters. If this limit is exceeded, error 10500 (E_Fatal) is returned. If we use a character set that uses multiple byte characters, it is easy to exceed this limit. Therefore, use care if we use this type of character set.

Tasks

1. Learn about the standard aspects of the UDDI APIs using the following topics.
   • UDDI registry Version 3 entity keys explains UDDI entity keys, and the capability with UDDI Version 3 to save UDDI entities with publisher-assigned keys.
   • Digital signatures and the UDDI registry explains the support for digital signing of UDDI entities, and for validation of signatures.

2. Access the APIs programmatically. The recommended client API is the UDDI Version 3 Client, which allows access to the UDDI Version 3 APIs from Java client code.

   Other client APIs are provided for compatibility with previous versions of the UDDI registry:

   • The UDDI4J programming interface provides Java class libraries for accessing UDDI Version 1 and v2 APIs. These class libraries are both deprecated in this release, and are replaced by the UDDI Version 3 Client for Java.

   • The UDDI EJB Interface provides an EJB interface to the UDDI Version 2 APIs. The UDDI EJB interface is deprecated in this release.

   Although the recommended programmatic access to the UDDI APIs is through the UDDI Version 3 Client for Java, it is also valid to use the UDDI APIs directly using SOAP. To use the SOAP API, construct a properly-formed UDDI message in the body of a SOAP request, and send it using HTTP POST to the appropriate SOAP endpoint for the UDDI service. The response is returned in the body of the HTTP reply.

   The UDDI registry samples include samples that demonstrate how to program directly to the SOAP API. The samples are written in Java code, but we can use other programming languages to create your SOAP client, provided that you still send requests that are compliant to the SOAP specification. Valid UDDI requests must conform to the UDDI schema, as detailed in the UDDI specification

   Support is also provided to use HTTP GET to return XML representations of UDDI entities: see HTTP GET services for UDDI registry data structures for details.

Subtopics

• Inquiry API for the UDDI Version 3 registry
  The Inquiry API provides four forms of query that follow broadly used conventions that match the needs of software that is traditionally used in registries.
• Publish API for the UDDI Version 3 registry
  Use the UDDI Publish API to publish, delete, and update information contained in a UDDI registry. The messages defined in this section all behave synchronously.
• Custody and Ownership Transfer API for the UDDI Version 3 registry
  Use the UDDI Custody and Ownership Transfer API to transfer custody or ownership of one or more entities contained in a UDDI Version 3 registry. The UDDI Version 3 registry supports only intra-node ownership transfer; it does not support inter-node custody transfer.
• Security API for the UDDI Version 3 registry
  The UDDI Version 3 registry has an independent Security API, unlike UDDI Version 1 and v2, where the Security API is part of the Publish API.
• UDDI registry Version 3 entity keys
  The UDDI Version 3 specification expands the space available for keys. Entity keys can be any Universal Resource Identifier (URI) that follows the recommended UDDI scheme. Depending on registry policy, both the UDDI registry and the publisher of the entity can assign keys.
• Digital signatures and the UDDI registry
  In UDDI Version 3, publishers can digitally sign UDDI elements while they are publishing. The UDDI Version 3 schema supports the signing of businessEntity, businessServices, bindingTemplate, tModel, and publisherAssertion elements.
• UDDI Version 3 Client
  Use the UDDI Version 3 Client for Java to access the UDDI Version 3 APIs from Java client code.
• HTTP GET services for UDDI registry data structures
  The UDDI registry offers an HTTP GET service for access to the XML representations of the businessEntity, businessService, bindingTemplate, and tModel UDDI data structures. The Uniform Resource Locators (URLs) at which these structures are accessible use the entity key as a URL parameter. The XML element that is returned is a businessDetail, serviceDetail, bindingDetail or tModelDetail element, according to the type of entity key supplied.
• UDDI registry SOAP service end points
  UDDI Version 3 supports multiple versions of SOAP API services. Depending on the security settings for WebSphere Application Server and the user data constraint transport guarantee settings for the UDDI SOAP service, UDDI Version 3 supports different end points for different services.
• UDDI4J programming interface (Deprecated)
  The UDDI4J v2 APIs are deprecated in this version of WAS. The UDDI Version 3 Client for Java is the preferred API for accessing UDDI through Java code.
• Use the UDDI EJB Interface (Deprecated)
  Use the EJB API of the UDDI registry component to publish, find, and delete UDDI entries. However, the UDDI EJB interface is deprecated and supports UDDI version 2 API requests only.

Samples for WAS

UDDI v2 Specifications

UDDI Version 3.0.2 Specification