JSP Application Models

The simple 2 tier model (accessing a database in the example above) describes the cgi bin replacement architecture that the Servlet model first enabled. This allows a JSP (or a Servlet) to directly access some external resource (such as a database or legacy application) to service a client's request. The advantage of such a scheme is that it is simple to program, and allows the page author to easily generate dynamic content based upon the request and state of the resource(s). However this architecture does not scale for a large number of simultaneous clients since each must establish/ or share (ad hoc) a (potentially scarce/expensive) connectionN-tier Application

to the resource(s) in question.

In this model the application is composed of (n>=3) tiers, where the middle tier, the JSP, interacts with the back end resources via an Enterprise JavaBeans component. The Enterprise JavaBeans server and the EJB provide managed access to resources thus addressing the performance issues. An EJB server will also support transactions and access to underlying security mechanisms to simplify programming. This is the progra mming model supported by the Java 2 Enterprise Edition WEE) platform.

Redircting Requests

It is common that the data to be sent to the client varies significantly depending on properties of the client that are either directly encoded in the request object or can be discovered based on some user/client profile (e.g. stored in a login database). In this case it is very convenient to have the initial JSP determine details about the request and then, if necessary, redirect the request to a different JSP.

This programming model is supported by the underlying ServIet APIs. The properties of the HTTP protocol are such that the redirect cannot be done if the response stream has started being sent back to the client; this characteristic makes the description of some common situations quite inconvenient. To address this, JSP 1.0 by default provides buffering on the output stream. The JSP code can redirect the request at any point before flushing the output buffer. Buffering is also very convenient for error page handling, since that is done by redirecting the request.

In both of the above cases, the page could also contain any valid Java code The JavaServer Pages architecture encourages separation of content from presentation it does not mandate it.

How to Choose between Access Models

With at least two access models, the question naturally arises "When does it make sense to have a JavaServer Page as the front end to a servIet, as the back end to a servIet, or use only the servIet? Here are some possible guidelines:

1 . If a graphical interface (GUI) is necessary to collect the request data use a JavaServer Pages file.

2. If the request and request parameters are otherwise available to the servlet, but the results of the servlet, processing requires a graphical interface to present them use a JavaServer Pages file.

3. If presentation layout is minimal (will not require very many printIn lines in your servlet, code) and you don't need to make that presentation logic available to a customer or your webpage designer, then a Servlet might suffice.

Domain Name Search