--- projects/cms/documentation/specification/spec-realtime.txt 2000/10/30 21:45:33 1.3 +++ projects/cms/documentation/specification/spec-realtime.txt 2000/10/31 16:12:25 1.4 @@ -9,17 +9,36 @@ System Component Startup CORE ---- +The core of the system provides little or no functionality +to the operation of the system, but instead oversees the +running. At startup this should be the first component to +intansiate. It essentially acts as a central logging and +configuration distrubution site, the "central" in +centralised monitoring system. It may also be running the +ORB or some components related to it. +On startup the first thing it should do is read in any +configuration files, start the logging interface then +prepare to bring the system online. This is done by +starting the various components. If however the system +configuration states that particular components are +operating in "distributed" mode, then it blocks until +the various key components have registered that they are +online. Client Interface ---------------- The Client Interface is essentially just one component with a series of lists within it. When run it should, obviously, create an instance of the Client Interface, and then bind -this to the ORB and register with the naming service. It -then needs to construct the "local clients". These clients -communicate with the system using the same interface as the -external clients, but they are tailored to specific +this to the ORB and register with the naming service. + +It can then read its configuration in from the CORE and get +a hook on the logging service that the CORE provides. + +It then needs to construct the "local clients". These +clients communicate with the system using the same interface +as the external clients, but they are tailored to specific purposes, such as E-Mail alerts, and SMS alerts. The Client Interface then listens on a "well known" address for clients to request a connection. @@ -53,19 +72,26 @@ known" location (probably a given machine name at a predefined port). The Filter Manager will create an instance of the Main Filter, and any Filters under it's control. It should also bind itself to the ORB and register with the -naming service. Through some mechanism the other Filters, -elsewhere on the network, will register with the Filter -Manager. The Filter Manager will need to tell each Filter -the location of the Main Filter upon registering. The Filter -Manager will then be in a position to receive connections -from hosts and pass them off to Filters. +naming service. +It can then read its configuration in from the CORE and get +a hook on the logging service that the CORE provides. + +Through some mechanism the other Filters, elsewhere on the +network, will register with the Filter Manager. The Filter +Manager will need to tell each Filter the location of the +Main Filter upon registering. The Filter Manager will then +be in a position to receive connections from hosts and pass +them off to Filters. + System Running State ******************** CORE ---- - +Once the various components are running then the core is +essentially idle, logging information and handling +configuration changes. Client Interface ----------------