| 9 |
|
|
| 10 |
|
CORE |
| 11 |
|
---- |
| 12 |
+ |
The core of the system provides little or no functionality |
| 13 |
+ |
to the operation of the system, but instead oversees the |
| 14 |
+ |
running. At startup this should be the first component to |
| 15 |
+ |
intansiate. It essentially acts as a central logging and |
| 16 |
+ |
configuration distrubution site, the "central" in |
| 17 |
+ |
centralised monitoring system. It may also be running the |
| 18 |
+ |
ORB or some components related to it. |
| 19 |
|
|
| 20 |
+ |
On startup the first thing it should do is read in any |
| 21 |
+ |
configuration files, start the logging interface then |
| 22 |
+ |
prepare to bring the system online. This is done by |
| 23 |
+ |
starting the various components. If however the system |
| 24 |
+ |
configuration states that particular components are |
| 25 |
+ |
operating in "distributed" mode, then it blocks until |
| 26 |
+ |
the various key components have registered that they are |
| 27 |
+ |
online. |
| 28 |
|
|
| 29 |
|
Client Interface |
| 30 |
|
---------------- |
| 31 |
|
The Client Interface is essentially just one component with |
| 32 |
|
a series of lists within it. When run it should, obviously, |
| 33 |
|
create an instance of the Client Interface, and then bind |
| 34 |
< |
this to the ORB and register with the naming service. It |
| 35 |
< |
then needs to construct the "local clients". These clients |
| 36 |
< |
communicate with the system using the same interface as the |
| 37 |
< |
external clients, but they are tailored to specific |
| 34 |
> |
this to the ORB and register with the naming service. |
| 35 |
> |
|
| 36 |
> |
It can then read its configuration in from the CORE and get |
| 37 |
> |
a hook on the logging service that the CORE provides. |
| 38 |
> |
|
| 39 |
> |
It then needs to construct the "local clients". These |
| 40 |
> |
clients communicate with the system using the same interface |
| 41 |
> |
as the external clients, but they are tailored to specific |
| 42 |
|
purposes, such as E-Mail alerts, and SMS alerts. The Client |
| 43 |
|
Interface then listens on a "well known" address for clients |
| 44 |
|
to request a connection. |
| 72 |
|
predefined port). The Filter Manager will create an instance |
| 73 |
|
of the Main Filter, and any Filters under it's control. It |
| 74 |
|
should also bind itself to the ORB and register with the |
| 75 |
< |
naming service. Through some mechanism the other Filters, |
| 57 |
< |
elsewhere on the network, will register with the Filter |
| 58 |
< |
Manager. The Filter Manager will need to tell each Filter |
| 59 |
< |
the location of the Main Filter upon registering. The Filter |
| 60 |
< |
Manager will then be in a position to receive connections |
| 61 |
< |
from hosts and pass them off to Filters. |
| 75 |
> |
naming service. |
| 76 |
|
|
| 77 |
+ |
It can then read its configuration in from the CORE and get |
| 78 |
+ |
a hook on the logging service that the CORE provides. |
| 79 |
+ |
|
| 80 |
+ |
Through some mechanism the other Filters, elsewhere on the |
| 81 |
+ |
network, will register with the Filter Manager. The Filter |
| 82 |
+ |
Manager will need to tell each Filter the location of the |
| 83 |
+ |
Main Filter upon registering. The Filter Manager will then |
| 84 |
+ |
be in a position to receive connections from hosts and pass |
| 85 |
+ |
them off to Filters. |
| 86 |
+ |
|
| 87 |
|
System Running State |
| 88 |
|
******************** |
| 89 |
|
|
| 90 |
|
CORE |
| 91 |
|
---- |
| 92 |
< |
|
| 92 |
> |
Once the various components are running then the core is |
| 93 |
> |
essentially idle, logging information and handling |
| 94 |
> |
configuration changes. |
| 95 |
|
|
| 96 |
|
Client Interface |
| 97 |
|
---------------- |
