Multiarchitektureller Agent

      Wir werden nun die zweite der drei Alternativen zur Kooperation von Managementarchitekturen vorstellen, die auf der Verwendung multiarchitektureller Agenten basiert.

Bevor wir den Nutzen und die Anwendbarkeit dieses Integrationsansatzes untersuchen, müssen wir zunächst diesen Begriff gegenüber einem auf den ersten Blick damit verwandten Konzept abgrenzen, nämlich dem des Proxy-Agenten .

  

Abbildung: Multiarchitektureller Agent vs. Proxy-Agent

Die grundlegenden Architekturkonzepte von Managementagenten haben wir in Abschnitt vorgestellt: Die Instrumentierung von Ressourcen erfolgt generell in Form sog. Ressourcen-Module, deren Schnittstellen in einer gewöhnlichen Programmiersprache (zumeist C oder C++) vorliegen. Die Managementinstrumentierung dieser Ressourcen-Module erfolgt durch Protokoll-Module, die einerseits eine Instanz der Protokollmaschine enthalten, andererseits die MIB-Struktur der administrierten Ressourcen verwalten, um die korrekte Adressierung der Managementinformation zu gewährleisten. Die Schnittstelle zwischen Ressourcen- und Protokoll-Modulen haben wir als Intra-Agenten-Schnittstelle bezeichnet. Ein multiarchitektureller Agent verfügt über mehrere Protokoll-Module zu jeweils einem Ressourcen-Modul, d.h. es erfolgt stets eine Abbildung an der Intra-Agenten-Schnittstelle . Grundsätzlich wird dabei immer die interne (proprietäre) Instrumentierung auf eine offene Managementarchitektur abgebildet.

  

Abbildung: Multiarchitektureller CORBA- und SNMP-Agent

Demgegenüber besteht die Aufgabe eines Proxy-Agenten darin, einen eigenständigen, d.h. bereits mit einem (ggf. offengelegten) Protokoll-Modul  versehenen Agenten in einen fremden Managementkontext einzubinden. Der Agent kommuniziert demzufolge mit dem Proxy-Agenten über eine Inter-Agenten-Schnittstelle (siehe auch Abbildung ). Im Gegensatz zum multiarchitekturellen Agenten kann ein Proxy-Agent insofern als Spezialfall eines Management-Gateways angesehen sehen, als ein Proxy-Agent jeweils in einer 1:1-Beziehung mit dem zu integrierenden Agenten steht; beim Gateway ist dies jedoch üblicherweise eine 1:n-Beziehung.

Die praktische Durchführbarkeit des Integrationsansatzes auf der Basis multiarchitektureller Agenten hängt maßgeblich von der Art der Ressourcen ab: Offensichtlich besteht bei preiswerten Netzkomponenten, in denen sich der vollständige Agent bereits in der Firmware des Gerätes befindet, keinerlei Möglichkeit, eine unserer Definition des multiarchitekturellen Agenten genügende Integration vorzunehmen. Bessere Chancen für diesen Ansatz bestehen dagegen bei Ressourcenklassen, die (System-)Dienste oder Softwarekomponenten darstellen. Hier kann die jeweilige Programmierschnittstelle als Vereinigungsmenge der Ressourcenmodule aufgefaßt werden, auf die die entsprechende Managementinstrumentierung aufgesetzt werden kann. Als charakteristische Beispiele für derartige Managementinstrumentierungen gelten die in Abschnitt vorgestellten Host Resources bzw. Application MIBs der IETF, welche die benötigte Managementinformation zum Teil anhand von Betriebssystemaufrufen ermitteln.

Die besten Realisierungsmöglichkeiten für eine effiziente Managementinstrumentierung sind naturgemäß dann gegeben, wenn die Ressourcen-Module im Quelltext vorliegen, was jedoch nur in den seltensten Fällen gegeben ist. Der Integrationsansatz des multiarchitekturellen Agenten bietet sich daher insbesondere für die Hersteller von Systemen bzw. Anwendungen an, die so auf einer gegebenen Instrumentierung parallel mehrere Managementarchitekturen unterstützen. Abbildung stellt dies graphisch dar.

Für das von uns betrachtete Anwendungsszenario geht es nun darum, bestehende SNMP-Agenten unter den folgenden Randbedingungen um eine CORBA-konforme Zugriffsmöglichkeit zu erweitern: Es ist wünschenswert, daß die Vorgaben an die Managementinstrumentierung hinsichtlich der bereits unterstützten Architektur auch für das Design der neu zu unterstützenden Managementarchitektur möglichst umfassend übernommen werden können. Dies würde eine signifikante Vereinfachung für die Entwicklung der neuen Managementinstrumentierung bedeuten, da man so bereits auf einer Grundmenge an Managementinformation aufsetzen könnte. Idealerweise sollte das Verfahren zur Transformation der Managementinstrumentierung offengelegt (d.h. standardisiert) und auf möglichst alle Ressourcenklassen universell anwendbar sein (d.h. es sollte effektiv sein). Ferner sollte die Spezifizität einer Managementarchitektur in bezug auf ihre Leistungscharakteristika zum Tragen kommen, wie zum Beispiel besonders performante Abfragemechanismen oder ein übersichtliches Design (d.h. das Verfahren zur Abbildung sollte zusätzlich effizient sein).

Im Grunde genommen geht es also hier um die Frage der allgemeingültigen Abbildbarkeit von Management-Informationsmodellen, da in ihnen die Struktur der Managementinstrumentierung festgeschrieben wird. Wir werden im nächsten Abschnitt im Rahmen der Management-Gateways demonstrieren, daß solche generischen Abbildungsvorschriften existieren, die eine effektive Umsetzung der Management-Informationsmodelle leisten. Andererseits werden wir auch feststellen, daß diese Umsetzung oft nicht effizient ist, da die bereits in Kapitel analysierten Unterschiede zwischen den Management-Informationsmodellen tiefgreifend sind. Um trotz der vorhandenen Unterschiede eine effiziente Transformation zwischen unterschiedlichen Informationsmodellen vornehmen zu können, haben wir im Zuge unserer Untersuchungen ein Verfahren entwickelt, das dies leistet. Wir werden es in Abschnitt vorstellen.