This section describes the EMS framework components.
The EMS API |
 |
The EMS API is the interface between the registrar, client
applications, target applications, and resource monitors as illustrated
in Figure 1-1 “Event Monitoring Service Components”. The EMS API is provided as part of the EMS product.
The EMS API manages these events:
client to registrar communication
puts clients in contact with the appropriate monitor for discovery
and registering monitor requests.
registrar to monitor communication passes client
requests to appropriate monitor
make comparisons between the current resource values
and pre-selected threshold values
monitor to target application communication:
sends events to configured targets
(pre-existing targets or target you create)
sends notifications to target applications when
the resource values meet event criteria
For exarmple, a target TCP application uses EMS API to translate TCP
messages into EMS objects. This enables the fields to be real. The
target application then reads the fields of the EMS objects.
The registrar |
|
The registrar is a link between the client applications and
the resource monitors. It communicates with the resource monitors
on behalf of the client applications to retrieve information requested
by the clients. The registrar runs on the same system as the resource
monitors. The registrar
is provided as part of the EMS product.
The registrar does not need to keep any state information
and does not need to be highly available. It does not need to be
running while a resource is being monitored. The registrar is needed
only to start the monitors and to provide communication between
clients and monitors.
One registrar process is started each time a client application
calls rm_client_connect(), so a registrar is always connected to one client. Depending
on the requests sent by the client, the registrar may be connected
to 0, 1, 2, or more resource monitors concurrently. The information
in the messages contains enough information to allow the registrar
to route the requests and replies correctly.
Figure 1-3 “Connections Among Clients and registrars” gives an example of what kinds
of connections are possible.
Each time the registrar starts, it reads the resource dictionary, exchanges
internal version information with the client application, and prepares
to receive client requests. When a request arrives, the registrar analyzes
it to determine if it is one that it can reply to, or whether it needs
to pass the request to a resource monitor.
When the registrar needs to pass the request to a resource
monitor, it needs to determine if the resource monitor is currently
running. If the appropriate resource monitor process is not found,
the registrar starts the process and waits until the resource monitor
can communicate with the registrar.
The Resource Dictionary |
|
The resource dictionary is the mechanism by which the resource
monitor identifies itself to
EMS.
The purpose of the resource dictionary is to give a preliminary
picture of the resource structure on a given system. Its main function
is to indicate to the registrar which resource monitors should be
contacted when information is needed about a certain resource. The
resource dictionary defines resources on the local system.
Printable version
