Web applications are an important part of the Java 2 Enterprise Edition (J2EE) platform because the Web components are responsible for key client-facing presentation and business logic. A poorly designed Web application will ruin the best business-tier com-ponents and services. In this chapter, we will review key Web application concepts and technologies and their use in WebLogic Server, and we will provide a number of recommendations and best practices related to Web application design and construction in WebLogic Server.

 This chapter also provides the foundation for the discussion of recommended Web application architectures in Chapter 2 and the construction and deployment of a com-plex, realistic Web application in Chapters 3, 4, and 5.

Java Servlets and JSP Key Concepts
In this section we will review some key concepts related to Java Servlets and JavaServer Pages. If you are unfamiliar with these technologies, or if you need addi-tional background material, you should read one of the many fine books available on the subject. Suggestions include Java Servlet Programming Bible by Suresh Rajagopalan et. al. (John Wiley & Sons, 2002), Java Servlet Programming by Jason Hunter (O'Reilly & Associates, 2001), and Core Servlets and JavaServer Pages by Marty Hall (Prentice Hall PTR, 2000).

Characteristics of Servlets
Java servlets are fundamental J2EE platform components that provide a request/response interface for both Web requests and other requests such as XML messages or file transfer functions. In this section, we will review the characteristics of Java servlets as background for a comparison of servlets with JavaServer Pages (JSP) technology and the presentation of best practices later in the chapter.

Servlets Use the Request/Response Model
Java servlets are a request/response mechanism: a programming construct designed to respond to a particular request with a dynamic response generated by the servlet's specific Java implementation. Servlets may be used for many types of request/response scenarios, but they are most often employed in the creation of HyperText Transfer Pro-tocol (HTTP) responses in a Web application. In this role, servlets replace other HTTP request/response mechanisms such as Common Gateway Interface (CGI) scripts.

The simple request/response model becomes a little more complex once you add chaining and filtering capabilities to the servlet specification. Servlets may now partic-ipate in the overall request/response scenario in additional ways, either by preprocessing the request and passing it on to another servlet to create the response or by postprocessing the response before returning it to the client. Later in this chapter, we'll discuss servlet filtering as a mechanism for adding auditing, logging, and debugging logic to your Web application.

Servlets Are Pure Java Classes
Simply stated, a Java servlet is a pure Java class that implements the javax.servlet .Servlet interface. The application server creates an instance of the servlet class and uses it to handle incoming requests. The Servlet interface defines the set of methods that should be implemented to allow the application server to manage the servlet life cycle (discussed later in this chapter) and pass requests to the servlet instance for processing. Servlets intended for use as HTTP request/response mechanisms normally extend the javax.servlet.http.HttpServlet class, although they may implement and use the Servlet interface methods if desired. The HttpServlet class implements the Servlet interface and implements the init(), destroy(), and service() methods in a default manner. For example, the service() method in HttpServlet interrogates the incoming HttpServletRequest object and for-wards the request to a series of individual methods defined in the HttpServlet class based on the type of request. These methods include the following:
-doGet() for handling GET, conditional GET, and HEAD requests - doPost() for POST requests
-doPut() for PUT requests
-doDelete() for DELETE requests
-doOptions() for OPTIONS requests - doTrace() for TRACE requests

The doGet(), doPost(), doPut(), and doDelete() methods in HttpServlet return a BAD_REQUEST (400) error as their default response. Servlets that extend HttpServlet typically override and implement one or more of these methods to gen-erate the desired response. The doOptions() and doTrace() methods are typically not overridden in the servlet. Their implementations in the HttpServlet class are designed to generate the proper response, and they are usually sufficient.

A minimal HTTP servlet capable of responding to a GET request requires nothing more than extending the HttpServlet class and implementing the doGet() method.

WebLogic Server provides a number of useful sample servlets showing the basic approach for creating HTTP servlets. These sample servlets are located in the samples/server/examples/src/examples/servlets subdirectory beneath the WebLogic Server home directory, a directory we refer to as $WL_HOME throughout the rest of the book. We will examine some additional example servlets in detail during the course of this chapter. These example servlets are available on the companion Web site for this book at www.wiley.com/compbooks/masteringweblogic.

Creating the HTML output within the servlet's service() or doXXX() method is very tedious. This deficiency was addressed in the J2EE specification by introducing a scripting technology, JavaServer Pages (JSP), discussed later in this chapter.

Servlets Have a Life Cycle
A servlet is an instance of the servlet class and has a life cycle similar to that of any other Java object. When the servlet is first required to process a request, the application server loads the servlet class, creates an instance of the class, initializes the instance, calls the servlet's init() method, and calls the service() method to process the request. In normal servlet operation, this same instance of the servlet class will be used for all subsequent requests.

Servlets may be preloaded during WebLogic Server startup by including the <load-on-startup> element in the web.xml file for the Web application. You can also pro-vide initialization parameters in this file using <init-param> elements. WebLogic Server will preload and call init() on the servlet during startup, passing the specified initialization parameters to the init() method in the ServletConfig object.

An existing servlet instance is destroyed when the application server shuts down or intends to reload the servlet class and create a new instance. The server calls the destroy() method on the servlet prior to removing the servlet instance and unload-ing the class. This allows the servlet to clean up any resources it may have opened dur-ing initialization or operation.

Servlets Allow Multiple Parallel Requests
Servlets are normally configured to allow multiple requests to be processed simultane-ously by a single servlet instance. In other words, the servlet's methods must be thread-safe. You must take care to avoid using class- or instance-level variables unless access is made thread-safe through synchronization logic. Typically, all variables and objects required to process the request are created within the service() or doXXX() method itself, making them local to the specific thread and request being processed.

BEST PRACTICE: Servlets that allow multiple parallel requests must be thread-safe. Do not share class- or instance-level variables unless synchronization logic provides thread safety.

Servlets may be configured to disallow multiple parallel requests by defining the servlet class as implementing the SingleThreadModel interface:

...
public class TrivialSingleThreadServlet
extends HttpServlet implements SingleThreadModel
{
public void init(ServletConfig config) throws ServletException
{
super.init(config); System.out.println("Here!");
}
...

This simple change informs the application server that it may not process multiple requests through the same servlet instance simultaneously. The application server can honor this restriction in multiple ways: It may block and queue up requests for pro-cessing through a single instance, or it may create multiple servlet instances as needed to fulfill parallel requests. The servlet specification does not dictate how application servers should avoid parallel processing in the same instance.

WebLogic Server satisfies the single-threaded requirement by creating a small pool of servlet instances (the default pool size is five) that are used to process multiple requests. In older versions of WebLogic Server, multiple parallel requests in excess of the pool size would block waiting for the first available servlet instance. This behavior changed in WebLogic Server 7.0. The server now creates, initializes, and discards a new instance of the servlet for each request rather than blocking an execute thread under these conditions. Set the pool size properly to avoid this extra servlet creation and initialization overhead.

You can configure the size of the pool at the Web application level using the single-threaded-servlet-pool-size element in the weblogic.xml deployment descriptor. If you choose to employ single-threaded servlets in high-volume applications, consider increasing the pool size to a level comparable to the number of execute threads in the server to eliminate the potential overhead required to create extra servlet instances on the fly to process requests.

Although instance variables are safe to use in single-threaded servlets, class-level static variables are shared between these instances, so access to this type of static data must be thread-safe even when using the SingleThreadModel technique. Deploy-ing and executing this TrivialSingleThreadServlet example verifies this pool-ing behavior in WebLogic Server. The first servlet request causes WebLogic Server to create five instances of the servlet, as evidenced by five separate invocations of the init() method and the subsequent writing of five "Here!" messages in the log.

Mastering BEA WebLogic Server, Best Practices for Building and Deploying J2EE Applications.

ISBN: 0-471-28128-X.
Published by Wiley

Authors:
Greg Nyberg, Robert Patrick with Paul Bauerschmidt, Jeff McDaniel, and Raja Mukherjee

Book Review
Mastering BEA WebLogic Server, Best Practices for Building and Deploying J2EE Applications is a new book for developers and architects. It covers many common areas experienced in the development and rollout of applications through J2EE and the use of BEA WebLogic Server. While the main audience is towards application developers and architects that have had some exposure to J2EE concepts and experience in development, beginners will find resource references and design patterns that will save a lot of extra work down the road.

The book covers Web applications, EJBs, and several other areas. There are three chapters on EJBs. Great care and time is spent discussing them in the BEA WebLogic Server context, including strategies in use, features, how to build, and typical packing and deployment of them. The remaining chapters cover JMS, security; administration/deployment; optimizing WebLogic Server performance, development, and production environment best practices; and developing/deployment of Web service applications. The first five chapters are on Web applications. Those covered focused on key concepts, best practices, architecture, package and deployment, and a sample walk-through.

Each section in a chapter normally contained best practice tips that are highlighted. Sample code was throughout the book, but there wasn't such an amount that you were reading code for the majority of a topic. Downloads are available to look through that exemplify the concepts the section is trying to portray. I like the fact that the authors bring out sections of BEA WebLogic Server that really aid in development or optimize performance, like the discussion of wl:cache.

In all, I found this book easy to read. I wished that there was more content on the security and deployment sections, but the information that was there established a strong basis for any team working with BEA WebLogic Server. I highly recommend this as a resource for any architect working with WebLogic Server. It will be a definite piece in my library.

by Eric Ballou (iknowbea@yahoo.com