Alternative Lösungsansätze

Der Object Request Broker ermöglicht den Zugriff auf alle CORBA-Objekte, die bei ihm registriert sind (die Registrierung erfolgt durch Erzeugen einer Objektreferenz). Client-Anwendungen können über die Aufrufschnittstellen des ORBs (statisch oder dynamisch - vgl. Kapitel 2) die Methoden der Objekte aufrufen.

Eine Managementanwendung (die eventuell selbst aus verteilten Objekten besteht) kann also auf jedes Managementobjekt zugreifen, wenn sie eine Referenz für dieses Objekt hat. Die möglichen Informationsquellen, um vorhandene Objektreferenzen zu ermitteln, werden in Kapitel 6 beschrieben.

Eine Anwendung, die auf CORBA-Objekte zugreifen soll, kann in jeder Programmiersprache implementiert werden, für die der verwendete ORB eine IDL-Sprachabbildung anbietet. Dabei spielt es keine Rolle, in welcher Sprache die Objekte implementiert sind.

Eine Forderung, die an die Kommunikationsschnittstelle von Managementplattformen häufig gestellt wird, ist, daß sie ein protokollunabhängiges API für den Zugriff auf Managementobjekte zur Verfügung stellen soll (vgl. z.B. [HEGE 93 S.305]). Unter diesem Gesichtspunkt wurde von X/Open das XMP-API (X/Open Management Protocols Application Program Interface) standardisiert (vgl. [X/Open 94]). XMP kann als Programmierschnittstelle für CMIP und SNMP verwendet werden. Es bietet dabei ein gewisses Maß an Transparenz bezüglich der verwendeten Managementprotokolle, da für die Protokolloperationen teilweise die gleichen Funktionsaufrufe verwendet werden können. Die Transparenz ist jedoch nur begrenzt, da je nach Protokoll unterschiedliche Parameter eingesetzt werden müssen. Die Parameter der XMP-Funktionsaufrufe werden mit XOM (X/Open OSI-Abstract-Data-Manipulation API) erzeugt, einem API für die Repräsentation von ASN.1-Datentypen in C.

Prinzipiell ist es denkbar, einen ORB direkt in die Kommunikationsinfrastruktur einer Managementplattform zu integrieren und das XMP-API als ,,protokollunabhängige`` Programmierschnittstelle für CMIP, SNMP und CORBA zu verwenden. Im folgenden wird kurz beschrieben, welche Schritte dafür nötig sind. Anschließend wird die Alternative bewertet und begründet, warum sie nicht implementiert wurde.

Die Kommunikationsinfrastruktur von NetView für AIX besteht aus folgenden Komponenten (vgl. Kapitel 3):

• Der Postmaster-Dämon enthält einen SNMP- und einen CMOT-Stack und vermittelt die PDUs zwischen den Managementanwendungen und den Agenten.
• Die ORS-Datenbank (Object Registration Services) ist ein Verzeichnis von bekannten Agenten und den von ihnen verwalteten OSI-Managementobjekten.

Die Integration des ORBs unter das XMP-API müßte folgende Schritte beinhalten:

• Das XMP/XOM-API wird verwendet, um Methoden auf CORBA-Objekten aufzurufen. Dazu sind eine CORBA-Management-Service-Package und diverse Management-Contents-Packages nötig, die nach XOM konvertierte IDL-Datentypen beinhalten. Die Management-Contents-Packages können durch einen Compiler generiert werden, der eine IDL-XOM-Sprachabbildung durchführen kann.
• Der Postmaster wandelt die für CORBA-Objekte bestimmten XMP-Funktionsaufrufe in CORBA-Methodenaufrufe um (dafür ist es sinnvoll, die dynamische Aufrufschnittstelle zu verwenden, weil sonst für jede Objektklasse ein Stub benötigt wird).
• Die ORS-Datenbank kann verwendet werden, um Adressierungsinformation für CORBA-Objekte zur Verfügung zu stellen. Da die ,,CORBA-Adresse`` eines Objekts seine Referenz ist, ist hier eine Abbildung zwischen Objektreferenzen (z.B. in String-Form) und benutzerfreundlichen Namen denkbar (also eine Funktionalität, die der eines Name-Service gleicht).

 

Abbildung 4.1: Integration des ORBs in die Kommunikationsinfrastruktur

Folgende Argumente sprechen gegen diesen Lösungsansatz:

• Die Entwicklung von Managementanwendungen mit XMP/XOM ist kompliziert und umständlich. Aus diesem Grund wird das API auch für die Kommunikation mit SNMP-Agenten in der Praxis höchst selten verwendet. Der Vorteil, den XMP/XOM bietet (ein gewisses Maß an Transparenz) kann den Nachteil der komplizierten Anwendungsentwicklung nicht ausgleichen.
• Der Empfang und die Weiterleitung von CORBA-Ereignismeldungen durch den Postmaster ist, wenn überhaupt, nur schwer realisierbar. Im Gegensatz zu SNMP und CMIP ist eine CORBA-Ereignismeldung kein Protokollelement mit definierter PDU-Struktur, sondern kann ein beliebiger Methodenaufruf auf einem Consumer-Objekt sein (vgl. [OMG 93c], Kapitel 5). Daraus folgt, daß der Code des Postmasters jedesmal erweitert werden müßte, wenn neue Ereignismeldungen definiert werden.
• Die gesamte Integration kann nur durch Erweiterung des Quellcodes von NetView vorgenommen werden. Es müssen 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.
  • Der Filterprozeß (ovesmd), um CORBA-Ereignismeldungen empfangen und verarbeiten zu können, was besonders schwierig ist, weil diese kein vordefiniertes Format haben.
  • Der Log-Manager (ovelmd), um CORBA-Ereignismeldungen 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.

Aufgrund der genannten Nachteile wurde dieser Lösungsansatz nicht realisiert. Statt dessen wurde zur Lösung der Aufgabenstellung folgendes Prinzip angewendet (vgl. Abb. 4.2):

• Anwendungen zum Überwachen und Steuern von CORBA-Objekten werden grundsätzlich als normale CORBA-Anwendungen implementiert, die über den ORB auf die entsprechenden Objekte zugreifen. Zur Implementierung kann jede Programmiersprache verwendet werden, für die der verwendete ORB eine IDL-Sprachabbildung anbietet.
• Als Schnittstelle zur Managementplattform wurden Adapter-Objekte entwickelt, die die Dienste der Plattform (Topologiemanagement und Ereignisverarbeitung) kapseln und somit für CORBA-Anwendungen zugänglich machen.

 

Abbildung: Konzept zur Lösung der Aufgabenstellung

Als alternativen Lösungsansatz für das Problem der heterogenen Managementarchitekturen und der protokollunabhängigen Programmierschnittstelle sei auf die Arbeiten der JIDM-Gruppe (vgl. Kapitel 2, [X/Open 95a]) verwiesen. Dort wird die Interoperabilität zwischen Managementarchitekturen durch Protokollgateways (CORBA, CMIP, SNMP) angestrebt. Durch solche Gateways wird das Problem der Programmierschnittstelle für Managementanwendungen zumindest in gleichem Maße wie durch XMP/XOM gelöst.