Configuration Database
The configuration parameters for all Components and, in
particular, for all Characteristic Components, i.e. the initial
values for Properties values and all Characteristics for Properties,
are persistently stored in the Configuration Database [RD01
- 4.2.1. Configuration Database]. Any application can make use of
the Configuration Database to get access to configuration
information.
There are 4 different issues related to the problems addressed by
the CDB:
1) input of data by the user
System configurators define the
structure of the system and enter the configuration data. Easy and
intuitive data entry methods are needed.
2) storage of the data
The configuration data is kept into
a database.
3) maintenance and management of the data (e.g.
versioning)
Configuration data changes because the system
structure and/or the implementation of the system’s components
changes with time and has to be maintained under configuration
control.
4) loading data into the ACS Containers
At run-time, the data
has to be retrieved and used to initialize and configure the
Components.
The main objective of the CDB Architecture is to keep these 4
issues as decoupled as possible so that:
We can develop them separately, in
space and time, according to the project priorities and the
availability of resources.
We can eventually use different
technologies
We can, in particular, support multiple data storage
mechanisms (like ALMA Archive, RDBMS and XML files) in different
environments (development, testing, final running system).
The high-level architecture is based on three layers:
1) The Database Itself
It is the database engine we use to
store and retrieve data.
2) The Database Access Layer (DAL) is used to hide the actual
database implementation from applications, so that it is possible to
use the same interfaces to access different database engines, as
described in the requirements and discussed in the following
sections.
3) The Database Clients, store and retrieve data from the database
using only the interfaces provided by the DAL.
Data Clients, like
containers, Managers and Components retrieve their configuration
information from the Database and are involved in issue 4.
On the
other hand, CDB Administration applications are used to configure,
maintain and load data in the database using again interfaces
provided by the DAL layer. They are involved in issue 1 and 3 and
will be possibly using DAL interfaces different from the ones used by
the Data Clients, as will be discussed later on.
Notice that
Data Clients need only data retrieving and not data change functions.
Figure 3.4: Configuration Database architectural
layers
A Database Loader application is used to manipulate database
description files and load them into the Database using the DAL
administrator interfaces. Database Description Files are XML files
and XML Schemas are used to define classes of database entities,
allowing to use inheritance and to define default values. The
Database Loader also takes care of validating the data, to make sure
that only valid and consistent data is actually loaded into the
database. For example, the following inconsistencies should be
spotted and reported:
missing property or characteristic
undefined values, default will be
used
defined values that are not used elsewhere
When a Characteristic Component is instantiated, it configures
itself according to the configuration stored in the Configuration
Database[RD01 - 3.3.2.
Serialization].
The implementation of the Configuration Database is hidden in a
Configuration Database Access API to allow switching among
alternative implementations[RD01
- 4.2.2 Database Design].
The reference implementation is based on XML files and a Java
application loads and parses the XML files. Files are validated at
run time and a separate CDB checker can be used to validate offline
CDB XML files without the need of loading them in a "live"
database.
In ALMA, configuration information is stored in the Telescope and
Monitoring Configuration Data Base (TMCDB). This is based on the
Oracle RDBMS (with the small-footprint RDBMS, hsqldb, used for
small-scale testing). Archive, Control and ACS subsystems are
responsible for the implementation of the Configuration Database
Access API on top of the TMCDB, throught the implementation of a
specific Component. This implementation includes round-trip tools to
convert CDB instances between the XML reference implementation and
the TMCDB. In this way it is possible to develop locally with the XML
implementation and transparently migrate to the final system based on
the ALMA Archive and TMCBD. (Being enhanced).
All Components have access to the Configuration Database during
construction/initialization and later during their operational life.
While accessing the CDB is optional for normal components,
Characteristic Components must retrieve their configuration
information from there.
At a higher level, the Container
responsible for the Components (see Container package) provides an
interface to set the reference to the configuration database used. In
this way it is also easy to switch between different databases at
startup time.
In order to allow switching
between different instances of Configuration Database, the reference
to the DAL used by each Component is provided as a common service by
the Container inside which the Component lives.
Whenever a Container is started,
it gets in touch with a specified DAL instance.
By default, if nothing else is
specified, this is the DAL for Central Configuration Database and is
obtained by requesting the reference to the Manager.
Otherwise, the container can be instructed to use explicitly
another DAL instance, apt to work with a Configuration Database
Engine of one of the supported types.
Figure 3.5: Configuration Database
We define Characteristics as statically defined in the
Configuration Database. This means that is possible to change their
value only by changing the configuration database and reloading just
the corresponding Characteristic Components[RD01
- 14.1.9 Dynamic configuration]. This means that they cannot be
used for, e.g., calibrations that change at run time. With this
definition, calibration values that change at run time should be
implemented as Properties, not as Characteristics. "Static"
calibration values, for example measured by an engineer and not
supposed to change for months can be Characteristics. Characteristics
can change with time or can change with the context.
Note:
It is possible to implement also a more dynamic mechanism, but we
have not identified a requirement for ALMA. This can be done
transparently at a later time extending the Property class with
methods to change the value of characteristics but this has not been
considered in the first design to avoid increasing the complexity of
the system. (Implementation not foreseen for ALMA)
Note:
A Visual Configuration Tool (CT) can be implemented on top of the
Database Loader. This can be completely independent of all other
aspects of CDB and therefore can be implemented at a later stage.
ALMA configuration data is edited using the TMCDB tools and therefore
no requirement for such Visual Configuration Tool has been
recognized. The basic features are described hereafter for a possible
future implementation (Implementation not foreseen for ALMA)
The
CT allows to visually edit the structure/schema of the configuration
database and to fill in the values inside the instantiated database.
The
CT supports expressions and variables.
Allows
switching between different views (think of Eclipse): source,
members, hierarchy, editions, and visual composition. Like in
Eclipse, there should be wizards that help create new structures,
but the structures can be created also manually. Structures can be
changed using connections and drag&drop.
An
existing CDB can be parsed and displayed visually, for easier
re-engineering.
There
is a tree view in CT that uses colour codes and icons to define
classes or properties that are abstract, inherited, calculated (from
expressions) and imported from templates.
A
“spreadsheet view” is used for mass population of configuration
data. The normal approach is to define the structure with the tools
just described, and then to write a substitution file, which
contains data in compact form in a table that is similar to a
spreadsheet. Ideally, it should be straightforward to create such a
substitution file in a spreadsheet program and use it from there
directly.
The
development of CT will be based on existing tools. For example it
could be an Eclipse plugin.