Ru-Brd |
The ADAPTIVE Communication Environment (ACE) toolkit has achieved enormous success in the area of middleware for networked computing. Due to its flexibility, performance, platform coverage, and other key properties, ACE enjoys broad acceptance by the networked application software community, as evidenced by its use in thousands of applications, in scores of countries , and in dozens of domains. ACE has also received considerable attention beyond the middleware community since it's an open -source role model for high-quality and well-designed pattern-oriented software architectures. But why is ACE so successful? Addressing this question properly takes some thought. To start off, let's reconsider the Foreword from C++ Network Programming: Mastering Complexity with ACE and Patterns (C++NPv1) and resume the mass transit analogy presented there by my colleague Steve Vinoski. Steve's right that a high-quality mass transit system consists of more than just aircraft, airports, trains, train stations , and rails. It also needs less obvious infrastructure, such as scheduling, routing, ticketing, maintenance, and monitoring. But even a complete collection of ingredients is still not sufficient to develop an effective mass transit system. Arranging these ingredients so they seamlessly fulfill their primary objective ”fast and reliable transportation of people ”is equally important. Would you use a mass transit system whose ticketing was located in a train maintenance location or an airport hangar, or whose planned and actual scheduling and routing weren't available to the public? I doubt it! The success of mass transit systems depends on more than the knowledge of the infrastructure parts that are provided ”it depends on how these different parts must be connected and integrated with their environment. This knowledge enables architects of mass transit systems to integrate individual parts into higher-level building blocks and to connect these building blocks effectively. For example, ticketing, information points, baggage offices, and boarding are integrated in train stations located at city centers or major suburban centers. Likewise, airports are often located near large cities and connected by frequent express trains. Even mass transit centers themselves are arranged so that activities can be performed effectively. For example, when you enter a train station or airport via the main entrance , you find ticket agents , information centers, and timetables. You also find shops to satisfy your travel needs. As you enter the main train hall or airport concourse, you find other information centers, up-to-date scheduling information, and the platforms and gates for boarding the trains and planes. Mass transit centers thus not only provide all necessary services to begin and end a journey, they also organize their internal "control flows" effectively. While the core structures and control flows in most train stations and airports are similar, their concrete realization can differ widely. Yet we all recognize these mass transit center patterns immediately since they follow key invariants that we've learned through years of experience. So what's the connection between successful mass transit system design and the success of ACE? The answer is simple: In addition to the basic network computing ingredients (the wrapper facades that Doug and Steve introduced in C++NPv1), ACE also includes useful object-oriented frameworks that build upon these wrapper facades and provide useful higher-level communication services, such as event demultiplexing and dispatching, connection management, service configuration, concurrency, and hierarchically layered stream processing. The ACE framework services satisfy many networked software needs by organizing the structures and internal control flows of your applications effectively via key patterns learned through years of experience. The ACE frameworks offer you a number of important benefits:
As a result of advising and leading many software projects over the years, I've found that ACE greatly simplifies the task of employing reusable middleware that can be customized readily to meet the needs of networked applications. Not all networked applications need heavyweight middleware, such as application servers, web services, and complex component models. Yet most networked applications can benefit from portable and efficient host infrastructure middleware like ACE. This flexibility is the core of ACE's success since you needn't commit to an entire middleware suite if you don't use all of it. Instead, you can combine just the essential ACE middleware classes you need to compose applications that are small, but as powerful as necessary. For this reason, I predict that ACE will still be widely used long after the influence of today's heavyweight middleware has waned. ACE's tremendous flexibility also needn't lead to a sea of incompatible middleware implementations. For example, if you build an embedded system that speaks the CORBA Internet inter-ORB protocol (IIOP) to the outside world, you can use The ACE ORB (TAO), which is a CORBA-compliant, open-source, real-time object request broker (ORB) built using the ACE wrapper facades and frameworks. If CORBA is overkill for your application needs, however, you can build custom, yet interoperable, middleware using the appropriate ACE classes. Both solutions can be based on the same core structures and protocols, such as the ACE Common Data Representation (CDR) classes and its TCP/IP Socket wrapper facades. They can therefore communicate seamlessly with one another, just as you can take a train from Paris to Istanbul ”the famous Orient Express ”and travel through many European countries without having to change trains due to incompatible railroad networks. As Steve Vinoski and I have pointed out, there are many similarities between high-quality mass transit systems and high-quality networking middleware. To me and thousands of other C++ developers around the world, ACE is the toolkit for building the latter! After saying so many good things about ACE, however, let's return to the main intent of this foreword: introducing the second volume (C++NPv2) of the C++ Network Programming series. As with all software technologies and middleware, the more you understand your tools, the better you'll be able to apply them. It turns out that using ACE in your applications is just one aspect of improving your networked software. To benefit significantly from ACE's many advantages, you therefore also need a sound understanding of the core concepts, patterns, and usage rules that underlie its powerful frameworks. For years, a common way to learn ACE involved studying its code, comments, and example applications. Clearly, this process was time consuming and error prone. Moreover, even after managing to read the several hundred thousand lines of C++ code in ACE, it was easy to miss the forest for the trees. As the Greek philosopher Thucydides noted two millennia ago: "A man who has the knowledge but lacks the power to clearly express himself is no better off than if he had never any idea at all." We're therefore fortunate that Doug and Steve found time in their busy schedules to create such a high-quality book on the ACE frameworks. C++NPv2 explains the ideas and concepts underlying the ACE frameworks in an easily accessible form using the popular concurrency and networking patterns from the POSA [POSA1, POSA2] and "Gang of Four" [GoF] patterns books. These patterns, in turn , reify thoughtful and time-proven solutions to common networking problems. For example, they tell you what the problems are, why these problems are hard, what the solutions to these problems are, and why these solutions applied to ACE are of high quality. If you want thorough coverage of the patterns and frameworks in ACE that are shaping the next generation of networked application software then read this book. I've learned much from it and I'm sure you will too. Frank Buschmann |
Ru-Brd |