Java Web Services

Where Is All the Java?

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 ...