To J2EE or not to J2EE

Many Java shops are wasting time and money by driving a big ol' SUV of a platform when all they need is a zippy little compact, according to a recent report.

The majority of new applications don't require all the functionality provided by the Java 2 Enterprise Edition (J2EE), yet that is what users are paying for when they buy a "standards-based application server" to deploy them, suggested Illuminata analyst James Governor in his recent "Java on the Cheap: Argument" white paper.

Instead, said Governor, many smaller organizations may be able to avoid the expense, complexity and hardcore skill sets involved with J2EE by using a Java-based servlet engine, such as Apache Tomcat, rather than a full-blown J2EE application server. Server-side Java commonly sits between back-end data and the client, fulfilling presentation rules and may be supporting some basic business logic. It's only when applications are heavily transaction-oriented that full-blown J2EE is needed, he said.

"This question of which to use as a server is relevant when users have decided to build rather than to buy. If the user is buying a packaged application, such as the ATG Dynamo commerce server which runs on certified J2EE servers, obviously they need J2EE. But for a home-grown app, the user should make an informed platform decision," Governor said.

Servlet development - which is relatively rapid and lightweight, compared to architecturally-driven J2EE development - is especially suited for applications that don't require middle-tier persistence or capabilities such as load balancing and failover for high-availability.

"An example of a lightweight app would be one that creates a single view of a customer for a CRM portal. In this case there is no actual transaction, this is a read-only application," Governor said.

Hassan Syed, a Vancouver-based consultant with PSS who advises companies on development strategies, said that although the servlet approach goes against conventional wisdom, it has merit.

However, Syed said, "it is hard to get companies to do it, and strangely enough it's harder for the smaller ones I work with. They seem to feel like they have to work with the full J2EE for their product to be taken seriously. It then comes as a surprise to them when I tell them that the enterprise that buys it may well farm it out to [a servlet engine] rather than the main platform."

In fact, Syed added, with the days of free-spending on IT a distant memory, it is very attractive to go with apps that don't need a top-dollar infrastructure. Of course, he added, you can't just use any old stripped-down server that's laying around, it has to be one that is stable as well as cheap.

Stability in this development model is the one point that leaves Toronto-based Java architect Bill Foxell feeling a little uneasy. The technical overkill of using J2EE as the go-to platform costs money and may look ugly, but he thinks there is something to be said for the peace of mind it brings.

"Obviously you want to keep a lid on capital expenditures - and supporting J2EE is a big one, for sure - but running apps on a Web server will make them less stable. So then you have to decide just how much less stable is still OK. For example, in cost-effectiveness, terms it makes sense to build something like a Web-enabled calendar or contact lists as a servlet, but how much grief would that cause people if it goes down for an hour," Foxell said.

"So I think that this idea is probably one of those things that makes sense from an ROI perspective, but it just feels funny to a lot of coders and CTOs out there," Foxell said.

Governor agreed that this is a decision that needs to be made carefully, noting that cost-conscious users should beware pushing too far by "trying to bring J2EE-like capabilities to their servlet and JSP (Java Server Page)-style apps."

"There is no tick list" for which platform to use, he said, but since vendors will not push the J2EE/servlet distinction it is worth considering since they will, ultimately, respond to user pressure.