3.1 Server-Side Presentation Tier

Most developers think of a web browser as the presentation layer of J2EE. But the web browser isn't the whole story. J2EE supports many ways for users to connect: web browser, WAP-enabled phone, or web service, to name a few. These mechanisms have two things in common:

• They have a client-server model.

  The clients, such as web browsers and cell phones, share the work of generating a presentation with a server. The server holds the server-side presentation tier, which typically generates marked-up data like HTML or XML. The client interprets the marked-up data and presents it to the user.

• They are request-based.

  When the user wants to do anything, the client initiates a request to the server, and then waits for a response. The server processes the request and generates the appropriate response.

Enterprise developers usually don't have control over the client. Concentrate on what we can control: the server-side presentation tier. Figure 3-1 shows a typical setup for a server-side presentation tier in a web-based environment. The server is like a hotel's front desk, waiting for clients to call with questions (in the form of HTTP requests). The web server acts like a highly caffeinated receptionist, answering basic questions itself and directing complex requests to other interfaces—like the concierge or the plumber.

Figure 3-1. Components of the server-side presentation tier

Web servers support a number of interfaces for generating responses. For requests that always yield the same result, the server can create a response directly from a static HTML file. This option is obviously the most efficient, but it is the least flexible: any dynamic data must be generated by a plug-in to the web server itself. For more complicated requests, the server may use the CGI interface to execute an external program and use its results as the response. This method is more flexible, since programs can be added, removed, or changed without stopping the server. Unfortunately, it is inefficient, since it requires a new process for each request. The final option—the one implemented in J2EE—is to keep another process around that is always running. The web server can forward requests to this process at any time, without having to worry about startup costs. In J2EE, this process is the servlet container.

The next few chapters concentrate on life within the servlet container. We explore patterns for building extensible, efficient servlets and using the many related services provided by J2EE. But a presentation is only as useful as the data it presents; in Chapters 7 and 9, we discuss how to connect to business data. Later in the book, we focus on building the business tiers themselves.