The History of Tomcat on the iSeries

Those of you who have been following my column know that I've been talking about Tomcat for some time now--specifically since IBM pulled the plug on WAS Standard Edition. I think we can all agree that the biggest snafu with the release of WAS Version 4 was the fact that there was no free version. IBM had brought us all into the wonderful cocoon of WebSphere, giving us the first one free, and then they took it away and told us that the free version was no more.

This irked some of us.

And so I and many others raised our voices and--Lo!--we were heard, and IBM gave us Tomcat! Yes indeed, for the space of about six or nine months, Tomcat was the new standard for low-cost Web application serving on the iSeries. This even made sense, sort of, since IBM had already embraced the Apache HTTP server in such a big way. It followed that the Web application server of choice would be Tomcat.

Unfortunately, for numerous reasons, this has not panned out. While the powered by Apache HTTP server in OS/400 is a state-of-the-art implementation, the version of Tomcat shipped with OS/400 (3.2.4 last I heard) is considerably behind the current open-source version, and it has serious scalability and performance issues. It works, but not particularly well.

But then one day somebody realized that, since Tomcat is a 100% Pure Java application, there's no reason it shouldn't work out of the box on the iSeries. And so David Morris tried it, and it was good! And in fact, I today run Tomcat on my iSeries box. I'm a little behind the times, running 4.1.24 while the current release is 4.1.27, and Version 5 is currently in beta, but it's considerably ahead of the "IBM-supported" release. My only issue is that in order to use Tomcat, I have to use it in standalone mode, which means I can't take advantage of IBM's powered by Apache HTTP server. I understand that you may indeed be able to set up Tomcat as an in-process server to HTTP, but I haven't figured it out yet. If anybody should do so, please let me know.

So Should You Use Tomcat?

Well, the official word is that Tomcat is no longer going to be supported. At some point, IBM will no longer ship Tomcat with OS/400. According to statements by John Quarantello, IBM's eServer Solutions marketing manager, that probably won't be before 2005, but the writing is on the wall. IBM is moving to sunset Tomcat support in favor of WebSphere Express.

Note: The primary reason that Tomcat is still supported is that many of IBM's advanced offerings are built around it, rather than WebSphere Express, but one focus of IBM's development is to migrate those products to WebSphere Express over the next year or so.

So, given that fact, there are only three reasons to use Tomcat instead of WebSphere Express:

1. You have a "small footprint" machine, typically one under about 300 CPW.
2. You can't afford the $2,000 for WebSphere Express.
3. You want to use a Web application server that is platform-independent.

Small-footprint machines are becoming less of an issue. I think it's safe to say that IBM's direction is that even its smallest machines will be able to run WebSphere Express. And if you can afford an iSeries, the extra $2,000 for WebSphere Express is definitely a worthwhile expense. And even that expense is moot if you already have WAS 3.5 Standard Edition; talk to your Business Partner about upgrading to WebSphere Express.

The last reason is only an issue if you need to offload your Web serving requirements. You can, for example, easily run Tomcat on a small FreeBSD machine and thus completely free your iSeries from any Web chores. This is typically the case when you want to completely secure your iSeries from Internet access; by placing your Web server on a different box, you can then remove any connections to your production iSeries from the outside world. However, you can just as easily do this with WebSphere Express, provided you use a Windows or Linux front-end.

There is one other issue: deployment. But I don't want to get into that just this second. I'll cover that issue in detail later in the article.

Is WebSphere Express Better?

"Better" is an interesting word. Better than what?

Is WebSphere Express better than the old WAS version? IBM spent a lot of development time making WebSphere Express easy to use. From the Web-based administration to the integration with WDSci, everything about Express is geared toward making it easy to deploy applications as quickly as possible. And many of those features simply can't be matched by other Web application servers.

But is WebSphere Express better than Tomcat? That's a slightly tougher call, because the two are so different. Tomcat is a mature open-source project that does what it was intended to do quite well--and it doesn't do other things, period. For example, there's no Web-based administration, and that's just the way it is.

So I decided to do some comparisons along functional lines. This is a list of what I consider to be some of the most important issues. If you have other issues that you think need to be handled, please let us know by stating your case in the forum at the end of this article.

Configuration

WebSphere Express configuration has been completely revamped. No longer do you need a PC-based, thick-client console to administer the Web application server on the host. While it probably seemed like a good idea at the time, adminconsole never quite got over its initial hurdles of complexity and fragility. And though it worked fine when it worked, the extra work of installing the software and its many patches was one of the stumbling blocks of many early adopters of those previous versions of WebSphere.

However, configuration does not require wading through a mass of XML configuration files as is common with other Web application servers. Instead, a simple Web-based application allows you to do most of the standard configuration functions using wizards that step you through the process. And even the more esoteric configuration tasks can be handled through a separate application that replaces all the functions of the old PC-based adminconsole. This is a far better way to do things.

Initial application deployment is also much easier. All of the Version 5 WebSphere products, including Express, have been moved to the J2EE deployment model. In fact, most of this was done with Version 4, but in Version 5, deployment is done through a wizard. IBM's support of both EAR and WAR files for applications allows you to deploy just about any J2EE-compliant application.

Comparison: WebSphere Express is much better than all previous WAS versions and much better than Tomcat.

Net Change Deployment

Note that I'm talking about initial deployment. Those who have read my comments out on the 'net know that I'm no fan of the J2EE model for ongoing production application maintenance. As far as I can tell, the J2EE developers never made allowances for the application environment that typical iSeries customers work in, where programs change on a daily--even hourly!--basis in response to external conditions. Today, the standard procedure for deploying a change is to stop the server, uninstall the application, install the new version of the application, and restart the server. Typically, this can take tens of minutes, if not longer, and during that time, the entire application is unavailable. This is really not a viable mechanism in a production environment.

