Previous | Table of Contents | Next |
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:
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.
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:
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 |