Java is the hype language of the year, and software that regards anything of itself is written in it. But the seasoned computer specialist doesn't think much of trends and is sceptical. After all, he knows that Java programs are supplied in bytecode, and they have to be compiled before they can be executed: compared with traditional programming languages, such as C or C++, surely a considerable performance slump. Therefore, for actual operation, a WWW server written in Java should be almost impossible to implement.
The WWW Consortium counters these doubts with some impressive benchmarks. According to these figures, Jigsaw's server speed is considerably faster than that of the CERN server, but under that of the Apache. At least in terms of speed therefore, Jigsaw qualifies as a proper WWW server, though the additional effort of the bytecode interpreter mustn't be forgotten. The better - in other words, object oriented - server design seems to more than compensate for this effort, something which leads to the hope that it will work really quickly when a just-in-time compiler is available.
Up to this point, Jigsaw isn't actually anything special, just one of many WWW servers. But some of the special features are interesting, and these make it stand out from the crowd.
All software written in Java automatically profits from being platform independent. As a rule, there is no porting effort at all, at least when the author takes into account the small subtleties - for example, that the dividing symbol between directories isn't always '/', but on various operating systems that are used here and there is '\'. If the programmer allows the Java program to consult the appropriate system properties, then there's nothing preventing platform-spanning application usage. This is the case with Jigsaw: all that you have to do is unpack it, set the CLASSPATH variable and start the Java interpreter (see the RefID138529_1:listing). Thanks to universal bytecode and virtual Java machines, that's all that is necessary, regardless of whether the server is to be installed under Unix, Windows NT or even Windows 95. Java runs, according to the words of the author, Anselm Baird-Smith, on all architectures "without no changes".
A second advantage that the properties of the Java language make possible, but which doesn't appear from nowhere like the bytecode portability, is the dynamic expandability of Java applications. Java takes advantage of this and the system administrator - or the person with rights, or with the ability, to configure Jigsaw (note the fine difference) - can include their own Java classes in the server. That's possible during operation too, it's not necessary to stop the server and then restart it.
Along with the clearer, object-oriented server architecture, Baird-Smith names another reason for the speed advantage of the Jigsaw server compared to the CERN server: the optimised, internal data representation. The server considers every object that it's able to deliver as a resource, for example a file or directory. Depending on the type, information such as file type, date of the last change, expiry date or access protection is also included. The main attraction is that Jigsaw holds numerous resources in a cache if possible. So when there is another access to the same resource, in an ideal case the server doesn't have to make a disk access at all, but serves the client directly from cache. It's therefore clear that it profits from the main memory being as large as possible.
Resources are full-blown Java objects and as such instances of classes. Java defines a range of classes, especially one called w3c.jigsaw.resources.Resource, the parent class of all the objects provided by the server. Important sub-classes of it are w3c.jigsaw.resources.HTTPResource for everything that the server distributes using HTTP (Hypertext Transfer Protocol), as well as w3c.jigsaw.resources.FileResource and w3c.jigsaw.resources.DirectoryResource for what comes underneath that - almost in any case. Entries within a DirectoryResource don't necessarily have to be files or further directories. Any number of sub-classes of Resource such as w3c.jigsaw.resources.RelocateResource are allowed. This class doesn't have any pendant in the file system, but is just seen in the server's name space. An object answers a GET request with a redirect response: it causes the WWW client to look for the file required at another URL.
Persistence is an essential property for resources. That means they survive beyond the server process and are available unchanged in a later server incarnation. Resources' attributes can be edited at administration level. More about that later on.
w3c.jigsaw.forms.CgiResource is taken from the resource classes. This class handles the special case of processing forms with a CGI script. Note the component forms in the full class name. There isn't a class for general calls of CGI scripts.
This fact leads to two important concepts of the Jigsaw server: the expandability and the forms support. The first of those points is just discussed here in short. If you miss having a class for general CGI processing, such as w3c.jigsaw.resource.CgiResource, you can make one yourself and implement the call mechanism for CGI scripts. The class compiled to bytecode is integrated in the server at run time. Like the rest of the server configuration, this procedure takes place over forms. How that works is demonstrated with a small example.
|
Overview.html: attributes can be edited using a form. (diagram 1) |
Let's say the Webmaster wants to edit the attributes of the resource Overview.html in the server's root directory. To do this he uses his Web browser to call up URI (Uniform Resource Identifier) http://my.host.de/Admin/Editor/Overview.html. The server responds with a form which contains the current attributes of the resource, as shown in diagram 1.
The fields can be changed as desired, or as is necessary: you can configure the expiry date, in the field content-language you can set the language of the document, and so on. As soon as OK is clicked, the server permanently notes the new settings. If you are using Jigsaw with a version of the JDK older than version 1.0.2, for example under Linux, there are considerable limitations at this point. An attempt to change a text field causes a thread that executes this command to crash. The server itself carries on running, but it seems unstable.
|
Administering the server using the server: simply call up http://my.host.de:9999/Admin/. (diagram 2) |
Changes initially take effect only on the server cache in the main memory. Depending on the number and size of all the other resources in the main memory, Jigsaw stores the modified resource either sooner or later on the hard disk. To be sure that no changes are lost, you can't just simply stop the server, you have to exit it properly - by calling up resource /Admin/Exit (for administration options see diagram 2). However, this procedure is not very good and error-prone. In a later version of the server, it should be possible to safely end it with just a kill signal.
After changing settings that don't affect resources but that affect the server itself, it has to be restarted so that these changes take effect. That's necessary if the server is to wait for accesses on a different port to the pre-configured 9999. Restarting the server - for which an appropriate button appears directly after changes have been made - leads to a run-time error under Linux with JDK 1.0.1. This can be rectified by stopping and then restarting the server.
Implementation of authentication mechanisms is important for a server, in other words, who is allowed to call up which resources or to create or modify them. With Jigsaw this is especially critical, because the configuration runs over the server itself. In other words: someone who has access to a sensible administration area has access to the whole server. Basic Authentication, defined by HTTP and implemented by Jigsaw, isn't sufficient for protecting the server's configuration because the user name and password are transmitted in practically plain text. Secure authentication procedures aren't available in Jigsaw. The software is still at alpha stage though, so at the moment perhaps one shouldn't expect more.
The first step is for the Webmaster to construct a protected area, in the WWW context this is generally called a realm. Resources can be organised into realms, so that the users wanting to access them have to prove their identity to the server. The server then decides whether a user is allowed to make the desired access. For access protection of the server's administration functions, a realm called Admin is set up, using a form like the one shown in diagram 3. If a protected area has been set up, the Webmaster can then enter one or more users who are to be known within this realm. Here, that's user 'Klute'.
|
|
Realms & Users: Jigsaw's administrator can set up areas that only certain users are allowed to access (diagram 3). Administration can be carried out using a form. (diagram 4) |
|
The new resource, /Admin, must first of all be informed that it belongs to the Admin area, and secondly, be made aware who is allowed to access it. We've already shown how resource attributes are edited. A form for the resources affected here is generated by calling up /Admin/Editor/Admin. On the bottom of the page, a little out of view, is a link called 'Add Filter'. Using this function resources can be provided with filters, as the name suggests. These are special resources which a HTTP request 'runs' through. Input filters process the request before the actual resource is called; output filters manipulate the result.
|
|
Asking for a password: the administrator just has to enter the authentication filter for the desired area. (diagram 5) |
Authentication is implemented in Jigsaw as an input filter. Before the server delivers the desired resource to the client, the request has to successfully run through this filter. Up to now only a relatively simple filter (w3c.jigsaw.auth.GenericAuthFilter) is available in Jigsaw and this filter executes the authentication as described with IP addresses and Basic Authentication. The administrator enters the class description within the AddFilter function (see diagram 5) and then anyone who wants to access the Admin area has to provide a user ID and password.
The filter's most interesting attribute is the realm and the users or user groups who are allowed access. The field methods names HTTP methods which govern the access limitations. If nothing is provided here, the rules for all the methods apply. After clicking on the OK button, a user name and password is required for each access to the administration area.
Filters aren't just useful for authentication, they provide a mechanism which can be used in general for processing requests or their results. Some examples are implemented in Jigsaw. A filter, for example, limits the number of simultaneous access on a resource, another counts the number of accesses, a further one redirects data intended for the user through an external program. PICS (Platform for Internet Content Selection) is also supported with a filter. Further filters can be programmed as desired and included into the server like resources.
In this alpha version, Jigsaw represents an interesting implementation of an innovative usage. The platform-independent extension of the server functionality using Java classes may take a significant amount of their work in the medium term because for generating a dynamic document an external program isn't started. Developing in Java is also easier than creating special server modules, as Apache allows for example.
Trivial everyday tasks, such as creating a new document area, are still very complicated though. The documentation is incomplete, especially for the PICS support.
Other functionality, that a conventional server offers, is still missing. Changing the user status within a certain area, for example, and serving documents from a user's home directory are two missing functions. But this can be put down to the current alpha status. If you should so desire, you can consult the supplied source code which should clear up any problems when viewed appropriately closely. Or you can wait for the next version of the server - by the time this article appears it will probably be available - and then fetch it from the W3C's server (ftp://ftp.w3.orb/pub/WWW/Jigsaw/).
Rainer Klute
is an IT graduate and managing partner of NADS GmbH in Dortmund, Germany.
Literature
[1] Anselm Baird-Smith; Jigsaw Overview
[2] Anselm Baird-Smith; Jigsaw: An Object Oriented Server
[3] Anselm Baird-Smith; Jigsaw Performance Evaluation
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 09/1996 von iX entnommen.
Parallelprogrammierung - die Kunst der Multi-Core-Nutzung
Agile ALM - agile Praktiken im Application Lifecycle Management
Webentwicklung - Applikationen für mobile Clients
HTML5, CSS3, WebGL: Das iX-Sonderheft zum Thema Webdesign fasst die wichtigsten Neuerungen der aktuellen und kommenden Webstandards zusammen.
