Are you Being Served?

If you have spent any time in England or any of the Commonwealth countries or watch much PBS, you probably have seen the long-running TV situation comedy “Are You Being Served?” about a bunch of wacky department store clerks who get into the most ridiculous jams while trying to service their customers.

Service industry hi-jinx aside, fulfilling orders and requests is, for the most part, a methodical process involving predictable parameters for input and output — a task that’s better suited to computers than human clerks. Once you’ve committed to going hi-tech, the question turns to software. Now, thanks to Jeeves, Java is one of your options.

In this column in our series on the Java API family, we introduce the Java Server API, also called, in somewhat quaintly British fashion, Jeeves. This API allows programmers to rapidly create connection-oriented server applications using a pre-defined architecture and providing the supporting object classes necessary.

Support service

The Server API is very much designed for the Web, although technically it can be used for any generic TCP/IP services. Jeeves itself is an HTTP or Web server that can be extended to include other protocols and applications. Each Web connection is processed by a servlet. This is similar in concept to a server application, but with minimal overhead and handling only the portions of the service workflow for which it is designed. Programmatically, the servlet is similar to an applet with the exception that there is no need for a graphical interface to the program. It is a piece of Java bytecode that can be downloaded from the network if necessary.

The Jeeves framework provides all the needs for handling multiple connections, managing a pool of servlets, keeping track of backlog, and dispatching service requests using a given set of classes.

Basically, it begins with the main server loading up, binding to a TCP/IP port, and starting a pool of servlets. The server resides on this port and accepts incoming connections, which are placed in a queue for processing by the servlets. Before passing this connection to an awaiting servlet, the server checks the servlet pool to see that enough servlets are available for future requests. The server can maintain a fixed pool of servlets or it can dynamically add and remove servlets from the pool to satisfy the requirements of the application.

The server will pass a request only to a servlet of the appropriate type for handling the request. There can be several pools of servlets, each a different type of request handler. For example, one servlet can handle HTML file requests, another can serve CGI requests, and still others can handle application-specific requests. Each servlet is designed to handle only its own area of service and thus does not need the huge overhead of traditional Web servers, where each server process needs to know how to handle everything. This makes for compact programs that can execute in a fast and efficient manner, supported by other programs that can handle other tasks more suited to them.

The perfect butler

One may wonder why we need such a complex system when we already have Web servers and the Common Gateway Interface (CGI). The most common answer is that CGI is limited, slow and inefficient. Although CGI still handles the bulk of all processing on the Web, developers have known for a long time about these limitations. However, it is still the only common interface on almost all Web servers.

Recognizing these limitations, Web server vendors like Netscape and Microsoft have taken to creating their own C language-level interface — NSAPI and ISAPI, respectively. These two APIs certainly allow for faster processing, but are still platform-dependent. The easy answer was to create a system that is not limited and is platform-independent; hence, Jeeves.

Jeeves strives to provide a simple, flexible, high-performance, secure, backward-compatible, standards-based server with platform independence. The servlet concept and classes support all these goals at different levels.

The basic classes all have been predefined and made available to the public. This makes it easy to create new servers. The servlet is quite flexible in what it can do using Java. It certainly is a much higher performance system than CGI. The security system for Jeeves is quite thorough, as we shall see shortly. Jeeves already supports a CGI Servlet to handle the traditional jobs that use this interface, and you could certainly make other servlets to support NSAPI, ISAPI, and so on. The use of Java makes the system an acceptable industry standard as well as platform-independent.

A million little servlets scampering around the Web

Making a servlet available over the network would be asking for trouble if there were no security mechanisms. In the ideal world, the server should be able to start up any servlet needed to provide the processing functionality for any given request. In truth, however, any servlet downloaded from the network is suspect, and thus should be limited or controlled.

Jeeves provides a useful design concept known as the Server Security Sandbox. Each untrusted servlet is located within a “sandbox” so that it can play with the others but only strictly so. There are four main species of servlets: Jeeves servlets, local servlets, signed network servlets, and unsigned network servlets.

