Zusammenfassung: Der Weg zu verteiltem CORBA-basierten Management

    Unsere in Abschnitt beschriebenen prototypischen Implementierungen CORBA-basierter Managementagenten für diverse Anwendungsszenarien haben insbesondere zu folgenden Erkenntnissen geführt:

• Das Konzept der auf dem ODP-Referenzmodell sowie dem Ansatz von Neumair aufbauenden GAMOCs, deren Ziel darin besteht, für eine Vielzahl verteilter Anwendungen gültige Managementinformation bereits an der Wurzel der Vererbungshierarchie zu definieren, hat sich als praktikabel erwiesen: Anhand unserer Prototypen konnten wir aufzeigen, daß die in den GAMOCs enthaltene Managementinformation nicht nur für verteilte kooperative Managementsysteme gültig ist, sondern einen Grundumfang an Managementinstrumentierung auch für verteilte Systemdienste (z.B. NFS und NIS; vgl. Abschnitt ) und Anwendungen (WWW) bereitstellen.
• Die Eignung des in Abschnitt vorgestellten werkzeugunterstützten Transformationsansatzes zur Gewinnung von CORBA-Agenten aus bestehenden Implementierungen konnte nicht nur anhand von SNMP-Agenten nachgewiesen werden, sondern gestattet ebenfalls das Re-Engineering bisher proprietärer Technologie (vgl. Abschnitt ).
• Die Kombination WWW-basierter Technologien mit CORBA gestattet eine einfache Entwicklung von Managementapplikationen nach dem Rapid-Prototyping-Ansatz. Die heutigen Entwicklungswerkzeuge bieten durch die Bereitstellung eines IDL/Java Language Mappings hierfür eine brauchbare Unterstützung, bei der nur in Ausnahmefällen manuelle Anpassungen des generierten Codes erforderlich sind.
• Die Tatsache, daß es zum heutigen Zeitpunkt aus Sicherheitsgründen nicht möglich ist, unmittelbar aus Java-Programmen auf Systemressourcen zuzugreifen, bedeutet eine signifikante Einschränkung für das Management: Grundsätzlich läuft der interpretierte Java-Bytecode in einer von den Systemressourcen abgeschotteten Umgebung ab (sog. ,,Sandbox``) , was offensichtlich dem Ziel des Managements entgegensteht. Abhilfe soll das in der zukünftigen Java-Version 1.2 realisierte Konzept der ,,signed Applets``  schaffen, mit dem ein Mechanismus zur Autorisierung von Applets bereitgestellt wird.
• Die (dynamische) Delegierung allgemein verwendbarer Managementdienste ist ein wichtiges Mittel zur Verbesserung der Skalierbarkeit des Managements. Die Kombination von CORBA mit Java erfüllt die Kriterien der Verteilungstransparenz.
• Die gegenwärtig verfügbare Menge an generischen CORBA-Managementdiensten reicht trotz der von der OMG sowie der OpenGroup unternommenen Standardisierungsbemühungen noch nicht aus, um ein umfassendes, ausschließlich CORBA-basiertes Management zu etablieren. Es ist daher notwendig, in anderen Managementarchitekturen bzw. in Plattformimplementierungen vorhandene Managementdienste für CORBA nutzbar zu machen. Diese können als temporärer Ersatz für momentan in der Spezifikationsphase befindliche CORBA-Managementdienste genutzt werden, wie das in Abschnitt vorgestellte Implementierungsbeispiel für das Management verteilter kooperativer Managementsysteme verdeutlicht hat.

Hierzu werden wir zunächst aufzeigen, welche Dienste sich besonders gut zur Delegierung an Agentensysteme eignen und anschließend ein Konzept vorstellen, wie die Vielzahl der in heutigen Managementsystemen enthaltenen Dienste für CORBA-basierte Systeme verfügbar gemacht werden können.

Wie in den Abschnitten und ausgeführt wurde, hat die Definition von gemeinsam verwendbarer und delegierbarer Managementfunktionalität, zwei Hauptgründe:

• Funktionalität, die von mehreren Managementanwendungen benötigt wird, sollte nur einmal definiert und implementiert und von den Anwendungen dann gemeinsam benutzt werden.
• Skalierbarkeit für eine große Zahl von Endsystemen setzt voraus, daß die Ausführung bestimmter Funktionen an die administrierten Systeme delegiert werden kann. In heterogenen Umgebungen müssen diese Funktionen dann natürlich exakt definiert und offengelegt sein.

  

Abbildung: Aufbau einer Managementplattform

Gemeinsam nutzbare Funktionalität , die für CORBA-basiertes Management derzeit definiert wird (vgl. dazu die Ausführungen in Abschnitt ), ist zu einem großen Anteil bereits in heutigen Managementplattformen enthalten. Diese in Abbildung schematisch dargestellten (grau unterlegten) Basisdienste erstrecken sich vor allem auf folgende Bereiche:

• Kreieren und Löschen von Managementobjekten, die die zu administrierenden Ressourcen für das Management repräsentieren (Lifecycle Management),
• Gruppieren von Objekten zu Managementdomänen (Domains, Collections) nach wählbaren Kriterien und Administration dieser Domänen,
• Definition und Anwendung bestimmter Zielvorgaben (Policies) für das Management der Objekte innerhalb einer Domäne, Erkennung eventueller konfliktärer Vorgaben,
• Handhabung verschiedener Versionen von Objektdefinitionen und Implementierungen, um Interoperabilität von Managementanwendungen und administrierten Ressourcen sicherzustellen,
• Definition umfassender Filtermöglichkeiten für asynchrone Ereignismeldungen,
• Bereitstellung einer Möglichkeit zur persistenten Speicherung von Ereignismeldungen in Logs.

Delegierbare Funktionalität , die die Skalierbarkeit für umfangreiche DV-Infrastrukturen sicherstellt, wird in einem ersten Schritt vor allem für folgende Bereiche benötigt:

• Handhabung asynchroner Ereignismeldungen und Alarme (Event Management: Abonnieren wählbarer Ereignistypen durch Anwendungen, Filterung von Ereignismeldungen nach wählbaren Kriterien),
• Handhabung periodisch durchzuführender Managementaktionen ( Scheduling),
• Überwachung von Schwellwerten (Threshold Monitoring),
• Aufzeichnen bestimmter, vor allem auch sicherheitsrelevanter Ereignisse, Komprimierung der zugehörigen Daten (Logging, Log Management)

Diese Liste könnte natürlich noch erheblich erweitert werden. Es handelt sich hier nur um die dringlichsten Aufgaben, die vorrangig behandelt werden müssen.