3.2.4 Die Funktionsweise des Agenten  

Wie schon mehrmals in diesem Kapitel erwähnt, stellen die Komponenten, aus denen sich die Agentenarchitektur zusammensetzt, auf der einen Seite schon eine Vielzahl von Funktionen bereit, auf der anderen Seite muß der Entwickler aber den Code implementieren, der schließlich für den Zugriff auf die zu überwachende und zu steuernde Ressource verantwortlich ist. In diesem Abschnitt soll dargestellt werden, wie die verschiedenen Komponenten miteinander kooperieren, um die Gesamtfunktionalität eines TMN- bzw. OSI-Agenten zu ermöglichen.
Der Start eines Agenten mit dem Befehl zStart bewirkt, daß alle für den Agenten notwendigen Prozesse (Infratop, Agent, Logr und Discr) in den Speicher geladen werden. Die Containment-Hierarchie in der Naming and Replication-Komponente, also im Infratop, ist noch leer. Ebenso existieren im Agent-Prozeß noch keine Instanzen von Managementobjekt-Klassen. Der Agent kann nun automatisch ,,bevölkert`` werden, das heißt, alle zum Betrieb des Agenten notwendigen Instanzen von Managementobjekt-Klassen können kreiert werden.
Das Kreieren einer Instanz einer Managementobjekt-Klasse bewirkt folgendes:

1.

Die Naming and Replication-Komponente überprüft, ob diese angegebene Instanz mit diesem Relative Distinguished Name in Bezug auf die existierenden NAME BINDINGs kreiert werden kann.

2.

Sobald Punkt 1 erfüllt ist, wird die Instanz im spezifischen Agententeil des Agenten kreiert und sowohl im Core Agent (für eine spätere Lokalisierung im spezifischen Agententeil) als auch in der Containment-Hierarchie (für die Auflösung von Scopes und die Überprüfung von NAME BINDINGs) im Infratop registriert.

Erst nachdem diese neue Instanz in beiden Komponenten (Core Agent und Naming and Replication) registriert ist, kann sie ihre Managementaufgabe erfüllen, das heißt, eine reale Ressource repräsentieren. Damit kann nun ein OSI-Manager beliebige CMIS-Anforderungen auf dieser Instanz auslösen. Falls in einer CMIS-Anforderung eine Instanz spezifiziert ist, die nicht im spezifischen Agententeil existiert und damit nicht im Core Agent und in der Containment-Hierarchie registiert ist, wird eine noSuchInstance-Fehlermeldung erzeugt.

Das Kreieren von Instanzen kann dabei auf zwei verschiedene Arten ausgelöst werden:

1.

Eine darunterliegende (zu repräsentierende) Ressource löst das Kreieren einer Instanz aus (createFromResource), oder

2.

die Instanz wird mittels eines CMIS M-CREATE-Requests erstellt.

Der Unterschied zwischen den beiden Möglichkeiten besteht darin, daß die Auslöser verschieden sind: Im ersten Fall ist eine darunterliegende Ressource, also ein Teil des Agenten selbst, im zweiten Fall irgendein OSI-Manager für das Auslösen des Kreierens einer Instanz einer Managementobjekt-Klasse verantwortlich. Da das ,,Bevölkern`` des Agenten automatisch und somit vom Agenten selbst ausgelöst wird, handelt es sich um ein createFromResource.
Die Bearbeitung des CMIS-M-CREATE-Requests stellt keine besonderen Anforderungen, außer natürlich dem schon erwähnten Kreieren der neuen Instanz im spezifischen Agententeil und dem anschließenden Registrieren im Core Agent und in der Containment-Hierarchie im Infratop. Zu der Bearbeitung eines createFromResource sollen aber noch einige Bemerkungen erfolgen:
Ein createFromResource kann definitionsgemäß nur vom Agenten selbst aufgerufen werden. Die Instanzen im spezifischen Agententeil des Agenten repräsentieren die zu überwachende, darunterliegende, reale Ressource. Sobald Veränderungen in der realen Ressource stattfinden, müssen auch dementsprechende Veränderungen im spezifischen Agententeil des Agenten erfolgen. Folgendes Beispiel soll die Situation verdeutlichen:
Ein Agent soll die Prozeßliste einer UNIX-Workstation überwachen und steuern. Dazu wird jeder existierende Prozeß von einer eigenen Instanz repräsentiert. Sobald ein neuer Prozeß entsteht, muß eine neue Instanz kreiert werden. Ebenso muß für jeden terminierten Prozeß die entsprechende Instanz gelöscht werden.
Der Agent ist also selbst dafür verantwortlich, seinen spezifischen Agententeil und damit auch die Containment-Hierarchie im Infratop, durch entsprechendes Kreieren (createFromResource) bzw. Löschen (deleteFromResource) von Instanzen von Managementobjekten konsistent mit der durch diese Instanzen repräsentierten, realen Ressource zu halten. Das heißt, sobald eine durch eine Instanz repräsentierte Ressource terminiert, muß auch die entsprechende Instanz gelöscht werden. Ebenso muß für eine neu entstandene Ressource auch eine, diese repräsentierende, Instanz kreiert werden. Diese Eigenschaft stellt bei der späteren Vorstellung der Architektur des CMIP/SNMP Gateways eine Restriktion dar (siehe Kapitel 5).

Nachdem eine Instanz auf eine der beiden gerade vorgestellten Möglichkeiten im spezifischen Agententeil des Agenten kreiert und damit in dem Core Agent und in der Containment-Hierarchie registriert wurde, kann ein OSI-Manager mit Hilfe von CMIS-Requests die reale Ressource, die diese Instanz repräsentiert, überwachen und steuern. Die Abbildung 3.8 zeigt ein Beispiel einer Bearbeitung eines gescopten und gefilterten CMIS-M-GET-Requests (1).

 

Abbildung:   Der Ablauf einer Bearbeitung eines gescopten und gefilterten CMIS-M-GET-Requests

26#26

Dieser CMIS-M-GET-Requests, wird von der im Infratop enthaltenen Infrastruktur vom OSI-Manager entgegengenommen und zur Naming and Replication-Komponente weitergeleitet (2). Dort werden die in diesem Request angesprochenen Instanzen (Scope) ermittelt (3). Falls die angesprochene Base Managed Object Instance (BMOC) nicht in der Containment-Hierarchie existiert, wird eine noSuchInstance-Fehlermeldung zum OSI-Manager zurückgeschickt (4). Andernfalls erhält jede angesprochende Instanz eine ,, Kopie`` (Replication) des originalen Requests. Dazu werden diese Kopien von der Naming and Replication-Komponente an den Core Agent übergeben (5). Dieser kann, anhand der in der Kopie angesprochenen Instanz, diese im spezifischen Agententeil lokalisieren (6) und die Bearbeitung des Requests im spezifischen Agententeil auslösen (7). Anschließend werden eventuelle Ergebnisse zu ,,linked Replies`` zusammengefaßt (8) und über die Infrastruktur (9) zum OSI-Manager zurückgeschickt.