Developing Scalable, Reliable, Business Applications with Servlets

Print-friendly Version

Articles Index

About a year ago, the technology group at Razorfish was presented with the challenge of developing a distributed web-based business application. Our immediate need was a scheduling application. But it was clear that we needed to create an intranet-based application that would not only provide us with our immediate scheduling needs, but could also be expanded in a modular way to allow us to add function modules when we needed them.

Our organization at Razorfish has to support many different kinds of users, altogether about 60 individuals, who interact with the system in many different ways.

Ultimately we were looking at an intranet; a project-management system that would provide: calendaring, scheduling, project management, and time tracking. We wanted to provide a framework for our organization that would allow us to authenticate each user and give them individual workspaces, tailored to their particular needs.

The application had to meet the following requirements:

• Platform-independent on the client side, because the application would be used by PC, UNIX, and Macintosh users.
• Platform-independent on the server side, because the environment included both UNIX and Windows NT servers.
• Be able to connect to a variety of databases, since potential data sources included Oracle, Informix, and SQLServer.
• Be able to run on different web servers, because, believe it or not, the environment included: Apache, Netscape, Java Web Server, and Microsoft IIS (this quickly ruled out proprietary scripting languages such as Netscape's LiveWire or Microsoft's Active Server Pages).
• Total latency (network + web server + database) of no more than a few seconds per request.
• Easy to implement and low cost.
• Highly modular so that more functionality could be added in the future.

We realized that we had to develop the ultimate in Write Once, Run Anywhere: platform-independent on the client and server side, able to run on all major web servers, and able to connect to all major relational databases.

Finally, we found the solution that best met all these requirements was Java Servlets, with JDBC on the server side; HTML, and JavaScript on the client side. Servlets and JDBC gave us the platform-independence, the ability to run on any web server, and the flexible database connectivity that we needed.

Servlets Everywhere

At the time we began development, we took it on faith that the Servlet API would soon be ported to other web servers (Apache, Netscape, IIS), and of course our faith has been amply rewarded! Not only are Apache, NSAPI, and ISAPI servlet plugins available from several vendors, but high-powered, Java technology-enabled application servers like WebLogic's Tengah and ATG's Dynamo are fully servlet-compliant.

The HTML/JavaScript front end gave us the most lightweight platform-independent solution and was adequate for our needs because our interface, besides a few forms, consisted mostly of information presentation.

The Servlet API provided us with a simple, robust, and powerful object framework for building this HTML-based application, including objects for retrieving arguments from a web-server request, a simple stream interface for sending the HTML response to the client, and even more advanced functionality, such as cookies and server-side includes of servlets.

The Servlet API is actually one of the most complete of its kind in any language for writing an HTML-based application, and also provides you with access to the rest of the JDK rich APIs. In addition, the Servlet API continues to expand (JDK 1.1 added page compilation, session tracking, templates, and servlet Beans).

Not Just A Better CGI

Although servlets use the HTTP protocol and HTML as a means of communication just as a CGI script does, there are important differences that we took into consideration both when we decided on the servlet solution, and when we actually implemented it. One major difference is that Java Servlets are direct extensions to the web server. They are simply Java objects that are loaded dynamically by the web server's Java Runtime Environment when needed. For each request to a servlet, a lightweight thread is spawned to handle that request (as opposed to starting a whole new process), which dramatically increased the performance of servlets over CGI scripts for our application. The key is to make sure that most of the large-scale manipulation of data (filtering, sorting, etc.) is done by the relational database, because that is what databases do best. The servlet then consists of mostly business logic and routines to format relatively small data sets into HTML.

Another important difference we found between servlets and CGI is that a servlet's thread doesn't have to terminate once it has sent back its response. A servlet can act like an application server that maintains persistent information between requests. In fact, the Java Web Server (as well as all the third-party web server plug-ins we've seen), includes an administration tool where one can specify that the servlet is to be loaded during the server's startup like a service. In our application, for example, we used servlets to maintain open JDBC database connections. When the servlet handles a new request, it simply hands off an existing database connection. Avoiding making a new connection to the database for every request was critical for meeting our performance requirements, because opening the connection can easily add 1-2 seconds of latency.

A Mini-Application Server

Building on this concept of a servlet as application server, we developed our application as a group of separate, but interconnected modules that the servlets instantiate dynamically upon request. The main servlet handles connection to the databases and user authentication for all modules. When the main servlet receives a request, it determines which module is to be loaded. The module is always the first parameter in the request, so a request looks like:

 
 /servlet/MyServlet?module=mymodule& ....,

and then dynamically instantiates the module simply by using the module's name. The code to do this is included below.

Every module is a subclass of the abstract class mModule. The mModule object includes the setParameter method (which simply passes along the request, response, userid, database connection, and logfile to the newly instantiated module), and the virtual method process, which is where the module must generate an HTML response to the request it received through setParameter. The task of the servlet's HTTP request handling methods, doGet and doPost, is then to simply instantiate the requested module, pass it the necessary parameters, and invoke its process method, as shown below:

    // instantiate an object of the requested module
       mModule mm = null;
    try {
     Class c = Class.forName( "com.razorfish.app."
                 + (String)appModules.get(module) );
     mm = (mModule) c.newInstance();
    } catch (IllegalArgumentException iaex) {
     printError(res, "Specified module not found");
     return;
    }


    // pass request parameters to the appropriate
    // module and go
    mm.setParams(request, 
                 response, 
                 user_id, 
                 database_connection, 
                 log_file);
    mm.process();

The overall architecture and how each component contributed to fulfilling our objectives is summarized in the attached diagram.

Servlet Application Architecture

There are many features of servlets that make them easy and attractive to use. These include:

• Easily configured using the GUI-based Admin Tool.
• Can be loaded and invoked from a local disk or remotely across the network.
• Can be linked together, or chained, so that one servlet can call another servlet, or several servlets in sequence.
• Can be called dynamically from within HTML pages, using server-side include tags.
• Are secure--even when downloading across the network, the servlet security model and servlet sandbox protect your system from "unfriendly" behavior.

The Advantages of the Servlet API

One of the great advantages of the Servlet API is protocol-independence. The Servlet API assumes nothing about:

• The protocol being used to transmit on the Net
• How it is loaded
• The server environment it will be running in.

These qualities are important, because it allows the Servlet API to be embedded in many different kinds of servers. There are other advantages to the Servlet API as well. These include:

• It's extensible--you can inherit all your functionality from the base classes made available to you.
• It's simple, small, and easy to use.

With servlets Razorfish was able to implement a flexible, scalable, modular application architecture with far less effort and greater maintainability than any comparable solution.

About the Authors

Oz Lubling and Leonardo Malave both work for Razorfish, a strategic digital communications company based in New York City and known for its award-winning design, original content and mission-critical digital solutions.

Oz Lubling, Director of Technology at Razorfish, where, he develops back-end technical solutions, user interfaces, and is expert in online communications. He has worked on projects for Pepsi, Microsoft, Time Warner, CBS, Bankers Trust, America Online, Revlon, AT&T, Sony, and IBM. Oz received a B.A. and an M.A.in Computer Science from Brandeis University. Leonardo Malave, an experienced software developer, creates database solutions for Razorfish clients. He has worked on projects for AT&T, CBS, and Sapient Corp. Leo holds a B.S. in Electrical Engineering from the Massachusetts Institute of Technology, and completed his senior thesis at the MIT Media Lab.