blank.gif
Search for PhotoDisc Images Here
webreview.com - Cross-Training for Web Teams
Search for: 
Jump to:
blank.gif
blank.gif

A Songline PACE Production



Understanding Java Servlets

by Dale Dougherty

T o get a better understanding of the significance of Java servlets, I interviewed Paul Colton, president and CEO of Live Software, Inc., a Java development company located in San Diego, Calif. Live Software developed JRun, a product that allows standard Web servers to run Java servlets. Paul is co-author of Java Unleashed, published by Sams.net. You can reach Paul at: pc@livesoftware.com

What is the difference between a Java applet and a Java servlet?

Basically, a servlet is the opposite end of an applet. A servlet can almost be thought of as a server-side applet. Servlets run inside the Web server in the way that applets run inside the Web browser. The browser can submit a request to execute a servlet directly; it can be stand-alone in terms of its actions -- as a browser can request an applet directly.

Do servlets require a specialized server?

To run a Java servlet, the first thing you need is a Java Virtual Machine (JVM) running on the server. It's analogous to running Java applets in a browser. The browser that supports applets must be running a JVM. So, for a server to run a servlet, it has to be running a JVM.

Additionally, the server also has to support the Java Servlet API. This API, developed by JavaSoft, defines how and when the servlet communicates with the server. Essentially, the Servlet API is a well-defined set of function calls to get and send information to and from the server. The servlet needs to be able to access server-defined variables, issue redirects, send error messages and the like.

Sun's Java Web Server supports the Servlet API and, of course, includes their JVM.

So the Java Servlet API is dependent on the Java Web Server?

No. The Servlet API is a set of Java classes that can be downloaded directly from Sun, independently from the Java Web Server. This is the Java Servlet Development Kit. When you download the kit, it comes with a set of simple plug-ins that add servlet support to Netscape, IIS and Apache. These are sample implementations that are not particularly robust or full-featured. They are fine as starter kits but not necessarily what you want to use in production.

What we've done at Live Software is develop JRun so that it is possible to use servlets written to the Java Servlet API with any Web server. JRun is a set of Java classes that implement all of the functionality needed for an application to run Java servlets. We then wrote native bridge-code that connects JRun to a particular native Web server allowing that server to run servlets. JRun currently works with Microsoft's IIS 3.0 and 4.0, Microsoft's Personal Web Server for Windows 95, and we've just completed an integration of JRun with O'Reilly's WebSite Professional. We've also begun development of JRun for the Macintosh Web server WebStar.

I'm really excited about the WebSite implementation. We've got some incredible stuff there because we were able to work so closely with the developer, Bob Denny. Integrating JRun into WebSite so tightly means that right now, out of all native Web servers available for Windows 95 and NT, WebSite offers the most servlet features. Under WebSite, servlets can inherit the access control features already built into WebSite, thus allowing one to authenticate users down to a specific servlet. We've also integrated the administrative interface for JRun into WebSite's administrator program. An update will be made available for current WebSite 2.0 users for full servlet support and will be part of WebSite's next major release.

How would you characterize the differences between developing servlet-based applications and CGI-based applications for the Web?

Using Java to develop your CGI is much easier and more bug-free than C, Perl or any other programming language. You have all the benefits of Java as a CGI-type language and Java simply has better support for building Web applications. Overall, it's an easier and friendlier development environment. For instance, in a servlet, you need only a few simple print statements to output information to the Web.

By using the Servlet API, the developer doesn't have to worry about the inner workings of the server. Form data, server headers, cookies, etc. are all handled for you by the servlet's underlying classes. Additionally, because the servlets are written in Java, you can move them from one server to another for deployment and not worry about the OS or the type of server. This advances Java's whole notion of "write once, run anywhere."

Perl advanced this same notion. You could write a Perl program and move it from one server to the next. But Perl is an interpreted language and it's going to be slower to load the Perl interpreter and execute a Perl script. It is true that there are now some approaches for running the Perl interpreter in-process, but Java is still a more robust and strongly type-checked language and a much safer solution for CGI development.

In the end, the biggest difference between CGI and servlets is performance. There's a single Java virtual machine running on the server and the servlet is loaded once when it is called. It's not loaded again until the servlet changes, and a modified servlet can be re-loaded without restarting the server.

The servlet stays resident in memory and it's very fast. Static or persistent information can be shared across multiple invocations of the servlet, allowing you to share information between multiple users. For example, if I want to submit something to a database, I can start the task in a separate Java thread and tell the user to come back in 15 minutes.

