PB & Java

Digg This!

For developers looking at the complex problem of building Web applications that produce dynamically generated content, using JavaServer Pages (JSP) is an excellent solution.

JSP is a Web-scripting specification developed by Sun and the Java Community Process (JCP) and implemented by various vendors in their products. The JSP specification defines a dynamic page-based technology that relies on scripts and tags to build Web applications similar to Microsoft Active Server Pages (ASP), Sybase PowerDynamo, and Macromedia/Allaire ColdFusion. In this article we look at the advantages of JSP over other dynamic page server solutions as well as compare class-based development with page-based development. In the future we'll build upon these concepts by developing a simple yet useful application.

Dynamic Page Servers
Dynamic page servers are designed to provide dynamic content to a Web request. The Web request asks for a particular document that contains both static HTML tags and embedded scripts. The embedded scripts within the document are run on the server, and the generated content created by running these scripts is written into the HTML page. Because applications that run on dynamic page servers are written as pages rather than as programs or classes (Java), this is called page-based development.

Page-based development makes it easier to develop Web applications because it allows Web designers, who are HTML and graphics experts but are less fluent in programming languages, to build the presentation of a Web site and application developers to concentrate on building the core processing logic using components (EJB, CORBA, PowerBuilder) and Java servlets. Since the presentation is separated from the business logic and doesn't require code to be compiled before running it, Web designers can build the Web site in editors that are designed to build the visual portion of a Web application, including visual HTML design, link management, and organization of graphics. Table 1 lists some of the differences between these two programming styles. We'll see a good example of this as we look at implementing a Hello World Web application as both a servlet (class-based development) and a JSP page (page-based development).

Note: JSP applications can be written with minimal Java skills if custom tag libraries and JavaBeans are used to offload most of the processing.

Advantages of JSP
What makes JSP a better solution than any of these other dynamic page server solutions? JSP has several advantages over these other servers, including:

• Portability to different platforms
• Portability to different containers
• Performance
• Scalability and stability

The "scripting language" for JSP pages is Java, so they have all the benefits of the Java technology including access to the Java API and delivery on the promise of "Write Once, Run Anywhere." Because JSP is based on Java, Web applications can be run on any platform that supports the Java Virtual Machine. Other dynamic page servers are based on proprietary scripts (VBScript, CFML, DynaScript) and tags and are often limited in the number of platforms they run on.

The WORA principle doesn't apply only to operating system platforms but also to the application server/JSP container. This container is the environment that JSP pages are executed in. Sun lists more than 25 different server engines that support JSP technology on its Web site. This gives companies the freedom to develop their Web applications without tying themselves into a particular vendor's implementation, and the flexibility to port the application to a different vendor's implementation based on cost, performance, and capability.

Rather than being interpreted each time it's accessed, like ASP, PowerDynamo, or ColdFusion pages, a JSP page is compiled as a servlet into bytecodes, providing a tremendous boost in performance. JSP pages are deployed as pages, but are compiled into servlets by the JSP container the first time they're requested. Most container implementations also have an option that will tell the container to compile each JSP page on server start-up to alleviate this performance hit the first time a page is requested. Once a page is compiled into a servlet it won't be recompiled unless the JSP page is changed. The AEGIS test center has done some benchmarking tests that have shown as much as a 20% increase in performance over other page servers. In addition, the JSP technology was found to be able to handle more concurrent users on the same hardware. Where other page servers crashed under heavy load, the JSP container was able to continue processing.

Looking at JSP
JavaServer Pages are an extension of the Java servlet specification and part of the J2EE initiative. To get familiar with JSP we will look at a simple JSP page that reports the JSP container it's running in. The code is shown in Listing 1. Notice that most of the page is static HTML. There's very little Java code in this page. The first thing that should grab your attention as differing from a typical HTML page is the following line:

<%@ page language="java" %>

All JSP tags start with a <% delimiter and end with the %> delimiter. The tag we're looking at is a directive, noted by the starting delimiter <%@. Directives are used to tell the JSP container how to handle the JSP page before it's compiled and run. This page directive tells the JSP container that the page uses Java as its "scripting language."

This next line of JSP code is also a directive:

<%@ include file="getServerName.jsp" %>

The include directive tells the JSP container to include the specified file's contents into the current JSP page before the page is compiled into a Java servlet. This is an excellent way to reuse code across several pages in a JSP application. In our current example it also provides a way to separate more intensive Java code from the actual HTML presentation, allowing each page to be written separately, one by a Java developer and the other by an HTML developer.

The last line of JSP code in the page is listed below:

<%= getServerName()%>

This is a JSP expression, noted by the starting delimiter <%=. This tag will accept a Java expression, in this case a call to the method getServerName that's defined in the JSP page getServerName.jsp (see Listing 2), which we included into the helloWorld.jsp file. The JSP expression writes the evaluation of the expression directly into the HTML page that is returned to the browser (see Figure 1). Although this is not a very complicated example, it demonstrates how an HTML developer with minimal Java experience can write a JSP page.

What Happens to a JSP Page at Runtime?
JSP pages are invoked over the Web via URL requests. The URL is typically typed in a Web browser and sent to the Web (HTTP) server. In our example we might type the following in the address bar of a Web browser: http://localhost:8080/samples/helloWorld.jsp

