A brief description of the object-oriented internal aspects of the base monitor is useful in understanding RMS.
Every object is an independent instance that carries out actions (typically implemented by shell scripts) according to rules based on its state and messages received from detectors or other objects. States, detectors, and scripts are briefly described in the section "Chapter 1 Introduction". The following sections provide more details about RMS internal structure and inter-object communication.
The configuration wizards generate a description for all applications that will be monitored by RMS. The description, which is maintained in an RMS-specific meta-language, represents every application with a logical graph that has the following characteristics:
Resources required by the applications are represented by objects in this graph.
Parent/child relationships between objects represent interdependencies between resources.
Object attributes represent the properties of the resources and the actions that are required for specific resources.
The proactive procedures that bring a particular object online or take it offline are specified by referring to shell scripts that are configured as attributes of the object. Other script attributes specify actions to be taken in reaction to state changes of the object as a result of messages from other objects.
A userApplication object has no detector, and if it has been configured by the RMS Wizard Tools or the RMS Wizard Kit, it has no scripts specified. Instead, a child Cmdline resource is configured with the appropriate scripts, and it is this object that interacts with the actual user application in the operating system environment. In this case, the userApplication becomes a logical container that represents the combined states of the resources in its graph.
RMS objects exchange messages for the following purposes:
To send requests
To communicate changes in the object states
In general, objects communicate only with their direct parents and children.
RMS sends incoming external requests to the parent userApplication object before it forwards the requests to the children. A userApplication object can also generate its own requests on the basis of changes to its state (such as a change over to the Faulted state). Requests originating from the userApplication are forwarded from the parent to the child (top-down).
