-
Diese
Erfindung bezieht sich auf ein System und Verfahren zum Laden eines
dynamischen Modells und insbesondere auf ein System und Verfahren zum
dynamischen Laden von Daten über
ein Dienstesystem in ein Dienstemodell in einem Dienste-Verwaltungssystem.
-
Hintergrund
der Erfindung
-
Dienste-Verwaltungssysteme
liefern Benutzern Daten über
darunter liegende Dienstesysteme. Ein typisches Dienste-Verwaltungssystem
verwendet ein Dienstemodell zum Speichern von Daten über das
Dienstesystem, und grafische Benutzerschnittstellen (GUI's), um die Daten
den Benutzern darzubieten.
-
Viele
GUI's verwenden
das Modell-Ansichts-(Modelview-)Steuerungs-(MVC-)-Muster zur Realisierung.
Verteilte GUI's
verwenden in vielen Fällen
das Mehrschicht-MVC-(MMVC-)Muster. Beide Muster erfordern es, dass
das Dienstemodell vollständig
bei der Initialisierung erzeugt und lediglich dann geändert wird,
wenn sich die Daten tatsächlich ändern. Das
Dienstemodell speichert und verwaltet die Daten über das gesamte Dienstesystem.
-
Als
ein Beispiel von Dienste-Verwaltungssystemen sind Netzwerk-Verwaltungssysteme
hinsichtlich ihrer Verwendung von MMVC und MVC zur Erzeugung von
GUI's und ihrer
Verwendung von Netzwerk-Modellen zum Speichern von Daten über darunter
liegende Netzwerke in keiner Weise verschieden.
-
Traditionelle
Netzwerk-Verwaltungssysteme initialisieren das Netzwerk-Modell mit
einer vollständigen
Ansicht des Netzwerkes. Im Hinblick auf die Größe älterer Netzwerke und der CPU/Speicher-Fähigkeiten älterer Computer
in älteren
Netzwerk-Verwaltungssystemen war dies eine erfolgreiche Lösung. Die
Netzwerk-Größe nimmt
jedoch mit einer höheren
Geschwindigkeit zu, als die CPU/Speicher-Fähigkeiten
von Anwendungscomputern. Einige Netzwerke enthalten einige zehntausend
Netzwerk-Elemente und Millionen von Verbindungen zwischen den Netzwerk-Elementen.
Die Lösung,
die das vollständige
Netzwerk-Modell verwendet, ruft schwerwiegende Skalierbarkeits-Beschränkungen
in den Netzwerk-Verwaltungssystemen
hervor. Das Netzwerk-Modell in diesen Netzwerk--Verwaltungssystemen ist zu groß, um zusammen
mit GUI's zu existieren,
die übliche
MVC- und MMVC-Techniken verwenden.
-
Einige
Netzwerk-Verwaltungssysteme haben versucht, das Netzwerk-Modell,
das heißt
ein GUI-Modell, in ihre Server-Schichten zu verschieben. Diese Lösung ruft
jedoch schwerwiegende Betriebsleistungsprobleme für GUI-Zuteilungen
hervor, die dies versuchen.
-
Die
Veröffentlichung
Morgenthal JP („Understanding
Enterprise JAVA API's", Middleware & Infrastructure,
August 1999, Seiten 36–40)
beschreibt Unternehmens-Java-API's, die den Java-Transaktionsdienst
(JTS)/Java-Transaktions-API (JTA), Java Namens- und Verzeichnisdienste
(JNDI) und den Java-Mitteilungsübermittlungsdienst
(JMS) einschließen.
Das US-Patent 5 440 744 beschreibt ein Netzwerk, das Plattformen
aufweist, von denen jede eine Lade-/Entlade-Softwarekomponente hat.
-
Es
ist immer noch erforderlich, ein System zu schaffen, das in der
Lage ist, die vorstehend erwähnten
Skalierbarkeits-Beschränkungen
in Dienste-Verwaltungssystemen zu beseitigen, und das in geeigneter
Weise in einem Netzwerk-Verwaltungssystem verwendet
wird, das ein Netzwerk verwaltet, das eine große Anzahl von Netzwerk-Elementen
umfasst.
-
Zusammenfassung
der Erfindung
-
Die
vorliegende Erfindung, wie sie in den beigefügten Ansprüchen angegeben ist, verwendet
eine Lader-Verwaltung, um ein Dienstemodell zu verwalten, das Daten über ein
Dienstesystem speichert. Die Lader-Verwaltung lädt dynamisch Daten über das Dienstesystem
in das Dienstemodell, wenn diese benötigt werden.
-
Gemäß einem
Gesichtspunkt der vorliegenden Erfindung wird eine Lader-Verwaltung zum Verwalten
eines Dienstemodells geschaffen, das Daten über ein Dienstesystem speichert,
das mehrfache Dienste hat. Die Lader-Verwaltung umfasst einen Empfangs-Port,
einen Aufruf-Port, einen Lade-Operator und eine Modell-Schnittstelle.
Der Empfänger-Port
ist zum Empfang einer Lade-Anforderung zum Laden von Daten in das
Dienstemodell vorgesehen. Der Aufruf-Port ist vorgesehen, um einen
Lader aufzurufen, der in der Lage ist, das Laden der Daten auszuführen. Der
Lader wird an den Aufruf-Port geliefert. Der Lade-Operator dient
zum Aufrufen des Laders. Die Modell-Schnittstelle kommuniziert mit
dem Dienstemodell. Das Laden wird über die Modell-Schnittstelle
ausgeführt.
-
Gemäß einem
weiteren Gesichspunkt der vorliegenden Erfindung wird eine Dienstemodell-Einrichtung
zur Verwaltung eines Dienstemodells geschaffen, das Daten über ein
Dienstesystem speichert. Die Dienstemodell-Einrichtung umfasst eine Lader-Anforderungseinrichtung,
eine Lader-Zuführungseinrichtung
und eine Lader-Verwaltungseinrichtung. Die Lade-Anforderungseinrichtung
ist zum Erzeugen einer Lade-Anforderung zum Laden von Daten in das
Dienstemodell vorgesehen. Die Lader-Zuführungseinrichtung ist zum Bereitstellen
eines Laders vorgesehen, der in der Lage ist, das Laden der Daten
auszuführen.
Die Lader-Verwaltung
ist zum Empfang einer Lade-Anforderung von der Lade-Anforderungseinrichtung
vorgesehen und gibt einen Aufruf zum Aufrufen des Laders von der
Lader-Zuführungseinrichtung
in Abhängigkeit
von der Lader-Anforderung
ab. Die Lader-Verwaltung schließt Folgendes
ein: einen Empfangs-Port
zum Empfangen der Lader-Anforderung von der Lade-Anforderungseinrichtung,
einen Aufruf-Port zur Abgabe eines Aufrufs zum Aufrufen des Laders
als Antwort auf die Lade-Anforderung, wobei der Lader an den aufrufenden
Port von der Lader-Zuführungseinrichtung
geliefert wird, einen Lader-Operator zum Aufrufen des Laders zur
Durchführung
einer Lade-Operation, die dem Lader zugeordnet ist, und eine Modell-Schnittstelle
zur Kommunikation mit dem Dienstemodell. Das Laden wird über die
Modell-Schnittstelle ausgeführt.
-
Gemäß einem
weiteren Gesichspunkt der Erfindung wird ein Verfahren zum Verwalten
eines Dienstemodells geschaffen, das Daten über ein Dienstesystem speichert.
Das Verfahren schließt
die folgenden Schritte ein: an einer Lader-Verwaltung, Empfangen einer Lade-Anforderung
zum Laden von Daten in das Dienstemodell, und an der Lader-Verwaltung,
Aufrufen eines Laders als Antwort auf die Lade-Anforderung. Der
Lader ist in der Lage, das Laden der Daten in das Dienstemodell
auszuführen. Das
Verfahren schließt
den folgenden Schritt ein: an einer Lader-Zuführungseinrichtung, Zuführen, als Antwort
auf den Aufruf, des Laders an die Lader-Verwaltung. Dann wird zugelassen,
dass der Lader das Laden der Daten in das Dienstemodell über eine
Modell-Schnittstelle zur Kommunikation mit dem Dienstemodell ausführt.
-
Andere
Gesichspunkte und Merkmale der vorliegenden Erfindung sind ohne
weiteres für
den Fachmann aus der folgenden ausführlichen Beschreibung von bevorzugten
Ausführungsbeispielen anhand
der beigefügten
Zeichnungen ersichtlich.
-
Kurze Beschreibung
der Zeichnungen
-
Die
Erfindung wird weiter aus der folgenden Beschreibung unter Bezugnahme
auf die Zeichnungen verständlich,
in denen:
-
1 eine
schematische Darstellung ist, die ein Dienste-Verwaltungssystem gemäß einer
Ausführungsform
der vorliegenden Erfindung zeigt;
-
2 eine
schematische Darstellung ist, die ein Beispiel der Lader-Verwaltung zeigt,
die in 1 gezeigt ist;
-
3 eine
schematische Darstellung ist, die Beispiele von Lade-Pfaden oder
Lade-Threads zeigt;
-
4 ein
Diagramm ist, das ein Beispiel einer Registrierung-Operation zeigt;
-
5 eine
schematische Darstellung ist, die ein Beispiel einer Lader-Operation zeigt;
-
6 eine
schematische Darstellung ist, die ein Beispiel einer Beendigungs-Operation
ist;
-
7 eine
schematische Darstellung ist, die ein Netzwerk-Verwaltungssystem
gemäß einer
weiteren Ausführungsform
der vorliegenden Erfindung zeigt.
-
Ausführliche
Beschreibung der bevorzugten Ausführungsbeispiele
-
In
einem Dienste-Verwaltungssystem ergibt die vorliegende Erfindung
eine Lader-Verwaltung zum
Verwalten eines Dienstemodells, das Daten über ein unterlagertes Dienstesystem
speichert. Die Lader-Verwaltung stellt dynamische Modell-Ladefähigkeiten
bereit, um dynamisch einen bestimmten Abschnitt der Daten über das
Dienstesystem in das Dienstemodell zu laden, wenn dieser erforderlich
ist. Das dynamische Laden des Modells ergibt eine Skalierbarkeit
und Flexibilität
im Rahmenwerk des Dienste-Verwaltungssystems.
-
Das
dynamische Laden des Modells ist vollständig unabhängig davon, was geladen wird,
und wie es geladen wird. Entsprechend ergibt die vorliegende Erfindung
eine generische Lösung,
die in einer Anzahl von Anwendungsräumen in dem Gebiet der Dienste-Verwaltung
verwendet werden kann. Beispielsweise ist das dynamische Laden des
Modells von erheblichem Wert bei der Schaffung von Netzwerk-Verwaltungs-systemen,
die die Skalierbarkeit von Netzwerken unterstützen können, die eine große Anzahl
von Netzwerk-Elementen haben.
-
Die
geladenen Abschnitte der Daten über das
Dienstesystem werden vorzugsweise entladen, wenn sie nicht mehr
länger
erforderlich sind, wie sie durch verschiedene Pufferspeicherungs-Strategien in
den Dienste-Verwaltungssystemen bestimmt sein können. Dies trägt weiter
zu der Skalierbarkeit der Dienste-Verwaltungssysteme bei.
-
Unter
Bezugnahme auf 1 wird eine Lader-Einrichtung
gemäß einer
Ausführungsform
der vorliegenden Erfindung beschrieben.
-
Die
Lader-Einrichtung 10 wird in einem Dienste-Verwaltungssystem 2 bereitgestellt,
das ein Dienstesystem 4 verwaltet, das eine Vielzahl von Diensten 5 umfasst.
Das Dienste-Verwaltungssystem 2 hat eine oder mehrere Benutzer-Schnittstellen 6, um
Daten über
das Dienstesystem 4 an Benutzer zu liefern. Die Benutzer-Schnittstellen sind
typischerweise GUI's,
die MVC oder MMVC verwenden.
-
Das
Dienste-Verwaltungssystem 2 weist weiterhin ein Dienstemodell 8 zum
Speichern von Daten über
das Dienstesystem 4 auf. Das Dienste-Verwaltungssystem 2 kann
weiterhin ein oder mehrere Daten-Sammeleinheiten 12 zum
Sammeln von Informationen von dem Dienstesystem 4 aufweisen.
-
Die
Lader-Einrichtung 10 ist vorgesehen, um das Dienstemodell 8 zu
verwalten. Es steuert dynamisch das Laden von Daten über das
Dienstesystem 4 in das Dienstemodell 8.
-
Das
Lader-Einrichtung 10 umfasst ein oder mehrere Lade-Anforderungs-einrichtungen 20,
eine oder mehrere Lader-Zuführungseinrichtungen 30 und
eine Lader-Verwaltung 40.
-
Die
Lade-Anforderungseinrichtungen 20 erzeugen Lade-Anforderungen 22 zum
Laden von Daten über
das Dienstesystem 4 in das Dienstemodell 8. Jede
Lade-Anforderungseinrichtung 20 ist
eine Einheit, die weiß,
wann sie es wünscht,
dass bestimmte Daten über
das Dienstesystem 4 in das Dienstemodell 8 geladen
werden, weiß jedoch
nicht, wie sie zu laden sind.
-
Die
Lader-Zuführungseinrichtungen 30 liefern
Lader 32. Ein Lader 22 ist eine Software-Einheit, die
in der Lage ist, das Laden bestimmter Daten über das Dienstesystem 4 in
das Dienstemodell 8 durchzuführen, wenn sie aufgerufen wird.
Lader 32 werden benötigt,
wenn das Dienste-Verwaltungssystem 2 nicht Daten über das
gesamte Dienstesystem 4 in dem Dienstemodell 8 zu
allen Zeiten halten kann.
-
Ein
Lader-Zuführungselement 30 ist
eine Einheit, die weiß,
wie erforderliche Daten über
das Dienstesystem 4 in das Dienstemodell 8 zu
laden sind, weiß jedoch
nicht, wann diese in das Dienstemodell 8 zu laden sind.
-
Die
Lader-Verwaltung 40 verwaltet die Lader 32 und
stellt die Möglichkeiten
zum dynamischen Laden erforderlicher Daten über das Dienstesystem 4 in das
Netzwerk-Modell 8 bereit. Die Lader-Verwaltung 40 ermöglicht es
den Lade-Anforderungselementen 20 und
den Lader-Zuführungselementen 30,
miteinander in Wechselwirkung zu treten, ohne dass jedes Element
Kenntnis von dem anderen hat.
-
Die
Lader-Verwaltung 40 empfängt über ihren Empfangs-Port Lade-Anforderungen 22,
die von Lade-Anforderungselementen 20 erzeugt werden. Als
Antwort auf die Lade-Anforderungen 22 gibt sie über ihren
Aufruf-Port an die Lader- Zuführungselemente 30 Aufrufe 42 ab,
die Lader 32 aufrufen, die den Lade-Anforderungen 22 entsprechen.
Dann liefern die Lader-Zuführungselemente 30 die
Lader 32 an die Lader-Verwaltung 40, die das Laden
der erforderlichen Daten über
das Dienstesystem 4 in das Dienstemodell 8 unter
Verwendung der zugeführten Lader 22 ausführt.
-
Jeder
Lader 32 wird vorzugsweise durch einen Lader-Typ und einen
Lader-Kontext identifiziert. Der Lader-Typ kann durch eine Zeichenfolge
definiert sein. Sie identifiziert, welche Art von Daten zu laden ist.
Er identifiziert eine Gruppe von Ladern, die zusammen einen Gesichtspunkt
des Dienstesystems 4 in das Dienstemodell 8 laden.
Der Lader-Kontext kann als ein Objekt definiert werden. Er identifiziert, welche
Daten zu laden sind.
-
Beispielsweise
können
in dem Dienstesystem 4 die Dienste in hierarchische Gruppen
unterteilt sein. Jede hierarchische Gruppe wird als ein „Layout" bezeichnet. Die
Lader 32 können
zum Laden der Layouts und Gruppen von Diensten in dem Dienstesystem
definiert werden. Für
Layout-Lader ist der Lader-Typ „Layout" und der Lader-Kontext
enthält
den Namen des zu ladenden Layouts. Für Gruppen-Lader ist der Lader-Typ „Gruppe" und der Lader-Kontext
enthält
die Identifikation der Gruppe, die zu laden oder zu öffnen ist.
-
Jedes
Lade-Anforderungselement 20 identifiziert vorzugsweise
jede Lade-Anforderung 22 durch einen
Lader-Typ und einen Lader-Kontext. Als Antwort auf die Lade-Anforderung 22 ruft
die Lader-Verwaltung 40 die erforderliche Lade-Operation an den speziellen
Lader-Typ und -Kontext durch Aufrufen eines Laders 22 auf,
der durch den Lader-Typ und -Kontext identifiziert ist.
-
Lader
hängen
in vielen Fällen
voneinander ab. Es wird bevorzugt, dass Lader außerdem eine Lader-Priorität einschließen. Die
Lader-Verwaltung 40 ruft Lader in der Reihenfolge auf,
die durch die Priorität
dargestellt ist. Lader mit der gleichen Priorität können zur gleichen Zeit ablaufen.
Lader mit einer niedrigeren Priorität, beispielsweise der Priorität 1, laufen
vor Ladern mit einer höheren
Prioritätsnummer,
beispielsweise der Priorität 5,
ab.
-
Das
Laden erfordert üblicherweise
eine lange Zeit. Als Ergebnis kann die Lader-Verwaltung 40 den Ladern 32 die
Option eines Wartens bis zum Ende des Ladens oder einer sofortigen
Rückkehr
auf den aktiven Zustand geben.
-
Die
erstere Option wird als „blockierendes" Laden bezeichnet,
während
die letztere Option als „entblockierendes" Laden bezeichnet
wird.
-
Die
Lade-Anforderungselemente 20 können weiterhin das Entladen
von Daten über
das Dienstesystem 4 aus dem Dienstemodell 8 anfordern.
Das Entladen von Daten kann angefordert werden, um sie an die betreffenden
Benutzer-Schnittstellen 6 zu liefern, damit sie den Benutzern
dargeboten werden, oder um Daten zu entfernen, die in dem Dienstemodell
nicht mehr benötigt
werden.
-
Die
Lader-Einrichtung 10 verwaltet außerdem das Entladen von Daten
aus dem Dienstemodell 8. Das Entladen von Daten ist ähnlich zum
Laden. Die Lade-Anforderungselemente 20 erzeugen
Entlade-Anforderungen zum Entladen bestimmter Daten über das
Dienstesystem 4. Als Antwort auf die Entlade-Anforderungen ruft
die Lader-Verwaltung 40 Entlade-Elemente von den Zuführungselementen 30 auf.
Ein Entlader-Element ist eine Software-Einheit, die in der Lage
ist, die erforderlichen Daten über
das Dienstesystem 4 aus dem Dienstemodell 8 zu
entladen oder zu entfernen.
-
Jedes
Entlade-Element wird vorzugsweise durch einen Lader-Typ und einen
Lader-Kontext identifiziert
und zeigt so eine Priorität
an, wie dies vorstehend für
Lader beschrieben wurde. Entlader werden in der entgegengesetzten
Reihenfolge zu den Ladern zum Ablaufen gebracht. Das heißt, dass Entlader
mit einer niedrigeren Prioritätsnummer,
beispielsweise der Priorität 1,
nach Entladern mit einer höheren
Prioritätsnummer,
beispielsweise der Priorität 5,
ablaufen.
-
Das
Entladen benötigt üblicherweise
eine kurze Zeit. Als Ergebnis blockiert die Entlade-Operation das
Lade-Anforderungselement, bis das Entladen beendet ist.
-
Lade-Anforderungselemente
haben vorzugsweise Kenntnis darüber,
dass Lade-Aufrufe
auf einen bestimmten Kontext bezugsgezählt sind. Das heißt, dass
jeder Lade-Aufruf an einen Entlade-Anruf angepasst ist. Beispielsweise
wird eine Lade- Anforderung
an der „Gruppe" 4 durchgeführt („Gruppe
ist der Typ und 4 ist der Kontext). Die Lade-Verwaltung 40 führt das
Laden aus. Es wird eine weitere Lade-Gruppe-4-Anforderung gemacht. Diesmal
tut die Lade-Verwaltung 40 nichts, weil dieser Teil des Dienstemodells 8 bereits
durch die erste Ladeanforderung geladen wurde. Bei der ersten Entlade-Gruppe-4-Anforderung
passiert nichts, weil die Lader-Verwaltung 40 weiß, dass
ein Laden aufgrund der zweiten Lade-Anforderung aussteht. Bei der
zweiten Gruppe-4-Entlade-Anforderung wird das Entladen tatsächlich ausgeführt. Dies
wird als Bezugzählung bezeichnet.
-
Die
Lader-Verwaltung 40 wickelt vorzugsweise die folgenden
Komplexitäten
des Ladens und Entladens ab.
-
Die
Lader-Verwaltung 40 führt
ein gleichzeitiges Laden und Entladen aus, das nicht in Konflikt steht.
Sie organisiert weiterhin das Laden und Entladen, das in Konflikt
steht. Sie wickelt mehrfache Lade-Anforderungen für den gleichen
Teil des Dienstemodells 8 ab.
-
Beispielsweise
führt,
wenn mehrfache Lade- und Entlade-Aufrufe für einen bestimmten Kontext ausstehen,
das heißt,
dass das Laden und Entladen mehr als einmal für den bestimmten Kontext angefordert
wird, die Lader-Verwaltung 40 vorzugsweise das tatsächliche
Laden auf den ersten Lade-Aufruf hin aus und führt das tatsächliche
Entladen auf den letzten Entlade-Aufruf hin aus. Nachfolgende Lade-Aufrufe
und vorhergehende Entlade-Aufrufe werden nicht ausgeführt.
-
Die
Lader-Verwaltung 40 kann auch eine Pufferspeicherung abwickeln.
Das heißt,
dass sobald das letzte Entlade-Ladeanforderungselement entladen
wird, die Lader-Verwaltung 40 auf
irgendeine Bedingung warten kann, bevor die Entlade-Elemente aufgerufen
werden.
-
2 zeigt
ein Beispiel der Lader-Verwaltung 40. Die Lader-Verwaltung 40 umfasst
eine Lader-Verwaltungs-Steuerung 41, die einen Lade-Operator 44 und
einen Entlade-Operator 45 einschließt.
-
Der
Lade-Operator 44 führt
die Lade-Operationen aus, und die Entlade-Funktion 46 führt die
Entlade-Operationen aus, wie dies vorstehend beschrieben wurde.
-
Die
Lader-Verwaltung 40 weist weiterhin eine Modell-Schnittstelle 48 zur
Kommunikation mit dem Dienstemodell 2 auf. Das Laden und
Entladen von Daten über
das Dienstesystem 4 wird über die Modell-Schnittstelle 48 unter
Verwendung der aufgerufenen Lader und Entlader ausgeführt.
-
Die
Lader-Verwaltungs-Steuerung 41 kann weiterhin einen Registrierungs-Operator 50,
einen Deregistrierungs-Operator 52 und ein Lader/Entlader-Register 54 haben.
-
Über den
Registrierungs-Operator 50 können die Lade-Zuführungselemente 30 ihre
verfügbaren
Lader und Entlader in dem Lader/Entlader-Register 54 registrieren
oder anmelden. Lader und Entlader werden registriert, um den Typ
des Ladens oder Entladens anzuzeigen, die sie unterstützt, sowie
die Lader oder Entlader selbst. Für die Zwecke der Ordnung der
Lader und das gleichzeitige Laden können die Lader-Zuführungselemente 30 weiterhin
anzeigen, wann ihre Lader oder Entlader ablaufen sollten.
-
Unter
Verwendung des Lader/Entlader-Registers 54 kann, wenn der
Lade-Operator 44 eine Lade-Anforderung oder eine Entlade-Anforderung
empfängt,
die Lader-Verwaltung 40 einen
geeigneten Lader oder Entlader aus dem Register 54 gewinnen.
-
Lader
und Entlader können
in den Lader-Zuführungselementen 30 gespeichert
werden, und die Lader-Verwaltung kann in dem Register 54 ein
Lader-Zuführungselement 30 finden,
das einen geeigneten Lader oder Entlader für das angeforderte Laden oder
Entladen bereitstellt, und sie kann den Lader oder Entlader von
dem Lader-Zuführungselement 30 aufrufen.
Die Registrierung von Ladern und Entladern kann auf den Lader-Typen
und Lader-Kontexten beruhen.
-
Der
Deregistrierungs- oder Abmelde-Operator 52 ermöglicht das
Deregistrieren oder Abmelden eines Laders oder Entladers, der nicht
mehr länger von
irgendeinem Lader-Zuführungselement 30 unterstützt wird.
-
Das
Lader/Entlader-Register 54 kann eine Hash-Tabelle 54 sein.
Die Lader-Verwaltungs-Steuerung 41 kann
weiterhin einen Beendigungs-Operator 56 haben.
-
Der
Beendigungs-Operator 56 ermöglicht es den Lade-Anforderungselementen 20,
eine Lade-Operation zu beenden. Wenn eine Beendigungs-Anforderung
empfangen wird, gibt der Beendigungs-Operator 56 einen
Beendigungs-Aufruf ab. Der Beendigungs-Aufruf identifiziert den
Kontext des Ladens, das zu beenden ist. Einzelne Lader können nicht
gestoppt werden, doch verhindert der Beendigungs-Aufruf, dass irgendwelche nachfolgenden
Lader starten. Der Beendigungs-Aufruf blockiert andere Operationen,
bis die Beendigung abgeschlossen ist. Wenn es ausstehende mehrfache
Lade- und Beendigungs-Aufforderungen gibt, stoppt ein Beendigungs-Aufruf
das derzeit ablaufende Laden hinsichtlich des Kontextes oder das
nächste
Laden hinsichtlich des Kontextes, wenn derzeit keiner läuft. Wenn der
Kontext bereits geladen ist oder es keine Lade-Anforderungen vor
der Beendigungs-Anforderung gibt, so hat die Beendigung Wirksamkeit.
-
Die
Lader-Verwaltung 40 kann weiterhin eine Lader-Informationssteuerung 70,
eine Lade-Status-Steuerung 80 und eine Ausnahme-Abwicklung 90 haben.
-
Die
Lader-Informations-Steuerung 70 steuert die Verwendung
von Ladern durch die Lader-Verwaltung 40. Sie ergibt einen
Zugriff auf Ladertyp-spezifische Strukturen.
-
Die
Ladestatus-Steuerung 80 ergibt eine Status- und Lader-Steuerung
auf der Grundlage pro aktivem Kontext. Ein aktiver Kontext ist ein
Kontext, der lädt,
geladen ist oder entladen wird, oder ein entladener Kontext, für den Anforderungen
anhängig sind.
Die Ladestatus-Steuerung 80 wickelt die grundlegende Status-,
Pfadsteuerungs-, Beendigungs- und Bezugszählung ab, das heißt wie viele
Lade-Anforderungen
für einen
bestimmten Kontext aktiv sind. Sie kann weiterhin eine Pfad-Gruppe
und die Ausgestaltung der Pufferspeicherung betreiben, das heißt ein verzögertes Entladen.
Die Ladestatus-Steuerung 80 kann einen FIFO-Mutex 82 haben.
Der FIFO-Mutex 82 verhindert Kollisionen zwischen Lade-
und Entladevorgängen
und hält
Lade- und Entlade-Anforderungen in der Reihenfolge.
-
In
der Lader-Verwaltung 40 gibt es eine Lader-Verwaltungs-Steuerung 41.
Es können
jedoch mehrere Status-Steuerungs-Objekte in der Lade-Status-Steuerung 80 vorhanden
sein, eines pro aktivem Kontext.
-
Die
Ausnahme-Abwicklung 90 ermöglicht es Ladern und Entladern,
den Status und Probleme an die Lader-Verwaltung 40 zu berichten.
Die Lader-Verwaltung 40 ist dann dafür verantwortlich, den Benutzer über die
betreffende Benutzer-Schnittstelle 6 (1)
zu informieren. Die Ausnahme-Abwicklung 90 informiert die
Lader-Verwaltung 40, ob sie weitermachen soll, welche Mitteilung
für den
Benutzer angezeigt werden soll, und welche Ausnahme bewirkte, dass
der Lader fehlschlug. Die Mitteilung und die Ausnahme sind optional,
doch ist es vorzuziehen, eine vorzusehen, so dass die Information
dem Benutzer dargeboten werden kann. Die Ausnahme-Abwicklung 90 konstruiert
eine Lader-Ausnahme unter Verwendung eines Status-Code und einer
Benutzer-Mitteilung.
-
Jedes
Lader-Zuführungselement 30 ist
mit einer Lader-Schnittstelle 100 versehen, um einen Lader
und einen Entlader zu schaffen. Die Lader-Schnittstelle 100 hat
eine Lade-Methode 102 und eine Entlade-Methode 104.
-
Die
Lade-Methode 102 der Lade-Schnittstelle 100 wird
von der Lader-Verwaltung 40 aufgerufen, wenn es Zeit ist,
dass der Lader abläuft.
Der Lader wird in seinem eigenen Pfad aufgerufen. Ein blockierender
Lader kehrt nicht zurück,
bevor nicht sein Laden abgeschlossen ist, wie dies weiter oben beschrieben
wurde. Sobald ein Lader zurückkehrt,
kann der nächste
Lader ablaufen.
-
Die
Entlade-Methode 104 der Lader-Schnittstelle 100 wird
von der Lader-Verwaltung 40 aufgerufen,
wenn es Zeit ist, dass der Entlader abläuft. Der Entlader wird in seinem
eigenen Pfad aufgerufen. Wenn ein Entlader zeitraubende Aufgaben
ausführen muss,
so kann ein derartiger Entlader in einem anderen Pfad ausgeführt werden.
Entlader können
bei bereits aus dem Dienstemodell 8 entfernten Daten aufgerufen
werden, das heißt
ein Entlader ist für
den Fall vorbereitet, in dem die Daten, die er entladen soll, bereits
aus dem Dienstemodell 8 entfernt wurden.
-
In
dieser Ausführungsform
organisiert die Lader-Verwaltung 40 Daten unter Verwendung
von drei Hauptstrukturen, nämlich
anhand des Lader-Typs, anhand des Lader-Kontextes und anhand der
Priorität.
Für diesen
Zweck hat die Lader-Verwaltung 40 eine
erste Hash-Tabelle 54, eine zweite Hash-Tabelle 52 und
eine geordnete Abbildung 74.
-
Die
Organisation von Daten hinsichtlich des Lader-Typs gilt für Lader
und Entlader und aktive Kontexte. Die Lader und Entlader werden
in der ersten Hash-Tabelle 54 registriert. Die Hash-Tabelle 54 bildet
Lader-Typen auf die Lader-Informations-Steuerung 70 unter Verwendung
der Lader-Typen als Schlüssel
und der Lader-Information
als Werte ab.
-
Das
Organisieren von Daten anhand des Lader-Kontextes gilt lediglich
für den
aktiven Lader-Kontext. Die Lader-Informations-Steuerung 70 registriert
die aktiven Lader 71 in der zweiten Hash-Tabelle 52.
Die zweite Hash-Tabelle 52 setzt aktive Lader-Kontexte
auf die Ladestatus-Steuerung 80 unter Verwendung der Lader-Kontexte als Schlüssel und
des Lader-Status als Werte um.
-
Die
Organisation von Daten anhand der Priorität gilt lediglich für Lader
und Entlader. Die Lader-Informations-Steuerung 70 registriert
geordnete Lader und Entlader 70 in der geordneten Abbildung 74.
Die geordnete Abbildung 40 hält Instanzen der Lader-Schnittstelle 100 in
der Reihenfolge.
-
Es
ist vorzuziehen, dass die Lader-Verwaltung 40 eine Pfadbildung
von Lade- oder Entlade-Operationen verwendet. Die Pfadbildung zeigt eine
Lade- oder Entladeoperation an, die zu einer Zeit auf einem bestimmten
Kontext abläuft.
Die Pfadbildung vermeidet das doppelte Laden oder Entladen hinsichtlich
des gleichen Kontextes oder das gleichzeitige Laden und Entladen
hinsichtlich des gleichen Kontextes. Lader und Entlader können gleichzeitig auf
unterschiedlichen Kontexten ablaufen. Es ist die Verantwortung der
Lader, irgendwelche Pfadbildung-Fragen in dieser Situation abzuwickeln.
Um das Laden und Entladen eines Kontextes zu steuern, verwendet
die Pfadbildung Lader-Kontexte als Hash-Tabellen-Schlüsse. Die
Pfadbildung verlässt sich
auf gute Hash-Codes, die unterschiedliche Kontexte nicht als gleich
anzeigen.
-
3 zeigt
Beispiele von Lade-Pfaden. Ein Pfad 24 stellt ein Beispiel
für ein
blockierendes Laden dar. Die Pfade 26 und 28 stellen
Beispiele eines nicht blockierenden Ladens dar. Für ein nicht
blockierendes Laden wird ein zusätzlicher
Pfad 28 verwendet. 3 zeigt
weiterhin einen Pfad 34 zur Registrierung oder Deregistrierung.
-
Die
Steuerung der Pfade in 3 erfolgt an zwei Ebenen. Auf
der Lader-Verwaltungsebene
wird die Pfad-Steuerung durch Synchronisieren mit dem Lader-Verwaltungsobjekt
durchgeführt.
Das heißt, dass
die Pfad-Steuerung sicherstellt, dass lediglich ein Laden, Entladen,
Beendigen, Registrieren oder Deregistrieren zu irgendeiner Zeit
erfolgt.
-
Auf
der zweiten Ebene wird jedesmal dann, wenn die Steuerung von der
Lader-Verwaltungs-Steuerung 41 auf
die Ladestatus-Steuerung 80 für Kontext-spezifische Arbeit
abgegeben wird, die Lader-Verwaltungs-Steuerung 41 freigegeben,
und der Pfad wird durch den FIFO-Mutex 82 gesteuert, der
in der Ladestatus-Steuerung 80 enthalten ist. Wenn beispielsweise
zwei Lade-Anforderungen zur gleichen Zeit für unterschiedliche Kontexte
auftreten, so läuft
eine Lade-Anforderung vor der anderen ab, während sie sich in der Lade-Verwaltungs-Steuerung 41 befindet.
Sobald jedoch die zwei Lade-Anforderungen in getrennte Ladestatus-Steuerungs-Objekte eintreten,
werden sie durch unterschiedliche FIFO-Mutexe 82 gesteuert
und laufen gleichzeitig ab. Wenn die zwei Lade-Anforderungen auf
den gleichen Kontext auftreten, so werden sie in einer Reihe angeordnet
und laufen sequenziell durch den FIFO-Mutex 82 in dem gleichen
Ladestatus-Steuerungsobjekt ab.
-
4 zeigt
ein Beispiel der Registrierungs-Operation. Ein Lader-Zuführungselement 30 sendet
eine Registrierungs-Anforderung an die Lader-Verwaltungs-Steuerung 41 zum
Registrieren seines Laders in der geordneten Abbildung 72 (120). Die
Registrierungs-Anforderung zeigt den Lader-Typ, die Priorität und die
Lader-Schnittstelle an. Die Lader-Verwaltungs-Steuerung 41 erhält das anwendbare
Lader-Informationsobjekt aus der Hash-Tabelle 54 (122).
Sie erhält
weiterhin die geordnete Abbildung von der Lader-Informations-Steuerung 70 (124). Dann
fügt die
Lader-Verwaltungs-Steuerung 41 die Lader-Schnittstelle
zu der geordneten Abbildung 52 unter Verwendung der Priorität hinzu
(126).
-
5 zeigt
ein Beispiel der Lade-Operation. Ein Lader-Anforderungselement 20 ruft
ein Laden durch Senden einer Ladeanforderung an die Lader-Verwaltungs-Steuerung 41 auf
(130). Die Lader-Anforderung zeigt eine Zeichenfolge (den
Lader-Typ), das
Objekt (den Lader-Kontext) und einen Bool'schen Wert (blockierend oder nicht blockierend) an.
Die Lader-Verwaltungs-Steuerung 41 erhält die Lader- Information aus der
Hash-Tabelle 54 (132). Sie erhält weiterhin die aktive Lade-Hash-Tabelle 72 aus der
Lader-Informations-Steuerung 70 (134). Sie erhält außerdem das
Lade-Status-Steuerungsobjekt aus der Hash-Tabelle 72 unter
Verwendung des Kontextes (136). In diesem Beispiel ist
der Kontext nicht aktiv, beispielsweise entladen, ohne anhängige Anforderungen.
Es gibt kein Ladestatus-Steuerungsobjekt.
Somit erzeugt die Lader-Verwaltungs-Steuerung 41 dieses
Objekt in der Ladestatus-Steuerung 80 (138) und
bringt sie in die Hash-Tabelle 72, so dass nachfolgende
Anforderungen diese erhalten können (140).
Die Lader-Verwaltungs-Steuerung 41 ruft
ein Laden für
das Laderstatus-Steuerungsobjekt 142 auf. Das Laderstatus-Steuerungsobjekt 80 blockiert den
Kontext 144. Dies bringt die Anforderung „in eine Reihe" in dem FIFO-Mutex.
Es wird hier angenommen, dass es keine aktiven Anforderungen gibt,
so dass der Pfad unmittelbar fortgesetzt wird. Das Ladestatus-Steuerungsobjekt 80 kann
eine Beendigung überprüfen (146).
Es erhält
den ersten/nächsten
Lader in der geordneten Abbildung 72 (148) und
lässt diesen über die
Lader-Schnittstelle 100 (150) ablaufen. Die Schritte 146, 148 und 150 werden
wiederholt, bis es keine weiteren Lader in der geordneten Abbildung 72 gibt.
-
6 zeigt
ein Beispiel der Beendigungs-Operation. Die Schritte 160, 162, 164, 166 und 168 sind äquivalent
zu den Schritten 130, 132, 134, 136 bzw. 142 nach 5.
Im Schritt 170 hinterlässt die
Beendigung eine Anzeige, dass sie für die Prüfung auf eine Beendigung anhängig ist,
um im Schritt 172 erfasst zu werden. Die Beendigung wird
dann in der Reihenfolge angeordnet. Wenn die Beendigung im Schritt 172 erfasst
wird, wird das Laden gestoppt und der Beendigungs-Pfad unterbrochen,
was als eine erfolgreiche Beendigung bezeichnet wird. Wenn dies
nicht der Fall ist, übernimmt
der Beendigungs-Pfad den FIFO-Mutex, weil nichts zu beenden ist.
-
Beispiel
-
Als
Beispiel eines Dienste-Verwaltungssystems wird die vorliegende Erfindung
in geeigneter Weise auf ein Netzwerk-Verwaltungssystem angewandt.
-
7 zeigt
ein Beispiel eines Netzwerk-Verwaltungssystems 200, auf
das die vorliegende Erfindung in geeigneter Weise angewandt wird.
-
Das
Netzwerk-Verwaltungssystem 200 ist vorgesehen, um ein Netzwerk 204 zu
verwalten, das eine Vielzahl von Netzwerk-Elementen 206 umfasst. Das
Netzwerk-Verwaltungssystem 200 hat
ein Netzwerkmodell 210 zum Speichern von Daten über das Netzwerk 204.
Das Netzwerk-Verwaltungssystem 200 verwendet GUI-Server 212,
um Daten über
das Netzwerk 204 zu sammeln und sie in das Netzwerkmodell 210 zu
laden. Typischerweise hat das Netzwerk-Verwaltungssystem 200 eine
Vielzahl von Bausteinen 210 (beispielsweise den Zusammenfassungs-Baustein
(SUMBB) 214a, den universellen Topologie-Modellierungsserver-(TUMS-)Block 214b) zum
Sammeln bestimmter Arten von Daten über das Netzwerk 204 von
deren zugeordnetem Satz von Netzwerk-Elementen 206 und zur Lieferung
der gesammelten Daten an ihre entsprechenden GUI-Server 212.
Die GUI-Server 212 können
jedoch die Daten auch direkt von den Netzwerk-Elementen 206 sammeln.
-
Um
Benutzern Daten über
das Netzwerk 204 zu liefern, verwendet das Netzwerk-Verwaltungssystem 200 GUI-Server 212 und 216,
um erforderliche Daten von dem Netzwerkmodell 210 zu entladen oder
zu lesen und sie an die betreffenden GUI-Klienten 218 weiterzuleiten.
-
Einige
der GUI-Server 212, 216 stellen weiterhin Lader
und Entlader bereit. Diese GUI-Server 212, 216 wirken
sowohl als Lade-Anforderungselemente 20 als auch als Lader-Zuführungselemente 30 gemäß 1.
-
Eine
Lader-Verwaltung 220 ist vorgesehen, um das Netzwerkmodell 210 entsprechend
einer Ausführungsform
der Erfindung zu verwalten. Sie hat Komponenten ähnlich zu denen, die in 2 gezeigt sind.
-
Die
GUI-Server 212, 216, die als Lader-Zuführungseinrichtungen
wirken, registrieren ihre Lader und Entlader in der Lader-Verwaltung 120.
GUI-Server 212, 216, die Daten laden oder entladen
möchten,
senden eine Lade- oder Entlade-Anforderung
an die Lader-Verwaltung 120.
-
Wenn
beispielsweise ein Benutzer das Öffnen
einer Gruppe in einem GUI-Klienten anfordert, beispielsweise in
dem grafischen Netzwerk-Darstellungs-(GND-) Klienten 218a,
so sendet der GND-Klient 218a Lade-Anforderungen an seinen
entsprechenden GUI-Server, den GND-Server 216a. Der GND-Server 216a bittet
andererseits die Lader-Verwaltung 120, die Gruppe zu laden.
Die Lader-Verwaltung 120 lässt die darin registrierten
Lader in der Prioritäts-Reihenfolge
ablaufen, die in den Ladern spezifiziert ist. Dies bewirkt, dass
Lader in den GUI-Servern ablaufen, beispielsweise dem Zusammenfassungs-Baustein(SUBB-)Server 212a und
einem universellen Topologie-Modellierungs-(TUMS-)Server 212b.
Der Zusammenfassungs-Baustein 214a sammelt Daten über die
Gruppe. Der TUMS-Server 212b verwaltet die Daten über die
Verbindungsbeziehung zwischen den Netzwerk-Elementen. Somit wird die Gruppe in
das Netzwerk-Modell 210 geladen. Wenn eine Entlade-Anforderung
von dem GND-Server 216 erzeugt wird, werden Entlader in
einer ähnlichen
Weise wie die Lader aufgerufen. Die Entlader laufen nicht ab, bevor
nicht die Gruppe geschlossen ist. Die entladenen Daten werden an
den GND-Server 216a geliefert. Der GND-Server 126a läuft mit
Aktionen zur Anzeige der Gruppe auf dem GND-Klienten 218a weiter.
-
Einige
oder alle der vorstehend beschriebenen Komponenten der vorliegenden
Erfindung können
durch irgendeine geeignete Hardware oder Software realisiert werden,
die die vorstehend beschriebenen Funktionen ausführt.
-
Obwohl
spezielle Ausführungsformen
der vorliegenden Erfindung gezeigt und beschrieben wurden, können Änderungen
und Modifikationen an diesen Ausführungsformen durchgeführt werden, ohne
von dem tatsächlichen
Schutzumfang der Erfindung abzuweichen. Beispielsweise kann die
Lader-Verwaltung
mit weiteren Operationen neben dem Laden, Entladen und Beenden erweitert
werden, um kompliziertere Lade-Wechselwirkungen abzuwickeln.