Buffer overruns create a whole class of pernicious Internet security holes. An oddly constructed email message, for example, may cause a certain Internet Message Access Protocol (IMAP) server to overflow a statically allocated buffer, which in turn can enable an attacker to gain control of that host. Recognizing the danger, thoughtful developers work hard to combat it. The Apache Group, for example, has devoted much effort to ensure that the Apache web server’s data structures grow dynamically and won’t cause buffer overruns. You can of course implement safe memory in C or C++, but it requires great diligence and above-average skill. In Java, safe memory is just an aspect of the language. You don’t have to do anything special to take advantage of it.

As network services proliferate, the number of programmers involved in creating them will grow. Not all of these programmers will be able to write memory-safe C or C++ programs. Java can help offset the security risks that come with new network services. What about Visual Basic? It’s true that VB programs are memory-safe. But VB alone is not very useful. As a provider of network services, it relies heavily on packaged components written, for the most part, in C++. The memory safety of these components will vary according to the skills and inclinations of the programmers who build them.

Network services need to handle lots of concurrent requests and respond quickly to all of them. Multithreaded software isn’t the whole answer to this problem, but it’s a key ingredient of many solutions. Java’s thread model is simple and accessible. Again this means that a new wave of developers will be able to exploit a capability that was formerly available only to a more elite group. The tricky problem of thread synchronization, for example, becomes very simple in Java, as we’ll see in this chapter.

The portability of multithreaded Java software plays an important role here too. The platform on which network services run needn’t be a monolithic superserver. Web APIs can stitch together a cluster of commodity servers. That cluster can be compact, tightly coupled, and homogeneous, or it can be far-flung, loosely coupled, and diverse. Either way, Java’s portable multithreading can help you build responsive network services.

Java’s Remote Method Invocation (RMI) provides an elegant way to build distributed software. RMI was invented because JavaSoft saw a need for a simple, lightweight alternative to object request broker (ORB) technologies such as the Object Management Group’s common object request broker architecture (CORBA) and Microsoft’s distributed component object model (DCOM). With CORBA and DCOM, building a distributed version of even the simplest “Hello, world” program is—without specialized tools—a daunting exercise. In an all-Java environment, RMI can simplify this chore.

But even RMI can be overkill. The applications that inhabit the Internet groupware environment are, after all, just good old-fashioned socket clients and socket servers. Java has excellent facilities for interacting with, and implementing, socket-oriented applications. And its URL classes, java.net.URL and java.net.URLConnection, make it very easy for Java clients to use HTTP-based services. We’ll see later in this chapter how it might make sense for a servlet, which is a provider of HTTP-based services, to also be a consumer of other HTTP-based services.

When we use web technology to connect server applications to data, we tend to think in terms of SQL databases and relational data. Java servlets can do that, using the Java Database Connectivity ( JDBC) APIs, just as Perl or other kinds of CGI scripts can, using various kinds of SQL adaptors. But servlets can also manage object data. How? Using serialization, a Java program can write in-memory Java objects to disk storage and reconstitute those objects when reading them back into memory. JavaSoft introduced serialization in Version 1.1 of the Java Development Kit (JDK) to support RMI, which required the ability to send serialized objects over network connections. But you can also serialize Java objects to files, and that means you can create and use very simple object databases.

The servlets we’ll explore in this chapter do just that. They are both, in essence, just web APIs to in-memory Java objects that are made persistent using serialization. These objects aren’t constrained by SQL’s tabular row-and-column format. Like Perl, Java has hashtables and lists, and can combine these to make arbitrarily complex structures—such as the hashes-of-hashes-of-lists (HoHoLs) or lists-of-hashes (LoHs) that we found to be so useful in earlier chapters. Groupware needs these kinds of data structures because it has to model what people really do, and that’s messy. Relationships among people, tasks, events, and resources are complex and fluid. Forcing these organic structures into the Procrustean bed of normalized relational tables can be a painful and unproductive exercise. Object storage can model webs of relationships much more directly than SQL databases can.

