Java Reference
In-Depth Information
Verifying wsimport
To verify that you're running Java SE 6, which makes the
wsimport
tool available, open a
command terminal and run the following command, which should print a version number of
JAX-WS:
$ wsimport -version
JAX-WS RI 2.1.1 in JDK 6
As long as your version number is 2.0 or higher, you should be in business. If you don't have
wsimport
on your path, you won't get a version number, but rather an error indicating that
the OS couldn't find the program. In that case, you'll need to either add it to an environment
variable or invoke the program using the complete path.
Generating client code
Now you'll point to the WSDL and generate the portable client-side artifacts you can use to
construct a SOAP message that the service is expecting. By using JAX-WS to do this instead
of SAAJ, you avoid having to deal with XML directly.
Create a new directory on your filesystem to contain your program. Mine will be
~/weatherTest.
Now navigate to this directory in your terminal. Create a directory called genunder it. This is
where you'll tell
wsimport
to put the generated classes based on the WSDL.
NOTE
This web service is written in .NET, which presents a good opportunity to test the promise of web
services. But its WSDL is written in a non-standard manner, using HTTP POST and GET operations,
without specifying SOAP bindings. So you will likely see some warnings when you run
wsimport
.
For this web service, the WSDL is located at
http://www.webservicex.net/WeatherFore-
cast.asmx?wsdl
.
Here is the command to generate the client objects:
wsimport -verbose -d gen -extension
-keep http://www.webservicex.net/WeatherForecast.asmx?wsdl
Using the
-keep
option retains the Java source files so that you can examine how the objects
are put together to make a request. The
-d
option allows you to specify the directory where
JAX-WS should put the generated files. Running this command should create about a dozen
Java files that correspond to the types defined in the schema.
