DE69830285T2

DE69830285T2 - Auf Beans basiertes Verwaltungssystem

Info

Publication number: DE69830285T2
Application number: DE69830285T
Authority: DE
Inventors: Osman Abdoul Ismael; Serge Andre Rigori
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1997-10-06
Filing date: 1998-09-24
Publication date: 2006-02-02
Anticipated expiration: 2018-09-25
Also published as: EP0909057A3; EP0909057B1; EP0909057A2; US6061721A; JPH11234276A; CA2249780A1; DE69830285D1

Description

HINTERGRUND DER ERFINDUNG
Die Erfindung bezieht sich auf Netzmanagement- bzw. Netzverwaltungssysteme und im besonderen auf das Erstellen bzw. Erzeugen eines Netzmodels für ein solches System.
Netzmanagementsysteme (auch Netzwerkverwaltungssyteme genannt) finden Anwendung beim Fern-Management von Systemen über ein Telekommunikationssystem. Es sind Netzmanagementsysteme bekannt, die das Manipulieren und Steuern einer großen Anzahl und Vielfalt von Objekten über ein Netz gemäß einem relativ beschränkten Satz von Kommandos einschließlich Operationen wie GET, SET, ACTION, CREATE und DELETE erlauben. Ein Beispiel eines solchen Netzmanagementsystems ist die sogenannte Telekommunikations-Management-Netz-(TMN)-Umgebung.
Die TMN-Umgebung stellt ein Common Management Information Protocol (CMIP) nach Industriestandard bereit und unterstützt Common Management Information Services (CMIS) gemäß X.710/ISO 9595 unter diesem Protokoll. Diese Dienste bzw. Services ermöglichen die Manipulation einer großen Anzahl und Vielfalt von Objekten über ein Netz gemäß einem relativ beschränkten Satz von Kommandos einschließlich Operationen wie GET, SET, ACTION, CREATE und DELETE.
Die physikalische Konfiguration des Netzes (in den Ansprüchen auch als „Netzwerk" bezeichnet), auf dem das Netzmanagementsystem eingerichtet ist, kann viele verschiedene Formen annehmen, einschließlich zum Beispiel die eines öffentlichen vermittelten Telefonnetzes und/oder eines lokalen Netzes und/oder eines fest zugeordneten Netzes, das Computer und andere Einrichtungen innerhalb eines lokalen Netzes und/oder über einen weiteren Bereich verbindet, oder ein offenes Netz wie das Internet oder ein Intranet. Die Objekte umfassen typischerweise Parameter und Methoden, die verwendet werden, um ein Teil der Ausrüstung, eine Komponente dieser Ausrüstung, eine Operation der Ausrüstung oder einer Komponente davon zu modellieren, usw.
Eine Schwierigkeit mit existierenden Netzmanagementsystemen bezieht sich auf das Erstellen eines Netzmodells. Zum Beispiel werden in der TMN-Umgebung Objekte gemäß Guidelines for Definition of Managed Objects (GDMO) nach Industriestandard X.722/ISO-10165-4 definiert. GDMO definiert Daten- oder Parameter-Typen gemäß X.208/ISO-8824 Abstract Syntax Notation One (ASN.1) und X.209/ISO-8825 Specification of Basic Encoding Rules for Abstract Notation One (BER) für die Datennotation. Diese verschiedenen Industriestandards werden von der International Standards Organisation (ISO) definiert.
GDMO ist eine formale Beschreibungssprache, die nicht direkt von einem Computer verstanden wird. Es ist daher notwendig, GDMO in ein computer-verständliches Format zu konvertieren. Da es keinen Standard für einen solchen Prozeß gibt, führt dies häufig zu mehrfachen Interpretationen, die ihrerseits zu Interoperabilitätsproblemen führen.
Um CMIS aufzurufen, ist es nötig, die Anwendungsprogrammschnittstelle (Application Programming Interface, API) einer Implementierung zu erzeugen. Typischerweise wurden APIs mittels Programmiersprachen wie C oder C++ kreiert. Obwohl die verschiedenen Standards vorhanden sind, ist diese Phase sehr aufwendig und potentiell gefährlich. Eine erhebliche Beteiligung von Programmierem ist nötig, um die APIs zu kreieren. Abgesehen von den Kosten besteht außerdem das Problem der Zuverlässigkeit und Verifikation der resultierenden APIs. Ein weiteres Problem, das von der Mischung eines programmbasierten API für die ASN.1- und GDMO-Standards herrührt, sind die Schwierigkeiten, auf die man stößt, wenn es einen Bedarf gibt, die Netzdienste zu erweitern, zum Beispiel indem neue Typen und Instanzen von Objekten (z. B. ein neuer Typ von Workstation für einen Netzmanager) definiert werden. Mit anderen Worten ist der herkömmliche Ansatz, ein API bereitzustellen, in einer dynamischen Netzmanagement-Umgebung problematisch.
Ein allgemeines Ziel der Erfindung ist es, einen verbesserten Ansatz für die Entwicklung einer flexibleren Netzmanagement-Umgebung bereitzustellen.
Ein Artikel mit dem Titel 'A Toolkit for Developing TMN Manager/Agent Applications' von Speaker R A, Hewlett-Packard Journal, Band 47, Nr. 5, 1. Oktober 1996, Seiten 52–61, beschreibt einen Werkzeugsatz für das Entwickeln von Telekommunikations-Management-Netz-(TMN)-Manager/Agent-Anwendungen. Dieses Dokument lehrt speziell, daß Spezifikationen von Managed-Object-Klassen nach GDMO verwendet werden sollten, wenn eine Agenten-Anwendung entwickelt wird.
Sun Microsystems, 'JAVABEANS specification' (Version 1.01), 24. Juli 1997, beschreibt die JavaBeans-API-Spezifikation. Die Eigenschaften von JavaBeans wie die Bereitstellung von Unterstützung für, unter anderem, Selbstprüfung, Ereignisse und kundenspezifische Anpassung sind in Abschnitt 2.1 dieses Dokuments dargelegt.
ZUSAMMENFASSUNG DER ERFINDUNG
Spezielle und bevorzugte Aspekte der Erfindung sind in den beigefügten unabhängigen und abhängigen Ansprüchen dargelegt.
Gemäß einem ersten Aspekt der Erfindung wird ein Computer-implementiertes Verfahren zum Erzeugen eines Computernetzmanagementsystems bereitgestellt, das die Schritte aufweist:

a) Definieren eines Netzmanagement-Modells einschließlich mindestens einer Management-Bean unter Verwendung einer Bean-basierten Umgebung, wobei die mindestens eine Management-Bean betreibbar ist, daß es Unterstützung für eine Selbstprüfung bietet, um die externe Analyse der Zusammensetzung dieser mindestens einen Management-Bean zu ermöglichen, und wobei die mindestens eine Management-Bean so ausgelegt ist, daß sie über eine graphische Benutzerschnittstelle eines Builder-Tools bzw. Aufbauwerkzeuges und durch Selbstprüfung dieser mindestens einen Management-Bean visuell manipuliert werden kann; und
b) Kompilieren des Modells, um das Computernetzmanagementsystem in der Bean-basierten Umgebung zu implementieren.

Durch Definieren eines Modells in einer Bean-basierten Umgebung ist es möglich, das Bean-basierte Modell direkt zu kompilieren, um eine Bean-basierte Implementierung mittels eines Standard-Compilers für die Bean-basierte Umgebung zu bilden.
In einer bevorzugten Ausführungsform der Erfindung sind die Management-Beans Java-Beans-Komponenten (JavaBeans ist eine Handelsmarke von Sun Microsystems Inc.). Beans sind wiederverwendbare Softwarekomponenten, die visuell in einem Builder-Tool (z. B. einem Editor oder Graphischen Benutzerschnittstellen-Builder (GUI-Builder)) manipuliert werden können. Ein Beispiel eines Builder-Tools ist das JavaBeans Development Kit. Weitere Einzelheiten über Beans können in vielen verschiedenen Werken gefunden werden, zum Beispiel in einem Buch mit dem Titel "Mastering JavaBeans" von Lawrence Vanhelsuwé, veröffentlicht von Sybex (ISBN 0-7821-2097-0). Dies ist gerade einmal ein Beispiel von vielen im Großen und Ganzen äquivalenten Büchern am Markt, die "JavaBeans" im Titel haben und die JavaBeans beschreiben. Viele dieser Werke einschließlich des Buches "Mastering JavaBeans" liefern das oben erwähnte Bean Development Kit mit.
Beans variieren in ihrer Funktionalität, aber sie haben typischerweise bestimmte definierende Charakteristika gemeinsam, die einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und für Selbstprüfung, auch bekannt als Reflexion, bereitstellen. Die Eigenschaften ermöglichen es, daß Beans programmtechnisch manipuliert werden, und unterstützen die kundenspezifische Anpassung der Bean. Die Methoden implementieren die Eigenschaften. Die Unterstützung für Ereignisse setzt Beans in die Lage, Ereignisse auszulösen und definieren die Ereignisse, die ausgelöst werden können. Die Unterstützung für Selbstprüfung ermöglicht es, daß die Eigenschaften, Ereignisse und Methoden der Bean von außerhalb inspiziert werden können.
Die vorliegende Erfindung beruht auf der erstmaligen Erkenntnis, daß Beans ein Vehikel zum Modellieren von Ressourcen, die zu verwalten sind, bereitstellen.
Zum Beispiel kann Schritt (a) das Definieren mindestens einer Eigenschaft in einer Management-Bean zum Modellieren einer Eigenschaft einer verwalteten Ressource aufweisen (z. B. ein Ressourcen-Attribut wie die Größe eines Speichers, die Anzahl von empfangenen Nachrichten in einem Puffer, etc.). Er kann ebenfalls das Definieren mindestens einer Methode für eine Management-Bean zum Modellieren einer Aktion einer verwalteten Ressource aufweisen (z. B. eines Zurücksetzens des Systems). Er kann auch das Definieren von Unterstützung für mindestens ein Ereignis (zum Beispiel ein Ereignis "Platte voll") für eine verwaltete Ressource beinhalten. Zu diesem Zweck kann die Management-Bean Unterstützung für ein Horcher-Ereignis vorsehen, wodurch eine Management-Bean auf ein Ereignis an einer anderen Management-Bean reagieren kann.
Eine Management-Bean bietet Unterstützung für Selbstprüfung, die externe Analyse der Zusammensetzung der Bean und den Austausch von Information zwischen Beans erlaubt.
Daher können Management-Beans Definitionen von Beziehungen und Interaktionen zwischen Management-Beans als Repräsentanten der Beziehungen und Interaktionen zwischen den verwalteten Ressourcen beinhalten.
In einer bevorzugten Ausführungsform der Erfindung weist Schritt (b) auf:

i) Registrieren mindestens einer Management-Bean bei einem erweiterbaren Agenten-Bezugssystem;
ii) Registrieren mindestens eines Netzadapters für ein Netzkommunikationsprotokoll bei dem erweiterbaren Agenten-Bezugssystem; und
iii) Ermöglichen von externem Zugriff über das Netz auf mindestens eine Management-Bean über mindestens einen Netzadapter.

