Publishing and Finding Web Services Using UDDI

The following sections provide information about publishing and finding Web services using UDDI:

• Introduction to UDDI

• WebLogic Server UDDI Features

• Invoking the UDDI Directory Explorer

• Using the UDDI Client API

 

---

Introduction to UDDI

UDDI stands for Universal Description, Discovery and Integration. The UDDI Project is an industry initiative that is working 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.

The UDDI registry can be broadly divided into two categories:

• UDDI and Web Services

• UDDI and Business Registry

For details about the UDDI data structure, see UDDI Data Structure.

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 this 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:

1. To seek an implementation of a known interface.

   In other words, the client has a tModel ID and seeks binding templates referencing that tModel.

2. To seek the updated value of the invocation point (i.e., 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 has the potential of fueling growth of 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 may contain the following:

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

• Categories—Standard categorization information (for example a D-U-N-S business category number).

• 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 is comprised 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 14-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. Information provided here gives client applications the technical information needed to bind and interact with the target Web Service. Contains access point (i.e., 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

Weblogic Server provides the following UDDI features:

• A UDDI Directory Explorer

• A UDDI registry

• An implementation of the client-side UDDI API so you can programmatically search for and publish Web services

The UDDI Directory Explorer allows authorized users to publish Web services in private WebLogic Server UDDI registries and to modify information for previously published Web services.

The UDDI Directory Explorer also enables you to search both public and private UDDI registries for Web services and information about the companies and departments that provide these Web services. The Directory Explorer also provides access to details about the Web services and associated WSDL files (if available.)

 

---

Invoking the UDDI Directory Explorer

To invoke the UDDI Directory Explorer in your browser, enter the following URL:

http://host:port/uddiexplorer

where

• host refers to the computer on which WebLogic Server is running.

• port refers to the port number where WebLogic Server is listening for connection requests. The default port number is 7001.

You can perform the following tasks with the UDDI Directory Explorer:

• Search public registries

• Search private registries

• Publish to a private registry

• Modify private registry details

• Setup UDDI directory explorer

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

 

---

Using the UDDI Client API

Use the UDDI client API in a Java client application to 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:

• weblogic.uddi.client.service

• weblogic.uddi.client.structures.datatypes

• weblogic.uddi.client.structures.exception

• weblogic.uddi.client.structures.request

• weblogic.uddi.client.structures.response

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

For examples of using the UDDI client API, go to the Web Services dev2dev Download Page and scroll down until you find the following examples:

• UDDI Client API Example

• UDDI Publish Example

• UDDI Inquire Example