More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com

UDDI4J lets Java do the walking

Access any UDDI registry from within Java using the UDDI4J API

By André Tost, JavaWorld.com, 08/24/01

Web services technology allows the communication between applications across the Internet over standard, XML-based protocols. The Simple Object Access Protocol (SOAP) invokes a Web service, which can be located anywhere on the Internet and written in any programming language. A Web service's interface is described using the Web Services Definition Language (WSDL). Public registries exist where a service provider can publish services and service requestors can find them. Such registries follow the Universal Description, Discovery, and Integration (UDDI) standard.

The standard defines an XML-based API with which clients access the registry. The open source UDDI4J project defines a Java API that provides access to any UDDI registry from within a Java application. UDDI4J lets you publish and find information in a UDDI registry by wrapping all the XML artifacts used by UDDI. It also handles the network access to a registry via the SOAP protocol, making it easy to integrate UDDI access into any new or existing Java application.

In this article, I introduce UDDI in general, then move on to the UDDI4J API, including some programming examples demonstrating its use. I will not cover the Web services architecture in any detail, nor will I explain the SOAP or WSDL specifications. Please see Resources for links to further articles and tutorials on these topics.

UDDI

UDDI defines a set of registries that contain information about businesses and the services they offer. Moreover, it defines a set of specifications: one specification for an XML schema that defines the structure of the contained data, one specification for a common API to access this data, and one API for the replication of data between different registries. A community of over 220 companies now back UDDI, each working together to define and support the comprising specifications.

Currently, two production UDDI registries exist: one hosted by IBM and one by Microsoft. Hewlett-Packard's registry should launch later this summer. (See Resources for links to all three registeries.) Since they replicate information between each other, any one provides all available information.

UDDI data structure

A UDDI registry contains data in a combination of white pages, yellow pages, and green pages. The white pages information includes items such as a business's name, its address, and other contact information. The yellow pages help categorize a business; they define its business type, as well as the industry in which it operates. Lastly, the green pages define what kinds of services a business offers, and how to electronically communicate with these services.

All UDDI registry data is formatted in XML. As such, the data structure specification defines the XML schemas all entries must follow. Some of the more generic defined elements can exist at various places of the registry:

  • TModel: A generic information container that typically points to a technical specification, thus making it possible to use TModels as technical fingerprints to identify certain services. Each TModel possesses a unique key. A number of entries in the UDDI registry use TModel, but most notably they are contained in a binding template, described below.
  • Identifier Bag: A number of named key-value pairs. Many of the elements in a UDDI registry can contain identifiers to help classify the given information. On top of that, each identifier includes a reference to a TModel, which indicates the key type contained in the identifier.
  • Category Bag: Contains a number of categories that resemble identifiers but have predefined taxonomies. For example, you'll find a category for industry codes as defined by the North American Industry Classification System (NAICS).


These elements help find businesses based on their industry classification, or based on certain technical specifications (TModels, for example) they support.

The other elements defined in the UDDI specification describe the actual businesses and their offered services:

  • Business Entity: Contains general information about a business, such as its contact information and business type categorization data. The entry also contains a number of business service entries.
  • Business Service: Represents the service a business offers. It contains a description, as well as an access-point element that defines where the service is located. Each business service entry contains a number of binding templates.
  • Binding Templates: Contains a reference to one or more TModels, which helps classifying the offered service.


Figure 1 shows the elements contained in a UDDI registry and their relationships. Please note the missing entry: the publisherAssertion, an element added to UDDI version 2.0, which no production registry yet supports. publisherAssertion helps define relationships between different business entity entries. As it's not supported, we will not look at it in any detail.

Figure 1. A UDDI registry



The UDDI API

The UDDI API specification defines itself as a collection of XML requests and their responses -- making the API completely programming-language neutral. There are two types of APIs: find methods and publish methods. Obviously, the find methods find certain entries in the registry; they do not make any updates.

You can call finder methods to retrieve any kind of entry contained in the registry. Finders exist for business entities, business services, or even individual TModels. The criteria passed with a find method can be a specific key -- to find all the services offered by a particular business, for example. Or it can be category or TModel information, for example to find all businesses that offer services associated with a particular specification identified by its TModel.

With the publish methods, you create new entries, change existing entries, and delete entries. Again, you can change business entities, business service entries, and also to TModels. All publish APIs require userid/password credentials to be passed with every request.

These methods' parameters and return values reflect the defined UDDI data structures closely. Since the API, as defined, is a collection of XML messages, some of these messages simply contain the exact structure of the element they represent.

Resources