Presentation Layer - How to be a Successful Technical Architect for J2EE Applications

Presentation Layer

The presentation layer is the section of the application responsible for everything end users physically see in the user interface. Various deployment wrappers provide functionality to the presentation layer.

J2EE developments support HTML/Javascript interfaces and applet interfaces. Most applications provide HTML. J2EE applications produce HTML interfaces by using a combination of static HTML pages and dynamically generated content via servlets and JSPs. There are several good texts for servlets and JSPs (e.g., see Hall, 2000; Hunter and Crawford, 2001). Applets can be used for applications that require advanced controls (actions on mouse-overs, drag-drops, sophisticated interactive display controls, etc.).

The presentation layer uses deployment wrappers exclusively. The reason is that the presentation might not execute on the same host as the business logic and will require distributed services. Although it is technically possible to run the servlet engine on the same host as the J2EE container, some organizations prefer not to.

Most organizations use a variant of the model-view-controller (MVC) pattern for the presentation layer. The MVC pattern is a natural choice for Java because Swing uses the MVC pattern as well. The MVC pattern consists of three parts: (1) the model tracks session state and relevant session information, (2) the controller interprets all URLs and directs changes to the appropriate model if necessary, and (3) the view presents information in the model. In a J2EE world, typically the model is a combination of deployment wrappers (enterprise beans, Web services, and RMI services), the controller is a servlet, and the view is a JSP.

The most popular implementation of the MVC pattern designed specifically for J2EE platform user interfaces is Struts. An open source product from the Apache Jakarta project (http://jakarta.apache.org/struts/), Struts provides a generic, configurable servlet controller that supports J2EE viewers and models. Figure 5.10 is a diagram of the basic parts of Struts and how it fits the MVC pattern.

Figure 5.10: MVC Pattern as It Appears in Struts

The classes depicted in the figure (plus an XML configuration file) are the basics needed to implement Struts. Although Struts has many more classes, a major focus of this book is to shorten the learning curve for new architects, so I stick to the basics. Readers desiring a more in-depth knowledge of Struts should see Spielman (2003).

In a Struts world, there are several components that the developer provides. First, a developer-provided XML configuration file (struts-config.xml) tells the ActionServlet which Action to invoke and which JSP to forward to based on parameters in the URL. The ActionServlet class from Struts is serving as the controller for the MVC pattern, and JSPs serve as a view. You will read more about the configuration format and features available for Struts in chapter 14.

Second, the developer optionally provides extensions of ActionForm to validate user input. If errors are found, Struts navigates the user back to the URL specified in the configuration file. Your JSPs are responsible for figuring out if there are errors to display and physically displaying error messages.

By the way, the Struts ActionForm is also intended as a mechanism to collect user-entered data from a Web page. Use of this feature is optional. If you do use it, any page that has user entry will require an ActionForm. This is a Struts feature I rarely use.

Third, developer-provided extensions of Action can call objects in the deployment layer, such as enterprise beans, Web services, RMI services, and so on. Calls to the deployment layer initiate some type of process within your application or retrieve data to be displayed to the user. The displayed data are put on the session (just as in a custom servlet). Your JSPs will retrieve any information needed for display from the session.

Fourth, the developer provides JSPs and/or static HTML pages to display to the user. The ActionServlet forwards the request after the Action has completed. Don't worry, Struts does provide a way to dynamically change the forward.

Struts has the advantage of giving you controller functionality you would otherwise have to build, and it's popular, which means many developers already know it. Its chief disadvantage is that it's complex and not the easiest creature to debug when problems arise. Despite its complexity, I usually opt for using it. I'll provide a cheat sheet for getting up to speed on Struts in chapter 14.