Global Configuration Repository

Configuration Repository is a logical folder on file system. This repository contains configuration files and is located on a central location. Configuration Server continuously monitors this folder for any changes. If a configuration files changes, A Internal FileChangeEvent is raised, this would result into appropriate configuration events to be propagated across the network.

Pluggable Configuration Handlers or Parsers allowed parse/retrieve configuration information from various sources (Like Database, XML files, INI files, Registry) etc.The timing or location of the parsing is configurable (i.e. At Server or Client side).

Master Configuration File:-

The configuration repository contains a master configuration file (Like Master Index file: Refer: JESConfigurationContext.dtd, Example: JESConfig.xml). This file has configuration data for the configuration server and most importantly the configuration data for application components (Like Configuration File Name, Configuration Class Names, Events, Node based subscription control, Global Variables, files, etc…)

The things to be noted about the master configuration file are:-

• Provision to declare Global variables, which can be used across other configuration files. This feature also provides an ability to specify file paths, server address, etc at global level and later use them across in component configuration files.
• The configuration data is defined at application component level (Ex. Logger, ExceptionHandler, FrontController, etc). One could have one or more configuration files for a application component.
• Similarly one can enable/disable callbacks (Bootstrap, Reload, destroy) for a component.
• It is extremely important to have an ability to push configuration information at a node level (a node in this case, means an instance of configuration client, each instance could be uniquely named or shared).

  For example:

  Let us suppose, we need to use logger component in web application and also in business application, but we want the Logger to behave differently on each of these application instances.

  In such a case by having the same configuration information for both of these applications would not help, this is where you need to have ability to define configuration data for each application separately, the framework provides the ability to define separate configuration data per node level. A node in this case is a logical unit and is represented by unique instance of a configuration manager.

  Individual/Component Configuration Files

  The framework comes with a standard format or grammar (DTD and XML Schema) for creating individual configuration files (Refer: ServiceConfiguration.dtd Example: JESLoggingConfig).

  In all likeness, one might have to deal with third-party configuration files (Ex. Log4J configuration file), the approach taken in this regard is to replicate this file to the client nodes during application bootstrap process and also ensure that at all times, and this file is kept in sync with the file in the global repository.

  When ever these file changes, the configuration server ensures that this file is replicated to the client node and also issues a callback to the user application component indicating the availability of the latest file. The client component now can parse and re-tune it behavior based on the new configuration data.

Configuration Server

Configuration Server acts as a controller component and is responsible for managing configuration information, raising configuration events, serves management and monitoring requests, etc…

From a process perspective: the configuration server is deamon service running on the remote node (It is designed, in such manner that, even if the server fails, the application using it would not fail), though design provisions for clustering were made but are not implemented.

From object model perspective:

• Configuration server is a Singleton based controller
• Has Observer/Observable monitoring layer, where each observable is coupled to a transport endpoint
• Has built-in Parsers, Broadcaster (Transport Interfaces), and other relevant interfaces, These interfaces can be later extended to provide event propagation on multiple transports mechanisms.
  • A Chain-Of-Responsibility(GOF: COR) is used to broadcasting configuration events on multiple transport mechanisms.
• Object hierarchy for EVENT and CONFIGURATOR objects.

From a program execution perspective:

In, Bootstrap Mode

• Parses all the configuration files and creates configuration objects, which are stored in a memory based repository. 
• Creates necessary client listeners,event broadcasters, monitoring, heartbeat, cleanup threads, etc.  

In, Operation Mode (Listerning Mode)

• Listerns for External Configuration Change Events from monitoring process. 

  Example: FileChangeEvent is raised by File Change Observer Thread, when ever configuration file changes (Start point for hot deployment feature) 

• Listens for User Control Events raised by Management and Monitoring Software Since, Events can be raised by a distributed or a remote application, the CS provides a Pluggable API to issues events from external applications (Remote Control API). 

In, Process Mode

• Based on the internal event, a secondary configuration event is generated and is selectively transported to configuration manager clients using chain of broadcasters. The selectivity is decided based on information available in the master configuration file.
• If, the input event is a file change event, the configuration file is parsed again to get new configuration object, which is updated in local memory based repository, the object is embedded as part Configuration event, which is broadcasted to remote nodes.

  The idea of having a memory based repository is many folds,

  • To provide an ability for the clients to ask for back-dated events and configuration objects, hence the performance is dramatically improved (Consider a case of having different nodes starting up at different times and requesting for configuration object)
  • This repository at a later date could be in memory replicated (using reliable multicasting) to another instance of configuration server (for clustering feature). Never really implemented this part.

Configuration Manager

On the client side, the following sub-components exist:-

• Configuration Manager
• Local Repository
• Client API = Configurator Locator + Callback Interface + Tools

Configuration Manager is a client side library component, it is executed with-in the process space of the parent application, as Configuration Manager is a singleton, only one copy of it existed in the address space.

One could configure a transport of his/her choice using environment variables and also assign a unique node or instance id to it (infact, there is a pre -defined resolution mechanism to obtain its own configuration information). Depending on the type of transport, it could spawn few listener threads. The idea is to make it as lightweight as possible.

Local Repository: Is where local configuration files (mostly third -party configuration files) are stored, these files are transported at run -time from server to client. These files are also resynced to keep in sync with files existing at server using Configuration Change Events. The local instance of the third-party components pointed to these files (Performant, as compared to accessing a remote or network file system)

Configuration Locator: Part of Client API, this is a singleton implementation.

• Application clients/components use this sub-component to get a handle of the configurator object.
• Configurator Locator provides a callback to application clients using a component callback implementation.
• Provides an option for applications to register their own listeners.

Essentially, this component internally consists of configurator objects in its memory based repository. The configuration manager takes care of updating this memory repository as and when configuration changes. Since the retrieval of the object is from the memory, the retrieval of the same is super quick.

Callback Interface: Part of the Client API Model, application components need to implement these interface to be notified of configuration changes. However one could enable/disable the callbacks at a run-time in master configuration file.

Tools: Code Generation Tool to generate Configuration Object code from a configuration file, Event Monitoring and Generation Tools, Event History Log Viewer (Some of them are yet to be implemented)