3.3 The ACE_IPC_SAP Class

I l @ ve RuBoard

Motivation

Section 2.3.1 on page 37 outlined the portability problems incurred by the I/O handles used in native OS IPC APIs. ACE addresses I/O handle portability by:

• Defining the ACE_HANDLE type definition, which designates the appropriate type of handle on each OS platform and

• Defining a portable ACE_INVALID_HANDLE macro that applications can use to test for errors

These simple ACE-defined type and value abstractions help to enhance application portability.

Object-savvy software developers will note, however, that a handle ”even a portable one ”is not the appropriate level of abstraction in an object-oriented networked application. Instead, a more appropriate programming abstraction would be some type of I/O handle class, which is why ACE provides the ACE_IPC_SAP class. ^[2]

^[2] In the networking standards literature [Bla91], the acronym "SAP" stands for "service access point."

Class Capabilities

The ACE_IPC_SAP class is the root of the ACE hierarchy of IPC wrapper facades and provides basic I/O handle manipulation capabilities to other ACE wrapper facades. Its interface is shown in Figure 3.5 (along with the ACE SOCK class described in Section 3.4) and its key methods are shown in the table below:

Method	Description
enable() disable()	Enable or disable various I/O handle options, such as enabling/disabling non-blocking I/O.
set_handle() get_handle()	Set and get the underlying I/O handle.

Figure 3.5. The ACE_IPC_SAP and ACE_SOCK Class Diagrams

Although ACE_IPC_SAP defines useful methods and data, it's not intended for direct use by applications. Instead, it's used by subclasses, such as the ACE wrapper facades for files, STREAM pipes, Named Pipes, and the System V Transport Layer Interface (TLI). To enforce this design constraint and to prevent ACE_IPC_SAP from being instantiated directly, we make ACE_IPC_SAP an abstract class by declaring its constructor in the protected part of the class. We use this convention instead of defining a pure virtual method to eliminate the need for a virtual pointer in each subclass instance.

I l @ ve RuBoard