Zukünftige Forschungsfragestellungen

Die in dieser Arbeit verfolgte Betrachtung des Managements als eine spezifische Ausprägungsform einer verteilten Anwendung hat durch die Verwendung zeitgemäßer Technologien für die objektorientierte Analyse und Design einen neuen Entwicklungsansatz für Managementagenten vorgestellt, der zu einem späteren Zeitpunkt im Rahmen der Web-based Enterprise Management (WBEM)  Initiative auf ähnliche Weise für Managementzwecke verwendet worden ist.

• Der CIM -Ansatz, unterschiedliche Architekturen in ein einheitliches Informationsmodell zu transformieren und dann jeweils wieder auf unterschiedliche Architekturen abzubilden mag zwar plausibel klingen, ist jedoch aufgrund der fundamentalen semantischen Unterschiede der Managementarchitekturen kaum praktikabel. Kapitel hat aufgezeigt, daß die Integration unterschiedlicher Managementarchitekturen alle Teilmodelle einer Managementarchitektur umfaßt und sich bei weitem nicht auf ein Compilerbauproblem reduzieren läßt, wie es CIM unterstellt: Beispielhaft seien hier die sogenannten ,,Pushbutton``-Variablen des SNMP-Managementmodells aufgeführt, aus deren syntaktischer Beschreibung nicht ersichtlich ist, daß sie bei der Überführung in ein objektorientiertes Informationsmodell zu Methoden einer Objektklasse werden müßten. Ein entsprechender Übersetzer würde daraus Attribute einer Objektklasse generieren. Hierbei ist auch das CIM ,,Scratchpad``, das semantische Unterschiede abdecken helfen soll, keine Hilfe bei der automatischen Transformation. Ferner bleiben dabei die Spezifika einzelner Managementarchitekturen (wie das OSI Scoping und Filtering) sowie die architekturspezifischen Mechanismen zur Ereignisfilterung und -propagierung vollständig unbeachtet.
• Die formale Überführung von Behaviour-Definitionen ist auch weiterhin als ungelöstes Problem anzusehen, da diese bisher lediglich in informeller Weise spezifiziert werden. Hier könnten gegenwärtige Aktivitäten der ISO helfen, die darauf abzielen, Behaviour-Definitionen in einer formalen Notation (Z) zu definieren. Alternative Ansätze wie die Einbeziehung von KI-Sprachen (wie z.B. Prolog) wären ebenfalls eine Alternative.
• Ein weiterer Punkt, der im Rahmen unserer Arbeit in Ermangelung entsprechender generischer Dienste lediglich durch die Abstützung auf proprietäre Merkmale der von uns verwendeten CORBA-Entwicklungsumgebungen erreicht werden konnte, ist die dynamische Erweiterbarkeit von Management-Gateways . Um neue Ressourcenklassen zur Laufzeit den Gateways und somit auch dem Umbrella Management verfügbar zu machen, müssen jeweils

  1.

  neue, für diese Ressourcen zuständige Gateways erzeugt werden. Dies besteht aus der MIB-Übersetzung und einer anschließenden Neucompilierung des Gateways, was die Anwendbarkeit dieses Verfahrens in der Umgebung von Netzbetreibern signifikant einschränkt, da hierfür ein vollständiges Entwicklungssystem beim Anwender vorhanden sein muß.

  2.

  Eine Alternative dazu besteht darin, diese Gateways zur Laufzeit um neue Managementinformationen erweitern zu können.

  Die bisher allgemein verfügbaren Lösungen implizieren die erste Alternative, d.h. das Vorhandensein statischer Gateways. Wünschenswert ist jedoch die zweite Alternative, nämlich dynamische Gateways, die neben den oben genannten Vorteilen insbesondere durch folgende Aspekte begründet sind. Häufig sind die Objektmodelle von Managementagenten Modifikationen unterworfen: Datentypen von Attributen eines Agenten können geändert bzw. neue Ressourcen einem System hinzugefügt werden. Ein Management-Gateway steht dann vor dem Problem, mit Managementobjekten kommunizieren zu müssen, deren Typen zu seiner Übersetzungszeit unbekannt waren. Es ist daher notwendig, Informationen bereitzustellen, welche die Typen der Managementojekte beschreiben. Ein Management-Gateway kann dann zur Laufzeit ermitteln, über welche Datentypen Managementagenten verfügen. Solche Metainformation  wird von sog. Typagenten angeboten, die in der neuesten Version des TMN/C++ API durch die Metadata Services realisiert werden. Diese standen uns jedoch bei der Implementierung unseres CMIP/SNMP Gateways nicht zur Verfügung. Das CORBA-Analogon hierzu besteht im Meta-Object Service, der sich jedoch ebenfalls noch in der Standardisierungsphase befindet.

• Die dynamische Erweiterbarkeit von Managementagenten um neue Funktionalität konnte von uns in Ermangelung geeigneter Entwicklungswerkzeuge nicht abschließend prototypisch implementiert werden. Unsere Erfahrungen mit der OMG Mobile Agents Facility Interoperability Spezifikation haben jedoch aufgezeigt, daß diese ein praktikabler Lösungsweg ist. Ferner bietet das Java Dynamic Management Kit (JDMK) in seiner neuesten Version ebenfalls die Möglichkeit, bestehende Systeme zur Laufzeit um neue Managementfunktionalität zu ergänzen.
• Kombiniert man die im vorigen Punkt angesprochenen Technologien zur dynamischen Delegierung von Managementdiensten mit dem Pull-Modell, so erreicht man damit eine Erweiterung bisheriger Agenten zu selbststeuernden Systemen , die autonom in Abhängigkeit des Auftretens von Fehlersituationen entscheiden, welche Art von Managementdiensten zur Problemdiagnose und -behebung erforderlich sind. Man erreicht so ein vollständig dezentrales Management, das eine spürbare Verbesserung hinsichtlich der Skalierbarkeit des Managements mit sich bringt.

Diese Gesichtspunkte sind in zukünftige Überlegungen einzubeziehen, die darauf abzielen, die in dieser Arbeit entwickelten Konzepte fortzuführen.