Funktionsmodell

 

Aufgrund unserer bisherigen Ausführungen zu CORBA kann der Eindruck entstehen, daß CORBA (insbesondere im direkten Vergleich mit dem OSI/TMN-Management) einige für das Management wichtige Eigenschaften fehlen. Hierbei muß jedoch beachtet werden, daß bisher lediglich die Basisinfrastruktur von CORBA im Mittelpunkt unserer Betrachtungen stand, und für eine umfassende Bewertung ein Blick auf die im Rahmen der Object Management Architecture (OMA) bereitgestellten (Management-) Dienste erforderlich ist. Ferner besitzt das OSI-Management einen Entwicklungsvorsprung von ungefähr zehn Jahren, sodaß sein Umfang an Managementdiensten gegenwärtig objektiv größer als der von CORBA ist. Wir werden im folgenden aufzeigen, daß sowohl die Differenz in bezug auf vorhandene Dienste nicht (mehr) besonders groß ist, als auch demonstrieren, inwiefern einige der oben angesprochenen Nachteile von CORBA durch den Einsatz entsprechender Dienste aufgewogen werden. Hierbei ist zu beachten, daß Dienste einer Kategorie jeweils Eigenschaften von anderen Diensten derselben oder einer darunterliegenden Kategorie erben können. Somit ist es beispielsweise möglich, aus bestehenden CORBAservices , CORBAfacilities  und CORBAdomains  mit vertretbarem Aufwand neue Managementfunktionalität zu realisieren. Die eigentlichen verteilten Management-Anwendungen stützen sich auf die in den drei oben genannten Kategorien definierten Dienste ab und erben somit bereits wichtige Teile ihres Dienstumfangs. Wir werden zunächst einige allgemeine CORBAservices, die für alle Klassen verteilter Anwendungen gelten, vorstellen und in Beziehung zu den entsprechenden Systems Management Functions setzen. Anschließend gehen wir auf spezifische CORBA-Managementdienste ein.

Wie bereits oben erwähnt wurde, bietet CORBA (u.a. mit dem Lifecycle Service)  die Möglichkeit, zur Laufzeit neue Objekte in das System zu integrieren bzw. nicht mehr benötigte Objekte zu löschen. Hinsichtlich der Instantiierung von Objekten gilt jedoch die in objektorientierten Systemen verbreitete Annahme, daß sowohl die Instantiierung als auch die Löschung von Objekten nur bei Instantiierung bzw. Terminierung des Gesamtsystems geschehen, also verhältnismäßig selten. Angesichts der Tatsache, daß im Management zahlreiche kurzlebige Managementobjekte existieren (z.B. Prozesse im Anwendungsmanagement, Teilnehmerverbindungen im Telekommunikationsmanagement), ist dies für das Management nicht sinnvoll. Ein daraus resultierendes Problem besteht darin, daß in CORBA bisher kein allgemeiner Mechanismus zur Instantiierung von Objekten existiert und pro Objektklasse jeweils eine sogenannte Factory benötigt wird. Für das Löschen, Kopieren und Migrieren von Objekten existieren hingegen generische Dienste.

Der oben angesprochenen Problematik, daß CORBA-konforme Objekte über Objektreferenzen adressiert werden und a priori keine (hierarchischen) Namen besitzen, wird durch den Naming Service  begegnet. Somit können Objekte nicht nur einen Namen zugewiesen bekommen, sondern auch durch die Definition von Namenskontexten auch hierarchisch angeordnet werden. Allerdings kann der Objektname nicht nur während der Laufzeit des Objekts geändert werden, sondern es können zu einem Objekt auch mehrere Namen existieren. Somit entfällt einerseits die Notwendigkeit einer Enthaltenseinshierarchie, andererseits ist gegenwärtig noch nicht abschließend geklärt, inwiefern die flexible Namenszuteilung Nachteile für das Management bringt.

