In my first column, I gave you the chance to choose the topics you wanted me to write about. The votes have been pretty evenly split among the various choices. Only a few percentage points separate the contenders, and this month's column is on WebSphere vs. Tomcat. Remember, you can go back and change your vote now that these last couple of columns have run. There are only two choices left: the administration client, and the Apache HTTP server vs. the IBM classic HTTP server. Go to the MCPressOnline Polls to register your vote for this (and any other) poll.

Since this article compares WebSphere and Tomcat, the quote at the beginning of the column really applies, because comparisons can sometimes lead to misunderstandings. It's important to understand before even starting to read this article that, while WebSphere and Tomcat do essentially the same thing, in many ways they fit two very different niches. Which server is best for you depends very much upon your own personal needs, and I hope this article can help make your decision less stressful.

In this article, I'll review:

1. Tomcat vs. WebSphere, from 30,000 feet
2. The installation of Tomcat on the iSeries
3. The differences between Tomcat and WebSphere configuration
4. Some benchmarks of the PSC400 product on the two platforms

Tomcat vs. WebSphere

First, you should be very clear on how Tomcat is and is not like WebSphere, from a very high level.

Tomcat is like WebSphere because:

• It is a Web application server--that is, it runs servlets and JavaServer Pages (JSPs).
• It runs on many platforms, including the iSeries.

Tomcat is more like WebSphere Standard Edition than WebSphere Advanced Edition because:

• It has no Enterprise JavaBean (EJB) support and, in fact, no J2EE support at all.
• It is free.

Tomcat is not like WebSphere because:

• It is open source, rather than proprietary.
• It is 100% Pure Java.

That's why Tomcat is, at least for the time being, a reasonable substitute for WebSphere Standard Edition. And as long as there is no official word from IBM as to whether or not there will be a free version of WebSphere Application Server available for the iSeries, it would be smart for you to hedge your bets and get familiar with Tomcat.

Of course, forcing people to an open-source solution in order to run Web applications on the iSeries is a pretty bad marketing position for IBM. Think about it: once you get your applications working on Tomcat for the iSeries, it is absolutely zero work for you to port your application to any other platform. In fact, I've done just that. For this article, I decided to port my PSC400 legacy Web enabling software to Tomcat. It was quite successful, and now I've got a product that will run on Linux, NT, or Solaris just as easily as it will on the iSeries. That being the case, I've got to believe that it is in IBM's best interest to somehow rethink this whole WebSphere packaging strategy and come back around to the realization that a free version of WebSphere for the iSeries is simply good business.

To summarize from a high level: Tomcat and WebSphere are very similar, except that WebSphere Advanced Edition includes EJB support. This is not to say that Tomcat cannot be used with EJBs. In fact, another open-source project called JBOSS provides EJB support for Tomcat quite well.

Are EJBs for Me?

And do you really need EJBs? That's a good question. The answer, as usual, is that it depends. While servlets and JSPs are a technology, J2EE--and EJB in particular--comprise an architecture. Because of this, any application can take advantage of servlets and JSPs, but you can really only make good use of EJBs if your application fits within the J2EE architecture. It's very much like the difference between writing custom code and buying an off-the-shelf package. If your business fits the off-the-shelf package, great, but if it doesn't, you're going to have to write custom code. And while it's pretty easy to shoehorn a simple application like a storefront into the EJB architecture, companies are finding it just a little more difficult to redesign several decades worth of experience in, say, ERP systems, so that they fit nicely into the J2EE paradigm. It's a little bit like IBM's Common User Access concept of the early '90s (can you say CUA?). A nice idea, but in the real world very few companies could actually implement CUA completely.

To truly deal with the EJB issue would require an article all to itself. For the time being, suffice to say that servlets and JSPs do not require EJB support, and for those projects, Tomcat by itself is sufficient.

Installation and Configuration

So back to the issue at hand. First off, how do you install Tomcat on the iSeries? Well, as it turns out, that's the easiest part. By simply installing the latest cumulative PTFs and the group PTFs for WebSphere, you automatically get Tomcat as well. As I said, I consider this to be a really poor marketing move on IBM's part, but I try not to look a gift horse in the mouth. So, I ordered and installed the latest PTFs on my development machine (which incidentally is still running V4R5; Tomcat is fully supported that far back), and with no additional effort I was at the point of actually configuring a Tomcat server instance.

This is probably the single biggest difference between the two packages. While WebSphere requires the much-maligned WebSphere Administration Client (and a powerful PC to run it on), Tomcat configuration is done entirely through the browser. The sheer number of options for Tomcat configuration can make the browser interface seem a little intimidating, but the WebSphere adminclient is no picnic, either. More importantly, because there is no additional software to load on the workstation, I was able to immediately begin configuring the Tomcat software, and I could do it from any PC with a browser. Not only that, performing the browser-based configuration is much quicker and more responsive than performing the same functions with the WebSphere adminclient. Here, Tomcat clearly beats WebSphere.

