SLEE Configuration and Sentinel upgrades

The SLEE specification defines 3 types of configuration:

Profiles are defined as tables and require a profile specification which can have several tables associated. The attributes defined in a profile specification can be of complex types and the way the data is persisted and retrieved is defined by Java code which is loaded into Rhino and referenced by SBBs or SBB parts. The Java code for profiles implements the profile interfaces defined in the SLEE specification. The profiles can be configured via the rhino-console or using MBean operations, which under the hood calls the methods defined in the profile interface that SLEE defines.

The RA properties are defined as part of the RA code and SLEE defines a different interface to set and read those properties. Each RA entity from the same RA can have different property values for the same properties.

Rhino also has utilities that allow the data to be exported to the file system and later re-imported to the same or another system. This data is in the form of XML files. Each profile table has a file with the profile contents and the profile default values, but it does not indicate which profile spec that profile table was created from. The RA properties are in different files and are set when the RA entity is created. This difference between RAs and profile tables requires complex handling of the data in the scope of major upgrades.

Transformation is only required for major upgrade, since by definition the only configuration changes allowed in a minor upgrade are ones that do not give rise to a need to perform transformation.

The image below shows the high level overview of how orca handles the SLEE configuration between two versions.

The system with version A has a set of configuration schema and configuration data. The version B changes the configuration schema because new features required those.

Schema changes can:

When trying to import the data from system version A into system version B, some configuration won’t apply due to schema changes, for example removing a profile attribute. The system version B will have the new schema in place and expects the data to conform to it. In order to import the version A configuration into system version B, it is necessary to first adjust that data.

orca persists the version A configuration and via a set of transformation rules it changes the version A configuration to be compatible to the version B schema. The rules are expressed in Java using a transformation API and are applied during the upgrade procedure. Once the configuration is compatible to system version B, it is imported and the system B will have the equivalent configuration to system version A.

Two tools are used to persist the configuration: rhino-export and slee-data-migration.

rhino-export will persist the profile tables and its profiles, while slee-data-migration will persist the RAs configuration, profile specifications and log settings.

To give the transformation process as much information as possible, these two tools are actually used to package up the configuration data both from the original system (version A) and from the uplevel system (version B) after the new version has been installed, but before it has been configured.

Thus there are four data files used as input to the slee-data-transformation process. The slee-data-transformation will create a transformed copy of the profile tables attributes and the data produced by the rhino-export of version A. It will also create a transformed copy of the data produced from version A by the slee-data-migration. Transformation is not applied to the data persisted from version B, but the transformation rules can consult it to decide how to modify the version A data.

Once the transformation is done, orca will import the transformed profiles and call the slee-data-migration to import the transformed RAs configuration and the (unmodified) log settings.

Certain parts of the configuration, specifically the feature-scripts, are too complex to be handled by the general data transformation process, and are therefore covered by a separate process.