| Many networked applications, such as e-mail, remote file backups , and Web services, use connection-oriented services containing classes that play the following roles: -
The connection role determines how an application establishes connections. -
The communication role determines whether an application plays the role of a client, a server, or both client and server in a peer-to-peer configuration. Networked applications that communicate via connection-oriented protocols (e.g., TCP/IP) are typified by the following asymmetric connection roles between clients and servers: Even in peer-to-peer applications, where applications play both client and server roles, connections must be initiated actively by one peer and accepted passively by the other. To enhance reuse and extensibility, networked applications should be designed to easily change connection and communication roles to support different requirements and environments. The ACE Acceptor-Connector framework implements the Acceptor-Connector design pattern [POSA2], which enhances software reuse and extensibility by decoupling the activities required to connect and initialize cooperating peer services in a networked application from the processing they perform once they're connected and initialized . This chapter describes the following ACE Acceptor-Connector framework classes that networked applications can use to establish connections and initialize peer services: | ACE Class | Description | | ACE_Svc_Handler | Represents the local end of a connected service and contains an IPC endpoint used to communicate with a connected peer. | | ACE_Acceptor | This factory waits passively to accept a connection and then initializes an ACE_Svc_Handler in response to an active connection request from a peer. | | ACE_Connector | This factory actively connects to a peer acceptor and then initializes an ACE_Svc_Handler to communicate with its connected peer. | The most important relationships between the ACE Acceptor-Connector framework's classes are shown in Figure 7.1. These classes play the following roles in accordance with the Acceptor-Connector pattern [POSA2]: Figure 7.1. The ACE Acceptor-Connector Framework Classes  -
Event infrastructure layer classes perform generic, application-independent strategies for dispatching events. The ACE Reactor framework described in Chapter 3 is commonly used as the event infrastructure layer. -
Connection management layer classes perform application-independent connection and initialization services. These classes include the ACE_Svc_Handler, ACE_ Acceptor , and ACE_Connector . -
Application layer classes customize the generic strategies performed by the other two layers via subclassing and/or template instantiation to create objects that establish connections, exchange data, and perform service-specific processing. In the ACE Acceptor-Connector framework, application layer classes are descendants and template instantiations of the connection management layer classes outlined above. By being descendants of ACE_Event_Handler , these classes all offer integration with the ACE Reactor framework from Chapter 3. Chapter 8 describes a variant of the Acceptor-Connector framework based on the ACE Proactor framework for applications in which asynchronous I/O is more appropriate or beneficial. The ACE Acceptor-Connector framework provides the following benefits: -
Reusability and extensibility. Connection-oriented networked applications often contain a significant amount of low-level code that establishes connections and initializes services. This code is largely independent of the processing that connected service handlers perform on the data they exchange. The ACE Acceptor-Connector framework refactors this low-level code into reusable, application-independent acceptor and connector classes that know how to establish a connection and initialize its associated service handler after the connection is established. As a result, service handlers can focus solely on their application-defined processing. This separation of concerns makes it easier to add new types of application services, service implementations , authentication protocols, and communication protocols without affecting existing connection establishment and service initialization configuration code. -
Portability. The class templates in the framework are all parameterized by the type of IPC mechanism needed to establish connections and to transfer data. The flexibility offered by this template-based extensibility is useful when developing applications that must run portably and efficiently across multiple OS platforms. The IPC class parameters for the Acceptor-Connector templates can be any network programming classes that conform to the interface expected by the templates. For example, depending on certain properties of the underlying OS platform, such as whether it's a BSD or System V variant of UNIX, a server can instantiate the framework classes to use the ACE Socket wrapper facades or the ACE TLI wrapper facades. For non- TCP / IP applications, the templates can be instantiated with many of ACE's IPC wrapper facades, or any privately developed classes that export the necessary interface. -
Robustness. By strongly decoupling a service handler from its acceptor, the framework can ensure that passive-mode transport endpoints aren't accidentally used to read or write data. This added type safety eliminates a subtle and pernicious class of errors that can arise when programming with weakly typed network programming interfaces, such as the Socket or TLI APIs defined in C. -
Efficiency. The Acceptor-Connector pattern can actively establish connections with a large number of peers asynchronously and efficiently over long-latency wide area networks. Asynchrony is important in these situations because large-scale networked applications may have hundreds or thousands of peers to connect. The remainder of this chapter motivates and describes the capabilities of the ACE Acceptor-Connector framework classes. It shows how service handlers are initialized and destroyed , and motivates key framework design choices. It also shows how this framework can be layered on top of the ACE Reactor and ACE Task frameworks to handle connection requests and data exchanged between client and server logging daemons. If you're not familiar with the Acceptor-Connector pattern from POSA2 we recommend you read about it first before delving into the detailed examples in this chapter. We also recommend you read about the ACE Reactor and Task frameworks in Chapters 3 and 6, respectively. |
