HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Java Servlets provide a number of significant benefits to Web and application servers everywhere:

  • The ability to write a server-side application that can run without regard to the hardware, server operating system or Web server
  • A dramatic performance boost over CGI or interpreted script applications
  • Increased productivity using the Java language to build such applications
The third benefit has seen an even greater boost in the form of dynamically compiled Web pages when using the Java Web Server from Sun Microsystems; this technology finally gave servlet developers the RAD technology they've needed to produce complex Web applications faster.

The next step in the trend toward greater productivity has been taken and is called JavaServer Pages, or JSPs. This time around you're not limited to using the Java Web Server. Third-party servlet engine providers, such as Live Software and IBM, allow you to deploy JSP applications on every major Web server and platform. All the players in this arena adhere to a basic specification as defined by Sun, but not all JSPs are equal. (For example, servlet pioneer Live Software has added objects that closely resemble the objects found in Microsoft's Active Server Pages.) Obviously, this lends itself well to a direct comparison between what Sun and IBM have to offer and what Live Software brings to the table. This article will give the reader a comparison of the two JSPs by delving into the details of their respective specifications and bringing to light their similarities and differences.

Let's begin with the JavaServer Pages specification, as defined by Sun Microsystems. Essentially, this technology allows you to embed the Java language in Web pages that end with the .jsp extension rather than .html. What they're doing here isn't terribly different from what they've done with their .jhtml pages on the Java Web Server. (See my JDJ article [Vol. 3, Issue 6] on "Dynamic Page Compilation with the Java Web Server" to update yourself on this technology.)

Sun begins by changing .jhtml tags like <java>...</java> to Active Server Page tags like <%...%>. Sun divides the JSP spec into five different areas, the first of which is Directives. Table 1 describes the six JSP Directives to be inserted at the top of your Web page.

The second area defined by the spec is JSP Declarations, which define class-wide variables and methods using the SCRIPT tag. The SCRIPT open tag is <script runat="server"> and the close tag is </script>. The "runat=server" part of the tag is required to ensure that your Web browser won't think that your JSP is defining client-side JavaScript code. An example is shown below:

