Ausgetauschte Information

  Im Rahmen eines sogenannten Informationsmodells muß für jede Architektur festgelegt werden, wie Syntax und Semantik der auszutauschenden Managementinformation definiert werden. Grundsätzlich muß entschieden werden, ob aus Gründen der Interoperabilität die allgemein denkbaren Möglichkeiten objektorientierter Spezifikationen weiter einzuschränken und zu spezialisieren sind oder ob aus Gründen der Flexibilität des Ansatzes darauf verzichtet werden soll. Zusätzlich ist festzulegen, ob man es bei einem Beschreibungsrahmen belassen möchte oder auf dieser Basis dann zur Förderung der Interoperabilität bereits konkrete Information spezifiziert werden soll. Dabei können folgende Eigenschaften der Modelle unterschieden werden:

• Struktur der Information: Hierzu existieren die beiden folgenden grundsätzlich verschiedenen Alternativen.
  • Der OMG-Ansatz definiert (bisher) ausschließlich eine Schnittstellen-Beschreibungssprache, die Interface Definition Language (IDL). Mit dieser C++-ähnlichen Sprache werden keinerlei weitere, managementspezifische Annahmen über die Struktur von Managementobjekten getroffen; es erfolgen keine weiteren Einschränkungen der denkbaren Objektwelt.
  • Die managementspezifischen Ansätze sind hier (vor allem aus Gründen der Interoperabilität) sehr viel restriktiver; es werden wesentliche Annahmen über die Struktur der Objekte gemacht. So legt das OSI-Informationsmodell z.B. fest, daß ein Managementobjekt durch Attribute, Aktionen und Notifikationen zu charakterisieren ist und gibt sehr detailliert sogenannte Templates vor. Im Internet-Management und bei DMI sind Managementobjekte nur einfache Variable oder Tabellen, die ebenfalls über spezielle Templates beschrieben sind.
• Datentypen: Wie bei anderen Spezifikationssprachen sind Basis-Datentypen festzulegen, die für die Charakterisierung der Objekte bzw. der Attribute verwendet werden können. Die managementspezifischen Ansätze geben hier teilweise bereits eine große Zahl an Typen vor, die für Managementzwecke nützlich sind. Beispiele hierfür sind Zähler, Schwellwerte, Pegel etc., die z.B. aus integer-Typen abgeleitet sind. Solche Festlegungen fehlen beim OMG-Ansatz völlig.
• Semantik der Zugriffe: Hier ist die Frage zu klären, welche Objektzugriffe die Architektur unterstützt. Die managementspezifischen Ansätze legen die Semantik möglicher Zugriffe von vornherein sehr detailliert fest. Die Basis dafür findet man in den obigen Restriktionen der Struktur von Objekten.

  Der OMG-Ansatz macht naturgemäß weniger Vorgaben an mögliche Objektzugriffe, was seinen Grund im allgemeiner gehaltenen Objektmodell hat. Um problemlose Interoperabilität in heterogener Umgebung für das Management sicherzustellen, sind dann noch weitergehende Festlegungen nötig.

• Semantik der Objekte selbst: Integriertes Management in heterogener Umgebung ist nur dann sinnvoll möglich, wenn auch an die Semantik der Objekte selbst Vorgaben gemacht werden. Einfache Beispiele hierzu sind die Semantik von Statusvariablen ( operational, up etc.) und Statusübergängen ( restarting, rebooting etc.) oder die Parameter von Ereignismeldungen (coming up, going down etc.).

  Derartige Vorgaben werden i.a. durch generische, nicht instantiierbare Objektklassen bzw. Interfaces realisiert, deren Eigenschaften weitervererbt werden können, was Einheitlichkeit und damit Interoperabilität fördert. In diesem Bereich ist das grundsätzliche Vorgehen beim OSI-Management und beim OMG-Ansatz sehr ähnlich: Im Rahmen bestimmter sogenannter Systems Management Functions bzw. CORBA-Services und -Facilities (siehe auch Abschnitt 2.5) werden nicht getrennt implementierbare Dienste bzw. Funktionen spezifiziert, sondern Vorgaben bezüglich der Semantik bestimmter Attribute, Methoden oder Object Interfaces gemacht. Diese sollen bei der Definition instantiierbarer Objektklassen bzw. Interfaces ererbt bzw. importiert werden.

  Internet-Management bzw. DMI liefern weniger Vorgaben. Hier baut man eher darauf, daß Informationsspezifizierer erkennen, wenn Gleiches schon einmal anderswo festgelegt wurde, und sich dann entsprechend daran ausrichten.

Insgesamt liefern die Definitionen der managementspezifischen Ansätze (vgl. Abschnitt 2.2) naturgemäß eine Interoperabilität des Managements in heterogener Umgebung, die beim OMG-Ansatz trotz der Arbeit von Gruppen wie der XoTGsysMan noch nicht gegeben ist. Andererseits hat dieser Ansatz den Vorteil, daß für ihn, weil er eben für viele andere verteilte Anwendungen ebenfalls einsetzbar ist, zukünftig eine größere Auswahl an Entwicklungs- bzw. Modellierungswerkzeugen als bei den anderen Architekturen zur Verfügung stehen wird.

Eine Möglichkeit zur Kombination der Vorteile beider Ansätze könnte darin bestehen, die weitergehenden Festlegungen der ,,klassischen`` Managementarchitekturen in OMG-IDL zu übersetzen bzw. zu übernehmen (siehe auch Abschnitte 3.2 und 4.1). Damit könnte man einerseits die allgemein verwendbare Infrastruktur und die Entwicklungswerkzeuge für Managementzwecke nutzen, würde aber andererseits die bei den spezifischen Ansätzen erreichte Interoperabilität auch nicht aufgeben.