Fazit: Eignung multiarchitektureller Manager

   

Die beiden in Abschnitt beschriebenen Alternativen der Anbindung eines ORBs an eine Managementplattform haben durch die Heterogenität der Informationsmodelle die Einschränkung, daß auf Managementobjekten einer Protokolldomäne nur diejenigen Funktionen anwendbar sind, die das entsprechende Protokoll erlaubt; Scoping und Filtering, essentieller Bestandteil des OSI-Modells, kann weder für das Management von SNMP- noch von CORBA-Ressourcen verwendet werden. Ein anderer Aspekt, der aufzeigt, daß dieser Integrationsansatz niemals nahtlos sein kann, ist die Tatsache, daß zahlreiche Werkzeuge und Applikationen, die mit der Plattform mitgeliefert werden, explizit auf eine bestimmte Architektur zugeschnitten sind: Ein MIB-Browser, der auf SNMP zugeschnitten ist, kann nicht die Attributwerte von CORBA- oder OSI-konformen MOs anzeigen. Die Möglichkeit, jeweils auf andere Architekturen zugeschnittene Werkzeuge mit ähnlichem Funktionsumfang in die Plattformoberfläche zu integrieren, kann dabei nicht über den Verlust an Transparenz hinwegtäuschen. Es sei an dieser Stelle nochmals erwähnt, daß die Ausführungen, die sich hier am konkreten Produkt NetView orientieren, prototypischer Art für diese Klasse von Integration ist und folglich keine Unzulänglichkeiten des von uns gewählten Produkts sind.

  

Abbildung: Root-Fenster der multiarchitekturellen Plattform IBM NetView

Ein weiterer prinzipieller Gesichtspunkt, der die Problematik dieses Integrationsansatzes für offenes integriertes Enterprise Management verdeutlicht, besteht darin, daß auch im Falle einer geglückten Integration bereits auf oberster Ebene der Topologiehierarchie zwischen den zugrundeliegenden Managementarchitekturen unterschieden wird: Man findet, wie es in Abbildung dargestellt ist, für jede Architektur (OSI/TMN, SNMP, CORBA) mindestens ein Symbol, unter dem dann die Ressourcen zu finden sind, die über diese Architektur verwaltet werden können. Genau dies sollte eigentlich verhindert werden, da man dem Betreiber die Anordnung MOs gemäß seiner Betriebsziele (d.h. nach organisatorischen oder geographischen Kriterien) ermöglichen möchte. Das Problem des Fortlebens unterschiedlicher Architekturen unter einer gemeinsamen Oberfläche bleibt bei diesem Integrationsansatz bestehen.

Wie bereits in Abschnitt eingehend begründet wurde, ist ein weiteres Problem bei der Implementierung multiarchitektureller Plattformen - nämlich die Abhängigkeit von bestehenden Plattformimplementierungen - inhärent mit diesem Integrationsansatz verbunden: Die Nutzung dieser produktspezifischen und nicht standardisierten Funktionen ist daher häufig nicht nur von Produkten abhängig, sondern auch in hohem Maße von Modifikationen dieser APIs durch den Hersteller.

Nichtsdestoweniger haben wir mit unserer Integration die Basis geschaffen, um trotz des gegenwärtigen Nichtvorhandenseins offener CORBA-Plattformen eine solche zu realisieren. Somit sind wir in der Lage, für die in Kapitel vorgestellten Agenten eine CORBA-Managementumgebung zu schaffen. Gleichzeitig können wir die Vielfalt an bereits vorhandenen Plattformdiensten als einen temporären Ersatz für in der Standardisierung befindliche CORBA-Dienste ansehen und zur Lösung unseres Integrationsproblems einsetzen.