| Section 2.2 described the naming and linking design dimensions that developers need to consider when configuring networked applications. An extensible strategy for addressing these design dimensions is to apply the Component Configurator design pattern [POSA2]. This pattern allows an application to reconfigure its services at run time without having to modify, recompile, or relink the program itself, or shut down and restart the application. The ACE Service Configurator framework is a portable implementation of the Component Configurator pattern that allows applications to defer configuration and implementation decisions about their services until late in the design cycle ”as late as installation time or even at run time. The ACE Service Configurator framework supports the ability to activate services selectively at run time regardless of whether they are -
Static services, which are linked statically into an application program -
Dynamic services, which are linked from one or more shared libraries (DLLs) Each service can also be passed argc / argv -style arguments to set certain information at run time. Due to ACE's integrated framework design, services using the ACE Service Configurator framework can also be dispatched by the ACE Reactor framework. This chapter examines the following ACE Service Configurator framework classes: | ACE Class | Description | | ACE_Service_Object | Defines a uniform interface that the ACE Service Configurator framework uses to configure and control a service implementation. Control operations include initializing, suspending, resuming, and terminating a service. | | ACE_Service_Repository | A central repository for all services managed using the ACE Service Configurator framework. It provides methods for locating, reporting on, and controlling all of an application's configured services. | | ACE_Service_Repository_Iterator | A portable mechanism for iterating through all the services in a repository. | | ACE_Service_Config | Provides an interpreter that parses and executes scripts specifying which services to (re)configure into an application (e.g., by linking and unlinking DLLs) and which services to suspend and resume. | The most important relationships between the classes in the ACE Service Configurator framework are shown in Figure 5.1. These classes play the following roles in accordance with the Component Configurator pattern [POSA2]: Figure 5.1. The ACE Service Configurator Framework Classes  -
Configuration management layer classes perform application-independent strategies to install, initialize, control, and shut down service objects. The classes in the configuration management layer in the ACE Service Configurator framework include ACE_Service_Config , ACE_Service_Repository , and ACE_Service_Repository_Iterator . -
Application layer classes implement concrete services to perform an application's processing. In the ACE Service Configurator framework, application layer classes are descendants of ACE_Service_Object , which in turn inherits from ACE_Event_Handler (Chapter 3), thereby enabling service objects to be linked and unlinked dynamically, and to participate in the ACE Reactor framework. The ACE Service Configurator framework provides the following benefits: -
Flexibility. The framework allows developers to offer multiple services, and a choice of different implementations of services, that can be assembled at run time. The choices concerning which services to execute on which network node(s) can be made (and changed) at any point, ranging from application build time to the actual point when services start running. Developers can also limit choices (e.g., by not offering dynamically linkable services) where desired. -
Configurability. Developers can customize and configure application data for nearly any aspect of a service and for each deployment. Services can be developed to read traditional configuration data, such as port numbers , network addresses, and file system locations. Moreover, services can allow tuning and performance decisions to be deferred until the right information is available to guide them. For example, depending on the run-time platform's available multithreading facilities and available CPUs, it may be either more or less efficient to run multiple services in separate threads or separate processes. The ACE Service Configurator framework enables applications to be configured by site-knowledgable administrators, or they can select and tune these behaviors flexibly at run time, when there's enough information to help match client demands with available system processing resources. -
Managability. All configuration information can be stored in a configuration script file, known as svc.conf . The framework uses these scripts to load and configure services. An application's installation procedure can record settings in an svc.conf file. Administrators can also edit and tune this information as needed, without rebuilding the application itself. Applications can form their own configuration directives and pass them directly to the ACE Service Configurator framework. The framework groups an application's services into one administrative unit and enables an application to report on its services and their states. -
Consistency. The framework imposes a uniform interface for initializing, suspending, resuming, and terminating a service. This uniformity provides consistency to framework users and allows services to be treated as building blocks that can be assembled flexibly to form complete applications. -
Maintainability. The framework's decoupling of service implementation from configuration into networked applications allows service implementations to evolve over time, independently of which networked applications they're included in. Each service can be developed and tested independently, which simplifies subsequent service composition and increases reuse. -
Enhanced dynamism and control. The framework enables a service to be reconfigured dynamically without modifying, recompiling, or statically relinking existing code. Each service can also be reconfigured without affecting other services or stopping and restarting the server process itself. These reconfiguration capabilities are often required for high-availability applications, such as mission-critical systems that perform online transaction processing or telecom call processing. The remainder of this chapter motivates and describes the capabilities of each class in the ACE Service Configurator framework. We also illustrate how this framework can be used to enhance the extensibility of our networked logging server. If you aren't familiar with the Component Configurator pattern from POSA2 we recommend that you read about it first before delving into the detailed examples in this chapter. |
