Wegweiser Web

Von: Petra Borowka

Das Bestechende an der Web-Technik: Fast jeder will sie, fast jeder hat sie und fast jeder nutzt sie. Ihre Werkzeuge, die Browser, sind längst ein unverzichtbares Kulturgut. Nichts und niemand kommt mehr daran vorbei – auch nicht das Netzwerk- und Systemmanagement. BMC, Cisco, Compaq, Intel und Microsoft haben deshalb frühzeitig ihre Aktivitäten kanalisiert und legten im Juni 1996 den Grundstein zu einer Initiative, die sich damals so nannte wie heute die Norm: "Web Based Enterprise Management" (WBEM). Ihr Kern ist das "Common Information Model" (CIM), dessen zweite Version (CIMv2) im März 1998 von der "Desktop Management Task Force" (DTMF) verabschiedet wurde.

WBEM schlägt gleich drei Fliegen mit einer Klappe:

•Es ermöglicht Applikationen, die untereinander nach einem einheitlichen Schema Informationen austauschen können;

•es verringert den Aufwand beim Erstellen und Anpassen von Programmen, die ständig um neue Funktionen ergänzt werden müssen; und

•es gestattet einen flexiblen und standardisierten Objektzugriff.

Zudem beseitigt es ein gerade in heterogenen Netzen weit verbreitetes Dilemma: Scheiterte die Zusammenarbeit der verschiedenen Hersteller in der Vergangenheit stets daran, daß alle die eigenen Datenmodelle als Differenzierungsfaktor vermarkteten, so verbindet heute der objektorientierte Ansatz von WBEM die Kontrahenten durch ein einheitliches Datenmodell.

WBEM setzt auf standardisierte Objektorientierung:

•Mittels Abstraktion und Klassenbildung können komplexe Managementdomänen auf ein Modell abgebildet werden. Es faßt Objektgruppen als Klassen zusammen und definiert gemeinsame Eigenschaften (Properties) von Objekten, deren Verhalten (Methods) und deren Beziehungen untereinander (Relations).

•Subklassen können die Funktionsvielfalt von Klassen erweitern. So entsteht eine Top-Down-Struktur, die sowohl allgemeine als auch spezielle Managementaspekte berücksichtigt.

•Assoziationen und Relationships beschreiben Abhängigkeiten und Zuordnungen verschiedener Bereiche, Komponenten und Applikationen. Diese Konzepte sind sehr viel mächtiger als die multidimensionalen Matrixkonstrukte oder Crossreferenz-Tabellen der bisherigen Managementstandards.

•Durch Vererbung von Standardmethoden, sprich Objektverhalten, wird eine weitergehende Vereinheitlichung erreicht. So kann eine Reset- oder Reboot-Methode auf oberster Abstraktionsebene spezifiziert werden, die nach einem Software-Absturz auf eine beliebige Komponente angewendet werden kann.

Den Kern von WBEM-Management bilden drei Elemente:

•ein erweiterbares Datenmodell, in dem die Objekte mit der "eXtended Markup Language" (XML) definiert werden,

•ein Objektmanager (CIMOM), der einen einheitlichen Zugriff auf Daten von verwalteten Objekten ermöglicht, und

•ein Repository, in dem sowohl Klassen als auch konkrete Instanzen von Klassen abgelegt sind.

Klassen und ihre Instanzen stellen die Managed Objects konform zum WBEM-Datenmodell dar. Die Spezifikationen für die WBEM-Architektur sind in eine Informations- und eine Prozeßarchitektur unterteilt. Die Informationsarchitektur spezifiziert die Darstellung und das Datenmodell, die Prozeßarchitektur die Interaktion von verschiedenen Applikationen und Objekten verschiedener Hersteller.

