Reuse of code and designs has been a hot topic in computer science for decades. Many of you probably don't remember when the idea of dividing a program up into subroutines was new. Or when algorithmic decomposition was all the rage. Yup, I was there. Me and my CDC 3600 when all good code was written in assembly language. Ah, those were the days... but I digress.

Reuse has come a long way. The terms "pattern," "class library," and "framework" are all commonly used these days, and are used very often in ACE circles. ACE's design is based around patterns, ACE is packaged in a class library form, and offers a number of powerful frameworks. To properly understand ACE's power and make the best choices for reusing its power in your project, it's important to understand the differences in these terms.

Patterns present solutions to common software problems arising within a certain context. Think of patterns as reusable abstract designs and software microarchitectures. Designers of patterns look for solutions that tend to be useful in a specific context. For example, highway design has a set of patterns that are applied such as cloverleaf exchanges and rotaries. When certain design contexts appear, designers can select from a set of patterns that may fit the domain. Similarly, certain software application domains have patterns. A wide range of them is documented in the GoF book, Design Patterns. ACE users may also be familiar with the highly-regarded "POSA2" book, Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects which describes many of the patterns implemented in ACE.

Classes are implementations of useful, reusable code artifacts. Whereas patterns are reusable designs, classes are reusable types expressed in a programming language such as C++. Classes can implement patterns. Reusable single classes (such as string class or a container) can often be very widely reused, but they are often passive. Thus, they don't have much of an affect on program structure.

Frameworks are also often implementations of patterns, but on a larger scale. Frameworks are integrated sets of classes that collaborate to produce a reusable architecture for a family of applications. Whereas single classes are often used as reusable data types, frameworks are reusable applications (or at least major pieces of applications). Frameworks are characterized by inversion of control. That is, the framework is responsible for driving execution, most often calling back to application-specified "hook methods" when prescribed events occur. GUI programmers are very familiar with this model, as are those familiar with using the ACE frameworks such as Reactor, Proactor, Acceptor-Connector, etc. commonality and variability

Frameworks very often give you the biggest "bang for the buck" in terms of reuse. Intelligently designed frameworks are organized by balancing commonality and variability. Commonality refers to actions and data that are common across all uses of the framework, and variability refers to those actions and types that vary between uses. As you investigate which ACE frameworks to make use of in your projects, keep those two concepts in mind. Look for things the framework does which you'll also need done (commonality) and places where the framework offers variability you'll need to customize its use for your particular application. These often occur in parameterized types (such as ACE_Svc_Handler's IPC and synchronization traits) and callback hooks (such as the ACE_Event_Handler's handle_input(), handle_close(), etc. If you could use some help sorting these items out and applying them for maximum benefit on your next project, consider Riverace's ACE training class and consulting services.

The ACE development community is hard at work on the next version of ACE. Here are some of the things you can look forward to (items in bold are new or changed since last month):

• Native library path-searching. Previous ACE versions's implementation of ACE_DLL (used in loading dynamic services) implemented a search of the configured path-search to try and locate the desired library file (DLL) and then used the full pathname to load the library. This skirted some platforms's rules for path search and security settings. This has been changed in the next ACE version to make use of all of the native platform's path-search and security facilities.
• Improved wide-character support. Wide- character support has been included in ACE for many years on Windows (also known as Unicode builds). However, wide-character support for POSIX platforms has been sorely lacking. As ACE's reach expands, this has become a more important issue. Riverace is leading the completion of wide-character support in the next version of ACE. This support is also available now in the ACE 5.4b fix kit.
• GNU autotools support. Riverace is the lead developer in charge of adding auto-configure support to ACE. For native-build, non-Windows systems, autoconf will very likely become the way to configure and build ACE. This will help insure that ACE uses the latest features available on each supported platform, and reduce the work required to build ACE. No more picking the right config.h or platform_macros.GNU file. Just do ./configure then make. Ahhh...
• Support for g++ 4.0, 3.4 and Microsoft Visual C++ 2005 are being added.
• Support for Red Hat Enterprise Linux 4.
• Newer C++ Features Being Used. As the range of ACE-supported compilers matures and older compilers are taken out of service, ACE can make more use of newer C++ features while still maintaining its stellar portability record. For example, many methods that returned 1 or 0 as an int now return bool. Small steps, yes, but significant ones. You'll see more modern C++ usage as time goes on.
• The ACE and ACE_OS classes, previously containing a number of static member functions, are now C++ namespaces. Similar ACE-internal classes, such as ACE_Sock_Connect, are no longer in use.

As you can see, the pace of changes is slowing and the ACE development team is beginning to focus more on testing in preparation for the release of ACE 5.5. The current estimate for ACE 5.5's release is late in 2005, so there's time to get a bit more in. In particular, the ACE_Dev_Poll_Reactor implementation for Linux would be a great addition. This was mentioned in our March 2005 newsletter - please check it out using the link below for more information!

If you're planning a new project to start soon, or find yourself grappling with how to apply ACE to your current project, remember that Riverace provides world-class development and consulting services with special expertise in ACE. We can help you be sure that your new system is designed to take full advantage of ACE's power and flexibility, getting your system delivered in the shortest possible time and with the highest level of quality. Please contact Steve Huston at 888-384-8154 (toll-free in the US) or +1 508- 541-9180 to discuss how Riverace can help you.