Das US-Patent 5.315.703 und das US-Patent 5.367.633 beschreiben Objekt-basierte Systeme, die ein Bezugssystem beinhalten, um Funktionen über Änderungsnachrichten zu erlauben. Diese Patente beschreiben jedoch eigenständige Systeme.
Vorzugsweise weist das erweiterbare Agenten-Bezugssystem eine zugeordnete Speicher-Bean auf und Schritt (b)(ii) weist das Registrieren mindestens einer Management-Bean und/oder mindestens eines Netzadapters bei der Speicher-Bean auf.
Der Netzadapter kann von einer Netzadapter-Bean gebildet werden.
Gemäß einem anderen Aspekt der Erfindung wird ein Computernetzmanagementsystem bereitgestellt, das aufweist:
eine Objekt-orientierte Netzmanagement-Modellierungs-Umgebung einschließlich mindestens einer Management-Bean, wobei die mindestens eine Management-Bean einer Ressource entspricht, die von einem Agenten gesteuert und überwacht wird, wobei die mindestens eine Management-Bean so betreibbar ist, daß sie Unterstützung zur Selbstprüfung vorsieht, um externe Analyse der Zusammensetzung der mindestens einen Management-Bean zu erlauben;
ein Builder-Tool zum visuellen Manipulieren der mindestens einen Management-Bean durch eine graphische Benutzerschnittstelle, wobei beim visuellen Manipulieren der mindestens einen Management-Bean das Builder-Tool darauf ausgelegt ist, externe Analyse der Zusammensetzung der mindestens einen Management-Bean durch Selbstprüfung der mindestens einen Management-Bean durchzuführen; und
einen Compiler für die Objekt-basierte Umgebung zum Erzeugen der Implementierung des Computernetzmanagementsystems in der Objekt-basierten Umgebung.
Weitere Ausführungsformen gemäß der vorliegenden Erfindung sind in den abhängigen Ansprüchen 2–9, 11 und 13–19 definiert.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Beispielhafte Ausführungsformen der vorliegenden Erfindung werden nachfolgend nur als Beispiel beschrieben unter Bezugnahme auf die beigefügten Zeichnungen, in denen sich gleiche Referenzbezeichnungen auf gleiche Elemente beziehen und in denen:
1 eine schematische Darstellung von drei Stationen ist, die über ein Telekommunikationsnetz verbunden sind;
2 und 2A eine schematische Darstellung eines Computer-Servers für eine Station von 1 bilden;
3 eine schematische Darstellung eines Agenten für eine verwaltete Station ist;
4 eine alternative Darstellung des Agenten von 3 ist;
5 ein Beispiel einer Konfiguration für einen Agenten ist;
6 ein Flußdiagramm ist, das Operationen mittels eines Agenten wie in 5 abgebildet veranschaulicht:
7 ein Beispiel einer Konfiguration eines Managementsystems ist;
8 ein anderes Beispiel einer Konfiguration eines Managementsystems ist;
9 einen Aspekt des Kreierens der Konfiguration von 8 veranschaulicht;
10 ein Flußdiagramm ist, das Operationen des Systems von 8 veranschaulicht;
11 ein Flußdiagramm ist, das die Operationen eines Namensdienstes veranschaulicht;
12 ein Flußdiagramm ist, das die Operation des Kreierens eines generischen Agenten veranschaulicht;
13 und 14 alternative Operationen eines Compilers veranschaulichen;
15A und 15B verwendet werden, um den Effekt des Kompilierens einer Management-Bean zu veranschaulichen;
16A und 16B auch verwendet werden, um den Effekt des Kompilierens einer Management-Bean zu veranschaulichen; und
17 ein Flußdiagramm ist, das Schritte beim Erzeugen eines Managementsystems veranschaulicht.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
1 ist eine schematische Darstellung eines netzbasierten Mehrstations-Systems 1 mit drei Stationen oder Knoten oder Maschinen 3, 4 und 5, die über ein Netz 2 verbunden sind. Das Netz 2 kann auf einem öffentlichen vermittelten Telefonnetz und/oder einem lokalen Netz und/oder einem fest zugeordneten Netz, das Computer und andere Einrichtungen innerhalb eines lokalen Bereiches und/oder über einen weiteren Bereich und/oder ein offenes Netz wie das Internet oder ein Intranet oder Kombinationen davon verbindet, oder tatsächlich auch auf jeder anderen Art von Telekommunikationsnetz basieren, das den Austausch von Telekommunikationsmanagementinformatation unterstützt. Das Netz kann jede gewünschte Struktur haben wie eine Schicht- bzw. Lagenstruktur, eine pyramidenförmige Hierarchie, etc.
Jede einzelne oder mehrere der Stationen 3, 4 oder 5 können als eine Netzmanagementstation ausgelegt sein. In dem in 1 gezeigten Beispiel wird angenommen, daß Station 3 eine Managementstation ist, und die Stationen 4 und 5 verwaltete Stationen sind. Man sieht, daß jede Anzahl von Managementstationen und verwalteten Stationen vorgesehen sein kann und daß die drei Stationen von 1 nur veranschaulichenden Zwecken dienen. Auch könnten die verwaltenden und verwalteten Funktionen vertauscht sein oder es könnten tatsächlich sowohl die verwaltenden als auch die verwalteten Funktionen auf ein und derselben Station unterstützt werden.
Die Stationen können viele Formen annehmen. Zum Zweck der Veranschaulichung wird angenommen, daß beide Computer-Workstations aufweisen. 2 ist eine schematische Darstellung der Konfiguration einer Computer-Workstation. Wie in 2 dargestellt, wird diese von einem Ser ver-Computer 10 implementiert, der eine Systemeinheit 11 mit einer Anzeige 8, eine Tastatur und andere Eingabeeinrichtungen 9 aufweist. 2A ist eine schematische Darstellung als Blockdiagramm von Aspekten des Inhalts der Systemeinheit 11. Wie in 2A dargestellt, beinhaltet die Systemeinheit einen Prozessor 17, einen Speicher 18, magnetische und/oder optische Plattenlaufwerke 13 und 14 und einen Kommunikationsadapter 16 zur Verbindung mit einem oder mehreren Telekommunikationsleitungen 15 zur Verbindung mit dem Telekommunikationsnetz 2. Wie in 2A dargestellt sind die Komponenten der Systemeinheit über eine Busanordnung 19 verbunden. Man erkennt, daß die 2/2A eine allgemeine schematische Darstellung einer möglichen Konfiguration für einen Server-Computer zum Bilden eines Routers sind. Es ist klar, daß viele alternative Konfigurationen bereitgestellt werden könnten.
Wenn die Workstation eine Management-Station implementiert, werden typischerweise eine Management-Anwendung oder -Anwendungen und Schnittstellen-Strukturen durch Software bereitgestellt, die in dem Speicher der Workstation gespeichert ist und von dem Prozessor der Workstation ausgeführt wird.
Wenn die Workstation eine verwaltete Station implementiert, reagiert ein Agent auf entfernt von den Management-Anwendungen über das Netzwerk abgesetzte Management-Anforderungen, um eine Schnittstelle zu den verwalteten Objekten auf den verwalteten Stationen zur Verfügung zu stellen. Der Agent und die verwalteten Objekt-Strukturen werden typischerweise durch Software bereitgestellt, die in dem Speicher der Workstation gespeichert ist und von dem Prozessor der Workstation ausgeführt wird.
Die Objekte weisen typischerweise Parameter und Methoden auf, die verwendet werden, um einen Teil der Ausrüstung, eine Komponente dieser Ausrüstung, eine Operation bzw. Betriebsweise der Ausrüstung oder eine Komponente oder Ressource davon etc. zu modellieren.
Das Management eines Telekommunikationsnetzes erfordert Anwendungen verschiedener Größen und Komplexität. Große Manager, mittlere Manager, erweiterbare Agenten, intelligente Agenten und Einrichtungen spielen alle eine Rolle beim Management eines Telekommunikationsnetzes. Ein Netzmanagementsystem, das die vorliegende Erfindung umfaßt, sieht ein erweiterbares Agentensystem vor, das es erlaubt, alle diese unterschiedlichen Anwendungstypen auf derselben Architektur zu errichten. Dieses erweiterbare Agentensystem wird von einer Komponente des Netzmanagementsystems vorgesehen. Alternative Begriffe für das erweiterbare Agentensystem in diesem Kontext könnten ein "dynamisches Bezugssystem" oder "offenes Bezugssystem" oder "Laufzeitkomponente" sein, wenngleich hier die Begriffe "Bezugssystem" oder "erweiterbares Agentensystem" verwendet werden.
Das Netzmanagementsystem ist mit einem Satz von Kernmanagementdiensten ausgestattet. Eine Auswahl kann aus diesem Satz von Diensten getroffen werden, und er kann erweitert werden, um spezielle Anwendungen zu entwickeln. Verschiedene Dienste sind statisch oder dynamisch in das Bezugssystem geladen, um die Anforderungen einer bestimmten Anwendung zu erfüllen.
Ein verwaltetes Objekt in einem Beispiel eines Netzagenten, der die vorliegende Erfindung umfasst, ist vorzugsweise als eine Bean, noch besser als eine JavaBeans-Komponente implemen tiert. Eine Bean (und eine JavaBeans-Komponente) ist eine wiederverwendbare Software-Komponente, die visuell in einem Builder-Tool (z. B. einem Editor oder graphischen Benutzerschnittstellen-Builder (GUI-Builder)) manipuliert werden kann. Ein Beispiel eines Builder-Tools ist das JavaBeans Development Kit. Beans variieren in ihrer Funktionalität, aber sie haben typischerweise bestimmte definierende charakteristische Merkmale gemeinsam, die einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und Selbstprüfung bereitstellen. Die Eigenschaften erlauben es, daß Beans programmtechnisch manipuliert werden und unterstützen kundenspezifische Anpassung der Bean. Die Methoden implementieren die Eigenschaften. Die Unterstützung von Ereignissen setzt Beans in die Lage, Ereignisse zu aktivieren bzw. auszulösen und definieren Ereignisse, die ausgelöst werden können. Die Unterstützung zur Selbstprüfung ermöglicht, daß Eigenschaften, Ereignisse und Methoden der Bean von außerhalb inspiziert werden können. Operationen wie GET, SET, ACTION, CREATE und DELETE können unterstützt werden.
Ein verwaltetes Objekt in dem Agenten ist verwaltbar, sobald es bei dem Bezugssystem registriert ist. Diese Vereinbarung erlaubt es, daß ein gemäß diesem Netzmanagementsystem entwickelter Agent mit geringem Einfluß auf das Design des Agenten verwaltbar ist.
Wie oben angegeben verwendet ein Beispiel des Netzmanagementsystems das JavaBeans-Komponentenmodell, wodurch die Entwicklung von Anwendungen erleichtert wird. In diesem Beispiel werden alle Kernmanagementdienste als JavaBeans-Komponenten bereitgestellt. Daher kann Zugriff auf sie mittels eines Java-Anwendungs-Builders wie durch das wohlbekannte JavaBeans Development Kit erlangt werden. Verwaltete Objekte werden als JavaBeans-Komponenten entwickelt. Auf eine JavaBeans-Komponente in dem Agenten des Netzmanagementsystems kann aus der Ferne oder lokal zugegriffen werden. Das bedeutet, daß es beim Entwickeln von verwalteten Objekten in dem Netzmanagementsystem nicht nötig ist zu wissen, über welches Kommunikationsprotokoll auf das verwaltete Objekt zugegriffen wird.
Das Netzmanagementsystem vereinfacht die Entwicklung von erweiterbaren Agenten. Ein Satz von Kernmanagementdiensten, den das Netzmanagementsystem bereitstellt, kann erweitert und in einen Agenten geladen werden, während er ausgeführt wird. Das bedeutet, daß ein mittels des Netzmanagementsystems entwickelter Agent nur den Dienst zu implementieren braucht, den er verwendet. Dieses Charakteristikum ermöglicht die Entwicklung von Agenten verschiedener Größen und Komplexität.
Agenten, die mittels des Netzmanagementsystems entwickelt wurden, sind auch intelligente Agenten. Ein intelligenter Agent stellt die Dienste bereit, die benötigt werden, um Managementanforderungen zu verarbeiten. In einem intelligenten Agenten kann viel von der Verarbeitung lokal in dem Agenten selbst vorgenommen werden, wodurch die Last auf der Netzverbindung zwischen dem Agenten und dem verwaltenden System verringert wird.
3 stellt einen Aspekt der Architektur eines Agenten des Netzmanagementsystems einschließlich der Beziehungen zwischen den Komponenten des Netzmanagementsystems dar. 3 zeigt auch die Beziehung zwischen dem Agenten des Netzmanagementsystems und Managementanwendungen.
Wie in 3 abgebildet besteht der Agent des Netzmanagementsystems aus einer Reihe von Komponenten innerhalb einer Java Virtual Machine (VM). Diese umfassen:

– M-Beans 29;
– das Bezugssystem 24;
– Kernmanagementdienste 25, 26, 27, 28;
– Adapterserver für verwaltete Objekte 30, 32, 34, 36 und 38.