<script runat="server">
int I = 0; String X = "Hello";
Public void Send() {

JSP Scriptlets define the body of the generated Servlet's Service method, and are the third area defined by the JSP spec. They look like this: <%...%>. Most of the Java code to be written will end up between these two tags. Table 2 describes the four predefined variables that you'll use throughout your JSP applications.

The fourth area defined by the spec is JSP Expressions, using tags like this: <%= %>. Expressions specified within these tags will first be evaluated, with the result converted into a string and displayed. Any primitive type between these tags will be converted to a string, as follows:
<% int I = 25; %>
<%I %> //prints out 25 as a string

The final area defined by the JavaServer Pages spec is the Bean tag. This tag gives your page a conduit to regular or Enterprise JavaBeans that will encapsulate business logic separately from the content presentation. Although it's not a requirement, the bulk of your Java code should be inside JavaBeans and not on the JSP page; Java-Beans will give your JSPs their database access through JDBC or access to other distributed objects through CORBA or RMI. Utilizing JavaBeans from JSPs is the next logical step from using imported classes, as was the norm with JHTML pages in the Java Web Server 1.1. The Bean tag provides the syntax that allows the JSP to refer to the bean, as follows.

<bean name="lookup name" varname="alternate variable name"
type="class or interface name" introspect="(yes/no)" beanName="filename" create="(yes/no)"
scope="(request/session)" >
<PARAM Property="Value">

Let's take a closer look at the attributes found in the Bean tag. The name attribute identifies the key by which the bean is looked up. The optional varname attribute identifies the variable name that will refer to the bean. The type attribute - again optional - specifies the name of the bean's class, or interface, and defaults to the Object type. The introspect attribute is also optional and is set to either yes or no; by default the introspect attribute is set to yes, which means that the appropriate property - setter methods from the bean's BeanInfo - is called for each matching property. The optional create attribute is also set to either yes or no and defaults to yes. When yes is set, the bean is created if not found in the specified scope, whereas an error returns if no is specified and the bean isn't found. The scope attribute is optional and is set to either request or session. Scope is set to request by default where the bean is retrieved from the request context. If scope is set to session, the bean is reused from the current session, if present.

The beanName attribute is the name of the serialized file or class file that contains the bean and is used only when the bean is not present in the scope of the Bean tag and the value of create is yes. Finally, the PARAM tag can be optionally inserted inside the Bean tag to define values for a list of properties that will be set automatically through introspection. An example Bean tag would look like this:

<BEAN name="db" type="com.insource.beans.db" scope="session">
<PARAM LastName="Flatt" FirstName="Darren">
<%=db.LastName %>

Remember that this spec is layered on top of the Servlet API, so any code you've included with servlets can be included in your JSPs. As always, make sure the classes and beans you call from your JSPs are in your Classpath or they won't work. While objects like Request, Response and Out are included with the Sun JSP spec, you'll have to utilize the Servlet API to build full-blown Web applications. Somehow, the most important object for building cohesive Web applications, the Session object, has been left out of the spec. To rectify that problem you'll need to add this line of code on your Web page before any other session-related code:

<% HttpSession session =
request.getSession(true); %>

With the addition of this code, you can add, retrieve and remove Session variables throughout your Web application, as follows:
session.putValue("Item", "Hat");
//add a Hat to the Item session variable
//retrieves the value of the Item session variable
//removes the Item session variable

This sums up the major features of the JSP spec as laid out by Sun Microsystems. With this spec and a little help from the Servlet API, you can build full-featured Web applications that run in the Java Web Server and any server supported by IBM's servlet engine.

The other main player in this JSP drama is Live Software. Their most notable product is a freely distributed servlet engine called JRun that allows users of most major Web servers to run Java Servlets. This has been a great deal for Web application developers who don't want to be tied to proprietary server APIs such as NSAPI or ISAPI, but want a performance boost over CGI. Of course, IBM also provides a servlet engine that runs on many Web servers and implements the Sun JSP spec, but Live Software has gone a step further by adding objects that will look familiar to Active Server Page developers. Since we've already covered the Sun spec, which also provides the basis of Live Software's JRun Server Pages, we'll move on to the Objects and features that JRun adds above and beyond what Sun provides.

Just like Sun's JSPs, JRun Server Pages are made up of Directives, Declarations, Scriptlets, Expressions and the Bean tag. JRun Server Pages Directives add server-side include functionality through the use of the include and vinclude variables. The include variable allows you to insert the contents of a file relative to the local file system, and the vinclude variable does the same thing relative to the Web document root.

More important, JRun Server Pages add ASP Compatibility Objects to ease the migration of Active Server Pages Web applications to JSP. The Application object allows you to share information among all the users of a Web application, as defined by the JSP files in a virtual directory, as well as its subdirectories. The syntax for using this object and its associated methods appears in Table 3.

The Request Object retrieves the data passed to the server by the Web browser. With the Request Object you can use ASP Compatibility methods as well as all other methods made available in the HttpServletRequest class. Any variable may be accessed by calling Request(String name), whether it comes from a Form, QueryString, Cookie or Server Variable. If a variable with the same name exists in more than one collection, Request will return the first instance it encounters. You can be more specific by calling one of the Request methods in Table 4.

The Response object sends data to the client Web browser. As with the Request object, you can use ASP Compatibility methods in addition to all other methods made available in the HttpServletResponse class. JRun Server Page Response methods include those in Table 5.

The Server Object provides access to methods and properties on the server; most of them serve as utility functions. Callable methods of this object are found in Table 6.

The Session Object allows you to store information throughout the life of a particular user session. Variables stored in the Session Object persist, as the user jumps from page to page in your Web application. A Session Object is created when a user who doesn't already have a session requests a Web page. The server destroys the Session Object when the session expires due to inactivity or abandonment in code. (It should be noted that Session state is maintained only for browsers that support cookies.) Available Session methods are shown in Table 7.

The final ASP-related object in the JRun Server Pages is the global.jsa file; this file mirrors the global.asa file found in Active Server Pages and performs the same functions. Your JSP application can have only one global.jsa file, which must then be located in the root directory of the application. JSP reads the global.jsa file when the Web server receives the first poststart-up request for any .jsp file in an application, or when a user who doesn't have a session requests a .jsp file in an application. You can include Application start/end events, as well as Session start/end events, in your global.jsa file. The syntax and restrictions on global.jsa events are described in Table 8.

Live Software's JSPs also include a few other features that further reduce the time it takes to build Web applications. Taglets allow programmers to define their own custom HTML tags that perform a certain function. A Java programmer can define a reusable, server-side Taglet that will execute Java code to do anything you can do using Java. A nonprogramming Web page designer can then use that Taglet in his or her Web pages without having to understand the complexities of the Java code it's executing. This method of creating custom HTML tags goes a long way toward separating the Web presentation from the underlying business logic. Last, Live Software goes beyond merely allowing you to communicate with JavaBeans from your Web page; it adds several useful beans to get you started: a File bean, an HTTP bean, an SMTP mail bean, a Shopping Cart bean, and Database Connectivity beans with built-in connection pooling.

Clearly, both Sun's and Live Software's approaches to building JSPs go further than any other tool currently used to build sophisticated Web applications. The spectacular thing is that this is accomplished without tying the Web developer to a particular Web server or operating system. Sun should be applauded for identifying the fact that not everyone wants to build servlets from scratch.

JSPs allow novice Web programmers to learn Java a little bit at a time, using their favorite HTML editor. The JSP/Bean model of development allows teams of Web page designers and artists to do what they do best, while the Java programmers develop JavaBeans that interface with databases, distributed objects and other systems.

The full suite of Enterprise Java APIs is available for use with JSPs. Java Server Pages, as defined by Sun and IBM, are a great step forward from JHTML Dynamic Page Compilation in terms of ease of programming. Live Software has taken the torch and run even farther with its JSP implementation. Its ASP Compatibility Objects, Taglets and beans dramatically reduce the amount of coding a Web developer has to perform to get a powerful Web application out the door quickly. The productivity gains achieved by using JRun Server Pages are rivaled only by Microsoft's Active Server Pages. Of course, your JSP application won't be tied to Internet Information Server; it will be portable to any Web server you desire. That's why we use Java.

About the Author
Robert Tiffany is a senior technology consultant with Insource Technology in Houston, Texas. He is working on an e-commerce Web site using servlet technology for the George Bush Presidential Library. Robert has worked on Internet/intranet/extranet development with both Active Server Pages and Enterprise Java technologies. You can reach him at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.