Previous Table of Contents Next


2.4.2. An Overview of an OO Web Server Communication Software Architecture

Figure 2.4 illustrates the general object-oriented communication software architecture for the Web servers covered in this section. The roles performed by the components in this architecture include the following:

  The Event Dispatcher encapsulates the Web server’s concurrency strategies (such as Thread-per-Request or Thread Pool) and request dispatching strategies (such as synchronous Reactive or asynchronous Proactive dispatching). The ACE framework allows these strategies to be customized according to platform characteristics such as user-level versus kernel-level threading in the OS, the number of CPUs in the end system, and the existence of special-purpose OS support for HTTP processing, such as the Windows NT TransmitFile system call (Hu et al., 1997).
  An HTTP Handler is created for each client HTTP connection (e.g., from a Web browser). It parses HTTP requests and performs the work specified by the requests (e.g., retrieving Web pages). An HTTP Handler contains an ACE SOCK Stream, which encapsulates the data transmission capabilities of TCP/IP sockets.
  The HTTP Acceptor is a factory that accepts connections from clients and creates HTTP Handlers to process the requests from clients. There is typically one HTTP Acceptor per server, although certain concurrency strategies (such as Thread Pool) allocate multiple HTTP Acceptors to leverage OS multithreading capabilities. An HTTP Acceptor contains an ACE SOCK Acceptor, which encapsulates the passive connection establishment capabilities of TCP/IP sockets.


FIGURE 2.4.   The object-oriented communication software architecture for a Web server.

The SOCK Acceptor and SOCK Stream are C++ wrappers provided by ACE. They shield applications from nonportable, tedious, and error-prone aspects of developing communication software using the native OS socket interfaces written in C. Other ACE components are introduced throughout this section as well.

2.4.3. Design Patterns for Web Server Communication Software

The communication software architecture diagram in Figure 2.4 explains how the Web server is structured but not why it is structured in this particular way. To understand why the Web server contains roles such as Event Dispatcher, Acceptor, and Handler requires a deeper understanding of the design patterns underlying the domain of communication software in general and Web servers in particular. Figure 2.5 illustrates the strategic and tactical patterns related to Web servers.


FIGURE 2.5.  Common design patterns in Web servers.

2.4.3.1. Strategic Patterns

Certain patterns are strategic because they are ubiquitous to the domain of communication software. Therefore, these patterns significantly influence the software architecture of Web servers. The following list details the strategic patterns involved in communication software:

  Acceptor pattern
  Reactor pattern
  Proactor pattern
  Active object pattern
  Half-sync/Half-async pattern

The Acceptor pattern (Schmidt, 1996b) decouples passive connection establishment from the service performed once the connection is established. Figure 2.6 illustrates the structure of the Acceptor pattern in the context of Web servers. The HTTP Acceptor is a factory that creates, accepts, and activates a new HTTP Handler whenever the Event Dispatcher notifies it that a connection has arrived from a client. All the Web server implementations described here use the Acceptor pattern to decouple connection establishment from HTTP protocol processing.


FIGURE 2.6.  The structure of the Acceptor pattern.

The Reactor pattern (Schmidt, 1995) decouples the synchronous event demultiplexing and event handler notification dispatching logic of server applications from the service(s) performed in response to events. Figure 2.7 illustrates the structure of the Reactor pattern in the context of Web servers. Both the HTTP Acceptor and HTTP Handler inherit from the abstract Event Handler interface and register themselves with the Initiation Dispatcher for input events (i.e., connections and HTTP requests), respectively. The Initiation Dispatcher invokes the handle_input notification hook method of these Event Handler subclass objects when their associated events occur. The Reactor pattern is used by most of the Web server concurrency models presented in section 2.4.4.


FIGURE 2.7.  The structure of the Reactor pattern.

The Proactor pattern (Harrison, Pyarali, et al., 1997) decouples the asynchronous event demultiplexing and event handler completion dispatching logic of server applications from the service(s) performed in response to events. Figure 2.8 illustrates the structure of the Proactor pattern in the context of Web servers. As before, both the HTTP Acceptor and HTTP Handler inherit from the abstract Event Handler interface. The difference is that this Event Handler defines completion hooks rather than initiation hooks. Therefore, when asynchronous invoked accept and read operations complete, the Completion Dispatcher invokes the appropriate completion hook method of these Event Handler subclass objects. The Proactor pattern is used in the asynchronous variant of the Thread Pool in section 2.4.4.3.


FIGURE 2.8.  The structure of the Proactor pattern.

The Active Object pattern (Lavender & Schmidt, 1996) decouples method invocation from method execution, allowing methods to run concurrently. Figure 2.9 illustrates the structure of the Active Object pattern in the context of concurrent Web servers. The client interface transforms method requests (such as get_request) into method objects that are stored on an activation queue. The scheduler, which runs in a separate thread from the client, dequeues these method objects and transforms them back into method calls to perform the specified HTTP processing. The Active Object pattern is used in the Thread-per-Request model in section 2.4.4.2, the Thread Pool models in section 2.4.4.3, and the Thread-per-Session model in section 2.4.4.4.


FIGURE 2.9.  The structure of the Active Object pattern.


Previous Table of Contents Next