Publish and find UDDI tModels with JAXR and WSDL

Work with WSDL, JAXR, and UDDI

By Frank Sommers, JavaWorld.com, 09/20/02

Web services allow you to compile and maintain such lists automatically. That convenience comes with two requirements: First, cruise ship companies must agree to use a common Web service interface when publishing their destinations. Second, each company must implement that interface and register its implementation in Web service registries. With those requirements satisfied, you can consult Web service registries, discover all cruise destination service instances, invoke each service, and produce your cruise destinations master list.

The pattern of finding all implementations of a Web service interface and possibly invoking those service instances proves useful in other contexts as well. Portal Websites still rely on manual—or semi-manual—compilation of news articles, automobile inventories, available hotel rooms, or airline seats. Even when data exchanges electronically, that automation often comes at the expense of lengthy and pricey system integration. Among the biggest motivations for building Web services is the desire to automate those tedious information-gathering tasks. This article provides a working example of how UDDI (Universal Description, Discovery, and Integration) registries, the Java API for XML Registries (JAXR), and the Web Services Description Language (WSDL) work together to initiate that automation.

Reuse your WSDL

Currently, several industry groups are working to define Web service interface standards. Examples are the Open Travel Alliance for travel, the Star Consortium for automotive retail, and RosettaNet for supply chain management. Many of those groups employ a community-oriented process and make their specifications available to anyone for comments.

Real-world interface specifications aim to be comprehensive and are rather complex. Thus, to make this article easy to follow, I use a simple interface definition for the example cruise ship destination Web service. That interface features only a single method. When invoked, that method produces a list of destinations a cruise company serves. Here is that interface in Java:

   
public interface CruiseService {
    public String[] cruiseDestinations(); 
}

Because Web services aim to remain programming language-neutral, we must convert this interface definition to a format not tied to Java. WSDL defines a document structure suitable for describing Web service interfaces with XML data elements. My previous Web Services column demonstrated how development tools, such as open source Apache Axis, convert a Java interface to a WSDL document.

As apparent from Web service-related discussion lists, many developers debate the better practice: first define your Web service's interface with code—for instance, Java code—then convert that code to WSDL definitions, or create the WSDL documents first, then convert those documents to Java code. Finding the right method might have more to do with personal predilection than hard and fast rules. I prefer to define a service's interface in Java (or some other language) first, because I find that a programming language-based definition produces a clearer, simpler picture of a service's capabilities. WSDL-first advocates have a point too: converting Java interfaces to XML structures is not an exact science and can introduce subtleties leading to surprising results.