JAVA SERVER PAGES-I OVERVIEW OF JSP
As you have already studied in previous units, servlets offer several improvementsover other server extension methods, but still suffer from a lack of presentation a
business logic separation. Therefore, developers created some servlet-based
environments that provided the desired separation. Some of these servlet-based
environments gained considerable acceptance in the marketplace e.g., FreeMarker and
WebMacro. Parallel to the efforts of these individual developers, the Java community
ndworked to define a standard for a servlet-based server pages environment. The
outcome was what we now know as JSP. Now, let us look at a brief overview of JSP: JSP is an extremely powerful choice for Web development. It is a technology using
server-side scripting that is actually translated into servlets and compiled before they
are run. This gives developers a scripting interface to create powerful Java Servlets.
JSP uses server-side scripting that is actually translated into servlets and compiled
before they are run
JSP pages provide tags that allow developers to perform most dynamic content
operations without writing complex Java code. Advanced developers can add the full
power of the Java programming language to perform advanced operations in JSP
pages
Server Pages
The goal of the server pages approach to web development is to support dynamic
content without the performance problems or the difficulty of using a server API.
The most effective way to make a page respond dynamically would be to simply
modify the static page. Ideally, special sections to the page could be added that
would be changed dynamically by the server. In this case pages become more like a
page template for the server to process before sending. These are no longer normal
web pages—they are now server pages.
The most popular server page approaches today are Microsoft Active Server Pages
(ASP), JSP from Sun Microsystems Inc., and an open-source approach called PHP.
Now, as you know, server pages development simplifies dynamic web development
by allowing programmers to embed bits of program logic directly into their HTML
pages. This embedded program logic is written in a simple scripting language, which
depends on what your server supports. This scripting language could be VBScript,
JavaScript, Java, or something else. At runtime, the server interprets this script and
returns the results of the script’s execution to the client. This process is shown in
Figure1. In this Figure, the client requests a server page; the server replaces some
sections of a template with new data, and sends this newly modified page to the
client
One of the greatest challenges in web development is in cleanly separating
presentation and business logic. Most of the web server extension methods have
suffered from this obstacle.
What does it mean to separate these layers? To start with, we can partition any
application into two parts:
• Business logic
It is the portion of the application that solves the business need, e.g., the logic to look
into the user’s account, draw money and invest it in a certain stock. Implementing the
business logic often requires a great deal of coding and debugging, and is the task of
the programmer.
• Presentation layer
Presentation layer takes the results from the business logic execution and displays
them to the user. The goal of the presentation layer is to create dynamic content and
return it to the user’s browser, which means that those responsible for the
presentation layer are graphics designers and HTML developers.
Now, the question arises that if, applications are composed of a presentation layer
and a business logic layer, what separates them, and why would we want to keep
them apart? Clearly, there needs to be interaction between the presentation layer and
the business logic, since, the presentation layer presents the business logic’s results.
But how much interaction should there be, and where do we place the various parts?
At one extreme, the presentation and the business logic are implemented in the same
set of files in a tightly coupled manner, so there is no separation between the two.
At the other extreme, the presentation resides in a module totally separate from the
one implementing the business logic, and the interaction between the two is defined
by a set of well-known interfaces. This type of application provides the necessary
separation between the presentation and the business logic. But this separation is so Java Server Pages-1
crucial. Reason is explained here:
In most cases the developers of the presentation layer and the business logic are
different people with different sets of skills. Usually, the developers of the
presentation layer are graphics designers and HTML developers who are not
necessarily skilled programmers. Their main goal is to create an easy-to-use,
attractive web page. The goal of programmers who develop the business logic is to
create a stable and scalable application that can feed the presentation layer with data.
These two developers differ in the tools they use, their skill sets, their training, and
their knowledge. When the layers aren’t separated, the HTML and program code
reside in the same place, as in CGI. Many sites built with those techniques have code
that executes during a page request and returns HTML. Imagine how difficult it is to
modify the User Interface if the presentation logic, for example HTML, is embedded
directly in a script or compiled code. Though developers can overcome this difficulty
by building template frameworks that break the presentation away from the code, this
requires extra work for the developer since the extension mechanisms don’t natively
support such templating. Server pages technologies are not any more helpful with
this problem. Many developers simply place Java, VBScript, or other scripting code
directly into the same page as the HTML content. Obviously, this implies
maintenance challenges as the server pages now contain content requiring the skills
of both content developers and programmers. They must check that each updating of
content to a specific server goes through without breaking the scripts inside the
server page. This check is necessary because the server page is cluttered with code
that only the business developer understands. This leaves the presentation developer
walking on eggshells out of concern for preserving the work of the business logic
developer. Worse, this arrangement can often cause situations in which both
developers need to modify a single file, leaving them the tedious task of managing
file ownership. This scenario can make maintaining a server pages-based application
an expensive effort.
Separating these two layers is a problem in the other extension mechanisms, but the
page-centric nature associated with server pages applications makes the problem
much more pronounced. JSP separates the presentation layer (i.e., web interface
logic) from the business logic (i.e. back-end content generation logic) so that web
designers and web developers can work on the same web page without getting in
each other's way.
Static and Dynamic contents in a JSP page
JSP pages usually contain a mixture of both static data and dynamic elements. Static
data is never changed in the server page, and dynamic elements will always be
interpreted and replaced before reaching the client.
JSP uses HTML or XML to incorporate static elements in a web page. Therefore,
format and layout of the page in JSP is built using HTML or XML.
As well as these static elements a JSP page also contains some elements that will be
interpreted and replaced by the server before reaching the client. In order to replace
sections of a page, the server needs to be able to recognise the sections it needs to
change. For this purpose a JSP page usually has a special set of tags to identify a
portion of the page that should be modified by the server. JSP uses the <% tag to
note the start of a JSP section, and the %> tag to note the end of a JSP section. JSP
will interpret anything within these tags as a special section. These tags are known as
scriptlets.
When the client requests a JSP page, the server translates the server page and client
receives a document as HTML. This translation process used at server is displayed in
Figure 2. Since, the processing occurs on the server, the client receives what appears
to be static data. As far as the client is concerned there is no difference between a
server page and a standard web page. This creates a solution for dynamic pages tha
does not consume client resources and is completely browser neutral
Resulting HTML
Template
<! DOCTYPE HTML PUBLIC “-//W3C//DTD
HTML 4.0 Final//EN”>
<HTML>
<HEAD>
<TITLE>A simple date example</TITLE>
</HEAD>
<BODY COLOR=#ffffff>
The time on the server is
Wed Aug 17 17:10:05 PST 2006
</BODY>
</HTML>
Server Page
<! DOCTYPE HTML PUBLIC “-//W3C//DTD
HTML 4.0 Final//EN”>
<HTML>
<HEAD>
<TITLE>A simple date example</TITLE>
</HEAD>
<BODY COLOR=#ffffff>
The time on the server is
<%= new java.util.Date() %>
</BODY>
</HTML>
No comments:
Post a Comment