One more important thing, servlets are modular; each servlet can perform a specific task and then you can tie them together. Servlets can talk to each other. I can do something called "servlet chaining." I can take the output of one servlet and forward it to the next servlet to process. This is very powerful because the servlets themselves don't need to know that they are going to be used that way.

What examples of servlets can you describe?

A simple example is building an information filter. Let's say you have a servlet that fetches text from a database and displays it for the user. Independently, you might write another servlet -- a favorite of mine is languages -- a servlet that parses the English language and attempts to translate it to another language, say French. You could chain the two servlets together so that the servlet that retrieves information from the database sends it to the servlet that does the translation.

This might be invoked by naming the servlets in sequence, as below:

/servlet/DBRequestServlet, FrenchTranslatorServlet

Using servlet chaining, you could translate any servlet's output, not just your own servlets. 

Another example is what is commonly called "content-fitting." We've written a servlet that takes any frame-based page and converts it to a table-based page layout. This is one possible way to handle all the different presentations that are often required on the Web -- no images, no frames, etc. You write a servlet to adapt the page content to different styles of presentation. If the user doesn't want to see heavyweight images, I send the document through a servlet that strips out large images. While this might be done in CGI, it's infinitely easier with servlets. 

Is the Java Servlet API at the early stages of development?

It's early on, definitely. However, the Servlet API is very simple. As a consequence, it is pretty stable.

The Servlet API, like Java itself, is being constantly improved by JavaSoft. There will be a few things to add in the future. In the next version of the Servlet API, I expect that session-tracking will be built-in and JRun will support it immediately.

Is Sun committed to supporting the Servlet API?

Sun seems very committed. I have to say they seem more committed to the Java Web Server. I'm not sure why. As a server toolkit it's great, but as a stand-alone Web server, there are few compelling reasons to use JWS because native servers are simply faster and have more features. Once you can run servlets on any Web server, you don't really need JWS.

Will there be a market for Java servlets?

We've been doing Web development for many years and what's been painfully obvious to me is everybody is implementing the same programs over and over again. We aren't really able to leverage the work that other people are doing so we do yet another implementation. Servlets can change this state of affairs. You will be able to find servlets that perform these fundamental tasks and you'll be able to build an application by tying these components together. It's very hard to reuse CGI code today.

For instance, we've written a servlet that allows you to communicate with a CyberCash payment server. There are probably dozens of scripts to do this, some good, some not so good. In fact, the scripts from CyberCash are written in Perl. Our CyberCash servlet is fast, small and cross-platform. This servlet is meant to be a standard component of any online shopping cart system. 

You produce a product called LiveSite that allows you to communicate with Java servlets by inserting tags in the HTML.

This is aimed at the Cold Fusion or ASP developer. LiveSite is a servlet that supports close to 100 "macros" that users call in their HTML. These macros do useful things like handle file I/O, string processing, and database access. What makes LiveSite unique is that servlets can also be mapped as new macros. The administrator can assign any macro name to any servlet. A macro invokes the servlet inside an HTML document; it can pass parameters to the servlet and format the result on the page.  So LiveSite provides an easy and powerful interface to using servlets.

Servlets may be the best possible use yet of Java. Applets are too slow to load and execute on the client side. What do you think?

My personal feeling is that most of the time, Java on the client is overkill. You have way more flexibility with Dynamic HTML to create more powerful client-side applications.

But Java as a server-side tool is just awesome. The good thing is that you can realize the power of Java right away. You're not dependent upon browser support. You don't have the JVM versioning problems that you face with client-side Java. We're using the latest JDK right away. When a new version comes out, we don't have to worry about Java support on the browser.

One last example of something we've done. We've written an in-line Java servlet that can process Java code embedded in an HTML document. We created a single new HTML tag "<JAVA>" that allows you to insert Java code in your HTML when you need it. Our servlet actually creates a servlet from your HTML. When a page is requested, our servlet will take the HTML, build a servlet out of it, and execute it, returning the results to the server. You don't need a full-blown development environment, in fact, you don't need any development environment. This is great for tasks that may be small enough to do in a few lines of Java code.

The number of potential applications for Java servlets is quite large, I believe.


Other articles in this series:

Developing Java Servlets: A Tutorial
In this first part of a series on developing Java servlets, William Crawford shows how to create a basic servlet. It includes information about downloading the Java Servlet Development Kit from Sun.
Java Servlets Reference Guide
This guide organizes useful information for Java servlet developers.

Click HERE to visit the all new DesignShops.com!
Web Review copyright © 1995-99 Songline Studios, Inc.
Web Techniques and Web Design and Development copyright © 1995-99 Miller Freeman, Inc.
ALL RIGHTS RESERVED