DE69820566T2

DE69820566T2 - Verfahren, Vorrichtung, und Programmprodukt zum Zugriff auf einen Server-basierten Verwaltungsinformationsdienst

Info

Publication number: DE69820566T2
Application number: DE69820566T
Authority: DE
Inventors: Govindarajan Sunnyvale Rangarajan; Subodh Palo Alto Bapat; Rajasekar Union City Ranganathan; Akhill San Jose Arora
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1997-10-24
Filing date: 1998-10-16
Publication date: 2004-06-03
Anticipated expiration: 2018-10-17
Also published as: JPH11219342A; EP0912014A2; CA2251484A1; EP0912014A3; DE69820566D1; US6185609B1; EP0912014B1

Description

Die vorliegende Erfindung betrifft ein Verfahren, eine Vorrichtung und ein Programmprodukt zum Zugreifen auf ein Managementinformationssystem (MIS), das von einem Server bereitgestellt wird.
Insbesondere erhält ein JAVA-Anwendungsprogrammierer mit der vorliegenden
Erfindung eine Schnittstelle zu einem MIS wie z. B. dem Solstice^TM Enterprise Manager^TM von Sun Microsystems Inc., um auf Datensätze in dem MIS zuzugreifen.
Objektorientierte Programmiersprachen (OOP) assoziieren die Daten eines Objekts mit programmierten Methoden, die auf die Daten dieses Objekts wirken. Gewöhnlich werden OOP-Objekte in einem Heap-Speicherbereich instanziiert und basieren auf Klassen, die die programmierten Methoden für das OOP-Objekt referenzieren. Instanziierte OOP-Objekte enthalten Daten (in Instanzvariablen), die für das jeweilige instanziierte OOP-Objekt spezifisch sind. Vom Konzept her enthält ein OOP-Objekt objektbezogene Informationen (z. B. die Zahl der Instanzvariablen in dem Objekt), die Instanzvariablen sowie Adressen von programmierten Methoden, die auf den Inhalt der Instanzvariablen in dem Objekt zugreifen und/oder diese manipulieren. Da Objekte jedoch häufig programmierte Methoden und objektbezogene Informationen gemeinsam nutzen, werden diese gemeinsam genutzten Informationen gewöhnlich in eine Klasse extrahiert. Somit enthält das instanziierte Objekt einfach seine Instanzvariablen und einen Zeiger auf seine Klasse.
Smalltalk, Java und C++ sind Beispiele für OOP-Sprachen. Smalltalk wurde in der Learning Research Group im Palo Alto Research Center (PARC) von Xerox in den frühen 70er Jahren entwickelt. C++ wurde von Bjarne Stroustrup in den AT & T Bell Laboratories 1983 als eine Erweiterung der C-Programmiersprache entwickelt. Java ist eine OOP-Sprache mit Elementen von C und C++ und beinhaltet hochabgestimmte Bibliotheken für die Internet-Umgebung. Sie wurde von Sun Microsystems entwickelt und 1995 freigegeben.
Weitere Informationen über OOP-Konzepte befinden sich in Not Just Java von Peter van der Linden, Sun Microsystems Press/Prentice Hall PTR Corp., Upper Saddle River, NJ, (1997), ISBN 0-13-864638-4, Seiten 136–149.
Eine Client/Server-Rechenumgebung erlaubt es einem Client-Computer, einen Service oder eine Ressource zu benutzen, der/die von einem Server-Computer bereitgestellt wird. Im Allgemeinen wird der Server-Computer von vielen Clients benutzt. Die Client/Server-Umgebung bietet Vorteile, die in der Technik hinlänglich bekannt und in Not Just Java auf Seite 199 beschrieben sind. Mit der Ankunft von Programmierumgebungen, die von dem für ihre Ausführung verwendeten Computer unabhängig sind (z. B. Programmierumgebungen, die die Java Virtual Machine beinhalten), werden Client-Anwendungen entwickelt, die auf einer Vielzahl verschiedener Computer laufen. Da der ablauffähige Code für diese Anwendungen von der Computer-Architektur und dem den Code ausführenden Betriebssystem unabhängig ist, braucht lediglich eine Kompilation des ablauffähigen Codes erzeugt zu werden. Diese Kompilation des ablauffähigen Codes kann vom Speicher eines Servers über das Netzwerk zu einem Client übertragen werden, auf dem der Code ausgeführt wird. Zuweilen laufen Client- und Server-Teile einer Anwendung auf demselben Computer.
Ein "Thin-Client" ist ein vernetzter Client-Computer, der keinen permanenten lokalen Speicher hat. Somit kommt der Speicherdienst von einem Server-Computer, der als "Thick" oder "Fat"-Server bezeichnet wird. Thin-Clients lesen Java-Anwendungen, die auf dem Fat-Server gespeichert sind, und führen sie örtlich aus. Diese Anwendungen können wiederum auf Daten von dem Fat-Server oder auf andere Quellen auf dem Internet zugreifen. Die Thin-Client/Thick-Server-Umgebung ist in Not Just Java auf den Seiten 207– 218 beschrieben.
Wie zuvor erwähnt, ist Java eine objektorientierte Programmiersprache. Sie ist somit zum Transportieren von Objekten zwischen Client und Server nützlich. Es ist auch vorteilhaft; eine auf einem Computer befindliche Methode eines Objekts mit einem Programm aufzurufen, das auf einem anderen Computer läuft. Java benutzt im Allgemeinen die Fernmethoden-Aufrufschnittstelle (RMI), um diese Fähigkeit bereitzustellen. Die RMI-Schnittstelle ist in Core Java von Cornell and Horstmann, 2. Ausgabe, ISBN 0-13-596891-7 © 1997 Sun Microsystems, Inc. auf den Seiten 643–681 beschrieben. Es gibt noch weitere Schnittstellen (wie z. B. der CORBA-Standard), die ähnliche Funktionalität bieten. Der CORBA-Standard ist ausführlich in "CORBA Integrating Diverse Applications within Distributed Heterogeneous Environments" (Steve Vinoski, Ions Technologies, Inc. ISSM 0163-6804) beschrieben. Dieses Dokument betrachtet die Anwendung der Object Management Architecture, die von OMG (The Object Management Group of Companies) entwickelt wurde, sowie ihre Verwendung von ORBs (Object Request Brokers), um Kommunikationsroutinen zwischen heterogenen Systemen zu erzeugen. Das Dokument lehrt die Verwendung einer statischen oder dynamischen Aufrufschnittstelle, die auf Object Request Brokers (ORBs) basiert. Die für diese Prozesse benötigten Programmiervorgänge werden ausführlich erläutert, und es wird gezeigt, dass der Programmierer Clients über ORBs mit Hilfe von "Stubs" und "Skeletten" oder über eine "IDL"-Sprache mit Servern verbinden muss.
Eine Schwierigkeit mit Fernmethoden-Aufrufschnittstellen besteht darin, dass der Anwendungsprogrammierer explizit eine Referenz auf ein Fernobjekt erlangen muss, bevor er die programmierten Methoden dieses Objekts aufruft. Diese zusätzliche Komplexität erhöht die Schwierigkeit in Verbindung mit dem Erzeugen einer vernetzten Anwendung. Darüber hinaus werden die programmierten Methoden des Objekts je nach dem Ort des Objekts auf dem Client oder auf dem Server ausgeführt. Somit sind selbst einfache programmierte Verfahren, wie z. B. das Einholen des Wertes der Daten eines Objektes, Vorgänge mit hohem Overhead, wenn sich das Objekt auf dem Server befindet, weil der Client den Server veranlassen muss, die programmierte Methode auszuführen, die den Wert zurückgibt. Dieser Wert wird dann über das Netzwerk zum Client zurückgegeben. Diese Overheads beeinflussen die Leistung der Anwendung auf dem Thin-Client. Es wäre von Vorteil, ein Objekt bereitzustellen, das sich über die Client/Server-Schnittstelle erstreckt und die Fähigkeit hat, automatisch eine seiner programmierten Methoden auf dem Client und eine andere seiner programmierten Methoden auf dem Server auszuführen. Ein Aspekt der Erfindung bietet diese Fähigkeit.
Ein weiteres Problem mit Client-Server-Systemen wie z. B. dem zuvor beschriebenen Thin-Client/Fat-Server-System besteht darin, dass der. Sever-Teil des Systems im Allgemeinen Vorgänge auf einem existierenden Service aufrufen muss – einem, der nicht unbedingt im Hinblick auf die Nutzung moderner Rechenumgebungsfunktionen wie einer Multi-Thread-Fähigkeit implementiert wurde. Somit begrenzt der Programmierer im Allgemeinen die Implementation einer Anwendung auf die Programmiertechniken, die der existierende Service zulässt. Da viele existierenden Server-Anwendungen keine Thread-Safe-APIs unterstützen, müssen mehrere Client-Threads (entweder auf demselben Server oder über mehrere Server oder beides) den Zugang zu dem Service synchronisieren, so dass die Client-Anwendung mit modernen Programmiertechniken geschrieben werden kann. Somit brauchen, wenn der Service für die Anwendung der neuen Methodik aufgerüstet werden soll, die existierenden Client-Programme nicht so modifiziert zu werden, dass sie die neuen Fähigkeiten des Service nutzen. Darüber hinaus sind viele APIs in einer anderen Programmiersprache als der zum Schreiben einer Anwendung benutzten Sprache geschrieben. Es ist kostspielig, eine in einer Sprache geschriebene API in eine andere Sprache umzuwandeln. Es ist somit vorteilhaft, eine API bereitzustellen, die in der neuen Sprache geschrieben ist, die die Methoden aufruft, die von der entsprechenden, in der ursprünglichen Sprache geschriebenen API angewendet werden. Threads werden kurz in Not Just Java auf den Seiten 149–156 erörtert.
Ein Netzwerkmanagement-Informationsdienst ist ein Beispiel für einen Service, der einem Client von einem Server bereitgestellt werden kann. Ein solcher Service, wie der Solstice^TM Enterprise Manager^TM von Sun Microsystems Inc., sammelt Informationen über Netzwerkgeräte, speichert diese Informationen in einem Managementinformationsservice (MIS) und stellt diese Informationen anderen Anwendungen bereit. Die Überwachung dieser Informationen in einer Thin-Client/Fat-Server-Umgebung würde es einem Benutzer oder Netzwerkadministrator gestatten, das Netzwerk von kostenarmen Thin-Clients oder von einem Java-befähigten Web-Browser aus zu überwachen. Eine solche Netzwerkmanagementanwendung auf einem Client muss in der Lage sein, Informationen über die Netzwerkgeräte anzufordern, die für den Netzwerkadministrator relevant sind. Eine solche Anwendung muss auch eine Mitteilung empfangen, dass ein relevantes Event in Bezug auf diese Geräte in dem MIS aufgetreten ist. Es wäre somit vorteilhaft, eine Technik bereitzustellen, die den Zugang von Clients zu einem gemeinsam genutzten Service serialisiert und von dem Service erzeugte Events zu den Clients verteilt, die für den Empfang der Events registriert sind.
Methodem zur grafischen Darstellung von Informationen über den standardmäßiger. Netzwerkgebrauch sind in "Providing a web-based view of your managed network" (Jim Boyle et al, ISBN 0-7803-3926-6) erörtert. Dieses Dokument bezieht sich auf einen handhabbaren Ersatz für ein [sic], oder die Entwicklung von einem, existierenden Netzwerküberwachungsprotokoll – SNMP (Simply Network Management Protocol).
Ein weiteres Problem mit Client-Server-Systemen besteht darin, dass der Client Operationen auf seinem Server-MIS durchführt. Insbesondere erfordert das Senden großer Zahlen von Datensätzen von einem MIS-System vom Server zum Client eine signifikante Netzwerkbandbreite, wenn sich Client und Server auf verschiedenen Computersystemen befinden. Es kann auch sein, dass ein Client, wenn er ein Thin-Client ist, möglicherweise nicht genügend Ressourcen hat, um die Datensätze rechtzeitig zu verarbeiten oder zu speichern. Es wäre daher vorteilhaft, wenn der Server dem Client diejenigen Dienste, die umfangreiche rechnerische und E/A-Verarbeitung verlangen, durch eine API bereitstellt.
Zusammenfassung der Erfindung
Die vorliegende Erfindung stellt eine Vorrichtung, ein Verfahren und ein Computerprogrammprodukt zum Bereitstellen einer Anwendungsausführung auf einem Client mit einer Alarm-API für die Verbindung mit einem auf einem Server ablaufenden MIS bereit. Ein Aspekt der Erfindung ist ein computergesteuertes Verfahren, um einer Client-Anwendung Zugang zu einem Managementinformationsdienst MIS zu geben, der von einem Server bereitgestellt wird. Der MIS enthält Daten über einen überwachten Zustand. Das computergesteuerte Verfahren beinhaltet das Instanziieren einer Anwendungsprogrammiererschnittstelle (API) durch die Client-Anwendung, die ein logisches Objekt umfasst, und beinhaltet den Aufruf einer programmierten Methode des logischen Objekts durch die Client-Anwendung. Darüber hinaus führt der Server die programmierte Methode zum Zugreifen auf den MIS durch.
Ein weiterer Aspekt der Erfindung beinhaltet eine Vorrichtung mit einer Zentraleinheit (CPU) und einem Speicher, der mit der genannten CPU gekoppelt ist, um einer Client-Anwendung Zugang zu einem von einem Server bereitgestellten Managementinformationsservice (MIS) zu geben. Der MIS enthält Daten über einen überwachten Zustand. Die Vorrichtung umfasst einen Instanzüerungsmechanismus, der so konfiguriert ist, dass er als Reaktion auf die genannte Client-Anwendung eine Anwendungsprogrammiererschnittstelle (API) instanziiert. Die API umfasst ein logisches Objekt. Die Vorrichtung beinhaltet auch einen Methodenaufrufmechanismus; der so konfiguriert ist, dass er eine programmierte Methode des logischen Objekts durch die Client-Anwendung aufruft. Darüber hinaus beinhaltet die Vorrichtung einen Ausführungsmechanismus, der so konfiguriert ist, dass er die programmierte Methode am Server ausführt, um auf den MIS zuzugreifen.
Ein weiterer Aspekt der Erfindung beinhaltet ein Computerprogrammprodukt, das in einem rechnerbenutzbaren Medium eingebettet ist, um zu bewirken, dass ein Computer einer Client-Anwendung Zugang zu einem von einem Server bereitgestellten Managementinformationsservice (MIS) bietet. Der MIS enthält Daten über einen überwachten Zustand. Bei Ausführung auf einem Computer veranlasst der rechnerlesbare Code einen Computer, einen Instanzüerungsmechanismus, einen Methodenaufrufmechanismus und einen Ausführungsmechanismus zu aktivieren. Alle diese Mechanismen haben dieselben Funktionen wie die entsprechenden Mechanismen für die zuvor beschriebene Vorrichtung.
Die vorliegende Erfindung wird nachfolgend beispielhaft mit Bezug auf die Begleitzeichnungen näher beschrieben. Dabei zeigt:
1 ein Computersystem, das die Erfindung ausführen kann, gemäß einer bevorzugten Ausgestaltung;
2A eine Client-Server-Architektur gemäß einer bevorzugten Ausgestaltung;
2B eine Objekt-Fabrik gemäß einer bevorzugten Ausgestaltung;
2C ein Server-Objekt gemäß einer bevorzugten Ausgestaltung;
3 einen Server-Objekt-Erzeugungsprozess gemäß einer bevorzugten Ausgestaltung;
4 einen Server-Objekt-Initialisierungsprozess gemäß einer bevorzugten Ausgestaltung;
5 einen API-Registrierungsprozess gemäß einer bevorzugten Ausgestaltung;
6 einen API-Operation-Aufrufprozess gemäß einer bevorzugten Ausgestaltung;
7 einen Client-Event-Handler-Dispatch-Prozess gemäß einer bevorzugten Ausgestaltung;
8 einen auf dem Client befindlichen Event-Verteilungsprozess zum Weiterleiten eines Events zur registrierten API gemäß einer bevorzugten Ausgestaltung;
9 einen Server-Event-Handler-Prozess zum Weiterleiten eines Events zu dem Client-Dispatcher gemäß einer bevorzugten Ausgestaltung;
10 einen Konstruktur-Prozess für ein logisches Objekt gemäß einer bevorzugten Ausgestaltung;
11 einen Aufrufprozess für ein logisches Objekt gemäß einer bevorzugten Ausgestaltung; und
12 einen Vorgang einer Anwendungsprogrammiererschnittstelle mit einem logischen Objekt gemäß einer bevorzugten Ausgestaltung.
Beschreibung der bevorzugten Ausgestaltung
Notationen und Nomenklatur
Die folgenden 'Notationen und Nomenklatur' sollen beim Verständnis der vorliegenden Erfindung und deren bevorzugten Ausgestaltungen behilflich sein.
Anwendungsprogrammiererschnittstelle (API) – Die API ist eine Definition für die Klassen und programmierten Methoden, die ein Programmierer zum Implementieren einer Anwendung verwenden kann.
Konstruktor – Eine programmierte Methode zum Initialisieren einer Instanz eines Objekts.
Rahmen – Ein Rahmen ist ein Satz von Klassen, die erweiterbare Funktionen (unter Verwendung von objektorientierten Methodiken) zum Ausführen von Diensten für das Anwendungsprogramm bereitstellen, das den Rahmen benutzt. Somit sind Rahmen im Wesentlichen Gruppen von verbundenen Objektklassen, die eine vorgefertigte Struktur von Teilen einer Arbeitsanwendung bereitstellen. Eine API unterscheidet sich von einem Rahmen dadurch, dass der Rahmen eine Implementation der API ist. Der Rahmen beinhaltet auch private Methoden und Daten, die für den die API benutzenden Programmierer nicht sichtbar sind.
Java Native InterFace (JNI) – Eine API, die es zulässt, dass ein Java-Programm programmierte Objekte und andere Prozeduren aufruft, die nicht in Java programmiert sind (z. B. C oder C++ Prozeduren).
Logisches Objekt – Ein Verbundobjekt, umfassend ein oder mehrere Objekte, die in einer Client/Server-Umgebung zusammenwirken, um einen automatischen Netzwerkaufruf einer fernen programmierten Methode bereitzustellen. Die Lokalität der programmierten Methode (d. h. wo sie sich auf dem Client oder Server befindet) ist für den Programmierer transparent.
Managementinformationsservice (MIS) – Ein MIS ist ein Dienst, der von einem Server-Computer bereitgestellt wird. Somit ist der Service entweder eine Bibliothek oder ein Rahmen die/der einem Client Dienste anbietet. Client und Server können sich auf demselben Computer befinden.
Programinierte Methode – Eine programmierte Methode ist eine Prozedur in Verbindung mit einem objektorientierten Objekt oder einer solchen Klasse, die eine Funktion an dem Objekt ausführt.
Remote Method Invocation (RMI) – Ein Mechanismus, der eine verteilte Programmierung in einer Client/Server-Umgebung mit Java zulässt.
Topologischer Knoten – Eine logische Darstellung eines Netzwerkgerätes, das von einem Managementinformationsserver überwacht wird.
Prozedur – Eine in sich einheitliche Folge von Schritten, die zu einem gewünschten Ergebnis führen. Diese Schritte sind diejenigen, die eine physikalische Manipulation physikalischer Größen erfordern. Diese Größen haben gewöhnlich die Form elektrischer oder magnetischer Signale, die gespeichert, übertragen, kombiniert, verglichen oder auf andere Weise manipuliert werden können. Diese Signale werden als Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen oder dergleichen bezeichnet. Die Fachperson wird verstehen, dass alle diese und ähnliche Begriffe mit den entsprechenden physikalischen Größen assoziiert sind und lediglich praktische Bezeichnungen für diese Größen sind.
Übersicht
Die von einem Computer bei der Ausführung programmierter Anweisungen durchgeführten Manipulationen werden häufig mit Begriffen wie z. B. Addieren oder Vergleichung bezeichnet, die gewöhnlich mit von einem menschlichen Operator durchgeführten mentalen Vorgängen assoziiert sind. In der vorliegenden Erfindung ist keine solche Fähigkeit eines menschlichen Operators in den hier beschriebenen Operationen notwendig. Die Operationen sind maschinelle Operationen. Nützliche Maschinen zum Durchführen der Operationen der Erfindung sind u. a. programmierte digitale Universalcomputer oder ähnliche Geräte. In allen Fällen unterscheidet sich das Rechenverfahren vom Betriebsverfahren beim Betreiben eines Computers. Die vorliegende Erfindung bezieht sich auf Verfahrensschritte zum Betreiben eines Computers bei der Verarbeitung elektrischer oder anderer (z. B. mechanischer, chemischer) physikalischer Signale, um andere gewünschte physikalische Signale zu erzeugen.
Die Erfindung betrifft auch eine Vorrichtung zum Ausführen dieser Operationen. Diese Vorrichtung kann speziell für die gewünschten Zwecke aufgebaut sein oder sie kann einen Universalcomputer umfassen, der von einem im Speicher eines Computers gespeicherten Computerprogramm selektiv aktiviert oder umkonfiguriert werden kann. Die hierin dargestellten Prozeduren beziehen sich nicht unbedingt auf einen bestimmten Computer oder eine andere bestimmte Vorrichtung. Insbesondere können verschiedene Universalmaschinen mit Programmen verwendet werden, die gemäß den Lehren hierin geschrieben wurden, oder sie können sich als praktischer beim Aufbau spezialisierterer Vorrichtungen zum Durchführen der benötigten Verfahrensschritte erweisen. Die benötigte Struktur für eine Reihe verschiedener solcher Maschinen geht aus der nachfolgenden Beschreibung hervor. Die Erfindung kann auch in einem rechnerlesbaren Speichermedium ausgestaltet werden, das mit einem Programm codiert ist, das einen Computer zum Ausführen der programmierten Logik veranlasst.
Betriebsumgebung
Einige der Elemente eines Computersystems, durch die allgemeine Bezugsziffer 100 bezeichnet, das zum Unterstützen der Erfindung konfiguriert ist, sind in 1 dargestellt. 1 zeigt einen Prozessor 101 mit einer Zentraleinheit (CPU) 103, einem Speicherteil 105 und einem Ein-/Ausgabe- (E/A) Teil 107. Der E/A-Teil 107 ist mit einer Tastatur 109, einer Anzeigeeinheit 111, einem Zeigergerät 113, einer Plattenspeichereinheit 115 und einer CD-ROM- Laufwerkseinheit 117 verbunden. Die CD-ROM-Laufwerkseinheit 117 kann ein CD-ROM-Medium 119 lesen, das gewöhnlich ein Programm und Daten 121 enthält. Die CD-ROM-Laufwerkseinheit 117, zusammen mit dem CD-ROM-Medium 119, und die Plattenspeichereinheit 115 umfassen einen Datenspeichermechanismus. Die Fachperson wird verstehen, dass die CD-ROM-Laufwerkseinheit 117 durch eine Diskette, eine Magnetbandeinheit oder ein ähnliches Gerät ersetzt werden kann, das ein entfernbares Medium akzeptiert, das das Programm und die Daten 121 enthalten kann. Darüber hinaus beinhaltet das Computersystem 100 eine Netzschnittstelle 123, die den Prozessor 101 mit einem Netzwerk 125 verbindet. Das Netzwerk 125 kann für die Kommunikation zwischen dem Prozessor 101 und einem vernetzten Computer 127 verwendet werden. Ein solches Computersystem ist ein Beispiel für ein System, das Prozeduren ausführen kann, die die Erfindung ausgestalten.
Die Fachperson wird verstehen, dass Client-Server-Architekturen es ermöglichen, dass Client-Programm und Server-Programm auf demselben Computer oder auf separaten vernetzten Computersystemen ausgeführt werden. Während sich die nachfolgende Beschreibung auf eine vernetzte Computersystem-Architektur bezieht, bezieht sie sich ebenso auf einen einzelnen Computer, auf dem sich sowohl Server als auch Client befinden.
JAVA-Management-Adapter.
2A illustriert eine Client-Server-Architektur, mit der allgemeinen Bezugsziffer 200 bezeichnet, die eine in einer Sprache programmierte Multi-Thread-Client-Anwendung befähigt, einen vom Server bereitgestellten Single-Thread-Service zu nutzen. Die Architektur 200 beinhaltet einen Client 201, bei dem es sich häufig um einen Computer oder um ein Netzwerkgerät handelt. Die Fachperson wird verstehen, dass die nachfolgend beschriebene Erfindung sich auch auf vollfunktionelle große Computer sowie auf Thin-Clients bezieht. Der Client 201 kommuniziert mit einem Server 203, der sich häufig auf einem Computer separat von dem Computer befindet, der den Client 201 beherbergt. Eine Anwendung 205 läuft in dem Client 201 ab und ruft Prozeduren von einer API 207 auf. Die API 207 kann ein objektorientierter Rahmen oder eine prozedurale Bibliothek sein. Die API 207 kommuniziert mit einem Java-Management-Adapter (JMA) 209, der sich auf dem Server 203 befindet. Der JMA 209 verwendet eine Java-Native-Interface (JNI) 211, um auf Funktionen einer portablen Management-Schnittstelle (PMI) 213 zuzugreifen. Die PMI 213 ist ein Multi-Thread-Unsafe-Rahmen (in C++ geschrieben), der Zugang zu einem Managementinformationsservice (MIS) 215 bietet (z. B. das Enterprise Manager^TM von Sun Microsystems Inc.).
2B illustriert eine JMA-Architektur, mit der allgemeinen Bezugsziffer 220 bezeichnet, die einen JMA-Dispatcher 221, ein erstes Serverobjekt 223 und ein zweites Serverobjekt 225 beinhaltet. Der Client 201 kommuniziert mit dem JMA-Dispatcher 221 zum Erzeugert von Server-Objekten wie z. B. dem ersten Server-Objekt 223 und dem zweiten Server-Objekt 225. Ein Server-Objekt existiert für jeden Client, der beim JMA-Dispatcher 221 registriert ist. Der JMA-Dispatcher 221 ist eine Objektfabrik, die ein Server-Objekt im Server 203 für jeden registrierten Client erzeugt.
2C illustriert eine Server-Objekt-Umgebung, mit der allgemeinen Bezugsziffer 230 bezeichnet, die Zugang von einem Multi-Thread-Client zum MIS 215 serialisiert. Die Server-Objekt-Umgebung 230 beinhaltet ein Server-Objekt 231, das einen 'Server-Event-Handler' Thread 233 und einen 'Kontroll-PMI' Thread 235 enthält, der eine Ausschlusssperre 237 erzeugt. Die Ausschlusssperre 237 serialisiert einen Thread, z. B. einen 'PMI-Operation' Thread 239, der auf eine JNI/PMI-Prozedur 241 wirkt. Der 'PMI-Operation' Thread 239 wird vom 'Kontroll-PMI' Thread 235 als Reaktion auf den Empfang, durch das Server-Objekt 231, einer Anforderung zum Ausführen einer Operation von der API 207 gestartet. Sobald der 'PMI-Operation' Thread 239 die Ausschlusssperre 237 erhält; kann der 'PMI-Operation' Thread 239 eine JNI/PMI-Prozedur 241 zum Zugreifen auf den angeforderten Dienst aufrufen.
Der 'Server-Event-Handler' Thread 233 empfängt Event-Bedingungen von der JNI/PMI-Prozedur 241 und leitet diese Events an den mit dem Server-Objekt 231 assoziierten Client 201 weiter.
3 illustriert einen Server-Erzeugungsprozess, mit der allgemeinen Bezugsziffer 300 bezeichnet, der vom Client-Teil des JMA-Dispatchers zum Instanziieren eines JMA-Server-Objektes verwendet wird. Der Server-Erzeugungsprozess 300 beginnt an einem 'Start' Terminal 301 und geht zu einer 'Newserver-Meldung empfangen' Prozedur 303 weiter, die eine 'New Server' Meldung empfängt. Die 'New Server' Meldung wird von einer 'Lookup-Host' Prozedur 305 verarbeitet, die einen Verweisadressen- (URL) String verwendet, der von der 'New Server' Meldung geliefert wird, um das Server-Computersystem zu finden und eine Verbindung damit herzustellen. Wenn kein URL-String bereitgestellt wird, geht die 'Lookup-Host' Prozedur 305 davon aus, dass sich der Service auf demselben Computer befindet wie der Client. Wenn das Server-System gefunden ist, dann geht der Server-Erzeugungsprozess 300 zu einer 'Lookup-JMA-Dispatcher' Prozedur 307 weiter, die den JMA-Dispatcher mit in der Technik hinlänglich bekannten Methoden wie z. B. Anschluss an einen bekannten Port oder Verwenden eines Verzeichnisses zum Finden des Dispatchers sucht. Als Nächstes bewirkt eine euen Server instanziieren' Prozedur 309, dass die JMA-Dispatcher-Anwendung auf dem Server ein neues Server-Objekt auf dem Server-System instanziiert. Das neue Server-Objekt stellt dem Client die gewünschten Dienste zur Verfügung. Dann fährt der Server-Erzeugungsprozess 300 mit einer 'Lookup New Server' Prozedur 311 fort, die das soeben erzeugte, auf dem Server-Computersystem ablaufende Server-Objekt findet. Dann fährt der Server-Erzeugungsprozess 300 mit einer 'Eventdispatch-Thread starten' Prozedur 313 fort, die einen Thread einleitet, der zum Versenden von Events, die von dem soeben erzeugten Server empfangen wurden, zu Objekten verwendet wird, die zum Empfangen vorgegebener Events registriert sind.
Wenn der Client-Event-Dispatch-Thread von der 'Start-Eventdispatch-Thread' Prozedur 313 gestartet ist, dann fährt der Server-Erzeugungsprozess 300 mit einer 'mit Event-Handler-Thread des neuen Servers verbinden' Prozedur 315 fort, die bewirkt, dass der Event-Dispatch-Thread eine Verbindung zum Event-Handling-Thread des Servers herstellt (nachfolgend mit Bezug auf 4 beschrieben). Der Server-Erzeugungsprozess 300 wird dann durch einen 'Ende' Terminal 317 beendet.
4 illustriert einen Server-Initialisierungsprozess, mit der allgemeinen Bezugsziffer 400 bezeichnet, der von der 'neuen Server instanziieren' Prozedur 309 von 3 aufgerufen wird. Der Server-Initialisierungsprozess 400 beginnt an einem 'Server-Objekt-Start' Terminal 401 und geht zu einem 'ersten PMI-Thread starten' Prozess 403 über, der den ersten PMI-Zugangsthread startet. Dieser Thread dient zum Initialisieren der PMI durch die JNI. Dieser Thread etabliert auch die Sperrmechanismen zum Serialisieren des Zugriffs durch andere PMI-Operation-Threads innerhalb des Server-Objekts auf den PMI-Rahmen. Die Fachperson wird verstehen, dass mit diesen Techniken auch auf andere Thread-Unsafe-Rahmen zugegriffen werden kann. Nach dem Start des ersten PMI-Thread geht der Server-Initialisierungsprozess 400 zu einem 'Event-Handler-Thread starten' Prozess 405 über, der von dem MIS erzeugte Events zum entsprechenden Client leitet. Dann wartet ein 'Verbindung zu Eventdispatch-Thread des Client herstellen' Prozess 407, bis die 'mit Event-Handler-Thread des Servers verbinden' Prozedur 315 versucht, eine Verbindung mit dem Event-Handler-Thread herzustellen, der von dem 'Event-Handler-Thread starten' Prozess 405 gestartet wurde. Wenn der Event-Handler-Thread des Servers mit dem Event-Dispatch-Thread des Clients verbunden ist, dann wird der Server-Initialisierungsprozess 400 über einen 'Ende'-Terminal 409 beendet. Wenn der Server-Initialisierungsprozess 400 beendet ist, kann der Server Ergebnisse für Anforderungen von Anwendungen empfangen, verarbeiten und zurückgeben, die auf dem Client ablaufen, und kann Events vom Server zum Client weiterleiten.
5 illustriert einen API-Registrterungsprozess, mit der allgemeinen Bezugsziffer 500 bezeichnet, der eine API wie z. B. eine Alarm-API mit dem JMA registriert. Der API-Registrierungsprozess 500 beginnt an einem 'API-Start registrteren' Terminal 501 als Reaktion darauf, dass die API den Registrierungsprozess aufruft. Der API-Registrierungsprozess 500 fährt mit einer 'API-Service instanziieren' Prozedur 503 fort, die einen JMA-Service für die anfordernde API instanziiert. Nach dem Instanziieren des Service beginnt der Service einen API-Dienst an einer 'API-Service starten' Prozedur 505. Der API-Service dient zum Verarbeiten von Anforderungen von der API an den JMA.
Nach dem Start des API-Service gibt der API-Registrierungsprozess 500 in einer 'API-Service-Handle zurückgeben' Prozedur 507 den API-Handle zurück. Der zurückgegebene API-Handle entspricht dem API-Service, der in der 'API-Service instanziieren' Prozedur 503 instanziiert wurde. Der API-Registrierungsprozess 500 wird an einem 'Ende'-Terminal 509 beendet. Die API kann Dienste (Operationen) vom IM anfordern, sobald die API registriert ist.
6 illustriert einen API-Operation-Prozess, mit der allgemeinen Bezugsziffer 600 bezeichnet, der einen PMI-Aufruf verarbeitet, der von einer API-Operation resultierte. Der API-Operation-Prozess 600 beginnt an einem 'API-Operation-Start' Terminal 601 als Reaktion darauf, dass die API-Anwendung einen JMA-Dienst anfordert, der einen PMI-Service aufruft. Der API-Operation-Prozess 600 fährt mit einer 'PMI-Sperre aufrufen' Prozedur 603 fort, die die PMI-Sperre holt, die vom ersten PMI-Thread etabliert wurde, der mit dem 'ersten PMI-Thread starten' Prozess 403 von 4 erzeugt wurde. Die Fachperson wird verstehen, dass der Thread so lange unterbrochen wird, bis er die Sperre holen kann. Die Fachperson wird auch verstehen, dass der API-Service-Thread einen Thread zum Durchführen der angeforderten Operation zuweist. Nach dem Holen der Sperre fährt der API-Operation-Prozess 600 mit einer 'PMI-Operation aufrufen' Prozedur 605 fort. Die 'PMI-Operation aufrufen' Prozedur 605 ruft jetzt die entsprechende PMI-Operation vom PMI-Rahmen durch die JNI auf. Nach Rückkehr der PMI-Operation gibt eine 'PMI-Sperre freigeben' Prozedur 607 die PMI-Sperre frei, so dass andere Threads auf den PMI-Rahmen zugreifen können. Wenn ein Ergebnis von der PMI-Operation zurückgegeben wird, dann wird der Operation-Ergebniswert zur API-Anwendung zurückgegeben. Schließlich wird der Prozess durch einen 'Ende'-Terminal 609 beendet. Somit serialisiert der API-Operation-Prozess 600 den Zugang auf den PMI-Rahmen und führt die von der API angeforderte Operation durch. Die Fachperson wird auch verstehen, dass die vom JMA benutzten Operationen auf andere Dienste als den PMI-Rahmen angewendet und von einer traditionellen Routine-Bibliothek bereitgestellt werden können.
Die JMA-API-Schnittstelle wird mit Bezug auf die Handhabung von Events optimiert. Anstatt RMI oder andere Client/Server-Objektkommunikationspakete zu verwenden, verwendet diese Schnittstelle einen TCP/IP-Socket oder ein Äquivalent.
7 illustriert einen Client-Event-Dispatch-Prozess, mit der allgemeinen Bezugsziffer 700 bezeichnet, der Events verarbeitet, die vom Server-Event-Handler-Thread geliefert werden, der nachfolgend mit Bezug auf 9 beschrieben wird. Der Prozess 700 beginnt mit einem 'Start'-Terminal 701 und fährt mit einer 'für Server verzögern' Prozedur 703 fort, die auf den Start des Event-Handler-Threads des Servers wartet (aufgerufen durch den 'Event-Handler-Thread starten' Prozess 405 von 4). Die 'für Server verzögern' Prozedur 703 wird dann beendet, wenn der Prozess 700 die durch den 'mit EventdispatchThread' des Client verbinden Prazess 407 eingeleitete Verbindung erhält Sobald der Prozess 700 erfasst, dass der Server-Event-Handler gestartet ist, fährt der Prozess mit einer 'eingehende Event-Threads starten' Prozedur 705 fort. Die 'eingehende Event-Threads starten' Prozedur 705 erzeugt genügend Threads, um (höchstens) die maximale Anzahl von Events zu handhaben, die während der Zeit erwartet werden, die zum Verarbeiten des längsten Events benötigt wird. Als Nächstes wartet eine 'API-Event-Zuhörerregistrierung empfangen' Prozedur 707 darauf, dass sich eine API bei dem Prozess 700 registriert. Die Event-Zuhörerregistrierung wird von der 'Verbindung mit Event-Handler-Thread des neuen Servers herstellen' Prozedur 315 von 3 gesendet. Die 'API-Event-Zuhörerregistrierung empfangen' Prozedur 707 speichert die Identifikation der API und der Event-Typen, die für die API von Interesse sind. Als Nächstes wartet der Prozess 700 in einer 'Event-Lieferung' Prozedur 708 auf den Eingang eines Events, der von einer beliebigen relevanten Event-Quelle (wie z. B. dem MIS) erzeugt und gesendet wurde. Als Nächstes weist eine 'Event Thread zuweisen' Prozedur 709 das Event einem Thread zur Verarbeitung zu. Wenn das Event einem Thread zugewiesen ist, führt der Thread eine 'Event zu registrierter API weiterleiten' Prozedur 711 aus, die ermittelt, welche registrierten APIs (ggf.) eine angeforderte Mitteilung für das Event haben, und verteilt das Event an diese APIs. Events werden vom Event-Handler-Prozess des Servers gesendet, wie nachfolgend mit Bezug auf 9 beschrieben wird. Dann fährt der Prozess 700 mit einer 'Beendigung angefordert' Entscheidungsprozedur 713 fort, die ermittelt, ob der Prozess 700 beendet werden soll. Wenn der Prozess 700 fortgesetzt werden soll, dann kehrt der Prozess zur 'Event Thread zuweisen' Prozedur 709 zurück und wartet auf das nächste Event. Wenn der Prozess jedoch beendet werden soll, dann geht er zu einer 'Threads stoppen' Prozedur 715 über, die die Threads stoppt, die an der 'eingehende Event-Threads starten' Prozedur 705 begonnen haben. Der Prozess wird dann an einem 'Ende'-Terminal 717 beendet.
8 illustriert einen 'Event an API weiterleiten' Prozess, mit der allgemeinen Bezugsziffer 800 bezeichnet, der von der 'Event an registrierte API weiterleiten' Prozedur 711 von 7 aufgerufen wird. Der Prozess 800 beginnt an einem 'Start'-Terminal 801 und fährt mit einer 'Event-ID-Übereinstimmung' Entscheidungsprozedur 803 fort, die das Event untersucht, um zu ermitteln, ob eine API für diesen Event-Typ registriert ist. Wenn die 'Event-ID-Übereinstimmung' Entscheidungsprozedur 803 eine erfolgreiche Übereinstimmung des Events mit einer registrierten API feststellt, fährt der Prozess 800 mit einer 'Event-Kopie an Event-Handler der API weiterleiten' Prozedur 805 fort, die eine Kopie des Events an diejenigen APIs weiterleitet, die für den Empfang von Events dieses Typs registriert sind. In einer bevorzugten Ausgestaltung werden diese Event-Kommunikationen von einem Kommunikationsmechanismus mit niedrigem Overhead wie z. B. TCP/IP-Sockets oder einem Äquivalent verarbeitet. Der Prozess 800 fährt dann mit einer 'Event entreferenzieren' Prozedur 807 fort, die die Referenzierung des ursprünglichen Events aushebt. Wenn die 'Event-ID-Übereinstimmung' Entscheidungsprozedur 803 ermittelt, dass das Event nicht für eine der registrierten APIs von Interesse ist, dann fährt der Prozess einfach mit der 'Event entreferenzieren' Prozedur 807 fort. Nach dem Ende der 'Event entreferenzieren' Prozedur 807 wird der Prozess 800 durch einen 'Ende'-Terminal 809 beendet.
9 illustriert einen 'Server-Event-Handler' Prozess, mit der allgemeinen Bezugsziffer 900 bezeichnet, der ein Event empfängt, das am Server auftritt, und das Event zum Client-Event-Dispatch-Prozess 700 von 7 weiterleitet. Der 'Server-Event-Handler' Prozess 900 beginnt am 'Start'-Terminal 901 und fährt mit einer 'Event empfangen' Prozedur 903 fort. Die 'Event empfangen' Prozedur 903 empfängt ein Event, das am Server erzeugt wurde. Dann sendet eine 'Event zu Client senden' Prozedur 905 das Event zum Event-Dispatcher des Clients (zuvor mit Bezug auf 7 beschrieben), wo das Event in der 'Event-Lieferung' Prozedur 708 empfangen wird. Dann wird der 'Server-Event-Handler' Prozess 900 an einem 'Ende'-Terminal 907 beendet.
Thin-Class
Eine Thin-Class ist eine logische Klasse (die ein logisches Objekt definiert), die zum Reduzieren des Ressourcen-Gebrauchs auf dem Client implementiert wird. Ein Vorteil dieser Thin-Class ist, dass sie die Komplexität in Verbindung mit der Programmierung von verteilten Anwendungen verbirgt. Die Thin-Class macht auch die verteilte Natur des Objekts für den Programmierer transparent, weil die Thin-Class automatisch den Client-Server-Kommunikationsmechanismus (bei Bedarf) für eine Kommunikation mit einer auf dem Server befindlichen programmierten Methode aufruft. Der in der Client-Server-Kommunikation verwendete zugrunde liegende Transportmechanismus ist häufig der ferne Methodenaufrufmechanismus (RMI), der Objekt-Request-Broker-Mechanismus gemäß Definition im CORBA-Standard oder ein anderer ähnlicher Mechanismus. Schließlich erlaubt es die Thin-Class einem API-Programmierer, Ausführungsgeschwindigkeit und Speichergebrauch zum Ausführen der API dadurch abzustimmen, dass die Lokalität der in der Klasse verwendeten programmierten Methode vorgegeben wird. Somit können sich einfache programmierte Methoden beim Client befinden, während komplexere programmierte Methoden sich beim Server befinden können. Der Programmierer einer Anwendung, der ein logisches Objekt der API verwendet, weiß nichts über die Lokalität der programmierten Methoden für dieses logische Objekt.
10 illustriert einen 'Thin-Class-Konstruktor' Prozess, mit der allgemeinen Bezugsziffer 1000 bezeichnet, der von einem logischen Objekt verwendet wird, wenn das logische Objekt instanziiert wird. Der 'Thin-Class-Konstruktor' Prozess 1000 beginnt an einem 'Start'-Terminal 1001 und fährt mit einer 'lokalen Teil instanziieren' Prozedur 1003 fort. Die 'lokalen Teil instanziieren' Prozedur 1003 erzeugt ein Objekt an dem Client, das programmierte Methoden für das logische Objekt bereitstellt, die auf dem Client ablaufen. Diese programmierten Methoden sind im Allgemeinen diejenigen, die klein und einfach genug sind, so dass die Ressourcen des Thin-Client durch die Instanziierung des Objektes oder die Ausführung der assoziierten programmierten Methoden nicht negativ beeinflusst werden. Ein Beispiel für ein solches Objekt wäre ein Objekt, das begrenzte private Daten enthält und programmierte Methoden hat, die Zugang zu diesen privaten Daten bieten. Solche programmierten Methoden sind im Allgemeinen klein genug und laufen auch schnell genug ab, so dass sie auf dem Thin-Client auf geeignete Weise implementiert werden können. Als Nächstes geht der 'Thin-Class-Konstruktor' Prozess 1000 zu einer 'Kommunikation mit Server einleiten' Prozedur 1005 über, die eine Kommunikation mit dem Fat-Server einleitet. Diese Prozedur sucht im Allgemeinen den Server-Host und stellt eine Verbindung mit einem bekannten Prozess her. Eine 'Fern-Teil instanziieren' Prozedur 1007 bewirkt, dass der bekannte Prozess einen Fernteil des logischen Objekts auf dem Fat-Server instanziiert. Der Fernteil beinhaltet programmierte Methoden, die den Betrieb des Thin-Client beeinflussen würden. Der API-Entwickler ermittelt, ob der Thin-Client oder der Fat-Server die programmierten Methoden ausführen soll, und implementiert die API entsprechend. Schließlich wird der 'Thin-Class-Konstruktor' Prozess 1000 durch einen 'Ende'-Terminal 1009 beendet. Die Fachperson wird verstehen, dass der 'Thin-Class-Konstruktor' Prozess 1000 nach Bedarf Objekt-Stubs und -Skelette erzeugt, wenn der Client-Server-Kommunikationsmechanismus eine RMI ist. Es existieren – oder können konstruiert werden – äquivalente Mechanismen für andere Client-Server-Kommunikationstechnologien.
11 illustriert einen Prozess zum Aufrufen einer programmierten Methode eines logischen Objekts, mit der allgemeinen Bezugsziffer 1100 bezeichnet, zum Aufrufen der programierten Mathode eines logischen Objekts. Der Prozess 1100 zum Aufrufen der programmierten Methode eines logischen Objektes beginnt an einem 'Start'-Terminal 1101 und fährt mit einer 'Fernmethode' Entscheidungsprozedur 1103 fort. Die 'Fernmethode' Entscheidungsprozedur 1103 ermittelt, ob die auszuführende programmierte Methode sich im Client-Teil oder im Server-Teil des logischen Objekts befindet. Wenn sich die programmierte Methode im Client-Teil befindet, dann fährt der Prozess 1100 mit dem Aufrufen der programmierten Methode des logischen Objektes zu einer 'lokale Methode aufrufen' Prozedur 1105 fort, die die im Client befindliche programmierte Methode versendet. Die programmierte Methode läuft auf dem Client mit den Daten ab, die sich im Client-Teil des logischen Objektes befinden. Nach der Rückkehr der programmierten Methode wird der Prozess 1100 zum Aufrufen der programmierten Methode des logischen Objektes durch einen 'Ende'-Terminal 1107 beendet.
Wenn jedoch die 'Fernmethode' Entscheidungsprozedur 1103 ermittelt, dass sich die auszuführende programmierte Methode im Server-Teil des logischen Objekts befindet, dann geht der Prozess 1100 mit dem Aufrufen der programmierten Methode des logischen Objektes zu einer 'Stub-Methode aufrufen' Prozedur 1111 über. Die 'Stub-Methode aufrufen' Prozedur 1111 sendet eine Kopie der Instanzvariablen des logischen Objekts im Client-Teil zum Server-Teil und ruft dann das Stub-Objekt auf, das dem Skelettobjekt entspricht, das sich im Server-Teil des logischen Objekts befindet.
In einer RMI-Umgebung kommuniziert die 'Stub-Methode aufrufen' Prozedur 1111 mit einem Skelettobjekt, das sich im Server-Teil des logischen Objekts befindet. diese Kommunikation bewirkt, dass eine 'Skelettmethode aufrufen' Prozedur 1113 die ferne programmierte Methode zur Ausführung veranlasst. Eine 'Fernmethode ausführen' Prozedur 1115 führt die programmierte Methode in dem Server unter Verwendung der Instanzvariablenwerte aus, die von der 'Stub-Methode aufrufen' Prozedur 1111 gesendet wurden. Als Nächstes sendet eine 'Ferndaten senden' Prozedur 1117 die möglicherweise modifizierten Instanzvariablendaten vom Server-Teil des logischen Objekts zurück zum Client-Teil des logischen Objekts, um den Client-Teil des logischen Objekts zu aktualisieren. Der Prozess 1100 zum Aufrufen der programmierten Methode des logischen Objekts wird dann durch den 'Ende'-Terminal 1107 beendet.
Die Fachperson wird verstehen, dass die vorherige Beschreibung sich zwar auf eine Ausgestaltung bezieht, die die RMI-Fähigkeiten von Java benutzt, aber es können im Rahmen der Erfindung auch andere Objektkommunikationsprotokolle, wie z. B. CORBA, benutzt werden.
Ferner kann die Anwendung, wenn die lokalen und fernen Teile des logischen Objekts konstruiert sind, die Methoden des logischen Objekts der API transparent dahingehend aufrufen, ob die Methode tatsächlich vom Client oder vom Server ausgeführt wird. So werden Programmieranwendungen für Thin-Clients durch die Verwendung von APIs stark vereinfacht, die eine Thin-Class implementieren. Eine solche API verbirgt die Einzelheiten der Client/Server-Kommunikation vor dem Programmierer und lässt es zu, dass der Programmierer transparent die API ohne Rücksicht auf zugrunde liegende Inter-Programm-Kommunikationsfragen verwendet. Der Programmierer einer Anwendung, der die API benutzt, kann die API-Objekte ohne Rücksicht darauf transparent benutzen, ob das Objekt im Client oder im Server abläuft, und die Methode wird automatisch nach Bedarf auf dem Server ausgeführt. Stattdessen wird diese Überlegung vom Programmierer der API analysiert, der ermittelt, welche Methoden im Client und im Server ausgeführt werden sollen. Einige Ausgestaltungen der API lassen eine dynamische Ermittlung der Lokalität der Methoden des logischen Objekts zu. Diese Ausgestaltungen ermitteln die Fähigkeiten und Ressourcen des Client und ermitteln die Lokalität der Methoden auf der Basis dieser Ermittlung.
Die Benutzung einer Thin-Class ermöglicht auch eine Änderung des zugrunde liegenden Inter-Programm-Kommunikationsmechanismus (d. h. RMI, CORBA oder einen anderen Mechanismus), ohne dass das Anwendungsprogramm geändert werden müsste.
ALARM-API
Ein Aspekt der Erfindung ist der einer Alarm-API. Die Alarm-API gibt dem Programmierer Funktionen zum Zugreifen auf einen Managementinformationsservice (MIS) von einem Thin-Client. Somit kann eine Anwendung, die zum Anzeigen von Alarminformationen über vernetzte Geräte ausgelegt ist, die Alarm-API zum Einholen von Informationen über diese Geräte verwenden. Die API ist eine Implementation der zuvor beschriebenen Thin-Class.
Der API-Programmierer ermittelt, welche Methoden lokal (auf dem Client ausgeführt) und welche fern (auf dem Server ausgeführt) sind. Der Programmierer, der die API benutzt, braucht nicht zu verstehen, wo die programmierte Methode ausgeführt wird. Die Server/Client-Kommunikation ist für den Programmierer, der die API benutzt, transparent. Somit braucht der Programmierer selbst bei sehr dünnen Thin-Clients keine Kompromisse zu finden, die normalerweise für die Verwendung des Thin-Clients notwendig sind; da der API-Programmierer dies bereits getan hat.
Der Thin-Client erhält häufig einen AlarmRecord als Reaktion auf nachfolgend beschriebene Methoden. Um die Menge an im Thin-Client benutztem Speicherplatz und die zwischen dem Thin-Client und dem die Netzwerkdatenbank enthaltenden Fat-Server benötigte Bandbreite zu minimieren, werden nur ausgewählte Teile des AlarmRecord (die Attribute von Interesse) übertragen. Der Programmierer wählt die Attribute von Interesse aus, indem er ein Argument des Typs AlarmRecordAttributeSet im Aufruf der entsprechenden programmierten Methoden vorgibt.
Im nachfolgenden Abschnitt bezieht sich der Begriff "Methode" auf eine "programmierte Methode".
12 illustriert einen MIS-Zugangsprozess, mit der allgemeinen Bezugsziffer 1200 bezeichnet, um einem Client Zugang zu einem auf einem Server befindlichen MIS zu geben. Der Prozess 1200 beginnt an einem 'Start'-Terminal 1201 damit, dass eine Anwendung im Client abläuft, und fährt mit einer 'API instanziieren' Prozedur 1203 fort.
Die 'API instanziieren' Prozedur 1203 instanziiert eine API im Client. Als Nächstes gibt die Anwendung in einer 'Attribute von Interesse vorgeben' Prozedur 1205 die Attribute von Interesse vor. Die Attribute von Interesse spezifizieren, welche Felder in von dem Server zurückgegebenen Datensätzen enthalten sind. Als Nächstes ruft die Anwendung eine Methode in der API in einer 'API-Methode aufrufen' Prozedur 1207 auf, die eine Meldung zum Server sendet, um ihn anzuweisen, eine Operation durchzuführen. Der Server führt dann die aufgerufene Methode an einer 'API-Methode ausführen' Prozedur 1209 aus. Diese Methode greift auf den MIS zu, um Daten zu erhalten und die gewünschten Operationen an den Daten durchzuführen. Im Allgemeinen ergibt diese Methode Ergebnisse, die in einer 'Werte für Attribute von Interesse zurückgeben' Prozedur 1211 dem Client zurückgegeben werden. Einige Methoden durchqueren rekursiv den Topologie-Baum, der von einem bestimmten topologischen Knoten im Netzwerk absteigt. Diese Methoden können ein Ergebnis für jeden durchquerten Knoten zurückgeben. Die 'Werte für Attribute von Interesse zurückgeben' Prozedur 1211 sammelt die Werte für die von der 'Attribute von Interesse zurückgeben' Prozedur 1205 vorgegebenen Attribute von Interesse und sendet diese Informationen zum Client, wo die Anwendung darauf zugreifen kann. Die für eine Alarm-API zurückgegebenen Informationen liegen in der Form von Alarmdatensätzen vor. Der Prozess 1200 kann dann Daten über einen überwachten Zustand im MIS zurückgeben. Wenn der MIS ein Netzwerk-MIS ist, dann sind diese Daten häufig der Status eines uberwachten Gerätes oder eines topologischen Knotens: Diese Daten können einem Benutzer der Client-Anwendung dann zur Verfügung gestellt werden.
Tabelle 1
Tabelle 1 ist eine Liste der öffentlichen Methoden, die zum Zurückgeben von Datenwerten von Feldern im AlarmRecord zur Verfügung stehen. Eine Ausnahme liegt dann vor, wenn versucht wird, ein Feld zurückzugeben, das dem Client nicht mitgeteilt wurde. In einer bevorzugten Ausgestaltung befindet sich jede dieser Methoden auf dem Client. Die Typen "String", "boolean" und "Date" sind hinlänglich bekannte Java-Datentypen. Der AlarmRecordld-Typ ist ein opakes Objekt, und EMSeverity ist eine Instanz eines Objekt-aufgezählten Typs, der fünf Werte (critical, major, minor, warning und indeterminate) beinhaltet, EMTopoNodeDn ist ein Objekt, das ein Topologieobjekt eindeutig identifiziert.
Es folgt eine Beschreibung der Funktion der öffentlichen Methoden im AlarmRecord.

