HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

The philosophy behind the Java 2 Enterprise Edition (J2EE) announced at JavaOne in June 1999 is to package the Java 2 platform with a collection of "Enterprise APIs," including Servlet and Java Server Pages (JSP), and an application programming model to define a standard platform upon which enterprise applications can be built. The first public release of the J2EE specification became available in October 1999, and a final draft is expected this month (see http://java.sun.com/j2ee/).

J2EE is a broad specification that covers many of the elements used in building multitier Web-based applications. The end-user-facing tier of a multitier application is the presentation layer. The Servlet and JSP specifications describe a standard methodology for building dynamic HTML or XML pages. Other J2EE technologies, such as JDBC and EJB, describe standard mechanisms for accessing data and business logic. Since the announcement of J2EE, the Servlet specification has been revised once (the current version is Servlet 2.1) and another version is in the process of being reviewed. (Servlet 2.2 is currently available for public review at http://java.sun. com/products/servlet/.)

The broad enterprise application view taken by J2EE has driven extensions and enhancements to the Servlet and JSP specifications. The most important of these is the introduction of the "Web Application" concept, which recognizes that it's necessary but not sufficient to describe how a single servlet should operate. It's also important to describe how all components of an overall application relate to each other.

A typical Web application comprises a collection of static content (e.g., HTML pages, sounds and images) and a collection of dynamically generated pages and images.

A Web application also requires management of security, state information in various scopes (e.g., application-wide, per-client session and per servlet) and the isolation of applications and their resources from each other within a server. By taking this broad view of an application, the Servlet 2.2 specification provides a complete programming model for dynamic-content elements within the context of an entire application.

Java Server Pages are a complement to servlets. The goal of JSP is to separate the visual aspects of a Web page from the programmatic aspects. A Web-page designer can focus on laying out the most beautiful HTML and simply use custom HTML tags to identify the areas of dynamic content. At the same time, a professional Java programmer can write the actual code and business logic that's executed to provide the dynamic content to the page. The current version of the JSP specification is 1.0, and a public draft for the 1.1 specification is now available. The remainder of this article will focus on the Web application model as introduced in Servlet 2.2. For more information on JSP see http://java.sun.com/products/jsp/.

Web Application Development
From the developer's point of view, a Web application consists of the following components:

  • Servlets and JSPs for generating dynamic content
  • Utility Java classes used by servlets and JSPs
  • Static documents (HTML pages, images, sounds, etc.) that may be directly URL-accessible and served directly by the Web server (alternatively, these documents may be accessed as part of a servlet's dynamic processing)
  • Client-side Java applets, JavaBeans and utility classes (not discussed in this article)
  • An XML application descriptor file

These components are packaged in an archive file called a .WAR file (Web Archive).

Web Application Deployment
A Web application (packaged in its .WAR file) is deployed to a "Web Container," available in many Web server products as well as in all J2EE-based Web Application Servers. The Web container provides the environment in which a servlet operates. Upon deployment it's responsible for appropriately adding the contents of the .WAR file to the URL space of its HTTP server.

The XML descriptor file contains the configuration and deployment information that makes this possible. The descriptor file includes information for design tools, deployment tools and details used at runtime by the Web container, including security information.

Consistent with the EJB specification, a Web application can define a set of logical security roles that are enumerated as part of the descriptor file. They're used to control access to any of the servlets in the application as well as any of the static resources. In addition, a servlet may dynamically check on whether the current user is in a particular role.

When the Web application is being deployed, the roles defined in the application must be mapped to actual users and groups.

URL Mapping
The descriptor file enumerates the servlets that are part of the application. For each servlet there's a mapping from one or more URL patterns to that servlet. For example, the following excerpt defines a servlet named "catalog" and the fully qualified name of the class that should be loaded. All other references to the servlet use the name.


The following excerpt specifies that for the servlet named catalog any request to a URL that begins with "/catalog/" should be delivered to this servlet. In other words, the servlet is written to make /catalog appear to be a directory hierarchy.


Web Application Runtime
The Web container is responsible for managing the runtime behavior of the components of the Web application (see Figure 1). The servlet API defines the contract between the Web container and the servlet objects that are deployed in it. The Web container must:

  • Provide an application-wide context object
  • Map URL requests within its root URL space according to the application descriptor information
  • Create and manage client sessions
  • Directly deliver URL-accessible static content
  • Invoke servlets to deliver dynamic content

Figure 1
Figure 1:

To represent the running Web application, the servlet container creates an instance of javax.servlet.ServletContext. This ServletContext object, available to each servlet within the application, provides three functions.

  1. It gives a servlet access to other resources (HTML pages, images, etc.) within the application's .WAR file via the getResource and getResourceAsStream methods.
  2. It's the manager of application-wide state information via the get/setAttribute methods.
  3. It's a factory for javax.servlet.RequestDispatcher objects. The RequestDispatcher is used by one servlet to invoke another servlet from within the same application. This allows a servlet to delegate its processing to a different servlet (forwarding) or to ask another servlet to provide a piece of the response (inclusion).
To represent a client HTTP session, the Web container creates an instance of javax.servlet.http.HttpSession. This object is used by a servlet to store state information that's per-client. The Servlet specification doesn't explain how a Web container should identify a session. Two common mechanisms are used for session identification: cookie-based and URL rewriting (cookieless). In addition, HTTP over SSL (HTTPS protocol) is inherently session based. In the case of an HTTPS session, the Web container makes the X509 certificate information available as a Request attribute.

A servlet is a Java class that implements the javax.servlet.Servlet interface. The purpose of a servlet is to generate dynamic content. It interacts with clients using a Web-style request-response mechanism based on the behavior of the HTTP protocol. (Note: The Servlet specification is protocol independent, but at least the HTTP protocol is required. For the purposes of this article, HTTP will be assumed.) At runtime a JSP behaves exactly like a servlet. In fact, most JSP hosts precompile a JSP into a compiled servlet. Throughout this article, wherever the term servlet is used, the phrase servlet or JSP can be substituted.

When a servlet is selected to process a request, its "service" method is invoked by the RequestDispatcher. The service method accepts two parameters: a Request object and a Response object. The servlet uses the information provided in the Request object and the ServletContext to determine what dynamic content is to be generated.

When a client request received by the server requests a servlet, an instance of the servlet is passed an object that implements the javax.servlet.ServletRequest interface. For HTTP-based clients, the object must implement javax.servlet.http.HttpServletRequest. The Request object provides all the information delivered from the HTTP client including parameters, headers, path elements and attributes.

Request parameters are obtained from the request query string (following the "?") and from HTML form data (in the case of an HTTP POST). Parameter information is provided by the end user or the application itself. For example, the request string www.mysite.com/ here/there/now.html?a=10&b=no-way specifies two request parameters with the names "a" and "b" and corresponding values of "10" and "no-way."

Request headers, a standard part of the HTTP and other Internet protocols, are generated by the HTTP client program or user agent, usually a browser or client-side Java program. An example of a request header is "User-Agent." The value of this header for Netscape Navigator 4.5 is "Mozilla/4.6 [en] (WinNT; I)". To properly use request headers, the programmer must have a working knowledge of the HTTP 1.1 protocol.

Request-path elements are pieces of the entire request path broken down functionally (from left to right) into three parts. First is the "Context Path," which is the path to the root URL of the Web application. Second is the path from the root URL of the Web application to the servlet itself. (Mapping of URLs to servlets is defined by the application descriptor file.) The third part of the path is the "Extra Path Info" that's interpreted by the servlet.

For example, a .WAR file is deployed as follows:

  • Application root: "/here"
  • The application descriptor maps the path "/there/fancy.blah" to the servlet "MyServlet"
A request for "/here/there/fancy.blah/ more/and/more" then delivers to "MyServlet" the following three path elements:
  1. Context path: "/here"
  2. Servlet path: "/there/fancy.blah"
  3. Extra path: "/more/and/more"
Attributes are information represented as name-value pairs and are internal to the application. A typical use for Request attributes is to pass parameters from one servlet to another when a request is being forwarded.

The response object, which implements the javax.servlet.ServletResponse interface, is used to encapsulate all information to be returned to the client. The Request object allows the servlet to set the return status (e.g., 200 OK, 404 Not Found, 304 Not Modified, etc.), response headers and the actual content (HTML, text, image, etc.).

New in Servlet 2.2, the Response object has additional methods that enable the servlet to control buffering of the response. This enhancement will greatly improve performance and reduce heap usage by enabling a servlet to indicate that it knows the size of its content and doesn't need any buffering.

Servlet Request Processing
The real work of a servlet, of course, is to process a client request and generate dynamic content. The servlet specification includes three features that enable a flexible component-based implementation of an application.

A servlet may forward-process a request to another servlet. This capability can be accomplished using HTTP redirection, but forwarding is much more efficient because the network round-trip is avoided and Java objects may be passed between the servlets as Request attributes (avoiding the need to encode complex state information).

A useful application of forwarding is to report errors detected during servlet processing.

A servlet may include the generated output of another servlet. This is useful for common design elements like navigation bars or for encapsulating the complex generation of table-based results that may be displayed in many page contexts.

Error Handling
Good error handling and reporting are important to building a user-friendly application. A Web application has an error-handling page that's invoked when an uncaught exception is thrown during servlet processing. This page ensures that the Web container will recover gracefully from unexpected application errors. The Web container provides an error-handling page by default, but the application can specify error pages to handle specific HTTP errors or Java exceptions.

In this article we've provided an overview of the Web application architecture as introduced by the upcoming Servlet 2.2 specification. Driven by J2EE, the Servlet and JSP-based Web application is literally the tip of the iceberg in building an enterprise application. It's the part you see, but there's much more underneath that's seamlessly integrated. The rest of the J2EE technologies, such as JDBC, JTA, JMS, EJB and JavaMail, are the workhorses that provide the dynamic data and business processes that a Web application presents to the user. The Servlet 2.2 specification is a giant step in the creation of a well-integrated, top-to-bottom platform for building enterprise applications.

Author Bio
Arny Epstein, chief technology officer and a cofounder of SilverStream, holds a Ph.D. in astrophysics from MIT. While at the Harvard-Smithsonian Center for Astrophysics, Arny contributed to the creation of data-analysis techniques in the field of experimental X-ray astronomy.
He can be reached at: [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.