The device repository contains information about devices stored as device policies. This information is used by MCS when generating pages tailored to the requesting device. The device information is stored within a device repository storage. A device repository client represents the device repository that is present in a running Java application. During the initialization process a client instance (e.g. an MCS instance) registers its own instance of a private JMX MBean in an MBean server to enable remote management of the device repository client via the drManager utility.
The device repository contains information about devices stored as device policies. This information is used by MCS when generating pages tailored to the requesting device. The device information is stored within a device repository storage. A device repository client represents the device repository that is present in a running Java application. During the initialization process a client instance (e.g. an MCS instance) registers its own instance of a private JMX MBean in an MBean server to enable remote management of the device repository client via the drManager utility.
The device repository storage and its clients can only be modified using the drManager CLI utility.
The device information can be stored in a file system directory, or in a JDBC compliant database. Typically, a device repository storage will contain a number of different versions of the device information at a time, allowing administrators to choose one to suit the requirements of a given project. When there is a need to apply a device repository update, the administrator will import a new version of the device information into the storage, and then switch to it using the drManager CLI utility.
A device repository file is a compressed XML file containing attributes of the devices. The directory-based device repository consists of a number of different versions of the device information kept in .mdpr files, and a Java properties file called repository.properties that contains configuration information. This file is automatically created and edited by the drManager utility. The repository can also be imported to a JDBC database, using drManager, to get optimum performance.
The device repository directory cannot contain any files other than the repository.properties file and the .mdpr files for the versions listed in repository.properties.
The MCS runtime can use the device repository held in a directory, or in a JDBC compliant database, whereas the MCS policy editors can only access the device information kept in a device repository file. By default, the MCS runtime uses the directory-based device repository.
The MCS runtime can still use the device repository kept in a stand-alone device repository file. However, this method is now deprecated.
Because new devices are always being added by manufacturers, and over several hundred attributes are recorded for many devices, the MCS repository is continually reviewed and updated. Updates to the device information can be obtained over the Web using the Mobile Portal Toolkit Import wizard. As an alternative to the Mobile Portal Toolkit interface to the device update service, administrators can use the mcsUpdateClient command line utility to download the latest version of an update, the mcsRepositoryManager utility to merge repositories and report on the merge, and the drManager utility to import the new device information to the device repository storage and dynamically update the repository clients. Refer to the topic entitled Device repository update CLI and Device repository manager CLI for further information.
The device information used by MCS at runtime can be updated statically (this method requires an MCS instance to be restarted) or dynamically (i.e. without restarting an MCS instance).
To statically update the device information used by the MCS runtime, the administrator needs to shutdown an MCS instance or all the MCS nodes in a cluster, update the device repository information, and then restart the servers that were shutdown. The static update is atomic and consistent across all the MCS nodes. Unfortunately, it may be a time-consuming process, and more importantly it requires the server shutdown while the update is being performed.
To dynamically update the device information used by the MCS runtime, the administrator must import a new version of the device information into the device repository storage and then switch the storage and its clients to use the newly imported version. The dynamic update is atomic and consistent across all the nodes and it does not require any servers to be taken down while the update is being done, and therefore it minimizes the impact of the update. Refer to the topic entitled Device repository manager CLI for details of the drManager command parameters.