|I l @ ve RuBoard|
ACE defines a set of C++ classes that address the limitations with the Socket API described in Section 2.3. These classes are designed in accordance with the Wrapper Facade design pattern [SSRB00].  They therefore encapsulate the functions and data provided by existing non-object-oriented APIs within more concise , robust, portable, maintainable , and cohesive object-oriented class interfaces. The ACE Socket wrapper facade classes presented in this chapter include:
Figure 3.1 illustrates the key relationship between these classes. These ACE Socket wrapper facades provide the following benefits:
Figure 3.1. The ACE Connection-Oriented Socket Class Relationships
Moreover, ACE Socket wrapper facades retain efficiency by using inline functions to enhance the software qualities listed above without sacrificing performance. ACE's efficiency- related design principles are discussed further in Section A.6 on page 255.
The structure of the ACE Socket wrapper facades corresponds to the taxonomy of communication services, connection/communication roles, and communication domains shown in Figure 3.2. The classes in this figure provide the following capabilities:
Figure 3.2. Taxonomy of the ACE Socket Wrapper Facades
It's instructive to compare the structure of the ACE classes in Figure 3.2 with the functions shown in Figure 2.1 on page 42. The classes in Figure 3.2 are much more concise since they use the ACE Socket wrapper facades to encapsulate the behavior of multiple socket functions within C++ classes related by inheritance. In addition to the classes that support connection establishment and communication, ACE also provides a related set of addressing classes. We examine their capabilities in Section 3.2 and their underlying design principles in Section A.4.2. Figure 3.1 depicts the associations between these classes and the other ACE classes in the connection-oriented Socket API family.
The remainder of our discussion in this chapter focuses on the ACE connection-oriented Internet-domain wrapper facades because they're the most widely used ACE IPC mechanism. The classes are arranged in the hierarchy shown in Figure 3.1. To avoid duplication of code, common methods and state are factored into abstract classes, which aren't instantiated directly. Subclasses then add appropriate methods and enforce proper usage patterns. For example, connection-oriented networked applications are typified by asymmetric connection roles between clients and servers. Servers listen passively for clients to initiate connections actively [SSRB00], as shown in Figure 3.3. Even in peer-to-peer applications, in which applications play the role of both client and server, connections must be initiated actively by one of the peers and accepted passively by the other.
Figure 3.3. Roles in the ACE Socket Wrapper Facade
The functions in the C Socket API can be distinguished by the three different roles they play for connection-oriented protocols, such as TCP:
This chapter motivates and describes the capabilities of the ACE Socket classes that collectively provide the connection and communication roles outlined above. Keep in mind the points noted in Sidebar 4 regarding UML diagrams and C++ code in this book.
|I l @ ve RuBoard|