4.5 Distributed Emergent Systems
5.1.1 Case Study: Emergent Web Server
The local scenario consists of evaluating the autonomous composition and opti- misation of an emergent web server. The Emergent Web Server is a single web server program autonomously assembled from small reusable components in a repos- itory. The web server architecture, illustrated in Fig. 5.1 has the following main
5.1. Local Emergent Web Server 108 interface that support the realisation of a web server program: RequestHandler, HTTPHandler, Cache and Compression. Each of these interfaces realise a part of the web server, and they have component variants (i.e. components that implement the same functionality in a slightly different manner). TheRequestHandler defines the concurrency model of handling incoming TCP requests, having two compo- nents providing two different models. The component RequestHandlerTPC creates a thread per connection received. In contrast, the component RequestHandlerPT creates a pool of threads and assigns each incoming connection to a thread. In case all threads are busy, the system places the connections to a queue in the thread. The threads are kept in a circular list, and the connection is always assigned to the next thread in the list (i.e. round robin).
The interface HTTPHandlerimplements the HTTP protocol. This standard im- plementation is provided by the HTTPHandlercomponent, which fetches requested files from disk and send them directly back to the client. Slightly different implemen- tations are provided by HTTPHandlerCH, HTTPHandlerCMP and HTTPHandlerCHCMP variants which require other interfaces for their implementation. The component HTTPHandlerCH implements the HTTP protocol, particularly the GET method, by firstly checking whether the requested content is stored in an in-memory cache; if the file is cached, the component returns the stored requested file, otherwise the component fetches the content from the disk and directly returns the file to the client. After returning the requested file, the component caches the file’s content. The HTTPHandlerCMP component, on the other hand, fetches the requested file on the disk and, before sending it back the client, compresses the file content before re- turning it to the client. Finally, the componentHTTPHandlerCHCMPworks as a com- bination of HTTPHandlerCH and HTTPHandlerCMP components. It verifies whether the requested file is in cache; in case it is not, the component loads the file from the disk, compresses the file, and sends the compressed file to the client. After the compressed version of the file is sent, the component stores it in cache.
TheCompressionandCacheinterface support different HTTP implementations, used specifically by the HTTPHandlerCH, HTTPHandlerCMP and HTTPHandlerCHCMP components. The components that implement Cache and Compression interfaces
5.1. Local Emergent Web Server 109
Figure 5.1: Architectural representation of the web server compositions.
are generic and reusable. The cache component, for example, stores a generic string of bytes, and each of its variants implements a different item replacement strategy. The FS component implements a simple First-In-First-Out (FIFO) strategy, where the first item cached is the first item replaced once the cache is full. TheLFUcompo- nent implements the Least Frequently Used strategy, replacing the item that has the lowest number of access. The MRU component implements the Most Recently Used strategy, replacing the last accessed item. TheLRUcomponent implements the Least Recently Used replacement strategy, where the item that was first accessed (i.e. the accessed ‘timestamp’ is the earliest) is replaced. BothMRU and LRUrequires a time stamp or (age bits) to determine when the items were accessed in order to select the
5.1. Local Emergent Web Server 110 most recently accessed or the least recently accessed. TheRRcomponent implements the Random Replacement strategy, where the items selected to be replaced are cho- sen randomly. TheCachecomponent does not implement any replacement strategy. Instead it considers an infinite amount of cache space and keeps caching new items until it runs out of memory. Finally, theCompressioninterface has two component variants: theGZandDeflatecomponents. According to the HTTP 1.1 specification RFC 2616 (https://tools.ietf.org/html/rfc2616}): the GZ component imple- ments the gzip compression algorithm (RFC1952), and the Deflate component uses thezlib format and the deflate compression mechanism (RFC 1950).2
A functional web server software instance is realised by selecting a single compo- nent in each one of the interfaces defined in the architecture in Fig. 5.1. For example, by selecting a single component available in theRequestHandler interface, another component in the HTTPHandler and depending on the component selected in that interface, it is required to select another component in Cache and/or Compression interface. The number of compositions possible is calculated by adding 2 (number of compositions when selectingHTTPHandlerCMP) plus 1 (number of composition when selectingHTTPHandlercomponent) plus 12 (number of compositions when selecting HTTPHandlerCHCMP– which is the result of multiplying 2, the number of compression components, times 6, the number of cache variants) plus 6 (number of compositions when selecting HTTPHandlerCH component). The result of the addition is 21, con- sidering that any of those 21 could be composed using either RequestHandlerPT component or RequestHandlerTPC variant, we multiply 21 times 2, resulting in a total of 42 unique compositionsfor the web server.