Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

28.11.1997 - 

Java-basiertes Netz-Management: Suns JMAPI kommt wohl früher

Microsoft bringt die WBEM-Initiative in Verzug

Vor rund 15 Monaten haben BMC Software, Cisco, Compaq, Intel und Microsoft die WBEM-Initiative ins Leben gerufen und erste Produkte für Ende dieses Jahres angekündigt. Seither hat sich die mittlerweile 75 Mitglieder zählende Gruppierung zunehmend zu einer von der Gates-Company geführten Allianz entwickelt. In der Folge wurde das Web-basierte Management auf Microsofts für Mitte nächsten Jahres geplantes Server-Betriebssystem Windows NT 5.0 zugeschnitten. Auf dessen Fertigstellung muß das gesamte Bündnis nun warten.

Daß die Allianz in den ersten Monaten nach der Gründung einen so regen Zulauf verzeichnen konnte, liegt an ihren hochfliegenden Zielen. Microsoft, Cisco, BMC und ihre mittlerweile 72 Verbündeten haben nicht nur die einfache Darstellung von Daten aus der IT-Installation im Browser vor Augen. Vielmehr sollen die unterschiedlichen Management-Verfahren der zahlreichen Hersteller unter einer gemeinsamen Oberfläche zusammengeführt und die heterogenen Daten konsolidiert werden. Da das geplante WBEM-Werkzeug somit an die Funktionsvielfalt verfügbarer Frameworks heranreichen und ihnen Konkurrenz machen würde, ist leicht vorstellbar, daß dies kein einfaches Unterfangen ist. WBEM wird auch als Metaschema bezeichnet, dem ein allgemeingültiges Repository für verschiedene Datentypen zugrunde liegt.

Dieses Herz der WBEM-Anstrengungen ist das Hypermedia Management Schema (HMMS), das auf eine einheitliche Art und Weise die Ressourcen der kompletten IT-Installation beschreibt. Die Allianz legte diesen Vorschlag der Desktop Management Task Force (DMTF) zur Standardisierung vor, die HMMS ausbaute und umbenannte. Das Common Information Model (CIM) ist ein Superset, das Verbindungen zwischen HMMS und Produkten herstellt, die mit der Common Object Request Broker Architecture (Corba), zum Simple Network Management Protocol (SNMP) oder zum Desktop Management Interface (DMI) der DMTF konform sind. Das Ergebnis dieses Vorgangs ist eine Beschreibung der zu verwaltenden IT-Ressourcen und -Vorgänge in nur noch einem Format. Aus logischer Sicht entspricht CIM dem Aufbau einer objektorientierten Datenbank mit wiederverwertbaren Inhalten, die Klassen und Eigenschaften von Ressourcen repräsentieren. Diese Vorgaben sind für Hersteller der zu verwaltenden Komponenten verpflichtend, sie können aber auch Erweiterungen definieren oder vorschlagen.

Die zweite wichtige Komponente des WBEM-Ansatzes ist ein Transportprotokoll, das auf dem Hypertext Transfer Protocol (HTTP) aufsetzt. Das Hypermedia Management Protocol (HMMP) umfaßt das CIM-Modell und bietet demnach auch Schnittstellen zu SNMP und DMI an. Es regelt die Anfragen und Antworten in der Management-Kommunikation, wobei die Gesprächspartner als Client oder Server definiert werden. Je nachdem, ob Anfragen an Stationen weitergeleitet werden, die mehr Informationen als der angesprochene Server vorhalten, können HMMP-Implementierungen auch in die Rolle einer kombinierten Client-Server-Konfiguration schlüpfen.

Die dritte Komponente der Web-basierten Verwaltungsofferte ist der Hypermedia Object Manager (HMOM). Dieses Datenmodell konsolidiert die eingehenden Daten und stellt sie im HTML-Browser dar. Es bildet in zweierlei Hinsicht auch die Schnittstelle zum Anwender: zum einen durch die bereits erwähnte Darstellung am Bildschirm, zum anderen durch die Anpassung der Verwaltungswerkzeuge an ihre konkreten Aufgaben. Das läßt sich über die Entwicklungsplattformen Java, Active X, Common Gateway Interface (CGI), Corba oder Component Object Model (COM) realisieren.