– getAckOperator () – Diese Methode gibt einen String zurück, der den Netzwerkadministrator (einen Benutzer) identifiziert, der den Alarm bestätigt hat.
– getAckState () – Diese Methode gibt einen booleschen Wert zurück, der angibt, ob der Alarm bestätigt wurde.
– getACkText () - Diese Methode gibt einen String zurück, der die Meldung des Benutzers in Bezug auf die Bestätigung des Alarms enthält.
– getAckTime () – Diese Methode gibt Datum und Uhrzeit an, wann der Benutzer den Alarm bestätigt hat.
– getClearOperator () – Diese Methode gibt einen String zurück, der den Benutzer identifiziert, der den Alarm beseitigt hat.
– getClearState () – Diese Methode gibt einen booleschen Wert zurück, der angibt, ob der Alarm beseitigt wurde.
– getClearText () – Diese Methode gibt den Text zurück, der von dem Benutzer gespeichert wurde, der den Alarm in Bezug auf das Beseitigen des Alarms beseitigt hat.
– getClearTime () – Diese Methode gibt Datum und Uhrzeit zurück, wann der Benutzer den Alarm beseitigt hat.
– getDisplayOperator () – Diese Methode gibt einen String zurück, der den Benutzer identifiziert, der einen Kommentarstring an den Alarm angehängt hat.
– getDisplayState () – Diese Methode gibt einen booleschen Wert zurück, der angibt, ob ein Benutzer einen Kommentarstring an den Alarm angehängt hat.
– getDisplayText () – Diese Methode gibt den Kommentarstring zurück, der an den Alarm angehängt wurde.
– getDisplayTime () – Diese Methode gibt Datum und Uhrzeit an, wann der Kommentarstring an den Alarm angehängt wurde.
– getEventTime () – Diese Methode gibt Datum und Uhrzeit an, wann das Event aufgetreten ist.
– getEventType () – Diese Methode gibt den Alarmtyp an. Der Alarmtyp gibt den Typ des Alarms an. Der Alarmtyp gibt an, ohne Begrenzung, dass der Alarm mit Internet, Kommunikation, Nervenzentrum, Dienstequalität, wiederholt auftretende Fehler, Geräte oder Umgebung assoziiert ist.
– getLogRecordld () – Diese Methode gibt eine eindeutige AlarmRecordld Kennung für diesen Alarmdatensatz an.
– getLoggingTime () – Diese Methode gibt Datum und Uhrzeit an, wann das Event im MIS tatsächlich protokolliert wurde.
– getManagedObjectlnstance () – Diese Methode gibt einen String an, der der völlig eindeutige Name des Gerätes ist, das den Alarm ausgelöst hat.
– getPerceivedSeverity () - Diese Methode gibt die Ernsthaftigkeit des Events an. Die Ernsthaftigkeitswerte sind in EMSeverity definiert.
– getProbableCause () – Diese Methode gibt einen String zurück, der die mögliche Ursache des Alarms angibt. Die Mögliche-Ursache-Strings sind freiformatierte Texteingaben des Netzwerkadministrators.
– getTopoNodeDns () – Diese Methode gibt eine Anordnung von EMTopoNodeDn zurück, die die eindeutigen Topologiekennungen für die durch diesen Alarm betroffenen Knoten enthält.
– toString () – Diese Methode gibt einen String zurück, der die Textdarstellung des Alarmdatensatzes ist.

