dynamicTAO:
Adding Dynamic Flexibility to ACE/TAO

This page describes the design for something that I've been calling dynamicTAO. I've started its implementation recently and I expect to have most of what is described in this page ready by December 98.

TAO is internally composed of a number of services that are carried out by Strategies. At the present moment (April/98), TAO allows a system administrator to use a configuration file to specify, for each of its strategies, specific implementations and their configuration parameters. Once the system is up and running, there's little support for reconfiguration.

My idea is to add support for dynamic reconfiguration of ORB components. Moreover, using the same framework, I intend to support the same kind of dynamic reconfiguration for TAO servants (the server-side applications running on top of the ORB).

The most important features of dynamicTAO are:

• Enabling [remote] reconfiguration and replacement of individual ORB components without the need for restarting the whole ORB.
• An Administration Panel will provide a user-friendly GUI for management of distributed collections of ORBs.
• Enabling upload of code containing new implementations of ORB strategies and new services. This code will take the form of DLLs (initially) or Java byte-code (later).

• System administrators and other automated administration tools will be able to send smart packets (or reconfiguration agents) to the network of ORBs. This capsules will contain code and/or pointers to code implementing new strategies and services.
• An Automatic Network Management System will gather information about the distributed set of ORBs and adapt its behavior in order to maximize its productivity.

  The main components in this figure and their roles are the following.

Traditional ACE/TAO Components:

• ACE_Service_Config: responsible for dynamically linking services from the local disk based on the configuration file svc.conf. These services are added to the ACE_Service_Repository and used by TAO to create its strategies.
• ACE_Service_Repository: a in-memory repository of services. One can iterate over the available services inspecting each of them or lookup for a particular service.
• Default_Strategy_Factory: a factory for TAO strategy objects. A Default_Server_Strategy factory creates strategies used in the server side and a Default_Client_Strategy_Factory takes care of the client side.

New Components:

• Dynamic_Service_Config: receives reconfiguration requests from the Net_Broker. It delegates the execution of some of its methods (e.g. for the initialization of a new service/strategy and its inclusion in the ACE_Service_Repository) to the ACE_Service_Config.

  Once a new service/strategy is added to the service repository and initialized, it can be "installed" in the ORB by calling the install method in the TAO_Dynamic_Config component. If necessary, this will update the Dynamic_Strategy_Factory (see bellow).

  The Dynamic_Service_Config also receives requests for the current state of the service repository. In this case, it queries the ACE_Service_Repository and returns the result in a proper format to the Net_Broker.

• TAO_Dynamic_Config: A subclass of the abstract class Application_Configurator. It contains TAO-specific knowledge of how to update/replace/remove strategies within TAO without breaking it. By encapsulating all TAO-specific knowledge in this class, we are able to use the remaining components of this framework to manage the dynamic configuration of other systems including servants running on top of TAO.

  The idea is that several concrete subclasses of Application_Configurator will be registered with the Dynamic_Service_Config. Thus, the system will be able to reconfigure both TAO and the applications that run on top of it using the same mechanisms.

• Net_Broker: Receives reconfiguration and status requests from remote entities and forwards them to local components. Currently, it services its requests by calling Dynamic_Service_Config. The Net_Broker is also used by remote entities to upload new strategies and services to the local file system. In the latter case, it uses the Local_File_Service to store this files.
• Local_File_Service: a thin layer on top of ACE to store DLLs and .so files in the correct places. Maybe its functionality will be implemented within the Net_Broker.
• Dynamic_Strategy_Factory: It works as the Default_Strategy_Factory component but it can be dynamically reconfigured to create new types of strategies. In the future, this factory will be subclassed to implement additional functionality such as returning different kinds of objects depending upon who is calling it or depending on the current system state. It will be the base for adaptation.