However, many pieces of your application can be "hot deployed"--you can simply copy the changed component (such as a JSP or a servlet) up into the appropriate directory, and in most cases, the application server will pick up the new component without having to restart. Now, this has some obvious ramifications for sessions currently in process, and you'll need to implement procedures similar to those you've always had in place for promoting software to production. But it's a bit more confusing with WebSphere, because you need to know which pieces need to be deployed and where on the iSeries IFS those pieces need to go. The latter information can be particularly difficult to determine.

But IBM is currently looking into this very issue. And while WDSci currently has no support for net change deployment, I'm confident that the developers will address this issue very soon; I think they realize exactly how crucial this feature is.

Comparison: WebSphere Express is the same as WAS4, worse than WAS35, and worse than Tomcat.

Scripting

One thing I found disappointing in WebSphere Express was that IBM changed the scripting interface yet again. The old wscp is gone, replaced by a new wsadmin with a completely new scripting language. The new language is something called Jacl. Jacl is based on Tcl (pronounced "tickle"), an open-source language used by lots of UNIX folks to create tools. The language is a little bizarre to this old RPG dinosaur. For example, take the following line:

This does something. In fact, it is a procedure that sums the digits in a string. That is, the string "1234" returns 10. Jacl is a Java-based version of Tcl, and wsadmin supports a specific syntax for WebSphere administration commands. There is definitely a learning curve involved with this particular tool, and I'm still working on it.

The real problem, though, is the lack of backward compatibility. Those of us who want to make our application installation transparent to the end user need to be able to do all of these functions programmatically. By making us have to change our procedures each time a new release of the product comes out, IBM is adding expense to our ongoing support of WebSphere. It seems that for at least a couple of releases nobody was really looking at this hidden cost. However, the good news is that the folks I've talked to at IBM insist that they recognize the issue, and I believe that future releases are going to be more compatible. We'll see.

Tomcat has programmatic deployment through the "deploy" command of the manager Webapp. The manager Webapp listens for HTTP requests and processes them as commands. This is a very powerful feature, though I haven't used it enough to determine whether it is as flexible as wsadmin. It certainly seems a lot simpler.

Comparison: WebSphere Express is different from previous versions (again) and more complex than Tomcat.

OS/400 Integration

This is where WebSphere Express truly has an advantage over Tomcat, not only now but even more as time goes on. For example, today you can sign on to a WebSphere Express application using your standard OS/400 user ID and password. While I recommend against this technique, especially for Internet applications, it's still a measure of the integration between the two environments.

Other areas where you'll benefit from this integration range from the Web-based administration I mentioned earlier to the ability to use your standard support line to handle installation, configuration, and runtime problems.

More important I think is the possibility of future enhancements. One of the things we may see someday is the ability to map a Web user ID to an OS/400 user profile so that sessions running under that ID will use the associated profile for OS/400 access. While not currently available or even scheduled, the fact is that, since IBM owns the environment, it will be possible for them to put this tight integration into place. Tie that together with the fact that you can take advantage of all of the great features of the powered by Apache HTTP server, and WebSphere Express starts to look very powerful indeed. For example, the Fast Response Cache Accelerator (FRCA) can ship out static Web components 4 to 10 times faster than the standard HTTP server. That's quite an improvement, and it's automatically available to WebSphere Express. Add in the automatic deflate capabilities of the Apache server, and now you've got some serious performance enhancements. Hopefully, I'll get a chance to do some more research into these particular areas and give you some more information in a future column.

Note: another area of integration is tools. While WDSci actually does integrate reasonably well with Tomcat, it really is designed to work with the various WebSphere editions. As WDSci evolves, you can be certain that it will take advantage of every new feature of WebSphere.

Comparison: WebSphere Express is better than previous versions of WAS and much better than Tomcat.

And the Winner Is...

So, if I were to summarize the results of this comparison, I'd get the following (a plus sign means WebSphere Express compared favorably to the other Web application server; a minus indicates an unfavorable comparison; an asterisk is a wash):

The configuration pretty much wins the day, making WebSphere Express outperform even my personal favorite, WebSphere 3.5 Standard Edition. WebSphere 4 actually was a bit of a step backward in overall usability, but I think it's important to note that WAS4 was really an evolutionary step to the current version. Without WAS4, there would be no WAS5 and thus no WebSphere Express.

Significantly, the two areas I have the most problems with--net change deployment and scripting--are both areas IBM recognizes as needing improvement, and I look forward to seeing subsequent versions of WebSphere that will address those issues.

Conclusion

Tomcat doesn't quite match up to WebSphere Express because it doesn't configure easily. Nor does it integrate particularly well with OS/400. However, if you are currently in the situation in which WebSphere is not feasible either because of budget or machine constraints, then Tomcat is a reasonable alternative. The good news is that as long as you use WAR files to deploy your applications, chances are that you will have little problem migrating to WebSphere Express. And once you're on WebSphere Express, you can then upgrade to other versions as your needs grow.

And that brings up the final point in the comparison. Tomcat is Tomcat, and that's all it will ever be. The designers have made it clear that they will not be adding EJB support; instead, they expect you, the end user, to pick a J2EE container and plug Tomcat into it. So there's really no "defined" upgrade path if you need additional features. Lots of other products out there can be combined with Tomcat, such as JBoss for EJB support, but it's difficult to determine which is the right tool for your environment. But with WebSphere, there is a clear path for upgrades: first to WebSphere Base Edition to get EJB support and then to the ND Edition for multiple machine configurations.

So, as long as your future coincides with IBM's vision--which is primarily a world of Linux, Windows, and OS/400--then WebSphere is the correct strategic answer. And for getting started, WebSphere Express is the easiest way to do it.