第1页 / 共6页
第2页 / 共6页
第3页 / 共6页
第4页 / 共6页
第5页 / 共6页
第6页 / 共6页
购物系统设计与实现外文资料.docx
An Overview of Servlet and JSP Technology
Abstract: Servlet program running in the server-side, dynamically
generated Web page with the traditional CGI and many other similar
compared to CGI technology, Java Servlet with a more efficient, easier
to use, more powerful and has better portability, more savings to invest .
Key words: JSP Technology, Servlet, HTTP server
A Servlet's Job
1.1
Servlets are Java programs that run on Web or application servers, acting
as a middle layer between requests coming from Web browsers or other HTTP
clients and databases or applications on the HTTP server. Their job is
to perform the following tasks, as illustrated in Figure 1-1.
Figure 1-1
1．Read the explicit data sent by the client.
The end user normally enters this data in an HTML form on a Web page.
However, the data could also come from an applet or a custom HTTP client
program.
2．Read the implicit HTTP request data sent by the browser.
Figure 1-1 shows a single arrow going from the client to the Web server
(the layer where servlets and JSP execute), but there are really two
varieties of data: the explicit data that the end user enters in a form
and the behind-the-scenes HTTP information. Both varieties are critical.
The HTTP information includes cookies, information about media types and
compression schemes the browser understands, and so on.
3．Generate the results.
This process may require talking to a database, executing an RMI or EJB
call, invoking a Web service, or computing the response directly. Your
real data may be in a relational database. Fine. But your database probably
doesn't speak HTTP or return results in HTML, so the Web browser can'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 results
inside a document.
4．Send the explicit data (i.e., the document) to the client.
This document can be sent in a variety of formats, including text (HTML
or XML), binary (GIF images), or even a compressed format like gzip that
is layered on top of some other underlying format. But, HTML is by far
the most common format, so an important servlet/JSP task is to wrap the
results inside of HTML.
5．Send the implicit HTTP response data.
Figure 1-1 shows a single arrow going from the Web middle layer (the
servlet or JSP page) to the client. But, there are really two varieties
of data sent: the document itself and the behind-the-scenes HTTP
information. Again, both varieties are critical to effective development.
Sending HTTP response data involves telling the browser or other client
what type of document is being returned (e.g., HTML), setting cookies and
caching parameters, and other such tasks.
1.2
Why Build Web Pages Dynamically?
many client requests can be satisfied by prebuilt documents, and the
server would handle these requests 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:
1． The Web page is based on data sent by the client.
page
from
search
For
the
results
instance,
and
order-confirmation pages at online stores are specific to particular user
requests. You don'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 (i.e., HTML form data) and implicit (i.e., HTTP request headers).
Either kind of input can be used to build the output page. In particular,
it is quite common to build a user-specific page based on a cookie value.
engines
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
server-side sources.
If the information is in a database, you need server-side 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; you need to talk to the database. Going from the client to the Web
tier to the database (a three-tier approach) instead of from an applet
directly to a database (a two-tier approach) provides increased
flexibility and security with little or no performance penalty. After all,
the database call is usually the rate-limiting step, so going through the
Web server does not slow things down. In fact, a three-tier approach is
often faster because the middle tier can perform caching and connection
pooling.
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 FTP or mail
servers to extend their functionality. And, a servlet API for SIP (Session
Initiation
(see
http://jcp.org/en/jsr/detail?id=116). In practice, however, this use of
servlets has not caught on, and we'll only be discussing HTTP servlets.
standardized
Protocol)
servers
was
recently
1.3
The Advantages of Servlets Over "Traditional" 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.
1．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 with a lightweight
Java thread, not a heavyweight operating system process. Similarly, in
traditional CGI, if there are N 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 would
be loaded. This approach reduces server memory requirements and saves time
by instantiating fewer objects. Finally, when a CGI program finishes
handling a request, the program terminates. This approach 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 client
requests.
2．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. In
CGI, you have to do much of this yourself. Besides, if you already know
the Java programming language, why learn Perl too? You're already
convinced that Java technology makes for more reliable and reusable code
than does Visual Basic, VBScript, or C++. Why go back to those languages
for server-side programming?
3．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.
4．Portable
Servlets are written in the Java programming language and follow a
standard API. Servlets are supported directly or by a plugin on virtually
every major Web server. Consequently, servlets written for, say,
Macromedia JRun can run virtually unchanged on Apache Tomcat, Microsoft
Internet Information Server (with a separate plugin), IBM WebSphere,
iPlanet Enterprise Server, Oracle9i AS, or StarNine WebStar. They are part
of
see
http://java.sun.com/j2ee/), so industry support for servlets is becoming
even more pervasive.
Enterprise
Platform,
the
Java
2
Edition
(J2EE;
5．Inexpensive
A number of free or very inexpensive Web servers are good for
development use or deployment of low- or medium-volume Web sites. Thus,
with servlets and JSP you can start with a free or inexpensive server and
migrate to more expensive servers with high-performance capabilities or
advanced administration utilities only after your project meets initial
success. This is in contrast to many of the other CGI alternatives, which
require a significant initial investment for the purchase of a proprietary
package.
Price and portability are somewhat connected. For example, Marty
tries to keep track of the countries of readers that send him questions
by email. India was near the top of the list, probably #2 behind the U.S.
Marty also taught one of his JSP and servlet training courses (see
http://courses.coreservlets.com/) in Manila, and there was great
interest in servlet and JSP technology there.
Now, why are India and the Philippines both so interested? We surmise
that the answer is twofold. First, both countries have large pools of
well-educated software developers. Second, both countries have (or had,
at that time) highly unfavorable currency exchange rates against the U.S.
dollar. So, buying a special-purpose Web server from a U.S. company
consumed a large part of early project funds.
But, with servlets and JSP, they could start with a free server: Apache
Tomcat (either standalone, embedded in the regular Apache Web server, or
embedded in Microsoft IIS). Once the project starts to become successful,
they could move to a server like Caucho Resin that had higher performance
and easier administration but that is not free. But none of their servlets
or JSP pages have to be rewritten. If their project becomes even larger,
they might want to move to a distributed (clustered) environment. No
problem: they could move to Macromedia JRun Professional, which supports
distributed applications (Web farms). Again, none of their servlets or
JSP pages have to be rewritten. If the project becomes quite large and
complex, 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 becomes 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 general-purpose
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
100-element 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 (e.g., with Runtime.exec 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 don't
support them and developers don't know how to use them, what good are they?
Servlet and JSP technology is supported by servers from Apache, Oracle,
IBM, Sybase, BEA, Macromedia, Caucho, Sun/iPlanet, New Atlanta, ATG,
Fujitsu, Lutris, Silverstream, the World Wide Web Consortium (W3C), and
many others. Several low-cost plugins add support to Microsoft IIS and
Zeus as well. They run on Windows, Unix/Linux, MacOS, VMS, and IBM
mainframe operating systems. They are the single most popular application
of the Java programming language. They are arguably the most popular
choice for developing medium to large Web applications. They are used by
the airline industry (most United Airlines and Delta Airlines Web sites),
e-commerce (ofoto.com), online banking (First USA Bank, Banco Popular de
Puerto Rico), Web search engines/portals (excite.com), large financial
sites (American Century Investments), and hundreds of other sites that
you visit every day.
Of course, popularity alone is no proof of good technology. Numerous
counter-examples abound. But our point is that you are not experimenting
with a new and unproven technology when you work with server-side Java.
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