Durch die Verteilung und/oder Replikation wichtiger Managementfunktionalität ist es prinzipiell möglich, CORBA-basierte Managementsysteme skalierbar zu machen, d.h. so zu implementieren, daß die Verarbeitungs- und Antwortzeiten auch für eine sehr große Zahl von Systemen in akzeptablen Grenzen bleiben. Mangelnde Skalierbarkeit aufgrund einer Polling-Strategie ist nicht zuletzt einer der Hauptkritikpunkte an SNMP-basierten (siehe Abschnitt ) Managementsystemen. Durch den standardisierten Event Service  zur Zustellung asynchroner Ereignismeldungen bietet CORBA demgegenüber gute Möglichkeiten, ereignisgesteuerte Managementstrategien zu realisieren. Hierbei werden Sender und Empfänger durch Event Channels  voneinander entkoppelt. Wir werden anhand eines von uns entwickelten Prototypen in Abschnitt detailliert auf diese Mechanismen eingehen. An dieser Stelle sei jedoch bemerkt, daß die Filtermöglichkeiten gegenwärtig noch nicht so weit entwickelt sind wie bei der vergleichbaren OSI Event Report Management Function.

Der OMG Security Service bietet leistungsfähige Mechanismen zur objektbezogenen Authentifizierung, Zugriffskontrolle und Protokollierung, der den OSI-Sicherheitsdiensten gleichwertig ist. Die Modellierung von Beziehungen zwischen einzelnen Objekten kann mit dem Relationship Service so effektiv geschehen, wie es im OSI-Management mit der Relationship Management Function getan werden kann. Die Dienste Property und Query in Verbindung mit dem Interface Repository sowie dem DII bieten ausgezeichnete Möglichkeiten zur Bereitstellung und Abfrage von Metainformationen, die über den Umfang der in Abschnitt angesprochenen OSI Management Knowledge Management Function hinausgehen. Als erster Schritt hin zu einem CORBA-basierten Abrechnungsmanagement kann der Licensing Service angesehen werden, der objekt- und verursacherbezogene Nutzungsstatistiken führt. Die Möglichkeit, Managementaktivitäten transaktionsorientiert auszuführen, wird durch den Transaction Service angeboten. Der Mehrwert eines solchen Dienstes für das Management ist jedoch bisher noch nicht abschließend geklärt. Weitere grundlegende CORBAservices befassen sich mit persistenter Speicherung, Nebenläufigkeit, sowie der Bereitstellung eines einheitlichen Zeitbegriffs in CORBA-basierten Systemen.

Mit den CORBAfacilities und den CORBAdomains existiert der konzeptionelle Rahmen, um Managementdienste in CORBA einzuführen. Die konkrete Ausgestaltung dieser Dienste ist aber heute nur teilweise vorhanden, eine Standardisierung durch die OMG lediglich in wenigen Fällen bereits erfolgt.