Diese Komponenten werden unten genauer beschrieben.
Ein verwaltetes Objekt ist eine Software-Abstraktion einer Ressource, die von einem Agenten gesteuert und überwacht wird. Ein verwaltetes Objekt (z. B. 28) wird als eine Management-Bean oder M-Bean bezeichnet. In einem Beispiel des Netzmanagementsystems sind alle M-Beans als JavaBeans-Komponenten implementiert. Daher kann auf diese mittels eines herkömmlichen Java-Anwendungs-Builders wie dem zuvor erwähnten JavaBeans Development Kit zugegriffen werden.
Wie für jedes andere verwaltete Objekt hat eine M-Bean einen Satz von Eigenschaften, kann einen Satz von Aktionen durchführen und kann einen Satz von Benachrichtigungen oder Ereignissen aussenden. Das Netzmanagementsystem ermöglicht es, zwischen einer nur-lesbaren und einer Schreib-Lese-Eigenschaft in einer M-Bean zu unterscheiden.
Eine M-Bean ist verwaltbar, sobald sie bei dem Bezugssystem 24 registriert ist. Wenn eine M-Bean registriert wird, wird ihr ein Objektname zugeordnet. Der Objektname identifiziert die M-Bean eindeutig innerhalb des M-Bean-Speichers (siehe unten). Er ermöglicht einer Managementanwendung, die M-Bean, auf der sie eine Managementoperation durchführen will, zu identifizieren. Der Objektname einer M-Bean ist ein beliebiger Name, der nicht in irgendeiner Weise davon abhängt, wie die M-Bean implementiert ist.
Das Bezugssystem 24 steuert die Managementdienste, und M-Beans eines Agenten 20 werden in das Bezugssystem 24 geladen. Das Bezugssystem oder die Laufzeitkomponente 24 ist eine JavaBeans-Komponente, die einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und Selbstprüfung aufweist. Die Eigenschaften beinhalten Eigenschaften zum Holen und Setzen. Die Methoden umfassen Methoden zum Implementieren der Eigenschaften zum Holen und Setzen. Das Bezugssystem ist auch in der Lage, Funktionen zum Hinzufügen und Entfernen von Objekten zu bewirken.
Wann immer ein Agent 20 aufgefordert wird, eine durch einen Netzadapter empfangene Managementoperation durchzuführen, ruft das Bezugssystem 24 den passenden Dienst auf, um die angeforderte Operation durchzuführen. Das Bezugssystem 24 behandelt auch die Kommunikation zwischen M-Beans 28 und den Adapterservern für verwaltete Objekte 30–38. Eine M-Bean kann bei dem Bezugssystem 24 anfragen, um Information über andere M-Beans 28 zu erhalten, die in dieselbe Instanz des Bezugssystems 24 geladen sind. Nur eine Instanz des Bezugssystems 24 darf in einer virtuellen Maschine 22 sein.
Das Netzmanagementsystem stellt eine Reihe von Kernmanagementdiensten bereit. In einem Beispiel des Systems sind die Kernmanagementdienste als Java-Schnittstellen definiert. Die Kernmanagementdienste sind optional. Das bedeutet, daß ein mittels des Netzmanagementsystems entwickelter Agent nur die Dienste zu implementieren braucht, die er benutzt. Die Kernmanagementdienste können als M-Beans registriert werden, was ermöglicht, daß einige Managementoperationen auf ihnen durchgeführt werden können, um ihr Verhalten abzustimmen bzw. anzupassen.
In dem bevorzugten Beispiel des Systems werden die Kernmanagementdienste als Java-Beans-Komponenten bereitgestellt. Es ist daher möglich, auf sie mittels eines konventionellen Java-Anwendungs-Builders wie dem zuvor erwähnten JavaBeans Development Kit zuzugreifen.
Eine Reihe von Kernmanagementdiensten soll nun beschrieben werden.
Der M-Bean-Speicherdienst 27 erhält Zeiger auf M-Beans. Jedes Mal, wenn eine M-Bean bei dem Bezugssystem 24 registriert wird, ruft das Bezugssystem 24 den M-Bean-Speicherdienst 27, um die Identität der M-Bean zu speichern. Ein Name wird einer M-Bean zugeordnet. Wenn bei dem M-Bean-Speicherdienst 27 angefragt wird, können Agenten- und Manager-Anwendungen eine M-Bean mittels ihres Namens identifizieren. Verschiedene Implementierungen des M-Bean-Speicherdienstes 27 sind möglich. Eine Implementierung verwendet eine relationale Datenbank zum Speichern persistenter M-Beans, während eine andere Implementierung einfachen Speicher einsetzt, um nicht-persistente M-Beans zu speichern.
Unter Berücksichtigung der von der Speichereinheit bereitgestellten Struktur ist eine alternative Darstellung der Beziehung zwischen Komponenten des Agenten in 4 dargestellt. Dies berücksichtigt die Registrierung der Beans für die Adapterserver für die verwalteten Objekte, die Managementdienste und die verwalteten Objekte bei der M-Bean-Speicherdienst-Bean.
Ein Filterdienst 29 wählt M-Beans aus, die Gegenstand einer Managementoperation sind. Die Auswahl beruht auf dem Vorhandensein und den Werten spezieller Attribute. Zum Beispiel könnte ein Filter alle M-Beans auswählen, für die das Attribut Farbe auf rot gesetzt ist.
Ein Metadaten-Dienst 25 stellt Information über die Struktur einer M-Bean zur Verfügung. Zum Beispiel fragt das Bezugssystem 24 beim Metadaten-Dienst 25 an, um auf Methoden zum Holen und Einstellen einer Eigenschaft innerhalb einer M-Bean zuzugreifen. Der Metadaten-Dienst 25 beruht auf dem Reflexions- oder Spiegelungs-API, das von dem JavaBeans Development Kit zum Durchführen einer Selbstprüfung bereitgestellt wird.
Ein Dienst zum dynamischen Laden von Klassen lädt neue Klassen in das Bezugssystem 24. Eine neue Klasse wird geladen, wenn der entfernte Eintrag das Kreieren von Instanzen einer Klasse verlangt, die nicht in das Bezugssystem 24 geladen ist. Die neue Klasse kann aus einem entfernten Klassen-Server geladen werden. Der Dienst zum dynamischen Laden erlaubt es auch, daß Kernmanagementdienste zu einem Agenten eines Netzmanagementsystems hinzugefügt werden, während er ausgeführt wird. Zum Beispiel könnte ein Agent ohne einen Filterdienst gestartet werden. Dann könnte später der Filterdienst dynamisch zu dem Agenten hinzugefügt werden, wenn es erforderlich ist.
Ein Zugangskontroll-Dienst kann vorgesehen werden, um den Zugang zu M-Beans zu kontrollieren. Bevor versucht wird, eine Managementoperation auf einer M-Bean durchzuführen, kann das Bezugssystem 24 dafür ausgelegt sein, bei einem Zugangskontroll-Dienst anzufragen, um zu überprüfen, daß die Operation gültig ist.
Ein Ereignisdienst kann vorgesehen werden, um Ereignisreports von M-Beans zu empfangen und sie zu irgendeiner Einheit weiterzuleiten, die angefordert hat, sie zu empfangen.
Ein Beziehungsdienst kann bereitgestellt werden, um es zu ermöglichen, daß Beziehungen zwischen M-Beans definiert werden, wenn sie benötigt werden. Die Beziehungen brauchen nicht im Voraus definiert zu werden. Informationen über Beziehungen zwischen M-Beans werden nicht in den M-Beans selbst gespeichert, sondern können von dem Beziehungsdienst erhalten werden.
Ein dynamischer Lade-Dienst einer (dem Bezugssystem eigenen) Bibliothek kann zum Laden von eigenem bzw. maschineneigenem Code in das Bezugssystem 24 bereitgestellt werden. Eine native Bibliothek kann geladen werden, wenn eine neue Klasse geladen wird, die maschineneigenen Code enthält. Die geladene Bibliothek hängt von der Hardware-Plattform und dem Betriebssystem ab, auf dem das Bezugssystem läuft. Die eigene Bibliothek kann von einer entfernten Einheit geladen werden.
Es folgt nun eine Beschreibung der Adapterserver für verwaltete Objekte 30–38.
Ein Adapterserver für verwaltete Objekte ist ein Protokolladapter, der eine Abstraktion eines Kommunikationsprotokolls bereitstellt. Jeder Adapterserver für verwaltete Objekte bietet Zugang zu M-Beans über ein bestimmtes Kommunikationsprotokoll. Ein Adapterserver für verwaltete Objekte versetzt Managementanwendungen in die Lage, Managementoperationen auf einem Agenten des Netzmanagementsystems durchzuführen.
Damit ein Agent des Netzmanagementsystems verwaltbar ist, ist er über mindestens einen Adapterserver für verwaltete Objekte angeschlossen. Jedoch kann ein Agent des Netzmanagementsystems an eine beliebige Anzahl von Adapterservern für verwaltete Objekte angeschlossen sein, wodurch ermöglicht wird, daß er von entfernten Managementanwendungen angefragt wird, die unterschiedliche Protokolle verwenden.
Das Netzmanagementsystem stellt Adapterserver für verwaltete Objekte für standardisierte und herstellereigene Protokolle zur Verfügung.
Zum Beispiel können Adapterserver für verwaltete Objekte als Beispiel für eines oder mehrere der Standard-Protokolle HTML/HTTP, SNMP und CORBA bereitgestellt werden.
Die Adapterserver für verwaltete Objekte für Standard-Protokolle kommunizieren direkt mit den Managementanwendungen, die sie benutzen.
Zum Beispiel versetzt ein HTML/HTTP-Adapterserver für verwaltete Objekte einen Benutzer in die Lage, einen Web-Browser zu benutzen, um Managementinformation zu betrachten, die in M-Beans enthalten ist und Managementoperationen auf einem Agenten des Netzmanagementsystems durchzuführen. Der HTML/HTTP-Adapterserver für verwaltete Objekte erhält Managementinformation von M-Beans und erzeugt HTML-Seiten, die diese Managementinformation repräsentieren.
Ein SNMP-Adapterserver für verwaltete Objekte kann eingerichtet werden, um eine speziell definierte SNMP-Management-Informationsbasis (MIB) zu verwenden, um den SNMP-Manager in die Lage zu versetzen, Managementoperationen auf einem Agenten des Netzmanagementsystems durchzuführen.
Das Netzmanagementsystem kann auch dafür ausgelegt sein, Adapterserver für verwaltete Objekte für ein oder mehrere der folgenden herstellereigenen Protokolle bereitzustellen: RMI, Java/HTTP und Secure Sockets Layer (SSL). In einem Beispiel des Netzmanagementsystems bietet ein Adapter-Client für verwaltete Objekte ein Java-API an. Dementsprechend wird jede Managementanwendung, die einen Adapter-Client für verwaltete Objekte verwendet, in der Sprache Java geschrieben sein.
Agenten, die mittels des Netzmanagementsystems entwickelt sind, können mittels unterschiedlicher Kommunikations- oder Management-Protokolle verwaltet werden. Um mittels eines Standard-Management-Protokolls verwaltet zu werden, muß ein Agent des Netzmanagementsystems mit dem Adapterserver für verwaltete Objekte für dieses Protokoll verbunden sein. Der Adapterserver für verwaltete Objekte für Standard-Protokolle kommuniziert direkt mit den Managementanwendungen, die sie benutzen.
Ein Beispiel dieser Struktur, die die Agentendarstellung von 4 verwendet, ist in 5 abgebildet, wobei auf den Agenten mit Hilfe eines Web-Browsers 46 zugegriffen wird. Hier ermöglicht ein HTML-Adapter, daß die Beans auf eine HTML-Seite abgebildet werden. Die Verwendung eines Protokolls wie HTML erlaubt es, daß der Browser 46 bei der Clientstation 90 Beans auf der entfernten Station 20 durchsucht und mittels herkömmlicher Web-Browser-Funktionen auf sie zugreift und sie, wenn nötig, modifiziert. Gemäß der in 4 abgebildeten Struktur wird der Speicherdienst 27 bei dem Bezugssystem 24 registriert, und der HTML-Adapter 34 und die Bean(s) 29 werden bei dem Speicherdienst registriert, wodurch die Bean(s) effektiv bei einer HTML-Seite registriert werden, die von dem HTML-Adapter 34 unterstützt wird. In 5 beziehen sich gleiche Referenzziffern auf gleiche Merkmale der Anordnung in 4.
6 ist ein Flußdiagramm, das Schritte darstellt, um die Modifikation von Eigenschaften der Beans in der entfernten Maschine zu ermöglichen. In Schritt 92 wird der HTML-Adapter 34 in der virtuellen Maschine 22 in der entfernten Station 20 initialisiert, und in Schritt 94 werden die Bean(s) 29 dieser virtuellen Maschine, auf die entfernt zugegriffen wird, bei dem Bezugssystem registriert, oder genauer bei dem Speicherdienst 27, wie oben beschrieben. Das bedeutet, daß dann, wenn der HTML-Adapter beim Bezugssystem 24 anfragt, das Bezugssystem 24 unter Bezug auf den Speicherdienst in der Lage ist, die Beans 29 zu identifizieren, auf die zugegriffen wird und Zugriff darauf durch den HTML-Adapter erlaubt.
Der HTML-Adapter 34 erlaubt Kommunikation über das Netz mittels herkömmlichen HTTP-Austauschs. Er verhält sich wie ein HTTP-Server. Wenn er eine Anforderung erhält, erzeugt er dynamisch eine Seite, die eine Liste von Beans (Objekten) 29 enthält, die aktuell bei dem Speicherdienst 27 registriert sind.
Eine Bean wird in HTML als eine HTML-Tabelle dargestellt, wobei:
eine erste Spalte einen Eigenschaftsnamen enthält;
eine zweite Spalte einen Eigenschaftstyp enthält;
eine dritte Spalte eine Zugriffsberechtigung (Lesen/Schreiben) enthält;
eine vierte Spalte einen Eigenschaftswert enthält.
Wie oben erwähnt, wird in dem Fall, daß die Eigenschaft les-/schreibbar ist, ein HTML-Formular erzeugt.
In Schritt 96 werden die Beans auf der Clientstation (repräsentiert durch die Anzeige 98) mittels der HTML-Darstellung einer Bean wie oben beschrieben durch Zugriff auf die HTML-Seite mittels eines herkömmlichen Web-Browsers angezeigt, der mit dem HTML-Adapter mittels HTTP-Austausch kommuniziert. Der Benutzer ist in der Lage, dann bei Schritt 100 eine Bean mittels herkömmlicher Web-Browser-Funktionen auszuwählen. Der Web-Browser wird dann eine HTTP-GET-Anforderung an den HTML-Adapter 34 absetzen. Der HTML-Adapter verwendet Selbstprüfung bzw. Introspektion, um die Bean-Eigenschaften zu extrahieren und gibt dann eine HTML-POST-Antwort an den Browser zurück, wodurch der Browser die Eigenschaften und ebenfalls möglicherweise die Aktionen und Ereignisse, die von der Bean unterstützt werden, anzeigen kann, wie bei 102 dargestellt. Durch weitere Verwendung des Browsers mittels herkömmlicher Browser-Funktionen ist der Benutzer in der Lage, Modifikationen an Aspekten der Bean auszuwählen und zu spezifizieren, zum Beispiel Änderungen an den Eigenschaften. Durch einen weiteren Austausch von HTML-GET- und/oder -SET-Anforderungen und -POST-Antworten sind der Web-Browser und der HTML-Adapter in der Lage, bei Schritt 104 die entsprechenden Eigenschaften der Bean auf der entfernten Station zu modifizieren und diese Änderungen dem Benutzer an der Client-Station anzuzeigen.
Daher stellt dieser Mechanismus ein Computer-implementiertes Verfahren zum Zugriff auf ein Objekt wie eine Bean auf einer entfernten Maschine über eine Telekommunikationsnetz von einer Client-Maschine bereit, indem das Objekt auf eine extern zugreifbare Maschinenseite auf der entfernten Maschine abgebildet wird und das Objekt über die Maschinenseite mittels eines Browsers durchsucht wird.
Ein anderes Beispiel der in 3 gezeigten Struktur, dieses Mal unter Verwendung der Darstellung von 3, ist in 7 abgebildet, wobei ein Agent 20 des Netzmanagementsystems durch eine SNMP-Manageranwendung verwaltet wird. In 7 beziehen sich gleiche Referenzziffern auf gleiche Merkmale der in 3 abgebildeten Anordnung.
Ein Beispiel eines in 8 dargestellten Netzmanagementsystems stellt ein Adapter-API bereit, um Java-Managementanwendungen in die Lage zu versetzen, mit Agenten des Netzmanagementsystems zu kommunizieren. Das Adapter-API stellt Adapter-Clients für verwaltete Objekte zum Zugriff auf verwaltete Objekte durch ein bestimmtes Kommunikationsprotokoll zur Verfügung. Das Netzmanagementsystem definiert eine Darstellung von M-Beans für Java-Managementanwendungen und stellt ein Tool bzw. Werkzeug zum Kompilieren bereit, um eine solche Darstellung automatisch aus einer M-Bean zu erzeugen. Ein Namensdienst wird geliefert, um es Java-Managementanwendungen zu ermöglichen, von einem bestimmten Kommunikationsprotokoll unabhängig zu sein.
Ein Adapter-Client für verwaltete Objekte ist eine abstrakte Java-Klasse, die Java-Managementanwendungen in die Lage versetzt, auf verwaltete Objekte zuzugreifen. Die programmtechnische Repräsentation der verwalteten Objekte für die Java-Managementanwendungen wird von dem Adapter-Client für verwaltete Objekte festgelegt. Ein solcher Mechanismus erlaubt, unterschiedliche Repräsentationen desselben verwalteten Objekts verschiedenen Java-Managementanwendungen zu präsentieren. Das Netzmanagementsystem sieht Adapter-Clients für verwaltete Objekte zum Zugriff auf verwaltete Objekte durch ein oder mehrere der folgenden Protokolle vor: RMI; HTTP und SSL.
Die Adapter-Clients für verwaltete Objekte stellen eine Definition einer Adapter-Schnittstelle für verwaltete Objekte zur Verfügung. Die Adapter-Schnittstelle für verwaltete Objekte setzt Java-Managementanwendungen in die Lage, eine oder mehrere der folgenden Managementoperationen auf einem Agenten des Netzmanagementsystems durchzuführen:

