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:
Client to registrar communication,
which puts clients in contact with the appropriate monitor for discovery
and registering monitor requests.
Registrar to monitor communication,
which passes client requests to the appropriate monitor.
Comparison between the current resource values and
pre-selected threshold values.
Monitoring of 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 example, 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” illustrates how
connections are made between clients and registrars.
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