Treibende Kraft beim Entwurf von CORBAfacilities für das Systemmanagement, die für eine große Zahl CORBA-basierter Systeme gelten, war die Systems Management Working Group der OpenGroup. Im Rahmen einer vorläufigen Spezifikation [#!xopen95a!#], die unter dem Namen X/Open Common Management Facilities (XCMF)  bekanntgemacht und von der OMG im November 1996 angenommen wurde, sind unter anderem folgende Dienste definiert worden:

• Der Managed Sets Service  erlaubt es, zu Managementzwecken zusammengehörige Objekte zu gruppieren und diese Gruppen zu administrieren. Darunter fallen Tätigkeiten wie die Aufnahme und Streichung von Mitgliedern oder das Einholen von Informationen über Mitglieder einer bestimmten Gruppe.
• Der Instance Management Service  unterstützt das Lifecycle Management, also das Kreieren oder Löschen administrierter Ressourcen, sogenannter Managed Instances.
• Der Policy Management Service  soll Administratoren dabei helfen, das Verhalten eines Managementsystems ihrer spezifischen Umgebung anzupassen. Mit ihm können Zielvorgaben (Policies) zu Objektgruppen definiert und ihre Einhaltung überwacht werden.
• Mit dem Customization Management Service  können Objekt(-typen) auf eine Art erweitert werden, die es erlaubt, auf solche Objekte auch noch in ihrer alten Form zuzugreifen. Damit kann dann die Interoperabilität von Managementanwendungen und Objektinstanzen verschiedener Versionen sichergestellt werden. Diese Funktionalität bildet das im OSI-Management vorhandene Allomorphie-Konzept in einer CORBA-Umgebung nach.

Obwohl die Systems Management Working Group neben der abschließenden Standardisierung dieser Dienste noch diverse weitere Systemmanagementdienste in die OMG-Referenzarchitektur einbringen wollte, muß man diese Bemühungen im nachhinein als gescheitert ansehen: Seit dem Erscheinen dieser ersten Spezifikation sind keine weiteren Aktivitäten der Arbeitsgruppe mehr bekanntgeworden. Hierfür gibt es mehrere Gründe: Paradoxerweise hat vermutlich der sehr frühe Erscheinungstermin dieser Dienste ihre endgültige Spezifikation verhindert, da zum damaligen Zeitpunkt von den jetzt vorhandenen 18 CORBAservices lediglich vier Dienste verabschiedet waren. Somit wurden in der Zwischenzeit durch die fortschreitende Normierung entsprechender CORBAservices einige XCMF-Dienste wie der Managed Sets oder der Instance Management Service überflüssig. Für die anderen XCMF-Dienste (wie z.B. den Policy Management Service) ist zum Teil auch heute noch unklar, auf welchen CORBAservices diese Dienste aufsetzen können. Somit wurden diese auf einem sehr hohen Abstraktionsniveau definiert, ohne daß das hierzu nötige Fundament vorhanden war. Die zwischenzeitliche Verschmelzung von X/Open mit der Open Software Foundation mag ebenfalls dazu beigetragen haben, daß eine Neuausrichtung der daraus hervorgegangenen Opengroup nicht mehr das Systemmanagement beinhaltet. Die äußerst restriktive Informationspolitik der X/Open, wonach der Zugang zu relevanten Dokumenten lediglich institutionellen Mitgliedern vorbehalten ist, hat das Übrige zur mangelnden Verbreitung beigetragen. Dies alles hat dazu geführt, daß bis heute der dem Systemmanagement vorbehaltene Teil der CORBAfacilities-Spezifikation [#!cfac98!#] nur ein knappes Dutzend überblicksartig formulierte Seiten umfaßt, die zudem aus dem Jahre 1995 stammen.

Im Bereich der CORBAdomains gehen seit der OMG-Restrukturierung im Jahre 1995 die Standardisierungsaktivitäten für Managementdienste ausschließlich von der Telecommunications Domain Task Force aus. Gegenwärtig befaßt sich diese Gruppe mit der Standardisierung des Notification Service, der den Event Service um managementspezifische Filtermöglichkeiten für asynchrone Ereignismeldungen erweitert. Als Maßstab dient hier die OSI Event Report Management Function. Der Notification Service bietet neben dem Versehen von Meldungen mit Zeitstempeln flexibel konfigurierbare Ereignisfilter, die denen des OSI-Managements ebenbürtig sind. Bei Bedarf kann darüberhinaus die persistente Speicherung von Ereignismeldungen in Logs veranlaßt werden. Die Definition dieses an der OSI Log Control Function angelehnten Logging Service befindet sich jedoch noch in einem sehr frühen Stadium.

Weitere angedachte Dienste der OMG Telecom DTF beinhalten die Interoperabilität von CORBA mit Intelligenten Netzen, sowie die Schaffung von Übergängen zwischen CORBA und TMN. Die schon begonnenen Arbeiten zum Topology Service, dessen Ziel in der Bereitstellung und Modifikation topologischer Beziehungen zwischen Managementobjekten bestand, wurden im Dezember 1997 zurückgestellt, da nicht abschließend geklärt werden konnte, inwiefern neueste Erweiterungen von CORBA (Portable Object Adapter, Meta-Object Service) bereits Teile der Funktionalität des Topologiedienstes enthalten.