Stream store discussion continued

The notification system is complimentary to the health reporting stack but not necessarily a substitute. This document positions the notification system component of the product as a must-have component which should work well with existing subscriber plugins. It also exists side by side with metrics publisher and subscribers.

Publisher-subscriber pattern based on observable events in a stream suits the notification system very well. Persistence of notifications also enables web-based access of notifications that can be programmed to deliver in more than one form to a customer as per the compatibility of the device owned by the customer. A stream store proves to be better suited for the messaging service so as a storage solution in can provide this service out of the box.

Classes:

Sensor Manager:

• Refreshes the list of active sensors by getting the entire set from SensorScanner.

• Creates a sensor task for each of the active sensors and cancels those for the inactive ones

SensorTask

• Retrieves sensors from persistence layer

• Persists sensor to persistence layer

• Determines the senor alert association

SensorScanner

• Maintains the sensors as per the storage container hierarchy in the storage system

• Periodically updates the sensor manager

SensorClient

• Creates/gets/updates/deletes a sensor

AlertClient

• Creates/gets/updates/deletes an alert

AlertAction

• Changes state of an alert by triggering the operation associated

NotificationList

• Creates a list of notification objects and implements the set interface

• Applies a function parameter on the data from the set of notification objects

• Applies predefined standard query operators on the data from the set of notification objects

Notification

• Data structure for holding the value corresponding to a point of time.

Unit-Test:

Evaluator evaluator = sensor.getEvaluatorRetriever().getEvaluator("alertpolicy1");        SensorStateInformation stateInformation = evaluator.evaluate(sensor, threshold);