Separating presentation and logic when building server-side Web-based applications allows you to generate Web pages with dynamic content easier and faster. It also enables Web designers who aren't especially experienced in application development to easily change the appearance of a Web page. For Web sites with information content that needs to change frequently, this advantage means that the update cycle can occur much more rapidly...thus bringing new information to Web site visitors faster.

Early Web-based applications were simple and usually contained both presentation and business logic, which created maintenance problems when changes occurred to either. Separating the two simplifies maintenance and allows faster and easier updates. This article will discuss two underlying technologies that can be used for presentation and logic separation: Java Servlets and JavaServer Pages (JSP). A simple application architecture in the context of a small demonstration will show you how to achieve this separation and deploy and change Web applications faster.

As the first step let me give a brief overview of Java Servlets and JSP - and of how they work together in a Web application architecture.

What's a Servlet?
Servlets are platform-independent 100% Pure Java server-side modules that fit seamlessly into the framework of an application server. They can be used to extend the capabilities of the server in a variety of ways with minimal overhead, maintenance and support. Because servlets are Java bytecode that can be downloaded or shipped across the network, they are truly "Write Once, Run Anywhere." Unlike CGI scripts, servlets involve no platform-specific consideration or modifications: they're Java application components that are downloaded, on demand, to the part of the system that needs them.

What's a JavaServer Page?
JSP is the Java platform technology for building applications containing dynamic Web content such as HTML, DHTML or XML. A JSP page is a text-based document containing static HTML and dynamic actions that describe how to process a response to the client. At development time, JSPs are very different from servlets. However, they are precompiled into servlets at runtime and executed by a JSP engine ,which is installed on a Web-enabled application server such as WebSphere V3.0.

Servlets and JSP Working Together
It's possible for a servlet to take an HTTP request from a Web browser, generate the request dynamically (possibly querying back-end systems to fulfill the request) and then send a response containing an HTML or XML document to the browser.

The drawback of this approach is that the creation of the page must be handled in the Java Servlet, which means that if Web page designers wanted to change the appearance of the page, they'd have to edit and recompile the servlet. With this approach, generating pages with dynamic content still requires some application development experience. Clearly the servlet request-handling logic needs to be separated from the page presentation.

The solution is to adopt the Model-View-Controller (MVC) paradigm for building user interfaces. With MVC, the back-end system is your Model, the templates for creating the look and feel of the response is the View and the code that glues it all together is the Controller. JSPs fit perfectly into this solution as a way of creating a dynamic response or View. Servlets containing logic for managing requests act as the Controller, while your existing business rules are the Model.

Let's look at a small demo application that utilizes the proposed MVC paradigm for presentation and logic separation. The demo provides browser-based access to a 3270 back-end system.

The architecture of the demo application follows the MVC design (see Figure 1).

A browser using HTML and JSP pages provides the View. A set of Java Servlets and JSPs in an application server provide the Control, while the backend CICS or PeerLogic applications provide the business rules or the Model. The flow between these servlets, HTML and JSP pages is shown in Figure 2 and described in the text that follows. (The source code for the Login Servlet and Login JSP files can be found on the JDJ Web site at www.javadevelopersjournal.com.)

Demo Application Flow Explained
The Request
The user will typically start with a page of HTML running within a browser. This page will be served from a Web-enabled application server. The application server serves files the same way a standard Web server such as Apache does. This page is an entry point into the Web application. It uses the HTML FORM tag to access the servlet, in our case, LoginServlet. Additional parameters can also be sent to the servlet within the bounds of the FORM action. An example of this would be as follows:

<FORM action="http://localhost:8080/servlet/LoginServlet" method="GET">
<input type="text" size="30" name="firstname">
<input type="text" size="30" name="surname">
.
.
<input type=hidden name=host value="localhost">
<input type=hidden name=port value="9876">
<input type=submit value=" Submit ">
</FORM>

The request will most likely be made using the HTTP or securely using HTTPS. This incoming request is then handled by the servlet, which uses the HttpServletRequest, getParameter() method to gain access to the FORM variables (see Listing 1).

The servlet then tests to see if the user has a session. A session is used to associate a set of unique requests from a remote client; this is necessary due to the stateless nature of the HTTP protocol.

A session is created as follows:

HttpSession session = req.getSession(true);

Objects can then be added to the session:

session.putValue("host", hostToConnectTo);
session.putValue("port", tmpPort);
}
}

