What do you think of when you see the acronym PITA? It shouldn’t be difficult for most computer professionals to figure out what it stands for, since acronym mastery is a basic computer skill (hint: P stands for Pain). What I’m asking is what task comes to your mind when you see it? Those of you who are relatively new to IBM hardware and software might be thinking what a PITA it is to RTFM (Read the Fine Manual) for your IBM system. The IT managerial types reading this article might be thinking what a PITA it is to keep up with IBM’s announcement letters and hardware name changes. I’m thinking about what a PITA the current deployment strategy of servlets is for my AS/400. Fortunately, the solution to my problem has been addressed in the Java Servlet Specification Version 2.2. It is commonly called a WAR file. In this, article I’ll discuss Web ARchive (WAR) files, what they are, where they’re used, and why it’s such a PITA that IBM doesn’t yet have them implemented in its AS/400 WebSphere product.

Following Orders

How would you distribute a native AS/400 application that you’ve developed? The simplest approach would be to ensure that all elements of your application appear in a single library. You also would place into that library an installation routine that would need to do little more than copy the command for accessing your application into one of the commonly accessible libraries, such as QUSRSYS. Let’s call this command STRMYAPP. The installer could then prompt for security information and issue the appropriate commands to create authority lists and grant authorities. Provided that you used the Product library (PRDLIB) parameter when you created STRMYAPP, your application is encapsulated so that a simple command gets it rolling. A quick Save Library (SAVLIB) command bundles up your application into a single save file that can be distributed in many ways, including via email. The administrator of your target AS/400 need only restore your library, run your installation script, and use your application. Easy!

Large shops typically have a development AS/400 separate from the production machine. Smaller shops typically have to make do with developing their applications on the production machine; this is doable with the judicious use of STRDBG and libraries created as TYPE(*TEST). What makes the application distribution scenario relatively painless (operating-system release-level issues aside) is that the application is going to be deployed

on the same kind of system on which it was developed. Contrast this with the scenarios you’ll find in Java development and you’ll find that things get much more complicated.

I personally use Linux, with Apache and Tomcat, on all of the systems I use for Java development. Other programmers may develop on other UNIX variants. The truly masochistic perform Java development on an AS/400. Some even use Windows. Once development is complete, the trick is to figure out how to move the application to the AS/400.

Frustration Breeds Contempt

To start with, you can have quite a number of different objects in your application. The short list includes the class files for your servlet and perhaps some static data, such as HTML pages or image files. How do you package and move all of this into IBM’s WebSphere product? Those of you who have bought into the full IBM product line, including VisualAge for Java Enterprise Edition, can put your hands down. I’m addressing those people who work in shops where the requirements (or pocketbook) are more modest than places where “the works” are available or justifiable. I fall into the former category.

I took my first trip down Headache Lane when I tried to deploy a simple application on my company’s 9406-500. This machine just wasn’t up to the task of running WebSphere—but I wanted to try it anyway. So, I plowed through the process using the Java JAR tool to “jar up” my application. I moved the result to an appropriate place on the AS/400 Integrated File System (AS/400 IFS) and “unjarred” the file back into the component parts. Next, I used the Web-based WebSphere configuration tool to put it into production. When I was done, everything seemed to work—but at a Florida ballot- counting pace. And, naturally, I remembered to document everything I did and every setting I used so that, if I had to reinstall this application or install it elsewhere, I’d have a reference.

To be fair, I’m not a WebSphere expert, nor do I play one on TV. I’m sure that, with the appropriate resources available in hardware and expertise, the entire process can be quite painless and rewarding. But as I mentioned, I’m hard-pressed to justify the purchase of the tools because our requirements are modest. Although the IBM tools are available for Linux, I resist using them simply because my tried-and-true ThinkPad laptop, which is based on a 233 MHz Pentium CPU, is sufficient to run open-source Web servers and servlet containers. I think the WebSphere experience on it would remind me too much of my 9406-500, and I’m certainly not going to replace a laptop computer just so that I can run WebSphere.

If you do use the WebSphere product, you’ll find that you have quite a bit of flexibility in your placement of your application. Flexibility, in this instance, is a double- edged sword. When I deployed my first application on WebSphere, I ran into so many configuration options that it became difficult to discern the ones required to make the application work from the options that are reserved for those brave souls who disassemble products clearly marked with tags stating “No user-serviceable parts inside.” What I’d really like is the same kind of simplicity of deployment that I currently enjoy with the AS/400 applications that I write. What I want is a save file for Java servlets.

Diplomatic Solutions

If you are developing servlets, or are considering doing so, then you’ll want to get a copy of the current Java Servlet Specification, Version 2.2, which you can find at http://java.sun.com/products/servlet. Since Java is a work-in-progress, each successive release of the specification has brought improvements over its predecessor. A major improvement in Version 2.2 over Version 2.1 (the specification on which WebSphere is based) is the concept of a Web Application. Section 9 in the specification describes this concept. Since many of you will be reading this magazine in a library that does not offer Internet service, I’ll give a brief description of its contents.

