next up previous contents
Next: References Up: No Title Previous: Beispielmodellierung 2

Fazit

Bleibt nun noch ein abschlie"sendes Res"umee der vorliegenden Arbeit zu ziehen, welche sich mit den F"ahigkeiten des Common Information Models und den Bezug zur "`Rechnernetze Realit"at"' darstellt.

CIM erhebt den Anspruch, eine hohe Plattformunabh"angigkeit zu realisieren. Wohl auch daher sind die meisten bisherig verf"ugbaren Produkte in Java implementiert, was zum einen tats"achlich eine gewisse Plattformunabh"angigkeit garantiert. Brauchbare Produkte sind vor allem auf der Serverseite zu finden; jede betrachtete Implementierung ist f"ur sich durchaus als ausgereift zu bezeichnen, obwohl noch einige Kompatibilit"atsprobleme vorhanden sind. Hier sind zwei Punkte relevant, zum einen Unterschiede bei der CIM-over-HTTP Implementierung, zum anderen bei der Providerimplentierung. Die erfolgten CIM-over-HTTP Implementierungen halten sich im Normalfall an die vorgegebene API; in Einzelf"allen unterscheidet sich jedoch die unterst"utzte Schnittstelle, wenn auch nur um Nuancen. Hingegen verh"alt sich die Sache bei der Providerimplementierung dramatischer. Bei einer Umsetzung eines Projektes ist durchaus damit zu rechnen, dass Providerimplementierungen stark von der verwendeten Plattform abh"angen. Auch m"ussten vorhanden Provider im Falle einer Migration auf einen anderen CIM Object Manager entsprechend angepasst werden, da Providervorlagen prinzipiell je nach Hersteller variieren.

Im Normalfall wird diese Problematik indes so gel"ost, dass auf eine Datenbank festgelegt und das entstehende Produkt daraufhin ausgerichtet wird, also eine vergleichbare Vorgehensweise zu herk"ommlichen Datenbanken.

Ein ganz entscheidender Punkt des Common Information Modell ist die herstellerneutrale Verwaltung heterogener Netzwerke. Diese Eigenschaft ist jedoch nicht ganz umsonst, jedem zu verwaltenden Objekt m"ussen die CIM F"ahigkeiten nachtr"aglich gegeben werden. Dies bedeutet, dass f"ur jedes Betriebssystem und jedes Objekt eigene Routinen zur Verf"ugung gestellt werden m"ussen, welche sich um die Umsetzung in CIM k"ummern. So w"are es beispielsweise w"unschenswert, wenn das betrachtete Objekt gleich selbst solche Routinen mitbringt, um sich beim CIM Object Manager ordnungsgem"a"s anzumelden, was so im realen Leben aber noch nicht der Fall ist.

Auf der Clientseite sieht es dagegen nicht derart rosig aus. Derzeit sind noch keine brauchbaren, auf CIM ausgerichteten Managementwerkzeuge auf dem Markt. In Bezug auf das Rechnernetzepraktikum w"are es sinnvoll, zwei Arten von Clients zu betrachten. Zum einen w"urde ein Client ben"otigt, welcher dem Systemadministrator zur Hand geht, Objekte zu managen und zu verwalten. Diese Managementsoftware sollte eine intuitiv bedienbare, graphische Oberfl"ache bieten. Die derzeitigen Standardl"osungen die CIM zur Datenhaltung verwenden, setzen jedoch noch gro"se Kenntnisse der CIM Modellierung voraus. Die verf"ugbaren, generischen CIM Browser bieten zwar Grundoperationen, die durchaus sinnvoll implementiert sind, jedoch fehlen Funktionen zum bequemen Managen der Objekte. So w"are beispielsweise eine "ubersichtliche Ansicht der Topologie w"unschenswert. Dies ist aber derzeit noch Zukunftsmusik. Auch fehlt die weiteref"uhrende Unterst"utzung aller CIM Object Manager Eigenschaften. So gibt es keinerlei Funktionalit"at, Methodprovider aufzurufen, die Funktion kann bislang nur "uber "`pures"' XML erfolgen. Die Eigenschaften der CIM Object Manager werden derzeit also noch nicht v"ollig ausgesch"opft.

