You might have noticed that there wasn’t much Java in this chapter. Most Java web service frameworks do a very good job of hiding the details of WSDL from the web service clients that they provide. You’re not likely to write a WSDL file yourelf; you’re more likely to read a WSDL file to understand and debug an interoperability problem.

Conceptually, a Java toolkit can work with an existing WSDL file in two ways. First, given a WSDL file, Java code could be generated that is capable of accessing the web service defined within the WSDL file. This type of code seems convenient, but it would contain classes and interfaces specific to the WSDL file. A client that used these classes would have to be recompiled or even rewritten each time the WSDL file was modified and the Java code was regenerated. The advantage of using a system like this is that it would provide Java objects for each WSDL type, message, and operation. Compile-time checking would provide a more reliable application.

The JAX-RPC specification, which is part of the Java Web Services Pack available from http://java.sun.com, allows both models. A tool that is compliant with JAX-RPC may generate statically defined stub interfaces, or it may generate a more generic stub that uses a dynamic invocation interface (DII) based on Java reflection to build a request object. JAX-RPC is discussed in more depth in Chapter 7.

Second, a Java web service invocation mechanism can import a WSDL file and then make an invocation on an operation dynamically. The advantage of this model is that the client code would not have to be recompiled each time the WSDL is modified, nor would Java code have to be generated each time the WSDL file is modified. The drawback to this approach is that no compile-time checking of data is used. The toolkit would formulate messages dynamically at runtime, so any typing problems that might arise could be more difficult to track down.

IBM’s Web Service Invocation Framework (WSIF) and Systinet WASP use this model. The WSIF is a toolkit (http://www.alphaworks.ibm.com/tech/wsif ) that provides a simple API for invoking web services, no matter how or where the services are provided. The WSIF’s API is driven by the abstract service description in WSDL. It is completely divorced from the actual Java client stub/proxy used. This invocation API is WSDL-oriented because it uses WSDL terms to refer to message parts, operations, etc.

Systinet WASP provides dynamic access to any service described by WSDL. It creates a dynamic Java proxy based on the WSDL description. WASP can also dynamically access any J2EE resource, such as a JMS Destination, JDBC driver, EJB, or J2EE CA adapter by creating a dynamic proxy.

The binding of Java to WSDL is discussed in more depth in upcoming chapters. Chapter 6, which discusses UDDI, has a section that talks about how WSDL documents should be placed within a UDDI registry. The next chapters also discuss JAX-RPC and how it absorbs WSDL documents to facilitate the invocation of web services in a standardized way.