-
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 SolsticeTM Enterprise
ManagerTM 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 SolsticeTM Enterprise
ManagerTM 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 ManagerTM 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 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.
Tabelle
2
- – 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.