12.2. Setting Up
Now that you have some basic concepts
down, it's time to get going on the fun part, the code. You
need a project or product for use, which turns out to be simpler to
find than you might think. If you want a Java-based project providing
SOAP capability, you don't have to look that far. There are two
groups of products out there: commercial and free. As in most of the
rest of the book, I'm steering away from covering commercial
products. This isn't because they are bad (on the contrary,
some are wonderful); it's because I want every reader of this
book to be able to use every example. That calls for accessibility,
something commercial products don't provide; you have to pay to
use them, or download them and at some point the trial period runs
out.
That brings us to open source projects. In that realm, I see only one
available:
Apache SOAP. Located online at
http://xml.apache.org/soap, this
project seeks to provide a SOAP toolkit in Java. Currently in a
Version 2.2 release, you can download it from the Apache web site.
That's the version and project I use for the examples
throughout this chapter.
12.2.1. Other Options
Before moving on to the installation and setup of Apache SOAP, I will
answer a few questions that might be rattling around in your head.
It's probably clear why I'm not using a commercial
product. However, you may be thinking of a couple of other open
source or related options that you might want to use, and wondering
why I am not covering those.
12.2.1.2. Isn't Microsoft a player?
Yes. Without a doubt, Microsoft and its SOAP implementation, as well
as the whole .NET initiative (covered more in the next chapter), are
very important. In fact, I wanted to spend some time covering
Microsoft's SOAP
implementation in detail, but it only supports COM objects and the
like, without Java support. For this reason, coverage of it
doesn't belong in a book on Java and XML. However, Microsoft
(despite the connotations we developers tend to have about the
company) is doing important work in web services, and you'd be
making a mistake in writing it off, at least in this particular
regard. If you need to communicate with COM or Visual Basic
components, I highly recommend checking out the Microsoft SOAP
toolkit, found online at http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000523
along with a lot of other SOAP resources.
12.2.1.3. What's Axis?
Those of you who monitor activity in Apache may have heard of
Apache
Axis. Axis is the next-generation SOAP toolkit, also being developed
under the Apache XML umbrella. With SOAP (the specification, not a
specific implementation) undergoing fairly fast and radical change
these days, tracking it is difficult. Trying to build a version of
SOAP that meets current requirements and moves with new development
is also awfully tough. As a result, the current Apache SOAP offering
is somewhat limited in its construction. Rather than try to
rearchitect an existing toolkit, the Apache folks started fresh with
a new codebase and project; thus, Axis was born. Additionally, the
naming of SOAP was apparently going to change, from SOAP to XP and
then to XMLP. As a result, the name of this new SOAP project was
uncoupled from the specification name; thus, you have
"Axis." Of course, now it looks like the W3C is going
back to calling the specification SOAP (Version 1.2, or Version 2.0),
so things are even more confusing!
Think of IBM SOAP4J as
architecture 1 of the SOAP toolkit. Following that is Apache SOAP
(covered in this chapter), which is architecture 2. Finally, Axis
provides a next-generation architecture, architecture 3. This project
is driven by SAX, while Apache SOAP is based upon DOM. Additionally,
Axis provides a more user-friendly approach in header interaction,
something missing in Apache SOAP. With all of these improvements,
you're probably wondering why I'm not covering Axis.
It's simply too early. Axis is presently trying to get together
a 0.51 release. It's not a beta, or even an alpha, really;
it's very early on. While I'd love to cover all the new
Axis features, there's no way your boss is going to let you put
in a pre-alpha release of open source software in your
mission-critical systems, now is there? As a result, I've
chosen to focus on something you can use,
today: Apache SOAP. I'm sure when Axis
does finalize, I'll update this chapter in a subsequent
revision of the book. Until then, let's focus on a solution you
can use.
12.2.2. Installation
There
are two forms of installation with regard to SOAP. The first is
running a SOAP client, using the SOAP API to communicate with a
server that can receive SOAP messages. The second is running a SOAP
server, which can receive messages from a SOAP client. I cover
installation of both cases in this section.
12.2.2.1. The client
To
use SOAP on a client, you first need to download Apache SOAP,
available online at http://xml.apache.org/dist/soap. I've
downloaded Version 2.2, in the binary format (in the version-2.2 subdirectory). You should then
extract the contents of the archive into a directory on your machine;
my installation is in the javaxml2 directory (c:\javaxml2 on my Windows machine,
/javaxml2 on my Mac OS X
machine). The result is /javaxml2/soap-2_2. You'll also need to
download the JavaMail package, available from Sun at http://java.sun.com/products/javamail/. This
is for the SMTP transfer protocol support included in Apache SOAP.
Then, download the JavaBeans Activation Framework (JAF), also from
Sun, available online at http://java.sun.com/products/beans/glasgow/jaf.html.
I'm assuming that you still have Xerces or another XML parser
available for use.
NOTE:
Ensure your XML parser is JAXP-compatible and namespace-aware. Your parser, unless it's a very special case, probably meets both of these requirements. If you have problems, go back to using Xerces.
Use a recent version of Xerces; Version 1.4 or greater should
suffice. There are a number of issues with SOAP and Xerces 1.3(.1),
so I'd avoid that combination like the plague.
Expand both the JavaMail and JAF packages, and then add the included
jar files to your classpath, as
well as the soap.jar library.
Each of these jar files is either in the root
directory or in the lib/
directory of the relevant installation. At the end, your classpath
should look something like this:
$ echo $CLASSPATH
/javaxml2/soap-2_2/lib/soap.jar:/javaxml2/lib/xerces.jar:
/javaxml2/javamail-1.2/mail.jar:/javaxml2/jaf-1.0.1/activation.jar
On Windows, it should look like:
c:\>echo %CLASSPATH%
c:\javaxml2\soap-2_2\lib\soap.jar;c:\javaxml2\lib\xerces.jar;
c:\javaxml2\javamail-1.2\mail.jar;c:\javaxml2\jaf-1.0.1\activation.jar
Finally, add the javaxml2/soap-2_2/ directory to your
classpath if you want to run the SOAP examples. I cover setup for
specific examples in this chapter as I get to them.
12.2.2.2. The server
To build a SOAP-capable set of server components, you first need a
servlet engine. As in earlier chapters, I'll use Apache Tomcat
(available from http://jakarta.apache.org) throughout this
chapter for examples. You'll then need to add everything needed
on the client to the server's classpath. The easiest way to do
that is to drop soap.jar,
activation.jar, and mail.jar, as well as your parser, in your
servlet engine's library directory. On Tomcat, this is simply
the lib/ directory, which
contains libraries that should be autoloaded. If you want to support
scripting (which is not covered in this chapter, but is in the Apache
SOAP examples), you'll need to put bsf.jar (available online at http://oss.software.ibm.com/developerworks/projects/bsf) and js.jar
(available from http://www.mozilla.org/rhino/) in the same directory.
NOTE:
If you are using Xerces with Tomcat, you'll need to perform the same renaming trick I talked about in Chapter 10, "Web Publishing Frameworks". Rename parser.jar to z_parser.jarand jaxp.jar to z_jaxp.jar, to ensure that xerces.jar and the included version of JAXP are loaded prior to any other parser or JAXP implementation.
Now restart your servlet engine, and you're ready to write SOAP
server components.
12.2.2.3. The router servlet and admin client
In addition to basic operation, Apache
SOAP includes a router servlet as well as an admin client; even if
you don't want to use these, I recommend you install them so
you can test your SOAP installation. This process is
servlet-engine-specific, so I just cover the Tomcat installation
here. However, installation instructions for several other servlet
engines are available online at http://xml.apache.org/soap/docs/index.html.
Installation under Tomcat is simple; just take the
soap.war file in the soap-2_2/webapps directory, and drop it in
your $TOMCAT_HOME/webapps directory. That's it! To test
the installation, point your web browser to http://localhost:8080/soap/servlet/rpcrouter.
You should get a response like that shown in Figure 12-2.
Figure 12-2. The RPC router servlet
Although this looks like an error, it does indicate that things are
working correctly. You should get the same response pointing your
browser to the admin client, at http://localhost:8080/soap/servlet/messagerouter.
As a final test of both the server and client, ensure you have
followed all the setup instructions so far. Then execute the
following Java class as shown, supplying your servlet URL for the RPC
router servlet:
C:\>java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter list
Deployed Services:
You should get the empty list of services, as shown here. If you get
any other message, consult the long list of possible errors at
http://xml.apache.org/soap/docs/trouble/index.html.
A fairly complete list of problems that you can run into is there. If
you do get the empty list of services, then you're set up and
ready to continue with the examples in the rest of this
chapter.
 |  |  | 12. SOAP |  | 12.3. Getting Dirty |
Copyright © 2002 O'Reilly & Associates. All rights reserved.
|
|