Which Web Application Server makes sense in today's technology landscape? You might be surprised.

The concept of a Web Application Server (WAS) has been around for a long time and has seen a lot of evolution. Earliest WAS implementations grew out of the attempt to use HTML, designed primarily as a way to serve static data on request, as a way to provide business application functionality. This can be done only if the requests can serve up dynamic data. In the end, this means touching a database of some kind, so perhaps the simplest definition of a Web Application Server is a method of allowing a user with a browser to interact with a database using business logic. We can come up with edge conditions and extreme cases, but in the line of business that we midrange programmers support, that characterization is almost universally applicable. This article will explore the state of today's technology as it pertains to that description of WAS.

A Little Terminology

I don't want to spend much time on terminology, but it's important to understand a few concepts.

First, application servers are not necessarily Web Application Servers and it's critical to know the difference when doing your due diligence. The thumbnail definition is that an application server will connect anything to the business logic, while a Web Application Server is optimized for browser access. With the headlong rush to mobile development, this delineation isn't as clear cut as it used to be, but for the purposes of this article, we're going to stick more to the browser (since, in the end, you can still use a properly designed browser application as a mobile app).

Next, once you narrow the field down to just Web Application Servers, you still have to choose implementations; that distinction generally comes down to Java or not Java. I suppose you might make a case for the Microsoft stack as a distinct subset, but to me the real difference is that Java is so rigorously standardized through the Java Specification Request (JSR) process. That standardization allows you the luxury of being able to implement a strategy, knowing that it won't suddenly take a turn in another direction and leave you with an orphan technology (can you say .NET?). It's ironic that IBM is both the best at this and at times the worst at it. The IBM i is the poster child of legacy value protection, and yet in the software world you get the diametrically different worlds of Eclipse and EGL, where one is embraced and the other is an afterthought. An interesting case is the PHP-based architecture that I like to call RAMP (RPG, Apache, MySQL, and PHP). Yes, I realize that MySQL is no longer really supported, but to replace it with DB2 (or Zend's DBi product) would mean I lose my nifty mnemonic; RADP just doesn't have the same ring to it. But that's actually illustrative of my point; less stable technologies have a tendency to disappear. PHP itself has a history of pretty massive changes; for example, the object model in PHP5 is fundamentally incompatible with the one in PHP4. And now that Zend has been purchased by Rogue Wave, it will be interesting to see where it goes. But let's focus now on the Java space for WAS.

To be sure, the concept of a Java WAS has evolved as much as anything over the years since it was introduced, as anything will over time. Historically, the Java WAS architecture is tied to the Java EE standard, which first appeared way back in 1999. Since then, a wide range of functionality has been added through additional JSRs with acronyms like JAXP and JPA and, of course, the dreaded EJB. And while there have been some rough patches (my use the word dreaded for EJB was not in jest), generally speaking, you can chart an orderly course from early versions of the Java EE standard to applications running today, with just about any technology required by a web application available to you as a Java EE package. And given the full-fledged embrace of Java by IBM and particularly the IBM i, I think it makes sense to concentrate there.

Three Tiers

This might seem to be a fairly arbitrary classification, but I think of any WAS as being in one of three tiers: Cadillac, Buick, or Kia. Actually, that's not entirely accurate, since the Kia while low-priced is hardly free. But indulge me while I present my category criteria. The Kia level is your standard open-source solution: everything in the stack is free software, with the only cost being your time (which is as valuable as you decide it is!). The Buick level is a standard proprietary version of the Kia, which typically includes easier packaging and deployment, some bells and whistles especially in development and debugging tools, and some level of support that usually varies depending on the amount you wish to pay. The Cadillac version is what you might expect: very expensive (perhaps to the point of it being the Bugatti option) but with complete support. It has features not easily reproduced or in some cases simply unavailable in the less expensive options, but that level of functionality comes at a steep price.

Java WAS options run the gamut of those options. You can easily put together an entirely free application stack using, as an example, the Apache offerings. This direction isn't without some peril. Apache has TomEE, which can probably be seen as the successor to Apache Geronimo, which in turn is the base of IBM's WebSphere AS Community Edition, which is no longer supported and has been replaced by WebSphere AS Liberty. Whew! The moral of this story is that the free community, even when supported by major players, is a very fluid environment. If you did a lot of development under Geronimo, you might have trouble moving to TomEE. A lot of that depends on how true you stayed to just the Java EE standards and how much you took advantage of Geronimo extensions. This tier has a lot of players with varying levels of support and development activity, but those levels can change pretty quickly. GlassFish, as an example, was the reference version for Sun's Java EE technologies, so you might have thought it would be around forever. However, Sun was purchased by Oracle, and Oracle also purchased BEA, which meant they had two servers: GlassFish and WebLogic. In the end, they decided one was enough, and that one is WebLogic; GlassFish is officially without commercial support. Welcome to the wild world of open-source software!

The second tier is the province of the commercial products such as the aforementioned WebLogic. WebLogic is a featured player in this space, but the more dominant choice is probably JBoss. Given its purchase by one of the most successfully commercial Linux implementations, the RedHat web application server is certainly one to be reckoned with. Along with the standard IBM WebSphere offering, you have a number of choices in the commercial middleware arena. This is probably the space that most businesses larger than a startup should occupy. Unless you have in-house development staff with some serious web development expertise, you're not going to be able to grow past the free stack without some serious consulting support. At that point, it's hard to argue against implementing a commercial offering, which already has the security and scaling built-in.

The Cadillac space is almost entirely taken up by the 800-pound gorilla of WebSphere and especially the WAS Network Deployment edition. With the ability to quickly run into millions of dollars in licensing and support costs, ND really is the Bugatti version. But to be sure, there are few options that even come close once you need that level of throughput. Of course, unless you're Walmart or Amazon, do you really need that level of throughput? That's a question only you and your board of directors can determine (if you don't have a board of directors, the answer is "no").

So which one is right for you? A lot depends on your growth path. If you never get past the free software stage, then really any of the solutions make sense, and as long as your applications stay vanilla (which they should be when you use free software!), you can move between the servers without too much trouble. If, however, you ever see going to a commercial package, then you should take a little more time with your selection process. If you're already an Oracle shop or heading that way, then WebLogic is the only logical choice, but that's the only reason to go that way. So unless you're heading off the IBM i, WebLogic doesn't make much sense. So now it's down to JBoss vs. WebSphere. You'd think this would be easy: WebSphere is an IBM product, so it's the best choice by default. However, the decision is a little more complex. If you're a shop that relies heavily on Linux, whether in standalone or virtual servers or as a partition on the IBM i, then JBoss has some obvious benefits. The initial cost is significantly lower, especially at the higher end of the spectrum, so if your primary driver is cost and you already have the prerequisite Linux support skills, JBoss may well be your best option.

There is another issue, though. IBM has been quite successful, especially in the last few years, in rationalizing their server line. The WAS Liberty platform scales from the free offering all the way up to the fully loaded enterprise capabilities of WebSphere ND. Applications developed at the lowest level can be deployed without change on the highest-end servers. This is not the case with JBoss; RedHat's entry environment is WildFly, and production is JBoss EAP. RedHat does not recommend developing on WildFly to deploy on EAP, so you have bifurcated development environment. You don't have to develop on WildFly; you can do your development on JBoss, but that's not as advanced from a standpoint of Java EE support. In fact, JBoss isn't even fully Java EE 6-compatible, so there's no clean way for you to develop with WildFly and then run that application on JBoss EAP. So any WAS product decision really must take your development cycle into account.

My final take? If you're more interested in price than leading-edge functionality and you have good Linux skills, then JBoss is the better choice. But absent those conditions, WebSphere Liberty provides the best development, deployment, and scaling solution for Java WAS solutions.

Non-Java Options

While IBM is clearly invested in Java as its primary language outside of the business logic space (where COBOL and our beloved RPG still reign supreme), you may be interested in the other options. I've already mentioned PHP. If you're willing to put in the effort, you can write your own WAS stack using PHP and your choice of ILE programming. PHP has a wide following both inside and outside the IBM i community, and the folks at Zend have worked diligently to make developing PHP code as uncomplicated as possible for RPG programmers. PHP was originally designed for creating web pages, so that part is straightforward. The rest of the architectural components, such as concurrency and failover and security, require a little more effort, but you should consider it as an option, especially if you already have in-house PHP expertise. One caution might be that a Cadillac version doesn't really exist for the PHP option; at the end of the day, you'll still have to roll your own for some of the more advanced features, but rest assured that there will always be someone willing to help you if the price is right.

And of course, I would be remiss if I didn't at least mention the Microsoft solution. You can always go that way, although I think the days of not being fired for picking Microsoft software have gone away. I think now you had better be able to justify your solution choice, and frankly the overall mood of the marketplace, at least as measured by Netcraft and the percentage of active sites for each technology, is not looking particularly rosy for the folks in Redmond. If your management is at all tech savvy, you might find Microsoft to be a harder sell these days.

What Could Have Been

I will always wonder what EGL (Enterprise Generation Language) might have been able to become had IBM stayed the course. The open-source version of EGL (called EGL Development Tooling, or EDT) stalled out, but before it did it offered a tantalizing glimpse of what a true tier-agnostic business language specification might look like. The ability to write in a single syntax in both the client and server tiers with the ability to move logic from one space to another is something I still don't see anywhere else. Add in the baked-in ability to pass data as records (something you just don't appreciate until you're forced to do without) and to seamlessly interact with objects outside the virtual machine (including any ILE program), and it was clear that EGL could have been the same sort of game-changer for web application design that Eclipse was in the IDE space. Alas, we'll never know, unless someone decides they have enough time to brush the dust off the EDT project.

In the meantime, I hope I've given you enough information to start your journey into the world of WAS and to make the decisions that best meet your company's business goals. I hope to provide more in the future!