Wie die meisten Informationsarchitekturen ist auch WBEM top-down organisiert: Völlig allgemeingültige Managementobjekte auf der obersten Ebene werden immer weiter verfeinert und konkretisiert. Das CIMv2-Modell, auch Meta-Modell oder CIMv2-Schema genannt, ist der "Top-Level" der definierten Informationsarchitektur. Darin sind die wesentlichen Managementelemente und ihr Verhalten zueinander abstrakt und also anpaßbar abgebildet. Es definiert die Struktur und das Verhalten eines allgemein anwendbaren "Enterprise-Management-Modells", das eine Managementumgebung als eine Ansammlung von mehr oder weniger stark miteinander verflochtenen Systemen betrachtet. Sie sind allesamt aus einer endlichen Anzahl von diskreten Elementen zusammengesetzt, wobei "diskret" bedeutet: nicht weiter in Einzelobjekte/Komponenten unterteilbar.

CIMv2 unterscheidet drei Ebenen:

Das "Core-Schema" (Core Model) beschreibt Aspekte, die für alle Managementbereiche gleich sind.

Das "Common-Schema" (Common Model) beschreibt Aspekte, die spezielle Managementbereiche betreffen, jedoch von einer bestimmten Implementierungstechnik unabhängig sind.

Das "Extension-Schema" erlaubt Erweiterungen des Common-Schemas, die herstellerspezifisch und von bestimmten Implementierungen abhängig sind.

Das CIM-Konzept ist insofern implementierungsunabhängig, als dasselbe Prinzip für den Austausch von Managementinformationen auf ganz unterschiedlichen Ebenen genutzt werden kann. Vom Meta-Schema ganz oben bis hinab zu den Spezial-Applikationen für Spezialkomponenten entsteht so eine CIM-konforme Informationskette. Erst sie macht die verschiedenen Applikationen interoperabel.

Das Meta-Modell ist in einem Repository abgelegt, auf das Programme zugreifen können. Aus dem Meta-Modell leiten CIM-Programmierer das Core Schema, das Common-Schema und Extension-Schemata als Instanzen her. Sie alle definieren allgemeine Objektklassen. Diese wiederum werden von verschiedenen Applikationen in konkrete, spezifisch angepaßte Objektinstanzen umgesetzt. So entsteht aus einem Schema eine konkrete Realisierung, sprich Applikation.

Ein Schema ist an sich datenbankunabhängig und deshalb von verschiedenen Datenbanken nutzbar. Darüber hinaus taugt es mittels Export/Import auch zum Austausch von Informationen zwischen verschiedenen Datenbanken. Dasselbe Schema kann also von verschiedenen konkreten Applikationen und für verschiedene konkrete Datenbanken genutzt werden und trotzdem zu einer CIM-konformen Realisierung/Implementierung führen. Verschiedene CIM-konforme Applikationen können dann über festgelegte Parameter Informationen austauschen und jeweils lokal anpassen oder Datenbestände gemeinsam nutzen.

Die Managementinformation wird einheitlich in einer Sprache abgefaßt, die auf der guten alten "Interface Definition Language" (IDL) basiert und "Managed Object Format" (MOF) heißt. Eine MOF-Datei (MOF-Spezifikation) beschreibt nach syntaktisch festgelegten Regeln und in Textform Assoziationen, Eigenschaften, Klassen, Methoden, Referenzen und Instanziierungs-Vorschriften mit den zugeordneten Qualifizierungen (Qualifiers).

Der Vorteil einer MOF-Spezifikation liegt darin, daß sie über einen Compiler in eine prinzipiell beliebige Management-Applikation eingebracht werden kann. Zu diesem Zweck stehen in der MOF-Datei entsprechende Compiler-Anweisungen. Wenn sie von einer Applikation benutzt wird, laufen im wesentlichen zwei Operationen ab: Zuerst erstellt ein Compiler die Struktur des Modells als "Knochengerüst"; anschließend fügt die Applikation konkrete Instanzen als "Fleisch und Blut" gewordenes Modell in die Managementplattform oder das Management-Tool ein.

Prozeßarchitektur

