--- /dev/null
+<HTML>\r
+<HEAD>\r
+ <TITLE>WWW5 API Workshop - Jigsaw an OO Web server</TITLE>\r
+</HEAD>\r
+<BODY>\r
+<H1>\r
+ <A HREF="http://www.w3.org/pub/WWW/"><IMG BORDER="0" ALT="W3C" SRC="/icons/WWW/w3c_home.gif" WIDTH="72"\r
+ HEIGHT="48"></A>\r
+</H1>\r
+<H1>\r
+ Jigsaw, An Object-Oriented Web server\r
+</H1>\r
+<P>\r
+<I>Anselm Baird-Smith <abaird@w3.org>,<BR>\r
+World Wide Web Consortium,<BR>\r
+April 1995</I>.\r
+<H2>\r
+ <A NAME="introduction">Introduction</A>\r
+</H2>\r
+<P>\r
+Most HTTP servers today, are tuned to serve files. This intimate relationship\r
+ between HTTP servers and their underlying file system has always affected\r
+their design in significant ways: the mapping from URL to their target resource\r
+generally relies on the file system hierarchy and the configuration information\r
+are generally understood as global to the whole server, or in some cases\r
+<I>per directory</I>, but no server today, allows you to fully configure\r
+your server on a <I>per-resource</I> basis.\r
+<P>\r
+In designing <B>Jigsaw</B>, the new experimental server from the World-Wide-Web\r
+consortium (written in Java), we took the opportunity of starting from scratch\r
+to test a new approach: <I>each exported resource is a full object</I>. This\r
+paper will briefly explain the <I>Resource</I> concept of <B>Jigsaw</B> and\r
+its configuration process.\r
+<H2>\r
+ <A NAME=resources>Resources</A>\r
+</H2>\r
+<P>\r
+<B>Jigsaw</B> is made of two different modules: the <I>server engine</I>\r
+deals with incoming connections, decoding requests and presenting them to\r
+the <I>resource module</I> which will perform them and produce either reply\r
+or error messages. The connection between these modules is described by an\r
+interface, so that you can replace them if needed. We will focus here on\r
+our sample implementation of the resource module.\r
+<H3>\r
+ What are <I>resources</I>\r
+</H3>\r
+<P>\r
+In the HTTP specification, a resource is described as "An network data\r
+object or service which can be identified by a URI". The <B>Jigsaw</B> design\r
+takes these words for truth: each resource is an object inheriting from the\r
+<CODE>Resource</CODE> class. As such, they have an associated behavior, and\r
+some internal state:\r
+<UL>\r
+ <LI>\r
+ The <I>behavior</I> of a resource is defined by its Java class (any subclass\r
+ of <CODE>Resource</CODE>). At this basic level, no particular requirements\r
+ are made on the behavior of a resource: it can define whatever methods it\r
+ wants.\r
+ <LI>\r
+ The <I>internal state</I> of a resource is a set of <I>attributes</I>. Attributes\r
+ have an associated description which indicates their name, how their values\r
+ should be saved to persistent storage, how they are restored from persistent\r
+ storage, and enough type information to be able to edit them.\r
+</UL>\r
+<P>\r
+An <CODE>HTTPResource</CODE>, is a resource tuned to handle the HTTP protocol:\r
+it inherits from the <CODE>Resource</CODE> class the ability to be saved\r
+and restored from persistent storage, along with the ability to describe\r
+and access its internal state. At this level of the class hierarchy, resources\r
+are able to handle an HTTP request by generating an appropriate Reply object:\r
+they can be plugged into the <I>server engine</I>. The set of attributes\r
+defined by the <CODE>HTTPResource</CODE> class is made of:\r
+<DL>\r
+ <DT>\r
+ <DT>\r
+ Content language\r
+ <DD>\r
+ The language tag of the resource, describing the natural languages in which\r
+ the content of the resource is emitted\r
+ <DT>\r
+ Content length\r
+ <DD>\r
+ The length of the content of the resource\r
+ <DT>\r
+ Content type\r
+ <DD>\r
+ The type of the content of the resource (e.g. <CODE>text/html</CODE>)\r
+ <DT>\r
+ Expires\r
+ <DD>\r
+ The date at which the resource expires\r
+ <DT>\r
+ Icon\r
+ <DD>\r
+ Any icon associated with this resource.\r
+ <DT>\r
+ Last modified\r
+ <DD>\r
+ The date of the last modification of the resource\r
+ <DT>\r
+ Quality\r
+ <DD>\r
+ A floating point number in the range <CODE>[0,1]</CODE>, indicating the quality\r
+ of the content of the resource\r
+ <DT>\r
+ Title\r
+ <DD>\r
+ The title of the resource\r
+</DL>\r
+<P>\r
+None of these attributes are mandatory: resources that generate their content\r
+dynamically, for example, might not have a predefined\r
+<CODE>content-length</CODE> or <CODE>content-type</CODE>; A resource whose\r
+content is negotiated will dynamically generate its <CODE>quality</CODE>\r
+attribute (typically by using the quality attribute of the selected variant).\r
+<H3>\r
+ Jigsaw resource class hierarchy\r
+</H3>\r
+<P>\r
+Although object oriented, we still want <B>Jigsaw</B> to be able to - at\r
+least - provide the basic functionality of a Web server: serve files in a\r
+filesystem hierarchy. This is handled by two particular sub-classes of\r
+<CODE>HTTPResource</CODE>: The <CODE>DirectoryResource</CODE> class handles\r
+file system directories and the <CODE>FileResource</CODE> handles files.\r
+<P>\r
+The <CODE>DirectoryResource</CODE> class inherits from the\r
+<CODE>ContainerResource</CODE> class the ability to manage a set of children\r
+resources. This last class specifies how resources are looked-up. The basic\r
+algorithm is the following: parse the requested URL into a sequence of\r
+components, then take the first of them, look it up in the server's root\r
+<CODE>ContainerResource</CODE> instance to obtain a target resource. If they\r
+are no more components to look up, then the target is the target for the\r
+URL, otherwise, the target should be itself a <CODE>ContainerResource</CODE>,\r
+to which we delegate the lookup of the remaining components. This lookup\r
+process takes a time proportional to the number of components in the requested\r
+URL, however, one can define its own <CODE>ContainerResource</CODE> subclass,\r
+and override the lookup algorithm all together.\r
+<P>\r
+The <CODE>DirectoryResource</CODE> maintains a <CODE>ResourceStore</CODE>\r
+to keep track of its children. This resource store manages the pickled version\r
+of each child, which is unpickled on-demand when looked-up. An optional\r
+<CODE>ResourceStoreManager</CODE> instance will keep track of accesses to\r
+loaded resource stores, in order to remove from memory the ones that have\r
+not been used for a while.\r
+<P>\r
+Most children of a directory resource instance will be\r
+<CODE>FileResource</CODE> instances. The file resource class defines the\r
+<CODE>head</CODE>, <CODE>get</CODE> and optionally the <CODE>put</CODE>\r
+methods. For the sake of efficiency, the file resource (optionally) caches\r
+the <CODE>content-length </CODE>and <CODE>last-modified</CODE> attributes\r
+(which it gets from the file system), so that <I>if-modified-since</I> request\r
+can be handled without any disk accesses.\r
+<P>\r
+These two classes, defines 90 percent of what a Web server is expected to\r
+do: serve files of some underlying file system. <B>Jigsaw</B> provides more\r
+resources: the <CODE>PostableResource</CODE> class is a basic class for handling\r
+the HTML form's POST method, the <CODE>CGIResource</CODE> class handles\r
+CGI scripts, etc. Of course, the server maintainer has the ability to defines\r
+its own resource sub-classes, and install instances of them as children of,\r
+for example, some <CODE>DirectoryResource</CODE> instance. This results in\r
+a very flexible server extension API. Again <B>Jigsaw</B> provides some basic\r
+packages of classes to help you here, the <B>form</B> package, for example,\r
+provides a high level API to manage HTML forms, allowing you to register\r
+fields of given types, etc.\r
+<H3>\r
+ Resource filters\r
+</H3>\r
+<P>\r
+We have briefly described the basic design of <B>Jigsaw</B> and explained\r
+how it allows for common server features. However, at this point, one might\r
+wonder how authentication is handled.\r
+<P>\r
+<B>Jigsaw</B> defines another important subclass of <CODE>Resource</CODE>:\r
+the <CODE>FilteredResource</CODE> class. Both the\r
+<CODE>ContainerResource</CODE> class and the <CODE>FileResource</CODE> class\r
+inherit from this new class, which provides the ability to filter requests\r
+to some particular target, or set of targets. A <CODE>ResourceFilter</CODE>\r
+is itself a resource (i.e. it has its own class, and it defines its own set\r
+of attributes). Instances of <CODE>ResourceFilter</CODE> are attached to\r
+a particular <CODE>FilteredResource</CODE> instance, and filtersall access\r
+to them: at lookup stage, the filter's <CODE>ingoingFilter</CODE> method\r
+is called with the request as the only parameter, and on the way back, its\r
+<CODE>outgoingFilter</CODE> method is (optionally) called with both the request\r
+and the target generated reply.\r
+<P>\r
+Given this, authentication is implemented as a special filter, whose\r
+<CODE>ingoingFilter</CODE> method will authenticate the given request, using\r
+whatever algorithm it wants. <B>Jigsaw</B> provides one\r
+<CODE>GenericAuthFilter</CODE> class that allows to authenticate requests\r
+by IP addresses, using the Basic authentication scheme or the Digest\r
+authentication scheme, or a mix of the first with one of the others.\r
+<P>\r
+The concept of filters allows for much more than just authentication. Also\r
+provided are a <CODE>DebugFilter</CODE> (that will print requests and replies\r
+to some given target) and an <CODE>AccessLimitFilter</CODE> (that will limit\r
+the number of simultaneous requests to some targets). Logging can be implemented\r
+as filters too resulting in a powerful mean of getting detailed logging\r
+information for only a sub-space of the whole information space exported\r
+by the server. A <CODE>PICSFilter</CODE> has also been integrated into\r
+<B>Jigsaw</B>, allowing it to serve\r
+<A HREF="http://www.w3.org/pub/WWW/PICS/">PICS</A> rating labels with documents.\r
+<H2>\r
+ <A NAME=configuration>Configuration</A>\r
+</H2>\r
+<H3>\r
+ Mapping files to resources, editing resource attributes\r
+</H3>\r
+<P>\r
+At this point, one might wonder how all these objects are created. The\r
+configuration process for <B>Jigsaw</B> was probably one of the most challenging\r
+problem (it is responsible for at least three of the entire re-design of\r
+<B>Jigsaw</B>). The main problem is the following: server administrators\r
+are used to configure their whole server through one single centralized\r
+configuration file, while for <B>Jigsaw</B> <I>each</I> resource might need\r
+some specific information. There are two central pieces to the actual solution\r
+we have tested:\r
+<UL>\r
+ <LI>\r
+ Resource meta description: as we have mentioned previously, each attribute\r
+ of a resource has an associated meta description, from which one should be\r
+ able to at-least deduce a generic editor for this attribute values.\r
+ <LI>\r
+ The lazy resource indexer. To help server administrators, <B>Jigsaw</B> defines\r
+ a special class that will try to create a resource instance suitable to export\r
+ a given directory, or given file. This creation process takes place <I>only\r
+ once</I> in the whole lifetime of the server (resource persists across\r
+ <B>Jigsaw</B> invocations).\r
+</UL>\r
+<P>\r
+The first piece allows for the editing of resource attributes, which is one\r
+part of the configuration process. The current version of <B>Jigsaw</B> comes\r
+with a generic form based editor that allows you to edit any resource on\r
+the server. Although not very user-friendly, this generic editor is mainly\r
+a proof of concept. It should be noted here, that this provides for a very\r
+fine-grain configuration: one is able, for example, to say that the file\r
+<CODE>/pub/foo.html</CODE>'s content type is <CODE>text/plain</CODE> and\r
+not <CODE>text/html</CODE>.\r
+<P>\r
+The second piece tackles with the creation process of resource\r
+instances associated with directories or files. One trivial way to cope\r
+with this would be to ask for the server administrator to declare each files\r
+of its system, along with the requested information (e.g. the class of the\r
+resource to be created for the file, the file's attributes, etc.). This,\r
+of course, is not acceptable. By default (this can be turned off) the\r
+<CODE>DirectoryResource</CODE> class implements lookup in the following way:\r
+it first looks in its resource store for the given child, if this fails,\r
+it then goes to the resource indexer, and asks it for a default resource\r
+instance to export the file. The sample resource indexer can be configured\r
+to create particular instances of resource sub-classes based on the file's\r
+extension, or if the file is a directory, on its name.\r
+<H3>\r
+ Global server configuration\r
+</H3>\r
+<P>\r
+<B>Jigsaw</B>'s configuration is not only made of its information space\r
+configuration: one would like to be able to configure the resource indexer,\r
+the authentication realms or the global server properties (such as its\r
+port number, etc.). One nice thing about the <B>Jigsaw</B> design, is that\r
+if you represent these configuration information as instances of\r
+sub-classes of the <CODE>Resource</CODE> class, then they will inherit\r
+persistency, caching and the ability to be edited (which is really what you\r
+want).\r
+<P>\r
+Due to this, the current <B>Jigsaw</B> release provides form-based edition\r
+of the following pieces:\r
+<UL>\r
+ <LI>\r
+ The resource indexer can be configured through forms: you can declare how\r
+ file's of a given extension are to be mapped to resources, and provide\r
+ a default set of attribute values for these newly created resources.\r
+ <LI>\r
+ Authentication realms are editable through forms too, along with each of\r
+ the users they define.\r
+</UL>\r
+<P>\r
+You can, in fact, install and configure <B>Jigsaw</B> without having a text\r
+editor.\r
+<H2>\r
+ <A NAME=conclusion>Conclusion</A>\r
+</H2>\r
+<P>\r
+We have briefly described <B>Jigsaw</B> architecture, and have shown how\r
+an object based server can implement the basic functionalities expected from\r
+a Web server, and more. We believe that the most important characteristics\r
+of our design are:\r
+<DL>\r
+ <DT>\r
+ Persistency of resource instances\r
+ <DD>\r
+ Web objects should be think of as persistent objects right from the begining:\r
+ they have to persist across server invocation (e.g. the server should be\r
+ able to pickle and unpickle them as needed).\r
+ <DT>\r
+ Edition of resource instances\r
+ <DD>\r
+ The configuration of <B>Jigsaw </B> is done through the edition of resource\r
+ attributes. <B>Jigsaw</B> 's design emphasis on this by having each resource\r
+ embedding a description of itself.\r
+</DL>\r
+<P>\r
+Other design considerations have played an important role in <B>Jigsaw</B>'s\r
+design, in particular the ability to unpickle resources only on-demand (so\r
+that the server don't start by unpickling its whole information space), and\r
+the caching mechanism for managing the number of unpickled resources at a\r
+given time. To conclude, we would like to emphasis on the fact that given\r
+this design, <B>Jigsaw</B>'s configuration is no more in one single configuration\r
+file, but rather spread across the various resources instances.\r
+<P>\r
+<B>Jigsaw</B> is still in its alpha stage, and will be available to members\r
+by May, and to the public by June.\r
+<P>\r
+ <HR>\r
+<P>\r
+<A HREF="mailto:jigsaw@w3.org"><I>Anselm Baird-Smith</I></A><BR>\r
+$Id: Position.html,v 1.1 2010/06/15 12:28:16 smhuang Exp $\r
+<P>\r
+<H3>\r
+</H3>\r
+</BODY></HTML>\r
projects / Benchmarks_CSolver.git / blobdiff