Jeeves has its own internal functions, which are built as servlets. These functions have total access since they are just part of the program itself, and are local to the machine as well. A local servlet resides on the same system as the Jeeves server; it has full access as well since it is part of the trusted set of servlets on the local system. Signed network servlets have a trusted signature that is accepted by Jeeves and can have controlled access to different parts of the server as controlled by the Jeeves administrator. Finally, unsigned network servlets are loadable over the network and are strictly controlled by placing them within a server sandbox.

The sandbox is actually a group of servlet threads that are monitored by the servlet administrator program and have a limited set of authorized access rights. The basic types of access rights are:

• HTTP request objects — this allows access to an incoming request and all the information associated with the request.
• HTTP response objects — this allows access to create an HTTP response to a client based upon given parameters.
• HTML File Access — this allows access to read or process files served by Jeeves.
• Jeeves Configuration Files — this allows access to the configuration data for Jeeves.
• Access Control Lists — this allows the servlet to hold a list of access rights for communications with other servlets.
• Peer Servlet Thread access — this allows access to the running threads of other servlets for communications.
• Peer Servlet Capabilities context — this allows access to the information about the capabilities of other servlets.
• Networking APIs — this allows access to use the Java networking APIs.

Although these security specifications have been identified, the further definition and full implementation of these security services is yet to come.

The man who did everything

The uses for the Jeeves server system have few limits. It can be employed in a significant number of ways, primarily through the merits of the servlet concept. Each servlet can be written to perform any common processing task on the server side. For example, a pool of servlets can be the interface between the Web server and database; these servlets maintain state information about access rights and database record location.

Another example would be for control applications; a servlet could act as a remote agent for a Web user, performing tasks such as resetting systems, retrieving data, and performing various control functions. From a network administrator’s point of view, you could create a servlet that monitors your machine room and controls humidity, temperature, power, and lighting for the room from your desk. A servlet could even act as an SNMP agent, but even go the step beyond to controlling remote systems.

Jivin’ with Jeeves

If you wish to become directly familiar with Jeeves, you are in luck. JavaSoft has released a preliminary alpha version of Jeeves so that programmers can get a head start on their server applications. This software is available free of charge from JavaSoft — with export and modification restrictions, of course. JavaSoft also offers a few example servlets that will give you a proper feel for the API.

We created one servlet of our own just as an example. With substantial enhancements, this servlet might be used as a basis for monitoring your system. The goal, however, is to show you some original code that may help you in your efforts to write a servlet.

We invite you to view the System Load Servlet in action, as well as the source of this servlet.

Basically, this servlet will show you the load on the system that Jeeves is running on. There are two caveats to our example in that this is not a truly portable Java servlet since it will work fine for Unix systems only. The system load here is generated by the ubiquitous Unix program simply called “w” and the output is displayed inside a Web page. The other caveat is that this is a simple user level status of the system. For more detailed system status information, you may have to use programs like vmstat (to check your virtual memory usage), iostat (to check your disk I/O usage), and so on.

This servlet is very simple in concept. The servlet is loaded into memory when Jeeves starts; when a user goes to this link to the servlet, it executes a program on the server system and redirects the output into the format of a Web page.

Essentially, you could do this with a Perl-based CGI script rather quickly. The benefit of using the servlet based system is that you do not have to load the servlet over and again to execute the program as you would have to with for example, a Perl-based CGI script. The servlet also consumes less memory than if you had to load Perl to execute the Perl script.

The way to improve this servlet is to actually use the Java Management API (JaMAPI) to get the system load. Using JaMAPI we will be able to create a system-independent servlet which could be network loadable. We will talk about JaMAPI in an upcoming article in continuation of our Java API series.

Note that Jeeves is based upon the concept of a Web server. The reason: The future of network computing will be based upon Web technology. This, however, by no means limits your responses to HTTP requests alone. The Java Server API can be made to respond to any protocol and reside on any TCP port. The core functionality certainly is directed towards HTTP and CGI, but all the classes are extensible, and new ones can be made to handle FTP, SNMP STMP, and any other IP service.

Our example shows the very basics of using Java as an Intranet tool for managing your system or your network. Combining Jeeves with JDBC, JaMAPI, and the other Java APIs will allow you to create a very powerful system for just about any problem you are working on. Simply said, the potential is limitless.