WORKING WITH WEB SERVICES in Java

Printer ECC200 in Java WORKING WITH WEB SERVICES

* This file was auto-generated from WSDL * by the Apache Axis Wsdl2java emitter. */ package soapapi; public interface StockQuoteService extends java.rmi.Remote { public float getQuote(java.lang.String symbol) throws java.rmi.RemoteException, soapapi.Exception; }

The program also creates a proxy class that implements this interface and redirects it to a remote endpoint, and a locator class that finds the endpoint at run time and binds to it. 15.2.3 Using the SOAP proxy classes To use these generated classes, simply create a Java file that imports and invokes them:

import soapapi.*; public class SoapClient { public static void main(String args[]) throws java.lang.Exception { StockQuoteServiceServiceLocator locator; locator=new StockQuoteServiceServiceLocator(); StockQuoteService service; service= locator.getStockQuoteService(); for(int i=0;i<args.length;i++) { float quotation=service.getQuote(args[i]); System.out.println(args[i]+"="+quotation); } } }

This service first creates a locator instance to locate the endpoint. In this example, it always returns the same endpoint, but it is conceivable that a locator could use a Universal Description, Discovery, and Integration (UDDI) registry or other directory service to locate a service implementation dynamically. After creating the locator we bind to the service by asking the locator for a binding; it returns an implementation of the remote interface the stub class that WSDL2Java created. With this binding, we can make remote calls, here asking for the stock price of every argument supplied to the main method, that being the classic simple web service. 15.2.4 Compiling the SOAP client Before we can run that method, we have to compile the source:

<target name="compile" depends="import-wsdl"> <javac srcdir="src;${generated.dir}" destdir="${build.classes.dir}"

classpathref="axis.classpath" debuglevel="lines,vars,source" debug="true" includeAntRuntime="false" /> </target>

We supply a path to the source directory to include both our source and the generated files. One irritation of the current SOAP import process is that the Java files are always regenerated, which means they always need recompilation. This makes the build longer than it need be. Unless WSDL2Java adds dependency checking, you should use something similar to <uptodate> to bypass the import-wsdl target when it is not needed. There is an extra complication here; you need to use a <filesmatch> test inside a <condition> to verify that the file you just fetched with <get> hasn t changed. We omit all this because it is so complex. 15.2.5 Running the SOAP service With compilation complete, there is one more target to write:

<target name="run" depends="compile" unless="offline"> <java classname="SoapClient" fork="true" failonerror="true" > <arg value="SUNW"/> <arg value="MSFT"/> <classpath> <path refid="axis.classpath"/> <pathelement location="${build.classes.dir}"/> </classpath> </java> </target>

This target runs the stock quote client, fetching the stock price of Sun and Microsoft, producing a result that we cannot interpret as good news for either of them, at least during May 2002:

If we were ambitious, we could save the output of the run to a properties file, and then load the output as Ant properties and somehow act on them.1

Having applications output their results in the properties file format makes it very easy to integrate their results into Ant or, indeed, into any other Java application. We have used this trick for Win32/ Java communications. XML is more powerful, but harder to work with.

Reviewing SOAP client creation As we have shown, Ant can create a build file that goes from a remote WSDL description to Java code and then it can compile and run this code to make remote SOAP RPC calls. More SOAP services could provide extra functionality for the build, such as returning information from a remote database, information that could populate a file used in the build or one of the build s redistributables. Alternative implementations to the Apache Axis SOAP libraries have different processes for creating stub code from WSDL services. We have not looked at the process for using alternate implementations in any detail, but they should be amenable to a similar build process. If multiple Java SOAP implementations do become popular, we may eventually see Ant adding a task to import WSDL that supports different implementations, just as <javac> supports many Java compilers.