So können Applikationen, die unterschiedliche Managementsprachen reden, MOF zum Export und Import derselben Information nutzen – etwa von DMTF/MIF über WBEM/MOF nach SNMP/SMI oder OSI/GDMO. Hierfür sieht CIMv2 zahlreiche Mapping-Regeln und Spezifikationen vor. Datenintegration wird also durch Konvertierung in ein gemeinsames Basisformat erreicht: das CIM-Schema mit MOF.

Bei extensivem Mapping gehen mitunter Informationen und Datenintegrität verloren, so daß Ergebnisse/Reports verfälscht werden. Davon sind insbesondere Details betroffen, die auf verschiedenen Plattformen unterschiedlich implementiert sind. Hier bietet CIMv2 die Möglichkeit, solche nicht eins zu eins abbildbaren Informationen in sogenannte "Scratch-Pads" einzufügen. Diese müssen gegebenenfalls für jede Applikation separat aufgebaut und bei Änderungen korrigiert werden – eine aufwendige Technik, die sich kaum automatisieren läßt.

Wenn ein oder mehrere Applikationen zu einem konkreten Zeitpunkt auf ein konkretes Objekt zugreifen, kommt die Prozeßarchitektur ins Spiel: Sie erst ermöglicht und steuert den Zugriff. Aktuell setzen die Applikationsspezifikationen NT als Basis voraus – Unix ist diesbezüglich noch immer ein Stiefkind. Ein Objektzugriff erfolgt über eine WBEM-Managementinfrastruktur, und zwar dynamisch mit einem sogenannten "Objekt-Provider". Die WBEM-Managementinfrastruktur besteht aus dem Objektmanager CIMOM und einer Sprache zur einheitlichen Darstellung der Information wie etwa "eXtended Markup Language" (XML) oder "Distributed Component Object Model" (DCOM). Der Objektmanager wird auch "Request Broker" genannt: Als Mittler zwischen Applikation und Objekt leitet er den Zugriffswunsch an die zuständigen Objekt-Provider weiter und das Zugriffsresultat vom Objekt-Provider zurück zur Applikation.

Managementapplikationen können verschiedene Tasks erledigen, etwa Performance-Messungen durchführen, Ausfallreports erstellen und Managementdaten korrelieren. Objekt-Provider werden benötigt, wenn eine Managementapplikation nicht auf statische, sondern auf dynamische Daten zugreifen soll. Die Objekt-Provider sind selbst komplexe Objekte, sogenannte "Component Object Model"-Komponenten (COM), die direkt mit den verwalteten Objekten kommunizieren können. Ein Objekt-Provider leitet die Information, die er von einer Komponente, also einem Objekt, empfangen hat, zur Integration und Interpretation an CIMOM weiter. Erst danach kann die Applikation die Informationen "verstehen" und weiterverarbeiten.

Der ursprüngliche Ansatz, als spezielles Protokoll für WBEM das "Hypermedia Management Protocol " (HMMP) zu standardisieren, ist bislang bei der "Internet Engineering Task Force" (IETF) gescheitert. Nichts desto Trotz entwickelte die WBEM-Initiative das HMMP-Konzept weiter und münzte es in einen XML-Vorschlag um. Im August entschied sich dann die "Desktop Management Task Force" (DMTF) doch für ein Kommunikationsprotokoll, nämlich HTTP im Verbund mit XML.

Produktsituation

Die wenigsten Managementprodukte, die mit dem Prädikat "Web-basiert" versehen sind, sind auch WBEM-konform. Manche Hersteller haben lediglich Browser-Oberflächen über die vorhandenen Kernfunktionen gelegt, andere lassen ihre Produkte Ergebnisse im Web-Seitenformat anstelle von Tabellen oder proprietären Grafiken generieren. Nachdem die CIMv2-Spezifikation erst im April dieses Jahres fertiggestellt wurde, können derzeit voll kompatible Gesamtlösungen noch nicht implementiert sein. Einige Firmen handeln einzelne Produkte aber dennoch schon als CIMv2-kompatibel:

