2.2 Servlets

[ Team LiB ]

2.2 Servlets The JSP specification is based on the Java servlet specification. In fact, JSP pages are often combined with servlets in the same application. In this section, we take a brief look at what a servlet is, and then discuss the concepts shared by servlets and JSP pages. In Chapter 3, we'll take a closer look at how JSP pages are actually turned into servlets automatically. If you're already familiar with servlets, this is old news. You can safely skip the rest of this chapter. 2.2.1 Advantages over Other Server-Side Technologies In simple terms, a servlet is a piece of code that adds new functionality to a server (typically a web server), just like CGI and proprietary server extensions such as NSAPI and ISAPI. But compared to other technologies, servlets have a number of advantages: Platform and vendor independence All the major web servers and application servers support servlets, so a servlet-based solution doesn't tie you to one specific vendor. Also, servlets are written in the Java programming language, so they can be used on any operating system with a Java runtime environment. Integration Servlets are developed in Java and can therefore take advantage of all other Java technologies, such as JDBC for database access, JNDI for directory access, RMI for remote resource access, etc. Starting with Version 2.2, the servlet specification is part of the Java 2 Enterprise Edition (J2EE), making servlets an important ingredient of any large-scale enterprise application, with formalized relationships to other server-side technologies such as Enterprise JavaBeans. Efficiency Servlets execute in a process that is running until the servlet-based application is shut down. Each servlet request is executed as a separate thread in this permanent process. This is far more efficient that the CGI model, where a new process is created for each request. First of all (and most obvious), a servlet doesn't have the overhead of creating the process and loading the CGI script and possibly its interpreter. But another timesaver is that servlets can also access resources that remain loaded in the process memory between requests, such as database connections and persistent state. Scalability By virtue of being written in Java and the broad support for servlets, a servlet-based application is extremely scalable. You can develop and test the application on a Windows PC using the standalone servlet reference implementation, and deploy it on anything from a more powerful server running Linux and Apache to a cluster of high-end servers with an application server that supports loadbalancing and failover. Robustness and security Java is a strongly typed programming language. This means that you catch a lot of mistakes in the compilation phase that you would only catch during runtime if you used a script language such as Perl. Java's error handling is also much more robust than C/C++, where an error such as division by zero typically brings down the whole server. In addition, servlets use specialized interfaces to server resources that aren't vulnerable to the traditional security attacks. For instance, a CGI Perl script typically uses shell command strings composed of data received from the client to ask the server to do things such as send email. People with nothing better to do love to find ways to send data that will cause the server to crash, remove all files on the hard disk, or plant a virus or a backdoor when the server executes the command. While a CGI script programmer must be very careful to screen all input to avoid these threats, such problems are almost nonexistent with a servlet because it doesn't communicate with the server in the same insecure way.[2] [2] However, servlet-based web sites are vulnerable to so-called cross site scripting attacks (see http://www.cert.org/advisories/CA-2000-02.html) the same way all dynamic web sites are, no matter which technology is used. As you will see in Chapter 3, JSP inherits all these advantages because it's based on the servlet specification. 2.2.2 Servlet Containers A servlet container is the connection between a web server and the servlets. It provides the runtime environment for all the servlets on the server as defined by the servlet specification, and is responsible for loading and invoking those servlets when the time is right. The container typically loads a servlet class when it receives the first request for the servlet, gives it a chance to initialize itself, and then asks it to process the request. Subsequent requests use the same, initialized servlet until the server is shut down. The container then gives the servlet a chance to release resources and save its state (for instance, information accumulated during its lifetime). There are many different types of servlet containers. Some containers are called add-ons, or plug-ins, and are used to add servlet support to web servers without native servlet support (such as Apache and IIS). They can run in the same operating-system process as the web server or in a separate process. Other containers are standalone servers. A standalone server includes web server functionality to provide full support for HTTP in addition to the servlet runtime environment. Containers can also be embedded in other servers, such as a climate-control system, to offer a web-based interface to the system. A container bundled as part of an application server can distribute the execution of servlets over multiple hosts. The server can balance the load evenly over all containers, and some servers can even provide failover capabilities in case a host crashes. No matter what type it is, the servlet container is responsible for mapping an incoming request to a servlet registered to handle the resource identified by the URI and passing the request message to that servlet. After the request is processed, it's the container's responsibility to convert the response created by the servlet into an HTTP response message and send it back to the client. This is illustrated in Figure 2-4. Figure 2-4. Request dispatching 2.2.3 Servlet Contexts and Web Applications A Java web application is typically made up by a combination of several different types of resources: JSP pages, servlets, applets, static HTML pages, custom tag libraries and other Java class files. Containers compliant with the Servlet 2.2 specification (or later), support a standard, portable way to package all these resources, along with a web application deployment descriptor containing information about how all the resources fit together. The deployment descriptor and all the other web application files are arranged in a well-defined hierarchy within an archive file, called a web application archive (WAR). All compliant containers provide tools for installing a WAR file or a special directory where a WAR file is automatically picked up (such as the webapps directory in Tomcat). Most containers also support web applications deployed directly in a filesystem using the same file structure as is defined for the WAR file, which can be convenient during development. Within the container, each web application is represented by a servlet context. The servlet context is associated with a unique URI path prefix called the context path, as shown in Figure 2-4. For instance, your human resources application can be associated with the context path /hr and your sales tracking system with the context path /sales. This allows one servlet container to distinguish between the different applications it serves and dispatch requests like /sales/report?month=Jan to the sales tracking application and /hr/emplist to the human resources application. The remaining URI path is then used within the selected context to decide how to process the request by comparing it to path-mapping rules defined by the application's deployment descriptor. Rules can be defined to send all requests starting with /report to one servlet and requests starting with /forecast to another. Another type of mapping rule can say that one servlet handles all requests with paths ending with a specific file extension, such as .jsp. This is how JSP page requests are handled. Figure 2-4 shows how the different parts of the URI paths are used to direct the request processing to the right resource through the container and context. Each context is self-contained and doesn't know anything about other applications running in the same container. References between the servlets and JSP pages in the application are commonly relative to the context path and, therefore, are referred to as context-relative paths. By using context-relative paths within the application, a web application can be deployed using any context path. Finally, a context can hold objects shared by all components of the application,[3] such as database connections and other shared resources needed by multiple servlets and JSP pages. [3] Special considerations must be taken for applications distributed over multiple servers. Chapter 18 describes this in more detail. The web application structure, the deployment file format, and the ability to share objects among components in an application are three important parts of the servlet specification that also apply to JSP. We will look at all these areas in much greater detail later in this book, starting with the basics in Chapter 5 and adding more advanced features as needed in the following chapters.

[ Team LiB ]