Web Development with JavaServer Pages
JSP benefits
JSP offers several benefits as a system for dynamic content
generation. First of all, as
a Java-based technology, it enjoys all of the advantages that the
Java language provides
with respect to development and deployment. As an object-oriented
language
with strong typing, encapsulation, exception handling, and automatic
memory
management, use of Java leads to increased programmer productivity
and more
robust code. Because there is a standard, published API for JSP, and
because compiled
Java bytecode is portable across all platforms that support a JVM,
use of JSP
does not lock you into using a specific hardware platform, operating
system, or
server software. If a switch in any one of these components becomes
necessary, all
JSP pages and associated Java classes can be migrated over as is.
Because JSP is
vendor-neutral, developers and system architects can select
best-of-breed solutions
at all stages of JSP deployment.
In addition, because it enables full access to the underlying Java
platform, JSP
can readily take advantage of all of the other standard Java APIs,
including those for
cross-platform database access, directory services, distributed
computing, and cryptography.
This ability to leverage a wide range of data sources, system
resources,
and network services means that JSP is a highly flexible solution for
creating feature-rich
web-based applications.
JSP
itself offers several advantages as a system for dynamic content
generation.
Among these are improved performance over CGI and a programming model
that
emphasizes component-centric application design. This programming
model
enables developers using JSP to maintain a strict separation between
the presentation
elements of a web application and its underlying implementation. This
separation, in
turn, facilitates a division of labor within the web development team
by establishing
a well-defined interface between application development and page
design.
Performance
Conventional CGI codes exist as external programs from the HTTP
server. When
the server receives a request to be handled via CGI, it spawns one
new process for
each request to execute the CGI code. This makes it easy for the web
server to handle
multiple simultaneous requests requiring the same CGI program, but in
most
operating systems, process creation is rather expensive: memory and
other system
resources must be allocated and data and program code loaded before
the code is
run. Since CGI programs are designed to generate a single response
for a single
request, they execute quickly. After a CGI program has finished
running, however,
additional operating system resources are consumed when its process
is destroyed.
As we will see in chapter 2, JSP is typically implemented via
servlets. When a web
server receives a request for a JSP page, it forwards it to a special
process dedicated
to handling servlet execution. This process is referred to as the
servlet container. In
the context of JSP, it is referred to as the JSP container.
JARGON In older literature on server-side Java
technologies, these containers are also
referred as "engines"- that is, the servlet engine and
the JSP engine.
The servlet container is normally a separate process from the HTTP
server, due
primarily to the fact that the servlet container is a Java process,
running a JVM, while
most HTTP servers are written in other languages. The key factor here
is that, for
servlet containers associated with conventional HTTP servers, there
is only one additional
process for the servlet container, which handles all servlet-related
requests,
including JSP. This process is initiated when the HTTP server starts
up, and continues
to run until the HTTP server is shut down. Rather than create a
completely new
process for each request requiring dynamic content generation, all
such requests are
forwarded by the HTTP server to a single servlet container
process.
TIP For those HTTP servers that are written in Java, there
is no reason the servlet
container cannot be run as part of the same process. In fact, for
many of the HTTP servers which are written in Java, all of the
functionality of the HTTP server is implemented via servlets, including the handling of
requests for both JSP and HTML files, so there is no distinction
whatsoever between the HTTP
server and the servlet container.
It is still a requirement that the servlet container handle
multiple requests for a
given servlet or JSP at the same time, but this is accomplished via
Java threads,
rather than full-fledged processes. Threads are similar to processes,
in that many
threads can be running simultaneously within a JVM. Threads require
considerably
less overhead to create and destroy than processes, however; for this
reason they are
sometimes referred to as lightweight processes. Because they
use less resources, they
are much more efficient than processes. For example, spawned
processes often copy
the memory of the parent process, whereas threads share memory with
the parent
thread. As a result, servlets and JSPs are much more efficient than
traditional CGI
programs for generating dynamic web content.
NOTE As a matter of fact, all of the code running within a
Java Virtual Machine is
part of one thread or another. When a JVM first starts up, it creates
an initial set of threads for managing itself (e. g., running the
garbage collector, listening
for user interface events), as well as a thread for running user
code. This code can in turn create and run its own threads, as is the
case for a servlet
container using threads to handle HTTP requests.
For even greater performance, some servlet containers are capable
of running
"in process," as part of the HTTP server process itself, even for
those HTTP servers
which are not written in Java. This makes communication of requests
and responses
between the servlet container and the HTTP server much more
efficient, and is
accomplished by running the servlet container itself as a thread
within the HTTP
server. IBM's WebSphere, for example, supports in-process operation
as an option,
and the servlet container built into Version 4 of Netscape's iPlanet
server products
only runs in process.
Furthermore, because all servlet and JSP requests are handled by the
same process
(i. e., the JVM), it is very easy for them to share resources, and
thereby improve
performance. For example, database access is much quicker when
employing a pool
of reusable database connections that always remain open. Since CGI
programs start
a separate process for each request, it is much more difficult for
them to share
resources. In the case of database access, for example, each CGI
request must typically
open its own connection to the database, and close that connection
when the
request is done. This adds additional overhead, which the servlet
container can
avoid by creating a connection pool during startup, and then sharing
these connections
among individual request threads.
As you are probably aware, Java class files are compiled to
platform-independent
bytecode rather than native assembly code. The job of the JVM is to
interpret this
bytecode and turn it into platform-native instructions at run-time.
Because of this
extra layer of interpretation required to run Java code, it is
necessarily the case that
Java code will run slower than an equivalent program written in
another programming
language (for example, C or C++) and compiled to native code. Given
this
fact, it might seem like Java would be a poor choice for dynamic
content generation,
since the speed with which requests can be turned into responses has
a direct impact
on the amount of traffic that can be handled by a web server.
Recall, however, that most dynamic content generation systems in wide
use
today rely on interpreted scripting languages. The most popular
language for CGI
programming is Perl, an interpreted scripting language. Active Server
Pages and PHP are based on interpreted scripting languages. Server-Side
JavaScript, like Java,
is compiled into a platform-independent format, so it also requires a
run-time interpreter.
ColdFusion tags are likewise interpreted at run-time on a per-request
basis.
Compared to the most popular alternatives, then, JavaServer Pages
does not suffer
a relative performance hit because of its reliance on an underlying
interpreter.
Furthermore, because of the popularity of Java as a programming
language, many
techniques have been introduced in recent years for improving Java
run-time performance,
such as Just-In-Time (JIT) compilation and generational garbage
collection.
In practice, then, Java performance is more than adequate for
dynamic
content generation, given adequate server hardware. At the same time,
hardware
and operating systems vendors continue to actively research new
methods for
improving JVM performance, as they compete for top honors in various
Java bench-marks.
And as Java performance continues to improve, the performance of
Java-Server
Pages also improves. So, while Sun Microsystems and all of the
other
vendors of servlet and JSP products continue to work on the
performance of the
basic JavaServer Pages API, JSP also benefits indirectly from all of
the resources
being devoted to Java performance in general.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