Microsoft und Verbündete reagieren mit ihrer Initiative auf das Verlangen vieler Anwender, System- und vor allem Netz-Ma- nagement-Verfahren unter einer einheitlichen Oberfläche zusammenzuführen. Ähnliche Vorhaben verfolgen zwar auch Computer Assocoiates (CA) mit "Unicenter", Tivoli mit "TME 10", Hewlett-Packard (HP) mit "Openview" und weitere Anbieter, doch vielen Anwendern erscheinen diese Tools als zu mächtig, zu komplex und zu teuer. Außerdem werden sie als Werkzeugsammlung angesehen, die zwar Namen, Kommunikationsinfrastruktur und Datenbank teilen, jedoch keine wirklich einheitliche Lösung bilden. Vor allem bei der Anpassung an die Aufgaben im eigenen Netz beziehungsweise die Wünsche der eigenen Kundschaft stoßen Anwender und Dritthersteller, die Werkzeuge für die genannten Management-Plattformen entwickeln, auf Schwierigkeiten, da CA, HP und Tivoli zwar offene, aber proprietäre Programmier-Schnittstellen unterstützen. Daher wird immer häufiger der Ruf nach Java-APIs als kleinstem gemeinsamen Nenner laut.

WBEM spaltet die Gemeinde, die in Browser-und Web-basiertem Management eine große Zukunftschance sieht, denn es konkurriert mit dem "Java Management Application Programming Interface" (JMAPI) von Sun Microsystems, und beide Parteien zeigen bisher keine Neigung, die unterschiedlichen Bestrebungen zusammenzuführen. Das wäre laut Sun mittlerweile auch schlecht möglich, den HMMP und JMAPI vertragen sich etwa in der Darstellung und den Datenformaten nicht. Sun verzichtet im Unterschied zu den WBEM-Aktivisten außerdem auf die Entwicklung eines neuen Datenbankmodells und auf die HTTP-Erweiterung. Der Anbieter beschränkt sich auf die Definition von Application Programming Interfaces (APIs), Java-Klassen und Modulen zur Darstellung der Management-Daten.

Zu den Spezifikationen zählen etwa das "Admin View Module" (AVM) zur Entwicklung eines User Interface oder Schnittstellen, mit denen Protokolle, Datenbanken und verteilte Ressourcen beschrieben werden. Diese Definitionen sind vor allem für die Anbieter von System-Management-Lösungen von Bedeutung, denn sie müssen ihre Angebote auf JMAPI zuschneiden, so daß Ergebnisse im Browser angezeigt oder Aktionen von der Java- basierten Konsole gestartet werden können. Kommen auf Anwenderseite dagegen JMAPI-kompatible Lösungen zum Einsatz, steht dem Administrator eine Umgebung zur Verfügung, die unabhängig von der verwendeten System-Management-Plattform und den Verwaltungs-Tools mit einem Java-Entwicklungswerkzeug an die eigene IT-Installation anzupassen ist. Während WBEM aufgrund seiner Komplexität noch einige Zeit benötigt, um auszureifen, trauen Fachleute der Sun-Implementierung eine schnellere Umsetzung zu, denn die Definition ist weit fortgeschritten. JMAPI hat zudem den Rückhalt wichtiger Anbieter wie Tivoli, CA, IBM und Novell und kann auf die Popularität und die Verbreitung von Java bauen.

Ende der Glaubenskriege?

Eine weitere Hürde, die WBEM, nicht aber JMAPI nehmen muß, ist die Standardisierung. Die WBEM-Partner haben das Kommunikationsprotokoll HMMP der Internet Engineering Task Force (IETF) als Vorschlag unterbreitet. Branchenkenner rechnen aufgrund der breiten Unterstützung des Verfahrens mit einem positiven Bescheid durch das Standardisierungskomitee.

Den Vorteilen des Web-basierten Managements wie etwa der Plattformunabhängigkeit, dem Fernzugriff via Browser oder der kostengünstigen Implementierung steht die mangelnde Funktionsvielfalt gegenüber. JMAPI wie auch WBEM können jeweils nur den kleinsten gemeinsamen Nenner für alle Verwaltungsfunktionen darstellen, so daß einige liebgewonnene Merkmale auf der Strecke bleiben werden. Im Vergleich zum weitverbreiteten SNMP zeigen die an Internet-Technologien angelehnten Verfahren etwa Beschränkungen bei der Konfiguration sowie bei Änderungen von Netz- und Systemkomponenten in Echtzeit. Erfüllen die Initiatoren ihre Versprechen, könnte sich jedoch ein Ende der Glaubenskriege zwischen den Herstellern anbahnen, die mit ihren unterschiedlichen Schnittellen die Programmierung von Zusatzkomponenten erschweren. Den Anwendern wäre geholfen, weil sie nur noch Know-how für standardisierte Übergänge zu den Management-Plattformen vorhalten müßten.