- Motivation
- Problem: Programming Yourself into a Corner with OS APIs
- An Appealing Solution: Host Infrastructure Middleware
- Improving Application Portability with ACE
- The Importance of Open-Source
- Concluding Remarks
An Appealing Solution: Host Infrastructure Middleware
An increasingly popular solution to the problems described above is to interpose host infrastructure middleware between OS APIs and application software. Host infrastructure middleware provides an "OS abstraction layer" that shields application software from the details of the underlying OS. Widely used examples of host infrastructure middleware include the following.
Sun's Java Virtual Machine (JVM) provides a platform-independent way of executing code by abstracting many differences between operating systems and CPU architectures. A JVM is responsible for interpreting Java bytecode and for translating the bytecode into an action or an OS call. It's the JVM's responsibility to encapsulate platform details within the portable bytecode interface, so that applications are shielded from the disparate operating systems and CPU architectures on which Java software runs.
Microsoft's Common Language Runtime (CLR) is the host infrastructure middleware foundation upon which Microsoft's .NET web services are built. The Microsoft CLR is similar to Sun's JVM. For example, it provides an execution environment that manages running code and simplifies software development via automatic memory management mechanisms, cross-language integration, interoperability with existing code and systems, simplified deployment, and a security system.
The ADAPTIVE Communication Environment (ACE) is a freely available, open-source, highly portable toolkit that we've written in C++. ACE shields applications from differences between native OS programming capabilities, such as file handling, connection establishment, event demultiplexing, interprocess communication, (de)marshaling, concurrency, and synchronization. At the core of ACE is an OS adaptation layer and C++ wrapper facades that encapsulate OS file system, concurrency, and network programming mechanisms. The higher layers of ACE build upon this foundation to provide reusable frameworks that handle network programming tasks, such as synchronous and asynchronous event handling, service configuration and initialization, concurrency control, connection management, and hierarchical service integration.
Some of the main differences between ACE, JVMs, and the .NET CLR are that a) ACE is always a compiled C++ interface, rather than an interpreted bytecode interface, which removes a level of indirection and helps to optimize runtime performance, b) ACE is open-source, so it's possible to subset it or modify it to meet a wide variety of needs, and c) ACE runs on more OS and hardware platforms than JVMs and CLR, including the following:
PCs: For example, Windows (all 32/64-bit versions), WinCE; Redhat, Debian, and SuSE Linux; and Macintosh OS X.
Most versions of UNIX: For example, SunOS 4.x and Solaris, SGI IRIX, HP-UX, Digital UNIX (Compaq Tru64), AIX, DG/UX, SCO OpenServer, UnixWare, NetBSD, and FreeBSD.
Real time operating systems: For example, VxWorks, OS/9, Chorus, Integrity, LynxOS, Pharlap TNT, QNX Neutrino and RTP, RTEMS, and pSoS.
Large enterprise systems: For example, OpenVMS, MVS OpenEdition, Tandem NonStop-UX, and Cray UNICOS.
We'll focus on ACE in the remainder of this article.