Methodik zur Gewinnung generischer MOCs

• Die funktionale Sichtweise  betrachtet ein Managementsystem als installierbares Softwarepaket (z.B. NetView for AIX), das sich in einzelne Komponenten aufteilt. Das IBM AIX-Systemadministrationswerkzeug SMIT listet die Bestandteile des o.a. Systems wie folgt auf: (Base System, Database, Developer Supplement, Online Documentation usw.) Diese Bestandteile können nun weiter unterteilt werden in die von einem Managementsystem angebotenen Dienste wie z.B. Konfigurationsmanager, Leistungsmonitor, Topologiemodul, Ereignisverarbeitung, Zustandsmonitor, Oberflächenbaustein, Kommunikationskomponente, MIB-Browser, Informationsverwaltung.
• Sieht man ein verteiltes kooperatives Managementsystem als ausführbares Programmsystem an, d.h. legt man eine strukturelle  Betrachtungsweise zugrunde, so erscheint dieses als eine Menge von Dateien, die entweder das Managementsystem selbst oder Konfigurationsdateien, Hilfefunktionen sowie Managementdaten enthalten.
• Sobald das Gesamtsystem instantiiert ist, liegt es in Form miteinander kommunizierender UNIX-Prozesse bzw. in Bearbeitung befindlicher Dateien vor. Wir hatten dies in Abschnitt als die operationelle  Sichtweise bezeichnet.
• Die systembezogene  Sichtweise schließlich trägt der Tatsache Rechnung, daß ein Managementsystem nicht isoliert betrachtet werden kann, sondern dessen Funktion stark von Betriebssystem- (Plattenplatz, Zugriffsrechte für Benutzer) und Netzdiensten abhängig ist: Die Prüfung der Netzkonnektivität mittels ICMP, die Abbildung von Namen auf IP-Adressen mittels DNS, die NIS-basierte Benutzerverwaltung sowie der Zugriff auf entfernte Dateisysteme durch NFS erfordert die Verfügbarkeit einer Vielzahl von Netz- und Systemdiensten.

Offensichtlich gelten diese Sichtweisen nicht nur für verteilte kooperative Managementsysteme, sondern auch für eine Vielzahl verteilter Anwendungen und Netzdienste. Daher ist es im Sinne einer Wiederverwendbarkeit von Managementinformation und -diensten angebracht, ein generisches Managementmodell zu entwerfen, das für ein breites Spektrum von Anwendungsklassen gemeinsam verwendbare Managementinformation definiert und durch Vererbungsmöglichkeiten entsprechend der Anwendungsarten verfeinert werden kann. Neben der Berücksichtigung aller vier obengenannten Sichtweisen sollte das Managementmodell ferner von den Spezifika einzelner Managementarchitekturen unabhängig sein und auch keine Annahmen über die zugrundeliegende Kommunikationsinfrastruktur (ORB, Protokoll, Inband- oder Outband-Management, Push- oder Pull-Kommunikation) machen.

Das Ziel unseres Top-down-Vorgehens liegt darin, zuerst generische, d.h. nicht systemspezifische Basisklassen zu gewinnen. Hierzu werden Konzepte des RM-ODP  herangezogen, weil dieses Modell ein architekturelles Rahmenwerk für die Entwicklung und Spezifkation von Software in einer offenen, verteilten Systemumgebung darstellt. Da das RM-ODP völlig systemunabhängig ist, aber dennoch die erforderlichen Objekte einer verteilten Systemlandschaft genau beschreibt, werden einige Konzepte und Objekte des RM-ODP unter dem Managementgesichtspunkt benutzt, um generische Basisklassen für das Anwendungsmanagement zu finden. Die gegenwärtige Verflechtung von ODP mit der von uns als Enterprise Management Architektur ausgewählten Common Object Request Broker Architecture kann als ein weiteres Anzeichen für die Machbarkeit eines durchgehenden Analyse-, Design- und Implementierungsprozesses angesehen werden. Obwohl der Entwurf eines vollständigen Objektmodells für beliebige verteilte Anwendungen und Dienste den Rahmen dieser Arbeit bei weitem sprengen würde, werden wir basierend auf dem RM-ODP, den in Abschnitt identifizierten Managementanforderungen an verteilte Anwendungen sowie dem Ansatz von Neumair [#!neum99h!#] generische anwendungsbezogene Managementobjektklassen (Generic Application Managed Object Classes (GAMOCs))  [#!kene97cc!#] definieren, die wir in Abschnitt als Basisklassen für unsere speziellen MOCs verteilter kooperativer Managementsysteme nutzen werden. Eine wesentliche Anforderung an die Modellierung ist, heterogene Systeme durch ein einheitliches Informationsmodell beschreiben zu können. Hierzu eignen sich objektorientierte Analyse- und Designmethoden sehr gut. Es sollen also Objektklassen gefunden werden, die von herstellerspezifischen, proprietären Details der Ressourcen abstrahieren, aber dennoch ein effizientes Management der Ressource erlauben. Hierzu müssen wir zunächst die GAMOCs in einer Notation beschreiben, die sowohl die Bildung einer Vererbungshierarchie auf einfache Art gestattet als auch eine Rapid Prototyping-basierte Implementierung erlaubt. Ausschlaggebend ist hierbei eine gute Werkzeugunterstützung, die eine möglichst automatische Transformation der Modelle auf konkrete Definitions- bzw. Programmiersprachen vornimmt. Unsere im vorangehenden Abschnitt beschriebenen positiven Erfahrungen mit der Object Modeling Technique in Verbindung mit dem CASE-Tool Software through Pictures haben uns dazu bewogen, unsere Modellierung darauf abzustützen. Das OMT-Modell der GAMOCs kann nun dahingehend verfeinert werden, um die Spezifika verteilter kooperativer Managementsysteme geeignet zu reflektieren. Hierzu ist eine geeignete Spezialisierungshierarchie zu finden, bei der strikte Vererbung anzuwenden ist. Auf diese Weise können, wie wir in Abschnitt nachgewiesen haben, auch bereits vorhandene Modelle in das Objektmodell integriert werden. Hierin enthaltene allgemeingültige Attribute und Methoden können gegebenenfalls in die Basisklassen des generischen Modells aufgenommen werden. Die in IDL überführten Schnittstellen der von uns konzipierten MOCs dienen anschließend als Eingabeparameter für eine CORBA-Entwicklungsumgebung, die uns die CORBA-basierte Implementierung der Managementobjekte gestattet. Abbildung stellt die Methodik graphisch dar.

• Ableitung der GAMOCs aus RM-ODP
• Computational Viewpoint
  • Computational Object
  • Computational Interface
  • Computational Interface Template
  • Interaction Information
  • Computational Object Template
• Engineering Viewpoint
  • Capsule, Cluster und Basic Engineering Object
  • Nucleus
  • Templates für Capsule und Cluster
  • Node
  • Channel
  • Beziehungen zwischen den Klassen des Computational und Engineering Viewpoint