next up previous contents
Next: A Konvertieren von MOF- Up: No Title Previous: Wichtiger Hinweis:

10 Zusammenfassung und Ausblick

 

Das Gebiet des Web-Based Management ist noch relativ neu. Einige Hersteller bieten für das Komponentenmanagement bereits seit einiger Zeit den Zugang über eine Web-Schnittstelle an (vgl. [Lor98]). Ein allgemeiner Rahmen für die Entwicklung von Software im Bereich des Web-basierten Netz-, System- und Anwendungsmanagements existiert jedoch noch nicht.

Mit JMAPI unternehmen Sun Microsystems und JavaSoft den Versuch, mittels eines Java-basierten Frameworks diese Lücke zu füllen. Die Plattformunabhängigkeit von Java in Verbindung mit der Fähigkeit des dynamischen Ladens ausführbaren Codes über das Netz lassen die Verwendung von Java als Basis verteilter Managementanwendungen als vorteilhaft erscheinen.

In dieser Diplomarbeit wurde die Eignung von JMAPI im Hinblick auf Einsatzmöglichkeiten für das integrierte Management untersucht. Die Bewertung stützte sich auf die vier Teilmodelle des Managements, das Informationsmodell, Organisationsmodell, Kommunikationsmodell und das Funktionsmodell.

Das Informationsmodell von JMAPI basiert auf dem Common Information Model der DMTF. Die Verwendung dieses herstellerübergreifenden Standards, dem ein objektorientierter Ansatz zugrundeliegt und der im Hinblick auf die Integration anderer Informationsmodelle wie SNMP oder DMI entwickelt wurde, erleichtert die Integration anderer Managementarchitekturen. Im Rahmen der Diplomarbeit wurde mittels einer Reihe von Perl-Skripten eine Möglichkeit erarbeitet, eine CIM-Beschreibung von Objektklassen im Managed Object Format (MOF) in eine JMAPI-konforme Beschreibung zu transformieren und somit für JMAPI nutzbar zu machen. Ferner wurde für die Konstruktion von Gateways gezeigt, wie sich CIM-Associations auf den Topology Service der OMG abbilden lassen.

Das Organisationsmodell unterscheidet die drei Rollen Client, Managed Object Server und Agent. Der MO Server bildet die zentrale Komponente der Architektur, und beinhaltet eine Datenbank sowie einen Web Server. Er agiert als Bindeglied zwischen den Client-Applets und den Agenten, die die eigentliche Management-Funktionalität implementieren. Das Vorhandensein einer zentralen Komponente erleichtert einerseits die Wartung, ist andererseits jedoch im Hinblick auf Skalierbarkeit und Fehlertoleranz mit Nachteilen verbunden. Hinsichtlich der Integration anderer Managementarchitekturen ist insbesondere die Frage nach der möglichen Einbeziehung von JMAPI-fremden Agenten von Bedeutung. Im Rahmen dieser Arbeit wurde speziell der Einsatz von CORBA-Agenten und von Agenten, die mit dem ebenfalls von Sun Microsystems entwickelten Java Dynamic Management Kit (JDMK) entwickelt wurden, untersucht. Als Ergebnis läßt sich festhalten, daß für das Ziel der Oberflächenintegration eine Einbeziehung von Fremdagenten zwar sinnvoll und möglich ist, daß andererseits jedoch im Falle von Fremdagenten ein Teil der von JMAPI bereitgestellten Funktionalität nicht genutzt werden kann. So kann z. B. der in JMAPI integrierte Transaktionsmechanismus für die Mehrbenutzersynchronisation nicht mehr eingesetzt werden. In diesem Fall kann es dann u.U. zu Inkonsistenzen zwischen dem Zustand der MOs auf dem Server und den Agenten kommen. Ein weiteres Beispiel nicht-nutzbarer Funktionalität im Falle von JMAPI-fremden Agenten ist die mangelnde Fähigkeit, automatische Versions-Updates der Agenten-Software durchzuführen. Ferner ist das von JMAPI vorausgesetzte Organisationsmodell nicht für alle Agenten sinnvoll. Beispielsweise widerspricht der zentralisierte Managementansatz von JMAPI dem Konzept weitgehend autonomer Agenten, das der JDMK-Architektur zugrundeliegt. Als Beispiel zur Oberflächenintegration wurde im Rahmen dieser Diplomarbeit für einen am Lehrstuhl vorhandenen CORBA-Agenten eine JMAPI-konforme Oberfläche erstellt.

Das JMAPI-Kommunikationsmodell führt kein neues Kommunikationsprotokoll ein. Es kommt im wesentlichen Java RMI zum Einsatz. Alternativ können für die Kommunikation des MO Servers mit den Agenten auch andere Kommunikationsprotokolle, wie CORBA IIOP oder SNMP verwendet werden. Die Verwendung von RMI hat den zusätzlichen Vorteil, daß der im RMI integrierte Sicherheitsmechanismus genutzt werden kann.

Das Funktionsmodell findet bei JMAPI keinerlei Ausprägung.


Für zukünftige Versionen von JMAPI sind folgende Entwicklungen zu erwarten:


Wünschenswert wären vor allem folgende Erweiterungen:

Die JMAPI-Spezifikation durchläuft zur Zeit noch den JavaSoft-Software-Review-Prozeß, der einer Veröffentlichung vorausgeht. Nach Informationen von der JMAPI-Mailing-Liste [Mai] ist die Spezifikation noch im Sommer 1998 zu erwarten (vgl. Anhang E). Zu diesem Zeitpunkt ist vermutlich auch mit einer neuen Version der Referenzimplementierung zu rechnen. Mit dem Erscheinen der Spezifikation sollte es möglich sein, einige der noch offenen Fragen, vor allem im Zusammenhang mit dem Einsatz mehrerer Managed Object Server, zu beantworten.


next up previous contents
Next: A Konvertieren von MOF- Up: No Title Previous: Wichtiger Hinweis:
Copyright Munich Network Management Team