•Tivoli: Netview V5.1 soll WBEM-Daten für Troubleshooting und Inventory sammeln und anzeigen können. Auch "Global Enterprise Manager" und "Distributed Monitoring" sollen künftig WBEM unterstützen. Framework und "Tivoli Enterprise Console" (TEC) sind noch nicht CIMv2-konform.

•Hewlett Packard: Das Unternehmen beschränkt sich noch auf die Web-Browser-Technik. Nach Aussagen des Marketings strebe man jedoch generell CIMv2-Konformität an.

•Compaq: Der "Insight Manager" verfügt in der Version 4.0 über Möglichkeiten, via Browser auf Geräte- und Konfigurationsdaten zuzugreifen. Kunden älterer Versionen erhalten das Release als kostenloses Upgrade.

Trotz all der WBEM-Euphorie bauen Tivoli und HP in naher Zukunft auch die Framework-Funktionen weiter aus.

Fazit

WBEM ja oder nein? Wie so oft, besteht die Suppe aus neuen Zutaten, aber es sind einige Haare drin. Zunächst die Vorteile:

•Managementapplikationen werden auf der Basis von Web-Techniken programmiert; der Umgang damit ist bekannt, verbreitet und kostengünstig.

•Das Benutzer-Interface ist ein Browser; im Regelfall gewöhnen sich auch ungeübte Managementanwender schnell an dessen Bedienung.

•Das gemeinsame Informationsmodell CIM ist der Grundstein für einen einheitlichen Objektzugriff; dadurch rückt ein wichtiges Ziel in greifbare Nähe: eine konsistente, integrierte Objektdatenbank für alle Managementbereiche, also etwa Applikationen, Benutzer, Netze oder Systeme.

•Ein anderes Ziel ist bereits erreicht: Die Beschreibungssprache MOF vereinheitlicht den Austausch und die Nutzung derselben Information in ganz verschiedenen Applikationen.

Dem stehen die haarigen Risiken entgegen, die gegen einen schnellen Einsatz sprechen:

•Jede neue Strategie sollte anfangs einen konfliktfreien Parallelbetrieb zur bisherigen Managementlösung gewährleisten. Diese Migration ist bei WBEM nur lückenhaft beschrieben und läßt sich auch nicht automatisieren. Das macht einen aufwendigen Doppelbetrieb notwendig.

•In den neu vorgestellten WBEM-Produkten sind zwar CIM-Grundfunktionen implementiert, die Mapping-Funktionen für Informations-Austausch blieben jedoch außen vor.

•Die heute erhältliche Integration beschränkt sich vielfach auf den gegenseitigen Aufruf von Applikationen unter einer standardisierten Browser- Oberfläche, die jedoch noch verschiedene Datenbanken und Objektmodelle nutzen.

•Der Beweis, daß CIM-Implementierungen in Form von WBEM-Applikationen tatsächlich hunderttausende von Objekten in einer komplexen vernetzten Systemumgebung gleichzeitig performant und interoperabel handhaben können, steht noch aus.

Selbst wenn WBEM zum Standard wird, der den Umgang mit Managementapplikationen erleichtert – das Tool ist nicht alles! Es ist insbesondere kein Ersatz für den mühevollen Prozeß, Managementanforderungen, Managementbereiche, Managementfunktionen und Betriebsabläufe organisatorisch sinnvoll zu definieren, mit Prioritäten zu belegen und Schritt für Schritt umzusetzen. (sk)

Petra Borowka leitet die Unternehmensberatung für Kommunikationsstrategien und herstellerneutrale Planung standardbasierter Netzwerke UBN.

Literatur

[1] Borowka, P.: Ist WBEM die Plattform der Zukunft?; Computerwoche focus Nr. 5, September 1998, S. 10 ff.

Weblinks

WBEM Homepage:

wbem.freerange.com

CIM Version 2.0:

www.dmtf.org/cim/cimdoc20/cimdoc20.htm