B.1 The Evolution of ACE

I l @ ve RuBoard

Eric Raymond, a pioneer of the open -source movement [O'R98], is fond of saying that "Every good work of software starts by scratching a developer's personal itch" [Ray01]. While this isn't always the case, it certainly applies to ACE. This section describes the evolution of ACE ”from its origins as a tool to simplify the life of a single researcher to one of the most portable and widely used C++ network programming toolkits in the world.

B.1.1 The Formative Itch

In 1990, Doug Schmidt took a break from his doctorate studies at the University of California, Irvine (UCI) to work at a Silicon Valley start-up company called Independence Technologies Inc. (ITI), which was ultimately bought by BEA Systems, Inc. ITI specialized in UNIX-based online transaction processing (OLTP), which was a novelty in 1990. It was at ITI that Doug was exposed to Richard Stevens's classic book UNIX Network Programming , which Doug absorbed and applied to help develop an OLTP middleware platform written in C and C++.

In 1991 Doug returned to UCI to finish his dissertation on concurrent networking protocol processing [SS95]. His doctorate project focused on the design and optimization of A Dynamically Assembled Protocol Transformation, Integration, and evaluation Environment (ADAPTIVE) [SBS93]. ADAPTIVE provided customizable lightweight and adaptive protocol machines that helped improve end-to-end application performance and reduce transport system overhead [SS93].

In the early 1990s there were two vexing sources of accidental complexity associated with writing systems software such as ADAPTIVE:

1. The protocol code in ADAPTIVE was written using object-oriented design techniques and C++. It was necessary to revert to C function APIs and algorithmic design, however, when accessing OS resources, such as processes, threads, locks, sockets, shared memory, DLLs, and files.

2. The same " boilerplate " code had to be written numerous times to handle common network programming tasks , such as connection establishment, synchronous event demultiplexing and dispatching, synchronization, and concurrency architectures.

The ADAPTIVE Communication Environment (ACE) was created to resolve these two frustrations. The first publicly available release of ACE in 1992 ran on SunOS 4.x and 5.x. Its roughly 10,000 lines of code combined C++ features, advanced OS mechanisms, and patterns to provide an extensible and efficient object-oriented networking software development toolkit.

Had Doug not released ACE using an open-source distribution model, it would likely have faded away after he finished his doctorate. Fortunately, he'd been contributing to the free software community for many years , having written the GNU GPERF perfect hash function generator [Sch90] and parts of the GNU LIBG++ library along with Doug Lea [Lea88]. He was therefore familiar with the benefits of building a community [SP01] around open-source processes and tools. A key strength of open-source development models is their ability to scale to large user communities, where application developers and end users can assist with many quality assurance, documentation, and support activities.

B.1.2 The Turning Point

By 1994, ACE had matured to the point where it was being used in several dozen commercial projects, including network management at Ericsson [SS94] and Iridium [Sch00]. At that point, Doug became an Assistant Professor at Washington University, St. Louis. This transition coincided with a surge of commercial interest in using middleware to help improve networked application software portability and flexibility.

ACE was well positioned to surf the early wave of interest in middleware. As a result, Doug and his research group at Washington University received funding from many visionary sponsors, including ATDesk, BBN, Boeing, Cisco, DARPA, Ericsson, Hughes, Icomverse, Iridium, Kodak, Krones, Lockheed Martin, Lucent, Motorola, Nokia, Nortel, NSF, Raytheon, SAIC, Siemens MED, Siemens SCR, Siemens ZT, Sprint, and Telcordia. These sponsors recognized that it was too costly and time consuming for them to independently rediscover and reinvent ad hoc solutions to their core networked application software challenges. Fortunately, the participants on the ACE project had identified, documented, and reified key patterns and frameworks to address these challenges, which Doug's sponsors then applied to reduce many tedious and expensive aspects of developing and maintaining their networked applications.

Over the next six years, around U.S.$7 million of sponsor funding enabled Doug to hire dozens of graduate students and full-time staff. Many of these people have worked for years in the Distributed Object Computing (DOC) Groups at Washington University in St. Louis, and now at UCI, where Doug has returned as a tenured Associate Professor in the Electrical and Computer Engineering department. Together, the DOC groups have:

1. Greatly expanded the capabilities of ACE, which is about 25 times its original size and contains hundreds more classes and frameworks.

2. Ported ACE to dozens of new OS/compiler platforms, which are summarized in Sidebar 1 on page 14.

3. Written scores of magazine articles and technical papers that describe the patterns and performance of the wrapper facades and frameworks in the ACE toolkit. The ability to download these papers from http://www.cs.wustl.edu/~schmidt/ publications .html enabled worldwide developers to assess the scope and quality of ACE to determine how it could best meet their needs.

The members of the DOC Group and the ACE user community have been instrumental in transitioning ACE from the personal hobby of a single researcher into one of the world's most widely used C++ frameworks for concurrent object-oriented network programming across a wide range of hardware and software platforms.

B.1.3 Crossing the Chasm

While Doug and his group at Washington University were working on ACE version 3.x in 1996, Steve Huston was doing consulting and networked application development. In one project he needed C++ networking software to meet an aggressive development schedule. A Web search yielded ACE. Unfortunately, ACE wasn't ported to the project's platform (Unixware). The project was doomed without the capabilities ACE provided, however, so Steve began the port to Unixware. The time to port ACE to a new platform, learn enough about ACE to do the job, and then develop the system was less than it would have taken Steve to write the necessary networking software from scratch. The new system performed efficiently and the result was the first of many ACE success stories [Gro].

Realizing the gains achievable with ACE, Steve kept an eye on the DOC Group and the ACE mailing list. Although ACE improved continually, it was still used mostly by researchers and industrial R&D groups. While ACE was too practical to be left solely in the hands of researchers, Steve recognized that high-quality support was needed in order for ACE to cross the chasm [Moo91] to support mainstream commercial software developers. The wheels started turning late in 1996 and by mid-1997 Steve had renamed his company Riverace Corporation (http://www.riverace.com) and focused it on support and product services that make ACE easier to learn and apply.

Today, Riverace provides support and consulting services that help companies make the best use of ACE in their development projects. The company continues to improve the quality of ACE as an open-source product, providing a level of commercial support that's helping to expand ACE's use into enterprise software development worldwide. ACE now has the "look and feel" of commercial software, and all of its benefits come without any run-time or developer licensing fees. Sidebar 24 outlines the open-source license used for ACE.

Sidebar 24: The ACE Open-Source License

The ACE open-source license is similar to the so-called BSD UNIX open-source license. Users are free to use, modify, copy, and distribute, perpetually and irrevocably, the ACE source code and object code produced from the source, as well as copy and distribute modified versions of this software. In particular, ACE can be used in proprietary software and users are under no obligation to redistribute any source code that's built with or derived from ACE. Complete copyright and licensing information for ACE is available in the file $ACE_ROOT/COPYING In the ACE release.

B.1.4 Middleware Standards

Toward the latter half of the 1990s, information technology was clearly becoming commoditized; that is, key hardware and software artifacts were getting faster, cheaper, and better at an increasingly predictable pace. For the past decade we've all benefited from the commoditization of hardware, such as CPUs and storage devices, and networking elements, such as IP routers. More recently, many software layers and components are becoming commoditized due to the maturation of the following standards:

• Programming languages, such as Java and C++

• Operating environments, such as POSIX and Java virtual machines and

• Middleware, such as CORBA, Enterprise Java Beans, and the .NET Web services [SS01].

A consequence of the commoditization of these software artifacts is that industries long protected by high barriers to entry, such as telecom and aerospace, are more vulnerable to disruptive technologies [Chr97] and global competition, which can drive prices to marginal cost.

Since Doug felt that the long- term success of the software industry depends on the adoption of useful open standards, he began two spin-off projects that focused on transitioning the ACE research into open middleware standards. This section describes the results of these spin-off efforts, which yielded the two standards-based middleware toolkits ”TAO and JAWS ”shown in Figure B.1. TAO and JAWS were developed using the wrapper facades and frameworks provided by ACE, as described below.

Figure B.1. Standards-Compliant Middleware Based on ACE

The ACE ORB (TAO)

TAO is a high-performance, real-time implementation of the CORBA specification [SLM98]. It contains the network interface, OS, networking protocol, and CORBA middleware capabilities shown in Figure B.1 (1). Many of the patterns used in TAO are described in [SC00]. Like ACE, TAO is open-source software, which is freely available for download at the URL http://ace.ece.uci.edu/TAO.

The DOC Group's work on TAO has played an important role in several standardization efforts:

• It influenced the OMG's real-time CORBA specification [Obj01], particularly its explicit binding and portable synchronizer features.

• It has been included as one of two ORBs selected for DISA's Joint Tactical Architecture (JTA) in the DII COE.

• It has been used as the basis for the DMSO HLA/RTI distributed interactive simulations standard [OSLN99].

Today, TAO is used in hundreds of research and commercial projects in the aerospace, telecommunication, simulation, health care, scientific computing, and financial services domains around the world. It has the distinction of being the first CORBA ORB flown successfully in a fighter aircraft [Lac98]. TAO is supported by OCI (http://www.theaceorb.com) using an open-source license and business model that's similar to River -ace's.

The JAWS Adaptive Web Server (JAWS)

JAWS is a high-performance, adaptive Web server [HS99] built using the ACE frameworks. It implements the HTTP 1.0 specification. Figure B.1 (2) illustrates the major structural components and patterns in JAWS. JAWS is structured as a framework of frameworks. The overall JAWS framework contains the following components and frameworks:

• Concurrency strategies, which implement concurrency mechanisms such as thread per request and thread pool, that can be selected adaptively at run time or preselected at initialization time;

• I/O strategies, which implement various I/O mechanisms, such as asynchronous, synchronous, and reactive I/O;

• Event dispatcher, which coordinates the handling of events between JAWS's I/O and concurrency strategies;

• Protocol handlers, which implement the parsing and handling of HTTP requests ;

• Protocol pipeline, which allows filter operations to be incorporated easily with the data being processed by protocol handlers; and

• Cached virtual filesystem, which improves Web server performance by reducing the overhead of filesystem accesses via caching strategies, such as least recently used (LRU) and least frequently used (LFU).

Each of these frameworks is structured as a set of collaborating objects implemented by combining and extending components in ACE. The patterns constituting JAWS are described in [SSRB00]. Like ACE and TAO, JAWS is used in many commercial projects. It's also open-source software ”distributed with the ACE release in the $ACE_ROOT/apps/ directory.

ACE has been fundamental to the success of TAO and JAWS. Moreover, the flow of technology has been synergistic. For example, the process of implementing and refactoring [FBB ⁺ 99] TAO and JAWS has yielded many new classes, as well as refined and optimized many classes and frameworks in ACE.

B.1.5 The Impact of Open Source

There are thousands of developers and end users in the ACE open-source community. Without their support it's unlikely that ACE would have been as successful as it has for the following reasons:

Lack of sufficient capital investment. Over 100 person-years of effort have been expended to develop ACE+TAO. Assuming that each person-year costs a conventional company around U.S.$200 thousand in salary and benefits, this effort would have required around U.S.$20 million in funding using a conventional closed-source development model. As mentioned on page 261, it cost the DOC groups' sponsors only one-third of this amount to develop ACE+TAO. Much of the difference was made up by contributions of time and effort by the ACE+TAO open-source community.

Lack of short-term return on investment. It took several years for ACE to mature to a point where it could be used for production systems. For example, many ACE framework required multiple iterations to determine the appropriate APIs, patterns, and relationships. Few companies or venture capitalists would be willing to invest in a middleware project for this long, particularly when the end result was given away for free!

Lack of time, interest, and available platforms. Developing highly portable middleware requires a substantial amount of effort on relatively "mundane" tasks, such as ensuring that the software builds and runs cleanly on dozens of compilers and OS platforms. Even if a core group of developers had sufficient time and interest (which is unlikely in chronically underfunded advanced R&D environments), it would be prohibitively expensive to obtain all the necessary hardware/software platforms necessary to create and maintain all these ports. Fortunately, the open-source model allowed the DOC groups to leverage the vast human and computing resources available on the Web to ensure that many mundane tasks were completed in a timely and economical manner [SP01].

Lack of broad technical expertise. ACE has benefited greatly from software contributions and guidance from middleware experts throughout the world. Doug had been involved in the GNU C and C++ projects during the latter years of the 1980s along with free software pioneers, such as Richard Stallman, Doug Lea, and Michael Tiemann. When he started developing ACE he therefore understood the value of creating a community of technical experts to augment and support the capabilities of a software toolkit.

As soon as the first working build of ACE was complete in 1991 it was available for anonymous ftp ”HTTP and the Web as we know it today didn't exist at that point. This immediately spawned a small user community to help fix bugs and port ACE to new platforms, thereby reinforcing the value of free software ”the term "open source" did not exist at that point either!

I l @ ve RuBoard