– Holen bzw. Suchen von M-Beans;
– Holen bzw. Lesen oder Einstellen der Eigenschaften von entfernten M-Beans;
– Aufruf von Methoden von entfernten M-Beans;
– Kreieren von Instanzen von M-Beans;
– Löschen von M-Beans; und
– Empfang von Ereignissen, die von entfernten M-Beans ausgesandt werden.

Ein Adapter-Client für verwaltete Objekte versorgt eine Java-Managementanwendung mit "Handhaben" auf verwalteten Objekten in einem entfernten Agenten. Diese Handhaben ermöglichen es der Java-Managementanwendung, die verwalteten Objekten direkt zu manipulieren. Die Java-Managementanwendung braucht keine Information über das von dem verwalteten Objekt verwendete Protokoll. Alles, was die Java-Managementanwendung benötigt, ist die Klasse des Objekts, die das verwaltete Objekt repräsentiert. Zum Beispiel verwendet eine Java-Managementanwendung zum Behandeln von Konten eine abstrakte Klasse zur Repräsentation von Konten. Um ein Konto zu manipulieren erhält die Java-Managementanwendung ein verwaltetes Konto-Objekt von dem Adapter-Client für verwaltete Objekte. Sie wandelt das verwaltete Konto-Objekt danach in die abstrakte Klasse um, die das Konto repräsentiert. Auf diese Weise ist der Anwendungscode unabhängig davon, wie das verwaltete Objekte implementiert ist.
8 ist eine schematische Darstellung der Beziehung zwischen einer Client-Bean (C-Bean) 54 und einer M-Bean 28. Eine C-Bean 54 ist eine Repräsentation einer M-Bean gegenüber einer Java-Managementanwendung. In der bevorzugten Ausführungsform der Erfindung ist eine C-Bean 54 wie eine M-Bean 28 als eine JavaBeans-Komponente implementiert. Eine C-Bean 54 definiert, wie eine Java-Managementanwendung auf eine M-Bean 28 zugreift.
Wie in 8 zu sehen, weist eine C-Bean 54 eine Schnittstelle 56 für verwaltete Objekte (Managed Object Interface, MO-Schnittstelle) auf, die definiert, auf welche der Methoden einer M-Bean eine Java-Managementanwendung Zugriff hat, und weist einen Stumpf bzw. Ansatz 58 für verwaltete Objekte (MOStub) auf, der die in der MO-Schnittstelle 56 definierten Methoden implementiert.
Eine Java-Managementanwendung erhält eine Referenz auf eine C-Bean, indem sie eine Adapter-MO-Schnittstelle 60 verwendet. Die Adapter-MO-Schnittstelle instantiiert die C-Bean 54. Dieselbe Implementierung einer C-Bean 54 kann auf jedem Adapter-Client für verwaltete Objekte ablaufen, der die Adapter-MO-Schnittstelle 60 implementiert. Unterschiedliche Implementierungen desselben verwalteten Objekts können verschiedenen Java-Managementanwendungen präsentiert werden. Daher kann eine einzelne M-Bean verschiedenen C-Beans 54 zugeordnet sein.
Eine Java-Managementanwendung führt Managementoperationen auf einer M-Bean durch, indem sie Methoden ihrer zugeordneten C-Bean 54 aufruft. Gegenüber einer Java-Managementanwendung ist eine C-Bean 54 eine lokale Repräsentation des entfernten Java-Objekts (einer M-Bean 28).
Die Adapter-MO-Schnittstelle 60 instantiiert die C-Bean 54. Dieselbe Implementierung einer C-Bean kann auf jedem Adapter-Client 62 für verwaltete Objekte ablaufen, der die Adapter-MO-Schnittstelle 60 implementiert. Unterschiedliche Repräsentationen desselben verwalteten Objekts können verchiedenen Java-Managementanwendungen präsentiert werden. Daher kann eine einzelne M-Bean verschiedenen C-Beans zugeordnet sein.
Eine Java-Managementanwendung führt Managementoperationen auf einer M-Bean durch, indem sie Methoden ihrer zugeordneten C-Bean aufruft. Gegenüber einer Java-Managementanwendung ist eine C-Bean eine lokale Repräsentation eines entfernten Java-Objekts (einer M-Bean).
9 ist eine schematische Darstellung der Erzeugung einer C-Bean 54 aus einer M-Bean. In einer Ausführungsform der Erfindung wird eine C-Bean automatisch aus einer M-Bean 28 mittels des Reflektions- bzw. Spiegelungs-API erzeugt. Die erzeugte C-Bean zeigt dieselben Eigenschaften, Methoden und Ereignisse wie die M-Bean. Dies ist zum Beispiel der Fall, wenn keine Zugriffskontrollrichtlinie bzw. -strategie in Kraft gesetzt wird.
Um die automatische Erzeugung einer C-Bean 54 aus einer M-Bean 28 zu besorgen, nimmt ein Compiler 60 die M-Bean 28 als eine Eingabe und erzeugt als eine Ausgabe die MO-Schnittstelle und die MO-Stümpfe einer C-Bean 54. Wenn zum Beispiel eine M-Bean 28, die eine Java-Klasse namens account repräsentiert, kompiliert wird, erzeugt der Compiler 60 eine MO-Schnittstelle 56 namens accountMO und eine Java-Klasse namens accountMOSTUB 58, die die accountMO Schnittstelle 56 implementiert.
Eine Java-Managementanwendung kann mittels der MO-Schnittstellen-Definitionen entwickelt werden. Indem verschiedene Stümpfe bzw. Ansätze geladen werden, kann die AdaptorMO Schnittstelle das Verhalten der Java-Managementanwendung im laufenden Betrieb ändern. Wenn zum Beispiel nur lesbare Ansätze geladen werden, wird die Java-Managementanwendung nicht in der Lage sein, die Eigenschaften der M-Bean 28 zu ändern.
Der Compiler 60 kann nur lesbare oder schreib-/lesbare Ansätze erzeugen. Die erzeugten Ansätze machen Gebrauch von der AdaptorMO Schnittstelle. Daher ist ihr Verhalten auf jedem A dapter-Client für verwaltete Objekte, der die AdaptorMO Schnittstelle implementiert, dasselbe, unabhängig von der Implementierung des Adapter-Client für verwaltete Objekte.
10 ist ein Blockdiagramm von Schritten zum Zugriff auf eine Bean auf der entfernten (Server-)Station von einer lokalen Management-(Client-)Station mittels einer Struktur wie in 8 abgebildet.
Die Managementanwendung (z. B. eine Java-Managementanwendung) auf der Management-Station erzeugt bei Schritt 80 eine Hol-Anforderung an das AdaptorMO auf der Client-Station. Das AdaptorMO erzeugt mit dem MOStub und dem Netzadapter auf der Client-Station bei 81 eine Anforderung gemäß einem geeigneten Netzprotokoll (z. B. HTTP).
Daher könnte die über das Netz an das verwaltete System gesandte Anforderung zum Beispiel in der Form einer GET-Anforderung für eine Management-Eigenschaft eines verwalteten Objektes vorliegen.
Der geeignete Adapterserver für verwaltete Objekte 30–38, der von dem verwendeten Protokoll abhängt, empfängt die externe Anforderung bei Schritt 82. Er wird dann bei Schritt 83 auf das Bezugssystem 24 zugreifen, um eine geeignete Methode zu bekommen. Das Bezugssystem bekommt bei Schritt 83 eine Methode eines verwalteten Objektes für die Anforderung und gibt bei Schritt 84 die Management-Eigenschaft des verwalteten Objektes an den Adapter zurück, der wiederum bei Schritt 85 eine Rückmelde-Nachricht mit dem Ergebnis gemäß demselben Netzprotokoll (z. B. HTTP) zusammensetzt. Die Ergebnisnachricht wird bei Schritt 86 beim Client-Adapter und dem adapterMO empfangen, der das Ergebnis an die Managementanwendung zurückliefert.
Ein Namensdienst wird bereitgestellt, der es Managementanwendungen ermöglicht, unabhängig von einem bestimmten Kommunikationsprotokoll zu sein. Java-Managementanwendungen verwenden den Namensdienst, um festrustellen, welcher Adapter-Client für verwaltete Objekte verwendet werden soll, um auf einen Agenten zuzugreifen. 11 ist ein schematisches Flußdiagramm, das den Betrieb des Namensdienstes veranschaulicht.
In Schritt 62 übergibt die Managementanwendung die Identität des Agenten, auf den zugegriffen werden soll, an den Hauptdienst.
In Schritt 64 gibt der Namensdienst den Klassennamen des Adapter-Client für verwaltete Objekte zurück, zum Beispiel sunw.jaw.moa.rmi im Fall eines Agentenzugriffs durch das Java-RMI-System.
In Schritt 66 verwendet die Java-Managementanwendung ihren standardmäßigen Klassenlader, um den Adapter-Client für verwaltete Objekte dynamisch zu laden und ihn zu instantiieren. Die Java-Managementanwendung kann daraufhin mit dem Agenten durch den Adapter-Client für verwaltete Objekte unabhängig von dem Kommunikationsprotokoll interagieren.
Wie oben erwähnt ist eine Management-Bean oder M-Bean ein verwaltetes Objekt in einem Agenten eines Netzmanagementsystems. Ein verwaltetes Objekt ist eine Software-Abstraktion einer Ressource, die von dem Agenten gesteuert und überwacht wird. In einem Beispiel eines Netzmanagementsystems sind alle M-Beans als JavaBeans-Komponenten implementiert. Auf sie kann mittels eines herkömmlichen Java-Anwendungs-Builder wie dem Java Beans Development Kit zugegriffen werden. Innerhalb einer M-Bean ist es möglich, Dienste aufzurufen und zu verwenden, die von dem Netzmanagementsystem bereitgestellt werden.
Eine JavaBeans-Komponente beinhaltet Eigenschaften, die diskrete, benannte Attribute bilden, die das Erscheinen oder das Verhalten der JavaBeans-Komponente beeinflussen können. Zum Beispiel könnte eine M-Bean, die einen Ethernet-Treiber repräsentiert, eine Eigenschaft namens Ipackets haben, die die Anzahl von eintreffenden Paketen repräsentiert. Eigenschaften können beliebige Werte haben einschließlich sowohl eingebauter Java-Endtypen und -Klassen oder Schnittstellentypen wie Java.awt.color. Auf Eigenschaften wird immer über Methodenaufrufe auf dem Objekt, das sie besitzt, zugegriffen. Für lesbare Eigenschaften gibt es eine Hole- bzw. get-Methode, um den Eigenschaftswert zu lesen. Für schreibbare Attribute gibt es eine Setze- bzw. set-Methode, um zu erlauben, daß der Eigenschaftswert aktualisiert wird.
Ein Standard-Auslegungs-Muster kann zum Lokalisieren von Eigenschaften verwendet werden:
public PropertyType getPropertyName ();
public void setPropertyName (PropertyType value);
Wenn eine Klassendefinition ein zusammenpassendes Paar von getPropertyName und setPropertyName Methoden beinhaltet, wobei der Rückgabetyp des Holers dem Parametertyp des Setzers entspricht, dann definieren diese Methoden eine Schreib-Lese-Eigenschaft. Wenn eine Klassendefinition nur eine dieser Methoden beinhaltet, definiert der Name entweder eine nur-lesbare oder nur-schreibbare Eigenschaft namens PropertyName.
Zusätzlich ist es für Bool'sche Eigenschaften möglich, eine Get-Methode mittels des folgenden Design-Musters zu definieren:
public boolean isPropertyName();
Die isPropertyName-Methode kann anstelle einer getPropertyName-Methode angeboten werden, wobei sie auch zusätzlich zu einer getPropertyName-Methode angeboten werden kann.
Eine Index-Eigenschaft ist ein Array PropertyElement⎕, auf das durch Methoden in der Form:
public PropertyElement getPropertyName (int index);
public void setPropertyName (int index, PropertyElement b) zugegriffen wird.
Wenn eine Klassendefinition eine von beiden Arten von Methoden beinhaltet, ist PropertyName eine Index-Eigenschaft. Diese Methoden können verwendet werden, um einen Eigenschaftswert zu lesen und zu schreiben. Diese Methoden können zusätzlich zu den Methoden für einfache Eigenschaften definiert werden. Daher kann eine Index-Eigenschaft durch vier Zugriffsmethoden repräsentiert werden.
Standardmäßig wird das folgende Design-Muster verwendet, um festzustellen, welches Ereignis eine M-Bean per Multicast versenden kann:
public void addEventListenerType(EventListenerType a);
public removeEventListenerType(EventListenerType a);
Beide Methoden erhalten das Argument vom Typ EventListenerType, wobei der Typ EventListenerType die Schnittstelle java.util.Eventlistener erweitert, wobei die erste Methode mit add anfängt und die zweite Methode mit remove, und wobei der Typnamen EventListenerType mit Listener aufhört.
Dieses Auslegungs-Muster geht davon aus, daß die Java-Bean als eine Quelle für per Multicast versandte Ereignisse für dasjenige Ereignis agiert, das in der EventListenerType-Schnittstelle spezifiziert ist.
Um mit dem JavaBeans-Modell konform zu sein, sollten alle öffentlichen bzw. public-Methoden einer JavaBeans-Komponente als externe Methoden innerhalb der Komponentenumgebung zum Zugriff durch die Komponenten offengelegt sein. Standardmäßig beinhaltet dies Eigenschaftszugriffsmethoden und eine Registriermethode im event listener.
Zusätzlich zu dem JavaBeans-Komponenten-Modell für Design-Muster-Elemente kann das Netzmanagementsystem eine Aktion als eine öffentliche Methode einer M-Bean definieren, für die es sinnvoll ist, entfernt aufgerufen zu werden. Die Aktion erleichtert die Unterscheidung einer öffentlichen Methode einer M-Bean, die für andere lokale M-Beans offengelegt ist, von öffentlichen Methoden, die entfernt aufgerufen werden können. Das Auslegungs-Muster für eine Aktion ist folgendermaßen:
public AnyJavaType performAnAction (AnySignature);
M-Beans können maschinen-spezifische ihnen eigene Bibliotheken beinhalten, das heißt eine Bibliothek, die nicht in der Sprache (z. B. Java) der M-Bean geschrieben ist. Das Netzmanagementsystem kann einen Mechanismus zum Laden einer eigenständigen Bibliothek von demselben entfernten Klassen-Server wie die M-Bean anbieten. Um eine M-Bean in die Lage zu versetzen, diesen Mechanismus zu verwenden, kann eine statische loadLibrary-Methode der Bezugssystem-Klasse aufgerufen werden, in der der Rufende eine Referenz auf die Java-Klasse des Rufenden einschließt. Eine solche Information wird von dem Bezugssystem 24 verwendet, um den Klassenlader zu identifizieren, durch den die Klasse geladen wird.
Die oben erwähnten Kernmanagementdienste sind für viele der Managementoperationen allen Agenten gemeinsam, wodurch die Entwicklung von Agenten vereinfacht wird. Indem diese Kerndienste angeboten werden, ermöglicht es das Netzmanagementsystem, daß der Aufwand auf die Entwicklung jener Teile eines Agenten konzentriert wird, die für eine bestimmte Anwendung spezifisch sind, nämlich die M-Beans und Anwendungen, um sie zu steuern und zu verwalten.
12 ist ein schematisches Flußdiagramm der Initialisierung eines Agenten 20 des Netzmanagementsystems. Der Initialisierungsprozeß weist auf:

– in Schritt 70 Kreieren einer Instanz des Bezugssystems 24;
– in Schritt 72 Hinzufügen des M-Bean Speicherdienstes 27;
– in Schritt 74 Hinzufügen des Metadaten-Dienstes 29; und
– in Schritt 76 Hinzufügen mindestens eines Adapterservers (30–38) für verwaltete Objekte, so daß auf den Agenten von Managementanwendungen zugegriffen werden kann.

Sobald der Agent 20 des Netzmanagementsystems initialisiert wurde, brauchen keine weiteren Managementdienste hinzugefügt zu werden, bevor ein Agent gestartet wird. Diese können dynamisch zu dem Agenten hinzugefügt werden, während er ausgeführt wird.
Das Bezugssystem 24 steuert die Managementdienste und M-Beans eines Agenten 20, der mittels des Netzmanagementsystems entwickelt wurde. In der bevorzugten Ausführungsform ist es durch die Java-Klasse java.jaw.agent.cmf.Framework implementiert. Ein Agent muß eine Instanz des Bezugssystems beinhalten, das heißt, in der bevorzugten Ausführungsform eine Instanz der java.jaw.agent.cmf.Framework-Klasse.
In der bevorzugten Ausführungsform können M-Beans nur verwaltet werden, wenn sie mit einem Objektnamen in dem M-Bean-Speicher 27 des Agenten 20 registriert sind. Dementsprechend wird der M-Bean-Speicherdienst 27 in Schritt 72 hinzugefügt, bevor der Agent 20 in Betrieb geht. Der M-Bean-Speicherdienst 27 wird zum Speichern und Zurückholen der Verknüpfung zwischen einer M-Bean und ihrem Objektnamen verwendet. Der M-Bean-Speicherdienst der bevorzugten Ausführungsform ist als die Java-Schnittstelle java.jaw.agent.services.MoRepSrvlf definiert. Ein Agent kann zu jedem Zeitpunkt nur mit einem M-Bean-Speicherdienst verknüpft sein. Es ist jedoch möglich, den M-Bean-Speicherdienst, mit dem der Agent verknüpft ist, zu ändern, während der Agent ausgeführt wird.
Der M-Bean-Speicher kann als ein flüchtiger Speicher oder als ein persistenter Speicher implementiert sein. In einem flüchtigen Speicher werden sämtliche Informationen über M-Beans im Hauptspeicher gespeichert. Sämtliche Informationen in einem flüchtigen Speicher gehen verloren, wenn der Agent angehalten wird. Dementsprechend muß ein Agent bei einem flüchtigen Speicher die Informationen in dem Speicher erneut laden, wenn der Agent gestartet wird. Bei einem persistenten Speicher werden sämtliche Informationen über M-Beans in einer Datenbank gespeichert, wobei die Informationen in einem persistenten Speicher nicht verloren gehen, wenn der Agent angehalten wird. Es ist auch möglich, einen gemischten Speicher zu implementieren, wobei die Informationen über M-Beans im Hauptspeicher oder in einer Datenbank gespeichert werden.
Der oben erwähnte Metadaten-Dienst wird verwendet, um die von einer M-Bean unterstützten Eigenschaften und Aktionen zu erhalten. Eine bevorzugte Implementierung des Metadaten-Dienstes basiert auf dem Reflektions- bzw. Spiegelungs-API, das von dem bekannten Java Development Kit zum Durchführen von Selbstprüfungen bereitgestellt wird.
Wie oben erwähnt sollte mindestens ein Adapterdienst für verwaltete Objekte in der virtuellen Maschine des Servers als der Agent des Netzmanagementsystem ablaufen. Das Netzmanagementsystem erfordert nicht, daß ein Adapterserver für verwaltete Objekte einer speziellen Schnittstellendefinition oder Implementierung entspricht. Der Adapterserver für verwaltete Objekte ist dafür ausgelegt, auf das Bezugssystem 24 zuzugreifen, um in dem Agenten enthaltene Informtionen abzuholen und zu ändern. Die bereitgestellten Adapterserver für verwaltete Objekte sind als M-Beans implementiert. Beispiele von Adapterservern für verwaltete Objekte wurden oben beschrieben. In der bevorzugten Ausführungsform der Erfindung sind die Adapterserver für verwaltete Objekte als passende Java-Klassen implementiert.
Zum Beispiel kann ein RMI-Adapterserver für verwaltete Objekte als eine Java-Klasse sunw.jaw.agent.adaptor.rmi.AdaptorServerlmpl implementiert sein. Er setzt Java-Managementanwendungen in die Lage, auf einen Agenten mittels des Java-Methoden-Fernaufruf- bzw. Java Remote Method Invocation (RMI) Systems zuzugreifen. Wie oben beschrieben, greift eine Java-Managementanwendung auf diesen Server durch einen Adapter-Client für verwaltete Objekte zu, der als die Java-Klasse sunw.jaw.agent.adaptor.rmi.AdaptorClient implementiert ist.
Kernmanagementdienste können zu einem Agenten hinzugefügt werden, während er ausgeführt wird, sobald der Agent wie oben beschrieben initialisiert wurde. Es ist möglich, einen Kerndienst zu einem Agenten in einer der folgenden Weisen hinzuzufügen:

– durch direkten Aufruf einer Setz- bzw. Set-Methode für den Dienst innerhalb der Bezugssystem- bzw. Framework-Klasse;
– durch Hinzufügen des Dienstes zu dem M-Bean-Speicher in derselben Weise wie bei einer M-Bean.

Einen Kernmanagementdienst direkt hinzuzufügen, ergibt schnelleren Durchsatz als das Hinzufügen eines Kernmanagementdienstes zu dem M-Bean-Speicher. Das liegt daran, daß das Bezugssystem nicht bei dem M-Bean-Speicher anzufragen braucht, um den Dienst zu erhalten. Jedoch können gewisse Einschränkungen für einen Kernmanagementdienst gelten, der direkt hinzugefügt wurde:

– der Dienst ist nicht sichtbar für entfernte Anwendungen; und
– es ist nicht möglich, Information über den Dienst in persistentem Speicher zu speichern.

Dementsprechend ist es nötig, den Dienst zu dem M-Bean-Speicher hinzuzufügen, wenn es wünschenswert ist, daß ein Kernmanagementdienst für entfernte Anwendungen sichtbar ist. Wenn es gewünscht ist, Informationen über einen Kernmanagementdienst in persistentem Speicher zu speichern, ist es ebenfalls notwendig, den Dienst zu dem M-Bean-Speicher hinzuzufügen. Der M-Bean-Speicher, zu dem der Dienst hinzugefügt wird, muß persistente Speicherung unterstützen.
Ein Klassendienstname bzw. Class Service Name beinhaltet Namen, mit denen das Bezugssystem 24 die Dienste identifiziert, die für einen Agenten implementiert sind. Das Bezugssystem 24 holt den Dienst, den es braucht, wie folgt:

1. Das Bezugssystem 24 prüft, ob ein Dienst mittels einer direkten Setz-Methode definiert wurde. Wenn ein Dienst auf diese Weise definiert wurde, verwendet das Bezugssystem 24 diesen Dienst.
2. Wenn der Dienst nicht mittels einer direkten Setz-Methode definiert wurde, fragt das Bezugssystem bei dem M-Bean-Speicher nach, um alle M-Beans zu erhalten, die Instanzen der Klasse sind, die den Service implementieren. Zum Beispiel fragt das Bezugssystem 24 für den Metadaten-Dienst bei dem M-Bean-Speicher nach, um alle Instanzen der Klasse namens ServiceName.META zu erhalten. – wenn der Speicher mehrere Instanzen der Klasse enthält, verwendet das Bezugssystem 24 die erste von dem M-Bean-Speicher zurückgelieferte Instanz. – wenn der M-Bean-Speicher keine Instanzen der Klasse enthält, wirft das Bezugssystem ein ServiceNotFound Ausnahmebedingung.

Verschiedene Operationen können in einem Agenten des Netzmanagementsystems durchgeführt werden. Zum Beispiel kann ein Objekt in einem Agenten Kernmanagementdienste verwenden zum:

– Instantiieren einer M-Bean;
– Registrieren von M-Beans bei dem M-Bean-Speicher;
– Holen von M-Beans aus dem M-Bean-Speicher;
– Holen und Setzen der Werte von Eigenschaften innerhalb von M-Beans; und
– Definieren von Beziehungen zwischen M-Beans.

Ein Objektname identifiziert eine M-Bean eindeutig. Managementanwendungen verwenden Objektnamen, um die M-Beans zu identifizieren, auf denen Managementoperationen durchzuführen sind. Jedes beliebige Namensschema könnte verwendet werden. Zum Beispiel könnte in der bevorzugten Ausführungsform der Erfindung ein von Microsoft Corporation für das Hyper-Media-Management-Schema (HMMS) definiertes Namensschema verwendet werden.
Um eine M-Bean zu instantiieren, kann eine der folgenden Methoden der Bezugssystem- bzw. Framework-Klasse aufgerufen werden:
newObject zum Verwenden eines Standard-Speichermechanismus' zum Speichern der M-Bean;
newDBObject zum Spezifizieren, daß die M-Bean persistent ist.
Mit jeder dieser Methoden ist es notwendig zu übergeben:

– die Java-Klasse der zu instantiierenden M-Bean; und
– den zum Registrieren der M-Bean zu verwendenden Objektnamen.

Standardmäßig verwendet das Bezugssystem 24 den Standard-Klassenlader, um die Java-Klasse der zu kreierenden M-Bean zu lokalisieren. Es kreiert dann eine Instanz der Klasse. Sobald die M-Bean instantiiert wurde, wird sie initialisiert und registriert, so daß sie für das Bezugssystem 24 zugänglich ist. Es ist möglich, eine M-Bean zu initialisieren und zu registrieren mittels:

– einer in der M-Bean selbst definierten Methode; oder
– des Rahmenwerkes 24.

Zum Initialisieren eines Registers einer M-Bean mittels einer in der M-Bean selbst definierten Methode, sollte die Java-Klassendefinition der M-Bean beinhalten:

– eine Initialisierungsmethode;
– den erforderlichen Code, um die M-Bean in die Lage zu versetzen, sich selbst bei dem M-Bean-Speicher zu registrieren.

Sobald die M-Bean instantiiert wurde, verwendet das Bezugssystem 24 den Metadaten-Dienst 27, um die Initialisierungsmethode in der neu kreierten M-Bean zu finden. Wenn eine solche Methode in der M-Bean vorhanden ist, ruft das Bezugssystem 24 sie auf, indem es übergibt:

– eine Referenz auf sich selbst als ersten Parameter;
– den Objektnamen zur Verwendung beim Registrieren der M-Bean als einen zweiten Parameter.

Die M-Bean ist daher in der Lage, sich selbst bei dem M-Bean-Speicher mittels des bereitgestellten Codes zu registrieren.
Wenn eine M-Bean nicht mit der Initialisierungsmethode ausgestattet ist, initialisiert und registriert das Bezugssystem die M-Bean mittels der für diesen Zweck bereitgestellten Funktionen.
Das Registrieren einer JavaBeans-Komponente bei dem M-Bean-Speicher 25 erlaubt es, daß die Komponente von dem Agenten 20 verwaltet wird. Registrieren der JavaBeans-Komponente erfordert keine Änderung von Code innerhalb der JavaBeans-Komponente selbst. Stattdessen ist das Hinzufügen von Code, um sie in dem M-Bean-Speicher zu registrieren, alles, was benötigt wird. Daher ist es möglich, irgendeine existierende JavaBeans-Komponente in dem M-Bean-Speicher zu registrieren. Einmal registriert verwaltet der Agent 20 die JavaBeans-Komponente in derselben Weise wie jede M-Bean. Wenn eine M-Bean registriert wird, wird ihr ein Objektname zugewiesen. Ein Objektname kann explizit spezifiziert werden. Wenn ein Objektname nicht explizit spezifiziert wird, weist das Bezugssystem 24 der M-Bean einen Standardnamen zu.
Das Netzmanagementsystem stellt Dienste zum Holen von M-Beans aus dem M-Bean-Speicher zur Verfügung. Diese Dienste ermöglichen das Holen von M-Beans mittels:

– Mustervergleich auf dem Objektnamen; oder
– Anfragen (Filter) auf die Java-Eigenschaften, die sie enthalten.

Durch Verwenden von Mustervergleich auf den Objektnamen von M-Beans ist es möglich, zu erhalten:

– eine spezielle M-Bean mittels ihres vollständigen Objektnamens;
– einen Satz von M-Beans, die dieselbe logische Klasse, wie in dem Objektnamen ausgedrückt, gemeinsam haben;
– einen Satz von M-Beans, die denselben Domänennamen gemeinsam haben; oder
– alle in einem Agenten enthaltenen M-Beans.

Das Verwenden von Anfragen ermöglicht das Gewinnen bzw. Erhalten von M-Beans gemäß Java-Eigenschaften und ihrer Werte innerhalb von M-Beans. Der M-Bean-Speicher wertet Eigenschaften aus, wenn er dies zu tun in der Lage ist. Ansonsten wertet das Bezugssystem Anfragen selbst aus. Um festzustellen, ob ein Speicher in der Lage ist, Anfragen auszuwerten, veranlaßt das Bezugssystem eine Anfragemethode für diesen Zweck.
Das Netzmanagementsystem bietet Dienste zum Holen und Setzen von Eigenschaften von M-Beans an. Wenn der Agent einen Metadaten-Dienst bietet, ist bei einem Aufruf der Hol- oder Setz-Methode der M-Bean alles, was geliefert zu werden braucht:

– der Name der Eigenschaft, die geholt oder gesetzt werden soll;
– der Objektname der M-Bean, die die Eigenschaft enthält.

Wenn der Agent keinen Metadaten-Dienst bietet, ist es dennoch möglich, die Hol- oder Setz-Methode einer M-Bean direkt aufzurufen. In diesem Fall ist es auch notwendig, dem Rufer den Namen und die Signatur der aufzurufenden Methode zu liefern.
Ein Beziehungsdienst ermöglicht es, daß Beziehungen zwischen M-Beans definiert werden, wenn sie benötigt werden. Die Beziehungen brauchen nicht im Voraus definiert zu werden. Informationen über die Beziehungen zwischen M-Beans werden nicht in den M-Beans selbst, sondern zusammen mit der Beziehung gespeichert. Eine Beziehung muß bei dem M-Bean-Speicher registriert werden. Eine Beziehung wird definiert durch:

– einen Satz von Rollen, zum Beispiel in einer Eigner-Beziehung besitzt eine Person ein Buch und ein Buch wird von einer Person besessen;
– einen Grad, der der Anzahl von benötigten Rollen in einer Beziehung entspricht.

Auf die an einer Beziehung beteiligten M-Beans wird in einer Beziehung durch ihre Objektnamen Bezug genommen. Ein spezieller Klassenlader kann zu einem Agenten beim Start oder während der Agent ausgeführt wird hinzugefügt werden. Es ist möglich, mehrere Klassenlader innerhalb desselben Agenten zu haben, vorausgesetzt daß sie alle bei dem M-Bean-Speicher registriert sind. Wenn das Kreieren eines neuen Objektes angefordert wird, ist es möglich, den für das Laden des Objektes zu verwendenden Klassenlader anzugeben. In diesem Fall wird der Klassenlader durch seinen Objektnamen identifiziert. Das System stellt einige Implementierungen eines Netz-Klassenladers zur Verfügung, wobei jede Implementierung ein unterschiedliches Protokoll verwendet und einen anderen Klassen-Server erfordert.
Das System stellt Dienste zur Ereignisbehandlung für das Filtern, Protokollieren und Weiterleiten von Ereignissen durch unterschiedliche Kommunikationsprotokolle zur Verfügung. Um ein Ereignis auszusenden, wird eine Ereignis-Senden-Methode aufgerufen. Wenn diese Methode aufgerufen wird, holt das Bezugssystem 24 alle M-Beans, die einem Dienst zur Ereignisbehandlung entsprechen und ruft eine Methode zur Ereignisbehandlung von jeder geholten Ereignisbehandlung auf. Diese Methode ist für das Behandeln der Ereignisse verantwortlich.
9 ist eine schematische Darstellung des Kompilierens einer C-Bean 54 aus einer M-Bean 28. Der Compiler 60 implementiert ein Übersetzungsschema zum Erzeugen von C-Beans. Es ist jedoch möglich, abhängig von den Anforderungen unterschiedliche Übersetzungsschemata zu implementieren.
13 stellt ein Beispiel der Ausgabe des Compilers 60 für das Kompilieren einer einzelnen M-Bean namens A dar. 14 zeigt die Ausgabe des Compilers 60, wenn eine kompilierte M-Bean einen aListener für ein spezielles Ereignis AnEvent beinhaltet.
Wenn die M-Bean einen Horcher bzw. Listener beinhaltet, erzeugt der Compiler 60 daher:

– eine Java-Schnittstelle für den Listener, die in die MO-Schnittstelle aufzunehmen ist;
– einen Listener-Stub bzw. -Ansatz, der eine Implementierung des M-Bean-Listener zum Abfangen von M-Bean-Ereignissen und Weiterleiten an das Bezugssystem 24 ist; und
– eine Aussicht einer Java-Managementanwendung des Ereignisses, das dem Listener zugeordnet ist, die als EventMO bezeichnet wird.

Der Compiler 60 parst eine M-Bean mittels der anwendbaren Design-Parameter. Nach dem Parsen verwendet der Compiler 60 eine Reihe von Regeln zum Erzeugen der C-Bean.
Jede Eigenschaft der M-Bean ist in der C-Bean mit denselben Zugriffsmethoden vorhanden. Daher ist die Eigenschaft in der C-Bean nur-lesbar, wenn sie auch in der M-Bean nur-lesbar ist.
15A ist eine Darstellung einer einfachen C-Bean, die erzeugt wird, wenn eine M-Bean kompiliert wird, die durch ein in 15B abgebildetes Code-Beispiel definiert ist. Darüber hinaus erzeugt der Compiler 60 eine Datei, die eine Implementierung der Simple-MO-Schnittstelle enthält.
Zusätzlich zu den Eigenschafts-Zugriffsmethoden erzeugt der Compiler 60 nur für die öffentlichen bzw. public-Methoden Code, für die es Sinn macht, entfernten Zugriff anzubieten. Andere public-Methoden erscheinen nicht in der C-Bean, die von dem Compiler 60 erzeugt wird.
16A zeigt eine Teilmenge für eine Aktionsmethode in einer C-Bean der MO-Schnittstelle, die der Compiler 60 erzeugt, wenn er die Aktionsmethode in einer wie in 16B definierten M-Bean kompiliert.
Wenn eine M-Bean einen Listener namens A beinhaltet, umfaßt der Compiler 60 einen Listener namens AlfMO in der C-Bean.
Beim Verwenden der C-Bean wird eine Anwendung die Aifmo-Schnittstelle implementieren müssen, um den Listener in der C-Bean hinzuzufügen oder zu entfernen. Im allgemeinen ist ein Listener eine Schnittstelle, die eine bestimmte Anzahl von Methoden enthält. Jede Methode hat einen Eingabeparameter. Der Eingabeparameter erstreckt sich auf ein betroffenes Ereignisobjekt.
In einem Beispiel bezieht sich jede Methode, die in dem Listener A definiert ist, auf ein Ereignisobjekt, das für die Zwecke dieses Beispiels AnEvent genannt wird. Dementsprechend wird das Ereignisobjekt in der Aifmo-Schnittstelle AnEventMO genannt. Somit erzeugt der Compiler 60 für einen Listener A Dateien:

