Introduction to servlet and alternatives
The evolution of internet has led to the development of the java language. It serves as a complete client/server solution where programs are dynamically downloaded on to the client. Till date, the focus has been on the client-side development of applets and GUI components, which is incomplete as far as client/server computing is concerned. Therefore we will be introduced to the other side of the client/server computing- the Servlets.
Java Servlets are more efficient, easier to use, more powerful, more portable, safer, and cheaper than traditional CGI and many alternative CGI-like technologies. They are programs that run on a server, acting as a middle layer between a request coming from a Web browser or other HTTP client and databases or applications on the HTTP server. Their job is to:
1. Read any data sent by the user.
This data is usually entered in a form on a Web page, but could also come from a Java applet or a custom HTTP client program.
2. Look up any other information about the request that is embedded in the HTTP request.
This information includes details about browser capabilities, cookies, the host name of the requesting client, and so forth.
Java Servlets are more efficient, easier to use, more powerful, more portable, safer, and cheaper than traditional CGI and many alternative CGI-like technologies. They are programs that run on a server, acting as a middle layer between a request coming from a Web browser or other HTTP client and databases or applications on the HTTP server. Their job is to:
1. Read any data sent by the user.
This data is usually entered in a form on a Web page, but could also come from a Java applet or a custom HTTP client program.
2. Look up any other information about the request that is embedded in the HTTP request.
This information includes details about browser capabilities, cookies, the host name of the requesting client, and so forth.
3. Generate the results.
This process may require talking to a database, executing an RMI or CORBA call, invoking a legacy application, or computing the response directly.
4. Format the results inside a document.
In most cases, this involves embedding the information inside an HTML page.
5. Set the appropriate HTTP response parameters.
This means telling the browser what type of document is being returned (e.g., HTML), setting cookies and caching parameters, and other such tasks.
6. Send the document back to the client.
This document may be sent in text format (HTML), binary format (GIF images), or even in a compressed format like zip that is layered on top of some other underlying format. Many client requests can be satisfied by returning pre-built documents, and these requests would be handled by the server without invoking servlets. In many cases, however, a static result is not sufficient, and a page needs to be generated for each request. There are a number of reasons why Web pages need to be built on-the-fly like this:
=> The Web page is based on data submitted by the user.
For instance, the results page from search engines and order-confirmation pages at on-line stores are specific to particular user requests.
=> The Web page is derived from data that changes frequently.
For example, a weather report or news headlines page might build the page dynamically, perhaps returning a previously built page if it is still up to date.
=> The Web page uses information from corporate databases or other server-side sources.
For example, an e-commerce site could use a servlet to build a Web page that lists the current price and availability of each item that is for sale.
In principle, servlets are not restricted to Web or application servers that handle HTTP requests, but can be used for other types of servers as well. For example, servlets could be embedded in mail or FTP servers to extend their functionality. In practice, however, this use o f servlets has not caught on, and I’ll only be discussing HTTP servlets.
This process may require talking to a database, executing an RMI or CORBA call, invoking a legacy application, or computing the response directly.
4. Format the results inside a document.
In most cases, this involves embedding the information inside an HTML page.
5. Set the appropriate HTTP response parameters.
This means telling the browser what type of document is being returned (e.g., HTML), setting cookies and caching parameters, and other such tasks.
6. Send the document back to the client.
This document may be sent in text format (HTML), binary format (GIF images), or even in a compressed format like zip that is layered on top of some other underlying format. Many client requests can be satisfied by returning pre-built documents, and these requests would be handled by the server without invoking servlets. In many cases, however, a static result is not sufficient, and a page needs to be generated for each request. There are a number of reasons why Web pages need to be built on-the-fly like this:
=> The Web page is based on data submitted by the user.
For instance, the results page from search engines and order-confirmation pages at on-line stores are specific to particular user requests.
=> The Web page is derived from data that changes frequently.
For example, a weather report or news headlines page might build the page dynamically, perhaps returning a previously built page if it is still up to date.
=> The Web page uses information from corporate databases or other server-side sources.
For example, an e-commerce site could use a servlet to build a Web page that lists the current price and availability of each item that is for sale.
In principle, servlets are not restricted to Web or application servers that handle HTTP requests, but can be used for other types of servers as well. For example, servlets could be embedded in mail or FTP servers to extend their functionality. In practice, however, this use o f servlets has not caught on, and I’ll only be discussing HTTP servlets.
Advantages of Servlets Over CGI
Java servlets are more efficient, easier to use, more powerful, more portable, safer, and cheaper than traditional CGI and many alternative CGI-like technologies.
Efficient
With traditional CGI, a new process is started for each HTTP request. If the CGI program itself is relatively short, the overhead of starting the process can dominate the execution time. With servlets, the Java Virtual Machine stays running and handles each request using a lightweight Java thread, not a heavyweight operating system process. Similarly, in traditional CGI, if there are N simultaneous requests to the same CGI program, the code for the CGI program is loaded into memory N times. With servlets, however, there would be N threads but only a single copy of the servlet class. Finally, when a CGI program finishes handling a request, the program terminates. This makes it difficult to cache computations, keep database connections open, and perform other optimizations that rely on persistent data. Servlets, however, remain in memory even after they complete a response, so it is straightforward to store arbitrarily complex data between requests.
Convenient
Servlets have an extensive infrastructure for automatically parsing and decoding HTML form data, reading and setting HTTP headers, handling cookies, tracking sessions, and many other such high-level utilities. Besides, we already know the Java programming language. Why learn Perl too? We’re already convinced that Java technology makes for more reliable and reusable code than does C++. Why go back to C++ for server-side programming?
Powerful
Servlets support several capabilities that are difficult or impossible to accomplish with regular CGI. Servlets can talk directly to the Web server, whereas regular CGI programs cannot, at least not without using a server-specific API. Communicating with the Web server makes it easier to translate relative URLs into concrete path names, for instance. Multiple servlets can also share data, making it easy to implement database connection pooling and similar resource-sharing optimizations. Servlets can also maintain information from request to request, simplifying techniques like session tracking and caching of previous computations.
Portable
Servlets are written in the Java programming language and follow a standard API. Consequently, servlets written for, say, I-Planet Enterprise Server can run virtually unchanged on Apache, Microsoft Internet Information Server (IIS), IBM WebSphere, or StarNine WebStar. For example, virtually all of the servlets and JSP pages in this book were executed on Sun’s Java Web Server, Apache Tomcat and Sun’s JavaServer Web Development Kit (JSWDK) with no changes whatsoever in the code. Many were tested on BEA WebLogic and IBM WebSphere as well. In fact, servlets are supported directly or by a plug-in on virtually every major Web server. They are now part of the Java 2 Platform, Enterprise Edition (J2EE; see
http://java.sun.com/j2ee/), so industry support for servlets is becoming even more pervasive.
Secure
One of the main sources of vulnerabilities in traditional CGI programs stems from the fact that they are often executed by general-purpose operating system shells. So the CGI programmer has to be very careful to filter out characters such as backquotes and semicolons that are treated specially by the shell. This is harder than one might think, and weaknesses stemming from this problem are constantly being uncovered in widely used CGI libraries. A second source of problems is the fact that some CGI programs are processed by languages that do not automatically check array or string bounds. For example, in C and C++ it is perfectly legal to
allocate a 100-element array then write into the 999th “element,” which is really some random part of program memory. So programmers who forget to do this check themselves open their system up to deliberate or accidental buffer overflow attacks. Servlets suffer from neither of these problems. Even if a servlet executes a remote system call to invoke a program on the local operating system, it does not use a shell to do so. And of course array bounds checking and other memory protection features are a central part of the Java programming language.
Inexpensive
There are a number of free or very inexpensive Web servers available that are good for “personal” use or low-volume Web sites. However, with the major exception of Apache, which is free, most commercial-quality Web servers are relatively expensive. Nevertheless, once we have a Web server, no matter its cost, adding servlet support to it (if it doesn’t come preconfigured to support servlets) costs very little extra. This is in contrast to many of the other CGI alternatives, which require a significant initial investment to purchase a proprietary package.
Efficient
With traditional CGI, a new process is started for each HTTP request. If the CGI program itself is relatively short, the overhead of starting the process can dominate the execution time. With servlets, the Java Virtual Machine stays running and handles each request using a lightweight Java thread, not a heavyweight operating system process. Similarly, in traditional CGI, if there are N simultaneous requests to the same CGI program, the code for the CGI program is loaded into memory N times. With servlets, however, there would be N threads but only a single copy of the servlet class. Finally, when a CGI program finishes handling a request, the program terminates. This makes it difficult to cache computations, keep database connections open, and perform other optimizations that rely on persistent data. Servlets, however, remain in memory even after they complete a response, so it is straightforward to store arbitrarily complex data between requests.
Convenient
Servlets have an extensive infrastructure for automatically parsing and decoding HTML form data, reading and setting HTTP headers, handling cookies, tracking sessions, and many other such high-level utilities. Besides, we already know the Java programming language. Why learn Perl too? We’re already convinced that Java technology makes for more reliable and reusable code than does C++. Why go back to C++ for server-side programming?
Powerful
Servlets support several capabilities that are difficult or impossible to accomplish with regular CGI. Servlets can talk directly to the Web server, whereas regular CGI programs cannot, at least not without using a server-specific API. Communicating with the Web server makes it easier to translate relative URLs into concrete path names, for instance. Multiple servlets can also share data, making it easy to implement database connection pooling and similar resource-sharing optimizations. Servlets can also maintain information from request to request, simplifying techniques like session tracking and caching of previous computations.
Portable
Servlets are written in the Java programming language and follow a standard API. Consequently, servlets written for, say, I-Planet Enterprise Server can run virtually unchanged on Apache, Microsoft Internet Information Server (IIS), IBM WebSphere, or StarNine WebStar. For example, virtually all of the servlets and JSP pages in this book were executed on Sun’s Java Web Server, Apache Tomcat and Sun’s JavaServer Web Development Kit (JSWDK) with no changes whatsoever in the code. Many were tested on BEA WebLogic and IBM WebSphere as well. In fact, servlets are supported directly or by a plug-in on virtually every major Web server. They are now part of the Java 2 Platform, Enterprise Edition (J2EE; see
http://java.sun.com/j2ee/), so industry support for servlets is becoming even more pervasive.
Secure
One of the main sources of vulnerabilities in traditional CGI programs stems from the fact that they are often executed by general-purpose operating system shells. So the CGI programmer has to be very careful to filter out characters such as backquotes and semicolons that are treated specially by the shell. This is harder than one might think, and weaknesses stemming from this problem are constantly being uncovered in widely used CGI libraries. A second source of problems is the fact that some CGI programs are processed by languages that do not automatically check array or string bounds. For example, in C and C++ it is perfectly legal to
allocate a 100-element array then write into the 999th “element,” which is really some random part of program memory. So programmers who forget to do this check themselves open their system up to deliberate or accidental buffer overflow attacks. Servlets suffer from neither of these problems. Even if a servlet executes a remote system call to invoke a program on the local operating system, it does not use a shell to do so. And of course array bounds checking and other memory protection features are a central part of the Java programming language.
Inexpensive
There are a number of free or very inexpensive Web servers available that are good for “personal” use or low-volume Web sites. However, with the major exception of Apache, which is free, most commercial-quality Web servers are relatively expensive. Nevertheless, once we have a Web server, no matter its cost, adding servlet support to it (if it doesn’t come preconfigured to support servlets) costs very little extra. This is in contrast to many of the other CGI alternatives, which require a significant initial investment to purchase a proprietary package.
No comments:
Post a Comment