Die AlarmLog-Klasse (in Tabelle 2 gezeigt) gibt eine Anzahl von Methoden zum Einholen von Informationen von den Alarmdatensätzen innerhalb des MIS und zum Manipulieren derselben bereit. Im Allgemeinen befindet sich die Lokalität dieser Methoden im Server (Ausnahmen sind angegeben). Diese Methoden werden nachfolgend beschrieben.

– void clearAlarms (AlarmRecordld []) – Diese Methode beseitigt die in der AlarmRecordId-Array vorgegebenen Alarme.
– void deleteAlarms (AlarmRecordld []) – Diese Methode löscht die in der AlarmRecordId-Array vorgegebenen Alarme.
– void acknowledgeAlarms (AlarmRecordld []) – Diese Methode bestätigt die in der AlarmRecordId-Array vorgegebenen Alarme.
– AlarmRecord [] getAlarms (AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die alle Alarme vom MIS enthält. Jeder Alarm enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.

– AlarmRecord [] getAlarms (AlarmRecordld [] alarmRecordlds, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die von der AlarmRecordIds-Array identifizierten Alarmprotokolldatensätze enthält. Jeder Alarmprotokolldatensatz enthält die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarms (EMSeverity severity, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze enthält, die die vorgegebene Ernsthaftigkeit haben. Jeder Alarmprotokolldatensatz enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarms (String deviceFDN, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze für das von dem völlig eindeutigen Namensstring im "deviceFDN" Argument identifizierte Gerät enthält. Jeder Alarmprotokolldatensatz. enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarms (EMTopoNodeDn deviceTopoNodeDn, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze für den vom "deviceTopoNodeDn" Argument identifizierten topologischen Knoten enthält. Jeder Alarmprotokolldatensatz enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarms (String deviceFDN, EMSeverity severity, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze für den vorgegebenen völlig eindeutigen Gerätenamen enthält, der eine vorgegebene Ernsthaftigkeit hat. Jeder Alarmprotokolldatensatz enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarms (EMTopoNodeDn deviceTopoNodeDn, EMSeverity severity, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze für den vorgegebenen topologischen Knoten enthält, der die vorgegebene Ernsthaftigkeit hat. Jeder Alarmprotokolldatensatz enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarmsRecursive (EMTopoNodeDn deviceTopoNodeDn, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze für den vorgegebenen topologischen Knoten und die Alarmprotokolldatensätze enthält, die für topologische Knoten sind, die Abkömmlinge des vorgegebenen topologischen Knotens sind. Jeder Alarmprotokolldatensatz enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.
– AlarmRecord [] getAlarmsRecursive (EMTopoNodeDn deviceTopoNodeDn, EMSeverity severity, AlarmRecordAttributeSet attrs) – Diese Methode gibt eine AlarmRecord-Array zurück, die die Alarmprotokolldatensätze für den vorgegebenen topologischen Knoten und die Alarmprotokolldatensätze enthält, die für topologische Knoten sind, die Abkömmlinge des vorgegebenen topologischen Knotens sind und die die vorgegebene Ernsthaftigkeit haben. Jeder Alarmprotokalldatensatz enthält nur die vom "attrs" Argument vorgegebenen Alarminformationen.

Die folgenden Methoden geben Informationen über die Anzahl von Alarmen im MIS zurück.

– int getAlarmCount (String deviceFDN, EMSeverity severity) – Diese Methode gibt einen ganzzahligen Wert der Anzahl von Alarmen mit der vorgegebenen Ernsthaftigkeit zurück, die von dem vorgegebenen Gerät erzeugt wurden.
– int getAlarmCount (EMTopoNodeDn deviceTopoNodeDn, EMSeverity severity) – Diese Methode gibt einen ganzzahligen Wert der Anzahl der Alarme mit der vorgegebenen Ernsthaftigkeit vom vorgegebenen topologischen Knoten zurück.
– int getAlarmCount (String deviceFDN) – Diese Methode gibt einen ganzzahligen Wert der Anzahl der Alarme von dem vorgegebenen Gerät zurück.
– int getAlarmCount (EMTopoNodeDn deviceTopoNodeDn) – Diese Methode gibt einen ganzzahligen Wert der Anzahl von Alarmen von dem vorgegebenen topologischen Knoten zurück.
– int getAlarmCount (EMSeverity severity) – Diese Methode gibt einen ganzzahligen Wert der Anzahl von Alarmen mit einer vorgegebenen Ernsthaftigkeit zurück.
– int getAlarmCountRecursive (EMTopoNodeDn device TopoNodeDn) – Diese Methode gibt einen ganzzahligen Wert der Zahl der Alarme in Bezug auf eine vorgegebenen topologischen Knoten zurück, einschließlich der topologischen Knoten, die Abkömmlinge des vorgegebenen topologischen Knotens sind.
– int getAlarmCountRecursive (EMTopoNodeDn deviceTopoNodeDn, EMSeverity severity) – Diese Methode gibt einen ganzzahligen Wert der Anzahl der Alarme in Bezug auf einen vorgegebenen topologischen Knoten zurück, einschließlich der topologischen Knoten, die Abkömmlinge des vorgegebenen topologischen Knotens mit der vorgegebenen Ernsthaftigkeit sind.
– int [] getAlarmCountRecursive (EMTopoNodeDn deviceTopoNodeDn, EMSeverity [] severity) – Diese Methode gibt eine Array von ganzzahligen Werten zurück, die jeweils die Anzahl der Alarme in Bezug auf den vorgegebenen topologischen Knoten sind, einschließlich der topologischen Knoten, die Abkömmlinge des vorgegebenen topologischen Knotens mit der durch die Array von vorgegebenen Ernsthaftigkeiten vorgegebenenErnsthaftigkeit sind.

Die folgenden Methoden dienen zum Durchführen verschiedener Funktionen.

– void setDisplayText (AlarmRecordld id, String displayText) – Diese Methode speichert der displayText-String in dem durch id identifizierten Datensatz. So kann ein Operator einen Textkommentar im Alarmdatensatz speichern, so dass er von anderen abgerufen werden kann.
– void addAlarmListener (AlarmLogEventListener listener, AlarmRecordAttributeSet attrs) – Diese Methode registriert eine Methode als Alarmzuhörer mit dem MIS, so dass der MIS Alarmobjekte zur registrierten Methode senden kann. Diese Methode befindet sich beim Client.
– void removeAlarmListener (AlarmLogEventListener listener) – Diese Methode entfernt den zuvor registrierten Alarmzuhörer aus der Liste der registrierten Zuhörer. Diese Methode befindet sich beim Client.

Die AlarmLogEventListener-Klasse (Tabelle 3) bietet Rückrufmethoden, die auf bestimmte Events im MIS reagieren. Tabelle 3

– alarmRecordCreated (AlarmLogEvent event) – Diese Rückrufmethode wird auf einem registrierten Alarmzuhörer aufgerufen, wenn ein neuer Alarmdatensatz im MIS erzeugt wird. Das Event-Argument ist ein Objekt, das Zugang zu dem neu erzeugten Alarmdatensatz bietet.
– alarmRecordDeleted (AlarmLogEvent event) – Diese Rückrufmethode wird auf einem registrierten Alarmzuhörer aufgerufen, wenn ein existierender Alarmdatensatz im MIS gelöscht wird. Das Event-Argument ist ein Objekt, das den gelöschten Alarmdatensatz identifiziert.
– alarmRecordModified (AlarmLogEvent event) – Diese Rückrufmethode wird auf einem registrierten Alarmzuhörer aufgerufen, wenn ein existierender Alarmdatensatz im MIS modifiziert wird. Das Event-Argument ist ein Objekt, das Zugang zum modifizierten Alarmdatensatz bietet.

Die AlarmLogEvent-Klasse (in Tabelle 4 gezeigt) gibt Informationen über MIS-Events. Diese Methode befindet sich beim Client. Tabelle 4

– int getEventType () – Diese Methode gibt einen ganzzahligen Wert zurück, der das zurückgegebene Event dadurch klassifiziert, dass einer der oben definierten Werte zurückgegeben wird (OBJECT_CREATED, OBJECT_DELETED, ATTR_VALUE_CHANGED, STATE_CHANGED, RELATIONSHIP_CHANGED).
– int getAlarmRecord () – Diese Methode gibt den AlarmRecord zurück, der erzeugt oder modifiziert wurde.
– int getAlarmRecordld () – Diese Methode gibt die AlarmRecordld für den AlarmRecord zurück, der erzeugt, gelöscht oder modifiziert wurde.

Aus dem oben Gesagten geht hervor, dass die Erfindung (ohne Begrenzung) die folgenden Vorteile hat:

1. Die Erfindung stellt eine API bereit, die mit einem vernetzten MIS Verbindung hat.
2. Die Erfindung begrenzt die Menge an Daten, die vom Server zum Client gesendet werden, indem der Programmierer Attribute von Interesse vorgeben kann.
3. Die Erfindung sucht rekursive und andere rechen- oder E/A-intensive Operationen am Server und begrenzt so den Verarbeitungseinfluss auf den Client und begrenzt den Datenfluss über den Client/Server-Kommunikationsmechanismus.
4. Die Erfindung stellt eine JAVA API bereit, die auf einen Nicht-JAVA MIS zugreift.

Claims

Computergesteuertes Verfahren, um einer Client-Anwendung (205) Zugang zu einem Managementinformationsdienst MIS (215) zu geben, der von einem Server (203) bereitgestellt wird, wobei der genannte MIS Daten über einen überwachte Zustand in einem Netzwerk (125) enthält, und wobei das genannte Verfahren die folgenden Schritte umfasst: (a) Instanziieren (1203), durch die genannte Client-Anwendung, einer Anwendungsprogrammiererschnittstelle API (207), umfassend ein logisches Objekt, wobei das genannte logische Objekt wenigstens eine programmierte Methode beinhaltet, die entweder auf einem Client-Teil oder einem Server-Teil implementiert wird, so dass die genannte wenigstens eine programmierte Methode, wenn sie ein Betriebsmittel des Client-Teils negativ beeinflusst, auf dem Server-Teil implementiert wird, und Mittel, um den Ort der genannten wenigstens einen programmierten Methode zu ermitteln; (b) Aufrufen wenigstens einer programmierten Methode (1100) des genannten logischen Objekts durch die genannte Client-Anwendung; und (c) Ausführen der genannten programmierten Methode (1209) an dem genannten Server (203), um auf den genannten MIS (215) zuzugreifen.
Computergesteuertes Verfahren nach Anspruch 1, bei dem der genannte überwachte Zustand ein Status eines überwachten Gerätes ist.
Computergesteuertes Verfahren nach Anspruch 1, bei dem der genannte überwachte Zustand ein Status eines topologischen Knotens ist.
Computergesteuertes Verfahren nach Anspruch 1, ferner umfassend: (d) Zurückgeben der genannten Daten (1211) zu der genannten Client-Anwendung (205) nach dem Ausführen des genannten programmierten Verfahrens (1209).
Computergesteuertes Verfahren nach Anspruch 4, bei dem die genannten Daten eine Mehrzahl von Attributen umfassen, und wobei Schritt (d) ferner die folgenden Schritte umfasst: (d1) Vorgeben eines Attributs (1205) der genannten Daten, das von Interesse ist; und (d2) Zurückgeben des genannten Attributs von Interesse (1211) zu der genannten Client-Anwendung nach dem Ausführen des genannten wenigstens einen programmierten Verfahrens.
Computergesteuertes Verfahren nach Anspruch 4, das ferner Folgendes umfasst: (e) Präsentieren der genannten Daten einem Benutzer der genannten Client- Anwendung (205).
Computergesteuertes Verfahren nach Anspruch 1, bei dem Schritt (c) ferner das rekursive Ausführen der genannten programmierten Methode auf einem Tochterknoten eines vorgegebenen topologischen Knotens umfasst.
Vorrichtung mit einer Zentraleinheit CPU (103) und einem mit der genannten CPU verbundenen Speicher (105), um einer Client-Anwendung (205) Zugang zu einem von einem Server (203) bereitgestellten Managementinformationsciienst MIS (215) zu geben, wobei der genannte MIS Daten über einen überwachten Zustand in einem Netzwerk (125) beinhaltet, wobei die genannte Vorrichtung Folgendes umfasst: einen Instanzüerungsmechanismus (1203), der so konfiguriert ist, dass er als Reaktion auf die genannte Client-Anwendung eine Anwendungsprogrammiererschnittstelle API (207) instanziiert, umfassend ein logisches Objekt, wobei das genannte logische Objekt wenigstens eine programmierte Methode beinhaltet, die auf einem Server-Teil des logischen Objektes oder einem Client-Teil implementiert wird, so dass die genannte wenigstens eine programmierte Methode, wenn sie ein Betriebsmittel des Client-Teils negativ beeinflusst, auf dem Server-Teil implementiert wird, und Mittel, um den Ort der genannten wenigstens einen programmierten Methode zu ermitteln; einen Methodenaufrufmechanismus (1100), der so konfiguriert ist, dass er eine programmierte Methode des genannten logischen Objekts durch die genannte Client-Anwendung aufruft; oral einen Ausführungsmechanismus (1209), der so konfiguriert ist, dass er die genannte programmierte Methode an dem genannten Server zum Zugreifen auf den genannten MIS ausführt.
Vorrichtung nach Anspruch 8, bei der der genannte überwachte Zustand ein Status eines überwachten Gerätes ist.
Vorrichtung nach Anspruch 8, bei der der genannte überwachte Zustand ein Status eines topologischen Knotens ist.
Vorrichtung nach Anspruch 8, die ferner Folgendes umfasst: einen Datenrückgabemechanismus (1211), der so konfiguriert ist, dass er die genannten Daten der genannten Client-Anwendung (205) nach dem Ausführen der genannten programmierten Methode (1209) an dem genannten Server (203) zurückgibt.
Vorrichtung nach Anspruch 11, bei der die genannten Daten eine Mehrzahl von Attributen umfassen, und wobei Schritt (d) ferner die folgenden Schritte umfasst: einen Attributspezifikationsmechanismus (1205), der so konfiguriert ist, dass er ein Attribut der genannten Daten vorgibt, das von Interesse ist; und einen Attributrückgabemechanismus (1211), der so kosfiguriert ist, dass er der genannten Client-Anwendung (205) das genannte Attribut von Interesse nach dem Ausführen der genannten wenigstens einen programmierten Methode (1209) zurückgibt.
Vorrichtung nach Anspruch 8, wobei der Ausführungsmechanismus (1209) ferner einen rekursiven Mechanismus umfasst, der so konfiguriert ist, dass er die genannte wenigstens eine programmiere Methode an einem Tochterknoten eines vorgegebenen topologischen Knotens rekursiv ausführt.
Vorrichtung nach Anspruch 11, die ferner Folgendes umfasst: einen Datenpräsentationsmechanismus, der so konfiguriert ist, dass er die genannten Daten einem Benutzer der genannten Client-Anwendung präsentiert.
Computerprogrammprodukt, das Folgendes umfasst: ein von einem Computer verwendbares Speichermedium (115) mit einem darin eingebetteten rechnerlesbaren Code, um einen Computer zu veranlassen, einer Client-Anwendung (205) Zugang zu einem Managementinformationsdienst MIS (215) zu geben, der von einem Server (203) bereitgestellt wird, wobei der genannte MIS Daten über einen überwachten Zustand in einem Netzwerk (125) beinhaltet, wobei der genannte rechnerlesbare Code Folgendes umfasst: rechnerlesbaren Programmcode, der so konfiguriert ist, dass er den genannten. Computer veranlasst, einen Instanzüerungsmechanismus (1203) zu aktivieren, der so konfiguriert ist, dass er als Reaktion auf die genannte Client-Anwendung eine Anwendungsprogrammiererschnittstelle API (207) instanziier, umfassend ein logisches Objekt, wobei das genannte logische Objekt wenigstens eine programmierte Methode beinhaltet, die auf einem Server-Teil des logischen Objekts oder einem Client-Teil implementiert wird, so dass dann, wenn die genannte wenigstens eine programmierte Methode ein Betriebsmittel des Client-Teils negativ beeinflusst, diese auf dem Server-Teil implementiert wird, und Mittel, um den Ort der genannten wenigstens einen programmierten Methode zu ermitteln; rechnerlesbaren Programmcode, der so konfigurier ist, dass er den genannten Computer veranlasst, einen Methodenaufrufmechanismus (1100) zu aktivieren, der so konfiguriert ist, dass er die genannte wenigstens eine programmierte Methode des genannten logischen Objekts durch die genannte Client-Anwendung aufruft; und rechnerlesbaren Programmcode, der so konfiguriert ist, dass er den genannten Computer veranlasst, einen Ausführungsmechanismus (1209) zu aktivieren, der so konfiguriert ist, dass er die genannte wenigstens eine programmierte Methode an dem genannten Server ausführt, um auf den genannten MIS zuzugreifen.
Computerprogrammprodukt nach Anspruch 15, wobei der genannte überwachte Zustand ein Status eines überwachten Gerätes ist.
Computerprogrammprodukt nach Anspruch 15, bei dem der genannte überwachte Zustand ein Status eines topologischen Knotens ist.
Computerprogrammprodukt nach Anspruch 15, 16 oder 17, das ferner Folgendes umfasst: rechnerlesbaren Programmcode, der so konfiguriert ist, dass er den genannten Computer veranlasst, einen Datenrückgabemechanismus (1211) zu aktivieren, der so konfiguriert ist, dass er der genannten Client-Anwendung (205) die genannten Daten nach dem Ausführen der genannten wenigstens einen programmierten Methode (1209) an dem genannten Server (203) zurückgibt.
Computerprogrammprodukt nach Anspruch 18, wobei die genannten Daten eine Mehrzahl von Attributen umfassen, und wobei Schritt (d) ferner die folgenden Schritte umfasst: rechnerlesbaren Programmcode, der so konfiguriert ist, dass er den genannten Computer veranlasst, einen Attributspezifikationsmechanismus (1205) zu aktiviren, der so konfiguriert ist, dass er ein Attribut von Interesse als die genannten Daten vorgibt; und rechnerlesbaren Programmcode, der so konfiguriert ist, dass er den genannten Computer veranlasst, einen Attributrückgabemechanismus (1211) zu aktivieren, der so konfiguriert ist, dass er der genannten Client-Anwendung (205) das genannte Attribut von Interesse nach dem Ausführen der genannten wenigstens einen programmierten Methode zurückgibt.
Computerprogrammprodukt nach Anspruch 18 oder 19, das ferner Folgendes umfasst: rechnerlesbaren Programmcode, der so konfiguriert ist, dass er den genannten Computer veranlasst, einen Datenpräsentationsmechanismus zu aktivieren, der so konfiguriert ist, dass er die genannten Daten einem Benutzer der genannten Client-Anwendung präsentiert.
Computergesteuertes Verfahren nach einem der Ansprüche 15 bis 20, bei dem der Ausführungsmechanismus ferner rechnerlesbaren Programmcode umfasst, der so konfiguriert ist, dass er den genannten Computer veranlasst, einen rekursiven Mechanismus zu aktivieren, der so konfiguriert ist, dass er die genannte programmierte Methode an einem Tochterknoten eines vorgegebenen topologischen Knotens rekursiv ausführt.