JSP.1.6 Application Model

JSP pages can be used in combination with servlets, HTTP, HTML, XML, applets, JavaBeans components, and Enterprise JavaBeans components , to implement a broad variety of application architecture(s) or models.

JSP.1.6.1 Simple 2 ^1/2 - Tier Application

The simple 2-tier model (accessing a database in Figure JSP.1-3) 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) connection to the resource(s) in question.

Figure JSP.1-3. 2-Tier DataAccess Model

JSP.1.6.2 N-Tier Application

In this model (Figure JSP.1-4) 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 programming model supported by the Java 2 Platform Enterprise Edition (J2EE).

Figure JSP.1-4. Multi-Tier DataAccess Model

JSP.1.6.3 Loosely Coupled Applications

In this model (Figure JSP.1-5) we have two loosely coupled applications (either on the same Intranet or over an Extranet or the Internet). These applications may be peers, or act as client or server for the other. A common example of this is supply chain applications between vendor enterprises . In such situations it is important that each participant be isolated from changes in the implementation of its dependents. In order to achieve this loose coupling the applications do not communicate using a fine grain imperative interface contract like those provided for by RMI/IIOP or Java IDL. The applications communicate with each other via HTTP, using either HTML or XML to/from a JSP page.

Figure JSP.1-5. Loosely Coupled Application Model

JSP.1.6.4 Using XML with JSP Technology

The JavaServer Pages technology is an ideal way to describe processing of XML input and output (Figure JSP.1-6). Simple XML generation can be done by just writing the XML as static template portions within the JSP page. Dynamic generation will be done through JavaBeans components, Enterprise JavaBeans components, or via custom actions that generate XML. Similarly, input XML can be received from POST or QUERY arguments and then sent directly to JavaBeans components, Enterprise JavaBeans components, or custom actions or manipulated via the scripting.

Figure JSP.1-6. XML Input/Output Model

There are two attributes of the JSP technology that make it specially suited for describing XML processing. One is that XML fragments can be described directly in the JSP page either as templates for input into some XML-consuming component or as templates for output to be extended with some other XML fragments . Another attribute is that the tag extension mechanism enables the creation of specific actions and directives that are targeted at useful XML manipulation operations.

Future versions of the JSP specification may include several standard actions that will support XML manipulation, including the transformation of the XML produced by the given JSP page using XTL/XSL.

JSP.1.6.5 Redirecting 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 page determine details about the request, perhaps create and/or update some server-side objects, and then, if necessary, redirect the request to a different JSP page.

This programming model (Figure JSP.1-7) is supported by the underlying servlet 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, the JSP specification by default indicates buffering on the output stream. The JSP page can redirect the request at any point before flushing the output buffer.

Figure JSP.1-7. Request Redirection Model

Buffering is also very convenient for error page handling, since that is done by redirecting the request.

JSP.1.6.5.1 Presentation JSP Pages and Front JSP Pages

In a slight variation of this model, the front component (a servlet or a JSP) only creates and/or updates the server-side objects. In this organization, the front component does no presentation at all; instead all presentation is done by a presentation component. Although the front component could be written as a servlet since it does no presentation, writing it as a JSP page enables the use of custom actions for the creation and update of the server-side objects. The presentation component will in almost all cases be a JSP page, and it will most likely access the server-side objects through custom actions. ^[1]

^[1] Readers of the original JSP 0.92 draft will recognize the combination " front component is servlet and presentation component is JSP " as the model 2 mentioned in that draft.

JSP.1.6.6 Including Requests

Another useful application model (Figure JSP.1-8) involves request includes. In this model, the request reaches an initial JSP page. The page may start generating/composing some result but at some point it may want to dynamically include the contents of some other page. These contents may be static but may also be dynamically generated by some other JSP page, servlet class, or some legacy mechanism like ASP.

Figure JSP.1-8. Request Inclusion Model

Although in some cases this inclusion model is applicable to presentation-dependent contents, it is most often used in the context of a presentation-independent content, as when the data generated is actually XML (which may be converted later into some other format using, say, XSL).