As I said mentioned, my test was to try to configure Tomcat to run my PSC400 Web-enabling software. PSC400 uses two IBM products (the Java Toolbox for the AS/400 and the JLOG logging package) as well as its own package of over 100 classes. This additional software must be added to the "Web application" in order to allow the PSC400 servlets to function properly. Also, PSC400 uses a number of JSPs and include files, and these must be configured as well. While the interface is different for the two products, the amount of work is about the same. The Tomcat configuration is perhaps a little easier, but I had the benefit of experience gained doing the initial setup with WebSphere. In any event, configuration of a Tomcat Web application able to run PSC400 took about 30 minutes.

One minor gripe is that, in my opinion, the placement of components in Tomcat is a little less flexible than with WebSphere. Tomcat has its own way of doing things, especially where to put servlets, and I don't necessarily like all of them. But the flip side of this is that anybody with prior Tomcat experience is likely to be able to look at my configuration and quickly figure out what the various components do, simply by looking at my directory structure.

Performance Benchmarks

Let me tell you what happened when I put the critter to a test. In my shop, I use a package called Web Roller from Novosoft, an absolutely outstanding Web application stress tester from a company out of Novosibirsk, Russia. Web Roller not only allows you to capture and playback HTTP sessions, but also has a very powerful scripting language that allows you to parse out the HTTP outbound data and use it to return data back to the application. This is crucial for PSC400, since it uses a special request key to keep the session synchronized. Once you've created a test script, Web Roller allows you to run dozens or even hundreds of sessions (limited basically by the resources of your workstation).

I created a basic script that goes through several of my more-involved test programs, fired off a bunch of clients, and recorded the average response times of WebSphere and Tomcat. Nothing particularly scientific in my approach, but since both my workstation and my iSeries are dedicated machines, I think the results are probably pretty indicative of the general performance of the two products.

Startup Time

WebSphere's startup time is considerably longer than Tomcat's. For one thing, there are more pieces that need to be started. Not only the HTTP server must be started, but also the QEJB subsystem. On my 370CPW Model 270, it takes several minutes to start QEJB. Once QEJB is started, it takes another 30-45 seconds to load adminclient on my workstation. Once loaded, the first HTML pages come up very quickly, but it takes about a minute to get the first JSP page to come up.

With Tomcat, once you've started the HTTP server, you're up and running. There is a little startup time (about a minute) prior to the first HTML page coming up, but then everything runs smoothly. The first JSP takes about 15 seconds, and after that there's no perceptible lag.

Runtime

Runtime is where WebSphere beats Tomcat pretty handily. I have to repeat that these tests are strictly unscientific, but they were run on a dedicated machine, so I'm pretty comfortable with their overall validity.

I ran two sets of tests, both using the same script. The script is my automated test script for the PSC400 product, which consists of about 20 different panels, ranging from about 4KB to 12KB per page. One test scenario ran three users simultaneously, each running through the script three times. Pause between requests was 500 milliseconds. The second scenario was exactly the same except that I bumped the number of both users and passes up to 20.

Here are the results, averaging the values over all 20 panels:

At smaller workloads, Tomcat is comparable in performance to WebSphere. However, Tomcat isn't nearly as scalable, as the 20x20 numbers show. Tomcat quickly falls apart, with the average and maximum numbers 3 and 4 times the equivalent numbers in WebSphere.

Even more disturbing was the trend. Web Roller provides a very nice graphical summary, and below are the plots for average time of both WebSphere and Tomcat.

Figure 1: Average WebSphere response time with 20 users and 20 passes

The average time for WebSphere stays nice and consistent from one page to the next. But take a look at the Tomcat graph:

Figure 2: Average Tomcat response time with 20 users and 20 passes

Notice the distinct upward trend for the Tomcat numbers, which also showed up as a general slowdown as workload increased. This may have something to do with memory management; I couldn't begin to tell you. But the numbers are pretty straightforward: the higher the workload, the better WebSphere performs in comparison to Tomcat.

So Which Will It Be?

So which is right for you, Tomcat or WebSphere? It really depends upon your requirements. If you need a Web application server that's fairly simple to install and run and you don't plan to have a really high workload, then Tomcat is perfect. But as your needs increase, it makes sense to move over to WebSphere. Even though maintenance is a little more work-intensive, WebSphere's scalability far outweighs the added effort.

If you're just beginning your foray into Web application design and your R&D (research and development) effort is going to be more R than D, I'd suggest Tomcat because it's easier to install and get working with. But if you're already well on your way toward implementing a fully functional and highly used Web application, WebSphere is probably the better choice.

I hope this clears up a little bit of the confusion and helps point you toward a logical decision for your organization.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. Joe knows more about WebSphere and Tomcat than is good for him. PBD's PCS/400 product, the only product designed specifically to allow RPG programmers to move legacy programs to the Web without learning HTML or Java, was Tomcat-enabled just for this article. You can reach Joe at This email address is being protected from spambots. You need JavaScript enabled to view it..