The first part of the URL (localhost:8080) specifies the Web server machine address and port that the Web server is listening to for requests. In this case the Web server (Jaguar CTS) is running on the same machine as the browser and is listening on port 8080. This is the default HTTP listener setup in Jaguar CTS.

The next part of the URL (samples) is the context name of the Web application. This helps the JSP container differentiate between several different Web applications that can potentially be running on the same Web server.

The last part of the URL (helloWorld.jsp) identifies the resource that the Web browser is interested in, in this case our JSP page.

The Web server takes the request and forwards it to the JSP container based on the .jsp extension. The JSP container is the environment in which the JSP page runs. It manages the interaction between the JVM, JSP pages, and the Web server, and the life cycle of the JSP page, threads, and other complex plumbing issues.

When the JSP page is loaded into memory the container scans the page for embedded scripts and executes them on the server-side. This allows JSP pages to be run from any type of browser without worrying about compatibility issues or whether the client machine has a JVM or not. Of course, as we explained earlier, the JSP page is not actually scanned and interpreted by the container but instead compiled as a Java servlet and executed. The JSP/servlet is run and the contents are returned to the Web server and ultimately the Web browser to be displayed as an HTML page (see Figure 2).

We've been looking at JSP pages as a way to deliver dynamic HTML content. But the JSP technology is not limited to HTML, and can in fact deliver a wide variety of content including (but not limited to) graphics, XML, and WML.

While JSP pages have access to the full Java API, it's considered good practice to wrap business/processing logic, database access, and application server access in JavaBeans and custom tag libraries. This helps separate the core logic from the presentation and allows non-Java developers to assemble the JSP pages using familiar tags. It also allows presentation changes to be made without impacting or redeploying the core processing logic and vice versa.

The HelloWorld Servlet
To contrast page-based development with class-based, we'll build a Java servlet equivalent to our helloWorld.jsp page. The source code is shown in Listing 3. This article is not intended to teach Java servlets, but it should be evident that this requires much more code and Java skills than the JSP page.

In addition, it should be noted that all the HTML output is generated by writing out Java strings as shown in the line below:

out.println("<html>");

Using Java servlets to handle presentation duties requires the Java developer to have excellent HTML skills as well as Java programming skills. It also makes it very difficult to use HTML WYSIWYG editors to design pages or make changes to existing pages. All changes to the look of the Web application built with Java servlets requires a programming change and a recompile instead of just editing the JSP page.

Note: JSP pages do not remove the need for Java servlets. In fact, the best application design incorporates servlets for presentation flow control and business processing (which can also be done in components), and uses JSP for pure presentation logic. This type of design utilizes the MVC design pattern and is known as a Model 2 JSP application. See the Sun Web site for more details, www.sun.com.

Portability Across JSP Containers
To demonstrate the portability of the JSP technology we'll deploy our Web application in Sybase Jaguar CTS (EAServer) and in Apache Tomcat. Sybase has provided JSP support in Jaguar CTS since version 3.6.

Tomcat is an open-source servlet/JSP container available from the Apache Software Foundation (www.apache.org). Tomcat is available under the Jakarta project link. Tomcat is the official reference implementation for the Java servlet and JSP specifications put out by Sun.

To run the samples shown in this article download the WAR file, samples.war, from www.tamingjaguar.com We'll look at how to package a Web application as a WAR file in a future article. For now we'll just concentrate on deploying the WAR file in two different JSP containers.

Installing the Samples in Jaguar
To deploy the Web application to Jaguar CTS, right-click on the Web applications folder as shown in Figure 3 and select the Deploy | J2EE WAR menu option. When the wizard opens, type the path and name of the WAR file and hit the Next button.

Next install the Web application to the Jaguar CTS server by right-clicking on the Installed Web Applications folder as shown in Figure 4 and selecting the Install Web Application menu option. When the wizard opens, choose the "samples" Web Application and hit the OK button. When that step is finished, shut down and restart the Jaguar server. When the Jaguar server has restarted the Web Application will be accessible from a Web browser.

Note that both Tomcat and Jaguar CTS have HTTP listeners set up to listen on port 8080 by default. To run the samples for this article the HTTP listener on the Jaguar server was changed from the default port of 8080 to port 80 so that Tomcat and Jaguar CTS could be run at the same time without causing a conflict.

Installing the Samples in Tomcat
To run the Web application from Tomcat, stop the Tomcat server and copy the WAR file to the following directory:

C:\jakarta-tomcat\webapps

Restart the Tomcat server and the Web application is accessible from a Web browser. Figure 5 illustrates what the helloWorld.jsp page returns when it's run inside Tomcat instead of Jaguar CTS (compare to Figure 1).

Summary
In this article we looked at the power behind JSP Web applications. The JSP technology is the best technology available for writing Web applications, offering a standard platform that outperforms other interpreted dynamic page servers while providing a stable solution that can be ported to different operating systems and JSP containers without any changes to the application. We discussed the difference between doing page-based development (JSP) and class-based development (servlet) and hopefully demonstrated why page-based development at the presentation-level of a Web application is the most appropriate choice. We also looked at the portability of the JSP technology running our sample in two different JSP containers. In Part 2 we'll look at how to set up the development environment and build an application.