It Don't Amount to Beans
By Jim Jagielski
In all aspects of life, there are status symbols: The kind of car you drive, the kind of house you live in, your brand of beer, and so on. If you have a choice, you can bet status is applied to the variations. Technology is no exception.
Status symbols even exist in Web infrastructure design—and I'm not talking about the type of servers you're running, or how much memory they have, or the kind of bandwidth you have access to. I'm talking about application servers.
It's almost a badge of honor when your site infrastructure has grown to include a dedicated Java 2 Enterprise Edition (J2EE) application server. Mention that you're using PHP or mod_perl—"What? Still!?!"—and it's assumed that, well, you're just not in that enterprise league yet.
Once you do migrate to a J2EE application server, there's still certification to contend with. If your server supports only part of the J2EE specification—say, it supports servlets and JavaServer Pages (JSP) but not Enterprise JavaBeans (EJB), or it's not fully J2EE certified—that's seen as a disadvantage.
Given all of this peer pressure (both internally and externally; after all, how you're perceived by your present and future customers is important), it isn't a surprise that so many companies are implementing solutions based on high-end, high-priced application servers. But is that a wise choice? If the current market adjustment has shown us anything, it's that needless spending is a dangerous strategic decision. There are three fundamental ways of handling application logic: server-side scripting languages, fully certified J2EE servers, and JSP/servlet servers.
