Einführung

 

Durch die zunehmende Verbreitung vernetzter arbeitsteiliger Systeme sehen sich die Betreiber großer verteilter IV-Infrastrukturen steigenden Anforderungen an die Güte der von ihnen angebotenen Dienste ausgesetzt. Diese Situation wird durch das Vorhandensein stark heterogener Endbenutzersysteme sowie den in ihnen enthaltenen Objekten wie Anwendungsprogrammen, Betriebssystemen und Kommunikationsprotokollen noch weiter verschärft. Demgegenüber resultiert aus der hohen Konkurrenzsituation zwischen den Betreibern und dem dadurch entstehenden Kostendruck der Zwang, die Anzahl hochqualifizierten Personals zur Überwachung und Steuerung dieser interagierenden Komponenten zu reduzieren.

Der Brisanz der Situation, in der sich die Betreiber befinden, kann jedoch geeignet entgegengetreten werden, indem ihnen Werkzeuge zur Verfügung gestellt werden, die die zugrundeliegende Heterogenität verschatten und es ihnen somit ermöglichen, eine einheitliche Sicht auf die verteilten Systeme zu erhalten. Standardisierte Managementarchitekturen sind ein geeignetes Mittel, um dieses Ziel zu erreichen. Beispiele hierfür sind das ISO/OSI-Management Framework oder die Internet-Managementarchitektur (häufig auch als SNMP-Management bezeichnet), die jedoch per se nicht interoperabel sind.

Beide Architekturen haben allerdings Gemeinsamkeiten, die unter anderem der Grund dafür sind, daß sich bis zum heutigen Tage keine dieser beiden Alternativen vollständig am Markt durchsetzen konnte: für die Beschreibung der zu steuernden Ressourcen wird ein eigenständiges Informationsmodell und damit eine spezielle Beschreibungssprache verwendet; zur Kommunikation zwischen Managementsystem und der zu überwachenden Infrastruktur existieren dedizierte Managementprotokolle. Die Handhabung dieser durch das Management zusätzlich eingeführten Heterogenität erweist sich im praktischen Betrieb jedoch oft als hinderlich und führt insbesondere dazu, daß die Hersteller einer verteilten Anwendung und der entsprechenden Managementapplikation nur in den seltensten Fällen identisch sind. Die Anforderungen der Betreiber an Managementsysteme werden daher in marktfähigen Produkten oft nur unzureichend berücksichtigt.
Auch im Bereich der Entwicklung von Managementsystemen macht sich die Fixierung auf eine spezielle Beschreibungsmethodik und ein eigenständiges Managementprotokoll bemerkbar: Allgemein verfügbare Modellierungs- und Implementierungswerkzeuge können entweder nicht oder nur mit hohem Anpassungsaufwand eingesetzt werden, da die Notation zur Beschreibung von Managementinformation oft nicht von den Herstellern dieser Werkzeuge unterstützt wird.

Demgegenüber verfolgt die im Rahmen der Object Management Architecture (OMA) von der Object Management Group (OMG) standardisierte Common Object Request Broker Architecture (CORBA) ([6]), die ursprünglich für verteilte objektorientierte Programmierung konzipiert wurde, einen anderen Ansatz: man fordert, daß eine einzige Architektur sowohl für die Entwicklung als auch für das Management einer verteilten Anwendung verwendet wird. Dies bedeutet, daß nicht nur die Beschreibung sowohl der Management- als auch der Anwendungsobjekte in einer identischen Notation (OMG IDL) erfolgt, sondern ebenfalls Nutz- und Managementdaten einer Applikation mit demselben Kommunikationsmittel (einem sogenannten Object Request Broker (ORB)) übertragen werden. Management wird somit zu einem (zweifellos wichtigen) Teilaspekt verteilter Anwendungen. Somit kann das gesamte Spektrum verfügbarer Werkzeuge zur Softwareentwicklung genutzt werden, da Nutz- und Managementdaten identisch modelliert und implementiert werden.
Konzeptionelle Untersuchungen bezüglich der Mächtigkeit des CORBA-Objektmodells im Vergleich zu den Informationsmodellen etablierter Managementarchitekturen haben die prinzipielle Eignung von CORBA für das Management von Endsystemen und der auf ihnen ablaufenden Anwendungen nachgewiesen (siehe [12]). Einerseits sind aufgrund des geringen Alters von CORBA momentan gerade erste Implementierungen auf dem Markt erhältlich; im Bereich des Managements sind derzeit noch keinerlei CORBA-konforme Managementsysteme und -agenten bekannt. Auf Seiten der Hersteller ist jedoch zunehmend die Tendenz erkennbar, solche Werkzeuge zu entwickeln ([15], [7]). Andererseits existiert gegenwärtig eine große Zahl an SNMP-fähigen Managementagenten und es stellt sich daher die Frage, wie bestehender SNMP-Agentencode nahtlos in die CORBA-Welt migriert werden kann. Ein so entstehender CORBA-Managementagent besteht aus verteilten kooperativen Managementobjekten, die mit Hilfe des Object Request Brokers interagieren.

  

Abbildung: Vorgehensweise bei der Portierung des Agenten

Der Beitrag präsentiert ein Vorgehensmodell zur Migration bestehenden modularen SNMP-Agentencodes in eine CORBA-Umgebung und schildert die Schritte dessen konkreter Anwendung anhand eines praxisnahen Beispiels. Seine Struktur orientiert sich an dem in Abbildung 1 skizzierten Vorgehensmodell: Abschnitt 2 beschreibt die Eigenschaften des am Lehrstuhl entwickelten SNMP-Agenten zum Management von UNIX-Workstations und den JIDM-Algorithmus (siehe 2.2) zur Umsetzung des Internet-Informationsmodells in CORBA-Objektbeschreibungen. Das Ergebnis ist ein algorithmisch erzeugtes Objektmodell, das jedoch noch verbessert werden muß, um den Anforderungen gerecht zu werden. Die Gründe dafür sowie die Schritte und Werkzeuge zur Optimierung des vorhandenen Objektmodells sind in Abschnitt 3 beschrieben. Hierbei ist es von großer Bedeutung, auf Werkzeuge wie CASE-Tools zurückgreifen zu können, die den zyklischen Prozeß der objektorientierten Analyse und des Designs geeignet unterstützen. Sie schaffen auch die Grundlage, um das bestehende Modell um neue Anforderungen von Seiten der Betreiber nahtlos zu erweitern. Nachdem die Modellierung abgeschlossen ist, kann die Implementierung erfolgen, die in Abschnitt 4 dargestellt wird. Hierbei hat sich bei unseren Arbeiten herausgestellt, daß die Schnittstellen zwischen den einzelnen Werkzeugen gegenwärtig noch verbesserungsbedürftig sind und man von einem reibungslosen Zusammenspiel aller am Entwicklungsprozeß beteiligten Komponenten noch etwas entfernt ist.