Java Desktop System Configuration Manager Release 1.1 Developer Guide

Chapter 5 Configuration Concepts

The presentation of the different trees in this document differs from what is covered in the administration guide. The administration guide does not mention the configuration tree because knowledge of the two different configuration and configuration policy trees is not necessary to use the Configuration Manager.

Strata

From the client point of view, the applications get configuration data from three separate data sources or strata. These strata are the default stratum, the user stratum and the policy stratum.

The user stratum and default stratum are the existing data sources that client applications currently deal with. The default stratum is deployed with the application and is mostly unchanged throughout its lifetime. It is stored locally alongside the application. The user stratum stores the changes made by a given user to the application settings. It is stored either locally or in a shared location.

The policy stratum is stored centrally in the configuration repository, which contains configuration settings that are managed by the Configuration Manager. These settings are associated on the server with entities such as organizations, roles, users, and hosts. They are accessed on behalf of a given user or host and are read-only for the user or host.

The Configuration Manager is able to read or write the configuration settings of the policy stratum only. The content of the default or user stratum cannot be accessed by the Configuration Manager. The client application configuration system is in charge of the retrieval and the combination of the values gathered from all strata. See Merging.

Trees

The Configuration Manager deals with four different hierarchical structures, also known as trees. To understand how the Configuration Manager works, it is important to distinguish these trees.

The first tree is the organization tree, the gray area inFigure 5–1, which represents the relationships between organizational units. The first level of the tree represents the organization itself. Subsequent levels can represent, for instance, departments and sub-departments. The last level can represent the members of these departments.

The second tree is the domain tree, which represents relationships between elements of the network such as domains or hosts. The first level of the tree represents the overall network. Subsequent levels can represent, for instance, the various subnets, and the last level the actual hosts in these subnets.

In the Configuration Manager, these two trees are currently obtained by interpreting the contents of an LDAP server, which is the typical repository for corporate structures. Each location within the tree in LDAP is called an entity. Entries in a LDAP server are mapped to the entities recognized by the Configuration Manager, namely "Organization", "Role", "User", "Domain" and "Host".

The third tree is the configuration tree, which are represented by the blue areas in Figure 5–1. The configuration tree hierarchically groups configuration settings in the back end. At the highest level of the configuration tree are components. Components comprise configuration settings that configure one software component. All elements below a component are either nodes or properties. Nodes can contain nodes or properties. Properties contain configuration settings. Each configuration setting can be referred to by a path. For example, org.openoffice.Office.Common/ExternalMailer/Program is referring to the "Program" configuration setting, which is in the "External Mailer" node under the "Common" component.

Each entity in the organization or domain tree can have its own configuration tree, resulting in two "trees of trees", one being an organization tree containing configuration trees and the other a domain tree containing configuration trees.

The fourth tree is the configuration policies tree, which is represented by the yellow area of Figure 5–1. The configuration policies tree is used to visually organize the configuration settings in order to conveniently browse and edit them. This is done by defining a hierarchy that is completely independent from the hierarchy in the configuration tree. The concrete values that are displayed in the configuration policy tree are obtained by referencing the location of the configuration settings in the configuration tree. See the arrows in Figure 5–1. This allows for the separation of the different design requirements for GUI and back-end data. For example, the position of a configuration setting changes more rapidly on the GUI than in the back end.

At the highest level of the configuration policy tree, there are applications with subsequent levels corresponding to various modules and sub-modules of that application, the last level being the actual configuration settings. A similar presentation can be seen in configuration systems dealing with many settings, such as the settings from StarOfficeTM or Mozilla, where, for instance, the HomeUrl setting would be found under Mozilla/Navigator/HomeUrl in the Preferences dialog.


Note –

The presentation of the different trees in this document differs from the presentation in the Java Desktop System Configuration Manager Release 1.1 Administration Guide. The administration guide does not mention the configuration tree because a knowledge of the two different configuration and configuration policy trees is not necessary to use the Configuration Managerr.


Figure 5–1 “Tree of trees”

Tree of trees

Merging

The configuration settings that are finally used for a given entity is determined by merging the configuration settings of that entity and those of its parent entities on the client side. For instance, the settings for a user take into account the policies assigned to that user and those assigned to the organizations that the user belongs to. The merging works by inheritance, that is, the user inherits the settings specified in the upper levels of the organization structure. This process is illustrated in Figure 5–2, which shows how the settings of the "marketing" organization are inherited by one of its members, user "jclarke". The configuration settings of user "jclarke" override some of the inherited settings.

Figure 5–2 Merge

Merge example

The three strata are merged to form the final set of configuration settings in the same way that the configuration settings are merged in the policy stratum. The user stratum takes precedence over the policy stratum, which in turn takes precedence over the default stratum. It is possible to mark configuration settings in the policy stratum so that configuration settings in the user stratum are no longer considered during the merge process, so that users not allowed to override settings made by an administrator with the Configuration Manager on their own client machines. This is called protection.

User-based and Host-based Configuration

The concepts for working with the organization tree and the domain tree are the same. The main difference between the two is that the organization tree consists of users and the domain tree consists of hosts. Having users and hosts in two separate trees enables the Configuration Manager to provide user-based and host-based configuration.

On the client side, the user-based configuration settings are fetched from the organization tree based on the user name. The host-based configuration settings are fetched from the domain tree based on the IP or the host name of the host the user is working on. The user settings are merged after the host settings, which means that the user settings take precedence over the host settings. For example, by offering these two types of configuration, roaming users can have one user-based configuration but nevertheless can make use of the optimal proxy configuration, depending on the host they are on.