Like many smaller iSeries shops, we have limited J2EE skills as we move our business operations more to a Web environment....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
And while we want to have a Web presence, we don't need a site like Amazon.com. What we do need is a Web application server that meets our basic needs:
- Supports current J2EE standards for Web applications, XML and web services
- Is very easy to install and administer
- Performs well
- Supports open-source standards well
- Is reliable
- Fairly priced for our needs
- WebSphere Application Server, version 5, 4 or 3.5.6
- WebSphere Express, version 5
- Apache Tomcat, version 3.2.4
- Apache Tomcat, version 4.1.24
- BEA WebLogic
The hard part is deciding which server is right for you. What we've heard from IBM marketing, support, and field personnel about WebSphere is that every version was a "state-of-the-art" J2EE Web application server. That it always scales well and Tomcat doesn't. That it performs very well. That it's designed for easy administration.
Was that our experience comparing WebSphere and Tomcat? No. Which goes to show that you need to compare the products yourself (or find a business partner who's skilled on both). Read articles by people USING the servers, not selling them.
Our experience with WebSphere and Tomcat
Several years ago, I was able to create my first J2EE Web application at another company and deploy it on WebSphere version 3.5. Moving to my current company, we built the first Web-inquiry application here and deployed it on two different servers: WebSphere version 4 and Tomcat 3.2.4 on the iSeries. We recently have used WebSphere version 5 on a trial basis along with Tomcat 4.1.24 to run our pilot WebFacing application along with our order-inquiry application. We've also tried WebSphere Express on the iSeries for our order-inquiry and WebFacing applications. Yes, our experience is limited and specific to our situation, but it should give you an idea of how these servers perform.
WebSphere Standard Edition, version 3.5.x: This was a very difficult solution for us. IBM service packs created as many problems as they fixed. The odd number service packs hurt us: 3.5.1, 3.5.3, 3.5.5. While IBM touts WebSphere as a server-based technology, the admin console was designed as a "fat client" application that depends on all sorts of services such as Enterprise Java Beans (EJB). Maybe it was just us, but performance was very slow and configuration was difficult. As a free server it was priced right. We would use it again for anything? No.
WebSphere Advanced, version 4: This server is expensive but definitely a clear improvement over version 3.5.x in performance. The admin console was improved slightly but still not as nice as a browser-based admin console like most competitive servers have always had. It was still somewhat difficult to configure, and performance was better only compared to the older version of WebSphere. We would we choose to use it now for any reason? No.
Tomcat 3.2.4 on the iSeries: We found this server to be very easy to setup on original server and deploy our first Web application. Total time: about 90 minutes from start to finish. In addition, it ran well. Did it have all the administration tools we needed? No. But for smaller implementations such as ours, it ran very well. And we liked the pricing. Although it's a fine server in several respects, we want more management capability and newer J2EE standards support.
WebSphere, version 5: Is the fifth go-round the charm? Maybe for you. It's clear version 5 is MUCH improved over the earlier versions in all areas: better admin tools, a usable admin console that is browser-based (finally), better performance and more current J2EE support levels (Servlets 2.3, JSP 1.2). Supporting JMX and JVMPI standards, it is easy to debug and profile performance. It also is the best server for fail-over support, EJB support, JMS support and running IBM WebSphere software products. You should be aware that when new versions of WebSphere are delivered, it may take up to a year for some of the IBM WebSphere software products to support the new version. While this is a very good server, we didn't need to buy it given our other options.
WebSphere Express, version 5 for iSeries: Is this one really related to WebSphere? It's faster for sure. It's also the easiest server we've installed and configured. Supporting JMX and JVMPI standards, it is easy to debug and profile performance. It DOES have some limitations, but none that will affect our current use of it. We can even support XML and Web services well when we get there. And it is fairly priced at $2,000 per CPU (about 25% of the price of WebSphere). DON'T confuse the Express iSeries version with Express on Windows. The Windows version lacked some of the key features the iSeries version has for administration and wasn't as easy to setup for our environment. It supports the same J2EE Web container standards as WebSphere version 5. We'll deploy our new version of our inquiry Web application on this server.
Tomcat 4.1.24: This is a new production server from Apache that is vastly improved over 3.2.4. It provides the support we want for J2EE Web container standards, XML and web services, as well as adds flexible support for different JDKs, including 1.4. The administration is very simple. It compares favorably with WebSphere Express to some degree here. You can use standard debuggers and profilers supported by the Java Virtual Machine Tomcat is running on.
We will use this server for our newest WebFacing application. We actually were able to get this one installed and configured in 15 minutes to run our WebFacing application on a Windows server in standalone mode. We can run it on any server that way -- iSeries included. It also has plug-in support to the Apache HTTP server. On the iSeries, IBM has not supplied a plug-in to the HTTP server for this version of Tomcat. So far we've run it easily on Windows and Linux. We'll run it in production on a Red Hat Linux server. And its pricing is even better than WebSphere Express.
Where do these servers fit for you?
The key in this speedy evolution of servers is choice and standards. Both have been very good for the Web application server market. Unlike proprietary software that Microsoft, IBM and others develop, J2EE software is built to an open standard. As a customer, we have multiple choices here. To keep our choices open, we elected to avoid using the proprietary extensions IBM WebSphere offers in our J2EE applications unless we found a compelling reason to do so. These extensions usually add significant costs as well (DB2 Extender, for example). In addition, they limit our portability among platforms, databases and servers. Our business partner helped us identify our options clearly in this area.
Understand this: IBM is committed to making WebSphere the largest Web application server in the market. Expect more marketing push, bundling (as in Enterprise edition package), etc. IBM's software and services plans (for portals, commerce, host integration, mobile, content management and collaboration, etc.) depend on building a successful WebSphere install base. If you plan on running IBM versions of these products, you'll want to run WebSphere. If you're interested, there are some open-source alternatives for some of these Web application frameworks: Cocoon, JetSpeed and more. Some are from Apache or SourceForge or directly from vendors.
Despite IBM's marketing efforts and focus, after four years WebSphere is running in production on a small but growing percentage of iSeries servers. It's clear to me that WebSphere leads other servers in scalability with versions supporting clustering well, etc. If we were larger, we'd probably choose WebSphere, too.
What about Tomcat on the iSeries? IBM introduced Tomcat on the iSeries about two years ago. Now they tell us they will stop supporting it on the iSeries in a future release of the HTTP server. Does that mean you can't use Tomcat on the iSeries? No. You can run newer releases of Tomcat on the iSeries in standalone mode, since they include an embedded HTTP server.
What about IBM's lack of support for Tomcat on the iSeries? If you use and like IBM Supportline, this is probably an important factor in your decision to select a server. If you don't depend on IBM for technical support, it may not matter, especially since it's not an IBM product. We have found it relatively easy to get reasonable answers to most of our technical questions for Tomcat just by searching on the Web. And our business partner is a real help here, too.
As a smaller iSeries company, we're comfortable with our decision. We'll run our new inquiry application on WebSphere Express -- it's easy to use and performs well. And we'll run our new WebFacing application on a Linux server that can grow affordably as we grow our portfolio of WebFacing applications. And a year from now, we'll probably review all this again as new offerings come out.
What's your best strategy?
Your best strategy depends on your specific situation, resources and needs. Maybe you've found other options that deliver better value. Let us know at firstname.lastname@example.org.
About the author: The Value Manager is an IBM iSeries IT manager trying to make the right decisions to deliver better value for his company. He welcomes your comments and feedback. E-mail him at email@example.com.
- WebSphere Express key to iSeries future in e-business
Web development expert Jim Mason says WebSphere Express is an affordable, easy-to-use application server that's packed with features that previously couldn't run on low-end servers. It's something most customers have been waiting for.
- Access WebSphere from multiple HTTP servers
Did you know you can access the WebSphere Application Server from multiple HTTP servers running on the same or different iSeries machines? That's something you may want to consider if you want to isolate the compute-intensive resources of WebSphere Application Server or if you want to isolate WebSphere resources from user access for security reasons.