Static vs. Dynamic Configuration

As described in Section 2.1, networked applications generally offer or use communication services. Popular services available on the Internet today include

 Web browsing and content retrieval services, e.g., Alta Vista, Apache, and Netscape’s HTTP server

 Software distribution services, e.g., Castanet

 Electronic mail and network news transfer services, e.g., sendmail andnntpd

 File access on remote machines, e.g.,ftpd

 Network time protocols, e.g., ntpd

 Payment processing services, e.g., Cybercash and

 Streaming audio/video services, e.g., RealAudio, RealSystem, and Re-alPlayer.

By combining the naming and linking dimensions described above, we can classify these types of networked application services as being either stat-ically or dynamstat-ically configured. The primary tradeoffs in this dimension involve efficiency, security, and extensibility.

Static configuration refers to the process of initializing an application that contains statically named services, i.e., developing each service as a sepa-rate function or class and then compiling, linking, and executing them in a separate OS process. In this case, the services in the application aren’t extensible at run-time. This design may be necessary for secure applica-tions that contain only trusted services. Statically configured applicaapplica-tions may also be more efficient since code generated by compilers can eliminate indirections required to support relocatable code.

However, statically configuring services can also yield non-extensible applications and software architectures. The main problems with static configurations are:

 It tightly couples the implementation of a particular service with the configuration of the service with respect to other services in a net-worked application and

 It severely limits the ability of system administrators to change the parameters or configuration of a system to suit local operating condi-tions or changing network and hardware configuracondi-tions.

36 Section 2.2 Conguration Design Dimensions

Dynamic configuration refers to the process of initializing an applica-tion that offers dynamically named services. When combined with ex-plicit dynamic linking and process/thread creation mechanisms, the ser-vices offered by dynamically configured applications can be extended at installation/boot-time or even during run-time. This degree of extensibility helps facilitate the following configuration-related activities:

 Functional subsetting—Dynamic configuration simplifies the steps necessary to produce subsets of functionality for application families developed to run on a range of OS platforms. Explicit dynamic linking enables the fine-grain addition, removal, or modification of services.

In turn, this allows the same framework to be used for space-efficient embedded applications and for large enterprise distributed applica-tions. For example, a web browsing application may be able to run on PDAs, PCs, and/or workstations by dynamically configuring subsets, such as image rendering, Java capability, printing, or direct phone number dialing.

 Application workload balancing—It’s often hard to determine the relative processing characteristics of application services a priori since workloads can vary at run-time. It may therefore be necessary to ex-periment with alternative load balancing techniques [OOS01] and sys-tem configurations that locate application services on different host machines throughout a network. For example, developers may have the opportunity to place certain services, such as image processing, on either side of a client/server boundary. Bottlenecks may result if many services are configured into a server application and too many active clients access these services simultaneously. Conversely, con-figuring many services into clients can result in a bottleneck if clients execute on cheaper, less powerful machines.

 Dynamic service reconfiguration—Highly available networked ap-plications, such as mission-critical systems that perform on-line trans-action processing or real-time process control, may require flexible dynamic reconfiguration management capabilities. For example, it may be necessary to phase new versions of a service into a server ap-plication without disrupting other services that it’s already executing.

Re-configuration protocols [SSRB00] based on explicit dynamic link-ing mechanisms can enhance the functionality and flexibility of net-worked applications since they enable services to be inserted, deleted,

Section 2.3 Summary 37

or modified at run-time without first terminating and restarting the underlying process or thread(s) [SS94].

Logging service ⁾ The implementations of our networked logging service in [SH02] and Chapter 3 are all configured statically. In Chapter ?? in this book, we describe

 The ACE_DLL class, which is a wrapper facade class that portably encapsulates the ability to load/unload dynamically linked libraries (DLLs) and find symbols in them and

 The ACE Service Configuration framework, which can be used to con-figure application services dynamically.

Starting with Chapter ??, all our examples are configured dynamically.

2.3 Summary

The way in which application services are structured, instantiated, and configured has a significant impact on how effectively they use system and network resources. Efficient resource usage is closely linked to applica-tion response time, and overall system performance and scalability. As important as performance and scalability are, however, a coherent and modular design is often just as important to maintain and extend applica-tions over time. Fortunately, performance vs. modularity tradeoffs needn’t be an either/or proposition. By studying the design dimensions carefully in this chapter and applying the ACE wrapper facades and frameworks judiciously, you’ll be able to create well-designed and highly efficient net-worked applications.

Configuration and service location/naming are important topics to un-derstand and use in the quest to reduce the effects of inherent complexity.

In this chapter, we described the two key design dimensions in this area as

1. Identifying a particular set of services and

2. Linking these services into the address space of one or more applica-tions.

The remaining chapters in the book describe the ACE frameworks that reify these design dimensions.

CHAPTER 3