--Madonna
This is a watershed period in iSeries development. We're slowly starting to see some recovery in the job market--not a lot, mind you--and the visa situation is still a big thorn in all of our sides, but there are glimmers of hope. I've heard of a few folks getting jobs lately that have been looking for over a year.
At the same time, IBM has inundated (I can't think of a more apt term) us with a bounty of new products. While the WebSphere name at times seems a bit overused--sort of the IBM version of .NET--the core product of the WebSphere Application Server (WAS) and the incredible suite of development tools under the WebSphere Studio moniker provide us with development capabilities we'd never have even guessed at just a few short years ago.
I intend to "weave" my way back and forth between those two particular product offerings over the coming months. For example, last month I introduced WDSci, and next month I will delve into the world of the Remote Systems Explorer. At the same time, though, I intend to do a lot of research into the application server offerings, and that's the focus of this column.
In this issue, I will cover the following topics:
1. The history of Tomcat on the iSeries
2. Should you use Tomcat?
3. Is WebSphere Express better?
4. Net change deployment
5. Scripting
6. OS/400 integration
But before I begin with Tomcat, I'd like to make one small announcement. Back in July, I wrote an article on "The Great RPG MOVE Debate." In it, I referenced some discussions I had on a mailing list, but I neglected to mention the name of the mailing list. Well, that list is the RPG400-L list, one of over a dozen lists hosted at www.midrange.com by my good friend David Gibbs. If you're unfamiliar with the concept, a mailing list is a little different from an online forum, like the ones hosted here at MC Press Online. With a mailing list, someone posts a message, and that message is emailed to all the subscribers of the list. You may then reply to that message, and your reply is in turn sent to all the members of the list. I encourage everyone to check out the various lists available.
And now, on with the show, starting with Tomcat.
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):
| Description | WAS3.5 | WAS4 | Tomcat |
| Configuration | ++ | ++ | ++ |
| Net change deployment | - | * | - |
| Scripting | - | - | - |
| OS/400 Integration | + | + | ++ |
| Total | + | ++ | ++ |
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.
Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at
MC Press books written by Joe Pluta available now on the MC Press Bookstore.
 |
||
 |
|
Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
|
|
||
 |
|
WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95
Now On Sale
|
|
||
 |
|
Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online