Servlets versus JSPs

JSPs can be used for most purposes, but there are some scenarios where Servlets are more appropriate. As well as components such as the "mediator" Servlets used earlier in this chapter, Servlets are well suited for handling binary data dynamically (for example, uploading files or creating dynamic images), since they need not contain any display logic.

Consider the following: a JSP needs to display a banner image based on who is referring the user to the site. This can be done by using the IMG tag like this:

<%@ page import="com.ibm.jspredbook.*;" errorPage="error.jsp" %>

</body>

</html>

The Servlet referenced in the IMG tag, ImgServlet, is coded as:

package com.ibm.projsp;

import javax.servlet.*;

import javax.servlet.http.*;

import java.util.*;

import java.io.*;

public class ImageServlet extends HttpServlet {

private String docHome = ".";

public void service(HttpServletRequest request,

HttpServletResponse response)

throws ServletException, IOException {

HttpSession session = request.getSession(true);

ServletConfig config = getServletConfig();

ServletContext application = config.getServletContext();

File file = findFile(request, response);

if (file == null) {

return;

} else {

response.setContentType(application.getMimeType(file.getName()));

response.setContentLength((int) file.length());

sendFile(file, response);

}

protected File findFile(HttpServletRequest request,

HttpServletResponse response) throws IOException {

// We should store a flow-to-image mapping and return the appropriate

// File, without any platform-specific paths. Right now we will just

// return a GIF file.

File file = new File("c://weblogic//images/myimage.gif");

return file;

}

protected void sendFile(File file, HttpServletResponse response)

throws IOException {

int c = 0;

FileInputStream fileinputstream = null;

try {

ServletOutputStream servletoutputstream =

response.getOutputStream();

fileinputstream = new FileInputStream(file);

while ((c = fileinputstream.read()) != -1) {

servletoutputstream.write(c);

}

servletoutputstream.flush();

}

finally {

if (fileinputstream != null) {

fileinputstream.close();

}

This image can be cached in memory and updated every minute or so as needed. Keeping the data in memory and using a servlet can save time and improve performance by not requiring access to the file system every time a request is made.

Summary

We have examined how we architect systems using JSPs, Servlets, and JavaBeans, discussed benefits and limitations of various approaches and actually seen an example that evolves to satisfy the constraints of the various architectures.

We discussed a variety of architectural patterns, each of which we categorized as either a Page-Centric or Dispatcher type of architecture. Page-Centric architectures have a JSP handling the request directly, while Dispatcher architectures include a Servlet that handles the request and delegates to a JSP.

The architectural patterns we examined are:

Page-View (Page-Centric)

Page-View with Bean (Page-Centric)

Mediator-View (Dispatcher)

Mediator-Composite View (Dispatcher)

Service-to-Workers (Dispatcher)

As we continue to investigate new ways to build our systems, we will continue to realize new architectural patterns. Additionally, the specifications for these technologies continue to be refined and improved in ways that will potentially demand modifications to current architectural patterns and the realization of additional ones. The ability (in the post-1.0 JSP specifications) to factor code and implementation details into a Custom Tag that might be used in place of a JavaBean is simply one example. The integration of these technologies more closely with XML and XSLT is another.

This is certainly an exciting and important area of technology that continues to change at a rapid pace. Hopefully, this information will help you better understand the current state of affairs with respect to JSP architectures, and thus feel better positioned to follow the evolution of these architectural issues in the future.