| Development of the JSP/Servlet platform - and how to use it. Updated
Oct 21, 2001 |
Getting Started
Tutorials
Applications and Forms
Actions
Directives
Scripting
Beans
JSP and Servlets
TagLibs
EJB
MVC: Struts, Velocity, etc
XML
Web services
Books |
Latest Specification:
JSR
-053 Java Servlet 2.3 and JSP 1.2 Specifications |
FAQs: Sun JSP FAQ
Esperanto
JSP FAQ JGuru JSP FAQ JSP Insider FAQ
Elsewhere: Learn Servlets
WebApps Java Servers
New: MVC frameworks: Expresso |
JavaServer Pages (JSP) is a scripting facility and specification built on
Servlets that enables you to build a Web interface by defining it in markup language pages, similar to HTML.
Using JSP requires a JSP-enabled Servlet engine, or a Servlet engine that incorporates the Java Server Web Development
Kit (JSWDK). A number of JSP engines are listed on JavaSkyline:
Servers. However, you should be especially aware of one of them
primarily: TomCat, from the Jakarta Apache Project. TomCat is the prototype for Sun's JSWDK standard.
Even as you read this, TomCat, Servlet architecture, and JSP technology are evolving. The target of this evolution,
what you might call the "Cadillac" version of TomCat, known as "Catalina" provides a highly
modular architecture. Catalina architecture provides a cascading "pipe-and-valve" process architecture
series that enables Servlet applications to be very versatile in responding to messages.
Two things to remember: First, at a detailed level, a JSP is actually a specialized servlet that you generate from
an HTML-like page. The JSP generates Java servlet code. In many servers, including TomCat, you can look up, examine,
and even save the code. Second, at a source level, JSP is very similar to ASP. If you work with one its fairly
easy to understand the other. |
JSP - an evolving standard. JavaServer
Pages is a highly adaptable facility - as pointed out by Sean Gallagher in Tagged for Success Java Pro, Mar
2000. For an architectural overview of JSP, see Introducing JavaServer Pages by
Timothy Eden and Ed Ludke, Java Pro Apr 2000. Another all too brief intro is given in Overview of Servlets and JSP by
Marty Hall, Java Boutique.
JSP is a "bridge" technology with which you define a Servlet process by using a markup page. Although
the approach has some limitations, JSP does provide an easy way to web-enable server applications. For a discussion
of JSP's advantages and limitations see the article and list of resources in JSP: Panacea or Quagmire by Richard
Katz JavaSkyline, Mar 2000, and see especially The Problems with JSP by Jason Hunter,
TrendMarkers Apr 2000, or on Servlets.Com.
Initially JSPs was designed with somewhat limited goals - to a replacement for Microsoft's ASP. But over time,
JSP has evolved and grown enormously. In fact, JSP has proved for many developers to be a worthy basis on which
to develop serious and demanding Web applications. Later versions of the JSP specification have added important
capabilities to JSP, such as Tag libraries, which give it superior encapsulation capabilities. JSP now supports
sophisticated patterns such as the Model-View-Controller (MVC) pattern combinations, and packages that use MVC.
JavaServer pages is highly adaptable as pointed out by Sean Gallagher in Tagged for Success JavaPro Mar 2000. |
|
Getting Started
|
First download and install TomCat or the JSWDK. The latest version of TomCat
can be found at the Jakarta Apache
Project, or you can get the latest official JSWDK download from
Sun's JSP
Download page.
Installation: Then of course you need to install it and make sure
it works. This is actually very simple. See Getting, Installing, and Running Tomcat (FermiLab).
A detailed overview of the installation process is provided on JavaBoutique in a (somewhat badly mislabeled) tutorial
called Writing
Servlets Part 3 by Gunther Birznieks. For installation instructions
for Mac OS X see, How
to Install Tomcat on MacOS X by Amandeep Jawa.
A couple notes:
The port Tomcat runs on by default is 8080. The port is defined in the file <TomCatHome/conf/server.xml. When you are starting out, it is recommmened that you leave the port address at
8080 - so you can follow tutorial material that directs you to that port.
Make sure it's running.
First start Tomcat. Go to the <tomcat>/bin directory and type ./startup.sh (or startup.bat for Windows) Then with your brower, navigate to: http://127.0.0.1:8080.
You should see the main Tomcat Index page. Click on several of the examples and test them out.
Installing Tomcat with Apache: There
is one other good reason to leave the port address alone: if you wish to run Tomcat with Apache (or another edge
server), then Apache will take port 80 and only route JSP/servlet requests to Tomcat. This adds greatly to scalability
- since you can use different machines for Apache and Tomcat. See TomCatHowTo instructions on How to make your first JSP page work on Tomcat
JavaChina/WebCabaret. See also How to install Apache and Tomcat to serve JSP pages on a MS Windows server, the
easy way (VerySimple.com) |
|
Starter Examples
|
Starter Examples: For a
short "Hello World" tutorial example, see Programming JSP (page 5 Introducing
JSP), Java Pro by Timothy Eden and Ed Ludke. Some basic examples appear on TECHVA's Introduction à JSP(fr) example page.
Most JSP engines also come with a collection of simple examples. You also receive a good starter set of examples
when you download Tomcat that you can run as explained in the previous section. After navigating to the main Tomcat
index page, click on the JSP examples link and try them out. The example JSP source will be located on your disk
drive in the directory: <TomCatHome>/webapps/examples/jsp |
|
Tutorials
|
Starter Tutorials: For
starters, go to Sun's JSP
Quickstart Guide And an excelent walk-through of the JSP development
process is provided in Willy Wheeler's Divide and Conquer Your Workflow with JSP,
Java Pro Apr 2000. Scott McPherson's informative tutorial: JavaServer Pages: A Developers Perspective,
JDC, Apr 2000 leads you through beans, tags, and using XML for a tag descriptor library. See also the Visual Builder
JSP Tutorial which is handy because you can either download as
a PDF or use it online.
Extended Tutorials: The
Servlet/JSP
tutorial series by Marty Hall provides quick start information
that will get you going on Servlets and JSP. The author also has a tutorial called First Servlets on Java Boutique,
part of its 3
part series on Servlets and JSP. Take a look at Making your first tag extension
from Orion, and JSP
1.1 examples from Orion.
OVERVIEW OF THE NEXT THREE SECTIONS: JSP
basically has three kinds of operations:Actions, Directives, and Scripting. |
|
Actions
|
Actions provide JSP runtime behavior. JSP Actions consist of a typical
(XML-based) prefix of "jsp" followed by a colon, followed by the action name followed by one or more
attribute parameters. For instance:
<jsp:include file="mypage.html" />
This particular action will embed the file mypage.html within the current
page. For a list of jsp actions see, for instance, the HP Bluestone JSP Actions page
|
|
Directives
|
While actions provide runtime behavior, with Directives you tell the JSP
engine to create features in the JSP before it is assembled. What does this mean? To understand, you need to know what a JavaServer
Page actually is.
Ok, what actually is a JavaServer Pages (JSP)? At the beginning it was noted that the JSP is a script that looks a lot like an
HTML page. Also, when the JSP runs, it's output looks like an HTML page. Could a JSP actually be an HTML page?
It walks like a duck...and talks like a duck so...
Well, in this case, it's not a duck - that is a JSP more than an HTML page.
A JSP is actually a set of HTML-like commands
which build a dynamic Servlet - that when run, displays output to the browser.
The browser output of course largely mimic the HTML commands you put into the JSP as modified by the run time actions.
But you also get to include dynamic elements.
Directives in your JSP source, tell the JSP engine how to generate this
Servlet - what features you want to incorporate, what to leave out. Directives are essentially a kind of "short
hand" that creates Java code.
The Page Directive. To
call a directive, you include "<%" at the beginning and "%> at the end and place @ in front
of the directive name. For instance, here is a simple example of the page directive:
<%@page language="java"%>
You don't need to include all the parameters - just the ones you wish to
modify by using the directive. However, the Page Directive is quite powerful. Here's Page with a number of the
options specified:
<%@page language=”java”
import="java.sql.*,java.rmi.*,java.util.*”
session=”true”
errorPage=”MyError.jsp”
isErrorPage=”false” %>
As you can probably tell, the Page Directive is rather important. It tells
the JSP engine, among other things, which libraries to use, whether there is a session in use or not, how to handle
errors when running the JSP. Sun provides a reference description for the Page Directive and its attributes
(for JSP 1.1) as part of Sun's JSP 1.1 Syntax Reference.
The Page directive is quite extensive. But using directives in general
isn't all that difficult - mainly because there just aren't that many directives. In fact, there are only three
- at least according to the JSP Syntax Refererence. One is Page. The other two are the Include Directive and the
TagLib Directive. But I would say there are actually four directives.
You mean there's a *missing* directive? Not really. And you won't need
to be a detective to find the missing directive. It's called ...
|
|
Scripting (Scriptlets, Declarations and Expressions)
|
Scripting incorporates actual Java code directly into the generated JSP
Servlet. So, scripting acts very similar to a directive - modifying what goes into the JSP Servlet. Since a scripting
creates code directly, it could have been called the "direct directive." Or maybe the "code directive."
But it isn't. It's called "scripting." There are three forms of scripting: scriptlets, declarations,
and expressions. A scriptlet looks like this:
<% Some
Java code ; %>
To use scriptlets effectively, it is good to know what Servlets are (for
what you need to know see Java Skyline:
Learn Servlets). And it's good to know one particular set of details
about all JSP generated Servlets - and that is this: All
JSP generated Servlets use a particular set of standard variables.
So, for instance, the HttpServletRequest that the JSP Servlet processes in its doPost method is always a variable
called "request." The PrintWriter that sends output to the browser is always called "out."
And so on. John Zukowski has a list of these variables. They're
given the haughty and overly eclectic name of "implicit objects." The important thing is all JSPs use
these standard variables.
Are these variables always the same because the programmers
who write JSP engines are boring and un-inventive? No. (Of course
he'd say that). But really, there is a very good reason why these variables are standard and that is this: As a
JSP programmer, you need to know these what these variables are because you quite often willl want to use them with your included code.
In fact, even if you didn't want to use them, it's good to know what they are - so you don't create variables with
the same names. That would not be good either. But more to the point, it's good to know that the PrintWriter is
called "out." You can always rely on using the variable "out" to write to the brower display
page. For example:
<% out.println("Hello World!") ; %>
So you don't have to worry that the JSP engine designer has declared a
different variable name like "mightyOutput." Here's a runnable example. Save the following text as <TomCatRoot>/webapps/ROOT/iterate.jsp:
<HTML>
<body>
<% int imax=8 ; %>
<% for (int i=0;i<imax;i++) { out.println("<BR>Hello World: "+i); } %>
</body>
</HTML>
Try it now! To run this example,
navigate with your browser to: http://localhost:8080/iterate.jsp. (Or you can click here to run iterate.jsp on Java
Skyline - if for instance you haven't downloaded TomCat yet).
Declarations. In general,
don't use declarations. A Declaration creates an instance variable. A Declaration looks very similar to a Scriptlet - only it has an exclamation point
at the beginning:
<%! Some
Java instance variable declaration code ; %>
As with Servlets, non-changing instance variables are fine. But you should
not use declarations or create instance variables in JSP - unless there is no way that two separate users might
simultaneously try to alter the value of the variable. Only use a Declaration to create 1) a non-changing variable
or 2) a static method variable or 3) a synchronized variable. Otherwise, your JSP will not be thread safe.
Note: If you think
you absolutely must create a changing instance variable , you can - but it's expensive. You need to tell the JSP
engine by including isThreadSafe="false" as an attribute in a Page directive. The JSP engine will then generate separate
synchronized requests to the Servlet one at a time, each time a user requests the JSP.
Expressions. There is
one more way of simple way of using Java code called an Expression. An "Expression" is essentially any
legal Java expression that returns a value - most commonly a method call that returns a String. The return variable
gets displayed in the JSP output. Expressions always begin with "=." Here's some fairly simplistic code
that uses expressions. Type this in and save it as <TomCatRoot>/webapps/ROOT/eightball.jsp
<HTML>
<body>
<%@page import="java.util.GregorianCalendar"%>
<H1>Let's play 'Ask the Eight Ball.'</H1>
<P>I'm thinking of a number.
<%! int imax=8 ; %>
<%! public int getImax() { return imax ; } %>
<P>It's coming through...I'm seeing the number <%=getImax()%> - at least I think that's it.
<P>Was that it?
<P><B>YES!</B>
<% GregorianCalendar now = new GregorianCalendar() ; %>
<P>When you hear the beep, the time will be <%=now.getTime()%>
<P>Beep.
</body>
</HTML>
To run this example, navigate with your browser to: http://localhost:8080/eightball.jsp.
Further research on Scripting.
Scriptlets and expressions are simple ways of incorporating new Java code into a JSP. Aside from simply composing
text responses, scriptlets can also be used for a variety of other functions. For instance:
Expressions are one way to refer to this Java code. However, there are
better ways that are more encapulating: TagLibs, and Beans as we shall see shortly.
|
|
Forms and Applications
|
Building an application.
From the users perspective, an application is it's forms. What the user sees and interacts with are the forms. So one of your objectives
is to make the forms as delightful, simple, and elegant as you possibly can so the user feels satisfied with your
application.
If you were to build a Web application that consists only of Servlets (or CGI for that matter) building the forms
would require a great deal of labor. For a given Servlet, you would need to design and build both 1) the interface
to the application
(the entry form
and 2) the interface produced by
the application, the follow-on form.
The follow-on form, of course becomes the entry form for the next Servlet in sequence and so on. In any useful
application, this process:
entry=> Servlet 1 => follow-on=> Servlet 2 => follow-on => Servlet 3 =>
creates form chains that are quite long. And once created they can be difficult
to re-arrange. So the most prominent and obvious advantages anticipated from JSP was to simplify the creation of
dynamic forms. And this it does quite well.
See for instance JSP: Creating Dynamic Forms by Stephanie
Kaminaris and Jose Annunziato (EarthWeb). Advanced form processing using JSP,
by Govind Seshadri JavaWorld, Mar 2000. There is a huge library of examples in JSP
Tags: Tiny Samples(Japanese).
|
|
Beans
|
An early attempt to include encapsulation for JSPs was the introduction of
Beans. In fact, three of the original standard JSP actions have to do with beans: <jsp:useBean> tells the
JSP it is using a particular bean. <jsp:setProperty> and <jsp:getProperty> manipulate properties stored
in a bean.
Beans improve dynamic forms by making data travel more easily from one form to the next. Beans can be used with
JSP 1.0 as well as JSP 1.1. See Beans
and Form processing from the JSP Tutorial. This tutorial example from iPlanet by
J.J. Kuslich demonstrates initializing a bean with jsp:setProperty and builds a feedback form. See also Q
& A - Reloading Java Classes in JSP Development by Daniel Savarese
on DevX and Validating JSP Input with JavaBeans Q & A
also by Daniel Savarese. |
|
Using
JSP with Servlets
|
A JSP is not a Servlet. But, as previously mentioned, using commands, a
JSP generates a dynamic Servlet. JSPs interoperate with Servlets very easily. And much progress in terms of enlarging
the scope of JSP architectures has come from taking advantage of this easy integration Servlets. The mechanisms
for doing so are quite simple and flexible:
Calling a Servlet from a JSP.
To terminate a JSP by calling a Servlet, you can use the "foward" action:
<jsp:forward page="/servlet/MyServlet" />
Or, to call a Servlet from within a JSP, use the "include" action:
<jsp:include file="/servlet/MyServlet" />
Calling a JSP from a Servlet. To call a JSP from a Servlet, write
the following code into the Servlet:
Patterns with Servlet-JSPs
The techniques shown above are quite flexible. They are capable for rapid development of page-centric features
for an otherwise Servlet-centric application. For instance,see Sample Application! by Harshal Deo
(WDVL). It shows how to easily add a Welcome screen as a follow-on for a login Servlet. Using techniques like Deo's
breaks down form chains to a more managable size.
The Servlet-JSP combination is also capable of being incorporated into
various design patterns. The article JSP and Servlets: A powerful pair,
Dan Malks' Architect's Corner column in Java Pro November 1999 shows how to use Servlet-JSP in a Mediator View
pattern. The techniques discussed. The Malks article is historically significant because it begins to reveal how
combining Servlets and JSPs result in useful design patterns and pattern frameworks.
Exactly a year later, Todd Lasseigne writing for the same Architect's Corner
column raised some navigation issues in Dynamic Servlet to JSP page navigation,
Java Pro, Nov 2000 and shows how they resolve by creating a controller Servlet object - acknowledging the Model
View Controller framework. A lot changed that year. In fact, a lot changed between November and December 1999 -
as we shall see shortly.
But, now I'm wondering: What will someone write in Architect's Corner in
November 2001? I can't wait.
Sending data and beans from a Servlet to a JSP There is the additional problem actually of passing data and classes from the Servlet to
the JSP. Which way you do this depends on the life cycle you want for the data (request, session or application).
Once you decide, you can pass a class to a JSP by storing it in the request, in the session, or in the Servlet
context, respectively. For instance:
MyBean myInstance = new MyBean();
session.putValue("myBean", myInstance);
The bean can then be accessed by the called JSP as:
<jsp:useBean id="myBean" scope="session"
class="MyBean" />
See also 10)
How do you invoke a JSP page from a Servlet? and 11) How do you pass data from a Servlet to a JSP
in the Esperanto JSP FAQ.
|
|
Cookies
|
Check out ServletUtilities and LongLivedCookie classes described
in Chapter
11 from Marty Hall's Core Servlets and JSP by Marty Hall. |
|
TagLibs
|
As of JSP 1.1 the use of tag libraries is standard. Tag libraries are a
good way to encapulate new functionality. Using custom tag libraries, you can create your own actions, or use custom
actions created by others.
For a basic introductory example see the Sun Tutorial: What is a Tag Library. The tutorial
directs you to download and deploy two war files (that are contained in a ZIP file) called interation.war and template.war.
To deploy them, just extract them from the ZIP file into the directory <TomCatHome>/webapps. Then stop and start TomCat. Once you have deployed them, you can run each by following
the instructions.
Now: Take a look inside.
After you do a deployment, it's a good idea to look at the files that are created. Dooing so means you'll know
that the deployment actually happenned. And, you'll also know just what directories and files were loaded. In this
case, after you deploy the template.war, you should get a webapp subdirectory called "template." If so,
take a look at the file:
<TomCatHome>/webapps/template/WEB-INF/classes/Dispatcher.java
Note that Dispatcher is actually a Servlet that redirects to a JSP using
the getRequestDispatcher() method as was described above.
Using Custom TagLibs. Creating
and using custom Taglibs requires three things.
1. Set up the Tag handler. This is a Java class that will process a Tag
reference and all the attributes.
2. Use the TagLib Directive - this set a particular prefix identifier to point to the URI where the TagLib is located.
3. Use the tag in your JSP.
So, knowing this, let's get started. Step 1: Write a tag handler... Um...
But let's say you don't want to re-invent the wheel.
Standard TagLibs There
are a lot of taglibs all ready that you can just download and use. For instance, take a look at the Orion Server
publishes a free Orion
Utility Taglib - one of them <util:displayCurrency> display
currency amounts based on locale. The site explains how to deploy and use them. And the Jakarta project has a set
of standard over 20 Taglibs (at this point in beta/early access stage). You can see the Jakarta Taglibs Web site for all
the details.
To use a tag library you will need to run a TagLib Directive which looks
like this:
<%@ taglib uri="/JoesUtilityLibrary.tld" prefix="joe"
%>
Creating your own. The
TLD (".tld") file is called a tag library descriptor. The TLD maps each tag to a program called a "Tag
Handler." A Tag Handler is a Java program that extends the class TagSupport. One Tag Handler program does
the work that supports one tag suffix. Each Tag Handler contains a method
public int doStartTag() { }
that is called when the tag is encountered and
public int doEndTag() { }
that is called when the tag close is encountered.
One Sue Spielman article in OnJava. Designing JSP Custom Tag Libraries,
Dec 2000, explains tag library concepts and then gives is a "Hello World" (and "Hello Sue")
example of a TLD and Tag Handler. Take a look at Casey Kochmer's Introduction to JSP Tag Libraries,
JSP Insider. Then Developing JSP Custom Tags by Qusay
H. Mahmoud, Aug 2001, JDC. For more, take a look at The Taglib tutorial from Orion Server.
Body Tags and Nested Tags. There
are also "Body Tags" which are somewhat more complex. And it is additionally possible to have nested
tags that pass variables from an outer tag to inner tags. For a good overview see JSP Custom_Actions (PPT) Hunter
et. al, O'Reilly Conference, Mar 2001 which provides examples of Tags, Body Tags, and Nested Tags. A second Sue
Speilman On Java article, Advanced Features of JSP Custom Tag Libraries,
Jan 2001, explains tags with bodies, nested tags and cooperating tags.
Forms revisited - this time with TagLibs. TagLibs can be created and used as a template for form definition as demonstrated in JSP
templates, David Geary JavaWorld Sep 2000.
|
|
EJBs
|
JSP and EJB: JSP can effectively
be used as the front-end to an EJB eCommerce application. In fact, that would seem to be a major reason for incorporating
JSP within J2EE. Material on using JSP with EJB is provided by Monica Pawlan's
Writing
Enterprise Applications with Java 2 SDK, Enterprise Edition, Lesson
4 (JDC). The Wrox book Professional JSP currently has Chapter
17, Case Study: J2EE, EJBs, and Tag Libraries on-line at Sun. Also
check out the Orion
EJB TagLibs and example JSP 1.1 EJB sample from Orion Server.
Handling stateful EJB session beans. Note
that EJBs and JSPs generally live in two containers and have different life cycles. A JSP/Servlet can and often
does use a stateful session EJB. When doing so, you need to be aware that your JSP user is holding on to valuable
resources within the EJB container. To ensure that your user lets go of these resources, it is useful to place
stateful session references inside the JSP/Servlet session. In this way, when the servlet session times out, the
EJB session reference will be dropped. See also What's the difference between EJB and JSP sessions?
Sara Polidori (JDC QoW), Aug 2001. |
|
Model View Controller (MVC) Frameworks:
Struts, Velocity, Turbine, JSF, etc.
|
The Model View Controller (MVC) framework
is a collection of patterns that incorporates three items:
- A controller that enables
- One or more combinable views to access
- A data model.
The MVC framework is desirable both for rationalizing user interface related
object designs, and creates an extendable architecture for user interface related software. MVC is additionally
a central concept of the well-known Design Patterns book by the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissidesbook.
JSP and Servlets again: The platform gets rich. MVC is thus a highly desirable pattern for something like the JSP/Servlet environment which
is quite concerned with user interfaces. Thus, beginning with the Dan Malks Java Pro article in November 1999,
MVC became a highly sought after goal and central focal point of server page development.
It was at this point, when JSP/Servlet began to refactor into MVC that the platform began to grow up. It become
more mature, rich, and sophisticated. In fact it was in its own way just as sophisticated as it's big brother,
the EJB platform, because JSP/Servlet was now asking and addressing the important questions from a systems engineering
standpoint like "what is design?" Doing so really put the JSP/Servlet platform on the map. Because, JSP/Servlet
transformed not only itself, but the entire Web as well. For the first time, a pattern-based design framework,
MVC, was being implemented on the Web. And thus JSP had made pattern compatible with, even synonomous with the
advancement of Web technology.
Dec 1999, MVC implemented in JSP/Servlets.
A second article on patterns and JSP Understanding the JSP Model 2 Architecture by
Govind Seshadri followed the Malks article a month later in JavaWorld, in December 1999. This article which is
sometimes referred to as "The Model 2 article" is also remarkable and often quoted by JSP-MVC advocates.
Technically, all the "Model 2" does is to point out that the MVC framework that could be realized within
the JSP/SErvlet framework, by enabling a Servlet controller and adding JSPs in a similar fashion to the Servlet
JSP articles above.
But it goes further. The article essentially organizes all JSP designs into either "Model 1" or "Model
2." If you aren't using MVC, then what you're using is "Model 1" which is "the default."
To underscore this, the article presents an very sophisticated but non-MVC design in the form of a JSP-bean architecture.
Seshadri then makes a slight modification to this architecture arriving at Figure 2 - what he calls "Model
2." When the new diagram is carefully examined, you can clearly see in blue text the three elements: the controller,
view, and model. The controller is a Servlet that routes the data model (beans) to multiple JSP views. To quote
Casey Kochmer in his Introduction to Struts:
"Developers new to JSP tend to start with Model 1 designs, where
JSP is used for every single aspect of their projects. In fact, it is common for programmers to use Model 1 design
without the realization they are building a Model 1 site. The reason comes from the fact that the natural state
of a JSP site is Model 1."
Recent developments in JSP design patterns: Addressing goals. Such was the state of affairs. But it is not the goal. A major goal addressed by
implementing Model 2 (MVC) and of continual concern throughout Web development everywhere is the separation of
work between the Web designer - a non-programmer and the Web programmer. One recent improvement in JSP-MVC architecture
is creating of beans for Views. In this way, the JSP doesn't have any Java code in it at all, See: The Dragonslayer Chronicles, Part 5 View beans: Keeping Java code out of the JSP
components Allison Pearce Wilson (IBM), Aug 2001. For an overview
see also slides Case Study: The Design of a JSP Framework
(PPT) Michael Alford, Mar 2001, O'Reilly Conference on Enterprise Java.
MVC has already become considered so important that Jakarta project alone
has three MVC frameworks related to JSP: Struts, Velocity, and Turbine. Of the three, Struts is the most JSP-centric.
Other MVC implementations are alternatives to JSP, or cooperate with JSP. Or both.
Model View Controller Frameworks
|
| |
| Struts (Jakarta) |
Struts is an MVC framework designed specifically for JSP. For information
on Struts see Introduction
to Stuts Tutorial. by Casey Kochmer on JSP Insider, the Struts User Guide from Jakarta Apache, and Strut your stuff stuff with JSP tags
by Thor Kristmundsson, JavaWorld Dec 2000. Also Applying the MVC pattern using Struts
by Peter Varhol Java Pro, May 2002.
OnJava has an introductory guide for Struts: Learning Jakarta Struts, Part 1 and Part 2 by Sue Spielman, Sep/Oct
2001. The latest release of Struts can be selected here. To run Struts on TomCat:
1. Extract all the files from the download into a directory
2. Copy from jakarta-struts-1.0.2/webapps to Tomcat's webapps
1. Install the files struts.jar and jaxp.jar in the Tomcat Lib directory. Place struts-example.war in the webapps
directory and start Tomcat. Then go to http://127.0.0.1/struts-example/ |
| Expresso New (JCorporate) |
Expresso is an MVC framework that also provides a high-performance caching
architecture, e-mail, a sophisticated event processing, and security and now incorporates Struts and other Jakarta
Apache technologies. See Why use Expresso? by Jcorporate. Expresso Enterprise provides integration
with EJB servers and there is also Expresso XML that provides XML-database mapping. Peter Pilgrim's article Best
Practice with Expresso Framework, Sep 2001, ServerSide, examines
the development of design patterns and MVC in the JSP/Servlet layer and explains creating an application with Expresso. |
Velocity
(Jakarta) |
Velocity is a template-based MVC framework system that is separate from JSP
Model 2 architecture and Velocity operates somewhat differently from JSP. In JSP variables are scoped by duration.
But in Velocity variables are instead organized into non-hierarchial "Contexts." Velocity can connect
to JSP through a set of JSP TagLibs. And, Velocity provides a ScopeTool that enable JSP to interact with Velocity.
See the Jakarta Velocity
Tag Library. For a good guide to Velocity itself, see Getting Up to Speed
with Velocity Jim Jagielski, Web Techniques, Sep 2001. If you're
trying to decide on an MVC platform and considering Velocity, you'll want to look at You make the decision by Jon Stevens,
plus the comments in as
re-published version of the article on Java Developers Journal,
and also the comparison between Velocity and Web Macro. |
Turbine
(Jakarta) |
Turbine is a Servlet based MVC framework that can integrate with Velocity
and JSP and works with a wide variety of back-end server tools including (the much sought after) XML-RPC integration. |
| JSF(Sun) |
JavaServer Faces, JSR 127 is a proposal in May 2001
that outlines eight goals concerning the creation of user interfaces and has beenincorporated as part of the JSP
1.2 specification. |
XTP, JSP Templates
(Caucho) |
Caucho JSP Templates Scott Ferguson implement MVC. Additionally, Caucho XTP Templates, Caucho's XML
processor implements a JSP Model 2 architecture and separates JSP coding from the page. |
XMLC
(Enhydra) |
Unlike JSP, XMLC (XML Compiler) reads an ordinary HTML page and creates an
object model of the page. A Java programmer then uses the model to create a dynamic presentation. See Gunning
for Sun, Tom Yeager, InfoWorld, Aug 10, 2001. |
Other MVC
Frameworks |
. Webmacro Model View Controller
. FreeMarker Freemarker An open alternative to JSP by
Vincent DiBartolo JavaWorld, Jan 2001 Example |
Further research on MVC and other JSP design patterns. The article Solve your Servlet-based presentation problems
Kevin Unger, JavaWorld, Nov 2000, describes several MVC implementations including the Web Macro scripting engine,
the Freemarker MVC implementation and Enhydra XMLC - as well as Struts. See also Java Skyline: WebApps Servlet Frameworks. Advanced
form processing using JSP also by Govind Seshadri, JavaWorld Mar
2000 discusses using JSP with Beans and the Memento pattern. Process JSPs effectively with JavaBeans by Milan Adamovic,
JavaWorld, Jan 2001 discusses the Template pattern. |
|
XML, XSL, XSP
|
JSP and XML: While XML
and JSP started as separate technologies they work together as Alex Chafee explains in Using XML and JSP together, JavaWorld,
Mar 2000. Actions and Tags were originally based on XML. And as of JSP 1.2, the JSP page itself is a well-formed
XML document. Sun's recent paper Developing XML Solutions with JavaServer Pages Technology
outlines how JSP can be used to both consume and generate XML for various clients: WML and XHTML for small devices,
VoiceXML for PBX and voice-based menu systems, as well as other application specific XMLs.
JSP, Java, and XSL:
XSLT is a transformation process used to (among other things) transform XML into a browser display. XSLT can work
within a brower (MS IE 5.0 and above, Netscape 6) or on the server side. In JSP XSLT is easily implemented using
Tags. The introduction, Development with JSP and XSLT Page Generation Systems
(ZIP/PPT) by Sam Borgeson, O'Reilly Conference, Mar 2001 shows how XSLT works and shows a JSP tag implementation.
See also the downloadable PDF version of Casey Kochmer and Jayson Falkner's Chapter 12 JSP and XML (available
on JSP Insider) from the Wrox Book Professional Also take a look at Casey Kochmer's series: Building an XML/XSLT/JSP based Newsletter Part 3
JSP Insider, August 2001 - there is also Part 1 June 2001 and part 2 July 2001. Caucho XML Template Library: Caucho
Resin can create JSP files from an XML template (XTP). The XTP provides the benefit of separating XML-based content
from scripting.
JSP and X-other: Stanley Santiago provides Combine the power of XPath and JSP tag libraries
in Java World, Jan 2001.
And there is also: eXtensible Server Pages (XSP), implemented in the very popular. Apache Cocoon See Ricardo Rocha's
XSP: A Primer and XSP
Samples on Plenix.com, and The XSP Tutorial XSP is different
from JSP - it's all XML see example source and result. Sue Spielman's article JSP
vs. XSP declares XSP could be "the next evolution" of server pages. She also has a Slide presentation on XSP (PPT)
from O'Reilly Conference, Mar 2001 that provides an overview of XSP, XSP vs. JSP, and XSP within the context of
other XML technologies. Or it might not be. See also Brett McLaughlin's Java and XML Section 9.4 XSP. |
|
Web services
|
For many organizations, of equal importance to MVC framework decisions are
the set of questions that revolve around how to approach Web services. Web services defines a set of formats (SOAP),
registries (UDDI), transport layers (HTTP/HTTPS, XML-RPC, SMTP), and interfaces (WSDL). These standards and mechanisms
enable numerous disparite platforms - including the Microsoft .Net platform. - to interoperate. Sun provides overview
documents for these technologies in a Web services: Special edition for developers
of Dot Com Builder Best Practices.
J2EE and Web services. For
Enterprise Java there are a number of independent enterprise tools, there are the JAX family of Java APIs and JWSDL
(in JCP development) and there are IBM and Apache SOAP XML tools which are designed to perform Web service. The
Developer's
Guide to Building XML-based Web Services by James Kao (ServerSide)
Jun 2001 shows how Web services and SOAP can connect to the JSP/Servlet layer using the HTTP/HTTPS protocols. Clean
up your wire protocol with SOAP, Part 2 by Tarak Modi also provides
discussion setting up the JSP/Servlet layer for use with Apache SOAP. Java Web services: What's not to like?
by Eric Armstrong, JavaWorld/JavaOne, Jun 2001 offers some preliminary insight into the new JSP 1.2 with JSF and
how it will enhance JSP and how it can be used with mobile devices.
The other major transport mechanism is XML-RPC. XML-RPC can be currently connected through Jakarta Turbine. But
the JCP is also building a transport layer called JAX-RPC. Still all the various ways that the JSP/Servlet layerfits
into this picture remains to be seen.
Organizing for Web services. The
paper J2EE vs. Microsoft.NET by Chad Vawter and Ed Roman, ServerSide, Jun 2001 shows the parallels between the
Microsoft .Net architecture and the J2EE Web services architecture. JSP and MS ASP appear, as shown in Table 1 Analogies between J2EE and .NET
as these are the systems that create dynamic content. And from an organizational stand point, the connections between
Microsoft and Java involves not only data, but also developers. JavaServer Pages initial weakness - being based
on and similar to Microsoft's ASP is ultimately one of its great strengths -- in that developers can adapt to them
both. See JSP
pages, evolving and contributing to Web services by Paul Monday
(IBM). |
|
Books
|
Professional
JSP Numerous authors (Wrox Press) Chapters 12 and 17 on-line.
Core Servlets and JSP Marty Hall (Sun) Chapters 7 Server Response and 14 Custom Tag Libraries on-line. See also Marty Hall's Servlet and JSP Tutorial Web site.
Book tips from John Zukowski: It is quite possible that when learning
JSP technology you will want to get a book. I do have some recommendations. However, before reading mine, please
take a look at John Zukowski's Book
Review list (JZ Ventures) and earlier book comparisons: Which
JSP book serves up the best lesson? JavaWorld Sep 2000. |