Recently I had to integrate the Apache Tomcat Servlet/JSP engine with WebSphere 4.0 Advanced Edition Single Server (AEs) to enable a self service application. Read More... all the details.
The application called for servlets and JSPs (running on many remote nodes)
making EJB calls to a central EJB server. The remote nodes were already
running Tomcat so the servlet/JSP portion of the app slid nicely into the
Tomcat webapp container. A robust EJB container was required so of course
WebSphere got the nod. The environment looked like this:
Web Nodes (servlets/JSPs):
-
Windows 2000
-
Apache 1.3.19 HTTP Server
- Apache Tomcat 3.2.3
-
IBM 1.3 JDK (build cn130-20010502w)
EJB Node:
-
Windows 2000
-
WebSphere Application Server AEs 4.0
-
IBM 1.3 JDK (build cn130-20010502w)
The environment setup was straight forward. The products were installed
as per the install guides. However in order for the servlets running in
the Tomcat Web container to make successful EJB calls to a WAS 4.0 node,
a number of WAS jar files were required in Tomcat. The following jars were
copied from the WAS EJB node (from [was_appserv_dir]/lib) to each
Tomcat node:
These jars need to be made available to the Tomcat environment. In order
to accomplish this without modifying the startup scripts that come with
Tomcat, I created a wrapper bat that added these jars to the classpath before calling the real Tomcat startup bat.
Now that we have the environment setup let's take a look at what was required
to install the app.
Both Tomcat and WAS are J2EE compliant so they require the app be packaged
in a J2EE format. This means an .ear file containing the EJBs (EJB module)
for WAS, a .war file (Web module) containing the servlets/JSPs for Tomcat
and the appropriate XML deployment descriptors in both files.
Creating the .ear and it's required deployment descriptors was straight
forward using WAS' gui Application Assembly Tool (AAT). After the .ear file was created it was deployed into the EJB container
using WAS' web admin interface (command line seinstall tool could
also be used).
With the EJBs now deployed to the WAS node we could move on to the install
of the servlet/JSP portion of the app. Tomcat will accept a
J2EE compliant .war file using a neat little feature which I've dubbed "auto
deploy" (...I can't find the official name for this in the Tomcat
doc). This feature allows for a .war to simple be dropped into Tomcat's
webapp directory. Tomcat will then "auto deploy" the application
into the web container at startup. The appropriate directory structure
for the app will automatically be created on the filesystem... cool !
The only step left was to create the .war file with the servlets/JSPs.
Tomcat does come with ANT and a well documented process for building your
application .war file and deployment descriptors. However I took a different
path. I decided to use WAS' AAT to create the .war file for Tomcat.
(oh the beauty of standards!). The .war files created by AAT are J2EE compliant
and can simply be dropped as is into Tomcat's webapp dir. The app will
automatically be deployed during the startup of Tomcat... double cool !
The app was packaged into it's .war format by AAT and deployed into Tomcat.
I find myself using AAT a lot, not only to view/build .ear and .war files
for WAS but to also view or tweak archives for other J2EE appservers. In
fact I use AAT for a number of things beyond it's primary purpose:
- to view J2EE applications after they have been deployed (even if no .war
or .ear exist)
- recreate the .war or .ear file from a deployed J2EE app
- modify a deployed J2EE app without needing the .ear or .war file and without
redeploying again (...ok maybe this isn't a good idea - but it works)
At this point we have our environment setup properly, EJBs deployed to
the WAS node and the servlet/JSPs deployed to Tomcat. The app is now ready
to take on users.
