-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung bezieht sich allgemein auf Datenkommunikationsnetzwerke
und insbesondere auf ein Persistenzspezifikationssystem und -verfahren
zum Ermöglichen
einer Erzeugung mit hoher Leistungsfähigkeit von Auf-Anforderung-Teilabbildungen
in einer Verwaltungsstation für
ein Datenkommunikationsnetzwerk.
-
Hintergrund
der Erfindung
-
Ein
Datenkommunikationsnetzwerk umfasst allgemein eine Gruppe von Geräten, z.
B. Computer, Repeater, Brücken,
Router, etc., die bei Netzwerkknoten gelegen sind, und eine Sammlung
von Kommunikationskanälen
zum Verbinden der verschiedenen Knoten. Eine Hardware und eine Software,
die dem Netzwerk und insbesondere den Geräten zugeordnet sind, ermöglichen,
dass die Geräte
Daten elektronisch über
die Kommunikationskanäle
austauschen.
-
Die
Größe von Netzwerken
variiert. Ein lokales Netz (LAN = Local Area Network) ist ein Netzwerk von
Geräten
in naher Nähe,
typischerweise weniger als eine Meile, und gewöhnlich durch ein einziges Kabel
verbunden, z. B. ein Koaxialkabel. Ein weites Netz (WAN = Wide Area
Network) ist ein Netzwerk von Geräten, die durch längere Abstände getrennt sind
und oft z. B. durch Telefonleitungen oder Satellitenverbindungen
verbunden sind. Tatsächlich überspannen
einige WANs die USA sowie die Welt. Ferner sind viele dieser Netzwerke
bereits verfügbar
für eine
Verwendung durch die Öffentlichkeit,
häufig
einschließlich
Universitäten
und kommerzieller Industrien.
-
Ein
sehr beliebtes Industrienorm-Protokoll für eine Datenkommunikation entlang
der Netzwerke ist das Internetprotokoll (IP). Dieses Protokoll wurde ursprünglich durch
das Verteidigungsministerium der US-Regierung entwickelt und wurde
durch die US-Regierung einer öffentlichen
Verwendung zugänglich
gemacht. Mit der Zeit wurden das Tramsmission-Control-Protocol (TCP) und das Unreliable-Datagram-Protocol
(UDP) für
eine Verwendung mit dem IP entwickelt. Das erstere Protokoll (TCP/IP) ist
ein Protokoll, das eine Übertragung
von Daten ohne Fehler garantiert, da dasselbe eine bestimmte Prüffunktionalität implementiert,
und das letztere Protokoll (UDP/IP) ist ein Protokoll, das eine Übertragung
von Daten nicht garantiert, aber viel weniger Mehraufwand erfordert,
als die TCP/IP-Plattform. Um die verschiedenen Geräte, die
in einem Netzwerk gelegen sind, zu verfolgen und zu verwalten, wurde
ferner schließlich
das Simple-Network-Management-Protocol (SNMP) für eine Verwendung bei einer UDP/IP-Plattform
entwickelt. Die Verwendung der vorhergehenden Protokolle wurde in
der Industrie extensiv und zahlreiche Verkäufer stellen nun viele Typen
von Netzwerkgeräten
her, die diese Protokolle einsetzen können.
-
Viele
Verwaltungssoftwarepakete („Verwaltungsplattformen") sind gegenwärtig zum
Implementieren von „Verwaltungsstationen" in einem Netzwerk und
insbesondere in Verbindung mit dem SNMP erhältlich. Beispiele von im Handel
erhältlichen SNMP-Verwaltungssoftwarepaketen
umfassen OpenView von der Hewlett-Packard Company (hierin die Anmelderin),
NetView/6000 von IBM Corp., Spectrum von Cabletron Systems, Inc.,
NetLabs/Manager von NetLabs, Inc. und SunNet Manager von SunConnect,
Inc. Die Knoten in einem Netzwerk und die Verbindungen derselben,
oft als die Netzwerk-„Topologie" bezeichnet, werden
am besten in einem graphischen Format angezeigt und die meisten,
wenn auch nicht alle, der verfügbaren
Verwaltungssoftwarepakete stellen dieses Merkmal bereit. Mit diesen
Paketen kann ein Netzwerk typischerweise von unterschiedlichen Betrachtungspunkten
betrachtet werden, abhängig
von dem Bereich der erwünschten
Ansicht. Eine Ansicht des Netzwerks könnte z. B. eine sehr breite
umfassende Ansicht aller Knoten des gesamten Netzwerks sein. Eine
zweite Ansicht könnte eine
Ansicht dieser Abschnitte eines Netzwerks innerhalb eines lokalen
Bereichs sein, z. B. innerhalb eines bestimmten Standorts oder Gebäudes. Eine dritte
Ansicht eines Netzwerks, oft ein Segment genannt, könnte eine
Ansicht der Knoten sein, die an einem speziellen LAN-Kabel angeschlossen
sind.
-
Hewlett-Packards
sehr erfolgreiches OpenView war der Gegenstand mehrerer Patente,
einschließlich
z. B. dem US-Patent
Nr. 5,185,860, erteilt an J. C. Wu am 09. Februar 1993, und dem
US-Patent Nr. 5,276,789, erteilt an Besaw et al. am 04. Januar 1994.
Das US-Patent Nr. 5,185,860 beschreibt ein automatisches Entdeckungssystem
für eine
Verwaltungsstation zum Bestimmen der Netzwerkgeräte und -verbindungen eines
Netzwerks oder der Topologie. Das US-Patent Nr. 5,276,789 beschreibt ein
Graphikanzeigesystem für
eine Verwaltungsstation zum graphischen Anzeigen der Topologie eines
Netzwerks und stellt verschiedene Ansichten (einschließlich Internet-,
Segment-, und Knotenansichten) bereit, die durch einen Benutzer
angefordert werden können.
-
Obwohl
die gegenwärtig
verfügbaren SNMP-Verwaltungsstationen
zu einem Ausmaß verdienstvoll
sind, befindet sich die Technik von SNMP-Verwaltungsstationen immer
noch in den Anfängen
und die Leistungsfähigkeit
dieser Verwaltungsstationen kann noch verbessert und optimiert werden.
Ein spezifischer Bereich, in dem man sich eine Optimierung vorstellt,
betrifft die Integrationsanwendungen, die den Verwaltungsstationen
zugeordnet sind und die zusätzliche
Informationen über
Netzwerkgeräte,
z. B. Router, liefern können.
Die zusätzlichen
Informationen könnten
z. B. Gerätekonfigurationsinformationen,
einen Gerätestatus,
Leistungsfähigkeitsparameter,
zusätzliche
Topologieinformationen, etc. umfassen. Bei Verwaltungsstationen
des Stands der Technik jedoch werden diese zusätzlichen Informationen dem
Benutzer oft nicht verfügbar gemacht.
Ein Grund, dass diese zusätzlichen
Informationen nicht verfügbar
gemacht werden, ist, dass diese Systeme unter einer unangemessenen
Schnittstelle zwischen den Integrationsanwendungen und dem Anzeigeabbildungsgenerator
innerhalb dieser Systeme leiden.
-
Genauer
gesagt weisen viele Verwaltungsstationen Auf-Anforderung-Teilabbildung-Fähigkeiten
auf. Ein derartiges Beispiel ist Hewlett-Packards OpenView. Bei
Auf-Anforderung-Teilabbildung-Systemen
entspricht eine Teilabbildung jeder Ansicht des Netzwerks, die angezeigt
werden soll. Die Systemabbildung ist die Sammlung aller Teilabbildungen.
Bei diesen Auf-Anforderung-Teilabbildung-Systemen und insbesondere
dem OpenView-System spezifiziert der Benutzer, welche Teilabbildungen
der Benutzer verfügbar
zu haben wünscht,
und spezifiziert daher die Teilabbildungen, die innerhalb der Abbildung
resident sind. Außerdem
kann der Benutzer ferner eine Teilabbildung während eines Betriebs öffnen oder „explodieren
lassen", obwohl
dieselbe nicht als innerhalb der Abbildung resident spezifiziert
ist. In diesem Fall wird die Teilabbildung unmittelbar aus Topologiedaten
erzeugt, wenn der Benutzer die Verwaltungsstation auffordert, die
Teilabbildung zu öffnen, daher
der Name Auf-Anforderung. Der vorhergehende Entwurf ist jedoch problematisch.
Erstens, falls eine Teilabbildung nicht in der Abbildung resident
ist und der Benutzer die Teilabbildung öffnet, dann kann eine Integrationsanwendung
auf Grund von Zeitbeschränkungen
beim Öffnen
der erwünschten
Teilabbildung nicht angemessen bestimmen, welche zusätzlichen
Informationen zu der Verwaltungsstation zu liefern sind, und der
Benutzer wird deshalb nicht über
diese zusätzlichen
Informationen benachrichtigt. Mit anderen Worten benötigen die
Integrationsanwendungen Zeit, um die Topologiedaten zu analysieren,
und Zeit, um die zusätzlichen
Informationen für
eine Anzeige für
den Benutzer zu erzeugen.
-
Ein
anderes Problem bei gegenwärtigen
Entwürfen
ist, dass Integrationsanwendungen für nicht-residente Teilabbildungen
nicht in der Lage sind, den Benutzer vor kritischen Infor mationen
zu warnen, bis der Benutzer die Teilabbildung explodieren lässt. Es
ist erwünscht,
den Benutzer zu warnen, sobald eine Anomalie erfasst wird.
-
Bei
Verwaltungsstationen des Stands der Technik bleibt, wenn eine Teilabbildung
einmal erzeugt wurde, dieselbe ferner von da an in der Abbildung
des Systems, selbst falls die Integrationsanwendungen die Teilabbildung
nicht länger
benötigen. Diese
missliche Lage verwendet unerwünschterweise
wertvollen Speicherplatz. Diese Situation verbraucht ferner unnötigerweise
Prozessorzeit, wenn gewisse Ereignisse oder Veränderungen bei einer Netzwerktopologie
unnötigerweise
zum Aktualisieren einiger der unnötigen residenten Teilabbildungen
verarbeitet werden. Somit besteht ein Bedarf in der Industrie nach
einem System und einem Verfahren zum besseren schnittstellenmäßigen Verbinden
von Integrationsanwendungen mit einem Auf-Anforderung-Teilabbildung-System zum Minimieren
von Speichererfordernissen desselben und zum Optimieren einer Leistungsfähigkeit
(einschließlich
einer Geschwindigkeit) desselben.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren
zum Verbessern der Leistungsfähigkeit
eines Auf-Anforderung-Teilabbildung-Prozesses in einer Verwaltungsstation
zu schaffen.
-
Diese
Aufgabe wird durch ein System gemäß Anspruch 1 und ein Verfahren
gemäß Anspruch
9 gelöst.
-
Ein
weiterer Vorteil der vorliegenden Erfindung ist, ein verbessertes
schnittstellenmäßiges Verbinden
von Integrationsanwendungen mit Teilabbildungsinformationen zu liefern.
-
Ein
weiterer Vorteil der vorliegenden Erfindung ist, ein System und
ein Verfahren zum Minimieren von Speichererfordernissen für einen
Auf-Anforderung-Teilabbildung-Prozess in einer Verwaltungsstation
bereitzustellen.
-
Ein
weiterer Vorteil der vorliegenden Erfindung ist, ein System und
ein Verfahren zum Minimieren einer erforderlichen Verarbeitungszeit
für einen Auf-Anforderung-Teilabbildung-Prozess
in einer Verwaltungsstation bereitzustellen.
-
Kurz
beschrieben ist die vorliegende Erfindung ein Persistenzspezifikationssystem
und -verfahren für
eine Verwaltungsstation oder ein anderes Gerät eines Netzwerks zum Verbessern
einer Schnittstelle zwischen einer Integrationsanwendung und einer
graphischen Benutzerschnittstelle, so dass mehr Informationen ein
Netzwerk betreffend zu einem Benutzer geliefert werden, während Speichererfordernisse
und eine Verarbeitungszeit minimiert sind. Das System weist einen
Prozessor, der die verschiedenen Softwareelemente des Systems ausführt, einen
Entdeckungsmechanismus zum Bestimmen der Netzwerktopologiedaten
und einen Layout-Mechanismus zum Umwandeln der Netzwerktopologiedaten
in Abbildungsdaten und zum Treiben einer Anzeige mit den Abbildungsdaten
auf.
-
Genauer
gesagt weist der Entdeckungsmechanismus einen Netzwerkmonitor, der
konfiguriert ist, um die Topologie des Netzwerks zu überwachen und
zu bestimmen, eine Topologiedatenbank zum Speichern der Topologiedaten
und einen Topologieverwalter bzw. eine Topologieverwaltungseinrichtung zum
Verwalten der Topologiedatenbank auf. Der Netzwerkmonitor ist ferner
konfiguriert, um Topologieveränderungsereignisse
zu erzeugen, wenn eine Veränderung
bei einer Netzwerktopologie auftritt, und ferner derartige Ereignisse
von anderen Geräten zu
empfangen, die mit dem Netzwerk verbunden sind.
-
Der
Layout-Mechanismus ist in Kommunikation mit dem Entdeckungsmechanismus
und einer oder mehreren Integrationsanwendungen. Der Layout-Mechanismus
weist einen Topologie-zu-Abbildung-Übersetzer,
eine graphische Benutzerschnittstelle (GUI = graphical user interface)
und eine Abbildungsdatenbank auf. Der Übersetzer ist konfiguriert, um
die Topologiedaten in die Abbildungsdaten umzuwandeln, die Ereignisse zu
empfangen und die Abbildungsdaten basierend auf den Ereignissen
zu verändern.
Die GUI ist konfiguriert, um die Abbildungsdaten von dem Übersetzer
zu empfangen, die Abbildungsdaten in der Abbildungsdatenbank zu
verwalten und die Anzeige basierend auf den Abbildungsdaten zu treiben.
Die GUI liefert ferner Informationen zu und empfängt Informationen von den Integrationsanwendungen,
die die Abbildungsdaten betreffen.
-
Bei
dem bevorzugten Ausführungsbeispiel ist
der Übersetzer
konfiguriert, um einen Satz von hierarchisch angeordneten Teilabbildungen
entsprechend verschiedener Ansichten des Netzwerks zu erzeugen.
Eine Abbildung ist hierin als die Sammlung aller Teilabbildungen
definiert. Die hierarchisch angeordneten Teilabbildungen umfassen
eine Internet-Teilabbildung,
die zumindest ein Netzwerkobjekt aufweist, zumindest eine Netzwerk-Teilabbildung,
die dem zumindest einem Netzwerkobjekt zugeordnet ist und zumindest
ein Segmentobjekt aufweist, zumindest eine Segment-Teilabbildung, die
dem zumindest einem Segmentobjekt zugeordnet ist und zumindest ein
Knotenobjekt aufweist, und zumindest eine Knoten-Teilabbildung,
die dem zumindest einem Knotenobjekt zugeordnet ist und zumindest
ein Schnittstellenobjekt aufweist.
-
Gemäß einem
erheblichen Merkmal der vorliegenden Erfindung weist der Übersetzer
einen Persistenzspezifikationsmechanismus auf. Der Persistenzspezifikationsmechanismus
und eine zugeordnete Methodologie spezifizieren basierend auf Eingangssignalen,
die dem Objekt entsprechen, wann ein Objekt, das angezeigt werden
soll, „persistent" ist und wann ein
Objekt, das angezeigt werden soll, „transient" ist. Die Eingangssignale werden durch den
Benutzer und durch die Integrationsanwendungen erzeugt, die mit
der Entdeckungs-/Layout-Software verbunden sind. Der Übersetzer
definiert Teilabbildungen als persistent, wenn die Teilabbildung ein
persistentes Objekt aufweist, und als transient, wenn die Teilabbildung
ohne persistente Objekte ist.
-
Persistente
Teilabbildungen werden erzeugt und kontinuierlich in dem Übersetzer
beibehalten, so dass Integrationsanwendungen wirksam einen kontinuierlichen
Zugriff aufweisen und die persistenten Objektinformationen verwenden
können,
um zusätzliche
Informationen für
den Benutzer zu erzeugen und zu liefern. Transiente Teilabbildungen
werden lediglich für
eine temporäre
Zeitperiode erzeugt, wenn ein Benutzer das System auffordert, und
der Übersetzer
ist konfiguriert, um die transienten Teilabbildungen zu löschen (nicht
zu speichern), nachdem der Benutzer mit einem Betrachten der transienten
Teilabbildungen fertig ist. Folglich verbessert das Persistenzspezifikationssystem
die Schnittstelle zwischen den Integrationsanwendungen und der graphischen
Benutzerschnittstelle, so dass mehr Informationen ein Netzwerk betreffend
zu dem Benutzer geliefert werden. Das System minimiert ferner Speichererfordernisse
und eine Verarbeitungszeit durch ein Entfernen unnötiger Teilabbildungen,
die basierend auf eingehenden Ereignissen der Gegenstand einer Veränderung
sein könnten.
-
Zusätzlich zu
einem Erreichen aller zuvor erwähnter
Aufgaben, weist die vorliegende Erfindung zahlreiche weitere Vorteile
auf, von denen einige hierin im Folgenden geschildert sind.
-
Ein
Vorteil der vorliegenden Erfindung ist, dass dieselbe einfach in
einem Entwurf ist und ohne weiteres auf einer kommerziellen Massenskala
zu implementieren ist.
-
Ein
weiterer Vorteil der vorliegenden Erfindung ist, dass dieselbe effizient
sowie in einem Betrieb zuverlässig
ist.
-
Ein
weiterer Vorteil der vorliegenden Erfindung ist, dass die Grundlagen
des Persistenzspezifikatiossystems und -verfahrens nicht nur auf
Verwaltungsstationen sondern auch auf andere Geräte angewendet werden können, einschließlich Geräten, die
das SNMP nicht praktizieren.
-
Andere
Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden
einem Fachmann auf dem Gebiet auf eine Untersuchung der folgenden Zeichnungen
und der detaillierten Beschreibung hin ersichtlich. Alle derartigen
zusätzlichen
Aufgaben, Merkmale und Vorteile sollen hierin innerhalb des Schutzbereichs
der vorliegenden Erfindung eingeschlossen sein.
-
Kurze Beschreibung
der Zeichnungen
-
Die
vorliegende Erfindung wird mit Bezug auf die folgenden Zeichnungen
in dem Kontext des Texts ersichtlicher.
-
1 ist
ein Blockdiagramm einer Verwaltungsstation, die eine Entdeckungs-/Layout-Software aufweist,
die das Persistenzspezifikationssystem und -verfahren der vorliegenden
Erfindung einsetzt;
-
2 ist
ein schematisches Diagramm, das eine Anzeigeabbildung darstellt,
die eine Sammlung von Teilabbildungen aufweist, von denen jegliche
auf der Anzeige der Verwaltungsstation durch die Entdeckungs-/Layout-Software
von 1 angezeigt werden können;
-
3 ist
ein Blockdiagramm der Entdeckungs-/Layout-Software von 1 und einer
Integrationsanwendung, die mit derselben schnittstellenmäßig verbunden
ist, gemäß der vorliegenden
Erfindung;
-
4 ist
ein Flussdiagramm, das die Architektur des Topologie-zu-Abbildung-Übersetzers
von 3 darstellt;
-
5 ist
ein Flussdiagramm, das die Architektur eines Stapel-Lesen-Blocks
von 4 darstellt;
-
6 ist
ein Flussdiagramm, das die Architektur eines Objekte-Wiedererlangen-Blocks
von 4 darstellt;
-
7 ist
ein Flussdiagramm, das die Architektur des Abbildungsveränderungen-Berechnen-Blocks
von 4 darstellt;
-
8 ist
ein Flussdiagramm, das die Architektur eines Teilabbildungsveränderungen-Berechnen-Blocks
von 7 darstellt;
-
9 ist
ein Flussdiagramm, das die Architektur eines Netzwerkveränderungsblocks
von 8 darstellt;
-
10 ist
ein Flussdiagramm, das die Architektur eines Segmentveränderungsblocks
von 8 darstellt;
-
11 ist
ein Flussdiagramm, das die Architektur eines Knotenveränderungsblocks
von 8 darstellt;
-
12 ist
ein Flussdiagramm, das die Architektur eines Schnittstellenveränderungsblocks
von 8 darstellt;
-
13 ist
ein Flussdiagramm, das die Architektur eines Abbildung-Aktualisieren-Blocks
von 4 darstellt;
-
14 ist
ein Flussdiagramm, das die Architektur eines Auf-Anforderung-Teilabbildung-Blocks innerhalb
der graphischen Benutzerschnittstelle (GUI) von 2 darstellt;
-
15 ist
ein Zustandsdiagramm, das einer Teilabbildung von 2 entspricht,
gemäß dem neuartigen
Persistenzspezifikationssystem und -verfahren von 1;
-
16 ist
ein schematisches Diagramm eines Persistenzvektors, der einer Teilabbildung
entspricht, zum Implementieren des Persistenzspezifikationssystems
und -verfahrens von 1;
-
17 ist
ein Flussdiagramm, das die Architektur eines Teilabbildung-Hinzufügen-Entscheidungsblocks
von 7 zum Implementieren des Persistenzspezifikationssystems
und -verfahrens von 1 darstellt; und
-
18 ist
ein Flussdiagramm, das die Architektur eines Persistenzspezifikation-Entscheidungsblocks
von sowohl 7 als auch 17 zum
Implementieren des Persistenzspezifikationssystems und -verfahrens
von 1 darstellt.
-
Detaillierte
Beschreibung des bevorzugten Ausführungsbeispiels
-
Die
folgende Beschreibung ist über
den gegenwärtig
betrachteten besten Modus zum Ausführen der vorliegenden Erfindung.
Diese Beschreibung soll nicht in einem begrenzenden Sinn aufgefasst werden,
sondern wird lediglich zum Zweck eines Beschreibens der allgemeinen
Grundlagen der Erfindung vorgenommen. Der Schutzbereich der Erfindung
sollte durch ein Referenzieren der beigefügten Ansprüche bestimmt sein.
-
1 zeigt
ein Blockdiagramm einer objektorientierten Verwaltungsstation 100,
die mit einem Universalcomputersystem implementiert ist, das eine neuartige
Entdeckungs-/Layout-Software 101 enthält, die einen Persistenzspezifikationsmechanismus 103 und
eine zugeordnete Methodologie der vorliegenden Erfindung einsetzt.
Mit Bezug auf 1 enthält die Verwaltungsstation 100 einen
herkömmlichen
Prozessor 102. Der Prozessor 102 kommuniziert
mit anderen Elementen innerhalb der Verwaltungsstation 100 über einen
Systembus 104. Ein Eingabegerät 106, z. B. eine
Tastatur oder eine Maus, wird verwendet, um Daten von einem Benutzer
des Systems 100 einzugeben, und eine Anzeige 108 wird verwendet,
um Daten zu dem Benutzer auszugeben. Eine Netzwerkschnittstelle 112 wird
verwendet, um die Verwaltungsstation 100 schnittstellenmäßig mit einem
Netzwerk 118 zu verbinden, um zu ermöglichen, dass die Verwaltungsstation 100 als
ein Knoten in einem Netzwerk 118 handelt. Eine Platte 114 kann verwendet
werden, um die Software der Entdeckungs-/Layout-Software 101 der
vorliegenden Erfindung zu speichern, sowie die Datenbanken (Topologie-
und Abbildungs-) zu speichern, die durch die Entdeckungs-/Layout-Software 101 erzeugt
werden. Ein Drucker 116 kann verwendet werden, um eine Druckkopieausgabe
der Knoten des Netzwerks 118 bereitzustellen, die durch
die Entdeckungs-/Layout-Software 101 entdeckt
werden. Ein Hauptspeicher 110 innerhalb der Verwaltungsstation 100 enthält die Entdeckungs-/Layout-Software 101.
Die Entdeckungs-/Layout-Software 101 kommuniziert
mit einem herkömmlichen
Betriebssystem 122 und einer herkömmlichen Netzwerk-Software 124,
um die Knoten in dem Netzwerk 118 zu entdecken. Die Netzwerk-Software 124 dient
als die Intelligenz, einschließlich
einer Validierung, für
die Datenkommunikationsprotokolle. Wie es in 1 gezeigt
ist, implementiert bei dem bevorzugten Ausführungsbeispiel die Netzwerk-Software
das IP, das TCP und UDP über
das IP, and das SNMP über
das UDP. Alle der vorhergehenden Protokolle sind auf dem Gebiet
gut bekannt.
-
Die
Entdeckungs-/Layout-Software 101 implementiert eine objektorientierte
Funktionalität.
In dem Kontext von SNMP-Verwaltern
bedeutet objektorientiert, dass die meisten der Verwaltungssystemhandlungen
und -prozesse, die der Benutzer aufrufen kann, zu einer Klasse von
Geräten
anstelle einzeln verwalteter Netzwerkknoten hin orientiert sind.
-
Allgemein
ist die Entdeckungs-/Layout-Software 101 von 1 konfiguriert,
um die Netzwerktopologie zu entdecken, d. h. alle Netzwerkknoten
und Netzwerkverbindungen, die in dem Netzwerk 118 existieren,
und um eine Abbildung aufzubauen, die verschiedene Teilabbildungen
aufweist, von denen jegliche zum Anzeigen der Netzwerktopologie
auf der Anzeige 108 verwendet werden können. 2 zeigt eine 200, die durch die Entdeckungs-/Layout-Software 101 aus
Topologiedaten erzeugt wird, die von dem Netzwerk 118 entdeckt
werden. Die Entdeckungs-/Layout-Software 101 kann jegliche
der verschiedenen Teilabbildungen zu der Anzeige 108 (1)
zum Betrachten durch den Benutzer treiben.
-
Die
Teilabbildungen in der 200 von 2 sind
in einer Hierarchie angeordnet. Eine Wurzel-Teilabbildung bzw. Root-Teilabbildung 202 ist
auf einer Wurzel-Ebene bzw. Root-Ebene definiert. Die Wurzel-Teilabbildung 202 stellt
die Teilabbildung der höchsten
logischen Ebene in der Hierarchie dar und zeigt Objekte 203,
die als Ankerpunkte für
unterschiedliche Teilabbildungshierarchien handeln. Jede Hierarchie
ist ein getrennter Verwaltungsbereich. Dies könnte z. B. ein Netzwerk, eine
logische Gruppierung von Knoten oder ein gewisser anderer Bereich
sein. Eine Internet-Teilabbildung 204 ist auf einer Internet-Ebene
definiert und wird durch ein „Explodieren
Lassen" eines Objekts 203 innerhalb
der Wurzel-Teilabbildung 202 erzeugt. In dem Kontext dieses
Dokuments bedeutet „Explodieren
Lassen", dass der
Benutzer die Verwaltungsstation 100 mit dem Eingabegerät 106 auffordert,
zu unterbrechen und mehr Daten zu liefern, die zu dem fraglichen
Objekt 203 gehören.
Ferner stellt die Internet-Teilabbildung 204 Objekte 203 in
der Form von Netzwerken und Routern dar. Irgendeine einer Anzahl
von Netzwerk-Teilabbildungen 206 kann aus der Internet-Teilabbildung 204 explodieren
gelassen werden. Jede Netzwerk-Teilabbildung 206 zeigt
Objekte 203 in der Form von Segmenten und Verbindern. Irgendeine
einer Anzahl von Segment-Teilabbildungen 208 kann aus einem
Objekt 203 innerhalb einer Netzwerk-Teilabbildung 206 explodieren
gelassen werden. Jede Segment-Teilabbildung 208 zeigt Objekte
in der Form von Netzwerkknoten. Schließlich kann irgendeine einer
Anzahl von Knoten-Teilabbildungen 210 aus einem Objekt
innerhalb einer Segment-Teilabbildung 208 explodieren gelassen
werden. Jede Knoten-Teilabbildung 210 zeigt Objekte 203 in
der Form von Schnittstellen innerhalb dieses Knotens.
-
Bei
dem bevorzugten Ausführungsbeispiel implementiert,
obwohl es nicht notwendig ist, um die vorliegende Erfindung zu praktizieren,
die Entdeckungs-/Layout-Software 101 Auf-Anforderung-Teilabbildungen,
um einen Speicher und eine Verarbeitungszeit zu bewahren. Das Konzept
von Auf-Anforderung-Teilabbildungen
ist, lediglich diese Teilabbildungen in der 200 von 2 zu
platzieren, die der Benutzer sehen will. Das Nettoergebnis ist,
dass lediglich ein Abschnitt der Teilabbildungs-Hierarchie zu einer
gegebenen Zeit in der 200 ist. In 2 sind
Teilabbildungen (nicht-resident), die nicht vorhanden sind, aber
auf ein Auffordern durch den Benutzer hin erzeugt würden, durch
eine Schraffur angegeben. Der residente Teilabbildungsteilsatz der Hierarchie ändert sich über die
Zeit, wenn der Benutzer die Teilabbildungshierarchie durchläuft und
bewirkt, dass nicht-residente Teilabbildungen erzeugt werden.
-
Ein
Blockdiagramm auf hoher Ebene der Entdeckungs-/Layout-Software 101 (1)
ist in 3 dargelegt. Mit der Ausnahme des Persistenzspezifikationsmechanismus 103 ist
die Architektur der Entdeckungs-/Layout-Software 101 in 3 im Wesentlichen
die gleiche wie die oder ähnlich
der Architektur von Hewlett-Packards gut bekanntem und im Handel
erhältlichen
Verwaltungssoftwarepaket, das OpenView genannt wird. Wie es in 3 gezeigt ist,
weist auf der allgemeinen Architekturebene die Entdeckungs-/Layout-Software 101 einen
Entdeckungsmechanismus 302 zum Entdecken von Knoten und
Verbindungen des Netzwerks 118 und einen Layoutmechanismus 304 zum
Empfangen von Topologiedaten von dem Entdeckungsmechanismus 302 und
zum Erzeugen der 200 (2)
zum Treiben der Anzeige 108 auf. Außerdem können eine oder mehrere Integrationsanwendungen 332 Anzeige-
und Abbildungsinformationen mit dem Layoutmechanismus 304 kommunizieren.
-
Der
Entdeckungsmechanismus 302 weist einen Netzwerkmonitor 306,
der mit dem Netzwerk 118 verbunden ist, wie es durch Verbindungen 308a, 308b angegeben
ist, einen Topologieverwalter bzw. eine Topologieverwaltungseinrichtung 310,
die mit dem Netzwerkmonitor 306 verbunden ist, wie es durch
Pfeile 312a, 312b angegeben ist, und eine Topologiedatenbank
in Kommunikation mit dem Topologieverwalter 310 auf, wie
es durch einen Pfeil 316 angegeben ist.
-
Der
Netzwerkmonitor 306 sendet und empfängt Datenpakete zu und von
dem Netzwerk 118. Der Netzwerkmonitor 306 entdeckt
und überwacht eine
Netzwerktopologie, wie es durch die Pfeile 308a, 308b angegeben
ist. Wenn sich eine Netzwerktopologie in dem Netzwerk verändert, erzeugt
der Netzwerkmonitor 306 Ereignisse oder Programmunterbrechungen
(traps) (SNMP-Fachsprache), die einen Objektidentifizierer und Objektveränderungsinformationen
umfassen. Der Netzwerkmonitor 306 kann ferner Ereignisse
von anderen Geräten
in dem Netzwerk 118 empfangen, wie beispielsweise einem
Router. Der Netzwerkmonitor 306 steht mit dem Netzwerk 118 durch
die Netzwerksoftware 126 in Wechselwirkung (1),
die im Wesentlichen Protokollstapel aufweist, die bei dem bevorzugten
Ausführungsbeispiel
IP, TCP, UDP und SNMP entsprechen, und die diese Protokolle allgemein
implementiert und Validierungsfunktionen durchführt. Ferner bestückt der Netzwerkmonitor 306 die
Topologiedatenbank 314 durch den Topologieverwalter 310 und
benachrichtigt den Topologieverwalter 310 über Ereignisse
(Topologieveränderungen).
Schließlich
ist anzumerken, dass das US-Patent Nr. 5,185,860 an Wu ein Knotenentdeckungssystem
beschreibt, das eingesetzt werden könnte, um den Netzwerkmonitor 306 hierin
zu implementieren.
-
Der
Topologieverwalter 310 verwaltet die Topologiedatenbank 314,
wie es durch einen Zweirichtungspfeil 316 angegeben ist.
Der Topologieverwalter 310 fordert den Netzwerkmonitor 306 auf,
Topologiedaten zu aktualisieren, die auf spezielle Ereignisse bezogen
sind, wie es durch den Pfeil 312a angegeben ist, und empfängt Topologieaktualisierungen,
wie es durch den Pfeil 312b angegeben ist.
-
Die
Topologiedatenbank 314 speichert Topologiedaten basierend
auf Objekten, die verwendet werden, um das Netzwerk aus logischen
Gründen
zu partitionieren. Objekte umfassen zum Beispiel, aber nicht begrenzt
darauf, ein Netzwerk, ein Segment, einen Computer, einen Router,
einen Repeater, eine Brücke,
etc. Außerdem
umfassen die Topologiedaten, die mit Bezug auf die Objekte gespeichert
sind, zum Beispiel, aber nicht begrenzt darauf, eine Schnittstellen-
oder Geräteadresse,
einen Schnittstellen- oder Gerätetyp,
einen Schnittstellen- oder Gerätehersteller
und ob eine Schnittstelle oder ein Gerät das SNMP unterstützt.
-
Der
Layoutmechanismus 304 weist einen Topologie-zu-Abbildung-Übersetzer 318 in
Kommunikation mit dem Topologieverwalter 310, wie es durch Pfeile 320a, 320b angegeben
ist, eine graphische Benutzerschnittstelle (GUI = graphical user
interface) 322 in Kommunikation mit dem Topologie-zu-Abbildung-Übersetzer 318,
wie es durch Pfeile 324a, 324b angegeben ist,
und eine Abbildungsdatenbank 326 in Kommunikation mit der
GUI 322 auf, wie es durch einen Zweirichtungspfeil 328 angegeben
ist. Die Integrationsanwendung 332 kommuniziert Informationen mit
der GUI 322, wie es durch Pfeile 333a, 333b angegeben
ist.
-
Es
ist anzumerken, dass der Netzwerkmonitor 306, der Topologieverwalter 310,
der Übersetzer 318 und
die GUI 322 sich bei einem Verwenden der Kombination des
Betriebssystems 122 (1) und des
Prozessors 102 (1) abwechseln, um die jeweiligen
Funktionen derselben zu erzielen. Ein „Kontextschalter", wie derselbe hierin
verwendet wird, bezieht sich auf eine Veränderung bei einer Steuerung des
Systems 122 und/oder des Prozessors 102 durch
die vorhergehenden Softwareelemente.
-
Der Übersetzer 318 wandelt
Topologiedaten aus der Topologiedatenbank 314 in Abbildungsdaten um
und baut die verschiedenen Teilabbildungen 202 – 210 in
der 200 von 2 auf. Der Übersetzer 318 kann
eine Anforderung zu dem Topologieverwalter 310 weiterleiten,
wie es durch einen Pfeil 320a angegeben ist, um Topologiedaten
hinsichtlich spezieller Objekte zu erhalten. Zusätzlich zu einem Weiterleiten
von Topologiedaten zu dem Übersetzer 318 auf eine
Anforderung hin benachrichtigt der Topologieverwalter 310 den Übersetzer 318,
wie es durch den Pfeil 320b angegeben ist, wenn sich Topologiedaten basierend
auf einem Ereignis verändert
haben, so dass der Übersetzer 318 jegliche
geeignete Veränderungen
bei den Teilabbildungen vornehmen kann.
-
Die
GUI 322 verwaltet die Abbildungsdatenbank 326,
wie es durch den Zweirichtungspfeil 328 angegeben ist,
und verwaltet die Anzeige 108 und das Eingabegerät 106,
wie es durch die Pfeile 330a, 330b angegeben ist.
Die GUI 322 empfängt
Abbildungsaktualisierungen von dem Übersetzer 318, wie es
durch einen Pfeil 324b angegeben ist, und legt dem Übersetzer 318 benutzerausgelöste Ereignisse vor,
wie es durch einen Pfeil 324a angegeben ist. Ein benutzerausgelöstes Ereignis
umfasst eine Aufforderung 330a von einem Benutzer, ein
Objekt explodieren zu lassen, wie es mit Bezug auf 2 beschrieben
ist. Schließlich
ist anzumerken, dass das US-Patent
Nr. 5,276,789 an Besaw et al. eine graphische Benutzerschnittstelle
beschreibt, die eingesetzt werden könnte, um die GUI 322 hierin
zu implementieren.
-
4 zeigt
ein Flussdiagramm 400, das die Architektur und Funktionalität des bevorzugten
Ausführungsbeispiels
des Topologie-zu-Abbildung-Übersetzers 318 (3)
angibt. Der Übersetzer
setzt den Persistenzspezifikationsmechanismus 103 und eine zugeordnete
Methodologie gemäß der vorliegen den Erfindung
ein, die Kontextschalter (Veränderungen bei
der Steuerung des Betriebssystems 122 und/oder des Prozessors 102)
minimieren und die Geschwindigkeit und die Leistungsfähigkeit
der Entdeckungs-/Layout-Software 101 erheblich verbessern.
-
Mit
Bezug auf 4 werden anfänglich Ereignisse in einer
Warteschlange (nicht gezeigt) oder einem Akkumulator, der dem Topologieverwalter 310 zugeordnet
ist, in Warteschlange gestellt und akkumuliert und warten auf eine
Wiedererlangung durch den Übersetzer 318.
Der Übersetzer 318 liest
während
jedes Zugriffs einen Stapel von Ereignissen von dem Topologieverwalter 310.
Jedes Ereignis enthält einen
Objektidentifizierer und eine Objektveränderung. Außerdem ist der Stapel um irgendeine
Anzahl von Ereignissen größer als
Null. Bei dem getesteten Ausführungsbeispiel
war der Stapel auf eine Anzahl von nicht mehr als 500 Ereignissen
begrenzt, aber andere Einstellungen, entweder kleiner als oder größer (vielleicht
erheblich) als diese Anzahl könnten verwendet
werden, abhängig
von der Konfiguration des Systems.
-
Als
nächstes,
wie es bei einem Block 404 angegeben ist, ruft der Übersetzer 318 den
Topologieverwalter 310 für eine Liste von Topologiedaten
hinsichtlich aller Objekte, die in den Ereignissen identifiziert
wurden. Nach einem Empfangen der Topologiedaten, tritt der Block 404 zu
einem Block 406 über.
-
Bei
dem Block 406 berechnet der Übersetzer 318 die
Veränderungen,
die an den Abbildungsdaten vorzunehmen sind, insbesondere der 200 (2), basierend
auf den Topologiedatenveränderungen,
die in den Ereignissen angegeben sind. Der Block 406 tritt
zu einem Block 408 über.
-
Bei
dem Block 408 aktualisiert der Übersetzer 318 die 200 (2) durch
ein Rufen der GUI 322 und Benachrichtigen der GUI 322 über alle Teilabbildungsverän derungen
(SYMCHANGELIST und NEWSYMLIST, die hierin im Folgenden beschrieben
sind), die zu allen Objektveränderungen gehören. Diese
Transaktion ist vorzugsweise, obwohl nicht notwendigerweise, eine
Stapelübertragung. Während dieser
Stapelübertragungstransaktion
identifiziert der Übersetzer 318 jede
Teilabbildung, die verändert
werden soll, jedes Objekt, das innerhalb einer Teilabbildung verändert werden
soll, und die spezielle Veränderung,
die an dem Objekt bewirkt werden soll. Eine Objektveränderung
kann zum Beispiel, aber nicht begrenzt darauf, eine Farb-, Positions- oder
Verbindungsveränderung
umfassen. Der Block 408 tritt zu einem Block 410 über.
-
Bei
dem Block 410 bestimmt der Übersetzer 318, ob
es einen weiteren Stapel von Ereignissen gibt, der von dem Topologieverwalter 310 gelesen werden
soll. Falls dem so ist, dann tritt der Block 410 zu dem
Block 402 über
und der vorhergehend beschriebene Prozess wird wiederholt. Falls
nicht, dann wartet die Software bei dem Block 410 auf einen
anderen Stapel von Ereignissen.
-
Wegen
des bevorzugten Ausführungsbeispiels
des Übersetzers 318,
das in 4 dargelegt ist, werden Topologiedaten, die zu
verschiedenen Objekten gehören,
in einem Stapel von dem Topologieverwalter 310 wiedererlangt
und werden ferner Abbildungsdaten, die zu verschiedenen Teilabbildungen
gehören,
in einem Stapel von dem Übersetzer 318 zu
der GUI 322 übertragen.
Die vorhergehende Implementierung minimiert Kontextschalter, d.
h. minimiert die Anzahl von Malen, die eine Steuerung des Prozessors 102 (1)
und/oder des Betriebssystems 122 (1) von einem
Softwaremodul zu einem anderen geleitet wird.
-
5 zeigt
ein Flussdiagramm der Architektur und Funktionalität zum Implementieren
eines bevorzugten Ausführungsbeispiels
des Stapel-Lesen-Blocks 402 (4). Dieses
Flussdiagramm stellt dar, wie der Übersetzer 318 einen
Stapel von Ereignissen von dem Topologieverwalter 310 liest.
Wie es bei einem Block 502 angegeben ist, werden anfänglich Ereignisse
von dem Topologieverwalter 310, die Veränderungen bei Topologiedaten
angeben, akkumuliert (in Warteschlange gestellt). Ein Zähler bei
einem Block 504 wird in Verbindung mit einer Schleife verwendet,
um jedes Ereignis von dem Topologieverwalter 310 zu dem Übersetzer 318 zu
führen
bzw. zu leiten. Bei einem Block 506 wird ein Ereignis durch den Übersetzer 318 von
dem Verwalter 310 gelesen. Der Block 506 tritt
zu einem Block 508 über,
der das Ereignis decodiert. Das Ereignis wird decodiert, um den
Ereignistyp und zugeordnete Daten zu identifizieren. Es gibt zahlreiche
Typen von Ereignissen und unterschiedliche Typen von Ereignissen
weisen unterschiedliche Typen von zugeordneten Daten auf. Genauer
gesagt kann ein Ereignis zum Beispiel, aber nicht darauf begrenzt,
einen neuen Knoten oder eine Knotenstatusveränderung (z. B. verbunden/zugreifbar
oder verbunden/unzugreifbar) betreffen. Ein Ereignis weist einen
Ereignisidentifizierer, gewöhnlich bei
dem Kopfblock, zum Identifizieren des Ereignistyps auf. In dem Fall
eines neuen Knotens enthält
das Ereignis außerdem
einen Objektidentifizierer und eine Adresse. In dem Fall einer Knotenstatusveränderung
enthält
das Ereignis einen Objektidentifizierer, den alten Status und den
neuen Status.
-
Der
Block 508 tritt zu einem Block 510 über. Bei
dem Block 510 werden die decodierten Ereignisdaten (d.
h. eine Aufzeichnung) zu einer TLIST hinzufügt. Bei einem Block 512 wird
der Zähler
inkrementiert, so dass ein anderes Ereignis bedient wird. Der Block 512 tritt
zu einem Block 514 über,
der bestimmt, ob es noch Ereignisse gibt, die bedient werden sollen.
Falls dem so ist, dann tritt der Block 514 zurück zu dem
Block 506 über
und der zuvor erwähnte
Prozess wird wiederholt. Falls nicht, dann kehrt der Block 514 zu
dem Block 404 (4) zurück.
-
6 zeigt
ein Flussdiagramm der Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
zum Imple mentieren des Objektinformationen-Wiedererlangen-Blocks 404 (4).
Wie es in 6 angegeben ist, werden in diesem
Flussdiagramm Objektinformationen (OBJINFO) aus den decodierten
Ereignisdaten decodiert, die in der TLIST enthalten sind. Bei einem
Block 602 wird die TLIST gelesen. Der Block 602 tritt
zu einem Block 604 über,
der einen Ereigniszähler
einleitet. Der Zähler
bewirkt in Verbindung mit einer Schleife, dass alle der Ereignisse
innerhalb der TLIST bedient werden. In der Schleife wird bei einem
Block 606 eine einzige Aufzeichnung gelesen. Aus der Aufzeichnung
werden (a) ein Objektidentifizierer und (b) eine Objektveränderung
bestimmt. Die vorhergehenden Daten werden in einer Objektliste (OBJLIST)
platziert. Als nächstes
wird bei einem Block 608 der Zähler inkrementiert, so dass
eine andere Aufzeichnung der TLIST bedient wird, falls jegliche
verbleiben. Der Block 608 tritt zu einem Block 610 über. Bei
dem Block 610 wird durch ein Vergleichen des Aufzeichnungszählwerts
des Aufzeichnungszählers
mit der Gesamtanzahl von bereits verarbeiteten Aufzeichnungen bestimmt,
ob jegliche Ereignisse übrig
sind, die bedient werden sollen. Falls dem so ist, dann tritt der
Block 610 zurück
zu dem Block 606 über,
der beginnt, eine weitere Aufzeichnung zu bedienen. Falls nicht,
dann tritt der Block 610 zu einem Block 612 über, der
eine Anforderung nach einer Stapelübertragung von Objektinformationen,
die zu allen der Objekte innerhalb des Stapels gehören, zu
dem Topologieverwalter 310 sendet. 7 zeigt
ein Flussdiagramm der Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
des Abbildungsveränderungen-Berechnen-Blocks 406 (4).
Bei diesem Flussdiagramm bestimmt der Übersetzer, welche Teilabbildungen
(2) verändert
sind und die Veränderung,
die bewirkt werden soll, basierend auf den Objektidentifizierungen
und den Objektveränderungen,
die vorhergehend basierend auf den Ereignissen bestimmt wurden.
Mit Bezug auf 7 leitet ein Block 701 einen
Objektveränderungszähler ein, so
dass alle Objektveränderungen
betrachtet werden. Der Block 701 tritt zu einem Block 702 über. Der Block 702 bestimmt
einen Teilabbildungsidentifizierer basierend darauf, welche der
Teilabbildungen (2) durch die Objektveränderung
beeinflusst sind, um die es sich gegenwärtig handelt. Der Block 702 tritt
zu einem Block 704 über,
der bestimmt, ob die beeinflusste Teilabbildung existiert. Falls
die Teilabbildung existiert, dann tritt der Block 704 zu
dem Block 710 über.
Falls die Teilabbildung nicht existiert, dann tritt der Block 704 zu
dem Block 705 über.
Bei dem Block 705 wird eine Bestimmung vorgenommen, ob
die fragliche Teilabbildung basierend auf der Persistenzspezifikation
der vorliegenden Erfindung erzeugt werden sollte, d. h. ob die Teilabbildung
persistente Objekte enthält.
Die Persistenzspezifikation wird mit Bezug auf 15 – 18 hierin
im Folgenden ausführlicher
beschrieben (insbesondere 17 ist
ein Flussdiagramm, das die spezifische Architektur des Blocks 705 darstellt).
Falls die Teilabbildung nicht hinzugefügt werden soll, dann tritt
der Block 705 zu einem Block 716 über. Falls
die Teilabbildung hinzugefügt
werden soll, dann tritt der Block 705 zu einem Block 706 über, der
die beeinflusste Teilabbildung in der 200 (2)
erzeugt. Der Block 706 tritt zu einem Block 708 über.
-
Bei
dem Block 708 bestückt
der Übersetzer 318 die
neuerzeugte Teilabbildung mit Abbildungsdaten, die aus der Topologiedatenbank 326 wiedererlangt
werden. Bei dem Block 710 werden als nächstes Teilabbildungsveränderungen
basierend auf dem aktuellen Ereignis, insbesondere dem Objektidentifizierer
und der Objektveränderung,
berechnet. Diese Berechnungen des Blocks 710 werden hierin
im Folgenden mit Bezug auf 8 beschrieben.
Der Block 710 tritt zu einem Block 712 über, der
eine Bestimmung vornimmt, ob das fragliche Objekt die neuartige Persistenzspezifikation
einhält.
Die Persistenzspezifikation wird wiederum hierin im Folgenden mit
Bezug auf 15 – 18 ausführlicher
beschrieben (insbesondere ist 18 ein
Flussdiagramm, das die spezifische Architektur des Blocks 712 darstellt). Falls
das Objekt die Persistenzspezifikation einhält, dann tritt der Block 712 zu
einem Block 714 über,
der die fragliche Teil abbildung als persistent identifiziert, und
dann tritt der Block 714 zu einem Block 716 über. Falls
das Objekt die Persistenzspezifikation nicht einhält, dann
tritt der Block 712 zu dem Block 716 über.
-
Bei
dem Block 716 wird der Objektveränderungszähler inkrementiert, so dass
eine weitere Objektveränderung
mit Bezug auf die Teilabbildungen betrachtet wird. Der Block 716 tritt
zu einem Block 718 über,
der eine Bestimmung vornimmt, ob jegliche Objektveränderungen
verbleiben, um bedient zu werden. Falls dem so ist, dann tritt der
Block 718 zurück zu
dem Block 702 über.
Falls nicht, dann endet das Flussdiagramm nach dem Block 718.
-
Daher
wurde bei dem Abschluss der Operation der Logik in 7 ein
Stapel von Teilabbildungsidentifizierern mit zugeordneten Teilabbildungsveränderungen
aus einem Stapel von Objektidentifizierern mit zugeordneten Objektveränderungen
erzeugt.
-
Mit
Bezug auf 8 erlangt bezüglich der Teilabbildungsveränderungsberechnungen
von Block 710 (7) ein Block 804 Daten
wieder, die ein einziges Objekt aus der OBJLIST betreffen. Der Block 804 geht
zu einem Block 806 über,
der bestimmt, ob der Objekttyp ein Netzwerk ist. Falls dem so ist,
dann tritt der Block 806 zu einem Block 808 über (Flussdiagramm
in 9), der die Teilabbildungsveränderungen berechnet und dann
endet das Flussdiagramm. Falls nicht, dann tritt der Block 806 zu
dem Block 810 über.
-
Bei
dem Block 810 wird eine Bestimmung vorgenommen, ob der
Objekttyp ein Segment ist. Falls dem so ist, dann tritt der Block 810 zu
dem Block 812 über
(Flussdiagramm von 10), der die Segmentveränderungen
an den Teilabbildungen berechnet, und dann endet das Flussdiagramm.
Falls nicht, dann tritt der Block 810 zu dem Block 814 über.
-
Bei
dem Block 814 wird eine Bestimmung vorgenommen, ob der
Objekttyp ein Knoten ist. Falls dem so ist, dann tritt der Block 814 zu
dem Block 816 über
(Flussdiagramm von 11), der die Knotenveränderungen
für die
Teilabbildungen berechnet, und dann endet das Flussdiagramm. Falls
nicht, dann tritt der Block 816 zu dem Block 818 über.
-
Bei
dem Block 818 wird eine Bestimmung vorgenommen, ob der
Objekttyp eine Schnittstelle ist. Falls dem so ist, dann tritt der
Block 818 zu dem Block 820 über (Flussdiagramm von 12),
der die Schnittstellenveränderungen
an der Teilabbildung berechnet, und dann endet das Flussdiagramm.
Falls nicht, dann endet das Flussdiagramm.
-
9 zeigt
ein Flussdiagramm der Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
zum Implementieren des Netzwerkänderungsblocks 808 (8).
Dieses Flussdiagramm berechnet Veränderungen an der Internet-Teilabbildung 204 (2),
die die Netzwerke anzeigt. Außerdem
ist anzumerken, dass es bei dem bevorzugten Ausführungsbeispiel lediglich eine
einzige Teilabbildung (mehrere Teilabbildungen sind möglich) auf
der Internet-Ebene
gibt. Mit Bezug auf 9 wird bei einem Block 902 eine
Variable INET gesetzt, um die Inhalte der Internet-Teilabbildung 204 (2)
anzunehmen. Die Inhalte umfassen eine Liste von Netzwerkobjekten
und Router-Objekten und eine Liste von Verbindungen zwischen dem
Netzwerk und Router-Objekten. Der Block 902 tritt zu einem
Block 904 über.
Bei dem Block 904 wird eine Variable NETOBJ gesetzt, um
den Wert des Objektidentifizierers (OBJID) anzunehmen. Der OBJID
wird aus der OBJINFO wiedererlangt. Der Block 904 tritt
zu einem Block 906 über.
Bei dem Block 906 wird eine Bestimmung vorgenommen, ob
NETOBJ in INET ist, d. h. ob das Objekt, das verändert werden soll, innerhalb
der Internet-Teilabbildung 204 (2)
liegt. Falls dem so ist, dann tritt der Block 906 zu dem
Block 908 über,
der das Netzwerk, das zu dem NETOBJ gehört, zu einer Liste SYMCHANGELIST
hinzufügt.
Falls nicht, dann tritt der Block 906 zu dem Block 910 über, der
das Netzwerk, das zu der NETOBJ gehört, zu einer Liste NEWSYMLIST
hinzufügt.
Die Listen SYMCHANGELLIST und NEWSYMLIST werden schließlich während der
Stapelübertragung
zwischen denselben durch den Übersetzer 318 zu
der GUI 322 weitergeleitet.
-
10 zeigt
ein Flussdiagramm der Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
zum Implementieren des Segmentänderungsblocks 812 (8).
Bei diesem Flussdiagramm werden Segmentveränderungen bestimmt und berechnet.
Mit Bezug auf 10 setzt ein Block 1002 eine
Variable INET, um die Inhalte der Internet-Teilabbildung 204 (2)
anzunehmen. Die Inhalte umfassen eine Liste von Netzwerk- und Router-Objekten
und eine Liste von Verbindungen zwischen den Netzwerk- und den Router-Elementen. Der Block 1002 tritt
zu einem Block 1004 über.
Bei dem Block 1004 wird eine Variable SEGOBJ gesetzt, um
den aktuellen Objektidentifizierer (OBJID) anzunehmen, der aus den
Objektinformationen (OBJINFO) wiedererlangt wird. Der Block 1004 tritt
zu einem Block 1006 über.
Bei dem Block 1006 wird eine Variable NETOBJ zu dem identifizierten
Netzwerk (NETID) gesetzt, das aus den OBJINFO bestimmt wird. Der
Block 1006 tritt zu einem Block 1008 über. Bei dem
Block 1008 wird eine Bestimmung vorgenommen, ob NETOBJ
in INET ist, d. h. ob das aktuelle Netzwerk innerhalb der aktuellen
Internet-Teilabbildung 204 (2) ist.
Falls nicht, dann endet das Flussdiagramm von 10.
Falls dem so ist, dann tritt der Block 1008 zu einem Block 1010 über. Bei dem
Block 1010 wird eine Variable NET gesetzt, um die Inhalte
der Netzwerk-Teilabbildung 206 (2) anzunehmen,
die zu NETOBJ gehört.
Die Inhalte umfassen zum Beispiel, aber nicht darauf begrenzt, eine Liste
von Segment- und Verbinderobjekten und Verbindungen zwischen einem
Segment und Verbindern. Der Block 1010 tritt zu einem Block 1012 über. Bei
dem Block 1012 wird eine Bestimmung vorgenommen, ob SEGOBJ
in der NET ist (d. h. ist das Segment in der Netzwerk-Teilabbildung?).
Falls dem so ist, dann tritt der Block 1012 zu dem Block 1014 über, der
das Segment, das zu SEGOBJ gehört,
zu der SYMCHANGELIST hinzufügt.
Falls nicht, tritt andernfalls der Block 1012 zu dem Block 1016 über, der das
Segment, das zu SEGOBJ gehört,
zu NEWSYMLIST hinzufügt.
Schließlich
endet das Flussdiagramm von 10 nach
den Blöcken 1014, 1016 und
eine Operation tritt zurück
zu 8 über.
-
11 zeigt
ein Flussdiagramm der Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
zum Implementieren des Knotenveränderungsblocks 816 (8).
Bei dem Flussdiagramm von 11 werden
Knotenveränderungen durch
den Übersetzer 318 bestimmt
und berechnet. Wie es in 11 gezeigt
ist, setzt ein Block 1102 eine Variable INET, um die Inhalte
der Internet-Teilabbildung 202 (2) anzunehmen.
Die Inhalte umfassen eine Liste von Netzwerk- und Router-Objekten und
eine Liste von Verbindungen zwischen den Netzwerk- und Router-Elementen.
Der Block 1102 tritt zu einem Block 1104 über. Bei
dem Block 1104 wird eine Variable NODEOBJ gesetzt, um den
Objektidentifizierer (OBJID) anzunehmen, der in den Objektinformationen
(OBJINFO) enthalten ist. Der Block 1104 tritt zu einem
Block 1106 über.
Bei dem Block 1106 wird eine Variable SEGOBJ gesetzt, um
den Segmentidentifizierer (SEGID) anzunehmen, der innerhalb der
OBJINFO enthalten ist. Der Block 1106 tritt zu einem Block 1108 über. Bei
dem Block 1108 wird eine Variable NETOBJ gesetzt, um den
Netzwerkidentifizierer (NETID) anzunehmen, der innerhalb der OBJINFO
enthalten ist. Der Block 1108 tritt zu einem Block 1110 über. Bei
dem Block 1110 wird eine Bestimmung vorgenommen, ob NETOBJ
in INET ist (d. h. ist das Netzwerk in der Internet-Teilabbildung?). Falls
nicht, dann endet das Flussdiagramm. Falls dem so ist, dann tritt
der Block 1110 zu dem Block 1112 über. Bei
dem Block 1112 wird die Variable NET gesetzt, um die Inhalte
der Netzwerk-Teilabbildung 206 (2) anzunehmen,
die zu NETOBJ gehört. Die
Inhalte umfassen zum Beispiel, aber nicht darauf begrenzt, eine
Liste von Segmenten, Verbindern und Verbindungen zwischen Segmenten
und Verbindern. Der Block 1112 tritt zu einem Block 1114 über. Bei dem
Block 1114 wird eine Bestimmung vorgenommen, ob SEGOBJ
in NET ist. Falls nicht, dann endet das Flussdiagramm. Falls dem
so ist, dann tritt der Block 1114 zu dem Block 1116 über. Bei
dem Block 1116 wird die Variable SEG gesetzt, um die Inhalte der
Segment-Teilabbildung 208 (2) anzunehmen,
die zu SEGOBJ gehört.
Die Inhalte umfassen zum Beispiel, aber nicht darauf begrenzt, eine
Liste von Knoten und Verbindungen zwischen den Knoten und dem Netzwerk.
Der Block 1116 geht zu einem Block 1118 über. Bei
dem Block 1118 wird eine Bestimmung vorgenommen, ob NODEOBJ
in SEG ist, d. h. ob das Knotenobjekt in dem vorliegenden fraglichen
Segment ist. Falls dem so ist, dann tritt der Block 1118 zu
dem Block 1120 über,
der den Knoten, der zu NODEOBJ gehört, zu SYMCHANGELIST hinzufügt, und
dann endet das Flussdiagramm. Falls nicht, tritt andernfalls der
Block 1118 zu dem Block 1122 über, der den Knoten, der zu
NODEOBJ gehört, zu
NEWSYMLIST hinzufügt,
und dann endet das Flussdiagramm.
-
12A bis 12B zeigen
gemeinsam ein Flussdiagramm der Architektur und Funktionalität des bevorzugten
Ausführungsbeispiels
zum Implementieren des Schnittstellenveränderungsblocks 820 (8).
Bei diesem Flussdiagramm werden Schnittstellenveränderungen
in den Teilabbildungen durch den Übersetzer 318 (3)
bestimmt und berechnet. Mit Bezug auf 12A setzt
ein Block 1202 eine Variable INET, um die Inhalte der Internet-Teilabbildung 204 (2)
anzunehmen, um die es sich gegenwärtig handelt. Die Inhalte umfassen
eine Liste von Netzen, Routern und Verbindungsobjekten. Der Block 1202 tritt
zu einem Block 1204 über.
Bei dem Block 1204 wird eine Variable IFOBJ gesetzt, um
den OBJID anzunehmen, der innerhalb der OBJINFO enthalten ist. Der
Block 1204 tritt zu dem Block 1206 über. Bei
dem Block 1206 wird die Variable NODEOBJ gesetzt, um den
NODEID anzunehmen, der innerhalb der OBJINFO enthalten ist. Der
Block 1206 tritt zu einem Block 1208 über. Bei
dem Block 1208 wird die Variable SEGOBJ gesetzt, um den
SEGID anzunehmen, der innerhalb der OBJINFO enthalten ist. Der Block 1208 tritt
zu einem Block 1210 über.
Bei dem Block 1210 wird eine Variable NETOBJ gesetzt, um den
NETID anzunehmen, der innerhalb der OBJINFO enthalten ist. Nach
dem Block 1210 wurde der Initialisierungsprozess abgeschlossen
und der Block 1210 tritt zu einem Block 1212 über.
-
Bei
dem Block 1212 wird eine Bestimmung vorgenommen, ob NETOBJ
in INET ist, d. h. ob das Netzwerkobjekt in der aktuellen Internet-Teilabbildung 204 (2)
ist. Falls nicht, endet das Flussdiagramm, wie es in 12A gezeigt ist. Falls dem so ist, dann tritt
der Block 1212 zu einem Block 1214 über. Bei
dem Block 1214 wird eine Bestimmung vorgenommen, ob NODEOBJ
in INET ist, d. h. ob das Knotenobjekt in der Internet-Teilabbildung 204 (2)
ist. Falls nicht, dann tritt der Block 1214 zu dem Block 1222 über. Falls
dem so ist, dann tritt der Block 1214 zu dem Block 1216 über.
-
Bei
dem Block 1216 wird eine Bestimmung vorgenommen, ob IFOBJ
in INET ist. Falls dem so ist, dann tritt der Block 1216 zu
dem Block 1218 über,
der die Schnittstelle, die zu IFOBJ gehört, zu der SYMCHANGELIST hinzufügt. Falls
nicht, dann tritt der Block 1216 zu einem Block 1220 über, der
die Schnittstelle, die zu IFOBJ (zwischen Knotenobjekt und Netzwerkobjekt)
gehört,
zu NEWSYMLIST hinzufügt.
-
Bei
dem Block 1222 wird die Variable NET gesetzt, um die Inhalte
der Netzwerk-Teilabbildung 206 (2) anzunehmen.
Die Inhalte umfassen zum Beispiel, aber nicht darauf begrenzt, Segmente,
Verbinder, Verbindungen, etc. Der Block 1222 tritt zu einem
Block 1224 von 12B über.
-
Bei
dem Block 1224 wird eine Bestimmung vorgenommen, ob SEGOBJ
in NET ist, d. h. ob das Segmentobjekt innerhalb der Netzwerk-Teilabbildung 206 (2)
ist. Falls nicht, dann endet das Flussdiagramm. Falls dem so ist,
dann tritt der Block 1224 zu dem Block 1226 über.
-
Bei
dem Block 1226 wird eine Bestimmung vorgenommen, ob NODEOBJ
in NET ist, d. h. ob das Knotenobjekt innerhalb der Netzwerk-Teilabbildung 206 (2)
ist. Falls nicht, dann tritt das Flussdiagramm zu einem Block 1234 über. Falls
dem so ist, dann tritt der Block 1226 zu einem Block 1228 über.
-
Bei
dem Block 1228 wird eine Bestimmung vorgenommen, ob IFOBJ
innerhalb NET ist, d. h. ob das Schnittstellenobjekt innerhalb der
Netzwerk-Teilabbildung 206 (2) ist.
Falls dem so ist, dann tritt der Block 1228 zu dem Block 1230 über, der
die Schnittstelle, die zu IFOBJ gehört, zu SYMCHANGELIST hinzufügt. Falls
nicht, dann tritt der Block 1228 zu dem Block 1232 über, der
die Schnittstelle, die zu IFOBJ (die zwischen einem Knotenobjekt
und einem Segmentobjekt ist) gehört,
zu NEWSYMLIST hinzufügt.
Die Blöcke 1230, 1232 treten
zu dem Block 1234 über.
-
Bei
dem Block 1234 wird die Variable SEG gesetzt, um die Inhalte
der Segment-Teilabbildung 208 (2) anzunehmen.
Die Inhalte umfassen zum Beispiel, aber nicht begrenzt darauf, Knoten
und Verbindungen zu einem Netzwerk (Schnittstellen). Der Block 1234 tritt
zu einem Block 1236 über.
-
Bei
dem Block 1236 wird eine Bestimmung vorgenommen, ob NODEOBJ
in SEG ist, d. h. ob das Knotenobjekt innerhalb der Segment-Teilabbildung 208 (2)
ist. Falls nicht, dann tritt das Flussdiagramm zu einem weiteren
Block über.
Falls dem so ist, dann tritt der Block 1236 zu dem Block 1238 über.
-
Bei
dem Block 1238 wird eine Bestimmung vorgenommen, ob IFOBJ
innerhalb SEG ist, d. h. ob das Schnittstellenobjekt innerhalb der
Segment-Teilabbildung 208 (2) ist.
Falls dem so ist, dann tritt der Block 1238 zu dem Block 1248 über, der
die Schnittstelle, die zu IFOBJ gehört, zu SYMCHANGELIST hinzufügt. Falls
nicht, dann tritt der Block 1238 zu dem Block 1244 über, der
die Schnittstelle, die zu IFOBJ gehört, zu NEWSYMLIST hinzufügt. Die
Blöcke 1242, 1244 treten
zu dem weiteren Block über, bei
dem die Variable NODE gesetzt wird, um die Inhalte der Knoten-Teilabbildung 210 (2)
anzunehmen. Die Inhalte umfassen Schnittstellenobjekte. Dieser Block
tritt zu einem zweiten weiteren Block über.
-
Es
wird eine Bestimmung vorgenommen, ob IFOBJ innerhalb NODE ist, d.
h. ob das Schnittstellenobjekt innerhalb der Knoten-Teilabbildung 210 (2)
ist. Falls dem so ist, dann wird die Schnittstelle, die zu IFOBJ
gehört,
zu SYMCHANGELIST hinzugefügt.
Falls nicht, wird die Schnittstelle, die zu IFOBJ gehört, zu NEWSYMLIST
hinzugefügt.
Schließlich
endet das Flussdiagramm, das gemeinsam in 12A bis 12B enthalten ist.
-
13 zeigt
ein Flussdiagramm der Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
zum Implementieren des Abbildung-Aktualisieren-Blocks 408 (4).
Bei diesem Flussdiagramm wird eine Stapelübertragung von Veränderungen
durch den Übersetzer 318 zu
der GUI 322 gesendet. Mit Bezug auf 13 überträgt bei einem
Block 1302 der Übersetzer 318 die
NEWSYMLIST zu der GUI 322 und bei einem Block 1304 überträgt der Übersetzer 318 die
SYMCHANGELIST zu der GUI 322. Nach dem Block 1304 endet
das Flussdiagramm von 13 und die Operation geht zurück zu dem
Block 410 (4) über.
-
14 stellt
ein Auf-Anforderung-Teilabbildung-Modul dar, das innerhalb der GUI 322 (3) enthalten
ist. Dieses Flussdiagramm implementiert die Benutzerschnittstelle
zu den verschiedenen Teilabbildungen der 200 (2).
Mit Bezug auf 14 überwacht bei einem Block 1402 die
GUI 322 die Eingabegeräte,
die mit der Verwaltungsstation 100 (1) verbunden
sind, z. B. die Tastatur 106. Wenn der Benutzer der Verwaltungsstation 100 die Verwaltungsstation 100 über die
Tastatur 106 oder über
ein gewisses anderes Eingabegerät
auffordert, ein Objekt auf der Anzeige 108 explodieren
zu lassen, tritt der Block 1402 von
-
14 zu
dem Block 1404 über,
um die Benutzeranforderung zu verarbeiten. Bei dem Block 1404 wird
eine Bestimmung vorgenommen, ob die Tochter-Teilabbildung innerhalb
der 200 (2) enthalten
ist. Falls dem so ist, dann tritt der Block 1404 zu dem
Block 1408 über.
Falls nicht, dann tritt der Block 1404 zu dem Block 1406 über, der
die Teilabbildung erzeugt und bestückt. Die GUI 322 bestückt die
Teilabbildung durch ein Auffordern des Übersetzers 318, eine
Teilabbildung basierend auf Topologiedaten zu erzeugen und zu bestücken, die von
dem Topologieverwalter 310 wiedererlangt werden. Außerdem tritt
der Block 1406 zu dem Block 1408 über, der
die Tochter-Teilabbildung öffnet
und die Tochter-Teilabbildung auf der Anzeige 108 für den Benutzer
anzeigt.
-
Persistenzspezifikation
-
Das
Konzept von Auf-Anforderung-Teilabbildungen, wie dasselbe mit Bezug
auf 2 dargestellt und beschrieben ist, besteht darin,
lediglich diese Teilabbildungen in der 200 (2)
zu platzieren, die der Benutzer auf der Anzeige 108 (1) sehen
will. Bei der Implementierung des Persistenzspezifikationsmechanismus 103 (1)
hierin ist dieses Konzept erweitert, um Teilabbildungen zu umfassen,
die durch Integrationsanwendungen 332 (3)
benötigt
werden, die sich während
einer Operation dynamisch verändern
können.
Das Nettoergebnis ist, dass lediglich ein Abschnitt der Teilabbildungshierarchie
zu einer gegebenen Zeit in der 200 (2)
ist und die Informationen, die zu dem Benutzer geliefert werden,
wesentlich durch ein Ermöglichen
verbessert werden, dass Integrationsanwendungen 332 Gerätekonfigurations-Informationen
ergänzen,
die durch den Entdeckungsmechanismus 302 (3)
aus dem Netzwerk 118 entdeckt wurden.
-
Die
Persistenzspezifikation betrifft ein Definieren jeder Teilabbildung
der 200 (2) als entweder persistent
oder transient, wie es in dem Diagramm 1500 von 15 angegeben
ist. Gleichgültig
was durch die Persistenzspezifikation spezifiziert wird, hat der
Benutzer immer noch einen Zugriff auf die gesamte Topologie durch
die 200. Diese Teilabbildungen, die
als persistent bezeichnet sind, werden jedoch unmittelbar nach dieser
Bestimmung an der 200 platziert, und
diese Abbildungen, die als transient bezeichnet sind, werden lediglich
auf Anforderung nach einer Benutzeraufforderung erzeugt, und dann,
wenn der Benutzer die transiente Teilabbildung verlässt, wird
die transiente Teilabbildung von der 200 (2)
entfernt.
-
Die
Persistenzspezifikation ist nützlich,
wenn es eine Integrationsanwendung 332 (3)
gibt, die eng mit der Teilabbildungshierarchie integriert ist. Mit anderen
Worten ist dieselbe nützlich,
wo die Integrationsanwendung 332 davon abhängt, dass
der Übersetzer 318 bestimmte
Objekte in der 200 platziert, damit
die Integrationsanwendung 332 ordnungsgemäß wirksam
ist. Zum Beispiel kann eine Firma eine Integrationsanwendung 332 entwickelt haben,
die einem Router in einer Knoten-Teilabbildung ein Blob-Symbol hinzufügt und den
Status der Blobs benötigt,
um sich in der Teilabbildungshierarchie nach oben auszubreiten.
Folglich würde
die Integrationsanwendung 332 den Router benötigen, der in
der Persistenzspezifikation spezifiziert ist.
-
Um
die Persistenzspezifikation zu implementieren, wird ein Persistenzvektor 1600 von 16 jeder
der Teilabbildungen der 200 (2)
durch die GUI 322 (3) zugeordnet.
Der Persistenzvektor 1600 weist zahlreiche Persistenzbits
auf. Ein Persistenzbit bU entspricht dem
Benutzer des Computersystems 100 und wird durch die GUI 322 erzeugt.
Außerdem
ist ein Persistenzbit bA1...bAn vorgesehen, das
jeder der Integrationsanwendungen 332 (3) entspricht,
die der Entdeckungs-/Layout-Software 101 (1, 3)
zugeordnet ist. Damit eine Teilabbildung als transient betrachtet
wird, darf keines der persistenten Bits bU,
bA1...bAn in dem
Persistenzvektor 1600 aktiviert sein. Wenn umgekehrt ein
jegliches der Bits bU, bA1...bAn des Persistenzvektors 1600 aktiviert ist,
dann wird die jeweilige Teilabbildung als persistent betrachtet.
-
Unter
erneuter Bezugnahme auf das Zustandsdiagramm in 15 geht
eine Teilabbildung unter den folgenden Umständen von transient zu persistent über: (a)
der Benutzer oder eine Integrationsanwendung 332 nimmt
eine Veränderung
(z. B. ein Hinzufügen
einer Hintergrundgraphik, ein Bewegen eines Symbols, ein Verändern eines
Symboletiketts, ein Verändern
bei einem automatischen oder manuellen Layout oder ein Verstecken
eines Symbols) mit Bezug auf ein Objekt vor und die Veränderung
beeinflusst nichts, was in der Topologiedatenbank 314 gespeichert
ist; oder (b) eine Integrationsanwendung Ai aktiviert das entsprechende
Persistenzbit bAi derselben. Eine Teilabbildung ändert sich
von dem persistenten Zustand zu dem transienten Zustand, wenn eine
Integrationsanwendung das entsprechende Persistenzbit derselben
deaktiviert, falls dies darin resultiert, dass alle Persistenzbits
des Persistenzvektors 1600 deaktiviert werden. Folglich
kann somit ein Benutzer eine persistente Teilabbildung erzeugen,
während
eine Integrationsanwendung entweder eine persistente oder eine transiente
Teilabbildung erzeugen kann.
-
Man
rufe sich in Erinnerung, dass in 7 der Block 705 eine
Anfrage vornimmt, ob die fragliche Teilabbildung zu der 200 (2) hinzugefügt werden
sollte, basierend auf der Persistenzspezifikation. 17 ist
ein Flussdiagramm, das die Architektur und Funktionalität eines
bevorzugten Ausführungsbeispiels
des Blocks 705 darstellt. Wie es in 17 gezeigt
ist, wird bei einem Block 1702 eine Variable OBJINFO gesetzt,
um jeden der Objektidentifizierer innerhalb der Teilabbildung anzunehmen, und
jeder der Objektidentifizierer wird über einen Zähler betrachtet. Der Block 1702 tritt
zu einem Block 1704 über.
-
Bei
dem Block 1704 wird eine Bestimmung vorgenommen, ob das
spezielle fragliche Objekt die Persistenzspezifikation einhält. Falls
nicht, dann tritt der Block 1704 zu dem Block 712 (7) über. Falls dem
so ist, dann tritt der Block 1704 zu dem Block 1706 über, der
die Teilabbildung, die das Objekt enthält, als eine persistente Teilabbildung
durch ein Aktivieren des Persistenzbits (eines von bU,
bA1...bAn) definiert,
das der fraglichen Teilabbildung entspricht. Der Block 1706 tritt
dann zu dem Block 706 (7) über.
-
18 zeigt
ein Flussdiagramm zum Bestimmen, ob ein Objekt als entweder persistent
oder transient klassifiziert werden sollte, wie es in Block 712 (7)
und ebenfalls in Block 1704 (17) bestimmt
ist. Unter Bezugnahme auf 18 setzt
ein Block 1802 eine Variable FILTEREXPR, um eine Liste
von Feldern und Werten anzunehmen, die von dem Übersetzer 103 zu der
Integrationsanwendung 322 übertragen werden. Die Felder
und Werte sind im Wesentlichen Flags für die Integrationsanwendungen 332 und
identifizieren ergänzende
Informationen, die durch die Integrationsanwendungen 332 geliefert
werden können.
Ein Feld identifiziert einen gewissen Parameter eines Objekts (zum
Beispiel, aber nicht begrenzt auf, einen Verkäufer (Hersteller), einen Gerätetyp, eine
Adresse, eine Rate (z. B. Pakete/Sekunde), etc.). Der Wert ist einfach
ein Wert für dieses
Feld (zum Beispiel, aber nicht begrenzt auf, CISCO, Router, 15,
2.112.337, 55 Pakete/Sekunde, etc.). Also sind für ein Verkäuferfeld mögliche Werte z. B. Hewlett-Packard,
CISCO, International Business Machines (IBM), etc. Für einen
Gerätetyp
sind mögliche
Werte z. B. ein Router, ein Drucker, etc.
-
Ferner
tritt der Block 1802 zu einem Block 1804 über, der
einen Zähler
zum Zweck eines Betrachtens aller Paarungen von Feldern und Werten mit
Bezug auf das fragliche Objekt einleitet. Der Block 1804 tritt
in die Schleife über,
die bei einem Block 1806 beginnt.
-
Bei
dem Block 1806 wird eine Variable EXPR gesetzt, um ein
Feld und einen Wert anzunehmen. Der Block 1806 tritt zu
einem Block 1808 über,
der eine Variable EXPRVAL setzt, um den Wert (EXPR.VALUE) innerhalb
der Variablen EXPR anzunehmen. Der Block 1808 tritt zu
einem Block 1810 über.
-
Bei
dem Block 1810 wird eine Variable OBJVAL gesetzt, um den
Objektwert, der zu dem fraglichen Objekt gehört, innerhalb des speziellen
Felds (EXPR. FIELD) von EXPR anzunehmen. Der Block 1810 tritt
zu einem Block 1812 über.
-
Bei
dem Block 1812 wird OBJVAL mit EXPRVAL verglichen, d. h.
der Objektwert wird mit dem Integrationsanwendungswert oder Testwert
verglichen. Falls der Objektwert nicht mit dem Integrationsanwendungswert übereinstimmt,
dann hält
das Objekt die persistente Spezifikation nicht ein, wie es bei einem
Block 1814 angegeben ist, und das Flussdiagramm endet.
Falls der Objektwert jedoch mit allen der Integrationsanwendungswerte übereinstimmt, dann
wird das Objekt schließlich
bei einem Block 1820 persistent gemacht. Vor einem Erreichen
des Blocks 1820 jedoch tritt der Block 1812 zu
einem Block 1816 über,
der den Zähler
inkrementiert, der bei dem Block 1804 eingeleitet wird.
Außerdem
tritt der Block 1816 zu einem Block 1818 über, der
bestimmt, ob alle EXPRs betrachtet wurden. Falls einige verbleiben,
dann tritt der Block 1818 zurück zu dem Block 1806 über und
der vorhergehende Prozess geht weiter. Falls keine EXPRs mehr verbleiben, dann
tritt das Flussdiagramm zu dem Block 1820 über, der
das Objekt als die Persistenzspezifikation einhaltend spezifiziert,
und dann endet das Flussdiagramm.
-
Wenn
ein Objekt definitiv mit einem Feld-/Wert-Paar in Übereinstimmung
gebracht ist und als persistent bezeichnet ist, benachrichtigt der Übersetzer 103 die
GUI 322 über
diese Tatsache und dann informiert die GUI 322 die Integrationsanwendung 332 über die
Existenz des persistenten Objekts. Die GUI 322 wiederum
liefert ergänzende
Informationen, wie es durch einen Pfeil 333b angegeben
ist, die zu dem persistenten Objekt gehören und/oder auf demselben
basieren, zu der GUI 322 für eine Einbringung in die geeigneten
Teilabbildungen und für
eine Anzeige.