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?
What makes sense in the former case may fall woefully on its face in the other. By the same token, the approaches taken in the latter case may be overkill for the first. It's a delicate balancing act and the decision often falls on folks who don't have the time or experience to entirely grasp the ramifications of the many approaches. It's daunting, and some are forced to make quick (and perhaps ill-informed) decisions.
Let's look a little more closely at some of the debates. We don't have time to resolve or even carefully cover all of them, nor all facets of each, but they'll give you a taste of what you're in for if you're just getting into this brave new world.
Servlets or JSPs? You Decide
As I mentioned before, the decision of how best to use servlets and JSPs is no simple task. Should you use one or the other? Or both? Many applaud JSPs for making Java server Web development easier for many people. They're similar to other Web application scripting tools and hide some of the challenges of learning Java when getting started. Indeed, others will laud that they make it possible to split development roles among Java developers and pure page designers (who should just ignore the occasional directive or action element and might even be able to create JSPs with WYSIWYG design tools).
The reality for many developers, however, is that they are the designer, Web developer, and Java programmer (or newcomer) and that separation of roles isn't as important. It's for this audience though that others will argue that JSPs will cause a developer to shoot him- or herself in the foot, littering pages with embedded Java scriptlets, JDBC calls, and otherwise corrupting the vaunted Model/View/Controller (MVC) paradigm, which calls for the separation of data display, request processing, and business logic.
Some go further and plain decry JSPs in general as a poorly designed development approach, as argued in the article "JSP: You Make the Decision," by Jon Stevens (JDJ, Vol. 6, issue 7), which supports the Velocity Template Language as an alternative.
Others will argue that servlets are the only way to go; yet even among servlet fans there are debates about how to implement them. Should you have a central controller servlet through which all requests pass or not? The same argument can be debated in JSP development as well.
It seems that for most, a mix of servlets and JSPs is the way to go, and the O'Reilly title, JavaServer Pages by Hans Bergsten, does a great job of discussing the many different approaches (including integrating servlets with JSPs), with an especially lucid perspective that suits relative newcomers. I'd like to publicly applaud his book for doing a great service for those facing these frequently fractious debates. Notice that I'm not taking sides: my point it that you need to carefully weigh the alternatives but be sure to consider several arguments.
What About MVC?
A few more words about the MVC paradigm may be in order. If you haven't heard of it before, don't worry. You won't get far in your exploration of J2EE development before learning that for many it's a linchpin of interactive application development.
The only problem is that many MVC discussions will assert that a key facet is that the client "view" must be kept in sync with the back-end data source "model" driving its data display. Of course this can't work in the Web application model: there's no easy way to update a page sitting on your client's browser because data on the server has changed.
Does that mean the MVC paradigm is severely crippled for Web application development? No. It's just one part of the paradigm (and some may argue not even the most important). The MVC model and its separation of data display, request processing, and business logic makes sense as a desirable approach in all other respects.
Java Within JSPs
The subject of MVC and its separation of content and code leads to yet another area of debate, with respect to whether and how much Java you should be coding in a JSP. Again, this is an area that will be influenced by your perspective on whether nondevelopers will be editing a given JSP template (in which case a minimum of Java is important so as not to confuse them or put the code at risk by their modification).
Even then, if the JSP developer(s) is more savvy, does it still make sense to litter a JSP with embedded Java? Scriptlets are easy to use if you know Java, but there are several alternatives that will hide the code and it may be beneficial to consider them.
Custom tags (or custom action elements) are a well-defined feature in the JSP specification widely supported by JSP containers. They not only allow segregation and encapsulation of code, but also form the basis for resusable components and even greatly simplified processing within a JSP page.
For some the only use for custom tags is to leverage entire tag libraries from third parties (or Web container providers) that provide a whole range of useful services and features in your JSP, including easier database access, record processing, and mail handling.
Know that they are available as an option to ease your own development by providing another means to separate your code from your JSP. Still another way to segregate code is to use JavaBeans, Enterprise and otherwise.
What About Beans, EJB and Otherwise?
Ah yes, JavaBeans or EJBs. For the newcomer few things may be as confusing. It's pretty easy to learn how to use JSPs and even the servlet API, but if you're new to Java you'll need to do some work to wrap your head around these two topics.
Some will argue that EJBs are heavyweight, though that's a matter for debate. In any case, they're not the same and they're also not mutually exclusive (you can use one or the other, or both, or neither).
In my last article I mentioned how disheartening it can be for a newcomer to J2EE who may read that JavaBeans are critical to JSP/servlet development, only to find books that describe them solely from the perspective of their value in client application development and/or IDE integration.
It's easy to miss the value of JavaBeans, which is, like so much in Java, about encapsulating data and methods into an object that can be used to describe something in your Web application. With their standardized mechanism for accessing data in the bean (getters and setters), they also support another fundamental goal - reusability - and, perhaps more important, hiding implementation behind a widely accepted interface.
Again I'll refer to the book, JavaServer Pages, for its excellent explanation of the value and application of JavaBeans, though some reviewers at Amazon have faulted it for relying too much on JavaBeans and not discussing EJBs that much. He does indeed recommend them as an approach that's suited to more enterprise class applications, and this exposes yet another area of debate.
What about EJBs? Should they by necessity be a core component of your Web application? Some will argue that absolutely no respectable Web application would be built without them. Others, though, will debate that and assert that their overhead is overkill. As you read about them you'll learn that there are different perspectives to bring to the table. Again, I can only recommend that you keep your mind open.
Another aspect of the discussion of EJBs may lead to real confusion for the newcomer: some resources will be describing EJBs from the perspective of client app-
lication/applet developers. If these client apps need to connect to a remote distributed server, then encapsulating the business logic (and database interactions) on the server rather than the client will make eminent sense. But it's not an argument that resonates with Web application developers who have always been doing their business logic "on the server." Do EJBs then still add value?
As with the debate over MVC, purists, newcomers, and more practical adherents are often talking on different planes, making presumptions that don't apply in all cases.
EJBs make sense when both your Web and EJB containers are distributed on different systems. What about when they're on the same server? It's not that they don't make sense in that last instance, just that their benefit has to be more carefully weighed against their cost. Some containers provide integration that eliminates some of the overhead when the Web and EJB containers are on the same server.
There's clearly a lot more to EJBs than the simple matter of segregating the business logic from the client. There are aspects of security, resource management, transaction control, and even database integration that can be encapsulated and managed by EJBs.
It takes a lot of reading, trial and error, and looking to more experienced counterparts for guidance on deciding when to leverage EJBs. There are several books on the generic subject of EJBs as well as the more specific matter of when and how to use them in Web applications. Just keep an open mind that's both skeptical and flexible. However, the diversity of opinion doesn't end with the debate over EJBs.
Even the matter of choosing a J2EE server or a Web, or EJB container is fraught with contentious and rancorous debate. There are open-source adherents for whom no commercial solution will do. Prominent offerings include Apache's Tomcat and JBossServer. It's certainly not obvious that an open-source solution will be any less capable than a commercial solution (though be careful, not all open-source products are licensed to be used for production purposes).
Even among commercial products there's a world of difference among the many contenders. Of course, the largest share of the J2EE server pie goes to BEA and IBM. There are many other worthy contenders, including offerings from Borland, HP, Iona, iPlanet, and Macromedia. Sun's J2EE-compliance program will help to sort out which companies provide fully compliant servers, but the number is large and growing.
Then, too, it's not always necessary to acquire a complete J2EE server. Perhaps your needs will be satisfied with just a servlet container. There are many offerings in that arena as well, including New Atlanta's Servlet Exec and Gefion's LiteWebServer.
Many vendors offer trial versions, and some offer unlimited development versions (or versions allowing only a small number of users). It's easy enough to try out a variety of servers to determine which suit your needs. Also, look to resources like Sun's Solutions Marketplace (http://industry.java.sun.com/solutions) and JDJ's Buyer's Guide (www.sys-con.com/java/wbg/index.cfm) for more insights.
What's It All Mean?
Is all this variety and contention over different approaches a bad thing? Not really, it's just different if you've only recently come into the J2EE arena. Is it hopeless? No, there are many resources available to help you learn about the many approaches, including articles, books, Web site information portals, classes, and mailing lists. The challenge is to digest it all, keep an open mind, be open to debate, and don't give any one argument too much weight. Favor those that do a good job of offering a balance of approaches, and compare and contrast them.
If anything, these numerous possibilities are another facet of the Java platform in general. It's a rich and flexible language, a platform with much to offer, and it satisfies an incredibly wide audience. And that audience is expanding all the time.
If there's one more hopeful message to sound, it's that this very widening of the Java community will surely lead to a more cohesive and well-digested sense of how best to apply the many sides of J2EE to a range of problems.
The fact that Java is set up to be molded and influenced by the Java Community Process is a sign that hopefully more and more public discussion by an ever-widening (and constantly learning) circle of participants will yield still better implementation solutions.
Fasten your seatbelts, fill your coffee cups, and settle in for the ride, which will be anything but boring. There will be an ever-growing abundance of resources and experienced cohorts to learn from, and even the newcomers among the audience may bring great new insights and possibilities to the table.
One last thing: speaking of the variety of developers out there, we welcome your feedback, not just to this article but to all of them. You'll notice that if you visit the JDJ Web site (www.JavaDevelopersJournal.com) you're now able to share your comments on all the articles, and subscribers can even rate them on a scale of 1 to 3. Please take a moment to share your feedback on any articles that strike you one way or another. It's all a part of the opportunity for continuous learning.
Charles Arehart is a 20-year IT veteran with experience spanning a range of technologies,
including large scale database systems. For the past four years he's been an active trainer, writer, and consultant in enterprise Web application development. He contributes to several resources, provides on-site coaching and consultation, and is a frequent speaker at user groups throughout the country.