Back to our example. The following code instantiates a new class of the type CICSEmulator called newEmulator. This is a vendor-supplied class from PeerLogic, Inc. CICSEmulator is a 3270 terminal emulator that exposes a set of methods for direct emulator manipulation. The newEmulator can be passed variables from the session, and in this case connected to the host and port of the remote system.

CICSEmulator newEmulator = new CICSEmulator();
newEmulator.setTN3270Port(portToConnectTo);
newEmulator.setTN3270Host(hostToConnectTo);

The second class instantiated is a JavaBean called AcctDetails. This bean was created using the LiveContent PATH 3270 tool from PeerLogic, Inc. AcctDetails is a data access bean; it performs the actual navigation and data retrieval from the back-end 3270 system. AcctDetails assigns the newEmulator class to be its 3270 terminal, then passes the input variables, surname and firstname to its set methods.

AcctDetails getAccountDetails = new AcctDetails();
getAccountDetails.set3270Emulator(newEmulator);

getAccountDetails.setSurname(inputsurname);
getAccountDetails.setFirstName(inputfirstname);

try {
getAccountDetails.performWork();
session.putValue("resultsBean", getAccountDetails);
}

catch ( IllegalStateException e ) {
// handle the error
}

Passing Control to the JSP
As mentioned, an important part of the Model-View-Controller approach is that presentation be kept separate from business logic. As you've seen, the servlet is responsible for processing the request using the data access beans. The data access bean, getAccountDetails, contains server-side logic for accessing and retrieving data from the back-end system. The back-end system itself (or the Model), contains all of the business rules. The response (or View) the user sees is created using JSP technology. JSPs are dynamic HTML pages containing small pieces of embedded Java code.

The servlet passes both the request and response objects to the JSP using the following syntax:

getServletContext().getRequestDispatcher("/jspDemo/login.jsp").forward(req, res);

The forward method allows the servlet to pass the processing of the response to another resource. Its request and response parameters must be the same objects that were passed to the calling servlet's service method.

It uses the RequestDispatcher object obtained via getRequestDispatcher() to determine the path to the JSP target resource. The pathname to the JSP must begin with a "/" and is interpreted as relative to the current context root.

Accessing the Results Bean
The JSP is responsible for creating the response for the user, which it does by gaining access to the getAccountDetails bean data (referred to by the resultsBean ID). This is done using the following syntax within the HTML page:

<HTML>
<BODY>
.
.
<jsp:useBean id="resultsBean" scope="session" class="acct.AcctDetails " />
<jsp:setProperty name="resultsBean" property="*"/>

The <jsp:useBean> action tries to find an existing object (in this case the resultsBean) using the ID and scope. In our example, we placed the getAccountDetails bean into the session and named it resultsBean. The action will therefore get the resultsBean from the user's session. Once this is done, the JSP can access any of the resultBean's get methods that gain access to its data. This is done using the following JSP syntax:

<%= resultsBean.getDetails_Title() %>
<%= resultsBean.getDetails_Initial() %>

This syntax is an example of a JSP expression. Anything between the <%= and %> markers is evaluated by the JSP engine, with the results sent as output to the JSP file. The two expressions above will execute the ResultsBean get methods for displaying the user's title and middle initial - exciting stuff! JSP code can be embedded throughout an HTML page the same way a scripting language such as JavaScript would. JSP syntax is relatively simple to understand. This means that the JSPs can be maintained by Web page designers rather than by the application programmers, who are responsible for the servlets and data access beans. Changes can be made to a JSP without affecting the servlet and vice versa.

The Response
The JSP is dynamically compiled into a Java Servlet at request time and cached by the application server. The advantage of this is that any subsequent request will be extremely quick. The response the user receives is basically an HTML page (with a .jsp extension) that contains dynamically generated content.

Summary
In the demo architecture I've described in this article, the client makes a request from a Web browser directly to a servlet, which then processes the request by using data access JavaBeans to retrieve data from the backend system. The servlet wraps the results into a results bean, places it into the session, then invokes a JSP to handle the response. The servlet is in complete control of the initiated request up to the time the response is generated.

It's up to the called JSP to generate the content needed for the response to the user. The JSP should include only logic that's needed for formatting the presentation. The advantage of this type of separation is that it creates more reusable, portable platform-independent components that can be shared between applications and implemented as part of a larger application.

Separating the actual development of the servlet logic and JSP presentation means that Web page designers and application developers can work independently of each other. This development approach conforms to the MVC paradigm that was outlined in the beginning of this document.