Describes the common principles involved in the structure of the RM backend system.

The RM backend infrastructure is the foundation of the RM system. It provides a structural model and base functional environment for all components of the system as well as advanced mechanisms for their configuration and monitoring.

The backend can comprise a single host or can be distributed over a number of machines available in the local network or in a wide area network. The physical placement of the backend system depends on the needs of the device operator. RM provides support for different deployment scales of the system (see "Deployment Scenarios" below).

RM Backend Context

The RM backend is accessed locally or remotely by various types of users or systems. Some of them have the right to alter the backend components (such as device operators), others only use them. Users can also access the RM backend through third-party systems, such as J2EE application servers. The RM backend uses third-party database servers to store the information about the entire system. It can be configured to communicate with external payment systems for handling payment transactions.
 

Backend Server Hosts

The nodes of the RM backend are referred to with the common name backend server hosts. Each backend server host has one or more roles within the system. There are three types of roles:

  • Control center (CC) - This is the unit that enables initial configuration and setup of an RM system. Once the system is set up, the control center may go offline, for it does not have other special functions within the system. However, further system configuration operations, such as adding or removing backend server hosts, can be performed only through the control center.
  • Management server (MS) - A management server, as its name suggests, is responsible for the management of devices registered in the system. There can be more than one management server in an RM system, each of them assigned to a separate branch of the device management tree. This can be used for static load distribution among the separate MSs.
  • Remote access server (RAS) - A remote access server's purpose is to handle connections from frontend modules. Frontend applications can also connect to the control center. However, the availability of remote access servers distributes the load among multiple components and enables connections from external applications even when the control center is offline.

A backend server host can have more than one role within the system (for example: both MS and RAS). Reversely, a single MS or RAS can be distributed over more than one backend host (see "MS and RAS Clusters" below).

Component IDs

When an RM system is initially configured, each of its components receives an individual ID, stored in the system database. There are IDs for each backend server host, management server, control center and remote access server. The entire system configuration also receives an unique ID, which distinguishes it from other RM systems. The IDs perform two functions:

  • Uniquely identify the host or role within the RM system.
  • Disable the "stealing" of modules between different RM systems. Each time a connection is established, the contacted party compares its locally stored RM system ID with the one presented by the contacting party. If the presented ID does not match the stored one, the contacted cancels the connection.

MS and RAS Clusters

To ensure maximum scalability, the RM system allows a number of backend server hosts to "unite" and form one or more clustered MSs or a clustered RAS. The process of clustering is transparent to all other system components. Both single-host and multihost (clustered) components are treated the same way. The members of the same cluster take care of distributing the load of managed devices (in case of a clustered MS) or external connections (in case of a clustered RAS) among themselves in a fairly equal manner.

When a backend host or an external application refers to a particular MS or to the RAS, the system chooses a member of the MS/RAS that can handle the request without the need for the requester to specify the exact host.

Communication between Backend Nodes

The RM system provides flexible mechanisms for exchanging information between backend hosts. The backend communication framework allows data to be distributed globally within the whole system, or targeted to a single host, host role, or all members of a cluster.

The backend communication framework consists of the following components:

  • Network connection framework – Manages the physical connections between backend server hosts.
  • RM RPC Service – Enables the remote invocation of services between different system components, including Remote Access Clients.
  • RM Events Service – Provides mechanism for inter-host communication through distribution of events.

Deployment Scenarios

The scalability feature of RM allows the system to fit different deployment models. From a small-scale development system to large-scale enterprise systems. The backend infrastructure can include various numbers of MS, RAS and DB servers residing in different physical locations. The following models represent exemplary schemes of deployment for different production fields.

Small-Scale Deployment Configuration

The simplest deployment model is suitable for development/evaluation purposes. It consists of one backend server host, assigned simultaneously the CC, MS and RAS roles. The RM databases are placed on an RDBMS server residing on the same host or in the local network. There can be up to 10000 connected devices registered in this system at one time, for the system lacks resources to support more substantial loading. The administrator can access the system locally on the backend host or remotely from any point through the console "Management Console" (MC). The small-scale model is illustrated in the following figure:

Medium-Scale Deployment Configuration

A medium-scale deployment configuration involves a number of backend hosts representing a single clustered MS, a single clustered RAS and a single RDBMS storing the system information. The clustered MS manages all devices registered in the system, distributing the load between the hosts participating in the cluster. The RAS servers are deployed on every backend host and distribute among themselves the requests from Remote Access Clients (RACs), including the console, and external backend systems. There is also a control center available on one of the hosts. The CC can optionally be turned off once the system is configured, and subsequently turned on if there is a need for reconfiguring the system. Administrators can access the system through the console "Management Console".

RM Users

The target users of RM are two types: system administrator and device operators.

System Administrator

The system administrator has a vital role in the administration of an RM system. Only a person owning this user role has the right to change the configuration of the entire RM system - add/remove management servers, manage users, configure databases, etc.

The system administrator has access to all RM functions and is identified with the system account. The system account is available by default. It can not be removed, only its password can be changed. This account is also used internally by the RM components for the normal system interaction between them.

Device Operator

The device operator (DO) is considered the administrator of the devices and of the modules involved in the RM device management paradigm. The DO has exclusive rights to register devices and execute operations over them, create and manage users, and, optionally, offer service packages to customers. All device operators participate in a common user group - administration. There is a default user who has the DO role – the admin user.

Web Services

Certain aspects of an RM system can also be conveniently accessed by using the Management via Web Services. They are exported for the major functional services of the backend such as device management, user management, software repository storage, etc.