Overview of the Version 3 UDDI registry
The Universal Description, Discovery, and Integration (UDDI) specification defines a way to publish and discover information about web services.
We can find the UDDI specification on the OASIS UDDI web page.
The UDDI specification defines a standard for the visibility, reusability, and manageability that are essential for a service-oriented architecture (SOA) registry service.
The UDDI registry is a directory for web services implemented using the UDDI specification. It is a component of WebSphere Application Server.
The UDDI registry is a critical component of the IBM on-demand service-oriented architecture. It solves the problem of discovery of technical components for an enterprise and its partners in the following ways:
- The UDDI registry provides control, flexibility, and confidentiality so an enterprise can protect its e-business investments.
- The UDDI registry increases efficiency by making it easier to identify technical assets.
- The UDDI registry leverages existing infrastructures
The following example shows how the UDDI registry can be used in a larger enterprise.
A company has an existing application that provides telephone numbers and human resources (HR) information about employees. This application is turned into a web service and published to the registry. A developer in the same company wants to write an application for a procurement function that also needs to provide HR information to the supplier. The application needs to give the supplier access to the employee account codes after the employee provides a name or serial number. Before web services, the developer might be in one of the following situations:
- The developer does not know about the similar application.
- The developer knows about the application, but cannot reuse it because of technical barriers.
- The developer knows about the application and reuses it, but only after significant time and negotiation.
With UDDI, the developer can search for the web service and reuse the existing technical component in their new application for the supplier in minutes. The developer saves time and gets the application running sooner, thereby increasing efficiency and saving the company time and money. The UDDI registry was the first version 2 standard-compliant UDDI registry for private enterprise work. The UDDI registry in this version has the following characteristics:
- It supports the UDDI Version 3.0 specification, in addition to the Version 1.0 and v2.0 standard APIs.
- It leverages the proven, reliable WAS technology.
- It uses a relational database, such as DB2, for its persistent store.
What is new in UDDI Version 3
The main aspects of the UDDI Version 3 specification provided with this version of WAS are as follows:
- Improved recognition of the importance of private UDDI registries
- Private UDDI registries are registries installed, owned, managed, and controlled by a separate body such as a department within a company, a company, an industry consortium, or an e-marketplace.
- Publisher-assigned keys
- The publisher of a UDDI entity can specify its key, rather than the registry automatically assigning a unique key. This means that URI-based keys can be used, and it makes it easier to manage multiple registries.
- UDDI information model improvements
- The UDDI data structures are extended, which improves the ability of UDDI to represent businesses and services through metadata.
- Security enhancements
- Digital signatures provide additional security. Each of the main UDDI entities can be digitally signed, which improves the integrity and trustworthiness of UDDI data.
- Ownership transfer APIs
- These APIs support the transfer of the ownership of a UDDI entity from one publisher to another.
- UDDI policy
- We can set policy to define the behavior of a UDDI registry and therefore recognize the different environments in which a UDDI registry is used.
- HTTP GET support for UDDI entities
- Use HTTP GET to access XML representations of each of the UDDI data structures. This extends the HTTP GET service beyond the scope for discovery URLs in the UDDI v2 specification.
Additional UDDI registry capabilities
The Version 3 UDDI registry in this version of WAS provides the following capabilities that are additional to support for the UDDI Version 3 specification:
- v2 UDDI inquiry and publish SOAP API compatibility
- There is compatibility with the Version 1 and v2 SOAP Inquiry and Publish APIs.
- UDDI administrative console extension
- The WAS administrative console includes a section that administrators can use to manage UDDI-specific aspects of their WebSphere environment. This management includes the ability to set defaults for initialization of the UDDI node, such as its node ID, and to set the UDDI Version 3 policy values.
- UDDI registry administrative interface
- The Java Management Extensions (JMX) administrative interface enables administrators to manage UDDI-specific aspects of the WebSphere environment programmatically.
- Multidatabase support
- The UDDI data is stored in a registry database. The following database products supported by WAS are also supported for use as the persistence store for the UDDI registry. For specific details on supported levels, see Detailed system requirements page.
- Apache Derby
- DB2
- (iSeries) DB2 for IBM i
- DB2 for z/OS
- Microsoft SQL Server
- (iSeries) Oracle
- User-defined value set support
- Create our own categorization schemes or value sets. These are in addition to the standard schemes, such as North American Industry Classification System (NAICS), provided with the UDDI registry.
- UDDI utility tools
- You can use UDDI utility tools to import or export entities that use the UDDI v2 API.
- UDDI user interface
- The UDDI user console supports the UDDI Version 3 inquiry and publish APIs.
- UDDI Version 3 client
- The Java client for UDDI Version 3 handles the construction of raw SOAP requests for the client application. It is a JAX-RPC client and uses Version 3 data types, which are generated from the UDDI Version 3 Web Services Description Language (WSDL) and schema. These data types are serialized or deserialized to the XML, which constitutes the raw UDDI requests.
- UDDI v2 clients
- The following clients for UDDI v2 requests are provided:
- UDDI4J. A Java class library for issuing UDDI requests.
Deprecated feature: This client is provided in WAS v5 for both UDDI Version 1 requests (uddi4j.jar) and v2 requests (uddi4jv2.jar). These class libraries are still supported, as part of the com.ibm.uddi.jar file, but are deprecated in WAS v6.0.depfeat
- JAXR. The Java API for XML Registries (JAXR) is a Java client API for accessing UDDI and ebXML registries. WAS provides a JAXR provider for accessing the UDDI registry that conforms to the JAXR 1.0 specification.
- EJB. An EJB interface for issuing UDDI v2 requests.
Deprecated feature: The UDDI EJB interface is still supported, but is deprecated in WAS v6.0.depfeat
Subtopics