Alternative 1: Kopplung des ORBs an das XMP-API

Eine Forderung, die an die Kommunikationskomponente von Managementsystemen gestellt wird, besteht darin, eine protokollunabhängige Programmierschnittstelle für den Zugriff auf Managementobjekte zur Verfügung zu stellen. Ein typischer Vertreter dieses Gedankens ist XMP/XOM (X/Open Management Protocol  [#!xopen92a!#], X/Open OSI-Abstract-Data Manipulation API  [#!xopen91!#]), 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ß: In Abhängigkeit des verwendeten Protokolls müssen zur Generierung der PDUs unterschiedliche Parameter in die XMP-Funktionsaufrufe eingesetzt werden. Letztere werden mit XOM erzeugt, einem API für die Repräsentation von ASN.1-Datentypen in C (siehe auch [#!poch96!#]).

 

Abbildung: XOM/XMP-basierte Integration des ORBs in ein Managementsystem

Die Integration des ORBs mit dem XMP-API müßte folgende Schritte beinhalten:

• Das XMP/XOM-API wird verwendet, um Methoden auf CORBA-Objekten aufzurufen. Dazu sind ein CORBA-Management-Service-Package und diverse Management-Content-Packages nötig, die nach XOM konvertierte IDL-Datentypen beinhalten. Die Management-Content-Packages könnten durch einen Compiler generiert werden, der eine IDL-XOM-Sprachabbildung durchführt. Ein solcher Compiler existiert jedoch bisher nicht und müßte erst entwickelt werden.
• Der Postmaster-Dämon wandelt die für CORBA-Objekte bestimmten XMP-Funktionsaufrufe in CORBA-Methodenaufrufe um. Hierfür ist es sinnvoll, die dynamische Aufrufschnittstelle (DII) zu verwenden, weil sonst für jede Objektklasse ein eigener Client Stub benötigt wird, was bei der großen Menge von Managementobjekten zu Leistungseinbußen führen würde.
• Die ORS-Datenbank kann verwendet werden, um Adressierungsinformation für CORBA-Objekte zur Verfügung zu stellen. Da die ,,Adresse`` eines Objekts durch seine Referenz dargestellt wird, ist hier eine Abbildung zwischen Objektreferenzen und benutzerfreundlichen Namen denkbar. Eine solche Funktionalität wird durch den CORBA Naming Service geboten.

Folgende Argumente sprechen gegen diesen Lösungsansatz:

• Die Entwicklung von Managementanwendungen mit XMP/XOM ist kompliziert und umständlich, da zahlreiche Parameter der ausgesprochen umfangreichen Funktionssignaturen lediglich für CMIP relevant sind und somit für andere Architekturen mit leeren Wertebelegungen aufgefüllt werden müssen, was jedoch recht unübersichtlich ist. Aus diesem Grund wird das API auch für die Kommunikation mit SNMP-Agenten in der Praxis nicht verwendet; vielmehr wird hierfür ein eigenständiges, einfaches SNMP-API genutzt. Der Vorteil, den XMP/XOM bietet - ein gewisses Maß an Transparenz - kann den Nachteil der komplizierten Anwendungsentwicklung nicht ausgleichen. XMP hatte seine Existenzberechtigung bis vor kurzem dadurch, daß es das einzige standardisierte API für CMIP war. Mit der Standardisierung des TMN/C++ APIs ([#!cmisapi!#], [#!ccsh97!#]) entfällt nunmehr diese Notwendigkeit. In neuesten Plattformimplementierungen (z.B. IBM NetView TMN Support Facility Version 3 vom Herbst 1998) ist XMP/XOM nicht mehr enthalten. Dies hat auch nachträglich unsere Entscheidung bestätigt, XMP/XOM nicht zur Integration des ORB in die Kommunikationsinfrastruktur der Plattform zu verwenden.
• Der Empfang und die Weiterleitung von CORBA-Ereignismeldungen durch den Postmaster-Dämon (pmd) ist, wenn überhaupt, nur schwer realisierbar. Im Gegensatz zu SNMP-Traps und CMIP-Notifications ist eine CORBA-Ereignismeldung kein Protokollelement mit definierter PDU-Struktur, sondern ein beliebiger Methodenaufruf auf einem Consumer-Objekt. Hieraus folgt, daß der Code des Postmasters jedesmal erweitert werden müßte, wenn neue Ereignismeldungen definiert werden. Da sich die Arten von Ereignismeldungen zwischen Ressourcenklassen stark unterscheiden, kommt dies in der Regel häufig vor.
• Die gesamte Integration kann nur durch Erweiterung des Quellcodes von NetView vorgenommen werden, was bei einem kommerziellen Produkt natürlich illusorisch ist. Es müßten zumindest folgende Programmteile erweitert werden:
  • Der Postmaster, um XMP-Funktionsaufrufe in CORBA-Methodenaufrufe umzuwandeln und um CORBA-Ereignismeldungen zu empfangen und diese an den Filterprozeß weiterzuleiten.
  • Die Komponente zur Filterung von Ereignissen, um CORBA-Ereignismeldungen empfangen und verarbeiten zu können. Dies gestaltet sich insofern schwierig, als diese, wie bereits oben ausgeführt wurde, kein festes vordefiniertes Format haben.
  • Der Log-Manager, um CORBA-Ereignismeldungen persistent speichern zu können.
  • Die Zugriffsmechanismen des Postmasters auf die ORS-Datenbank, um sie für die Adressierung von CORBA-Objekten verwenden zu können.

Ferner impliziert die Belegung der XMP-Funktionsaufrufe mit entsprechenden Aufrufparametern, daß ein Managementsystem zu jedem Agenten wissen muß, mit welchem Managementprotokoll auf dessen Informationen zugegriffen werden kann. Die hierfür in der Praxis angewandte Lösung besteht darin, bereits an oberster Stelle der Topologiehierarchie zwischen den Protokollwelten zu unterscheiden.

Diese gravierenden Einschränkungen disqualifizieren den XOM/XMP-basierten Integrationsansatz für eine universell und flexibel anwendbare Lösung.