【正文】 ge and plex, they might want to use Enterprise JavaBeans (EJB) to encapsulate their business logic. So, they might switch to BEA WebLogic or Oracle9i AS. Again, none of their servlets or JSP pages have to be rewritten. Finally, if their project bees even bigger, they might move it off of their Linux box and onto an IBM mainframe running IBM WebSphere. But once again, none of their servlets or JSP pages have to be rewritten. 6． Secure One of the main sources of vulnerabilities in traditional CGI stems from the fact that the programs are often executed by generalpurpose operating system shells. So, the CGI programmer must be careful to filter out characters such as backquotes and semicolons that are treated specially by the shell. Implementing this precaution 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 100element array and then write into the 999th element, which is really some random part of program memory. So, programmers who forget to perform this check open up their system to deliberate or accidental buffer overflow attacks. Servlets suffer from neither of these problems. Even if a servlet executes a system call (., with or JNI) 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. 7． Mainstream There are a lot of good technologies out there. But if vendors don39。t know what to display until you read the data that the user submits. Just remember that the user submits two kinds of data: explicit (., HTML form data) and implicit (., HTTP request headers). Either kind of input can be used to build the output page. In particular, it is quite mon to build a userspecific page based on a cookie value. 2． The Web page is derived from data that changes frequently. If the page changes for every request, then you certainly need to build the response at request time. If it changes only periodically, however, you could do it two ways: you could periodically build a new Web page on the server (independently of client requests), or you could wait and only build the page when the user requests it. The right approach depends on the situation, but sometimes it is more convenient to do the latter: wait for the user request. For example, a weather report or news headlines site might build the pages dynamically, perhaps returning a previously built page if that page is still up to date. 3． The Web page uses information from corporate databases or other serverside sources. If the information is in a database, you need serverside processing even if the client is using dynamic Web content such as an applet. Imagine using an applet by itself for a search engine site: Downloading 50 terabyte applet, please wait! Obviously, that is silly。An Overview of Servlet and JSP Technology Gildas Avoine and Philippe Oechslin EPFL, Lausanne, Switzerland A Servlet39。t talk directly to the database. Even if it could, for security reasons, you probably would not want it to. The same argument applies to most other applications. You need the Web middle layer to extract the ining data from the HTTP stream, talk to the application, and embed the results inside a document. 4． Send the explicit data (., the document) to the client. This document can be sent in a variety of formats, including text (HTML or XML), binary (GIF images), or eve