I just got back from JavaOne in San Francisco this weekend. My humble opinions on the conference are presented elsewhere in this issue of JDJ. As expected, one of the main themes of JavaOne this year was the J2EE platform and related technologies. Over the last two years, since Sun announced the three editions of the Java Platform, J2EE has come a long way.

The products offered by third-party vendors are mature - and a large part of the mundane development activities are abstracted from the programmer. With the Java Connector Architecture (JCA) specification around the corner, integration with Enterprise Information Sources (EIS) also becomes much clearer and more manageable.

Openness Has Its Advantages
J2EE is definitely more open than any of the other enterprise software platforms available in the industry. However, this openness also means that Sun, as the owner of the specifications, doesn't really provide the entire product suite needed to build the enterprise applications. In short, J2EE is basically a bunch of software specs and APIs. While this is a good thing, in that the specs and APIs are not owned by a single vendor (i.e., Sun), this does mean that application developers have to depend on infrastructure support from third-party vendors, such as IBM, BEA, ATG, as well as Sun.

Openness Is Costly
This in itself is not a bad thing. Open APIs and vendor neutrality are what we all look for as enterprise application developers. However, when you get around to designing the architecture for an enterprise application, there are several tools and products needed to create the building blocks for the application. For starters, in order to use the basic features of J2EE, you need a J2EE application server. Some folks would argue that applications built on JSPs and servlets only require a servlets engine. However, for true n-tier distributed applications, you need the EJB container. EJBs are the nexus of J2EE.

Even if you were developing applications in the pure Web paradigm using servlets and JSPs, if you wanted to save the costs associated with the complexities of development and maintenance of infrastructure services - such as threading and persistence - you would have to pick an industry-strength application server.

And the story doesn't stop here. For messaging, you have to pick a messaging provider, such as MQSeries or Tibco. For commerce services, you need a commerce server, such as the one offered by BEA, ATG, or Macromedia. For the complete application, you need to add a personalization server, a workflow environment, a security solution, and a service provider for enterprise connectivity. Add an IDE, designing tools, and administration to the mix, and you're looking at a pretty hefty sum for a basic application. This can run into thousands for pure development.

J2EE development is expensive. And, because of the complexity associated with the platform, so is the training. With new APIs emerging every month, and updated versions of the existing ones, training becomes a major issue. The problem associated with cost may have been dismissed during the boom times, but corporations are now questioning the viability of swallowing such costs in an economy trying to bounce back from a slump.

In Search of Less Expensive Solutions
Although Microsoft technologies offer a less expensive solution, the openness and enterprise-presence of these technologies has yet to be proven. An alternative for companies is to consider cheaper solutions in the Java world. Open source products - such as Enhydra from Lutris and Jserv from Apache - are equally high-quality products. And all applications may not require the degree of scalability, performance, and robustness that vendors like BEA, iPlanet, and WebSphere tout with their product suites; however, when choosing the vendor, you need to look at their financial status. You don't want to be stuck with an unsupported product or one that gets tagged with a high sticker price because the vendor got bought out.

A colleague of mine mentioned that he heard from one of the product managers at a leading application server vendor that the vendor was considering bundling the application server products with their hardware and selling this as a package. This will certainly bring costs down. Plus the costs and effort associated with training, installation, administration, and maintenance of these products will be reduced considerably. But, in that case, you lose the benefits of vendor neutrality. You are back to the issue associated with buying a Windows PC with IE bundled in the package.

Consider the Costs and Trade-offs
My intention here is not to discourage you from developing applications on J2EE. I architect solutions on J2EE and I think it is one of the best choices available for enterprise development. Java is a great platform and J2EE has matured rapidly as an environment for developing enterprise applications. I just want to encourage you to think carefully about costs and trade-offs associated with J2EE-based development.

The best approach is to build incrementally as opposed to offering a solution that tries to solve world hunger.