– Aifmo.java;
– AnEventMO.java.

Darüber hinaus erzeugt der Compiler 60 eine Implementierung des Listener A namens AStub.java.
Code, der vom Compiler 60 erzeugt wird, stimmt mit den Design-Parametern überein, die durch das JavaBeans-Komponenten-Modell bestimmt sind. Dementsprechend können die vom Compiler 60 erzeugten Objekte in Entwicklungsumgebungen integriert werden, die mit diesem Modell konform sind. Darüber hinaus fügt der Compiler 60 einige public-Methoden hinzu, die den durch das JavaBeans-Komponenten-Modell definierten Design-Mustern nicht folgen. Die hinzugefügten Methoden sind dafür ausgelegt, das Netzverkehrsaufkommen zwischen einer M-Bean und einer C-Bean zu begrenzen. Zum Beispiel ist es durch Aufrufen einer Funktion in der C-Bean möglich, alle Eigenschaften der entsprechenden M-Bean zu lesen.
Der Compiler 60 erzeugt Java-Quellcode. Es ist möglich, den erzeugten Code zu editieren und ihn zu modifizieren, um eine spezifische Sicht der M-Bean zu definieren. Anstatt sowohl die Schnittstelle als auch den Stub zu modifizieren, ist es besser, die Schnittstelle beizubehalten und nur den Stub zu ändern. Der von dem Compiler 60 erzeugte Code ermöglicht es, eine Anwendung mittels der Schnittstelle aufzubauen. Zu einem Zeitpunkt wird sich das Verhalten ändern abhängig davon, welche Stubs von dem adapterMO geladen werden. Zum Beispiel kann der Compiler nur- lesbare oder schreib-lesbare Stubs für dieselbe Schnittstelle erzeugen. Dementsprechend kann ein M-Bean-Browser basierend auf der Schnittstelle entwickelt werden. Wie oben erwähnt, wird der Browser dadurch unterschiedliches Verhalten haben abhängig davon, ob die nur-lesbaren oder die schreib-lesbaren Stubs geladen werden.
Die AdaptorMO-Schnittstelle ist eine Java-Schnittstelle, die zum Verwalten des Agenten 20 definiert ist. Das Netzmanagementsystem stellt verschiedene Implementierungen der AdaptorMO-Schnittstelle basierend auf unterschiedlichen Kommunikationsprotokollen bereit, wie oben beschrieben. Die AdaptorMO-Schnittstelle ist jedoch protokollunabhängig. Dementsprechend kann jedes Stück Code, das mittels der Schnittstelle geschrieben wurde, auf irgendeiner der von dem Netzmanagementsystem bereitgestellten Implementierungen ablaufen.
Innerhalb der AdaptorMO-Schnittstelle gibt es zwei Stufen. Eine untere Stufe, auf der entfernte Objekte (M-Bean) mittels ihres Namens, und eine obere Stufe, auf der entfernte Objekte (M-Bean) mittels einer lokalen Ansicht (C-Bean) des entfernten Objekts manipuliert werden. Die obere Stufe ist über der Schnittstelle auf unterer Stufe aufgebaut.
Die Schnittstelle auf unterer Stufe zu verwenden, ist praktisch zum Aufbau generischer Anwendungen (wie einem HTML-Objektbetrachter oder einem MIB-Browser). Die Schnittstelle auf oberer Stufe zu verwenden, ist viel einfacher als die Schnittstelle auf unterer Stufe zu verwenden. Es bedeutet jedoch, daß die Anwendung die Semantik der C-Bean kennt, die sie manipuliert. Darüber hinaus macht es erforderlich, daß die Anwendung (oder die AdaptorMO-Schnittstelle) Zugriff auf MOs und MOStubs hat. Ein erster Schritt zum Initialisieren eines Adapters besteht aus dem Initialisieren einer Implementierung der AdaptorMO-Schnittstelle.
Um einen Adapter zu initialisieren, ruft die Client-Anwendung eine in der MO-Schnittstelle definierte "Connect"- bzw. "Verbinde"-Methode auf. Es werden Parameter übergeben, die sich auf den Hostnamen des Agenten, die zu verwendende Portnummer und einen logischen Namen, der im allgemeinen von dem zugrundeliegenden Kommunikationsmechanismus abhängt, beziehen. Die verschiedenen Stücke von Information könnten von einem Namensserver oder Verzeichnisdienst zum selben Zeitpunkt, zu dem der Implementierungsname des zu verwendenden Adapters gegeben wird, erhalten werden. Abhängig vom zugrundeliegenden Kommunikationsmechanismus, der von der AdaptorMO-Schnittstelle verwendet wird, könnte der Aufruf des "Connect" keinerlei Nachrichtenaustausch zwischen dem Client und dem Agenten nach sich ziehen.
Ein Adapter macht Gebrauch von:

– einem Namensserver zum Erhalt des Java-Klassennamens zur Verwendung zum Darstellen einer speziellen M-Bean (die durch ihren Objektnamen bekannt ist);
– einem Klassenlader zum Laden con C-Beans.

Wenn alle Java-Klassen für die C-Beans auf der Maschine, auf der die Client-Anwendung läuft, vorhanden sind, gibt es keinen Bedarf, einen spezifischen Klassenlader zu verwenden. Ansonsten ist es möglich, einen Netz-Klassenlader zu verwenden, um die Klassen über das Netz zu bekommen.
Um einen Netzklassenlader zu verwenden, muß eine Client-Anwendung den Netzklassenlader instantiieren. Wenn das Objekt instantiiert wird, stellt die Anwendung einen Objektnamen zur Verfügung. Der Objektname kann irgendeine Domäne und irgendeinen Klassennamen beinhalten. Der Objektname sollte jedoch die folgenden Schlüsseleigenschaften beinhalten:

– Host (den Hostnamen, wo der Klassenserver läuft);
– Port (die zu verwendende Portnummer);
– Dienst (den Namen des aufzurufenden RMI-Dienstes).

Sobald ein Adapter initialisiert ist, ist die Anwendung bereit, Managementoperationen auf dem entfernten Agenten durchzuführen. Eine Anwendung kann eine Teilmenge der M-Beans oder alle von einem Agenten verwalteten M-Beans holen. Wenn Objekte geholte werden, kann eine Anwendung Anfragen spezifizieren. Die Ergebnisse des Holens können unter zwei verschiedenen Schemata erhalten werden:

– eine Liste von Objektnamen (durch einen Vektor repräsentiert);
– eine Liste von C-Beans (für jeden geholten Objektnamen instantiiert der Adapter eine C-Bean).

