Servlets are objects running in a Java Virtual Machine (JVM) on the server that generate responses to client requests. Often in a J2EE application the client will contact a JSP that communicates with a servlet. The servlet in turn will call a session bean that interacts with one or more entity beans.
Each entity bean will use Java DataBase Connectivity (JDBC) to communicate with a database. You don't need all of these steps. A servlet can make a call directly into a database. You can even write your own custom file in which to keep your data.
You can eliminate JSPs and just write a servlet that stands on the front line communicating with the client. In fact, JSPs are compiled into servlets before they are accessed. Chapter 4 deals with JSPs; for now you can think of them as servlets written in a more Web designer–friendly way.
Servlets are the second baseman of an enterprise system. When they get a request, they can sometimes handle it themselves and send a response back to the client. More often than not, however, they receive a request, transform it, and toss it over to another part of the system that performs the next step.
If you're familiar with the Model−View−Controller (MVC) enterprise architecture, you'll recognize servlets as in the role of the controller. Another way of describing their function is to say that servlets are in the middle tier. You don't want your client thinking about how the database is organized.
The client should be making requests that have to do with your business. The servlet can be built around the business logic and make the method calls of the components that make the actual calls into the database. Servlets are often seen as an alternative to CGI (Common Gateway Interface) scripts.
A CGI program, often written in Perl, has been a popular way of adding dynamic content to Web pages. In addition to the language limitations, a lot of overhead is involved in working with CGI scripts. Each request requires a new process to handle it. This presents problems for servers handling a large volume of requests.
If two users want to access the same CGI script (or the same user wants to access it twice), a separate process is spawned. In contrast, servlets are written in Java. A single instance can handle requests from different users. You don't have the CGI overhead of creating a servlet every time one is requested.
Servlets are initialized once using their init() method and then persist. You can take advantage of their persistence to reaccess them, share information, and to connect to other resources. When you are dealing with HTTP, the javax.servlet.http package provides a lot of support for common tasks.
You won't have to use Perl to step through long strings in order to parse and reassemble the client request. Library support exists for methods to set and get attributes, for adding and retrieving cookies, and for interacting with the client using intuitive methods and typed data.
Also, because a servlet is a Java solution, you can write ordinary Java objects that work with your servlet on the server. A servlet runs inside a JVM on a server. Before you shudder in memory of your early experience with applets, let us assure you that you won't have the same problems here.
The servlet is sending back HTML or other formats that the browser (or other custom client) can render. Actually, a more accurate description is that a servlet runs inside an application called a servlet container inside a JVM on the server. You will need to test your servlets against the containers you'll be running in.
The servlet container will take care of some of the life−cycle functions for you. We'll talk more about this later in this chapter in the section "Introducing the Servlet APIs." Since you're running within this servlet container you don't care about the operating system of the server, and your servlets should port easily to different Web and java application servers.
We don't know which application server you do or should use and can't tell you how to set it up. Things change. Different servers add support for different versions of the J2EE release. The manufacturers change the way their servers are configured and the extras that they provide.
Often you won't have a choice — you'll have to learn how to use the Web or application server that your employer has chosen. That being said, we are covering Servlet API 2.3 and are using the reference implementation Apache Tomcat 4.0, available from The Jakarta Project.
Installation is very easy, and the documentation has greatly improved. All of our examples have been tested in this environment. If you are not seeing the results we describe and are sure you have checked your configuration, you may have to shut Tomcat down and start it back up again. If you have edited the deployment descriptor file, you will definitely need to restart Tomcat.
