Breaking up J2EE: Use just the tools you need to get the job done

By incorporating several programming approaches in its Model-View-Controller pattern, Java 2 Enterprise Edition (J2EE) enables component-based development for highly complex and scalable Internet-based applications. The different areas of the hierarchy serve various needs: Some developers work in the Model level with Enterprise JavaBeans; others center on the View level, utilizing Java Server Pages; and still others concentrate on the Controller level using Java Servlets. But all this complexity can be a little overwhelming and can actually impede development efforts. The multiple layers sometimes make the J2EE appear monolithic, an insurmountable collection of technology. Learning about the idiosyncrasies of the various tiers takes time, and J2EE projects can stress the skill resources of smaller development teams. Fully understanding the architecture and implementation of an existing J2EE application sharpens the learning curve, especially considering time constraints on the development cycle. As a result, the temptation for technical teams to shun a "proper" J2EE implementation exists, likely causing problems with further development or maintenance.

To avoid these issues, developers can separate the J2EE technologies, which will allow them to better harness their skills and concentrate on the task at hand.

Just JSP
The first—and possibly easiest—separation and use of a J2EE technology exists in Java Server Pages (JSP). With JSP, developers create presentation with HTML and functionality with scriptlets, JavaBeans, or custom tags. Suggesting this combination seems anathema to a purist; the J2EE doctrine states that logic and display layers of an application should never mix.

Sometimes, however, having a sense of scope benefits a project developed using only JSP. Arguments advocating the separation of presentation from functionality bear weight, especially if a single JSP extends more than two printed pages. But smaller, pure JSP projects work well. By keeping the effort modest, coding tasks like a simple clock (see Listing A) become easy.

This example illustrates several points. The code provides a user interface (albeit very basic), accepts user input, and responds dynamically—all essential elements of an Internet application, contained in a mere 33 lines including comments. Achieving a more useful implementation of a JSP clock requires even less code:

<%
Date d = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("d MMMM yyyy, h:mm:ss a");
TimeZone zone = TimeZone.getDefault();
sdf.setTimeZone( zone );
%>
Current date and time in the <b><%= zone.getID() %></b> time zone: <b><%= sdf.format( d ) %></b>

Here's another advantage to developing JSP-only projects: ease of learning and of use. JSP uses the same syntax as Java, but in a context that suggests other server-side development environments—Active Server Pages or ColdFusion, for instance. The benefit of this comes from the small leap in skill sets to use JSP technology.

Simply servlets
Developing applications with just Java servlets is another way of dissecting the J2EE model. In fact, servlets have their own track record. Many people don't realize that, a few years ago, servlets embodied the only choice for server-side Java. A straightforward API combined with CGI-like qualities made for relatively short development cycles. The ability to maximize server efficiency with in-process memory management won over both developers and system administrators. Enhancing functionality by chaining servlets together added to their benefits. The same advantages make servlets an appealing development platform today. Integrate other Java technologies, like a data source via JDBC, and a robust solution for small to medium-size projects emerges.

Traditionalists may balk at including a data connection within a servlet; according to J2EE, such intricacies should reside in Enterprise Java Beans (EJB). While this is true for an extensive project, a simple servlet displaying an image that reports product availability, such as the skeleton example shown in Listing B, does not need the additional overhead. Although the example accesses a database and creates a graphic dynamically, use of database connection pooling and developer-designed resource management gives this servlet speed and stability. A full J2EE implementation for the same result becomes computationally costly.

A non-Web-browser application would use servlets to its advantage. Servlet containers like Tomcat allow low-cost—or in this case, free—arenas in which to build and deploy the latest wireless information platform. Servlets that output XML and apply style sheets on the fly ensure that users receive the proper format on their mobile phones or pagers.

Elemental EJB
Considered the programmatic parallel of business logic in a J2EE application, EJB contain the most complexity. On the surface, EJB represent either database-stored information with entity beans or service requests with session beans. This simplification cloaks the numerous aspects requiring detailed investigation; the steep learning curve causes projects developed with EJB to proceed slowly. Developers must take into account the peculiarities of their chosen EJB container. Additionally, small code changes or debugging attempts often turn into Herculean tasks.

EJB work well, however, when dealing with larger projects. The memory management, threading model, and transactional capability of a J2EE-certified EJB container allows developers to devote more time to mapping business processes with code. Most EJB containers allow simple modification of compiled code behavior via XML documents. Tools exist that generate Java source code for EJB from UML diagrams, easing the transition from concept to implementation.

When using EJB alone, the choice of client environment changes. Browsers will not work, since out of the J2EE context, EJB allow no direct method of Web-based communication. Creation of alternative clients must occur: applications, both Java and non-Java; enterprise information systems; even other EJB. A project deployed in a controlled environment—one that facilitates updating client applications, like a company intranet—serves as the best situation for isolated EJB use.

Conclusion
Employed together, the technologies packaged in the J2EE specification constitute a powerful toolkit. While using such tools for large projects makes sense, some situations call for less complicated tactics. By analyzing scope, resources, and timelines, developers can find opportunities for streamlining certain projects through the segmentation of J2EE.