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.
