Ein solches Modell ist im Rahmen dieser Arbeit durch Zusammenführen und Weiterentwicklung vorhandener Ansätze in mehreren Schritten erstellt worden. Bei der anschließenden prototypischen Implementierung entstand eine Managementlösung in Form eines CORBA-Agenten und zugehöriger Managementanwendung mit graphischer Oberfläche.
Für das Informationsmodell wurde als Basis die Object Modeling Technique festgesetzt. Neben dem mächtigen objektorientierten Ansatz bietet OMT im Objektmodell die graphische Repräsentation von Beziehungen zwischen den MOCs. Außerdem wurde gezeigt, daß das dynamische Modell nicht nur die Modellierung von asynchronen Meldungen für Ereignisse erlaubt, die innerhalb der Ressourcen auftreten können, sondern im Zustandsdiagramm auch die Zustandsübergänge graphisch darstellen kann, die zum Eintritt eines Ereignisses führen. Da die verwendeten OMT-Techniken praktisch unverändert von UML, dem kommenden State-of-the-Art für Design und Entwurf objektorientierter Software, übernommen werden, ist die Zukunftssicherheit gewährleistet. Im Hinblick auf die Realisierung des Modells auf Basis von CORBA war die Möglichkeit der Generierung von IDL-Objektbeschreibungen durch ein kommerzielles CASE-Tool ein weiteres wichtiges Argument für OMT.
Zur Gewinnung von generischen Basisklassen für das Modell wurde im ersten Schritt der Ansatz von Bernhard Neumair aufgegriffen und auf das Systemmanagement ausgedehnt. Dieser analysiert unter dem Managementgesichtspunkt die semantischen Konzepte der RM-ODP Viewpoint Languages, um daraus geeignete generische MOCs abzuleiten. Das Referenzmodell bietet eine solide, weil standardisierte, Grundlage und gewährleistet aufgrund seiner abstrakten, systemunabhängigen Sichten die breite Anwendbarkeit der gefundenen MOCs auf Ressourcen eines heterogenen, verteilten Systems. Der dienstorientierte Blick des Computational Viewpoint, der die funktionale Zerlegung einer Anwendung in Software-Komponenten beschreibt, die über Schnittstellen interagieren, führt zu MOCs für das Software- und Anwendungsmanagement. Der Engineering Viewpoint hingegen legt fest, welche Infrastrukturobjekte eine verteilte Plattform bieten muß, um die Kooperation der verteilten Anwendungskomponenten zu unterstützen. Aus diesen Konzepten lassen sich MOCs für Endsystem- und Netzressourcen wie Prozesse und Kommunikationsverbindungen ableiten.
Um ein effizientes Management zu ermöglichen, erfolgte im zweiten Schritt die Definition von Managementinformation und Funktionalität in Form von Attributen und Methoden für die gefundenen Basisklassen. Hierzu wurde auf die Anforderungen verschiedener Managementfunktionsbereiche, auf existierende generische MIBs und auf bottom-up gewonnene Information spezieller Ressourcen zurückgegriffen. Für letztere mußte insbesondere überprüft werden, ob sie so allgemeingültig ist, daß sie generell auf Klassen dieser Ressourcen anwendbar ist und auch gewöhnlicherweise bereitgestellt werden kann. Das Gesamtmodell der Basisklassen ist in den Abbildungen A.1 und A.2 im Anhang A zu finden.
Im nächsten Schritt wurde das Modell um Klassen für das Management der Endsystemressourcen von UNIX-Workstations erweitert, in dem der Prototyp eines vorhandenen Objektmodells erfolgreich über eine Spezialisierungshierarchie integriert wurde. Da dies praktisch problemlos gelang, sollten sich die generischen Basisklassen auch auf andere Endsysteme, z.B. unter OS/2 oder Windows NT, anwenden lassen.
Ein weiterer Schwerpunkt der Arbeit war die Berücksichtigung des Managements verteilter Systemdienste. Hierzu wurden generische MOCs für beliebige Client/Server-basierte Dienste eingeführt und wiederum mit Information und Funktionalität zu verschiedenen Funktionsbereichen ausgestattet. Diese wurden anschließend für die konkreten Dienste NFS und NIS weiter spezialisiert. Eine Bottomp-Up-Analyse hat ergeben, daß die geforderte Managementinformation ohne Instrumentierung der Software momentan leider nur zum Teil von den Diensten bereitgestellt wird. Dies gilt insbesondere auch für wünschenswerte asynchrone Ereignismeldungen. Trotzdem erlaubt das entstandene Modell (siehe Abbildung A.3) die Entwicklung von Managementanwendungen, die auf unterschiedlichen Ebenen der Spezialisierungshierarchie operieren. Auf der obersten Ebene der ODP-Basisklassen ist die Überwachung des Status beliebiger Anwendungen möglich. Eine Applikation für das Dienstmanagement könnte auf den generischen MOCs Server, Client und Request arbeiten. Schließlich wird ein Administrationswerkzeug für NFS auf unterster Ebene die dienstspezifischen Klassen instantiieren. Letzteres wurde im Rahmen des implementierten Prototyps realisiert.
Zur Erstellung des Objektmodells und der Zustandsdiagramme wurde das CASE-Tool StP/OMT eingesetzt. Nach Festlegung der Datentypen für die Attribute und der Parameter und Rückgabewerte für die Methoden generiert das Werkzeug aus dem Objektmodell automatisch die IDL-Beschreibungen der Managementobjektklassen als Grundlage für den CORBA-Agenten. Der generierte Code konnte ohne größere Modifikationen vom IDL-Compiler übersetzt werden. Bei der Abbildung gehen allerdings Assoziationen und Aggregationsbeziehungen zwischen den Klassen verloren. Auch die in den Zustandsdiagrammen definierten asynchronen Ereignismeldungen werden bei der Code-Generierung übergangen. Schwächen zeigte das ansonsten sehr leistungsfähige Werkzeug darüber hinaus bei der Formatierung und beim Ausdruck der Modelle.
Die CORBA-Entwicklungs- und Laufzeitumgebung VisiBroker for Java war insgesamt betrachtet sehr gut für die Realisierung des Prototyps geeignet. Die Java-Agentenobjekte sind allerdings aufgrund der Heterogenität der zu managenden Endsysteme nicht plattformunabhänging. Das JNI ermöglicht sowohl die Nutzung von Betriebssystemfunktionen innerhalb eines Agentenobjekts als auch die Wiederverwendung von C-Code eines bestehenden SNMP-Agenten unter der Voraussetzung, daß die nativen Funktionen in einzelnen Modulen vorliegen. Dynamische Managementobjekte des Agenten wurden mit Hilfe von Factories bereitgestellt. Asynchrone Ereignismeldungen wurden auf Basis des CORBA Event-Service realisiert. Der enstandene CORBA-Agent implementiert einen repräsentativen Teil des entwickelten Objektmodells für das Betriebssystem AIX 4.2. Zum Zugriff auf die Information und Funktionalität des Agenten wurde eine plattformunabhängige Managementanwendung in Form eines Java-Applet erstellt, die innerhalb aller gängigen Web-Browser ausgeführt werden kann. Der ohnehin schon relativ kleine Aufwand für die graphische Oberfläche der Anwendung könnte durch den Einsatz eines GUI-Builder noch erheblich gesenkt werden. Die Kommunikation zwischen Applet und Agentenobjekten über CORBA funktioniert bis auf kleinere Probleme, die auf den mangelnden Reifegrad der verwendeten Produkte zurückzuführen sind, reibungslos. Die Ergebnisse der Arbeit zeigen, daß der CORBA-basierte Ansatz für das System- und Anwendungsmanagement tragfähig ist. Voraussetzungen für einen Durchbruch sind allerdings die Integration eines ORB in die unterschiedlichen Betriebssysteme der Workstations und die weitgehende Verwendung von CORBA durch die Software-Hersteller bei der Entwicklung verteilter Anwendungen.
Zuletzt soll noch ein Ausblick auf offene Fragestellungen präsentiert werden, die sich aus dieser Arbeit ergeben. Ebenso sollen Punkte genannt werden, an denen aufbauende Arbeiten anknüpfen könnten.
Eine zentrale Fragestellung ist natürlich, ob die Information und Funktionalität der generischen Basisklassen des Objektmodells tatsächlich allen Anforderungen des System- und Anwendungsmanagements gerecht wird. Aufgrund der Breite dieser beiden Disziplinen konnten einige Bereiche nur oberflächlich betrachtet werden. Ebenso steht der Beweis aus, daß die Information der Oberklassen auch für das Management von Workstations, die nicht unter UNIX betrieben werden, angewendet werden kann. Hierzu wäre eine Bottom-Up-Analyse der Betriebssysteme OS/2 und Windows NT einschließlich der Betrachtung der Systemdienste erforderlich.
Weiterhin fehlt es an ODP-konformen Anwendungen, die Managementinformation an einer genormten Schnittstelle bereitstellen. Bei kommerziellen Werkzeugen zum Anwendungsmanagement handelt es sich praktisch ausschließlich um spezielle Tools, die mit einem Software-Produkt ausgeliefert werden oder in dieses integriert sind. Ein Beispiel hierfür ist das Computing Center Management System zur Status- und Performance-Überwachung von SAP R/3. Hier wären die Software-Hersteller gefordert, ihre Anwendungen entsprechend zu instrumentieren, damit Agenten entsprechende Klassen des Objektmodells wie compObject, comp Interface und interactionInfo instantiieren können und die Information somit einer integrierten Managementlösung zugänglich machen können. Zumindest bei der Neuentwicklung von Systemdiensten und Anwendungen wäre es wünschenswert, daß diese auf dem RM-ODP basierten, damit RM-ODP-konforme Beschreibungen vorliegen würden, um daraus spezifische MOCs ableiten zu können, die von einem Agenten implementiert werden könnten.
Das Objektmodell bietet Spielraum für Erweiterungen und Weiterentwicklungen:
Ein weites Feld für weiterführende Arbeiten stellt auch der entstandene Prototyp dar. Die folgende Aufzählung nennt die entsprechenden Ansatzpunkte.
Der Einsatz weiterer CORBA-Services würde die Leistungsfähigkeit der Managementlösung erhöhen. Die folgenden Anregungen hängen natürlich von der Verfügbarkeit des entsprechenden Service ab.
Schließlich sollte die Tragfähigkeit der CORBA-Managementlösung auch in produktiven Systemumgebungen durch Performance-Messungen und Überprüfung der Skalierbarkeit unter Beweis gestellt werden. Dies könnte auch den Vergleich der Leistungsfähigkeit mit einer herkömmlichen, SNMP-basierten Lösung einschließen. Die CORBA-Lösung wird überzeugen, sobald die angesprochene Funktionalität der CORBA-Services zur Verfügung steht und von Agenten und Managern genutzt wird. Die prinzipielle Eignung des Ansatzes hat diese Arbeit gezeigt.