Essentially, you build your application as a structured hierarchy of directories. I place all of my Java projects into one directory on my laptop. Every project I have can be found in /home/klinebl/java. I do this to make backup easier. Assume that I’m going to create an application creatively called MyApp. To start it, I’ll create the directory /home/ klinebl/java/MyApp. Everything related to MyApp will appear here.

If I have a welcome page, it may be stored as /home/klinebl/java/MyApp/welcome.htm. Since I like things well-structured, I may place images into a subdirectory of .../MyApp, say .../MyApp/images/. Perhaps I have some audio clips, too. These go into .../MyApp/audio. You get the point. You’re free to build the directory structure to your liking—with one exception. The Servlet API Version 2.2 specifications require that you create a directory under the root called WEB-INF. For the mythical MyApp application, it means that you will create the directory .../MyApp/WEBINF. Under this one, you’ll be adding three things.

The first thing is a file titled web.xml, an XML file that is the deployment descriptor for the application. Figure 1 (page 65) shows an example of the simplest of all web.xml files. It describes an application called MyApp where the class file for the application is called MyApp. This file can get quite lengthy (as with any XML-formatted file) and can include directives for mapping Uniform Resource Identifiers (URI) to servlets, security, and context parameters. In short, all of those horrible settings that I had to manually configure with WebSphere are put into this file and parsed by the container on startup. This means that all of the meticulous documentation I did before (and subsequently misplaced) is now embedded within the application itself. So it goes where the application goes.

The second item in the WEB-INF directory is a subdirectory called lib. Into this subdirectory go all of the supporting classes and JAR files that your application needs to run. A nice feature of lib is that you do not have to change your classpath in any way to accommodate this location. The servlet container will look here automatically when attempting to load a class that your servlet requires.

The third and final item in WEB-INF is another subdirectory known as classes. It is from this directory that the Web-application class loader will load classes. Figure 2 (page
65) shows the directory structure of MyApp, with MyApp.class showing up in the classes subdirectory. Obviously, the use of Java packages would add additional subdirectories to classes, but I wanted to keep this description simple.

Going to WAR

Now that everything is in place, what’s with the WAR file? Every Java programmer is familiar with JAR files. It’s the Java version of an AS/400 save file. Or, if you prefer, it’s a Java version of a PC Zip file. Change the extension of the file from jar to war and you have a WAR file. Once MyApp is complete, the only thing you have to do to deploy it is use the JAR utility to package up the contents of the MyApp directory. Assuming that your Java source code is stored elsewhere, you’d simply change directory to the application directory, in this case /home/klinebl/ java/MyApp and issue the command jar -cvf MyApp.war *. The resulting Web application archive file is ready for distribution.

Deployment is even easier. In the case of a default Tomcat installation (see “Tomcat for the OS/400: An Open Source Web Application Server,” Don Denoncourt, MC, December 2000), you’d copy MyApp.war into $TOMCAT_HOME/webapps and (re)start the Tomcat application server. When it starts, it will detect the existence of the file, expand (unjar) it, and create the necessary context to run the servlet. Once done, pointing the browser to http:/YourWebServer/ MyApp/servlet/MyApp will give you access to the servlet. After my WebSphere experience, it’s darned near magic! I now have my save file for Java.

Peace at Last

At the moment, I currently use Tomcat on my AS/400 for an application server. Even though my AS/400 has enough horsepower to run WebSphere now (the 500 got replaced with an 820) I still haven’t moved applications to it. Why? Because the ease of servlet development and deployment I now enjoy with Linux, a tool called ant (which will be covered in a subsequent issue), and the Web application archive are just too nice to give up. I’d rather fight than switch!

IBM has committed to making WebSphere Java Servlet Specification Version 2.2 compliant in WAS 4.0 sometime this year. When that happens, I may just load it onto my AS/400 and use it instead. Until then, I’m going to stick with what works and ensure my domestic tranquility.

“http://java.sun.com/j2ee/dtds/web-app_2_2.dtd”>

MyApp

MyApp

Figure 1: This figure shows “The Minimalist’s Deployment Descriptor,” which is sufficient information for the container to run your servlet.

Directory of /home/klinebl/java:

MyApp/
MyApp/index.html
MyApp/images/
MyApp/images/graphic1.jpg
MyApp/audio/
MyApp/audio/thankyou.wav
MyApp/WEB-INF/web.xml
MyApp/WEB-INF/lib/
MyApp/WEB-INF/lib/mybean.jar
MyApp/WEB-INF/classes/
MyApp/WEB-INF/classes/MyApp.class

Figure 2: The Web Application directory structure spelled out in JSS Version 2.2 is simple and clear. This sample shows the directory structure for a servlet titled MyApp.