WAS v8.5 > Develop applications > Develop web services - UDDI registry > Develop with the UDDI registryUDDI registry client programming
The UDDI registry provides several APIs used to access the UDDI registry programmatically.
The UDDI v3 registry supports multiple versions of UDDI. It supports UDDI v1, v2, and v3.
For details of the v1 and v2 API, refer to the UDDI v2 Specifications.
For details of the UDDI v3.0.2 API, refer to the UDDI v3.0.2 Specification.
The UDDI registry information in this information center defines the support the UDDI registry provides for the UDDI v3.0.2 specification and associated addenda.
The following UDDI v3 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.
- Learn about the standard aspects of the UDDI APIs using the following topics.
- UDDI registry v3 entity keys explains UDDI entity keys, and the capability with UDDI v3 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.
- Access the APIs programmatically. The recommended client API is the UDDI v3 Client, which allows access to the UDDI v3 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 v1 and v2 APIs. These class libraries are both deprecated in this release, and are replaced by the UDDI v3 Client for Java.
- The UDDI EJB Interface provides an EJB interface to the UDDI v2 APIs. The UDDI EJB interface is deprecated in this release.
Although the recommended programmatic access to the UDDI APIs is through the UDDI v3 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 v3 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 v3 registry
Use the UDDI Publish API to publish, delete, and update information contained in a UDDI registry. The messages that are defined in this section all behave synchronously.- Custody and Ownership Transfer API for the UDDI v3 registry
Use the UDDI Custody and Ownership Transfer API to transfer custody or ownership of one or more entities that are contained in a UDDI v3 registry. The UDDI v3 registry supports only intra-node ownership transfer; it does not support inter-node custody transfer.- Security API for the UDDI v3 registry
The UDDI v3 registry has an independent Security API, unlike UDDI v1 and v2, where the Security API is part of the Publish API.- UDDI registry v3 entity keys
The UDDI v3 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 v3, publishers can digitally sign UDDI elements while they are publishing. The UDDI v3 schema supports the signing of businessEntity, businessServices, bindingTemplate, tModel, and publisherAssertion elements.- UDDI v3 Client
We can use the UDDI v3 Client for Java to access the UDDI v3 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 v3 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 v3 supports different end points for different services.- UDDI4J programming interface (Deprecated)
The UDDI4J v2 APIs are deprecated in this version of WAS. The UDDI v3 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.
Related information: