| This section covers the following configuration design dimensions: -
Static versus dynamic naming -
Static versus dynamic linking -
Static versus dynamic configuration 2.2.1 Static versus Dynamic Naming Applications can be categorized according to whether their services are named statically or dynamically. The primary tradeoff in this dimension involves run-time efficiency versus flexibility. Statically named services associate the name of a service with object code that exists at compile time and/or static link time. For example, INETD 's internal services, such as ECHO and DAYTIME , are bound to statically named functions stored internally in the INETD program. A statically named service can be implemented in either static or dynamic libraries. Dynamically named services defer the association of a service name with the object code that implements the service. Code therefore needn't be identified ”nor even be written, compiled, and linked ”until an application begins executing the corresponding service at run time. A common example of dynamic naming is demonstrated by INETD 's handling of TELNET , which is an external service. External services can be updated by modifying the inetd.conf configuration file and sending the SIGHUP signal to the INETD process. When INETD receives this signal, it rereads inetd.conf and dynamically rebinds the services it offers to their new executables. 2.2.2 Static versus Dynamic Linking Applications can also be categorized according to whether their services are linked into a process address space statically or dynamically. The primary tradeoffs in this dimension involve extensibility, security, reliability, and efficiency. Static linking creates a complete executable program by binding together all its object files at compile time and/or static link time, as shown in Figure 2.6 (1). Figure 2.6. Static Linking versus Dynamic Linking  Dynamic linking loads object files into and unloads object files from the address space of a process when a program is invoked initially or updated at run time, as shown in Figure 2.6 (2). The OS run-time linker updates external symbol addresses for each process that the object file is loaded into to reflect the memory region the file is loaded into. Operating systems generally support two types of dynamic linking: -
Implicit dynamic linking loads referenced object files during program execution without explicit action by the program itself. Many platforms offer the option to defer address resolution and relocation operations until a method is first referenced. This lazy evaluation strategy minimizes link editing overhead during application initialization. Implicit dynamic linking is used to implement dynamically linked libraries (DLLs) [SR00], also known as shared libraries [GLDW87]. -
Explicit dynamic linking allows an application to obtain, use, and remove the run-time address bindings of certain function- or data- related symbols defined in DLLs. Explicit dynamic linking mechanisms supported by popular operating systems include UNIX functions ( dlopen() , dlsym() , and dlclose() ) and Windows functions ( LoadLibrary() , GetProcAddress() , and FreeLibrary() ). Dynamic linking can help to reduce the memory consumption of both a process in memory and its program image stored on disk. Ideally, only one copy of DLL code will exist, regardless of the number of processes that execute the DLL code simultaneously . When choosing between dynamic and static linking, developers must carefully weigh tradeoffs between flexibility, security, and robustness against the potential benefits of time and space efficiency. The following are some downsides to using dynamic linking: -
Security and robustness problems. A dynamically linked application may be less secure and robust than a statically linked application. It may be less secure because trojan horses can be interposed in DLLs. It may be less robust because a faulty DLL can corrupt the state of other code or data in the same application process. -
Run-time overhead. Dynamic linking can incur more run-time overhead compared with static linking. In addition to opening and mapping multiple files, external symbol addresses in DLLs must be adjusted based on the memory locations the files are loaded into. Although lazy linking can ameliorate this effect, it can be noticeable, especially the first time a DLL is loaded into memory. Moreover, compilers that generate position-independent code often use extra levels of indirection to resolve method invocations and access global variables within DLLs [GLDW87]. -
Excessive jitter. Time-critical applications may be unable to tolerate the latency of linking DLLs into a process and resolving method addresses dynamically. Naturally, you should empirically evaluate the impact of dynamic linking to determine whether it's really an issue for your applications. 2.2.3 Static versus Dynamic Configuration As described in Section 2.1, networked applications often offer or use a variety of services. By combining the naming and linking dimensions described in Sections 2.2.1 and 2.2.2, we can classify networked application services as being either statically or dynamically configured. As with static versus dynamic linking, the primary tradeoffs in this dimension involve extensibility, security, reliability, and efficiency. Static configuration refers to the activities associated with initializing an application that contains statically named services (i.e., developing each service as a separate function or class) and then compiling, linking, and executing them in a separate OS process. In this case, the services in the application cannot be extended at run time. This design may be necessary for secure applications that only contain trusted services. Statically configured applications can also benefit from the more aggressive compiler optimizations applicable to statically linked programs. However, there are several problems with statically configuring networked applications and services: -
They can yield nonextensible applications and software architectures that tightly couple the implementation and the configuration of a particular service with respect to other services in an application. -
Static configuration limits the ability of system administrators to change the parameters or configuration of applications to suit local operating conditions or variations in network and hardware configurations. -
Large-scale statically configured applications may be impractical due to their executable size, which can be hard to deliver, take excessive time to load, and can cause thrashing in systems if sufficient memory isn't available. Dynamic configuration refers to the activities associated with initializing an application that offers dynamically named services. When combined with explicit dynamic linking and process/thread creation mechanisms, the services offered by applications configured dynamically can be extended at installation or boot time, or even during run time. This extensibility can yield the following configuration-related optimizations: -
Dynamic service reconfiguration. Highly available networked applications, such as online transaction processing or telecom call processing systems, may require flexible dynamic reconfiguration management capabilities. For example, it may be necessary to phase a new version of a service into a server without disrupting other services that it's already executing. Reconfiguration protocols based on explicit dynamic linking mechanisms can enhance the functionality and flexibility of networked applications since they enable services to be inserted, deleted, or modified at run time without first stopping and restarting the underlying process or thread(s) [SS94]. -
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. This in turn allows the same framework to be used for space-efficient embedded applications and for large enterprise distributed applications. 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 processing characteristics of application services in advance since workloads can vary considerably at run time. It may therefore be necessary to use dynamic configuration to support load balancing techniques [OOS01] and system partitionings that locate application services on different host machines throughout a network. For example, developers may have the opportunity to collocate or distribute 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, configuring many services into clients can result in a bottleneck if clients execute on cheaper, less powerful machines. Logging service Our networked logging service implementations in C++NPv1 and in Chapters 3 and 4 of this book are configured statically. In Chapter 5 of this book, we describe ACE_DLL , which is a portable wrapper facade that encapsulates the ability to load/unload shared libraries (DLLs) dynamically and find symbols in them. We also describe the ACE Service Configurator framework, which can configure application services dynamically. From Chapter 5 onward most of our examples are configured dynamically. |