Um eine Eigenschaft einer entfernten M-Bean zu lesen, wird der Eigenschaftsname benötigt, wenn die AdaptorMO-Schnittstellenstufe unterer Stufe verwendet wird. Wenn die Schnittstelle oberer Stufe verwendet wird, wird die C-Bean geholt und dann wird ein der Eigenschaft zugeordneter Holer bzw. Getter aufgerufen.
Beim Setzen einer Eigenschaft einer entfernten M-Bean wird ein Eigenschaftsname und der Objekttyp der Eigenschaft benötigt, wenn die AdaptorMO-Schnittstellenstufe unterer Stufe verwendet wird. Wenn ein Wert gesetzt wird, ist es möglich, den Namen einer Operator-Klasse anzugeben. Auf der Seite des Agenten wird der angegebene Operator instantiiert und zum Setzen des Eigenschaftsnamens aufgerufen. Wenn die AdaptorMO-Schnittstellenstufe unterer Stufe verwendet wird, ist es möglich, mehrere Eigenschaften durch einen Methodenaufruf mittels einer Liste von Änderungen zu setzen.
Wenn die AdaptorMO-Schnittstellenstufe oberer Stufe verwendet wird, wird eine C-Bean erhalten und der Entwickler ruft dann das der Eigenschaft zugeordnete Setzen auf.
Durch die AdaptorMO-Schnittstelle ist es möglich, die Instantiierung von M-Beans innerhalb eines entfernten Agenten anzufordern. Wenn die Instantiierung angefordert wird, ist es möglich, einen neuen Klassenlader zu spezifizieren, durch den der Agent die neue, zu instantiierende Klasse laden soll. Der Klassenlader kann mittels seines Objektnamens spezifiziert werden. Wenn kein Klassenlader angegeben wird, verwendet der Agent den Standard-Klassenlader. Wenn eine entfernte M-Bean instantiiert wird, ist es möglich, direkt eine C-Bean zum Repräsentieren der neu kreierten M-Bean zu erhalten. Wenn kein Name mitgeliefert wird und wenn ein Namenserver spezifiziert wird, fragt der Adapter beim Namenserver an, um den Namen der auf Seiten des Agenten zu instantiierenden Java-Klasse zu erhalten. Ansonsten ist es die Verantwortlichkeit des Agenten, den Klassennamen der zu instantiierenden Klasse zu bestimmen. Wenn eine M-Bean in dem Agenten instantiiert wird, ist es möglich, explizit anzufordern, daß das Objekt persistent ist.
Durch die AdaptorMO-Schnittstelle ist es möglich, Java-Objekte von dem Client zu dem Agenten zu transferieren. Um dies zu tun, serialisiert die AdaptorMO-Schnittstelle das Objekt, sendet das Objekt hinüber und deserialisiert das Objekt in dem Agenten.
Durch die AdaptorMO-Schnittstelle ist es auch möglich, ein M-Bean-Objekt aus dem entfernten Agenten zu entfernen. Die M-Bean wird nicht aus der virtuellen Maschine entfernt, sondern nur aus dem Objektspeicher des Agenten.
17 ist ein Flußdiagramm, das eine Übersicht über die Schritte beim Kreieren und Betreiben eines Managementsystems, wie oben beschrieben, gibt, einschließlich der Schritte des Definierens eines Netzmanagementmodells einschließlich mindestens einer Management-Bean mittels einer Bean-basierten Umgebung und des Kompilierens dieses Modells, um das Computernetzmanagementsystem in der Bean-basierten Umgebung zu implementieren.
In Schritt 110 wird ein Modell mittels einer Bean-basierten Umgebung kreiert. Eine bevorzugte Bean-basierte Umgebung ist die Java-Umgebung, wobei die Beans JavaBeans sind.
Wie oben erwähnt bieten Beans einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung von Ereignissen und Selbstprüfung. Herkömmlicherweise ermöglichen die Eigenschaften, daß Beans programmtechnisch manipuliert werden, und sie unterstützen die kundenspezifische Anpassung der Beans, die Methoden implementieren die Eigenschaften, und die Unterstützung für Ereignisse ermöglicht es, daß Beans Ereignisse auslösen und die Ereignisse definieren, die sie auslösen können. Die Unterstützung für Selbstprüfung ermöglicht es, daß Eigenschaften, Ereignisse und Methoden der Bean von außerhalb inspiziert werden.
Dementsprechend beinhaltet Schritt 110 das Erzeugen mindestens einer Management-Bean, die mindestens eine Eigenschaft zum Modellieren einer Eigenschaft einer verwalteten Ressource und/oder einer Methode zum Modellieren einer Aktion für die verwaltete Ressource und/oder für mindestens ein Ereignis zum Modellieren eines Ereignisses der Ressource und/oder Unterstützung zur Selbstprüfung bereitstellt, die eine von außerhalb vorgenommene Analyse der Zusammensetzung der Bean erlaubt. Dieser Schritt beinhaltet auch das Definieren der Beziehung und der Interaktionen zwischen Management-Beans als Repräsentanten der Beziehungen und Interaktionen zwischen verwalteten Ressourcen. Dieser Schritt kann auch das Definieren mindestens eines Horcher- bzw. Listener-Ereignisses in Bezug auf mindestens eine Management-Bean beinhalten.
Es wurde zum ersten Mal in Bezug auf das vorliegende Netzmanagementsystem erkannt, daß Beans über ihre herkömmliche Rolle, ein Managementvehikel (Management-Bean) zum direkten Modellieren von zu verwaltende Ressourcen darzustellen, hinaus verwendet werden können. Zum Beispiel kann eine Eigenschaft in einer Management-Bean zum Modellieren einer Eigenschaft (z. B. eines Ressourcenattributs wie der Größe eines Hauptspeichers, der Anzahl von empfangenen Nachrichten in einem Puffer, etc.) einer verwalteten Ressource verwendet werden. Eine Methode einer Management-Bean kann zum Modellieren einer Aktion (z. B. eines System-Rücksetzens einer verwalteten Ressource verwendet werden. Eine Bean kann auch verwendet werden, um Unterstützung für ein Ereignis (zum Beispiel eines Platte-voll-Ereignisses) für eine verwaltete Ressource bereitzustellen. Zum Beispiel kann eine Management-Bean Unterstützung für ein Listener-Ereignis bereitstellen, wodurch eine Management-Bean auf ein Ereignis einer anderen Management-Bean reagieren kann. Durch die Unterstützung von Selbstprüfung kann eine Management-Bean eine von außen vorgenommene Analyse der Zusammensetzung der Bean und den Austausch von Information zwischen Beans ermöglichen. Management-Beans können Definitionen von Beziehungen und Interaktionen zwischen Management-Beans als Repräsentanten der Beziehungen und Interaktionen zwischen den verwalteten Ressourcen beinhalten.
Da Beans wiederverwendbare Softwarekomponenten sind, die visuell in einem Builder-Tool (z. B. einem Editor oder einem Builder mit graphischer Benutzerschnittstelle (GUI-Builder)) manipuliert werden können, kann in Schritt 110 ein Benutzer ein herkömmliches Builder-Tool wie das Java-Beans Development Kit verwenden, um das Managementsystemmodell einschließlich Beans, die Systemressourcen, ihre Funktionen und die Beziehungen zwischen und Interaktionen von Systemressourcen zu erstellen. Das Bean-Modell wird innerhalb einer virtuellen Maschine definiert, die die Bean-basierte Umgebung bildet, zum Beispiel ein Modell, das JavaBeans innerhalb einer virtuellen Java-Maschine verwendet. Dies erleichtert in großem Maße das Erstellen des Managementsystemmodells. Die Überprüfung und das Testen des Modells kann mittels Selbstprüfung und anderer Techniken einfach durchgeführt werden.
In Schritt 112 kann das Modell direkt mittels eines herkömmlichen Compilers, zum Beispiel des in 9 abgebildeten Compilers 60, für die Bean-basierte Umgebung kompiliert werden, sobald das Modell erzeugt worden ist. Durch Definieren eines Modells in einer Bean-basierten Umgebung ist es möglich, das Bean-basierte Modell direkt zu kompilieren, um eine Bean-basierte Implementierung mittels eines Standard-Compilers für die Bean-basierte Umgebung zu bilden, zum Beispiel durch Kompilieren der JavaBeans mittels eines Java-Compilers. Dementsprechend wird auch das resultierende Bean-Managementsystem innerhalb derselben Java-Umgebung definiert. Dies vereinfacht in großem Maße diese Stufe der Erzeugung eines Managementsystems, da der Compiler eine zuverlässige und homogene Implementierung des Modells erzwingt.
Im laufenden Betrieb stellt daher das vorstehend in diesem Dokument beschriebene Managementsystem in Schritt 114 eine robuste und einfach zu modifizierende Struktur bereit, ohne die Schwierigkeiten und Nachteile früherer Netzmanagementsysteme.
Schritt 144 beinhaltet die unter Bezug auf 12 beschriebenen Schritte: Registrieren einer oder mehrerer Management-Bean(s) bei dem erweiterbaren Agenten-Bezugssystem; Registrieren eines oder mehrerer Netzadapter (z. B. Netzadapter-Bean(s)) für ein Netzkommunikationsprotokoll bei dem erweiterbaren Agenten-Bezugssystem und Ermöglichen eines Zugriffs von außen über das Netz auf die Management-Bean(s) über die Netzadapter.
Wie unter Bezug auf 12 beschrieben, kann das erweiterbare Agenten-Bezugssystem eine zugeordnete Speicher-Bean beinhalten, und die Schritte zum Registrieren einer oder mehrerer Management-Bean(s) und/oder Netzadapter kann das Registrieren einer oder mehrerer Management-Bean(s) und/oder Netzadapter bei der Speicher-Bean aufweisen.
Es wurde die Erzeugung eines Netzmanagementsystems einschließlich des Zusammenstellens eines Netzmanagementmodells mittels einer Bean-basierten Umgebung und anschließendem Kompilieren des Modells zum Implementieren des Computernetzmanagementsystems in der Bean-basierten Umgebung beschrieben. Die Beans sind direkt in der Lage, die Charakteristiken von Komponenten eines zu modellierenden Systems zu modellieren. Die Beans können auch direkt kompiliert werden, um die Implementierung des Modells zu liefern. Als ein Ergebnis kann das Erfordernis einer von derjenigen, die zum Implementieren dieses Managementsystems verwendet wird, separaten Umgebung zum Modellieren eines Managementsystems vermieden werden.
Dementsprechend erkennt man, daß, auch wenn bestimmte Ausführungsformen der Erfindung beschrieben wurden, viele Modifikationen/Ergänzungen und/oder Ersetzungen innerhalb des Anwendungs- bzw. Gültigkeitsbereiches der vorliegenden Erfindung vorgenommen werden können.

Claims

Computerimplementiertes Verfahren zum Erzeugen eines Verwaltungssystems für ein Computernetzwerk mit den Schritten: a) Definieren eines Modells für eine Netzwerkverwaltung einschließlich zumindest eines Verwaltungsprogramms (Management-Bean) (29) unter Verwendung einer Umgebung auf (Bean-) Programmbasis, wobei das zumindest eine Verwaltungsprogramm in der Weise betreibbar ist, daß es eine Unterstützung für eine Selbstprüfung gewährleistet, welche die externe Analyse der Zusammensetzung des zumindest einen Verwaltungsprogramms erlaubt, und wobei das zumindest eine Verwaltungsprogramm derart ausgestaltet ist, daß es über eine graphische Benutzerschnittstelle eines Aufbauwerkzeugs und durch Selbstprüfung des zumindest einen Verwaltungsprogramms visuell manipuliert werden kann, und b) Kompilieren des Modells, um das Verwaltungssystem des Computernetzwerks in der Umgebung auf Bean-Programmbasis zu implementieren.
Verfahren nach Anspruch 1, wobei Schritt a) das Definieren des zumindest einen Verwaltungsprogramms aufweist, welches zumindest eine Eigenschaft zum Modellieren der Eigenschaft einer verwalteten Ressource bereitstellt.
Verfahren nach Anspruch 1 oder 2, wobei der Schritt a) das Definieren zumindest eines solchen Verwaltungsprogramms aufweist, das ein Verfahren zum Modellieren einer Aktion für die verwaltete Ressource einschließt.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Schritt a) das Definieren zumindest eines solchen Verwaltungsprogramms aufweist, welches eine Unterstützung für zumindest ein Ereignis zum Modellieren eines Ereignisses der Ressource bereitstellt.
Verfahren nach einem der vorstehenden Ansprüche, wobei Schritt a) das Definieren der Beziehungen und Wechselwirkungen zwischen Verwaltungsprogrammen als repräsentativ für die Beziehungen und Wechselwirkungen zwischen den verwalteten Ressourcen aufweist.
Verfahren nach Anspruch 5, welches das Definieren zumindest eines Beobachter- bzw. Empfängerereignisses in Bezug auf zumindest ein Verwaltungsprogramm aufweist.
Verfahren nach einem der vorstehenden Ansprüche, wobei Schritt b) aufweist: i) Registrieren zumindest eines derartigen Verwaltungsprogramms mit einem Agentensystem (24), ii) Registrieren zumindest eines Netzwerkadapters (30, 32, 34, 36, 38) für ein Netzwerkkommunikationsprotokoll in dem erweiterbaren Agentensystem, und iii) Ermöglichen eines externen Zugriffs über das Netzwerk auf das zumindest eine Verwaltungsprogramm über den zumindest einen Netzwerkadapter.
Verfahren nach Anspruch 7, wobei das erweiterbare Agentensystem ein zugehöriges Ablageprogramm (Bean) (27) aufweist und Schritt b) ii) das Registrieren des zumindest einen Verwaltungsprogramms und/oder des zumindest einen Netzwerkadapters in dem Ablageprogramm aufweist.
Verfahren nach Anspruch 8, wobei der zumindest eine Netzwerkadapter ein Netzwerkadapterprogramm (Bean) aufweist.
Computerprogrammprodukt, welches Programmanweisungen aufweist, die zum Durchführen des Verfahrens nach einem der vorstehenden Ansprüche ausführbar sind.
Computerprogrammprodukt nach Anspruch 10 auf einem Trägermedium.
Verwaltungssystem für ein Computernetzwerk mit: einer objektbasierten Umgebung zur Modulierung einer Netzwerkverwaltung einschließlich zumindest eines Verwaltungsprogramms (Management-Bean) (29), wobei das zumindest eine Verwaltungsprogramm einer Ressource entspricht, die durch einen Agenten (20) kontrolliert und überwacht wird, wobei das zumindest eine Verwaltungsprogramm in der Weise betreibbar ist, daß es eine Unterstützung für eine Selbstprüfung gewährleistet, welche eine externe Analyse der Zusammensetzung des zumindest einen Verwaltungsprogramms erlaubt und wobei das zumindest eine Verwaltungsprogramm so ausgestaltet ist, daß es über eine graphische Benutzerschnittstelle eines Aufbauwerkzeuges und durch Selbstprüfung des zumindest einen Verwaltungsprogramms visuell manipuliert werden kann, einem Aufbauwerkzeug zum visuellen Manipulieren des zumindest einen Verwaltungsprogramms über eine graphische Benutzerschnittstelle, wobei das Aufbauwerkzeug beim visuellen Manipulieren des zumindest einen VerwaVerwltungsprogrammsltungsprogramms so ausgelegt ist, daß es eine externe Analyse der Zusammensetzung des zumindest einen Verwaltungsprogramms durch Selbstprüfung des zumindest einen Verwaltungsprogramms ausführt, einem Kompilierer für die objektbasierte Umgebung zum Erzeugen der Implementierung des Verwaltungssystems des Computernetzwerks in der objektbasierten Umgebung.
System zur Verwaltung eines Computernetzwerks nach Anspruch 12, wobei das zumindest eine Verwaltungsprogramm zumindest eine Eigenschaft zum Modellieren einer Eigenschaft einer verwalteten Ressource aufweist.
System zur Verwaltung eines Computernetzwerks nach Anspruch 12 oder 13, wobei das zumindest eine Verwaltungsprogramm ein Verfahren zum Modellieren einer Aktion für die verwaltete Ressource umfaßt.
System zur Verwaltung eines Computernetzwerks nach einem der Ansprüche 12 bis 14, wobei das zumindest eine Verwaltungsprogramm mit einer Unterstützung für zumindest ein Ereignis zum Modellieren eines Ereignisses der Ressource ausgestattet ist.
System zur Verwaltung eines Computernetzwerks nach einem der Ansprüche 12 bis 15, wobei eine Mehrzahl von Verwaltungsprogrammen, welche die Beziehungen und Wechselwirkungen zwischen den Verwaltungsprogrammen definieren, für die Beziehungen und Wechselwirkungen zwischen den verwalteten Ressourcen repräsentativ sind.
System zur Verwaltung eines Computernetzwerks nach Anspruch 16, wobei das zumindest eine Verwaltungsprogramm mit einer Unterstützung für ein Beobachter- bzw. Zuhörerereignis ausgestattet ist.
System zur Verwaltung eines Computernetzwerks nach einem der Ansprüche 12 bis 16, wobei das kompilierte System einen Netzwerkagenten umfaßt, welcher aufweist: ein Objekt (24) für einen erweiterbaren Systemdienst, zumindest ein Verwaltungsprogramm, welches bei dem Systemdienst registrierbar ist, zumindest ein Netzwerkadapterprogramm (30, 32, 34, 36, 38), welches in dem Systemdienst für ein Netzwerkkommunikationsprotokoll registrierbar ist, um einen Zugriff auf die Verwaltungsprogramme zu gewähren.
System zur Verwaltung eines Computernetzwerks nach Anspruch 18, wobei der Netzwerkagent ein zugehöriges Ablageprogramm (27) aufweist, wobei das zumindest eine Verwaltungsprogramm und/oder der zumindest eine Netzwerkadapter in dem bzw. durch das Ablageprogramm registrierbar sind.