Professional Documents
Culture Documents
By Dion Almaer
Web services have been a buzzword for a while. A friend used to say "Web services are
like high school sex. Everyone is talking about doing it, but hardly anyone is, and those
that are probably aren't doing it well." These days, though, Web services are moving to
college, so to speak, and lots of people are starting to "do it" more often and better than
before. Tools are maturing, and creating and working with Web services isn't all that hard
anymore.
IBM has given a lot of code to the Apache group, including SOAP4J, their group of
SOAP tools. The Apache SOAP and SOAP4J guys got together and are working on the
latest and greatest tool set called Apache AXIS, which features not only better
performance, but also some new features that make it trivial to play in this new world. I
see the most common actions being "I want to expose this functionality as a Web
service," and "I want to access that Web service." Surely it should be very straight-
forward to strap on this interface, and you shouldn't have to learn everything there is to
know about the underlying platform. This is the same idea as not having to know about
the IP and TCP layer when accessing a URL over HTTP. Let's keep it simple, folks.
• First, I will show the "easy to deploy" feature that lets you drop a source file into
the AXIS Web application and have it become a Web service -- just like that!
• Then we will use the new WSDL2Java and Java2WSDL tools to see how we can
quickly get a WSDL descriptor and access the associated Web service, and then
how to easily expose some Java code.
NOTE: I assume that you have basic knowledge of Web services. If you
need to look up what a WSDL file is, checkout the Web services section
of ONJava.com.
The Apache guys realized that it would be really nice to be able to drop some code
somewhere and have it become a Web service "just like that." This simplicity is a current
trend; Microsoft has it in .NET, and BEA in the WebLogic 7 platform. But just how easy
is it to:
• Deploy a piece of code?
• Write a client that accesses the Web service?
• Obtain the WSDL for the deployed Web service?
% cp samples\usersguide\example2\Calculator.java
%TOMCAT_HOME%\webapps\axis\Calculator.jws
Just by having the code (with the .jws extension) in the Web application deploys it and
allows us to access it. If we open a browser and access the file (e.g.
http://localhost:8080/axis/Calculator.jws) we will be told that we are talking to
a Web service. How easy was that?! A simple copy command and we are done.
Now we have a deployed Web service; we need to access it. Let's look at a client that
allows us to pass in a math operation (add or subtract) and the two amounts to work with.
package samples.userguide.example2;
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType;
import org.apache.axis.utils.Options;
import javax.xml.rpc.ParameterMode;
The code first imports all of the required classes. Then we set the URL of the Web
service that we want to invoke. Skip past the argument checking, and we get to the meat:
we configure the method that we want to call, the parameters to pass, and then invoke the
service itself. So, we have deployed and accessed the Web service by writing a minimal
amount of code.
1. We have a piece of code that calculates the Fibonacci sequence for a given
iteration.
2. We want to take the existing code, wrap it up as a Web service, and then deploy it
to the Apache Axis system.
3. Once we have a running service on the server side, we will create Java stubs that
allow us to communicate with the service, only requiring the WSDL.
After going through this full process, you will be able to create clients to any Web
services (when given the WSDL), and wrap up any code, exposing it as a Web service.
Example 1. Fibonacci.java
package fibonacci;
Then we have the real implementation of that code. Don't spend time studying how the
Fibonacci sequence is calculated, though; that isn't the point.
Example 2. FibonacciImpl.java
package fibonacci;
previous1 = fib;
return fib;
}
Now we have the Fibonacci code, and we compile it (javac). Here comes the first tool
that helps us out as we endeavor to make that code a Web service. The Java2WSDL
command line will generate a standard WSDL file that conforms to a given interface. We
tell the program the information it needs to know as it builds the file, such as:
After the program runs, we see that a new file, fib.wsdl, was created for us. If we look
inside the file, we see 114 lines of information that needed to be created for this Web
service. Aren't you glad that you didn't need to write the whole thing? How do people
write them by hand?
3. WSDL2Java: Generate the Server-side Wrapper Code and Stubs For Easy Client
Access
Our next step is to take this WSDL and generate all of the glue code for deploying the
service, as well as stubs for accessing it. The WSDL2Java tool comes to our aid here to
take that chore out of our hands.
Let's generate this code into the fibonacci.ws package, to keep it separate from the
original code. Once again, we need to tell this command line some information so it can
go ahead and do its work:
After running this program, a slew of code has been generated for us in the
fibonacci\ws directory:
We need to tweak one of the output source files to tie the Web service to
FibonacciImpl.java. FibonacciSoapBindingImpl.java is waiting for us to add the
stuff into the methods that it created. The lines that we added are in bold:
package fibonacci.ws;
import fibonacci.FibonacciImpl;
}
We are simply tying in to the existing class. We could have hard-coded the methods in
this class, but in the real world, we probably want to wrap logic as Web services, and not
just enable access via that interface.
Next, we package all of the code that we have and copy it into Axis' classpath:
% mv fib.jar %TOMCAT_HOME%/webapps/axis/WEB-INF/lib
Deploy the Web Service using the WSDD Deployment Descriptor:
Apache Axis has an Admin client command line tool that we can use to do tasks
such as (un)deployment, and listing the current deployments. We pass the
deployment descriptor to this program so it can do its work:
Now our Fibonacci Web service is alive and running in the server!
6. Client: Write a Client That Uses the Generated Stubs to Easily Access the Web
Service
We should check to see if it is working, right? Let's write a simple client that uses the
generated client code from the WSDL2Java step, to calculate the Fibonacci number at the
10th step.
All we need to do in the code is to get access to the service via the ServiceLocator, and
then call methods on the remote handle that we have to the service. It looks just like
normal Java; none of that silly SOAP or RPC code is in sight. Isn't that nicer? (Take
another look at the CalcClient that we used at the beginning, and compare it to this
code.)
package fibonacci;