DE69832354T2

DE69832354T2 - Netzwerkverwaltungsrahmenwerk

Info

Publication number: DE69832354T2
Application number: DE69832354T
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-07-20
Anticipated expiration: 2018-09-25
Also published as: EP0909058B1; JPH11232239A; DE69832354D1; EP0909058A3; US6134581A; CA2249484A1; EP0909058A2

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf Netzwerkverwaltungssysteme und auf ein Grundgerüst (Framework) und Verfahren für derartige Systeme.
Netzwerkverwaltungssysteme finden ihre Anwendung auf die Fernverwaltung von Systemen über ein Telekommunikationssystem. Es sind Netzwerkverwaltungssysteme bekannt, welche die Manipulation bzw. Handhabung und Steuerung einer großen Anzahl und Vielfalt von Objekten über ein Netzwerk entsprechend einem relativ begrenzten Satz von Befehlen, einschließlich Operationen wie z. B. GET, SET, ACTION, CREATE und DELETE ermöglichen. Ein Beispiel eines solchen Netzwerkverwaltungssystems ist die sogenannte Telekommunikations-Management-Network (TMN)-Umgebung.
Die TMN-Umgebung sieht ein gemeinsames Managementinformationsprotokoll (CMIP) nach Industriestandard vor und unterstützt unter diesem Protokoll die „Common Management Information Services (CMIS) gemäß X710/ISO 9595. Diese Dienste ermöglichen die Manipulation einer großen Anzahl und Vielfalt von Objekten über ein Netzwerk entsprechend einem relativ begrenzten Satz von Befehlen einschließlich von Operationen wie z. B. GET, SET, ACTION, CREATE und DELETE.
Die physikalische Ausgestaltung des Netzwerkes, auf welchem das Netzwerkverwaltungssystem konfiguriert ist, kann viele verschiedene Formen annehmen, einschließlich beispielsweise die eines öffentlichen, geschalteten Telefonnetzes und/oder eines Local Area Network oder eines speziell zugeordneten Netzwerks, welches Computer und andere Ausrüstungsgegenstände innerhalb eines lokalen Bereiches oder auch über einen größeren Bereich oder ein offenes Netzwerk, wie z. B. das Internet oder ein Intranet verbindet. Die Objekte weisen üblicherweise Parameter und Methoden auf, die verwendet werden, um einen Ausrüstungsgegenstand, eine Komponente dieser Ausrüstung, einen Betrieb der Ausrüstung oder eine Komponente derselben usw. zu modellieren.
In der TMN-Umgebung werden Objekte beispielsweise definiert nach ISO-Standard X722/ISO-10165-4 entsprechend den Richtlinien für die Definition verwalteter Objekte (GDMO). Die GDMO definieren Daten oder Parameter und Arten entsprechend der X208/ISO-8824 Abstract Syntax Notation One (ASN.1) und der X209/ISO-8825 Beschreibung der grundlegenden Kodierregelen für die abstrakte Notation 1 (BER) für die Datennotation. Diese verschiedenen Indus-triestandards sind definiert durch die Internationale Standardorganisation (ISO).
GDMO ist eine formale, beschreibende Sprache, die von einem Computer nicht direkt verstanden wird. Es ist deshalb notwendig, GDMO in ein für einen Computer verständliches Format umzuwandeln. Da es für einen solchen Vorgang keinen Standard gibt, führt dies oftmals zu Mehrfachinterpretationen, was wiederum zu Problemen bei der wechselseitigen Zusammenarbeit bzw. der Zusammenarbeit der einzelnen Komponenten führt.
Um das CMIS aufzurufen, ist es erforderlich, eine Anwendungsprogrammschnittstelle (Application Programming Interface – API) bereitzustellen. Typischerweise sind APIs unter Verwendung von Programmiersprachen wie z. B. C oder C++ erzeugt worden. Eine programmbasierte API für die ASN.1- und GDMO-Standards führt jedoch zu Schwierigkeiten, wenn die Netzwerkdienste erweitert werden sollen. Beispielsweise durch Definieren neuer Typen und Instanzen von Objekten (beispielsweise ein neuer Typ einer Workstation für einen Netzwerkmanager). Ein weiteres Problem bei existierenden Netzwerkverwaltungssystemen liegt darin, daß sie hinsichtlich der Protokolle, welche die Netzwerkmanagementagenten unterstützen können, beschränkt sind. Mit anderen Worten, der konventionelle Ansatz für das Bereitstellen einer API ist in einer dynamischen Netzwerkverwaltungsumgebung problematisch.
Das US-Patent 5,315,703 und das US-Patent 5,367,633 beschreiben objektbasierte Systeme, welche eine Struktur zum Ermöglichen von Funktionen der Kennzeichnung von Veränderungen enthalten. Diese Patente beschreiben jedoch isolierte Systeme.
Ein Artikel mit dem Titel „The Common Agent – A Multiprotocol Management Agent" von Newkerk et al, veröffentlicht im IEEE Journal on Selected Areas in dem IEEE Journal on Selected Areas in Comunications II (1993), Dezember, Nr. 9 beschreibt einen üblichen Agenten, der eine Implementierung eines dem ISO-Standard entsprechenden Verwaltungsagenten bildet, der mehrere Verwaltungsprotokolle und die Laufzeitaddition neuer Klassen verwalteter Objekte unterstützt. Die Protokollverarbeitung bei dem üblichen bzw. gemeinsamen Agenten wird gesteuert durch getrennte Prozesse, die Protokollmaschinen genannt werden. Jede Protokollmaschine ist u.a. für das Zuführen einer Schnittstelle zu einem Netzwerkstab und für das Abfertigen der verwalteten Objekte verantwortlich. Der gemeinsame Agent ermöglicht, daß sowohl verwaltete Objekte als auch Protokolle dynamisch zu dem System hinzugefügt oder von diesem entfernt werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Aspekt der vorliegenden Erfindung stellt einen Netzwerkagenten für ein Telekommunikationsnetzwerk bereit, wobei der Netzwerkagent aufweist: Eine erweiterbare Struktur bzw. ein erweiterbares Grundgerüst, eine oder mehrere verwaltete Objekte, die innerhalb des Grundgerüstes registriert werden können und einen oder mehrere Netzwerkadapter, die innerhalb des Grundgerüstes für ein Netzwerkkommunikationsprotokoll registriert werden können, um einen Zugriff auf die verwal teten Objekte zu ermöglichen, wobei ein solches verwaltetes Objekt ein Bean ist, welches einen Satz von Eigenschaften, einen Satz von Methoden zum Ausführen von Aktionen und eine Unterstützung für Ereignisse und für die Selbstprüfung aufweist.
Die Beans (Teilprogramme) können implementiert sein als JavaBeans-Komponenten (Java-Beans ist eine Marke von Sun Microsystems, Inc.). Beans sind wiederverwendbare Softwarekomponenten, die in einem Zusammenbauwerkzeug (beispielsweise einem Editor oder einer Aufbaueinrichtung einer graphischen Benutzerschnittstelle (GUI-Aufbaueinrichtung)) visuell manipuliert werden können. Ein Beispiel eines Aufbauwerkzeuges ist der JavaBeans-Entwicklungssatz (Development Kit). Weitere Einzelheiten über Beans kann man in vielen verschiedenen Arbeiten finden, beispielsweise in einem Buch mit dem Titel "Mastering JavaBeans") von Lawrence Vanhelsuwe, veröffentlicht von Sybex (ISBN 0-7821-2097-0). Dies ist nur ein Beispiel von vielen weitestgehend equivalenten Büchern auf dem Markt, die „JavaBeans" in ihrem Titel tragen und die JavaBeans beschreiben. Viele dieser Arbeiten einschließlich des Buches "Mastering JavaBeans" liefern den Bean-Entwicklungssatz, der oben erwähnt wurde.
Beans variieren in ihrer Funktionalität, aber sie verwenden typischerweise gemeinsame Definitionsmerkmale, die einen Satz von Eigenschaften, einen Satz von Methoden und eine Unterstützung für Ereignisse und für die Selbstprüfung aufweisen, die auch als Reflektion bekannt ist. Diese Eigenschaften erlauben es, daß Beans programmtechnisch manipuliert werden können und sie unterstützen eine maßgeschneiderte Anpassung des Bean. Die Methoden implementieren die Eigenschaften. Die Unterstützung für Ereignisse ermöglicht es den Beans, Ereignisse auszugeben („abzufeuern") und die Ereignisse zu definieren, die abgegeben bzw. „abgefeuert" werden können. Die Unterstützung der Selbstprüfung ermöglicht es, daß die Eigenschaften, Ereignisse und Methoden des Bean extern untersucht werden.
Dies bedeutet, daß, wenn man verwaltete Objekte mit dem Netzwerkverwaltungssystem entwickelt, es nicht notwendig ist, zu wissen, über welches Kommunikationsprotokoll auf das verwaltete Objekt zugegriffen wird.
Eine Ausführungsform der Erfindung kann ein erweiterbares Grundgerüst für einen Netzwerkagenten mit verwalteten Objekten und Netzwerkadaptern bereitstellen, die dem Grundgerüst zugeordnet oder in diesem registriert werden können, wobei ein flexibler Netzwerkagent, beispielsweise ein Netzwerkmanagementagent, vorgesehen werden kann, der in anpaßbarer Weise erweitert werden kann, um sich wechselnden Umständen anzupassen. Indem die Zuordnung oder Registrierung von unterschiedlich verwalteten Objekten je nach Erfordernis angepaßt wird, kann die Erweiterung der Struktur zur Einbeziehung neuer Objekte für die Verwaltung neuer oder geänderter Ressourcen in einfacher Weise ermöglicht werden. Indem man eine wahlweise Verbindung unterschied licher Netzwerkadapter zuläßt, die vorzugsweise als Objekte implementiert sind, können die Protokolle für die Verwaltung der verwalteten Objekte ganz nach Erfordernis ausgewählt werden.
Managementdienste können in dem Grundgerüst in dynamischer Weise registriert werden, um eine skalierbare Managementumgebung bereitzustellen. Ein Beispiel eines Management- bzw. Verwaltungsdienstes ist ein Ablagedienst.
Ein Ablagedienstobjekt kann in dem Grundgerüst registrierbar sein, wobei das verwaltete Objekte bzw. die verwalteten Objekte und/oder die Netzwerkadapter (und/oder weitere Managementdienste) bei dem Ablagedienstobjekt registrierbar sind, wodurch das verwaltete Objekt und die Netzwerkadapter indirekt über das Ablagedienstobjekt in dem Grundgerüst registrierbar sind. Das Grundgerüst kann dann Zugriff auf die verwalteten Objekte und die Netzwerkadapter über das Ablageobjekt gewähren, oder indem es darauf weist. Das Ablagedienstobjekt stellt aktiv einen Verbindungsmechanismus zwischen dem Grundgerüst und den verwalteten Objekten und den Netzwerkadaptern bereit. Dies bietet eine besonders flexible Struktur für die dynamische Erweiterung der Agentenstruktur.
Das Grundgerüst kann Hol- und Setzeigenschaften (Getter- und Setter-Eigenschaften) aufweisen und implementiert Hol- und Setzmethoden für das Heranholen und/oder Einstellen (Setzen) von Objekten und/oder Objektmethoden. Um die Handhabung von Objekten aus der Ferne bereitzustellen, können der bzw. die Netzwerkadapter auf eine empfangene externe Anforderung reagieren, um zu bewirken, daß das Grundgerüst eine verwaltete Objektmethode für die Anforderung holt und eine nachfolgende Antwort liefert. Soweit der Ablagedienst bereitgestellt wird, verweist das Grundgerüst auf den Ablagedienst, um die verwaltete Objektmethode aufzurufen. Das Grundgerüst kann so ausgelegt sein, daß es Funktionen für das Hinzufügen und das Entfernen von Objekten zum Implementieren dynamischer Skalierung der Verwaltungsstruktur bewirkt. Das Grundgerüst kann vorzugsweise als ein Bean einschließlich Heranhol- und Setzeigenschaften mit Methoden zum Implementieren dieser Eigenschaften und zur Unterstützung für Vorgänge des Hinzufügens und des Entfernens von Objekten implementiert sein.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zur Bereitstellung von Agentendiensten über ein Telekommunikationsnetzwerk bereitgestellt, wobei das Verfahren die Schritte aufweist: Dynamisches Registrieren eines oder mehrerer verwalteter Objekte in bzw. bei einem erweiterbaren Agenten-Grundgerüst, Registrieren eines oder mehrerer Netzwerkadapter für ein Netzwerkkommunikationsprotokoll in das Grundgerüst, und Ermöglichen des Zugriffes auf das bzw. die verwaltete(n) Objekt(e) über den/die Netzwerkadapter, wobei ein solches verwaltetes Objekte ein Bean ist, das einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und für die Selbstüberprüfung aufweist.
KURZE BESCHREIBUNG DER FIGUREN
Ausführungsformen der vorliegenden Erfindung werden nachstehend lediglich anhand eines Beispiels unter Bezug auf die beigefügten Zeichnungen beschrieben, in denen gleiche Bezugszahlen sich auf gleiche Elemente beziehen und in denen:
1 eine schematische Wiedergabe von drei über ein Telekommunikationsnetzwerk verbundenen Stationen ist,
2 und 2A eine schematische Wiedergabe eines Computerservers für eine Station nach 1 darstellen,
3 eine schematische Wiedergabe eines Agenten für eine verwaltete Station ist,
4 eine alternative Darstellung des Agenten nach 3 ist,
5 ein Beispiel einer Konfiguration für einen Agenten ist,
6 ein Flußdiagramm ist, welches Operationen veranschaulicht, die einen Agenten verwenden, wie er in 5 dargestellt ist,
7 ein Beispiel einer Konfigurierung eines Managementsystems,
8 ein weiteres Beispiel einer Konfigurierung eines Managementsystems ist,
9 einen Aspekt der Erzeugung der Konfiguration nach 8 veranschaulicht,
10 ein Flußdiagramm ist, welches Operationen des Systems nach 8 zeigt,
11 ein Flußdiagramm ist, welches die Operation eines Namensgebungsdienstes veranschaulicht,
12 ein Flußdiagramm ist, welches die Operation der Erzeugung eines generischen Agenten veranschaulicht,
13 und 14 alternative Operationen eines Compilers zeigen,
15A und 15B verwendet werden, um den Effekt des Kompilierens eines Managementbeans veranschaulichen,
16A und 16B ebenfalls verwendet werden, um den Effekt der Kompilierung eines Managementbeans zu zeigen, und
17 ein Flußdiagramm ist, das Schritte beim Erzeugen eines Managementsystems veranschaulicht.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
1 ist eine schematische Wiedergabe eines auf einem Netzwerk mit mehreren Stationen basierenden Systems 1 mit drei Stationen oder Knoten oder Maschinen 3, 4 und 5, welche über ein Netzwerk 2 verbunden sind. Das Netzwerk 2 kann auf einem öffentlichen Telefonnetzwerk oder einem Local Area Netzwerk und/oder einem speziellen Netzwerk beruhen, das Computer und andere Ausrüstungsgegenstände innerhalb eines lokalen Bereiches und/oder über einen größeren Bereich hinweg und/oder in einem offenen Netzwerk wie z. B. dem Internet oder einem Intranet oder mit einer Kombination derselben oder auch mit irgendeinem anderen Telekommunikationsnetzwerk mit einander verbindet, das den Austausch der Telekommunikationsverwaltungsinformation unterstützen kann. Das Netzwerk kann irgendeine gewünschte Struktur, wie z. B. eine ebene Struktur, eine Pyramidenhierarchie, etc. haben.
Eine oder mehrere der Stationen 3, 4 oder 5 können als eine Netzwerkverwaltungsstation bzw. Netzwerkmanagementstation konfiguriert sein. In dem in 1 dargestellten Beispiel sei angenommen, daß die Station 3 eine Managementstation ist, und das die Stationen 4 und 5 verwaltete Stationen sind (A. d. Ü.: Die Begriffe „Management" und „Verwaltung" bzw. „managed" und „verwaltet" werden im vorliegenden Text synonym verwendet.). Es versteht sich, daß irgendeine beliebige Anzahl von Verwaltungsstationen und verwalteten Stationen vorgesehen werden kann und daß die drei Stationen nach 1 lediglich veranschaulichenden Zwecken dienen. Auch die verwaltenden und verwalteten Funktionen könnten ausgetauscht sein oder es könnten auch sowohl die Verwaltungs- als auch die verwalteten Funktionen an ein- und derselben Station unterstützt werden.
Die Stationen können viele Formen annehmen. Für Zwecke der Veranschaulichung sei angenommen, daß beide Computerworkstations aufweisen. 2 ist eine schematische Wiedergabe der Konfiguration einer Computerworkstation. Wie in 2 dargestellt, ist diese implementiert durch einen Servercomputer 10, der eine Systemeinheit 11 mit einer Anzeige 8, einer Tastatur und anderen Eingabeeinrichtungen 9 aufweist. 2A ist eine schematische Blockdarstellung von Aspekten der Inhalte bzw. Gegenstände der Systemeinheit 11. Wie in 2A dargestellt, enthält die Systemeinheit einen Prozessor 17, einen Speicher 18, magnetische und/oder optische Laufwerke 13 und 14 und einen Kommunikationsadapter 16 für die Verbindung mit einer oder mehreren Telekommunikationsleitungen 15 für die Verwendung mit dem Kommunikationsnetzwerk 2. Wie in 2A veranschaulicht, sind die Komponenten des Systems über eine Busanordnung 19 miteinander verbunden. Es versteht sich, daß die Figuren 2/2A eine generelle schematische Wiedergabe einer möglichen Konfiguration für einen Servercomputer zum Bilden eines Routers sind. Es versteht sich, daß viele alternative Konfigurationen ebenfalls vorgesehen werden könnten.
Soweit die Workstation eine Managementstation implementiert, werden die Managementanwendung oder -anwendungen und Schnittstellenstrukturen typischerweise durch Software bereitgestellt, die in dem Speicher der Workstation gespeichert und durch den Prozessor der Workstation ausgeführt wird. Soweit die Workstation eine verwaltete Station implementiert, reagiert ein Agent auf Managementanforderungen von Managementanwendungen über das Netzwerk aus der Ferne, um eine Schnittstelle zu verwalteten Objekten an den verwalteten Stationen bereitzustellen. Der Agent und die verwalteten Objektstrukturen werden typischerweise durch Software bereitgestellt, die in dem Speicher der Workstation gespeichert ist und durch den Prozessor der Workstation ausgeführt wird.
Die Objekte weisen typischerweise Parameter und Methoden auf, die verwendet werden, um einen Ausrüstungsgegenstand, ein Bauteil dieser Ausrüstung, eine Funktionsweise bzw. Operation der Ausrüstung oder eine Komponente oder Ressource derselben usw. zu modellieren.
Die Verwaltung eines Telekommunikationsnetzwerkes erfordert Anwendungen unterschiedlicher Größe und Komplexität. Schwere- bzw. Schwerlastmanager, mittlere Manager, erweiterbare Agenten, intelligente Agenten und Anwendungen haben alle ihre Rolle in der Verwaltung eines Telekommunikationsnetzwerkes. Ein Netzwerkmanagementsystem, welches die vorliegende Erfindung beinhaltet, stellt ein erweiterbares AgentenGrundgerüst bereit, welches ermöglicht, daß alle diese unterschiedlichen Anwendungstypen auf derselben Architektur aufbauen. Dieses erweiterbare Agenten-Grundgerüst wird bereitgestellt durch eine Komponente des Netzwerkmanagementsystems. Alternative Begriffe für das erweiterbare Grundgerüst in diesem Kontext könnte sein: „dynamisches Grundgerüst" oder „offenes Grundgerüst" bzw. „dynamisches oder offenes Rahmenwerk", oder „Laufzeitkomponente" bzw. "Bezugssystem", auch wenn hier die Begriffe „Grundgerüst", „Rahmenwerk" oder „erweiterbares Agenten-Grundgerüst" verwendet werden.
Das Netzwerkverwaltungssystem wird über einen Satz von Kernmanagementdiensten zugeführt. Es kann aus diesem Satz von Diensten eine Auswahl getroffen werden und er kann erweitet werden, um spezielle Anwendungen zu entwickeln. Unterschiedliche Dienste werden statisch oder dynamisch in das Grundgerüst geladen, um die Erfordernisse einer bestimmten Anwendung zu erfüllen.
Ein verwaltetes Objekt in einem Beispiel eines Netzwerkagenten, welcher die vorliegende Erfindung beinhaltet bzw. inkorporiert, ist vorzugsweise als ein Bean implementiert, noch bevorzugter als eine JavaBeans-Komponente. Ein Bean (und eine JavaBeans-Komponente) ist eine wiederverwendbare Softwarekomponente, die visuell in einem Aufbauwerkzeug manipuliert werden kann (d.h. in einem Editor oder einer Aufbaueinrichtung mit graphischer Benutzerschnittstelle (GUI-Aufbauwerkzeug)). Ein Beispiel eines Aufbauwerkzeuges ist der JavaBeans-Entwicklungssatz (JavaBeans Development Kit). Beans variieren hinsichtlich ihrer Funktionalität, verwenden jedoch typischerweise gewisse gemeinsame definierende Merkmale, die einen Satz von Eigenschaften, einen Satz von Methoden für die Durchführung von Aktionen und die Unterstützung für Ereignisse oder die Selbstuntersuchung oder Selbstprüfung bereitstellen. Die Eigenschaften ermöglichen es, daß Beans programmtechnisch manipuliert werden und unterstützen eine maßgeschneiderte Herstellung des Bean. Die Methoden implementieren die Eigenschaften. Unterstützung für Ereignisse ermöglicht es Beans, Maßnahmen zu treffen bzw. Ereignisse oder Abläufe auszulösen und die Ereignisse zu definieren, die ausgelöst werden können. Die Unterstützung für die Selbstuntersuchung ermöglicht es, daß die Eigenschaften, Maßnahmen bzw. Abläufe und Methoden des Bean von außen überprüft bzw. untersucht werden können. Operationen wie z. B. GET, SET, ACTION, CREATE und DELETE (Heranholen, Setzen bzw. Einstellen, Ausführen, Erzeugen und Löschen) können unterstützt werden.
Ein verwaltetes Objekt in dem Agenten kann verwaltet werden, sobald es in dem Grundgerüst registriert ist. Diese Anordnung ermöglicht es einem Agenten, der gemäß diesem Netzwerkverwaltungssystem entwickelt ist, daß er mit minimaler Einwirkung auf das Design bzw. die Auslegung des Agenten verwaltet werden kann.
Wie oben erwähnt, verwendet ein Beispiel des Netzwerkmanagementsystems das Model einer JavaBeans-Komponente und erleichtert damit die Entwicklung von Anwendungen. In diesem Beispiel sind alle Kernmanagementdienste als JavaBeans-Komponenten vorgesehen. Man kann darauf Zugriff nehmen unter Verwendung eines Aufbauwerkzeuges einer Java-Anwendung, wie z. B. des allgemein bekannten JavaBeans-Entwicklungssatzes (Development Kit). Verwaltete Objekte werden als JavaBeans-Komponenten entwickelt. Auf eine JavaBeans-Komponente in dem Netzwerkmanagementsystemagenten kann lokal oder aus Ferne zugegriffen werden. Dies bedeutet, daß beim Entwickeln verwalteter Objekte in dem Netzwerkmanagementsystem es nicht notwendig ist, zu wissen, über welches Kommunikationsprotokoll auf das verwaltete Objekt zugegriffen wird. Das Netzwerkmanagementsystem vereinfacht die Entwicklung erweiterbarer Agenten. Ein Satz von Kernmanagementdiensten, welche das Netzwerkmanagementsystem bereitstellt, kann erweitert und in einen Agenten geladen werden, während er läuft. Die meisten der Kernmanagementdienste sind optional. Dies bedeutet, daß ein Agent, der unter Verwendung des Netzwerkmanagementsystems entwickelt wurde, nur den Dienst implementieren muß, den er verwendet. Diese Eigenschaft ermöglicht die Entwicklung von Agenten unterschiedlicher Größe und Komplexität.
Agenten, die unter Verwendun des Netzwerkmanagementsystems entwickelt wurden, sind außerdem intelligente Agenten. Ein intelligenter Agent stellt den Dienst bereit, der benötigt wird, um Verwaltungsanforderungen abzuarbeiten. In einem intelligenten Agenten kann viel von der Verarbeitung lokal in dem Agenten selbst erfolgen, was die Belastung der Netzwerkverbindung zwischen dem Agenten und dem Verwaltungssystem reduziert.
3 veranschaulicht einen Aspekt der Architektur eines Netzwerkmanagementsystemagenten, einschließlich der Beziehungen zwischen den Komponenten des Netzwerkmanagementsystems. 3 zeigt auch die Beziehung zwischen dem Netzwerkmanagementsystemagenten und Managementanwendungen.
Wie in 3 dargestellt, besteht der Netzwerkmanagementsystemagent aus einer Anzahl von Komponenten innerhalb einer virtuellen Java-Maschine (VM). Diese umfassen:

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

Diese Komponenten werden nachfolgend genauer beschrieben.
Ein verwaltetes Objekt ist eine Softwareabstraktion einer Ressource, die durch einen Agenten gesteuert und überwacht wird. Ein verwaltetes Objekt (beispielsweise 28), wird als ein Managementbean oder M-Bean bezeichnet. In einem Beispiel des Netzwerkmanagementsystems sind alle M-Beans als JavaBeans-Komponenten implementiert. Daher kann auf diese unter Verwendung eines konventionellen Aufbaus für Java-Anwendungen, wie z. B. den JavaBeans-Entwicklungssatz, der bereits erwähnt wurde, zugegriffen werden.
Wie für irgendein anderes verwaltetes Objekt hat ein M-Bean einen Satz von Eigenschaften, kann einen Satz von Aktionen ausführen und kann einen Satz von Meldungen oder Vorgängen bzw. Maßnahmen ausgeben. Das Netzwerkmanagementsystem ermöglicht, daß eine Unterscheidung getroffen werden kann zwischen einer Nur-Lese und einer Lese-Schreibe-Eigenschaft in einem M-Bean.
Ein M-Bean ist verwaltbar, sobald ihm ein Objektnahme zugeordnet worden ist. Der Objektname kennzeichnet das M-Bean innerhalb der M-Bean-Ablage (siehe unten) eindeutig. Er ermöglicht, daß eine Verwaltungsanwendung das M-Bean identifiziert, auf welchem sie einen Verwaltungsvorgang anwenden bzw. ausführen soll. Der Objektname eines M-Beans ist ein willkürlicher Name, der in keiner Weise davon abhängt, wie das M-Bean implementiert wird.
Das Grundgerüst 24 steuert die Managementdienste und M-Beans eines Agenten 20 werden in das Grundgerüst 24 geladen. Das Grundgerüst 24 ist eine JavaBeans-Komponente, welche einen Satz von Eigenschaften, einen Satz von Methoden für die Durchführung von Aktionen und Unterstützung für Maßnahmen bzw. Abläufe und für die Selbstuntersuchung aufweist. Die Eigenschaften umfassen Heranhol- und Setzeigenschaften. Diese Methoden umfassen Methoden zum Implementieren der Heranhol- und Setzeigenschaften. Das Grundgerüst ist auch in der Lage, Funktionen der Hinzufügung und Entfernung von Objekten zu bewirken.
Sobald eine Anforderung an einen Agenten 20 gerichtet wird, eine über einen Netzwerkadapter empfangene Management- bzw. Verwaltungsoperation auszuführen, ruft das Grundgerüst 24 den geeigneten Dienst auf, um die angeforderte Operation durchzuführen. Das Grundgerüst 24 handhabt auch die Kommunikationen zwischen M-Beans 28 und den Servern 30–38 des verwalteten Objektes. Ein M-Bean kann das Grundgerüst 24 befragen, um Informationen über andere M-Beans 28 zu erhalten, die in derselben Instanz des Grundgerüstes 24 geladen sind. Nur eine Instanz des Grundgerüstes 24 ist in einer virtuellen Maschine 22 zugelassen.
Das Netzwerkmanagementsystem bietet eine Anzahl von Kernmanagementdiensten. In einem Beispiel des Systems sind die Kernmanagementdienste definiert als Java-Schnittstellen. Die Kernmanagementdienste sind optional. Dies bedeutet, daß ein Agent, der unter Verwendung des Netzwerkmanagementsystems entwickelt wurde, nur die Dienste implementieren muß, die er verwendet. Die Kernmanagementdienste können als M-Beans registriert sein, was es ermöglicht, daß einige Managementvorgänge mit ihnen ausgeführt werden, um ihr Verhalten abzustimmen.
In dem bevorzugten Beispiel des Systems sind die Kernmanagementdienste als JavaBeans-Komponenten bereitgestellt. Es ist daher möglich, auf sie zuzugreifen unter Verwendung eines konventionellen Aufbauwerkzeuges einer Java-Anwendung, wie z. B. des JavaBeans-Entwicklungssatzes, der schon erwähnt wurde.
Eine Anzahl der Kernmanagementdienste soll nun beschrieben werden.
Der M-Bean-Ablagedienst 27 enthält Zeiger auf M-Beans. Jedes Mal, wenn ein M-Bean in dem Grundgerüst 24 registriert wird, ruft das Grundgerüst 24 den M-Bean-Ablagedienst 27 auf, um die Identität des M-Beans zu speichern. Einem M-Bean wird ein Name zugeordnet. Wenn die M-Bean-Ablage 27 befragt wird, können Agenten- und Verwalteranwendungen ein M-Bean anhand seines Namens identifizieren. Unterschiedliche Implementierungen des M-Beans-Ablagedienstes 27 sind möglich. Eine Implementierung verwendet eine relationale Datenbank für das Speichern dauerhafter M-Beans während eine andere Implementierung einen einfachen Speicher für das Speichern nicht dauerhafter M-Beans verwendet.
Unter Berücksichtung der Struktur, die durch die Ablageeinheit bereitgestellt wird, ist eine alternative Darstellung der Beziehung zwischen Komponenten des Agenten in 4 dargestellt. Dies berücksichtigt die Registrierung der Beans für die Adapterserver des verwalteten Objektes, die Managementdienste und die verwalteten Objekte mit dem Service-Bean der M-Bean-Ablage.
Ein Filterdienst 29 wählt M-Beans als Gegenstand eines Verwaltungsvorganges aus. Die Auswahl erfolgt auf Basis der Anwesenheit und der Werte spezieller Attribute. Beispielsweise könnte ein Filter alle diejenigen M-Beans auswählen, für welche die Attributfarbe auf rot gesetzt ist.
Ein Metadatenservice 25 stellt Information über die Struktur eines M-Beans bereit. Beispielsweise fragt das Grundgerüst 24 den Metadatendienst 25 nach Zugriffsmethoden für das Holen und Einstellen einer Eigenschaft innerhalb eines M-Beans. Der Metadatenservice 25 beruht auf der Reflektions-API, die durch den JavaBeans-Entwicklungssatz für die Durchführung einer Selbstprüfung bereitgestellt wird.
Ein dynamischer Klassenladungsdienst lädt neue Klassen in das Grundgerüst 24. Eine neue Klase wird geladen, wenn ein Fernantrag die Erzeugung von Instanzen einer Klasse anfordert, welche nicht in das Grundgerüst bzw. in den Arbeitsrahmen 24 geladen sind. Eine neue Klasse kann von einem entfernten Klassenserver geladen werden. Der dynamische Ladedienst ermöglicht auch, daß Kernmanagementdienste einem Netzwerkverwaltungssystemagenten hinzugefügt werden, während er läuft. Beispielsweise könnte ein Agent ohne einen Filterdienst gestartet werden. Dann könnte später der Filterdienst dynamisch zu dem Agenten hinzugefügt werden, wenn er erforderlich ist.
Ein Zugangskontrolldienst kann bereitgestellt werden, um den Zugriff auf M-Beans zu kontrollieren. Vor dem Versuch, einen Verwaltungsvorgang mit einem M-Bean auszuführen, kann das Grundgerüst bzw. der Arbeitsrahmen 24 so ausgelegt sein, daß er den Zugangskontrolldienst befragt, um zu verifizieren, daß die Operation gültig ist.
Ein Vorgangsdienst kann vorgesehen sein, um Vorgangsberichte von M-Beans zu empfangen und sie an irgendeine Einheit weiterzuleiten, welche den Empfang derselben angefordert hat.
Ein Beziehungsdienst kann vorgesehen sein, um zu ermöglichen, daß Beziehungen zwischen M-Beans definiert werden, wenn sie erforderlich sind. Die Beziehungen müssen nicht im voraus definiert sein. Information über die Beziehungen zwischen M-Beans wird nicht mit den M-Beans selbst gespeichert, sondern kann von dem Beziehungsdienst erhalten werden.
Ein dynamischer Ladedienst für eine Ursprungsbibliothek kann für das Laden von dem ursprünglichen Code in das Grundgerüst 24 vorgesehen sein. Eine ursprüngliche bzw. natürliche Bibliothek kann geladen werden, wenn eine neue Klasse, die den ursprünglichen Code enthält, geladen wird. Die geladene Bibliothek hängt von der Hardwareplattform und dem Betriebssystem ab, auf welchem das Grundgerüst läuft. Die ursprüngliche Bibliothek kann von einer entfernt gelegenen Einheit geladen werden.
Es folgt nunmehr eine Beschreibung der Adapterserver 30–38 des verwalteten Objektes.
Ein Adapterserver eines verwalteten Objektes ist ein Protokolladapter, der eine Abstraktion eines Kommunikationsprotokolls bereitstellt. Jeder Adapterserver von verwalteten Objekten gewährt Zugriff auf M-Beans über ein bestimmtes Kommunikationsprotokoll. Ein Adapterserver eines verwalteten Objektes ermöglicht, daß Verwaltungsanwendungen Verwaltungsvorgänge auf einem Netzwerkmanagementsystemagenten ausführen.
Damit ein Netzwerkmanagementsystemagent handhabbar ist, wird über zumindest einen Adapterserver eines verwalteten Objektes angeschlossen. Ein Netzwerkmanagementsystemagent kann jedoch mit irgendeiner beliebigen Anzahl von Adapterservern für verwaltete Objekten verbun den sein, was ermöglicht, daß er Anforderungen von entfernt gelegenen Verwaltungsanwendungen erhält, welche unterschiedliche Protokolle verwenden. Das Netzwerkmanagementsystem stellt Adapterserver für verwaltete Objekte für standardmäßige und für individuelle Protokolle bereit.
Beispielsweise können Adapterserver für verwaltete Objekte bereitgestellt werden für eines oder mehrere der Standardprotokolle: HTML/HTTP; SNMP; und CORBA, um nur einige Beispiele zu nennen.
Die Adapterserver für verwaltete Objekte für Standardprotokolle kommunizieren direkt mit den Verwaltungsanwendungen, welche sie verwenden.
Beispielsweise ermöglicht ein Adapterserver eines verwalteten Objektes mit HTML/HTTP, das ein Benutzer einen Webbrowser verwendet, um Verwaltungs- bzw. Managementinformation zu betrachten, die in M-Beans enthalten ist, und um Managementvorgänge auf einem Netzwerkmanagementsystemagenten auszuführen. Der HTTP/HTML-Adapter-Server für verwaltete Objekte erhält Managementinformation von den M-Beans und erzeugt HTML-Seiten, welche diese Management- bzw. Verwaltungsinformation wiedergeben.
Ein Adapterserver für verwaltete Objekte mit SNMP kann so ausgelegt sein, daß er eine spezielle SNMP-Informationsbasis (MIB) verwendet, um den SNMP-Manager in die Lage zu versetzen, Managementvorgänge auf einem Netzwerkmanagementsystemagenten auszuführen.
Das Netzwerkmanagementsystem kann auch so ausgelegt sein, daß es Adapterserver für verwaltete Objekte für eines oder mehrere der folgenden speziellen bzw. individuellen Protokolle bereitstellt: RMI; Java/HTTP-, und Secure Sockets Layer (SSL). In einem Beispiel des Netzwerkmanagementsystems bietet ein Adapterclient eines verwalteten Objektes eine Java API. Dementsprechend wird jede Verwaltungsanwendung, die einen Adapeterclient für verwaltete Objekte verwendet, in Java-Sprache geschrieben sein.
Agenten, die unter Verwendung des Netzwerkverwaltungssystems entwickelt wurden, können unter Verwendung unterschiedlicher Kommunikations- oder Managementprotokolle verwaltet werden. Um unter Verwendung eines standardmäßigen Managementprotokolls verwaltet zu werden, muß ein Netzwerkmanagementsystemagent mit dem Adapterserver für verwaltete Objekte für dieses Protokoll verbunden sein. Der Adapterserver verwalteter Projekte für Standardprotokolle kommuniziert direkt mit den Managementanwendungen, welche diese verwenden.
Ein Beispiel dieser Struktur, welches die Agentendarstellung nach 4 verwendet, ist in 5 wiedergegeben, wo auf den Agenten mit Hilfe eines Webbrowsers 46 zugegriffen wird. Hier ermöglicht ein HTML-Adapter, daß Beans auf eine HTML-Seite abgebildet werden. Die Verwendung eines Protokolls wie z. B. HTML ermöglicht es, daß der Browser 46 an der Clientstation 90 Beans an der entfernten Station 20 durchläuft bzw. durchblättert und auf diese zugreift, und falls nötig, sie unter Verwendung konventioneller Webbrowserfunktionen modifiziert. Gemäß der in 4 dargestellten Struktur ist der Ablagedienst 27 in dem Grundgerüst 24 registriert und der HTML-Adapter 34 und des (der) Bean(s) 29 ist bzw. sind bei dem Ablagedienst registriert, wodurch das (die) Bean(s) effektiv auf einer HTML-Seite registriert ist bzw. sind, welche durch den HTML-Adapter 34 unterstützt wird. In 5 beziehen sich gleiche Bezugszahlen auf gleiche bzw. ähnliche Merkmale der in 4 dargestellten Anordnung.
6 ist ein Flußdiagramm, welches Schritte für die Ermöglichung bzw. Freischaltung der Modifikation von Eigenschaften der Beans in der entfernten Maschine veranschaulicht. In Schritt 92 wird der HTML-Adapter 34 in der virtuellen Maschine 22 an der entfernt gelegenen Station 20 ausgelöst bzw. initiiert und in Schritt 94 wird bzw. werden das (die) Bean(s) 29 dieser virtuellen Maschine, auf welche aus der Ferne zugegriffen werden soll, in dem Grundgerüst registriert, oder genauer gesagt in dem Ablagedienst 27, wie oben beschrieben. Dies bedeutet, daß dann, wenn der HTML-Adapter eine Anfrage an das Grundgerüst 24 richtet, das Grundgerüst 24 unter Bezug auf den Ablagedienst in der Lage ist, die Beans 29, auf welche zugegriffen werden soll, identifiziert und über den HTML-Adapter darauf Zugriff gewährt.
Der HTML-Adapter 34 ermöglicht eine Kommunikation über das Netzwerk unter Verwendung konventioneller HTTP-Austausche. Er verhält sich wie ein HTTP-Server. Wenn er eine Anforderung empfängt, so erzeugt er dynamisch eine Seite, die eine Liste von Beans (Objekten) 29 enthält, welche aktuell in dem Ablageobjekt 27 registriert sind.
Ein Bean wird in HTML als eine HTML-Tabelle wiedergegeben, wobei:
Eine erste Spalte einen Eigenschaftsnamen enthält,
eine zweite Spalte einen Eigenschaftstyp enthält,
eine dritte Spalte das Zugriffsrecht (Lesen/Schreiben) enthält,
einen Eigenschaftswert enthält.
Wie oben erwähnt, wird, falls die Eigenschaft Lesen/Schreiben ist, ein HTML-Formblatt bzw. HTML-Format erzeugt.
In Schritt 96 werden die Beans an der kleinen Station dargestellt, bzw. angezeigt, wie es durch die Anzeige 98 wiedergegeben wird, und zwar unter Verwendung der HTML-Darstellung eines Bean, wie oben beschrieben durch Zugriff auf die HTML-Seite unter Verwendung eines konventionellen Webbrowsers, der unter Verwendung von HTTP-Austauschen mit dem mit dem HTML-Adapter kommuniziert. Der Benutzer ist in der Lage, dann bei Schritt 100 ein Bean auszuwählen, welcher konventionelle Webbrowserfunktionen verwendet. Der Webbrowser gibt dann eine HTTP- GET-Anforderung an den HTML-Adapter 34 aus. Der HTML-Adapter verwendet die Selbstuntersuchung, um die Beaneigenschaften zu extrahieren und liefert dann eine HTML-Arbeitsplatzantwort, wodurch der Browser die Eigenschaften anzeigen kann und möglicherweise auch die Aktionen und Vorgänge, die durch den Bean unterstützt werden, wie es bei 102 dargestellt ist. Durch weitere Verwendung des Browsers unter Verwendung konventioneller Browserfunktionen ist der Benutzer in der Lage, Modifikationen zu einzelnen Aspekten des Bean auszuwählen und anzugeben, beispielsweise Änderungen an den Eigenschaften. Durch einen weiteren Austausch von HTML-GET- und/oder SET-Anforderungen und POST-Antworten sind der Webbrowser und der HTML-Adapter in der Lage, bei Schritt 104 die entsprechenden Eigenschaften des Bean auf der entfernten Station zu modifizieren und diese Veränderungen für den Benutzer an der Clientstation anzuzeigen.
Demnach stellt dieser Mechanismus ein computerimplementiertes Verfahren für das Zugreifen auf ein Objekt, wie z. B. ein Bean an einer entfernten Maschine über ein Telekommunikationsnetzwerk von einer Clientmaschine aus bereit, indem das Objekt auf eine extern zugängliche Maschinenseite bei der entfernten Maschine abgebildet wird und das Objekt über die Maschinenseite unter Verwendung eines Browsers durchlaufen bzw. durchsucht wird.
Ein weiteres Beispiel der in 3 dargestellten Struktur, diesmal unter Verwendung der Darstellung nach 3, ist in 7 dargestellt, wo ein Netzwerkmanagementsystemagent 20 durch eine SMNP-Manageranwendung verwaltet wird. In 7 beziehen sich gleiche Bezugszahlen auf gleiche bzw. ähnliche Merkmale der in 3 dargestellten Anordnung.
Ein Beispiel eines Netzwerkverwaltungssystems, welches in 8 wiedergegeben ist, stellt eine Adapter-API bereit, um es Java-Managementanwendungen zu ermöglichen, mit den Netzwerkmanagementsystemagenten zu kommunizieren. Die Adapter-API stellt Adapterclients für verwaltete Objekte für den Zugriff auf verwaltete Objekte über ein bestimmtes Kommunikationsprotokoll bereit. Das Netzwerkmanagementsystem definiert eine Darstellung von M-Beans für Java-Managementanwendungen und stellt ein Kompilierungswerkzeug für das automatische Erzeugen einer solchen Darstellung aus einem M-Bean bereit. Ein Namensdienst wird zugeführt, um es Java-Managementanwendungen zu erlauben, daß sie unabhängig von einem bestimmten Kommunikationsprotokoll sind.
Ein Adapterclient für verwaltete Objekte ist eine abstrakte Java-Klasse, die es Java-Managementanwendungen ermöglicht, auf verwaltete Objekte zuzugreifen. Die programmtechnische Darstellung des verwalteten Objektes für die Java-Managementanwendung wird bestimmt durch den Adapterclient des verwalteten Objektes. Ein solcher Mechanismus ermöglicht, daß unterschiedliche Darstellungen bzw. Repräsentationen desselben verwalteten Objektes verschiedenen Java-Managementanwendungen dargeboten werden. Das Netzwerkmanagementsystem stellt Adap terclients für verwaltete Objekte für den Zugriff auf verwaltete Objekte durch eines oder mehrere der folgenden Protokolle bereit: RMI; HTTP; und SSL.
Die Adapterclients für verwaltete Objekte stellen eine Definition einer Schnittstelle des Adapters für das verwaltete Objekt bereit. Die vom Adapter verwaltete Objektschnittstelle ermöglicht es Java-Anwendungen, daß sie eine oder mehrere der folgenden Verwaltungsvorgänge auf einem Netzwerkmanagementsystemagenten ausführen:

– Aufrufen bzw. Heranholen von M-Beans,
– Holen oder Einstellen der Eigenschaften entfernt gelegener M-Beans,
– Aufrufen von Methoden auf entfernt gelegenen M-Beans,
– Erzeugen von Instanzen auf M-Beans,
– Löschen von M-Beans,
– Empfangen von Vorgängen, die von entfernt gelegenen M-Beans ausgegeben werden.

Ein Adapterclient für verwaltete Objekte versieht eine Java-Managementanwendung mit „Handhaben" für verwaltete Objekte in einem entfernten Agenten. Diese Handhaben ermöglichen es der Java-Managementanwendung, die verwalteten Objekte direkt zu manipulieren und die Java-Managementanwendung benötigt keine Information über das durch das verwaltete Objekt verwendete Protokoll. Alles, was die Java-Managementanwendung benötigt, ist die Klasse des Objektes, welche das verwaltete Objekt repräsentiert. Beispielsweise verwendet eine Java-Managementanwendung für die Handhabe von Konten eine abstrakte Klasse für die Repräsentation bzw. Darstellung von Konten. Um ein 'Konto zu manipulieren bzw. auf dieses zuzugreifen erhält die Java-Managementanwendung ein verwaltetes Kontoobjekt von dem Adapterclient für verwaltete Objekte. Sie formt dann das verwaltete Kontoobjekt in die abstrakte Klasse um, welche das Konto repräsentiert. Auf diese Weise ist der Anwendungscode unabhängig davon, wie das verwaltete Objekt implementiert ist.
8 ist eine schematische Darstellung der Beziehung zwischen einem Client-Bean (C-Bean) 54 und einem M-Bean 28. Ein C-Bean 54 ist eine Darstellung eines M-Beans für eine Java-Managementanwendung. In der bevorzugten Ausführungsform der Erfindung ist ein C-Bean 54, ebenso wie ein M-Bean 28, als eine JavaBeans-Komponente implementiert. Ein C-Bean definiert, wie eine Java-Managementanwendung auf ein M-Bean 28 zugreift.
Wie man in 8 sieht, weist ein C-Bean 54 eine Schnittstelle für eine verwaltetes Objekt (MO-Schnittstelle) 56 auf, welche definiert, welche der Methoden eines M-Beans für eine Java-Managementanwendung zugänglich sind, und es weist weiterhin einen Stub des verwalteten Objektes (MOStub) 58 auf, welcher die in der MO-Schnittstelle 56 definierten Methoden implementiert.
Eine Java-Managementanwendung erhält eine Referenz auf ein C-Bean durch Verwendung einer MO-Adapterschnittstelle 60. Die MO-Adapterschnittstelle instanziiert das C-Bean 54. Dieselbe Implementierung eines C-Bean 54 kann auf irgendeinem Adapterclient verwalteter Objekte laufen, der die MO-Adapterschnittstelle 60 implementiert. Unterschiedliche Implementierungen desselben verwalteten Objektes können unterschiedlichen Java-Managementanwendungen angeboten werden. Deshalb können einem einzelnen M-Bean mehrere C-Beans 54 zugeordnet sein.
Eine Java-Managementanwendung führt Managementvorgänge bzw. Operationen auf einem M-Bean aus, indem sie Methoden seines zugeordneten C-Bean 54 aufruft. Für die Java-Managementanwendung ist ein C-Bean 54 eine lokale Darstellung des entfernten Java-Objektes (ein M-Bean 28).
Die MO-Adapterschnittstelle 60 instanziiert das C-Bean 54. Dieselbe Implementierung eines C-Bean kann auf irgendeinem Adapterclient 62 eines verwalteten Objektes laufen, welcher die MO-Adapterschnittstelle 60 implementiert. Unterschiedliche Darstellungen bzw. Repräsentationen desselben verwalteten Objektes können verschiedenen Java-Managementanwendungen dargeboten werden. Demnach können einem einzelnen M-Bean mehrere C-Beans zugeordnet sein.
Eine Java-Managementanwendung führt Managementoperationen auf einem M-Bean aus, indem sie Methoden seines zugehörigen C-Bean aufruft. Für die Java-Managementanwendung ist ein C-Bean eine lokale Darstellung bzw. Repräsentanz eines entfernt gelegenen Java-Objekts (eines M-Beans).
9 ist eine schematische Darstellung der Erzeugung eines C-Bean 54 aus einem M-Bean. In einer Ausführungsform der Erfindung wird ein C-Bean automatisch aus einem M-Bean 58 unter Verwendung des Reflektions-API erzeugt. Die erzeugten C-Beans zeigen dieselben Eigenschaften, Methoden und Vorgänge bzw. Abläufe wie die M-Beans. Dies ist beispielsweise dann der Fall, wenn keine Politik bzw. Strategie der Zugangskontrolle in Kraft gesetzt ist.
Um die automatische Erzeugung eines C-Bean 54 aus einem M-Bean 28 zu gewährleisten, nimmt ein Compiler 60 das M-Bean 28 als Eingangsgröße und erzeugt als Ausgangsgröße die MO-Schnittstelle und MO-Stubs eines C-Bean 54. Wenn beispielsweise ein M-Bean 28, das eine Java-Klasse mit dem Namen Konto repräsentiert, kompiliert wird, erzeugt der Compiler 60 eine MO-Schnittstelle 56 mit dem Namen AccountMO und eine Java-Klasse mit dem Namen AccountMO-STUB 58, welche die AccountMO-Schnittstelle 56 implementiert.
Eine Java-Managementanwendung kann unter Verwendung der MO-Schnittstellendefinitionen entwickelt werden. Indem unterschiedliche Stubs geladen werden, kann die Adapter-MO-Schnittstelle das Verhalten der Java-Managementanwendung während des laufen den Betriebs modifizieren. Wenn beispielsweise Nur-Lese-Stubs geladen sind, ist die Java-Managementanwendung nicht in der Lage, die Eigenschaften des M-Bean 28 zu modifizieren.
Der Compiler 60 kann Nur-Lese- oder Lese-Schreibe-Stubs erzeugen. Die erzeugten Stubs verwenden die Adapter-MO-Schnittstelle. Daher ist ihr Verhalten dasselbe auf irgendeinem Adapterclient verwalteter Objekte, der die Adapter-MO-Schnittstelle implementiert, unabhängig von der Implementierung des Adapterclients des verwalteten Objektes.
10 ist ein Blockdiagramm von Schritten für den Zugriff auf ein Bean an einer entfernt gelegenen (Server-)Station von einer lokalen Management- bzw. Verwaltungs-(Client-) Station unter Verwendung einer Struktur, wie sie in 8 dargestellt ist.
Die Managementanwendung (beispielsweise eine Java-Managementanwendung) an der Managementstation erzeugt in Schritt 80 eine Heranholanforderung für die Adapter-MO an der Clientstation. Die Adapter-MO mit dem MO-Stub und dem Netzwerkadapter an der Clientstation erzeugt in Schritt 81 eine Anforderung entsprechend einem geeigneten Netzwerkprotokoll (beispielsweise HTTP).
Demnach könnte die über das Netzwerk an das verwaltete System gesendete Anforderung beispielsweise in Form einer GET-Anforderung für eine Managementeigenschaft eines verwalteten Objektes vorliegen.
Der geeignete Adapterserver 30–38 für verwaltete Objekte empfängt je nach dem verwendeten Protokoll in Schritt 82 die externe Anforderung. Er greift dann in Schritt 83 auf das Grundgerüst 24 zu, um eine geeignete Methode zu erhalten. Das Grundgerüst erhält bzw. holt in Schritt 83 eine Methode eines verwalteten Objektes für die Anforderung und liefert in Schritt 84 die Managementeigenschaft des verwalteten Objektes an den Adapter, der seinerseits in Schritt 85 eine Antwort mit dem Ergebnis entsprechend demselben Netzwerkprotokoll (beispielsweise HTTP) zusammensetzt. Diese Ergebnisnachricht wird in Schritt 86 bei dem Clientadapter und der Adapter-MO empfangen, die das Ergebnis an die Managementanwendung liefert.
Ein Namensdienst wird bereitgestellt, welcher ermöglicht, daß Managementanwendungen von einem bestimmten Kommunikationsprotokoll unabhängig sind. Java-Managementanwendungen verwenden den Namensdienst, um zu bestimmen, welcher Adapterclient verwaltete Objekte für den Zugriff auf einen Agenten zu verwenden ist. 11 ist ein schematisches Flußdiagramm, welches die Betriebsweise des Namensservice veranschaulicht.
In Schritt 62 leitet die Managementanwendung die Identität des Agenten, auf welchen zugegriffen werden soll, an den Hauptdienst.
In Schritt 64 liefert der Namensdienst den Klassennamen des Adapterclients des verwalteten Objektes, beispielsweise 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 Adapterclient verwalteter Objekte dynamisch zu laden und zu instanziieren. Die Java-Managementanwendung kann dann mit dem Agenten über den Adapterclient des verwalteten Objektes interagieren, unabhängig von dem Kommunikationsprotokoll.
Wie oben erwähnt, ist ein Management-Bean oder M-Bean ein verwaltetes Objekt in einem Netzwerkmanagementsystemagenten. Ein verwaltetes Objekt ist eine Softwareabstraktion einer Ressource, die durch den Agenten gesteuert bzw. kontrolliert und überwacht wird. In einem Beispiel eines Netzwerkmanagementsystems sind alle M-Beans als JavaBeans-Komponenten implementiert. Es kann auf sie unter Verwendung eines konventionellen Java-Anwendungsbauwerkzeuges, wie z. B. des JavaBeans-Entwicklungssatzes, zugegriffen werden. Innerhalb eines M-Bean ist es möglich, Dienste aufzurufen und zu verwenden, die durch das Netzwerkmanagementsystem bereitgestellt werden.
Eine JavaBeans-Komponente enthält Eigenschaften, die getrennte bzw. diskrete, mit Namen versehene Attribute enthält, welche das Erscheinungsbild des Verhaltens der JavaBeans-Komponente beeinflussen können. Beispielsweise kann ein M-Bean, der einen Internet-Treiber repräsentiert, eine Eigenschaft mit dem Namen I-Packets haben, welche die Anzahl der eingehenden Pakete repräsentiert. Eigenschaften können willkürliche Werte haben, sowohl eingebaute Java-Endtypen als auch Klassen- oder Schnittstellentypen, wie z. B. Java.awt.color. Auf Eigenschaften wird immer über Methodenaufrufe auf dem Objekt zugegriffen, welches sie besitzt. Für lesbare Eigenschaften gibt es eine GET-Methode, um den Wert der Eigenschaft zu lesen. Für schreibbare Eigenschaften gibt es eine SET-Methode, um zu ermöglichen, daß der Eigenschaftswert aktualisiert wird. Ein standardmäßiges Auslegungsmuster bzw. Modellmuster kann für die Lokalisierung von Eigenschaften verwendet werden.
public Property Type get PropertyName();
public void set PropertyName (PropertyType value).
Wenn eine Klassendefinition ein passendes Paar von get PropertyName und set Property-Name-Methoden enthält, wobei der Rücklieferungstyp des „Getter"-Typ dem Parametertyp des „Setter" entspricht, dann definieren diese Methoden eine Lese-Schreibe-Eigenschaft. Wenn eine Klassendefinition nur eine dieser Methoden enthält, so definiert der Name entweder eine Nur-Lese- oder eine Nur-Schreibe-Eigenschaft, die PropertyName genannt wird.
Zusätzlich ist es für Bool'sche Eigenschaften möglich, eine GET- bzw. Heranhol-Methode unter Verwendung des folgenden Auslegungsmusters zu definieren:
public boolean is PropertyName();
Die isPropertyName-Methode kann anstelle einer getPropertyName-Methode vorgesehen werden, wenn sie zusätzlich zu einer getPropertyName-Methode vorgesehen ist.
Eine Indexeigenschaft ist ein Array PropertyElement[], auf welches durch Methoden der Form
public PropertyElement getPropertyName (int index);
public void set PropertyName (int index, PropertyElement b)
zugegriffen wird.
Wenn eine Klassendefinition irgendeine Art einer Methode enthält, ist PropertyName eine Indexeigenschaft. Diese Methoden können verwendet werden, um einen Eigenschaftswert zu lesen und zu schreiben. Diese Methoden können zusätzlich zu den Methoden definiert werden, die für einfache Eigenschaften definiert sind. Daher kann eine Indexeigenschaft durch vier Zugriffsmethoden dargestellt bzw. repräsentiert werden.
Standardmäßig wird das folgende Auslegungsmuster verwendet, um zu bestimmen, welche Vorgänge ein M-Bean durch Multicasting behandeln kann (Multicasting = Übermitteln von Kopien an einen ausgewählten Teilsatz möglicher Zielorte):
public void addEventListenerType(EventListenerType a);
public removeEventListenerType(EventListenerType a).
Beide Methoden verwenden das Argument vom Typ des EventListenerType, wobei der Typ EventListenerType die java.util.EventListener-Schnittstelle erweitert, wobei die erste Methode mit add startet, die zweite Methode mit remove startet und wobei der Typname des EventListenerType mit Listener endet.
Dieses Patent eines Modells geht von der Annahme aus, daß das JavaBean als eine Multicast-Vorgangsquelle für den in der EventListenerType-Schnittstelle spezifizierten Vorgang wirkt.
Um das JavaBeans-Modell gleichförmig zu machen, sollten alle öffentlichen Methoden einer JavaBeans-Komponente als externe Methoden innerhalb der Komponente für den Zugriff durch die Komponenten freigelegt werden. Standardmäßig umfaßt die Eigenschaft Zugriffsmethoden und die Registriermethode in dem EventListener.
Zusätzlich zu dem JavaBeans-Komponenten-Modell für Elemente der Auslegungsmuster kann das Netzwerkmanagementsystem eine Aktion als eine öffentliche Methode eines M-Bean definieren, die sinnvollerweise aus der Ferne aufgerufen wird. Die Aktion erleichtert die Unterscheidung einer öffentlichen M-Bean-Methode, die für andere lokale M-Bean frei- bzw. offenliegt, gegenüber öffentlichen Methoden, die aus der Ferne aufgerufen werden können. Das Auslegungsmuster für eine Aktion ist folgendermaßen:
public AnyJavaType performAnAction (AnySignature).
M-Beans können ursprüngliche bzw. natürliche Bibliotheken enthalten, d.h. eine Bibliothek, die nicht in der Sprache (beispielsweise Java) des M-Bean geschrieben ist. Das Netzwerkmanagementsystem kann einen Mechanismus zum Laden einer ursprünglichen Bibliothek von demselben entfernt gelegenen Klassenserver wie die M-Beans bereitstellen. Um ein M-Bean in die Lage zu versetzen, diesen Mechanismus zu verwenden, kann eine statisch loadLibrary-Methode der Grundgerüstklasse aufgerufen werden, in welcher der Aufrufer eine Referenz auf die Java-Klasse des Aufrufers einschließt. Eine solche Information wird durch das Grundgerüst 24 verwendet, um den Klassenlader zu identifizieren, durch welchen die Klasse geladen wird.
Die Kernmanagementdienste, die oben erwähnt wurden, sind für viele der Managementoperationen allen Agenten gemeinsam, was die Entwicklung von Agenten vereinfacht. Indem diese Kerndienste bereitgestellt werden, ermöglicht das Netzwerkmanagementsystem, daß Bemühungen auf die Entwicklung derjenigen Teile eines Agenten konzentriert werden, die für eine bestimmte Anwendung spezifisch sind, nämlich auf die M-Beans und die Anwendung zur Steuerung und Verwaltung derselben.
12 ist ein schematisches Flußdiagramm der Initialisierung eines Netzwerkmanagementsystemagenten 20. Der Initialisierungsvorgang weist auf:

– in Schritt 70, Erzeugen einer Instanz des Grundgerüstes 24,
– in Schritt 72, Hinzufügen des M-Bean-Ablagedienstes 27,
– in Schritt 74, Hinzufügen des Metadatendienstes 29, und
– in Schritt 76, Hinzufügen zumindest eines Adapterservers (30–38) für verwaltete Objekte, so daß auf den Agenten durch Managementanwendungen zugegriffen werden kann.

Wenn der Netzwerkmanagementsystemagent 20 initialisiert worden ist, müssen keine weiteren Managementdienste hinzugefügt werden, bevor ein Agent gestartet wird. Diese können zu dem Agenten dynamisch hinzugefügt werden, während er läuft.
Das Grundgerüst 24 steuert die Managementdienste und M-Beans eines Agenten 20, welche unter Verwendung des Netzwerkmanagementsystems entwickelt wurden. In der bevorzugten Ausführungsform ist es durch die Java-Klasse java.jaw.agent.cmf.Framework implementiert. Ein Agent muß eine Instanz des Grundgerüstes enthalten, d.h. in der bevorzugten Ausführungsform eine Instanz der Klasse java.jaw.agent.cmf. Framework.
In der bevorzugten Ausführungsform können M-Beans nur verwaltet werden, wenn sie mit einem Objektnamen in der M-Bean-Ablage 27 des Agenten 20 registriert sind. Dementsprechend wird in Schritt 72 der M-Bean-Ablagedienst 27 hinzugefügt, bevor der Agent 20 wirksam wird bzw. arbeitet. Der M-Bean-Ablagedienst 27 wird verwendet, um die Zuordnung zwischen einem M-Bean und seinem Objektnamen zu speichern und wiederzuholen. Der M-Bean-Ablagedienst der bevorzugten Ausführungsform wird als die Java-Schnittstelle java.jaw.agent.services.MoRepSrvlf definiert. Zu einem gegebenen Zeitpunkt kann einem Agenten nur ein M-Bean-Ablagedienst zugeordnet sein. Es ist jedoch möglich, den M-Bean-Ablagedienst, der dem Agenten zugeordnet ist, zu verändern, während der Agent läuft.
Die M-Bean-Ablage kann als ein flüchtiger Speicher oder als dauerhafter Speicher implementiert sein. In einer flüchtigen Ablade wird die gesamte Information über M-Beans in dem Speicher gespeichert. Die gesamte Information in einer flüchtigen Ablage geht verloren, wenn der Agent gestoppt wird. Dementsprechend muß ein Agent mit einer flüchtigen Ablage, wenn er gestartet wird, die Information in der Ablage erneut laden. Bei einer dauerhaften Ablage ist die gesamte Information über M-Beans in einer Datenbank gespeichert, wodurch die Information in einer dauerhaften Ablage nicht verloren geht, wenn der Agent gestoppt wird. Es ist auch möglich, eine gemischte Ablage zu implementieren, wodurch Information über M-Beans in dem Speicher oder in einer Datenbank gespeichert wird.
Der oben erwähnte Metadatendienst wird verwendet, um die Eigenschaften von Aktionen zu erhalten, die durch ein M-Bean unterstützt werden. Eine bevorzugte Implementierung des Metadatendienstes beruht auf der Reflektions-API, die durch den bekannten Java-Entwicklungssatz für das Ausführen einer Selbstüberprüfung bereitgestellt wird.
Wie oben erwähnt, sollte zumindest ein Adapterdienst für verwaltete Objekte in der virtuellen Maschine des Servers als Netzwerkmanagementsystemagent laufen. Das Netzwerkmanagementsystems erfordert keinen Adapterserver eines verwalteten Objektes, um mit einer spezifischen Schnittstellendefinition oder Implementierung übereinzustimmen. Der Adapterserver für das verwaltete Objekt ist so ausgelegt, daß er auf das Grundgerüst 24 zugreift, um in dem Agenten enthaltene Information abzurufen und zu verändern. Die vorgesehenen Adapterserver für verwaltete Objekte sind als M-Beans implementiert. Beispiele von Adapterservern für verwaltete Objekte sind oben beschrieben worden. In der bevorzugten Ausführungsform der Erfindung sind die Adapterserver für verwaltete Objekte als geeignete Java-Klassen implementiert.
Beispielsweise kann ein RMI-Adapterserver für ein verwaltetes Objekt implementiert sein als eine Java-Klasse sunw.jaw.agent.adaptor.rmi.AdaptorServerlmpl. Er ermöglicht es der Java-Managementanwendung, auf einen Agenten unter Verwendung des entfernten Methodenaufrufsystems (RMI-System) von Java zuzugreifen. Wie oben beschrieben, greift eine Java-Managementanwendung auf diesen Server über einen Adapterclient eines verwalteten Objektes zu, der als die Java-Klasse sunw.jaw.agent.adaptor.rmi.AdaptorClient implementiert ist.
Kernmanagementsysteme können zu einem Agenten hinzugefügt werden, während er läuft, sobald der Agent, wie oben beschreiben, initialisiert wurde. Es ist möglich, einem Agenten einen Kerndienst in einer der beiden folgenden Weise hinzuzufügen:

– Direktes Aufrufen einer Setz-Methode für den Dienst innerhalb der Grundgerüstklasse,
– Hinzufügen des Dienstes zu der M-Bean-Ablage in derselben Weise wie für ein M-Bean.

Das direkte Hinzufügen eines Kernmanagementdienstes ergibt eine schnellere Leistung als das Hinzufügen eines Kernmanagementdienstes zu der M-Bean-Ablage. Dies liegt daran, daß das Grundgerüst nicht bei der M-Bean-Ablage anfragen muß, um den Dienst zu erhalten. Gewisse Einschränkungen gelten jedoch für einen Kernmanagementdienst, der direkt hinzugefügt wurde:

– Der Dienst ist für entfernte Anwendungen nicht sichtbar, und
– es ist nicht möglich, Information des Dienstes in einem dauerhaften Speicher abzulegen.

Dementsprechend ist es, falls es wünschenswert ist, daß ein Kernmanagementdienst für entfernte Anwendungen sichtbar sein soll, notwendig, den Dienst der M-Bean-Ablage hinzuzufügen. Falls es gewünscht ist, Information auf einem Kernmanagementdienst in einem dauerhaften Speicher abzulegen, so ist es ebenfalls notwendig den Dienst der M-Bean-Ablage hinzuzufügen. Die M-Bean-Ablage, zu welcher der Dienst hinzugefügt wird, muß einen dauerhaften Speicher unterstützen.
Ein Klassendienstname enthält Namen, anhand derer das Grundgerüst 24 die Dienste identifiziert, die für einen Agenten implementiert sind. Das Grundgerüst 24 holt den Dienst, den es benötigt, folgendermaßen heran:

1. Das Grundgerüst 24 prüft, ob ein Dienst unter Verwendung einer direkten Setz- bzw. Bringmethode definiert worden ist. Wenn ein Dienst auf diese Weise definiert worden ist, verwendet das Grundgerüst 24 diesen Dienst.
2. Wenn der Dienst nicht unter Verwendung einer direkten Setzmethode definiert wurde, so fragt das Grundgerüst bei der M-Bean-Ablage an, um alle M-Beans zu erhalten, welche Instanzen der Klasse sind, die den Dienst implementieren. Beispielsweise fordert das Grundgerüst 24 bezüg lich des Metadatendienstes bei der M-Bean-Ablage den Erhalt aller Instanzen der Klassen mit dem Namen ServiceName.META an.
– Wenn die Ablage mehrere Instanzen der Klasse enthält, so verwendet das Grundgerüst 24 die erste Instanz, die von der M-Bean-Ablage geliefert wird.
– Wenn die M-Bean-Ablage keine Instanzen der Klasse enthält, so gibt das Grundgerüst eine Ausnahme ServiceNotFound (Dienst nicht gefunden) aus.

Verschiedene Operationen bzw. Vorgänge können in einem Netzwerkserviceagenten ausgeführt werden. Beispielsweise kann ein Objekt in einem Agenten Kernmanagementdienste verwenden für:

– Instanziieren eines M-Beans,
– Registrieren von M-Beans in der M-Bean-Ablage,
– Heranholen von M-Beans aus der M-Bean-Ablage,
– Erhalten und Einstellen der Werte von Eigenschaften innerhalb von M-Beans, und
– Definieren der Beziehungen zwischen M-Beans.

Ein Objektname identifiziert ein M-Bean eindeutig. Managementanwendungen verwenden Objektnamen, um die M-Beans zu identifizieren, auf welchen Managementvorgänge ablaufen sollen. Jedes beliebige Namensgebungsschema könnte verwendet werden. Beispielsweise könnte in der bevorzugten Ausführungsform der Erfindung ein Namensgebungsschema verwendet werden, welches von der Microsoft Corporation für das Hyper Media Management-Schema (HMMS) definiert wurde.
Um ein M-Bean zu instanziieren, kann eine der folgenden Methoden der Grundgerüstklasse aufgerufen werden:
newObject an den Standardspeichermechanismus des Benutzers zum Speichern des M-Bean,
newDBObject, um anzugeben, daß das M-Bean dauerhaft ist.
Bei jeder dieser Methoden ist es notwendig bereitzustellen:

– Die Java-Klasse des zu instanziierenden M-Beans, und
– den Objektnamen, der für das Registrieren des M-Bean verwendet werden soll.

Standardmäßig verwendet das Grundgerüst 24 den Standardklassenlader, um die Java-Klasse des zu erzeugenden M-Bean zu lokalisieren. Es erzeugt dann eine Instanz der Klasse. Wenn das M-Bean instanziiert worden ist, wird es initialisiert und registriert, so daß es für das Grundgerüst 24 zugänglich ist. Es ist möglich, ein M-Bean zu initialisieren und zu registrieren unter Verwendung von:

– Einer Methode, die in dem M-Bean selbst definiert ist, oder
– des Grundgerüstes 24.

Um ein Register eines M-Bean unter Verwendung einer in dem M-Bean selbst definierten Methode zu verwenden, sollte die Java-Klassendefinition des M-Bean enthalten:

– Eine Initialisierungsmethode,
– den Code, der erforderlich ist, um das M-Bean in die Lage zu versetzen, sich selbst bei der M-Bean-Ablage zu registrieren.

Wenn das M-Bean instanziiert worden ist, verwendet das Grundgerüst 24 den Metadatendienst 27, um die Initialisierungsmethode in dem neu erzeugten M-Bean zu finden. Wenn eine solche Methode in dem M-Bean vorhanden ist, ruft das Grundgerüst 24 sie auf unter Angabe:

– Einer Referenz auf sich selbst als ersten Parameter,
– des Objektnamens für die Verwendung beim Registrieren des M-Bean als zweiten Parameter.

Das M-Bean ist deshalb in der Lage, sich selbst unter Verwendung des vorgesehen Codes bei der M-Bean-Ablage zu registrieren.
Wenn ein M-Bean nicht mit der Initialisierungsmethode ausgestattet ist, initialisiert das Grundgerüst das M-Bean und registriert es unter Verwendung von Funktionen, die für diesen Zweck vorgesehen sind.
Das Registrieren einer JavaBeans-Komponente bei der M-Bean-Ablage 25 versetzt die Komponente in die Lage, durch den Agenten 20 verwaltet zu werden. Das Registrieren der Java-Beans-Komponente erfordert keine Modifikation von Code innerhalb der JavaBeans-Komponente selbst. Stattdessen ist alles, was erforderlich ist, die Hinzufügung von Code, um ihn in der M-Bean-Ablage zu registrieren. Daher ist es möglich, irgendeine existierende JavaBeans-Komponente in der M-Bean-Ablage zu registrieren. Sobald die JavaBeans-Komponente registriert ist, verwaltet der Agent 20 diese in derselben Weise wie irgendein M-Bean. Wenn ein M-Bean registriert ist, so wird ihm ein Objektname zugeordnet. Ein Objektnahme kann ausdrücklich angegeben werden. Wenn ein Objektname nicht ausdrücklich angegeben wird, ordnet das Grundgerüst 24 dem M-Bean einen Standardnamen zu.
Das Netzwerkverwaltungssystem stellt Dienste zum Wiedergewinnen bzw. Heranholen von M-Beans aus der M-Bean-Ablage bereit. Diese Dienste ermöglichen die Wiedergewinnung von M-Beans unter Verwendung von:

– Musteranpassung für den Objektnamen, oder
– Anfragen (Filter) zu den Java-Eigenschaften, die sie enthalten.

Indem eine Musteranpassung mit den Objektnamen von M-Beans verwendet wird, ist es möglich, folgendes abzurufen:

– Einen speziellen M-Bean unter Verwendung seines vollen Objektnamens,
– einen Satz von M-Beans, welche dieselbe logische Klasse gemeinsam verwenden, wie es in dem Objektnamen zum Ausdruck kommt,
– einen Satz von M-Beans, welche denselben Domainnamen verwenden, oder
– alle M-Beans, die in einem Agenten enthalten sind.

Das Verwenden von Anfragen bzw. Anforderungen ermöglicht die Abrufung von M-Beans gemäß den Java-Eigenschaften und mit ihren Werten innerhalb der M-Beans. Die M-Bean-Ablage wertet Eigenschaften aus, wenn sie dazu in der Lage ist. Ansonsten wertet das Grundgerüst Anfragen selbst aus. Um zu bestimmen, ob eine Ablage in der Lage ist, Abfragen beurteilen, veranlasst das Grundgerüst für diesen Zweck eine Abfragemethode.
Das Netzwerkmanagementsystem stellt Dienste für das Holen und Einstellen von Eigenschaften von M-Beans bereit. Wenn der Agent einen Metadatendienst bereitstellt, so ist alles, was in einem Aufruf an die Hol- bzw. Setzmethode des M-Bean zugeführt werden muß:

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

Wenn der Agent keinen Metadatendienst bereitstellt, ist es dennoch möglich, direkt die Hol- oder Einstellmethode eines M-Bean aufzurufen. In diesem Fall ist es außerdem notwendig, dem Aufrufer den Namen und die Signatur der Methode zuzuführen, damit er sie aufrufen kann.
Ein Beziehungsdienst ermöglicht es, daß Beziehungen zwischen den M-Beans definiert werden, wenn sie erforderlich sind. Die Beziehungen müssen nicht im voraus definiert werden. Information über die Beziehung zwischen M-Beans wird nicht mit den M-Beans selbst gespeichert, sondern wird mit der Beziehung gespeichert. Eine Beziehung muß nicht in der M-Bean-Ablage registriert werden. Eine Beziehung wird definiert durch:

– Einen Satz von Rollen, beispielsweise ist einer Besitzbeziehung eine Person Besitzer eines Buches und ein Buch wird durch eine Person besessen,
– einen Grad, welcher der Anzahl erforderlicher Rollen in der Beziehung entspricht.

Die in einer Beziehung betroffenen M-Beans werden in einer Beziehung durch ihre Objektnamen bezeichnet. Ein spezieller Klassenlader kann zu dem Agenten zu Beginn oder während des laufenden Betriebes des Agenten hinzugefügt werden. Es ist möglich, mehrere Klassenlader innerhalb desselben Agenten zu haben, vorausgesetzt, daß sie alle bei der M-Bean-Ablage registriert sind. Wenn die Erzeugung eines neuen Objektes angefordert wird, so ist es möglich, den Klassenlader zu spezifizieren, der für das Laden des Objektes verwendet werden soll. In diesem Fall wird der Klassenlader anhand seines Objektnamens identifiziert. Das System sieht verschiedene Implementierungen eines Netzwerkklassenladers vor, wobei jede Implementierung ein anderes Protokoll verwendet und einen anderen Klassenserver erfordert.
Das System sieht Handhabungsdienste für Ereignisse bzw. Vorgänge oder Abläufe zum Filtern, Protokollieren und das Weiterleiten von Ereignissen bzw. Vorgängen über unterschiedliche Kommunikationsprotokolle vor. Um einen Vorgang bzw. ein Ereignis auszugeben, wird eine Vorgangssendemethode aufgerufen. Wenn diese Methode aufgerufen wird, holt das Grundgerüst 24 alle M-Beans, welche einem Vorgangshandhabungsdienst entsprechen und ruft eine Vorgangshandhabungsmethode jeder erhaltenen Vorgangshandhabung auf. Diese Methode ist verantwortlich für die Handhabung von Vorgängen bzw. Maßnahmen oder Ereignissen.
9 ist eine schematische Darstellung des Kompilierens eines C-Beans 54 aus einem M-Bean 28. Der Compiler 60 implementiert ein Übersetzungsschema zum Erzeugen von C-Beans. Es ist jedoch möglich, unterschiedliche Übersetzungsschemata je nach den Erfordernissen zu implementieren.
13 veranschaulicht ein Beispiel der Ausgangsgröße des Compilers 60 zum Kompilieren eines einzelnen M-Beans, der A genannt wird. 14 zeigt die Ausgangsgröße des Compilers 60, wenn ein kompilierter M-Bean einen aListener für ein spezielles Ereignis AnEvent enthält.
Demnach erzeugt der Compiler 60, wenn der M-Beans Listener enthält:

– Eine Java-Schnittstelle für den Listener, der in die MO-Schnittstelle einbezogen werden soll,
– einen Listener-Stub, der eine Implementierung des M-Bean-Listeners zum Einfangen von M-Bean-Ereignissen bzw. Vorgängen und das Weiterleiten derselben an das Grundgerüst 24 ist, und
– die Ansicht des Vorganges bzw. Ereignisses einer Java-Managementanwendung, welche zu dem Listener gehört, der als EventMO bezeichnet wird.

Der Compiler 60 analysiert ein M-Bean unter Verwendung der anwendbaren Designparameter. Nach dem Analysieren bzw. „Parsing" verwendet der Compiler 60 eine Anzahl von Regeln zum Erzeugen des C-Beans.
Jede Eigenschaft des M-Bean ist in dem C-Bean mit denselben Zugriffsmethoden vorhanden. Wenn also eine Eigenschaft in dem M-Bean „Nur-Lesen" ist, so ist auch in dem C-Bean die Eigenschaft „Nur-Lesen".
15A ist eine Darstellung eines einfachen C-Beans, der beim Kompilieren eines M-Bean erzeugt wurde, der durch ein in 15B dargestelltes Codebeispiel definiert wurde. Zusätzlich erzeugt der Compiler 60 eine Datei, die eine Implementierung der einfachen MO-Schnittstelle enthält.
Zusätzlich zu den Zugriffsmethoden auf die Eigenschaften erzeugt der Compiler 60 Code nur für öffentliche Methoden, für die es sinnvoll ist, einen entfernten Zugriff zu gewähren. Andere öffentliche Methoden erscheinen nicht in dem C-Bean, das von dem Compiler 60 erzeugt wird.
16A zeigt einen Teilsatz für eine Aktionsmethode in einem C-Bean der MO-Schnittstelle, welchen der Compiler 60 erzeugt, wenn er die Aktionsmethode in einem M-Bean kompiliert, das so definiert ist, wie in 16B.
Wenn ein M-Bean einen Listener mit dem Namen A enthält, so enthält auch der Compiler 60 einen Listener, der in dem C-Bean AIfMO genannt wird.
Wenn das C-Bean verwendet wird, muß eine Anwendung, die AIfMO-Schnittstelle implementieren, um den Listener in dem C-Bean hinzuzufügen oder zu entfernen. Allgemein ist ein Listener eine Schnittestelle, die eine gewisse Anzahl von Methoden enthält. Jede Methode hat einen Eingangs- bzw. Eingabeparameter. Der Eingangsparameter erweitert ein entsprechendes Vorgangs- bzw. Ereignisobjekt.
In einem Beispiel bezieht sich jede Methode, die in einem Listener A definiert ist, auf ein Vorgangsobjekt, welches für den Zweck dieses Beispiels AnEvent genannt wird. Dementsprechend wird in der Aifmo-Schnittstelle das Ereignis- bzw. Vorgangsobjekt AnEventMO genannt. Demnach erzeugt für einen Listener A der Compiler 60 Dateien:

– Aifmo.java,
– AnEVentMO.java.

Zusätzlich erzeugt der Compiler 60 eine Implementierung des Listeners A mit dem Namen AStub.java.
Codes, die durch den Compiler 60 erzeugt werden, stimmen mit den Designparametern überein, die durch das JavaBeans-Komponentenmodell festgelegt bzw. entworfen wurden. Dementsprechend können die Objekte, die durch den Compiler 60 erzeugt wurden, in Entwicklungsumgebungen integriert werden, die mit diesem Modell übereinstimmen. Zusätzlich fügt der Compiler 60 einige öffentliche Methoden hinzu, die nicht dem durch das JavaBeans-Komponentenmodell definierten Entwurfsmuster folgen. Die hinzugefügten Methoden sind dafür ausgelegt, den Netzwerkverkehr zwischen einem M-Bean und einem C-Bean zu begrenzen. Beispielsweise ist es durch Aufru fen einer Funktion auf einem C-Bean möglich, alle Eigenschaften des 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 Ansicht eines M-Bean zu definieren. Statt sowohl die Schnittstelle als auch den Stub zu modifizieren, ist es besser, die Schnittstelle zu behalten und nur den Stub zu modifizieren. Der durch den Compiler 60 erzeugte Code ermöglicht, daß eine Anwendung unter Verwendung der Schnittstelle aufgebaut wird. Zu einem gegebenen Zeitpunkt verändert sich das Verhalten abhängig davon, welche Stubs durch die AdapterMO geladen werden. Beispielsweise kann der Compiler Nur-Lese- oder Lese-Schreibe-Stubs für dieselbe Schnittstelle erzeugen. Dementsprechend kann ein M-Bean-Browser auf Basis der Schnittstelle entwickelt werden. Wie oben erwähnt, hat der Browser daher ein unterschiedliches Verhalten, je nachdem, ob die Nur-Lese- oder die Lese-Schreibe-Stubs geladen sind.
Die Adapter-MO-Schnittstelle ist eine Java-Schnittstelle, die für das Verwalten des Agenten 20 definiert ist. Das Netzwerkmanagementsystem stellt verschiedene Implementierungen der Adapter-MO-Schnittstelle auf der Basis verschiedener Kommunikationsprotokolle bereit, wie es oben beschrieben wurde. Die Adapter-MO-Schnittstelle ist jedoch protokollunabhängig. Dementsprechend kann jeder Codeabschnitt, der unter Verwendung der Schnittstelle geschrieben wurde, auf irgendeiner der Implementierungen laufen, welche durch das Netzwerkmanagementsystem bereitgestellt werden.
Innerhalb der Adapter-MO-Schnittstelle gibt es zwei verschiedene Ebenen. Eine niedrige Ebene, in welcher entfernte Objekte (M-Bean) unter Verwendung ihrer Namen manipuliert bzw. gehandhabt werden und ein hohes Niveau, auf welchem entfernte Objekte (M-Beans) unter Verwendung einer lokalen Ansicht (C-Bean) der entfernten Objekte gehandhabt bzw. manipuliert werden. Die hohe Ebene ist auf die Schnittstelle niedriger Ebene aufgesetzt.
Die Verwendung der Schnittstelle niedriger Ebene ist praktisch für das Aufbauen grundlegender Anwendungen (wie z. B. eines HTML-Objektbetrachters oder eines MIB-Browsers). Das Verwenden der Schnittstelle auf hoher Ebene ist viel einfacher als das Verwenden der Schnittstelle auf niedriger Ebene. Es bedeutet jedoch, daß die Anwendung die Semantik der C-Beans, die sie handhabt, kennt. Zusätzlich erfordert es, daß die Anwendung (oder die Adapter-MO-Schnittstelle) Zugriff auf die MOs und die MOStubs hat. Ein erster Schritt beim Initialisieren eines Adapters besteht in der Initialisierung einer Implementierung der Adapter-MO-Schnittstelle.
Um einen Adapter zu initialisieren, ruft die Clientanwendung eine „Connect"-Methode auf, die in der Adapter-MO-Schnittstelle definiert ist. Parameter werden bereitgestellt, die sich auf den Hostnamen des Agenten, die zu verwendende Anschlußnummer (Portnummer) und einen logischen Namen beziehen, der im allgemeinen abhängig von dem zugrunde liegenden Kommunikationsmechanismus ist. Die unterschiedlichen Informationselemente könnten von einem Namensserver oder Verzeichnisdienst zur gleichen Zeit erhalten werden, zu welcher der Implementierungsname des zu verwendenden Adapters geliefert wird. Je nach dem zugrunde liegenden Kommunikationsmechanismus, der durch die Adapter-MO-Schnittstelle verwendet wird, beinhaltet der Aufruf von „Connect" möglicherweise keinen Nachrichtenaustausch zwischen Client und Agenten. Ein Adapter verwendet:

– Einen Namensserver zum Erhalten des Java-Klassennamens für die Verwendung für die Darstellung eines spezifischen M-Beans (bekannt aufgrund seines Objektnamens),
– einen Klassenlader für das Laden von C-Beans.

Wenn alle Java-Klassen für die C-Beans auf der Maschine vorhanden sind, wo die Clientanwendung läuft, so muß man keinen speziellen Klassenlader verwenden. Ansonsten ist es möglich, einen Netzwerkklassenlader für das Holen der Klassen über das Netzwerk zu verwenden.
Für die Verwendung eines Netzwerkklassenladers muß eine Clientanwendung den Netzwerkklassenlader instanziieren. Wenn das Objekt instanziiert wird, stellt die Anwendung einen Objektnamen bereit. Der Objektname kann irgendeine Domain und irgendeinen Klassennamen enthalten. Der Objektname sollte jedoch die folgenden Schlüsseleigenschaften enthalten:

– Host (den Host-Namen, auf welchem der Klassenserver läuft),
– Port (die Port- bzw. Anschlußnummer, die verwendet werden soll),
– Dienst (den Namen des aufzurufenden RMI-Dienstes).

Wenn ein Adapter initialisiert ist, ist die Anwendung bereit, Verwaltungsvorgänge mit dem entfernten Agenten auszuführen. Eine Anwendung kann einen Teilsatz oder alle der durch einen Agenten verwalteten M-Beans abrufen. Wenn Objekte abgerufen werden, kann eine Anwendung Anfragen spezifizieren. Die Ergebnisse des Abrufs kann man nach zwei verschiedenen Schemata erhalten:

– Eine Liste von Objektnamen (wiedergegeben durch einen Vektor),
– eine Liste von C-Beans (für jeden abgerufen Objektnamen instanziiert der Adapter ein C-Bean).

Um eine Eigenschaft eines enternten M-Bean zu lesen, wir der Eigenschaftsname benötigt, wenn das untere Niveau der Adapter-MO-Schnittstellen-Niveaus verwendet wird. Wenn die Schnittstelle der höheren Ebene verwendet wird, wird das C-Bean abgerufen und dann wird ein Heranholer, der der Eigenschaft zugeordnet ist, aufgerufen.
Das Einstellen bzw. Setzen einer Eigenschaft eines entfernten M-Bean, eines Eigenschaftsnamens und des Eigenschaftsobjekttyps ist erforderlich, wenn die niedrige Ebene der Adapterschnittstellenebenen verwendet wird. Wenn ein Wert gesetzt wird, so ist es möglich, den Namen einer Operatorklasse zu spezifizieren. Auf der Agentenseite wird der spezifizierte Operator instanziiert und für das Setzen des Eigenschaftswertes aufgerufen. Wenn die untere Ebene der Adapter-MO-Schnittstellenebenen verwendet wird, so ist es möglich, mehrere verschiedene Eigenschaften durch einen Methodenaufruf unter Verwendung einer Liste von Modifikationen zu setzen.
Wenn die hohe Ebene der Adapter-MO-Schnittstellenebenen verwendet wird, so erhält man ein C-Bean und der Entwickler ruft dann den zu der Eigenschaft gehörigen Satz auf.
Durch die Adapter-MO-Schnittstelle ist es möglich, instanziierte M-Beans mit einem entfernt gelegenen Agenten anzufordern. Wenn die Instanziierung angefordert wird, so ist es möglich, einen neuen Klassenlader zu spezifizieren, über welchen der Agent die neue, zu instanziierende Klasse laden soll. Der Klassenlader kann unter Verwendung seines Objektnamens spezifiziert werden. Wenn kein Klassenlader spezifiziert wird, verwendet der Agent den standardmäßigen Klassenlader. Wenn ein entfernter M-Bean instanziiert wird, so ist es möglich, direkt ein C-Bean für das Darstellen des neu erzeugten M-Beans zu erhalten. Wenn kein Name bereitgestellt wird und wenn ein Namensserver spezifiziert ist, ruft der Adapter den Namensserver auf, um den Namen der auf der Agentenseite zu instanziierenden Java-Klasse zu erhalten. Ansonsten liegt es in der Verantwortlichkeit des Agenten, den Klassennamen der zu instanziierenden Klasse festzulegen. Wenn ein M-Bean in dem Agenten instanziiert wird, so ist es möglich, ausdrücklich anzufordem, daß das Objekt dauerhaft (persistent) ist.
Über die Adapter-MO-Schnittstelle ist es möglich, Java-Objekte von dem Client zu dem Agenten zu übertragen. Um dieses zu tun, ordnet die Adapter-MO-Schnittstelle das Objekt seriell an, sendet das Objekt herüber und löst die serielle Anordnung des Objektes in dem Agenten wieder auf.
Über die Adapter-MO-Schnittstelle ist es außerdem möglich, ein M-Bean-Objekt von dem entfernt gelegenen Agenten zu entfernen. Das M-Bean wird nicht aus der virtuellen Maschine entfernt, sondern nur aus der Objektablage des Agenten. 17 ist ein Flußdiagramm, welches einen Überblick über die Schritte beim Erzeugen und Betreiben eines Managementsystems liefert, wie es oben beschrieben wurde, und zwar einschließlich der Schritte des Definierens eines Netzwerkmanagementmodells, das zumindest ein Management-Bean unter Verwendung einer Umgebung auf Bean-Basis umfaßt sowie das Kompilieren des Modells, um das Computernetzwerkmanagementsystem in der Umgebung auf Bean-Basis zu implementieren.
In Schritt 110 wird ein Modell unter Verwendung einer Umgebung auf Bean-Basis erzeugt. Eine bevorzugte Umgebung auf Bean-Basis ist die Java-Umgebung, wobei die Beans JavaBeans sind. Wie oben erwähnt, stellen Beans einen Satz von Eigenschaften, einen Satz von Methoden für das Durchführen von Aktionen und Unterstützung für Vorgänge bzw. Ereignisse und für die Selbstuntersuchung bzw. Selbstüberprüfung bereit. Konventionell ermöglichen es die Eigenschaften, daß Beans programmtechnisch manipuliert werden und sie unterstützen eine maßgeschneiderte Anfertigung des Bean, wobei die Verfahren die Eigenschaften implementieren und die Unterstützung für Vorgänge bzw. Ereignisse die Beans in die Lage versetzen, Vorgänge auszulösen und die Vorgänge zu definieren, die ausgelöst werden können. Die Unterstützung für die Selbstprüfung bzw. Selbstuntersuchung ermöglicht es, daß die Eigenschaften, Vorgänge und Methoden des Bean von außen untersucht werden.
Dementsprechend umfaßt der Schritt 110 das Erzeugen zumindest eines derartigen Management-Bean unter Bereitstellung zumindest einer Eigenschaft zum Modellieren einer Eigenschaft einer verwalteten Ressource und/oder ein Verfahren zum Modellieren einer Aktion für die verwaltete Ressource und/oder eine Unterstützung für zumindest einen Vorgang bzw. ein Ereignis zum Modellieren eines Ereignisses bzw. Vorganges der Ressource und/oder Unterstützung für die Selbstuntersuchung bzw. Selbstprüfung, welche eine externe Analyse der Zusammensetzung des Bean ermöglicht. Dieser Schritt umfaßt auch das Definieren der Beziehung und der Wechselwirkungen zwischen Management-Beans als Darstellung der Beziehungen und Interaktionen zwischen den verwalteten Ressourcen. Dieser Schritt kann auch das Definieren zumindest eines Listener-Ereignisses in Bezug auf zumindest ein Management-Bean umfassen.
In Bezug auf das vorliegende Netzwerkmanagementsystem wurde erstmalig erkannt, daß Beans über ihre konventionelle Rolle hinaus verwendet werden können, um ein Managementvehikel (Management-Bean) für das direkte Modellieren von zu verwaltenden Ressourcen bereitzustelllen. Beispielsweise kann eine Eigenschaft in einem Management-Bean verwendet werden, um eine Eigenschaft zu modellieren (beispielsweise ein Ressourcenattribut wie z. B. die Größe eines Speichers, die Anzahl von in einem Puffer empfangenen Nachrichten etc.) einer verwalteten Ressource. Eine Methode eines Management-Bean kann verwendet werden für die Modellierung einer Aktion (beispielsweise einer Systempause) einer verwalteten Ressource. Ein Bean kann auch verwendet werden, um Unterstützung für einen Vorgang bzw. ein Ereignis (z. B. das Ereignis Festplatte voll) für eine verwaltete Ressource bereitstellen. Z. B. kann ein Management-Bean auch Unterstützung für ein Listener-Ereignis bereitstellen, wobei ein Management-Bean auf ein Ereignis auf einem anderen Management-Bean reagieren kann. Mit Hilfe der Unterstützung für die Selbstuntersuchung kann ein Management-Bean eine externe Analyse der Zusammensetzung des Bean und den Austausch von Information zwischen den Beans gewähren. Management-Beans können Definitionen von Beziehungen und Wechselwirkungen zwischen Management-Beans als Darstellungen der Beziehungen und der Wechselwirkungen zwischen den verwalteten Ressourcen umfassen.
Da Beans wiederverwendbare Softwarekomponenten sind, die visuell in einem Aufbauwerkzeug (beispielsweise in einem Editor oder in einem Aufbauwerkzeug einer graphischen Benutzerschnittstelle (GUI-Aufbauwerkzeug)), visuell manipuliert bzw. bearbeitet werden können, kann in Schritt 110 ein Benutzer ein konventionelles Aufbauwerkzeug verwenden, wie z. B. den JavaBeans- Entwicklungssatz, um das Managementsystemmodell zu erzeugen, welches Beans enthält, die Systemressourcen, deren Funktionen und Beziehungen zwischen und Wechselwirkungen der Systemressourcen definiert. Das Bean-Modell wird definiert innerhalb einer virtuellen Maschine, die eine Umgebung auf Bean-Basis bildet. Beispielsweise ein Modell, welches JavaBeans innerhalb einer virtuellen Java-Maschine verwendet. Dieses ermöglicht in hohem Maße die Erzeugung des Managementsystemmodells. Verifizierung und Debugging (Fehlersuche) auf dem Modell kann in einfacher Weise unter Verwendung der Selbstuntersuchung und anderer Techniken durchgeführt werden.
In Schritt 112 kann das Modell, wenn es erzeugt worden ist, direkt unter Verwendung eines konventionellen Compilers für die Bean-basierte Umgebung kompiliert werden, beispielsweise Compiler 60, der in 9 dargestellt ist. Indem eine Modell in einer Bean-basierten Umgebung definiert wird, ist es möglich, das Bean-basierte Modell direkt zu kompilieen, um eine Bean-basierte Implementierung unter Verwendung eines Standardcompilers für die Bean-basierte Umgebung zu bilden, beispielsweise durch Kompilieren der JavaBeans unter Verwendung eines Java-Compilers. Dementsprechend wird das sich ergebende Bean-Managementsystem auch innerhalb derselben Java-Umgebung definiert. Dies vereinfacht in hohem Maße dieses Stadium bzw. diese Stufe der Erzeugung von Verwaltungssystemen, da der Compiler eine zuverlässige und homogene Implementierung des Modells erzwingt.
Deshalb stellt das zuvor in dieser Druckschrift bereits beschriebene Managementsystem in Schritt 114 im laufenden Betrieb eine robuste und einfach modifizierbare Struktur bereit, ohne die Schwierigkeiten und Nachteile von früheren Netzwerkmanagementsystemen.
Schritt 114 umfaßt die Schritte, die in Bezug auf 12 beschrieben wurden, nämlich der Registrierung von einem oder mehreren Management-Beans bei dem erweiterbaren AgentenGrundgerüst, das Registrieren eines oder mehrerer Nerzwerkadapter (beispielsweise der Netzwerkadapter-Beans) für ein Netzwerkkommunikationsprotokoll bei dem erweiterbaren AgentenGrundgerüst, und das Ermöglichen eines externen Zugriffs auf die Management-Beans über die Netzwerkadapter.
Wie oben unter Bezug auf 12 beschrieben wurde, kann das erweiterbare Agenten-Grundgerüst ein zugehöriges Ablage-Bean enthalten und die Schritte des Registrierens von einem oder mehreren Management-Beans und/oder Netzwerkadaptern kann das Registrieren eines oder mehrerer Management-Beans und/oder Netzwerkadaptern bei dem Ablage-Bean aufweisen.
Demnach ist ein Netzwerkagent für ein Telekommunikationsnetzwerk beschrieben worden, welcher ein erweiterbares Grundgerüst, eines oder mehrere Objekte, die bei dem Grundgerüst registrierbar sind, und eine oder mehreren Netzwerkadapter, die bei dem Grundgerüst registrierbar sind, enthält, und zwar für ein Netzwerkkommunikationsprotokoll, um Zugriff auf die verwalteten Objekte zu ermöglichen. Der Netzwerkagent stellt einen flexiblen Mechanismus für eine dynamische Netzwerkmanagementumgebung bereit. Die Registrierung bei dem Grundgerüst kann mit Hilfe eines Ablagedienstobjektes erfolgen. Das verwaltete Objekt ist vorzugsweise ein Bean, das einen Satz von Eigenschaften, einen Satz von Methoden und Unterstützung für Vorgänge und für die Selbstuntersuchung aufweist. Es ist auch ein Verfahren zum Bereitstellen von Agentendienst und ein Netzwerkmanagementsystem unter Verwendung eines solchen Agenten beschrieben worden.
Der Netzwerkagent kann in Form von Software auf zumindest einem Speichermedium implementiert sein. Das Speichermedium könnte ein tragbares Speichermedium, wie z. B. eine magnetische, optomagnetische oder optische Platte und/oder ein Festkörperspeicher und/oder ein Speicher eines Servercomputers sein. Der Netzwerkagent kann in den Speicher eines verwalteten Systems geladen werden, indem das tragbare Speichermedium angeschlossen wird, oder durch Herabladen aus dem Server und kann ausgeführt werden durch den Prozessor auf dem verwalteten System. Alternativ könnte der Netzwerkagent zumindest teilweise durch speziell angefertigte Firmware oder Hardware implementiert sein.
Es versteht sich, daß, auch wenn bestimmte Ausführungsformen der Erfindung beschrieben worden sind, viele Modifikationen/Zusätze und/oder Substitutionen innerhalb des Schutzumfangs der vorliegenden Erfindung vorgenommen werden können.

Claims

Netzwerkagent für ein Telekommunikationsnetzwerk, wobei der Netzwerkagent aufweist: ein erweiterbares Grundgerüst bzw. Grundgerüst (24); ein oder mehrere verwaltete Objekte (25–29), die bei dem Grundgerüst registriert werden können; und ein oder mehrere Netzwerkadapter (30–38), die bei dem Grundgerüst für ein Netzwerkkommunikationsprotokoll registriert werden können, um Zugriff auf die verwalteten Objekte zu ermöglichen, charakterisiert dadurch, daß ein verwaltetes Objekt ein Bean ist, das einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und zur Selbstprüfung bzw. Introspektion aufweist.
Netzwerkagent nach Anspruch 1, der ein Ablage- bzw. Speicherdienstobjekt (27) aufweist, das bei dem Grundgerüst registriert werden kann, wobei (ein) verwaltete(s) Objekt(e) und/oder Netzwerkadapter und/oder ein oder mehrere weitere Dienstobjekte bei dem Ablagedienstobjekt registriert werden können, wobei das verwaltete Objekt und die Netzwerkadapter über das Ablagedienstobjekt indirekt bei dem Grundgerüst registriert werden können.
Netzwerkagent nach Anspruch 2, wobei (ein) Netzwerkadapter (ein) Netzwerkadapterobjekt(e) aufweist bzw. aufweisen.
Netzwerkagent nach einem der vorstehenden Ansprüche, wobei das Grundgerüst Hol- und Setz-Eigenschaften aufweist und Hol- und Setz-Methoden implementiert, um Objekte und/oder Objektmethoden zu holen und/oder zu setzen.
Netzwerkagent nach Anspruch 4, wobei ein Netzwerkadapter auf eine empfangene externe Anforderung reagiert, um das Grundgerüst zu veranlassen, eine Methode eines verwalteten Objektes für diese Anforderung zu holen und eine anschließende Antwort zurückzugeben.
Netzwerkagent nach Anspruch 5, der ein Ablagedienstobjekt aufweist, das bei dem Grundgerüst registriert werden kann, wobei (ein) verwaltete(s) Objekt(e) und/oder (ein) Netzwerkadapter bei dem Ablagedienstobjekt registriert werden können, wobei das verwaltete Objekt und die Netzwerkadapter über das Ablagedienstobjekt indirekt bei dem Grundgerüst registriert werden können, wobei das Grundgerüst den Ablagedienst referenziert, um die Methode des verwalteten Objekts aufzurufen.
Netzwerkagent nach Anspruch 4, wobei das Grundgerüst darauf ausgelegt ist, Funktionen zum Hinzufügen und zum Entfernen eines Objektes zu bewirken.
Netzwerkagent nach einem der vorstehenden Ansprüche, wobei das Grundgerüst ein Bean ist, das einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und zur Selbstprüfung bzw. Introspektion aufweist.
Netzwerkagent nach einem der vorstehenden Ansprüche, wobei ein Netzwerkadapter ein Netzwerkadapter-Objekt aufweist.
Rechnersystem, das mit einem Telekommunikationsnetzwerk verbunden werden kann, wobei das Rechnersystem einen Netzwerkagenten nach einem der Ansprüche 1 bis 9 aufweist.
Netzwerkmanagementsystem, das einen Netzwerkagenten nach einem der Ansprüche 1 bis 9 aufweist.
Verfahren zum Bereitstellen von Agentendiensten über ein Telekommunikationsnetzwerk, wobei das Verfahren die Schritte aufweist: dynamisches Registrieren von einem oder mehreren verwalteten Objekten (25–29) bei einem erweiterbaren Agenten-Grundgerüst; Registrieren eines oder mehrerer Netzwerkadapter (30–38) für ein Netzwerkkommunikationsprotokoll bei dem Grundgerüst; und Ermöglichen eines Zugriffs auf (ein) verwaltete(s) Objekt(e) über (den) Netzwerkadapter, charakterisiert dadurch, daß ein verwaltetes Objekt ein Bean ist, die einen Satz von Eigenschaften, einen Satz von Methoden zum Durchführen von Aktionen und Unterstützung für Ereignisse und zur Selbstprüfung aufweist.
Verfahren nach Anspruch 12, wobei das Grundgerüst ein zugeordnetes Ablageobjekt (27) aufweist und die Schritte zum Registrieren das Registrieren des verwalteten Objektes und/oder der Netzwerkadapter bei dem Ablageobjekt aufweisen.
Verfahren nach Anspruch 13, wobei ein Netzwerkadapter auf eine empfangene externe Anforderung reagiert, um das Grundgerüst zu veranlassen, eine Methode eines verwalteten Objektes für diese Anforderung aufzurufen und eine anschließende Antwort zurückzugeben.
Verfahren nach Anspruch 14, wobei ein Netzwerkadapter ein Netzwerkadapter-Objekt auf weist.