JSP vs. XSP02/22/2001
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.
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.
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
are provided as well.
XSP has a few additions to its object
XspNodeStack is a
used to control element nesting in the XSP page Document object;
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
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