Zum anderen m"ussten Clients automatisch auf Ver"anderung im Topologiesystem zu reagieren. Es ist sinnvoll, diese beiden Gattungen zu unterscheiden, da solche "`Agenten"' auf mehreren Systemen verteilt zum Einsatz kommen und so die Integrit"at des Datenbestands garantieren. Die Datenintegrit"at lie"se sich ebenfalls durch Verwendung von Providern herstellen. Hier w"urde die Datensammlung zentral vom CIM Object Manager gesteuert. Den Providern m"ussten F"ahigkeiten zum entfernten Managen und Abfragen von Komponenten gegeben werden. Im einen Fall w"urde also eine PULL-Operation, im anderen eine PUSH-Operation erfolgen.

Ein Pluspunkt sammelt CIM bei der gelungenen XML Unterst"utzung. Der Pegasus Provider speichert sein CIM Repository in reinem XML, bei WBEMServices und SNIA Cimom ist dies leider nicht der Fall.

Das Common Information Model wurde daraufhin ausgelegt, f"ur m"oglichst alle g"angigen Plattformen verwendbar zu sein. Daher erkl"aren sich auch die umfangreichen Spezifikationen. Der Preis f"ur diese Plattformunabh"angigkeit ist aber eine hohe Komplexit"at bei der Anwendung. Die zweite Beispielmodellierung gibt hier einen leisen Einblick. Es wurde lediglich versucht, einen Netzmanagement Versuch des Rechnernetzepraktikums zu modellieren; dabei wurde bewu"st auf das ITSec Praktikum verzichtet, obwohl hier dieselben Rechner zum Einsatz kommen. Das Resultat sind zahlreiche Instanzen, welche sich in dieser Fassung auf f"unf Seiten erstrecken. Es ist leicht einsichtig, dass dieses Modell als komplex zu erachten ist, zumal die Instanzen dar"uber hinaus beliebig verkn"upft werden k"onnen. CIM gibt hier keine Vorgaben, in welcher Weise die Assoziations- und Aggregationsklassen zu verwenden sind. Die Gefahr, dass sich hier ein Fehler einschleichen k"onnte ist immens.

Betrachtet man hingegen den Aufbau des Rechnernetzepraktikum und ITSicherheitspraktikum, so scheint dieser Aufwand kaum gerechtfertigt. Viele Attribute der verwendeten Instanzen w"urden unbesetzt bleiben, das Potenzial welches CIM bietet, w"urde hier also keinenfalls ausgesch"opft.

F"ur eine Netzwerktopologie dieser Gr"o"se ist das CIM Modell demnach nicht praktikabel. Dar"uberhinaus m"ussten zahlreiche Eigenentwicklungen angefertigt werden, welche dieses Modell umsetzen. Diese beiden Sachverhalte w"urden demnach wohl kaum gerechtfertigten Aufwand verursachen.

Wird eine solche L"osung trotzdem angestrebt, so sind im folgenden die weiteren Schritte n"otig.

W"are das Einfangen von Managementinformationen noch zu bew"altigen, wenn auch mit relativ gro"sem Aufwand, w"urde auf der anderen Seite eine Managementsoftware n"otig, welche die erhaltenen Daten auswertet und geeignet darstellt. Demnach w"urde der zweite Punkt hingegen eine hohe Entwicklungsarbeit fordern. Die Forderungen nach Komfort und Intelligenz der Managementsoftware, die selbst"andig Fehlerf"alle findet und eventuell auch aufl"ost, sind hoch gegriffen.

Die letztliche Folgerung ist, dass die n"achsten Schritte der Hersteller abzuwarten sind, inwieweit ihre Produkte in der n"achsten Zeit CIM Unterst"utzung erhalten. Dies w"are die Voraussetzung daf"ur, dass CIM f"ur den Enduser attraktiv wird.


next up previous contents
Next: References Up: No Title Previous: Beispielmodellierung 2
Emanuel Heidinger
2/5/2004