In an N-tier application, the server side of the architecture is broken up into multiple tiers, as illustrated in the next figure:

In this case, the application is composed of multiple tiers, where the middle tier, the JSP, interacts with the back end resources via another object or Enterprise JavaBeans component. The Enterprise JavaBeans server and the EJB provide managed access to resources, support transactions and access to underlying security mechanisms, thus addressing the resource sharing and performance issues of the 2-tier approach. This is the programming model supported by the Java 2 Enterprise Edition (J2EE) platform.

The first step in N-tiered application design should be identifying the correct objects and their interactions, in other words, object modeling. This is the part where class diagrams and tools like Rational Rose (http://www.rational.com) step in for architects. Quite often a line has to be drawn as to what objects need to be modeled: being over zealous can cause unnecessary complexity. If you get this part right, you're half way there!

The second part is identifying the JSPs or Servlets. As a rule of thumb, these should be divided into two categories, depending on the role they play, often called "web components" in the J2EE terminology

• Front end JSPs or Servlets that manage application flow and business logic evaluation. This is where a lot of method invocation on the objects, or usage of EJBs, can be coded. They are not responsible for any presentation, and act as a point to intercept the HTTP requests coming from the users. They provide a single entry point to an application, simplifying security management and making application state easier to maintain.
• Presentation JSPs that generate HTML (or even XML), with their main purpose in life being presentation of dynamic content. They contain only presentation and rendering logic.

The figure below shows the relationship between these two categories. The front-end component accepts a request, and then determines the appropriate presentation component to forward it to. The presentation component then processes the request and returns the response to another front component or directly back to the user:

Sometimes this distinction is hard to maintain, but the clearer the distinction, the cleaner the design.

These categories are analogous to the Model-View design pattern, where the front-end component is the model and the presentation component the view. This approach was referred to as the 'Model 2' programming model in earlier releases of the JSP specifications. It differs from Model 1 essentially in the location at which the bulk of the request processing is performed. The figure below shows the Model 2 approach:

In this approach, JSPs are used to generate the presentation layer, and either JSPs or Servlets to perform process-intensive tasks. The front-end component acts as the controller and is in charge of the request processing and the creation of any beans or objects used by the presentation JSP, as well as deciding, depending on the user's actions, which JSP to forward the request to. There is no processing logic within the presentation JSP itself; it is simply responsible for retrieving any objects or beans that may have been previously created by the Servlet, and extracting the dynamic content for insertion within static templates.

Instead of writing Servlets for the front-end components you can choose, if you wish, to use a JSP that contains only code and doesn't have any presentation responsibilities. Whichever option is used (and in this chapter we only use Servlets in this role), this approach typically results in the cleanest separation of presentation from content, leading to delineation of the roles and responsibilities of the developers and page designers, especially in complex applications.

Beans that are used by JSPs are not the same as Enterprise JavaBeans (EJBs), but are usually simple classes that serve as data wrappers to encapsulate information. They have simple get and set methods for each bean property .The properties further correspond by name to the HTML variables on the screen. This allows the bean properties to be set dynamically by the jsp:usebean tag without doing an individual request.getParameter(parametername) on the request object. See Chapter 4 for bean usage.

Continued...