Erweiterung von IBM TME 10 NetView zu einer multiarchitekturellen Plattform

Sollen Plattformen als Basis für die Integration unterschiedlicher Managementarchitekturen verwendet werden, ist es naheliegend, unmittelbar an der Kommunikationsschnittstelle der Plattform anzusetzen, um so die Heterogenität verschiedener Managementprotokolle so weit ,,unten`` wie möglich abzuhandeln. Ein typischer Vertreter dieses Gedankens ist XMP/XOM (X/Open Management Protocol, X/Open OSI-Abstract-Data Manipulation), dessen Zielsetzung darin besteht, eine einheitliche Programmierschnittstelle für die Managementprotokolle CMIP und SNMP bzw. die Darstellung von ASN.1-Datentypen in C bereitzustellen, um einheitliches Management unabhängig von der verwendeten Managementarchitektur zu erlauben. Dieser Versuch der Vereinheitlichung muß jedoch aus heutiger Sicht als gescheitert betrachtet werden, da sich die Heterogenität der Managementprotokolle nicht verbergen ließ. Das sehr komplexe XMP wird daher in heutigen Produkten (wie zum Beispiel der IBM NetView TMN Support Facility, einem auf NetView basierenden OSI-Managementsystem) ausschließlich als CMIP-API eingesetzt; SNMP-konforme Ressourcen werden in bestehenden Produkten über ein separates einfaches SNMP-API angesteuert.

Wir haben uns für unsere Implementierung aus folgenden Gründen gegen eine auf XMP/XOM basierende Lösung entschieden:

• Der XMP-Stack wird bei NetView durch den sog. Postmaster-Dämon verwaltet. Eine CORBA-Ereignismeldung ist, im Gegensatz zu SNMP oder CMIP, keine Protokolldateneinheit mit festgelegter Struktur, sondern ein beliebiger Methodenaufruf auf einem Consumer-Objekt. Im vorliegenden Falle würde der Postmaster in der Rolle des Consumers (s.u.) agieren; es folgt, daß er um jede neu eingeführte Ereignismeldung erweitert werden müßte. Aufgrund des zu erwartenden Aufwands ist dies nicht praktikabel, da eine solche Erweiterung beim Einbringen jeder neuen CORBA-Ressource erfolgen müßte.
• Um solche Erweiterungen vornehmen zu können, hätte der Quellcode des Postmaster-Dämons und einiger anderer NetView-Komponenten vorliegen müssen; diese Forderung ist bei kommerziellen Produkten natürlich illusorisch.

Eine Alternative zu XMP ist der unmittelbare Zugriff auf die plattformspezifischen Infrastrukturdienste, wie z.B. Topologiedatenbank, Ereignisfilter oder Ressourcenverwaltung; jede dieser Komponenten verfügt über ein eigenes API. Die Nutzung dieser produktspezifischen und nicht standardisierten Funktionen impliziert allerdings den Verlust der Unabhängigkeit von bestehenden Plattformimplementierungen: die Lösung ist damit nur unter vermutlich hohem Aufwand auf andere Plattformen zu portieren. Die oben beschriebenen Argumente ließen jedoch keine andere Wahl zu.

Beide Alternativen haben durch die Heterogenität der Informationsmodelle die Einschränkung, daß auf Managementobjekten einer Protokolldomäne nur die durch das entsprechende Protokoll erlaubten Funktionen anwendbar sind; Scoping und Filtering, essentieller Bestandteil des OSI-Modells, kann nicht für das Management von SNMP-Ressourcen verwendet werden (vergleiche dazu Abschnitt 4.3). Auf multiarchitekturellen Plattformen wird daher bereits an oberster Stelle der Topologiehierarchie zwischen beiden Protokollwelten unterschieden. Das in der Einleitung beschriebene Problem des Fortlebens unterschiedlicher Architekturen unter einer gemeinsamen Oberfläche bleibt bei diesem Integrationsansatz bestehen (siehe auch [9]).

Der Schwerpunkt des Integrationskonzeptes liegt auf einem möglichst hohen Verfügbarkeitsgrad von Infrastruktur-Diensten, wie sie in Abschnitt 2.5 beschrieben wurden. Dies kann auf zweierlei Arten geschehen:

• Falls die Dienste der einen Architektur keine Entsprechung in der anderen betrachteten Architektur haben, kann man (siehe Abschnitt 2.6) durch die Überführung der Beschreibungen dieser Dienste in das entsprechende Informationsmodell die Managementfunktionalität einer Architektur von einer anderen Managementarchitektur aus nutzen. Damit könnte man z.B. in der OSI-Architektur existierende Mechanismen zur Schwellwertüberwachung von CORBA-Objekten aus verwenden. Dieser Weg hin zu Interoperabilität von Infrastruktur-Diensten wird in Abschnitt 4 ausführlicher beschrieben. Es sei hier nur kurz erwähnt, daß die Beschreibungen der Dienstschnittstellen algorithmisch in das Informationsmodell der Zielarchitektur überführt werden müssen (vgl. Abschnitt 2.3). Dort werden Proxy-Objekte erzeugt, die die Dienstaufrufe innerhalb der einen Architektur auf die Dienstimplementierungen der anderen transparent für den Dienstnutzer weiterleiten.
• Liegen vergleichbare Infrastruktur-Dienste in beiden Architekturen vor, müssen sie aufeinander abgebildet werden. Dies gilt für die in den folgenden Abschnitten betrachteten Applikationen, die die Topologie von CORBA-Agenten ermitteln (siehe Abschnitt 3.3) bzw. die von ihnen ausgesendeten CORBA-Events auf SNMP-Traps (und umgekehrt) abbilden (siehe Abschnitt 3.2). Hierbei werden ebenfalls Infrastruktur-Dienste genutzt, die die Managementplattform bereitstellt, um die ermittelten Informationen einer CORBA-konformen Managementapplikation (siehe auch [16]) zur Weiterverarbeitung anzubieten. Die Plattform fungiert dabei als Brücke zwischen den CORBA-Agenten und einer CORBA-Managementapplikation (siehe Abbildung 2).