The dynamic reconfigurator mechanism for CORBA components has two major parts: a System Configurator (SC) inside at the decision engine and a Component Configurator (CC) as a wrapper around each individual application component.

1) System Configurator (SC)
The SC uses a data structure (componentInstList) to store connection information between components. Each component keeps a client list and a server list. The client list keeps track of client components with provided interfaces of the component. Each interface contains the names and request interfaces of the clients that need the provided interfaces. The server list consists of the names and provided interfaces of the server components. The data structure is shown as follows:

   Vector componentInstList; //Each element is of type ComponentInst
    ComponentInst {
       Vector clientList; Vector serverList; String componentName; ¡­
    }
    //Vector clientList contains elements with the type of ClientInfo
    ClientInfo {
       String providedInterface;
       A list of client names and interface names that use this provided interface;
    }
    //Vector serverList contains elements with the type of ServerInfo.
    ServerInfo {
       String requiredInterfaceName; String serverName;
       String serverInterfaceName;
    }

With componentInstList, the SC is able to find the clients or servers of a certain component during the run time. The SC provides a SystemConfiguratorSvcs interface for a CC to access.

    interface SystemConfiguratorSvcs {
       void register(in string componentName, in ComponentConfiguratorSvcs cc);
       void notify_ready(in string componentName);
    }

When a new component starts, its associated component reconfigurator calls the SC¡¯s register function and passes its name and reference. The SC registers this component and its reference. The SC will use this reference to call functions provided in this component configurator service. The notify_ready function is used by the component to notify the SC that the component is blocked and ready for further operations.Several reconfiguration primitives are provided. The reconfiguration primitives can be triggered by the decision engine or can be invoked explicitly by a system administrator through a system configuration GUI

2) Component Configurator (CC)
The CC is a packager of the actual component i.e. the CORBA-based application component. The reason that we use this pattern for dynamic reconfiguration is to separate connections from implementations, thus separating the dynamic reconfiguration code from the application code. Services that a component provides sit in the component reconfigurator; and connections to the system configurator and other server components are also held by the component reconfigurator. In order to make the CC configurable, a service to the system configurator should be provided with the following interface implementation.

    interface ComponentConfiguratorSvcs {
       void block();
       void resume();
       boolean move(in string ipAddress);
       boolean saveState();
       boolean loadState();
       boolean invoke(¡­);
       ¡­other operations ¡­
       void addConnection(in string requiredInterface, in string componentName,
                          in string providedInterface, in StringList orbInitParams);
       string getServiceHost(in string interfaceName);
       string getServicePort(in string interfaceName);
    };

The reference to ComponentConfiguratorSvcs service is registered to the system configurator when the component starts. The system configurator uses this reference to call functions in ComponentConfiguratorSvcs. addConnection function is used to establish a connection from the component to a server component, where the parameter requiredInteface is the name of the client interface, componentName is the name of the server component and the providedInterface is the name of the server provided interface. getServiceHost() and getServicePort() are used to get the location (host ip and port number) where a service is running.

3) Reconfiguration efficiency algorithms

A reconfiguration efficiency algorithm adopt by AwareWare is provided by C. Bidan, and it satisfies two constraints: the consistency constraint (CC) and the efficiency constraint (EC). Under consistency constraint, if a connection is going to be removed, any service request related to this connection requested earlier than connection removal operation should be completed. Under efficiency constraint, only those connections that are to be removed or connections that are connected to a to-be-removed component are affected during the dynamic reconfiguration.
The reconfiguration efficiency algorithm in AwareWare is implemented as follows. The system configurator finds a list of client components that need services from the component specified by the remove operation. Then the system configurator sends block messages to those client components, which set their states as ¡®blocked¡¯ to prevent new requests. When all the previously accepted requests are completed, each client component notifies the system configurator that it has been blocked. After the system configurator has received all notifications, it blocks any request from the component specified by the operation to its servers. Now the component is ready for dynamic reconfigurations such as remove, relink, etc.

 A large number of distributed applications use Dynamic Linked Libraries (DLLs) to implement particular services and reuse them extensively as the construct of an application. In AwareWare, we use "DLL component" to describe a service that is implemented in a DLL. Please note that strictly speaking, DLL is not considered as a component model.
AwareWare supports the dynamic reconfiguration for DLL component based application. A similar architecture exists as the CORBA-based reconfiguration. However, the implementation of the DLL based reconfiguration differs to the CORBA-based in multiple aspects.

1) The packaging for each DLL has three major functions. First it provides the name of the DLL component and its version information, so that the DLL component can be identified by the component container. Second, it provides several standard interfaces besides the component service implementation, e.g. input port, output port, set parameter, start, and stop interfaces, so that the DLL component can process data and intercommunicate with other DLL components in the same process space. Third, it provides a standard function GetThisComponent to instantiate the DLL component and returns the component reference to component container.

2) A component container is provided to load, create, maintain, identify the DLL components, and communicate to the system reconfigurator. The container first loads all necessary DLLs as components described in the XML, and creates the instances of these DLL classes by calling GetThisComponent. Container then creates a default parameter list associated with each component. Parameters are used to set the component initial status before they are called by different actuators.

3) DLL-based component reconfigurator is a DLL component pointer list, which points the required components that are created in the container, in sequence. Reconfigurator also has a parameter list under the user rule associated with each component. Application set the input of the first component in the component list, and the output of the previous component is connected to the input of the next component by a connecter. The output of the last component is then returned to the application.

4) Actuator Exchange: Because all the actuator just keeps a pointer list that point to the components of the container, all actuators share the same component instance if their use the same component. When the system architecture is changed to accommodate the new requirements under event notifications, the architecture would load a different actuator. To load a new actuator, the architecture first waits for the completion of existing data processing in current actuator. Next, architecture loads the container parameter list to reset the components status. After that, architecture loads the parameter list of the new actuator to set the required component status. Finally, architecture changes the actuator pointer to set the new actuator as the existing actuator to process the accepted data.

TAO: http://www.cs.wustl.edu/~schmidt/TAO.html

DynamicTao: http://srg.cs.uiuc.edu/2k/dynamicTAO/

RAPIDware: Component-based development of adaptable and dependable middleware.

QuO: Quality Objects

ABLE: Architecture Based Languages and Environments

Composable Software Systems

Aspect Oriented Programming