| The original server-side Java technology is called servlets. The name comes from a play on the word applet. Because the word means little application, it was reasoned that the word servlet would mean little server application. Strictly speaking, the name is not exactly correct because servlets can be huge. The name is convenient and useful, however, because it gives us a unique name that cannot be confused with other technical terms. Servlets are not really programs in their own right. They cannot be run from a command line because they contain no main() method. They are intended to be run from a special piece of software called the servlet container. This container used to be a separate container from the Web server itself and required a separate download. Recent releases of Web server software have included the servlet engine in the base product. The servlet container has several responsibilities: Loads the servlet when it is requested. Loads additional instances of the servlet in response to increased demand. Unloads servlets and copies of servlets when demand falls. Calls the servlet's entry point causing execution to begin. Receives the output from the servlet and hands it over to the Web server to be sent to the requesting client.
Servlets can be called by placing a URL in a browser's address bar as shown here: http://localhost/examples/servlet/GenericHello The http prefix tells the Web server that we want to communicate using the http protocol. The word localhost is the name of computer that we want to connect to. The examples/servlet/GenericHello tells the Web server which servlet you want to run. The physical location on disk where you place servlets that you want to make runnable varies from one Web server to anther. For example, on Apache Tomcat, the physical location of this servlet's class file is C:\Program Files\Apache Tomcat 4.0\Web apps\examples\WEB -INF\classes As you can see, the actual location of the class file is not easily discerned by looking at the URL used to call it. To complicate matters further, each Web server vendor seems to have different ideas about how the mapping between the logical location shown in the URL and the physical location of the servlet's class files in the server's file system. Figure 26.4 shows the inclusion of the servlet engine in the layered software diagram of the server. Figure 26.4. The Web server calls the Servlet Engine.  Notice that the Servlet Engine is not an HTTP application. It uses the Web server to communicate with the client. There is a call level interface between the servlet engine and the Web server software. Calling one simple servlet from a browser is a fairly easy task. How would someone go about creating a servlet that follows the Model-View-Controller architecture, though? To do this, separate servlets are used for different parts of the application. This servlet normally displays a welcome of some sort, and then gives the user a choice of functions to perform. When the user clicks one of these HTML buttons, a second servlet is called, which causes a screen or form to be displayed. (This form might contain JavaScript code to do browser-level error checking.) These two servlets constitute part of the View portion of this system. When a user fills out the form on the second screen and clicks a submit button, a third servlet is called, which applies business logic to answer questions like these: Is this user allowed to purchase this item? Do we extend credit to this user? Is this credit-card number valid? Do we have this item in the warehouse?
Notice that none of these tasks places HTML on the screen; therefore, the servlet or servlets that answer these questions are part of the Controller portion of the system. In addition, the servlets themselves might make calls to other classes to do this work. In that case, the servlets and the other classes would, as a group, be called the Controller. The servlets in the Controller portion of the system might determine the appropriateness of the request by using logic alone, but more than likely some external data would be required. This external data could be stored in a flat file or in a database. Normally, a Controller servlet doesn't access a database directly because of our desire to provide a division of labor. The preferred approach to performing database access is to place all database access code in a regular Java class in the Model layer. The Controller servlet can then instantiate this database-centric class that contains the JDBC code. Figure 26.5 shows how this architecture looks. Figure 26.5. By combining servlets with regular Java classes, we can implement a system that is faithful to the MVC architecture.  Notice that each layer except the View has regular Java classes in it. Servlets can become complicated very quickly if you try to do all the processing inside of them. The strongest feature of servlets is that they can be called from a browser on the client's computer. Many system designers move as much logic as possible into regular Java classes. These classes are easier to debug because they are just ordinary Java classes. If you add a main() method that instantiates the class and calls the methods, you can debug the class before ever calling it from a servlet. | 
