Next: Spezifischer Agententeil
Up: Allgemeiner Agententeil
Previous: Callback CMIS/CMIP Interface
Aufgrund der Spezifikation seiner Klasse kann es einer Instanz möglich sein,
Notifikationen (=asynchrone Mitteilungen) abzuschicken, wenn bestimmte Ereignisse
eintreten. So ist es zum Beispiel denkbar, daß eine Instanz die Notifikation
attributeValueChange generiert, sobald sich der Wert eines Attributes ändert.
Als Event werden die Meldungen bezeichnet, weche mit Hilfe des
CMIP-Protokolls übertragen werden und dabei aus bestimmten Notifikationen
entstanden sind. Es werden jedoch nicht alle von Instanzen von
Managementobjekten ausgelösten Notifikationen zu Events und damit zum Manager
geschickt. Dies könnte zu einem riesigen Kommunikationsaufkommen führen. Um
dieses Kommunikationsaufkommen (Netzlast) zu kontrollieren, werden in [ISO10164-5]
Mechanismen beschrieben, die es Managern erlauben, nur diejenigen Ereignisse zu
beschreiben, die für sie interessant sind und ihnen gemeldet werden sollen.
Damit werden nicht alle von den Managementobjekten generierten Notifikationen
zu Events, sondern nur diejenigen, die von einem Manager ausgewählt wurden
(siehe Abbildung 3.3):
Abbildung 3.3:
Aufbau der Event Report Management Funktion
21#21 |
Es existiert im Agenten mindestens ein Managementobjekt, welches
beim Auftreten bestimmter Ereignisse Notifikationen auslöst
(changeAttributeValue, objectCreation, objectDeletion, ...).
Ein lokaler Erkennungs- und Verarbeitungsmechanismus, der nicht
der Standardisierung unterworfen ist, nimmt die erzeugten
Notifikationen entgegen. Er formt danach potentielle Event-Reports.
Diesen können neben den Informationen aus den Notifikationen noch weitere
Informationen hinzugefügt werden, so zum Beispiel der Zeitpunkt des Ereignisses
oder die Objekt-Klasse bzw. die Instanz des Auslösers.
Potentielle Event-Reports werden an alle
Event-Forwarding-Discriminators (EFD), die im lokalen System
existieren, verteilt. Diese EFDs sind wiederum Managementobjekte.
Ein Diskriminator legt fest, welche Event-Reports
weitergeleitet werden sollen. Die Zielinstanzen (=Manager) werden dazu in
einer Liste gespeichert. Der Diskriminator
enthält dabei zum einen einen Filter, welcher
festlegt, aus welchen potentiellen Event-Reports schließlich
Events aufgebaut werden sollen. Andererseits enthält
ein Diskriminator einen Scheduler, der festlegt, in welchem
Intervall überhaupt potentielle Event-Reports bearbeitet werden.
Da EFDs selbst Managementobjekte sind, enthalten sie auch Attribute und
Status und können somit von einem Manager aus gesteuert und überwacht werden.
Wie andere Managementobjekte auch, können die EFDs selbst
Notifikationen generieren. Diese werden erkannt (von der lokalen
Ereignisfeststellung und -verarbeitung) und als potentielle
Event-Reports allen EFDs zur Bearbeitung übergeben, damit auch
wieder dem EFD, der diese Notifikation ursprünglich erzeugte.
Es können zwei Typen von Ereignismeldungen im Agenten auftreten:
Notifikationen und Events. Das Log-Management ist nun
dafür verantwortlich, daß diese Ereignismeldungen dauerhaft
abgespeichert werden können, siehe Abbildung 3.4.
Abbildung 3.4:
Elemente der Log Control Function
22#22 |
Ein Log [ISO10164-6] ist eine dauerhafte Ablage von Mangementinformationen,
die in Log Records organisiert werden. Diese Informationen können
entweder von empfangenen Events oder von internen
Ereignissen stammen. Die internen Ereignisse werden, wie auch bei der
Event-Report-Management Function [ISO10164-5], von Notifikationen
repräsentiert, die jeweils von Managementobjekten ausgelöst werden.
Ein lokaler Erkennungs- und Verarbeitungsmechanismus nimmt die
Notifikationen entgegen. Er formt anschließend potentielle Log
Reports und verteilt diese an alle existierenden
Log-Instanzen. Alle von den Log-Instanzen empfangenen
Reports (Event-Reports oder potentielle Log Reports) werden anhand
eines Filters überprüft, ob sie abgespeichert
werden sollen oder nicht. Bei diesem Filter
liegt der gleiche Mechanismus zugrunde, wie er schon bei der
Event-Report-Management Function beschrieben wurde.
Der Event Handler ist eine Implementierung der
eventForwardingDiscriminator-Klasse. Alle CMIS/P-Anforderungen, die den
EventForwardingDiscriminator (EFD) betreffen, werden zu dem Event Handler
geleitet und von diesem bearbeitet. EFD Instanzen werden statt im spezifischen
Agententeil in dieser
Komponente kreiert. Alle Notifikationen, egal, ob sie von Instanzen von
Managementobjekten,
vom Log Handler oder vom Event Handler generiert wurden, werden zu dieser
Komponente weitergeleitet. Hier wird anhand des EFD-eigenen Filters geprüft,
ob die Notifikation als eine CMIP-Event-Notification weitergeleitet werden
soll.
Ebenso werden alle CMIS/P-Anforderungen, die die log-Klasse betreffen, zum
Log Handler weitergeleitet. Alle Notifikatioen (von Instanzen von
Managementobjekten, von dem
Event Handler oder von dem Log Handler) werden zum Log Handler weitergeleitet.
Dort wird anhand des Log Handler-eigenen Filters überprüft, ob diese Notifikation
gespeichert werden soll oder nicht. Im dem Fall, daß die Notifikation
abgespeichert werden soll, wird eine Instanz der Klasse logRecord
generiert. Diese kann sowohl im Speicher existieren, als auch in eine Datenbank
eingetragen werden.
Next: Spezifischer Agententeil
Up: Allgemeiner Agententeil
Previous: Callback CMIS/CMIP Interface
Copyright Munich Network Management Team