There are many facets to J2EE Web application development. It's a powerful platform that offers a variety of possibilities and capabilities, with many different approaches and models of development available. This is both a strength and, for newcomers to the platform, an Achilles' heel.
In this installment of Journeyman J2EE, we look at the many sides of J2EE development with a focus on the diversity, dichotomy, and divided opinions that can challenge even experienced developers, but especially newcomers. Consider these some warning signs on the road to J2EE.
So Much to Learn, Who to Believe?
In the previous Journeyman J2EE (JDJ, Vol. 6, issue 9) I discussed the importance of continuous learning as a J2EE Web application developer, especially for those making the transition from other platforms such as ASP, PHP, and ColdFusion. This extends beyond the obvious matters of learning the Java language, JSP programming, and/or the servlet API.
Of course, there are all the other APIs available in the platform, including JDBC, JMS, JNDI, JTA, and RMI, that you may or may not need to learn about at the outset. If you need to use any of them, it will be rather obvious but they're worth persuing as time permits.
You may also need to learn about EJBs, but this can be yet another source of confusion as there are many opinions about their role. More about that later.
Even the simple choice of whether to use servlets or JSPs is beset by many arguments for and against. Just when you think you may have a handle on the debates and best practices, you may encounter discussions of design patterns, which can be a great resource for applying reusable design techniques but is yet another set of practices to learn and apply. (See the J2EE Blueprints at http://java.sun.com/j2ee/blueprints/index.html for more information.)
It's enough to make your head spin if you're coming from one of the aforementioned Web development platforms. In those communities we knew the enemy and the enemy was "them" - all the developers using other platforms. Okay, that's stretching it, but as much as there may have been debate within each community about best practices for implementing apps, nothing comes close to the incredible variety of approaches (and opinions) about how best to do J2EE Web application development.
There's no use crying about it. The Java platform is incredibly rich, and this variety speaks to the many different ways in which the tools can solve problems for a wide range of applications. One of the key problems I find in discussions about alternative approaches (or rather a problem I have with naming "best practices") is that what works for one situation may not be the best solution for another.
A frequent source of confusion is the matter of whether you're programming "in the small" or "in the large." In other words, are you developing a rather simple application, displaying just a few pages to be used by a relatively small audience, or are you developing a full-blown e-commerce application with authentication and authorization, database transaction processing, session handling, personalization, internationalization, and more that will be implemented on a cluster of servers with distributed processing?
