JSP vs. XSP
02/22/2001
Overview
In the world of server page acronyms, XSP is gaining
recognition. It's the next evolution of server pages.
XSP stands for eXtensible Server Pages and is one of the core
technologies available in Cocoon. Cocoon is one of the seven current
parts of the Apache XML project. The new Cocoon paradigm is based on
the fact that document content, style, and logic are often created by
different individuals or working groups. Cocoon aims for a complete
separation of the three layers. In other words, Cocoon allows content,
logic, and style to be separated into different XML files, and it uses
XSL transformation capabilities to merge them.
While having similar concepts to Java Server Pages (JSP), there are
a number of differences present in XSP. We will look at both
technologies to see how they stack up against each other. This article
assumes you have at least some understanding of XML and its
terminology.
XSP Technology
The main concept behind a web site using XML is the separation of
content, logic, and presentation. XSP provides the front-end portion
of an XML framework. Providing dynamic XML pages that are parsed and
transformed by the framework allows application interoperability, yet
the pages are constructed and stored as static files on a file
system.
Just as Java is aimed at providing a clear separation of content
from application and business logic, XSP seeks to provide the same for
XML-based applications. Although many of the currently available XML
frameworks allow this separation of layers within compiled code,
changes to the formatting of actual data in an XML document still
require Java code and subsequent recompilation.
XML browsers are useless without some predefined semantics. This is
one of the reasons why XSL (the eXtensible Stylesheet Language) was
proposed and designed. XSL is divided into two parts: transformation
(XSLT) and formatting objects (variously referred to as FO, XSL:FO, or
simply XSL). Both are XML DTDs that define a particular XML syntax:
every XSL or XSLT document is a well-formed XML document.
The Cocoon publishing model is heavily based on XSLT's
transformation capabilities. XSLT allows complete separation of
content and style, something everyone writing web applications has
been striving toward but has been unsuccessful at. This separation is
much harder to obtain with HTML, even if CSS2 or other styling
technologies are being used. But Cocoon goes further and defines a way
of separating content and style from the programming logic that drives
server-side behavior. The XSP language defines an XML DTD for
separating content and logic for compiled server pages.
In dynamic content generation technology, content and logic are
combined. There is typically a mix of static content and dynamic
logic that work together to create the final result, usually using
run-time or time-dependent input. XSP is no exception. It defines
syntax to mix static content and programmatic logic in a way that is
independent of both the programming language used and the binary
results that the final source rendering generate.
It should be understood that XSP is just a piece of the
framework. In much the same way that formatting objects mix style and
content, XSP objects mix logic and content. On the other hand, since
both are XML DTDs, XSLT can be used to move from pure content to these
final DTDs, placing the style and logic in the transformation layers
and guaranteeing complete separation and easier maintenance.
JSP Technology
The intention of JSP technology was to provide a clean separation
between content and presentation. While making great strides in doing
so, it falls somewhat short. While JSP has simplified many of the
server-side Java programming details, it still can't quite make the
clean break it was intended to. If you have delivered a large-scale
application using JSP you will no doubt agree.
JSP mingles content (pure data) with presentation in the same way
static HTML does. JSP allows tags and inline Java code to be inserted
into an otherwise normal HTML page. When the JSP page is requested,
the resulting code is executed in a Servlet engine and the results are
inserted right into the output HTML. JSPs tend to be specific for an
application because they are designed from the outset for the delivery
of output from that application. A typical JSP pages contains static
HTML/XML components, JSP tags, and optional snippets of Java code
called scriptlets. You can create and maintain JSP pages with your
favorite HTML/XML tool.
By using XML-like tags, scripting elements, scriptlets, and
directives, a content developer can accomplish quite a lot. Scripting
elements and expressions allow for runtime evaluation of
variables. Directives can be used to control certain aspects of the
actual workhorse servlet's operation. To simplify the scripting
elements, a JSP developer has access to a number of predefined
variables such as request, response, in, and out. These variables
represent, respectively, HttPServletRequest, HttpServeletReponse,
PrintWriter, and BufferedReader. There are a few other predefined
variables but for this discussion those listed should suffice.
Scriptlets provide a mechanism to insert code into the servlet's
service method. In addition, JSP can work hand-in-hand with
JavaBeans. By embedding beans within a JSP, it is possible to
encapsulate functionality for a JSP as well as reuse the bean in other
development efforts. Special treatment is given to beans in a JSP,
which can make for a cleaner, less cluttered JSP page. For example,
parameter values in a client request can automatically be used to set
a bean's properties. Beans also have scope and can be used per
request, between pages, or even throughout an application.
Custom Tag libraries also provide a way for JSP to separate content
from presentation. Using custom tag libraries it is possible to create
business logic that is almost completely hidden from the presentation
developer. The only thing that the presentation developer has to know
is how to reference the tag library and use the tag. This could be as
simple as one line of code, or it could be more complicated if tag
interaction is required.
As you can see, JSP technology is very powerful and useful but is
not ideal.
The Object Models
The XSP model works on the concept of processor and producers. A
processor is a Cocoon Java type that takes a DOM tree as input and
produces another (possibly modified) DOM tree as output. Think of it
as a filter in a command pipeline. The XSP engine is implemented as a
Cocoon processor that accepts an XSP page as input. The first time a
given XSP page is processed, it is translated into an equivalent
source program that is then compiled, loaded, and executed. Subsequent
requests for the same XSP page result in the execution of the
generated program. As you may expect, the output DOM tree returned by
the XSP engine processor is actually built by the generated
program.
XSP pages are compiled into Cocoon producers. A producer is a
Cocoon Java type normally used to feed the initial XML content to the
Cocoon processing pipeline. For example, when Cocoon serves a static,
"regular" XML document, file contents are actually delivered by
Cocoon's built-in FileProducer.
Where JSP technology generate servlets, XSP generates producers
instead. This is because, among other reasons, the servlet model does
not yet provide a mechanism for portably and efficiently
post-processing XML content.
JSP and XSP share many of the same built-in objects. XSP defines
an abstract producer (XSPPage) as the base class for generated
programs. The request and response are available with a slight change
to the wrapper provided in Cocoon. Access to
ServeltOutputStreamObject and its associated writer are
not provided. HttpSession and ServletContext
are provided as well.
XSP has a few additions to its object
model. XspNodeStack is a java.util.Stack
used to control element nesting in the XSP page Document object;
xspCurrentNode and xspParentNode are
org.w3c.Node objects. xspParser is a
Cocoon-supplied DOM parser, which may be used to create new documents
and parse external XML documents. In addition to the objects already
listed, the XSPPage contains a xspExpr() method than can
be used to wrap any Java value as an org.w3c.Text object.
There is also an XSPUtil Class automatically imported that offers a
number of DOM, HTTP, and file manipulation services implemented as
public static methods. These include cloneNode,
toMarkup encodeMarkup, formEncode,
formDecode, pathComponent,
fileComponent, baseName, split,
and isAlphaNumeric.