The basic object persistence exploited by Polls and GroupCal isn’t an exclusive capability of Java. Perl CGI scripts using modules such as Data::Dumper can achieve similar results. But Java currently offers a better upgrade path to real object database technology. Why would you need that? There’s a limit to the amount of object storage that you can manage in memory and serialize en masse to disk. An object database, such as ObjectDesign’s ObjectStore (http://www.odi.com/) or POET Software’s POET (http://www.poet.com/), creates a kind of object cache, mapping between in-memory structures and disk storage as needed. You don’t need to change your Java code to gain this benefit, because these products can work transparently with your existing hashtables (java.util.Hashtable objects) and lists (java.util.Vector objects). They also provide transaction controls and search capabilities.

Groupware needs object storage. Java servlets can manage simple object stores. And because object database vendors are creating Java bindings to their products, servlets can be easily (sometimes transparently) upgraded to industrial-strength object storage.

A servlet runs in the context of a host that may be a conventional web server, a Java-based web server, or a Java-based application server. In all these cases, the host keeps a Java virtual machine always running, with servlets loaded and ready to respond to requests. To achieve this effect with scripting languages such as Perl or Python, you need special and server-specific adaptations of these languages. mod_ perl (http://perl.apache.org/) binds Perl into the Apache web server and caches Perl code so that scripts run with almost no startup delay. mod_ python does the same thing for Python under Apache. ISAPI Perl and PerlEx (http://www.activestate.com/) likewise adapt Win32 Perl for low-latency invocation under the control of Win32 web servers such as Microsoft’s IIS.

The servlet programming model is attractive because it’s a standard way to do what these various script-engine adaptors achieve by very different means. mod_ perl, for example, is a powerful technology that I use and recommend. But it’s a discipline unto itself, with a learning curve that even seasoned Perl CGI programmers must climb. Because of the way mod_ perl embeds Perl in Apache, for example, you have to be very careful not to contaminate the Perl global namespace visible to all instances of the Apache daemon. In the servlet realm, servlets are more effectively isolated from one another, because a servlet’s scope ends at its package boundary and because each servlet runs on its own separate thread of execution. And once you learn this drill, it’s pretty much the same from one servlet host to the next. Servlets mostly keep the “write once, run anywhere” promise.

How much does this thread-based dispatching enhance the efficiency of servlets? That depends on several things. A Java implementation for Solaris or Win32, where Java threads can map directly to native operating system threads, may run threaded servlets more efficiently than a Java implementation for a version of Unix that has to provide its own pseudothread mechanism. However, it’s not clear that the native-thread approach always wins out over the pseudothread approach. In either case, another key factor is the load placed on the servlet host. The thread-per-request model works pretty well, but it isn’t infinitely scalable.

At very high levels of traffic, the overhead required to create a thread for each request becomes a real burden. That situation calls for a thread-pool model in which the server manages a fixed-size pool of request-handling threads. Should you worry? Not unless you plan to deploy servlets on a very busy public server. On an intranet server that handles hundreds of requests per day, or even on an Internet server that handles thousands, the thread-per-request model is good enough.

Pure Java-based web servers are one way to host servlets. Sun’s Java Web Server (JWS, http://www.sun.com/software/jwebserver/), a commercial product, was the first servlet host I used. Open-source Java Web servers include Jetty (http://www.mortbay.com/software/Jetty.html), Jigsaw (http://www.w3.org/Jigsaw/), and Acme.Serve (http://www.acme.com/).

You can also host servlets using conventional web servers. Sun’s Java Servlet Development Kit (JSDK) includes an adaptor that enables the Netscape, Microsoft, and Apache web servers to host servlets. (The JSDK also comes with servletrunner , a stripped-down servlet host that you can use to exercise servlets in a standalone fashion.) A free adaptor for Netscape’s web servers is Gefion Software’s WAICoolRunner (http://www.gefionsoftware.com/). Commercial adaptors for various web servers are available from Live Software (JRun, http://www.livesoft.com/), and other vendors. O’Reilly & Associates’ WebSite Pro includes servlet support.

Should you use a Java-based web server or a conventional web server to host servlets? That depends on what kind of web server you prefer. Sun’s JWS, for example, is a full-featured web server. It has a complete authentication model that can restrict access to URLs based on user and group permissions; it comes with a GUI administration and monitoring tool that runs as a Java applet; it can establish SSL-secured sessions with browsers. JWS is a fine general-purpose web server. But, if like many people, you’re already committed to Apache, IIS, or another conventional web server, you don’t need to switch to JWS or another Java web server just to host servlets. Servlet-hosting adaptors enable you to leverage what you already have while adding servlets to the arsenal of tools that you can use to create groupware applications.

A servlet host can also be a pure application server. For example, I like to run servlets under the control of Acme.Serve, because it’s so easy to control the services provided by this small and simple Java web server. Its file-serving capability is just another servlet, which you can easily disable. In that configuration Acme.Serve responds only to the URLs handled by the servlets you attach to it. Contrast this with JWS, which, because it’s a full-fledged web server that installs all sorts of default behaviors, creates a whole new set of potential security risks that need to be analyzed and doors that need to be locked.