"That which we call a rose by any other name would smell as sweet."
--William Shakespeare

(An interesting side note: The Bard enjoyed double entendre, and it has been suggested that this reference might have been a little dig at the Globe Theatre's rival, the Rose Theatre, and its subpar sanitary arrangements. I thought you might get a kick out of that information.)

What really is in a name? This latest Web application server offering from IBM has not one but two buzzwords in it: IBM's catchall e-software term, WebSphere, and the universally overused "express" (for example, Burger Express, Hair Express, and my favorite, Sleep Express). Well, does WebSphere Express live up to either one of these monikers? In this column, I'll explore that very question:

• Overview of WebSphere Express
• Migration from older versions
• Comparison to other WebSphere Version 5 editions
• Server management
• Application deployment
• Performance

And since I don't have the column space to delve into all of these topics in any great detail, I'm going to have a poll to see which of them are important to you, and I'll dedicate more column space to the top topics. As always, folks, this column is your column, but you have to let yourself be heard.

Overview

I'd like to be able to write a column that's positive and glowing, a column filled with great things to say about the product and its features, a column that details the wonderful strides IBM has made in usability. And you know what? I can!

That's right, folks! You know me, Joe Pluta, the Grumpy Old Programmer. You may recall the fit I pitched when The Great WebSphere "Change in Direction" occurred, in which we were told that there would be no free WebSphere. Well, IBM announced this, WebSphere Express, as the replacement. And after much anticipation, the product is finally here. Does it succeed? Well, you know that I call it like I see it, and in my opinion, from a standpoint of feature/function, WebSphere Application Server V5.0 Express for iSeries (or WAS5X, as I like to call it) lives up to both the WebSphere and Express designations.

It's definitely WebSphere--in fact, it's something of an evolutionary release when compared to Version 4 (I'll get into that a little later in the column). That is to say, there's not a lot that's new, but what's there is done well--with one glaring exception that I alluded to the last time I discussed WAS5X. In general, WAS5X is a JavaServer Pages (JSPs) container. No fancy EJB support, no clustering capabilities--just a simple application server for servlets and JSPs.

"Simple" is not meant to imply barebones, either. WAS5X supports the latest J2EE APIs, including JSP 1.2 and Servlet API 2.3. WAS5X also includes full support for an amazing variety of acronyms, including these:

• JavaMail 1.2
• JCA (J2EE Connector Architecture)
• JNDI 1.2.1 (Java Naming and Directory Interface)
• LDAP (Lightweight Directory Access Protocol)
• XML via Xerces and Xalan
• Web services support via SOAP, WSDL, and UDDI

Currently, WAS5X has plug-ins for both the IBM HTTP Powered-by-Apache server and the Domino HTTP for iSeries server. Note that WAS5X also runs on Windows and Linux, but I don't usually bother with that fact except when I'm using the WebSphere Test Environment in WebSphere Development Studio client (WDSc), but that's a completely different topic for a different column. In any event, WAS5X definitely lives up to its billing as part of the WebSphere family.

However, it's from a deployment and management standpoint that the product lives up to the Express label. Configuration is 100% browser-based now and consists of two pieces: an extension to the original HTTP server administration and an entirely new browser-based administration console, shown in Figure 1.


Figure 1: The extensions to the HTTP server management console are very slick. (Click images to enlarge.)

The HTTP administration extension makes it very easy to get WAS5X up and running. A wizard walks you through creating a WAS5X instance. In essence, all you need to know is the name of your server, the TCP/IP address of your iSeries, and the port the new server will listen on. It's a little more complicated than that, but not much. Enter the values and hit the button, and you have a new server. That truly lives up to the "Express" name in my book.

For more complicated tasks that involve actually changing the way the installed applications work, you'll need to use the administration console, but that's a nice browser-based application as well. See Figure 2.


Figure 2: The new browser-based WebSphere Express administration console is also nicely done.

Note: If you have never used a browser-based application, this interface will take some getting used to. It doesn't have the linear feeling of a 5250 application, and sometimes you can't tell whether something has actually happened or is still in process. You'll need to be patient while you're learning. But for anyone who had to live with the installation and configuration of the old fat-client, CORBA-based adminclient application, this new console is a huge improvement.

Now, it's not all wine and roses, folks, not by a long shot. The first touch of the product is smooth as silk, but if you look under the covers, you'll still find a little burlap. In particular, migration and/or deployment of complex applications can uncover a few snags. Keep in mind, though, that even if there are some problems in deployment, they may well be due to my lack of knowledge. I'll be trying to get more information from some of my sources, so if an area that I report negatively on is important to you, please vote for it in the reader poll so I can make sure to update you in a later column.

Migration from Older Versions

As I noted, WAS5X is in many ways a simple evolutionary step from WAS4. The concept of the J2EE deployment model, using WAR and EAR files, is the dominant theme. If you're not familiar with these concepts and you are planning on doing anything past the bare minimum with WebSphere, then I suggest some additional reading. To get started, you might want to get Sun's spin on things, first from the architectural standpoint (a slightly older document which identifies the various pieces that make up an EAR file), and then from the "role" standpoint (a somewhat newer document that details the activities people do to develop Web applications). The thing I find interesting is that in Sun's view of the world, it takes five layers of people to develop and deploy an application (no "how many developers" jokes, please). But anyway, the idea behind this model is to make it easy to deploy applications. And from what I understand, migration from WAS4 to WAS5X is quite straightforward. Of course, I'm not going to be that lucky, am I? No, I have to start from WAS Version 3.5 Standard Edition (WAS35SE), and I can't even find documentation to help me.

However, my contacts over at IBM once again came to my aid and pointed me to the WAS5X manual and particularly Chapter 8, detailing migration from WAS35SE to WAS5X. Unfortunately, one of the first points was the following:

"If only one application server is listed in the administrative console, that application server is used to generate the 5.0 instance. If multiple application servers are listed in your server environment, you have three options:

The migration tools merge applications from multiple application servers of a Version 3.5.x instance into a single J2EE EAR file containing multiple Web modules, one Web module for each 3.5.x application migrated. The EAR is deployed as a single application within the Express 5.0 instance.

If you do not want your applications merged into a single EAR file and run in the same application server, you need to separate them into different 3.5.x instances prior to running the migration tools. Each instance should have a single application server containing the desired Web application or applications. You then migrate each 3.5.x instance to a corresponding Express instance.

Use the WebSphere Development Studio Client environment to build an EAR file for each 3.5.x application you have and deploy each EAR file into a single Express instance. This option does not use the migration tools shipped with the Express 5.0 product. If this is your preference, we recommend that you follow the roadmap for Tomcat instead as outlined in "Manual migration using source files" on page 110."

Well, the idea of having multiple application servers was one of the strengths of WAS35SE and one we took advantage of quite a bit, so this was an immediate obstacle. But I figured I could muddle through the first option and then just pare down the resulting EAR file in WDSc. Unfortunately, I quickly ran up against an arbitrary limit of 300 files in the document root (like any enterprise-level shop, we've got thousands of files in our development environment), so the conversion didn't complete successfully.

Thus, I had to resort to the last option, manually creating an EAR file. By using a stripped-down version with just a couple of programs, I was able to install and run PSC/400 on WAS5X without too much difficulty, but it's definitely not a plug-and-play operation.

Comparison to Other Version 5 Editions

I'm not going to spend a lot of time on this topic, because it's really not my area of expertise. I'm not a big user of Enterprise Java Beans (EJBs), and the bulk of the difference between Base and Express is EJB support. And while the Network Deployment edition seems to have more capabilities as far as supporting multiple environments, the $13,000-per-processor price tag is a little excessive.

You can review the capabilities of the various editions and decide for yourself which are important to your organization. My focus is on ease of deployment, low price, and flexibility, so I lean toward the Express edition. For a complete list of Express features and a specific list of Base features not included in the Express edition, click here. The list of Base features is here, and the Network Deployment features are here.

Server Management

This may be the easiest part of the job. Now that the new administration console is in place, it's almost trivial to administer servers. The primary tasks of administration--enabling and disabling individual applications, and starting and stopping applications and servers--are all easily available in a couple of easy to navigate pages. Figure 3 shows an example.


Figure 3: Managing applications is relatively easy (albeit a touch slow) with the browser interface.

I'm still doing a little testing, but at this point, I have found one annoyance concerning startup. Like WAS35SE, WAS5X has its own subsystem to start. In the case of WAS35SE, this was QEJBSBS, while for WAS5X, it's QASE5. When I start QEJBSBS, it "remembers" the last state of its application servers and automatically restarts them. That means that, after an IPL, all I need to do is restart QEJBSBS to restore my application servers to the state they were last at. This is important, because it means that I don't need some sort of configuration file to determine which servers need to be restarted when I IPL.

Currently, WAS5X does not do this. When I restart the QASE5 subsystem, no Web applications are started automatically. I've tried to figure out a way to do this, and I will ask around for more information, but at this point, there is no easy workaround. My IBM sources came through once again and pointed me to the WAS5X manual, this time Chapter 5.1. This chapter contains information on programmatically starting and stopping WAS5X servers. And while the code looks easy enough to implement, that means that I will need a utility to do this autostart and probably a database with flags to indicate which servers should be autostarted. With WAS35SE, it was all done for me. A quibble, to be sure, but just one of those things that really make me wonder if anyone talked to those of us using WAS35SE before the decision was made to do away with some of the features.

Application Deployment

By enabling the J2EE deployment model, WebSphere Express allows someone with no programming skill to deploy an application--in theory, of course. In reality, there are often quite a few bumps in the road. However, couple this feature with WDSc's ability to export EAR files ready for deployment, and you can package up an entire application into a single deployment module that you can then send electronically to people in other locations to install on their machines with a minimum of effort. That is, of course, as long as the EAR deployment model actually fits your application architecture.

Warning: Grumpy Old Programmer reiterates his position! This is not a knock on the WAS5X developers, except for the fact that they have removed the wonderfully flexible WAS35SE capabilities and replaced them with the less flexible J2EE model. I don't mind supporting the J2EE model, I just hate the fact that it's the only model supported.

The EAR file model is not a proper application deployment model. It is at best an application installation model suitable only for relatively simple applications--and in its infancy at that. There are no capabilities for upgrades; for versioning; for sharing resources among multiple enterprise applications; for having development, testing, QA, and production environments; for supporting multiple production environments; or indeed for most of the features we take for granted in business application deployment on the iSeries. The EAR model is one of the areas in which the J2EE architecture shows its UNIX roots in a particularly unflattering light, and we can only hope that the model will mature. And while I can work around some of the limitations in the EAR model (Sarah Poger has done lots of research on using symbolic links to address some of the issues), the fact that I have to work around them at all emphasizes the lack of flexibility of the model as currently implemented. I've said all of this before, so I'll close with a quick comment and then move on to other issues: When any language or tool crosses the line from helping me write code to dictating to me how I must deploy it, then it will have problems in a business application. This is because, unlike a utility or a game, a business application must change to suit the end user, not vice versa, and an inflexible deployment model rarely meets the needs of all businesses--in fact, the original deployment model in a business rarely meets the needs of that same business as it evolves and matures.

OK, end of editorializing and back to the column. I will, of course, be doing a lot more work with this particular issue because somebody has to figure out how to run multiple environments with WAS5X, and it's certainly not clear today how to do that. If you think multiple environments or any other deployment issue is important, please vote for application deployment in the poll.

Performance

I haven't been able to run any stringent tests yet. I hope to do some of that over the next few weeks. If you're really interested, please vote for Performance in the reader poll. I intend to compare WAS5X with WAS35SE and then possibly with the latest Tomcat version if I have time. Unfortunately, after spending days working around the limitations of the EAR file, I find that Tomcat doesn't even support them, so it's one more non-standard standard to deal with.

My initial impressions are that the software runs about as fast as it used to. This is purely a subjective, non-scientific measure, but PSC/400 seems to work just fine. There are some minor differences: WAS35SE tended to sort of cache output and then send it all in one shot, while WAS5X outputs it more granularly. This is a side effect of my use of programmatic server-side includes, but it usually doesn't seem to be much of an issue.

Where I really do notice a problem is in deployment. Right now, strictly adhering to the J2EE practice of deployment via EAR file, every time I want to make a change on the host, it means shutting down the application server, uninstalling the application, installing the new version, and restarting the server. For whatever reason, each of these steps is a minute or more, so the total time for restart is upward of five minutes. This is rough enough for an initial deployment, but for mission-critical updates, it's pretty tough to deal with. Until this speeds up, I don't think it will be feasible to use in a production environment.

Conclusions

This is a first look, as you can see. I found quite a few good things and a couple of not-so-good things. WAS5X has many features that make it an easier-to-use product than its predecessor, and the development team should be proud of its efforts. At the same time, a number of issues need to be addressed. The prompt responses from Tom convince me that people are actually looking at these things. And truly, most of them are probably not of screaming importance. Migration, for example, is a one-time issue and only important to companies like mine with significant development effort invested in WAS35SE. On the other hand, the deployment issues are significant and will only get worse as more people try to use these products. I firmly believe something needs to be done to at least provide interim support for incremental deployment.

Other than that, though, WAS5X is an excellent first release, and I'm looking forward to better and better things.

Postscript

Unfortunately, not all is well in the software delivery department. I've been trying to get my software for some time now, and it's still not all here yet. As I noted in last month's column, I had managed to order WAS5X and WDSC5 through 1-800-IBM-CALL. Unfortunately, after that article went to press, I was told that this is not the correct procedure. Since I lease a development machine through Partners in Development, I needed to go through the PID program. I managed to get the order correctly placed on May 5.

That is not the end of the story. IBM sent the software Airborne Express. Since they sent it without sending me any tracking information, I didn't know it was coming. A package arrived while nobody was available, and the fine folks from Airborne Express simply left it on a concrete stoop on a busy sidewalk between a restaurant and a bar and reported it as "delivered." It wasn't until I talked to IBM to check on the package that I was told it had already been sent.

The folks at IBM once again did their magic, and relatively quickly I received a new shipment (and was even given the tracking number ahead of time). And while Airborne delivered the package late, at least they delivered it. At this point, seeing the cup as half full was getting to be a habit, and this shipment was no different. While it did contain the WAS5X disks, WDSC5 was "backordered." How a mass-produced CD can be backordered is beyond me, but there you have it. Of course, this is the same issue I have with the original estimate of two weeks to ship the disks.

(Author's Note: On June 2, I got an email that yet another Airborne package was on its way. Assuming this package arrives safely, that will be a total of four weeks from order to delivery.)

The really ironic thing is that once I got the disks, I realized I needed a recent group PTF. And while this has to actually be created dynamically in response to my request, I was able to use the iPTF system to generate the entire 2 GB group PTF and download it that night. Why couldn't the same have been done for the actual production products? I have no idea.

So, while the products are getting to be very impressive, the shipping procedures leave something to be desired.

Reader Poll

As I mentioned, I'm going to allow you to decide in which order I cover other WAS5X topics. Go to the Reader Poll to choose. I'll write about the topics according to the number of votes received. Please note that there is no option for comparing the other versions of WAS5. I'm not going to do an in-depth article on that topic.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used 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. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..