-
Diese
Patentanmeldung betrifft im Allgemeinen Netzwerkverwaltungsrahmenwerke
und konkret ein Datenverwaltungsrahmenwerk, das ein Metamodell zum
Darstellen eines Netzwerkes und der Beziehungen zwischen Elementen
in dem Modell auf eine dynamische Weise bereitstellt.
-
Die
Verfahrensverwaltung ist die Anwendung von abstrakten Verfahrensweisen,
um die Dienste zu steuern, die von einem Netzwerk-Switch bereitgestellt
werden. Die Verfahrensweise ist die Verknüpfung von Bedingungen und Handlungen,
basierend auf den Attributen des Switches, die bestimmte Verhaltensweisen
in dem Switch erzwingen, die einen speziellen Dienst zur Folge haben.
-
Infolge
der Komplexität
und der Bereiche der Werte zum Switching der Attribute, um spezifische Dienste
durchzusetzen, müssen
die Switching-Attribute in einer Form organisiert werden, die effektiv
auf den Netzelementen unterstützt
werden kann, die im Lieferumfang der Dienste einbezogen sind. Obgleich Lösungen für ein Netzwerkverwaltungssystem (NMS)
im Stand der Technik vorhanden sind, welche für die Verfahrensverwaltung
verwendet werden könnten,
sind diese Lösungen
unerwünscht,
weil sie im Allgemeinen ihr Konzept des Netzwerkes in statistisch
aufgebaute virtuelle Informationsspeicher umsetzen, die als verwaltete
Informationsdatenbanken (MIB) bezeichnet werden. Diese Umsetzung
wird entweder durch Umsetzer, die eine Eingabe einer Modellierungssprache,
wie beispielsweise ASN.l (Abstract Syntax Notation One), übersetzen
oder durch manuelle Codierung aller statistisch eingegebenen Modellelemente,
Daten und Verhaltensweisen erreicht.
-
Vorhandene
Netzverwaltungsarchitekturen nutzen daher nicht die dynamische Belastung
von Elementdefinitionen und die Laufzeitabfrage von Typen, sie nutzen
im Allgemeinen auch keine beschreibenden Metadateninformationen,
um spezifische Verhaltensweisen und Konfiguration der auf Typisierungsinformationen
basierten Netzwerkmodellierung hervorzurufen. Außerdem binden gegenwärtige Architekturen
in der Regel die Netzverwaltung an die Typisierung des ganzen Rahmenwerkes
im Hinblick auf das Protokoll, erlauben dem Rahmenwerk und Modell
zum Beispiel ATM aber nicht IP, Trägersprache aber nicht Daten,
und IP/ATM-Enterprise aber nicht Träger-ATM/-Frame Relay darzustellen.
-
Entsprechend
besteht ein Bedarf an einem Netzwerkverwaltungsrahmenwerk, das ein
Metamodell zum Darstellen eines Netzwerkes und der Beziehungen zwischen
den Elementen in dem Modell auf eine dynamische Art bereitstellt.
Das Netzwerkverwaltungsrahmenwerk sollte Datendarstellung und Verhaltensweisen,
Topologiebeziehungen und Anwendungsdienste, einschließlich Verfahrensverwaltungsdienste
ermöglichen,
die dynamisch zu einem leicht zu handhabenden Modell eines Netzwerkes ohne
Einschränkungen
hinsichtlich Typisierung, Größe, Wachstum
und/oder Leistungsfähigkeit
zusammenzusetzen sind.
-
Der
Artikel "Telecommunications
services management with computational reflection, using COBRA und
JAVA" von Goncalves
et al., Telecommunications Symposium, 1998. ITS '98 Proceedings. SBT/IEEE International
Sao Paulo, Brazil 9-13 Aug. 1998, New York, NY, USA, IEEE, US, 9
August 1998 (1998-08-09),
pages 486 – 491,
XP010300833 ISBN: 0-7803-5030-8, offenbart ein Verwaltungsmodell
für Telekommunikationsdienste.
Das Modell ermöglicht Telekommunikationsunternehmen,
ihre Dienste mit der Informationstechnologie zu koppeln, das heißt sie mit
Internet- und Intranettechnologien in einer verteilten Umgebung
zu integrieren. Das offenbarte Modell berücksichtigt die notwendigen
Anforderungen für
die Hauptfunktionalitäten,
die in einer Telekommunikationsarchitektur zum Implementieren der
Telekommunikationsdienste mit der Wiederverwendbarkeit von Codes
unter Verwendung der rechentechnischen Reflexion vorgesehen sind.
Dieses Implementierungsverfahren weist eine Grundfunktion auf, um ein
Meta-Objekt aufzubauen, um zu überwachen,
wie andere Objekte auf Meldungen reagieren, ermöglicht den Eingriff in den
Rechenzustand. Dieser Eingriff ist das Wesentliche der dynamischen
reflektierenden Berechnung, die auf transparente Weise im Sinne des
Erfassens und des Registrierens der Informationen zum Zwecke der
Ausführung
durchgeführt
wird. Das ursprüngliche
Ziel besteht im Simulieren der Dienste, die von einem Telekommunikationsunternehmen
unter Verwendung des Internet angeboten werden, im Generieren leicht
zu handhabender Informationen, damit Informationen verfügbar werden,
so daß die
Verwaltungsfunktionalitäten
unter Verwendung der rechentechnischen Reflexionen implementiert
werden können.
-
EP-A-0
909 058 offenbart ein Netzwerkverwaltungsrahmenwerk für ein Netzverwaltungssystem,
das ermöglicht,
Verwaltungsdienste und Verwaltungsagenten in Gebrauch nach Bedarf
hinzuzufügen.
Verwaltungsdienste können
in das Rahmenwerk dynamisch geladen oder verbunden werden. Als eine Folge
kann eine Verwaltungsstruktur bereitgestellt werden, die skalierbar
und dynamisch ist und sich entwickeln kann, wenn sich die Anforderungen ändern. Verwaltungsinformationen
werden wie Verwaltungs-Beans modelliert. Netzverwaltungsadapter können ebenfalls
nach Bedarf zu dem Rahmenwerk zu den für den Port verschiedenen Protokollen
hinzugefügt
werden. Abgesetzte Anwendungen können auf
diese Weise die Verwaltungs-Beans entfernt über verschiedene Protokolle
steuern. Die Verwaltungsdienste werden vorzugsweise in der Form
von Objekten implementiert, die mit dem Rahmenwerk registrierbar
sind. Ein Beispiel eines Verwaltungsdienstes ist ein Repository-Dienst. Überdies
ist offenbart, ein Rechensystem bereitzustellen, das mit einem Telekommunikationsnetz
verbunden ist. Das Rechensystem beinhaltet einen Netzwerkagenten,
wobei der Netzwerkagent umfaßt:
ein erweiterbares Rahmenwerk, ein oder mehr verwaltete Objekte,
die mit dem Rahmenwerk registrierbar sind, und ein oder mehr Rahmenwerkadapter,
die mit dem Rahmenwerk registrierbar sind, für ein Netzkommunikationsprotokoll, um
den Zugriff auf die verwalteten Objekte zu ermöglichen.
-
EP-A-0
810 799 offenbart eine Anordnung, um Anrufleistungsmerkmale für "Plug-und-Plug" möglich zu
machen. Entsprechend diesem Dokument – eine Infrastruktur des Telekommunikationssystems,
die das mühlelose
Einfügen
von Leistungsmerkmal-Software in ein vorhandenes derartiges Telekommunikationssystem
und die mühelose
Integration der neuen Anrufleistungsmerkmale und ihrer Implementierungssoftware
mit vorhandenen Leistungsmerkmalen und ihrer Software ermöglicht.
Die Software zum Implementieren der Leistungsmerkmale weist eine
modulare Client-Server-Konfiguration
mit Leistungsmerkmalmanagern auf. Die Infrastruktur bietet einen
Kontextdienst und eine Kontext-API zum Registrieren einer Instanz
eines Leistungsmerkmalmanagers für
jeden Benutzer, nachdem dieser Benutzer die Berechtigung für dieses
Leistungsmerkmal bekommt, eine Verwaltungs-API für die Kommunikation zwischen
den Leistungsmerkmalmanagern und den Leistungsmerkmal-Verwaltungsagenten
am Endpunkt des Benutzers, um die Benutzer-Verfahrensweisen des
Benutzers für
den Benutzer individuell anzupassen, und eine Kontext-API. Die Kontext-API
dient zum Einbeziehen der Verfahrensweise des Benutzers von Benutzern,
die Teilnehmer an einem Anruf sind, in den Anruf und zum Übertragen
anrufrelevanter Ereignisse, um Server und andere Dienstimplementierungssoftware
zu charakterisieren.
-
Es
ist die Aufgabe der Erfindung, eine vorteilhafte Ausführungsform
einer Modellwahl eines Datenverwaltungsrahmenwerkes für ein Datenübertragungsnetz
und eines Verfahrens für
den Betrieb des Rahmenwerkes bereitzustellen.
-
Diese
Aufgabe wird durch die entsprechenden Gegenstände der Ansprüche 1 und
6 gelöst.
-
In
einer Ausführungsform
befaßt
sich die vorliegende Erfindung mit einem Datenverwaltungsrahmenwerk
für ein Datenübertragungsnetz,
das einen Client und einen Server in Verbindung mit dem Client beinhaltet.
Der Server stellt ein dynamisch aufgebautes Modell von Elementen
des Datenübertragungsnetzes
bereit. Das Modell stellt eine einheitliche Programmierschnittstelle
bereit, um dem Client zu ermöglichen,
dynamisch auf die Elemente zuzugreifen und dynamisch neue Elemente
beim Ausführen
der Netzverwaltungsfunktionen hinzuzufügen.
-
In
einer anderen Ausführungsform
befaßt sich
die vorliegende Erfindung mit einem Datenverwaltungsrahmenwerk für ein Datenübertragungsnetz,
wo das Datenverwaltungsrahmenwerk einen Anwendungsdienst beinhaltet,
der Anwendungsfunktionen für
das Netzwerk, ein Modellierungswerkzeug zum Generieren eines dynamischen
Modells von Elementen, die mit dem Anwendungsdienst verknüpft sind,
und eine einheitliche Programmierschnittstelle, die den dynamischen
Zugriff auf die Elemente zum Ausführen der Netzverwaltungsfunktionen
bietet, bereitstellt.
-
Diese
und andere Leistungsmerkmale, Aspekte und Vorteile der vorliegenden
Erfindung werden in Anbetracht der folgenden detaillierten Beschreibung,
beigefügten
Ansprüche
und beiliegenden Zeichnungen besser verstanden:
-
1 ist
ein schematisches Blockdiagramm der verschiedenen Schichten eines
Datenverwaltungsrahmenwerkes, das zum dynamischen Erzeugen eines
Netzinformationsmodells gemäß einer Ausführungsform
der Erfindung verwendet wird;
-
2 ist
ein Blockdiagramm von verschiedenen Komponenten und Modulen des
Datenverwaltungsrahmenwerkes von 1 gemäß einer
Ausführungsform
der Erfindung; und
-
3 ist
ein beispielhaftes objektorientiertes Diagramm eines Modellkontextes
gemäß einer
Ausführungsform
der Erfindung.
-
1 ist
ein schematisches Blockdiagramm von verschiedenen Schichten eines
Datenverwaltungsrahmenwerkes, das für das dynamische Erzeugen eines
Netzinformationsmodells gemäß einer Ausführungsform
der Erfindung verwendet wird. Auch wenn die Schichten des in 1 dargestellten Rahmenwerkes
in Form von verschiedenen Softwareschichten und/oder Komponenten
beschrieben sind, sollte ein Fachmann erkennen, daß eine oder mehr
Schichten des Rahmenwerkes ebenfalls in der Middleware implementiert
sein können.
-
Die
verschiedenen Schichten des Datenverwaltungsrahmenwerkes beinhalten
vorzugsweise eine Kommunikationssteuerungsschicht 10, Anwendungsdiensteschicht 20,
Informationsmodellschicht 30, Trägerdiensteschicht 40 und
eine Plattformschicht 50. Die Kommunikationssteuerungsschicht 10 stellt
vorzugsweise die Verbindung für
Softwaresysteme und/oder menschliche Benutzer (zusammen als Clients
bezeichnet) zum Zugreifen auf die Anwendungsdienste, Informationsmodelle
und/oder Trägerdienste
bereit, die durch entsprechend die Anwendungsdiensteschicht 20,
die Informationsmodellschicht 30 und/oder die Trägerdiensteschicht 40 bereitgestellt
werden. Vorzugsweise wird eine Verbindung über öffentliche Anwendungsprogrammierschnittstellen
(APIs) bereitgestellt, die über
CORBA (Common Object Request Broker Architecture), RMI (Remote Method
Indication) oder andere Fernschnittstellen und Transportprotokolle
implementiert sind, die im Stand der Technik herkömmlich sind.
Wenn eine Verbindung aufgebaut ist, wird vorzugsweise eine Sitzung
erzeugt. Sitzungen steuern vorzugsweise die Sicherheit und den Benutzerzugriff,
protokollieren Transaktionen, pflegen Verbindungsattribute, unterstützen die
Fehlerbeseitigung und dergleichen.
-
Die
Anwendungsdiensteschicht 20 beinhaltet Dienste, die die
Funktionalität
für Leistungsmerkmale
der Anwendung bereitstellen, wie beispielsweise die Verfahrensverwaltung.
Gemäß einer
Ausführungsform
der Erfindung können
Anwendungsdienste dynamisch hinzugefügt und mit den Leistungsmerkmalen
des Netzinformationsmodells sowie anderen durch das Rahmenwerk bereitgestellte
Diensten verknüpft
werden.
-
Die
Informationsmodellschicht 30 beinhaltet Informationsmodelle,
die verwendet werden, um die mit den Anwendungsdiensten verknüpften Datenmodelle
zu erzeugen. Solche Informationsmodelle können herkömmliche Modelle wie zum Beispiel
das Common Information Model (CIM), die Managed Information Base
(MIB) oder dergleichen enthalten. Die Informationsmodelle sind vorzugsweise
Container von Objektinstanzen, die gemeinsam das Modell der Informationen
und das Verhalten von realen Elementen in einem Verwaltungssystem
der realen Welt wie zum Beispiel einem Verfahrensverwaltungssystem modellieren.
-
Die
Trägerdiensteschicht 40 stellt
Unterstützungstechnologien
zum Implementieren der Softwarefunktionalität und Betriebssystemdienste
für das Datenverwaltungsrahmenwerk
bereit. Trägerdienste beinhalten
Protokollstacks, Datenbanken, World Wide Web, Graphik, Transaktionen,
Fehlererkennung/Fehlerbehandlung, Ressourcenverwaltung und/oder
dergleichen.
-
Die
Plattformschicht 50 beinhaltet vorzugsweise ein Softwarebetriebssystem
und zugehörige Hardware
zum Ausführen
der Anwendungsdienste in der Anwendungsdiensteschicht 20,
einschließlich Verfahrensverwaltung.
Das Softwarebetriebssystem ist vorzugsweise in der Programmiersprache
JAVA implementiert.
-
2 ist
ein Blockdiagram von verschiedenen Komponenten und Modulen des Datenverwaltungsrahmenwerkes
gemäß einer
Ausführungsform der
Erfindung. Das Datenverwaltungsrahmenwerk wird vorzugsweise durch
einen Server 102 in Verbindung mit einem Client 100 bereitgestellt.
Der Client 100 enthält
vorzugsweise Verbindungen von externer Software zu dem Server 102 über die
Kommunikationssteuerungsschicht 10. Solche Verbindungen
umfassen grafische Benutzerschnittstellen (GUIs) 104, Web-Verbindungen 106,
andere Anwendungs-/Verwaltungssysteme 108 und dergleichen.
-
Der
Server 102 stellt vorzugsweise die Kommunikationssteuerungsschicht 10,
die Anwendungsdiensteschicht 20, die Informationsmodellschicht 30 und
die Trägerdiensteschicht 40 von 1 bereit. Der
Server 102 kann sich in einem Prozessor-/Computersystem
oder in mehreren Prozessor-/Computersystemen befinden. Außerdem kann
innerhalb der Umgebung eines einzelnen Computers der Server 102 eine
oder mehr virtuelle Maschinen für
Java enthalten.
-
Der
Server 102 stellt vorzugsweise verschiedene Controller 110, 112, 114 innerhalb
der Kommunikationssteuerungsschicht 10 bereit, wo jeder
Controller eine Verbindung zu dem Client 100 steuert. Die Controller
können
den Benutzerzugriff, das Benutzerprofil, die Transaktionsprüfung und
dergleichen steuern.
-
Der
Server 102 stellt überdies
einen oder mehr Anwendungsdienste in der Anwendungsdiensteschicht 20 bereit,
wie zum Beispiel einen Verfahrensdienst 115 und andere
Dienste 117, die in einem Datenübertragungsnetz üblich sind.
Die Elemente jedes Anwendungsdienstes werden vorzugsweise als Objektinstanzen
dargestellt, die selbstbeschreibend sind. Die Objektinstanzen werden
als verwaltete Objekte (MO) 120, 121 bezeichnet.
-
Ein
Softwarebus 132, 134 ermöglicht das Verbinden von verschiedenen
MO miteinander und mit dem entsprechenden Anwendungsdienst. Der Softwarebus
kann zum Beispiel unter Verwendung der von Lotus entwickelten InfoBus-Technologie
implementiert sein.
-
Jedes
MO ist vorzugsweise eine Objektinstanz, die unter Verwendung objektorientierter
Programmierverfahren implementiert wurde, die eine Definition (Klasse),
Namen, Attribute und Beziehungen mit einer oder mehr MO beinhaltet.
Die Beziehung zwischen einem oder mehr MO wird als eine Assoziation
bezeichnet. Assoziationen können benannt/identifiziert
werden und Bedingungen, Beschränkungen
und andere Formen oder Attribute enthalten, die eine Beziehung zwischen
den MO beschreiben. In dem Beispiel der Verfahrensverwaltung modellieren
die MO vorzugsweise verschiedene Verfahrensweisen, Aktionen, Bedingungen,
Netzelemente, Directory-Server und andere durch eine Verfahrensweise
gesteuerte Ausrüstungen
und Software in einem Netzwerk.
-
Die
mit einem speziellen Anwendungsdienst verknüpften MO gehören zu einem
Datenmodell 116, 118, das unter Verwendung der
Informationsmodelle in der Informationsmodellschicht 30 aufgebaut
wurde. Jedes Datenmodell 116, 118 stellt Kontext
bereit oder enthält
eine Umgebung, in welcher sich die MO befinden und innerhalb der
Softwaresysteme und externen Systeme wechselwirken. Die Datenmodelle werden
auch als Modellkontexte bezeichnet.
-
Jeder
Modellkontext hat eine anwendungsspezifische Funktionalität und Dienst.
Jeder Modellkontext ermöglicht
die Steuerung und die Wechselwirkung über die Objekte innerhalb des
Containers. Ein neuer Modellkontext, der eingeführt oder gestartet wurde, kann
andere Modellkontexte auffinden und die Leistungsmerkmale des Netzwerkes
erweitern. Die Modellkontexte geben die Existenz der Inhalte bekannt,
veröffentlichen
Attribute und Verhalten und steuern den Zugriff. In dieser Hinsicht
stellt jeder Modellkontext eine einheitliche API für den Client 100 zum
Wechselwirken mit dem Modellkontext auf eine dynamische Weise bereit.
Die Strecke des Netzwerkes zum Rahmenwerk kann somit auf eine dynamische
Weise beschrieben werden, ohne statische Spracheinschränkungen
oder das Anhalten der Verarbeitung.
-
Vorzugsweise
exportiert jeder Modellkontext das Verhalten als eine Kombination
der öffentlichen API
des Kontextes, des Namendienstes des Kontextes, der API der Anwendungsdienste
und aller öffentlich
exportierten Attribute oder Verhaltensweisen der MO. Ein Kontext
muß in
der Lage sein, seine Attribute, Aktionen und Dienste sowie diejenigen
seiner Nachkommen bekanntzugeben. Wenn einmal bekanntgegeben, können andere
Komponenten die bekanntgegebenen Informationen nutzen.
-
Jeder
Modellkontext 116, 118, der das Netzinformationsmodell
bildet, kann unabhängig
oder gemeinsam mit anderen Modellkontexten ausgeführt werden.
Auf diese Weise kann das ganze Netzinformationsmodell aus einzelnen
Modellen aufgebaut sein, die dezentralisiert sind, die Skalierbarkeit
und Verfügbarkeit
für die
Netzverwaltungslösung
bereitstellen.
-
Die
Anwendungsdienste, die von den Modellkontexten 116, 118 umgeben
sind, nutzen vorzugsweise die Trägerdienste
in der Trägerdiensteschicht 40 beim
Durchführen
ihrer Funktionen. Die Trägerdienste
implementieren vorzugsweise die Funktionalität, die von einem oder mehr
Anwendungsdiensten gemeinsam genutzt wird. Für die Verfahrensverwaltung
können
die Trägerdienste
Datenbanken 122 für
das reduzierte Directory-Zugriffsprotokoll (LDAP), SNMP 124,
Datenbank-Verwaltungsdienste 126, Fehlerbehandlung 128 und
andere Dienste 130 wie zum Beispiel automatisches Auffinden
und dergleichen beinhalten.
-
3 ist
ein beispielhaftes objektorientiertes Schema eines Modellkontextes
gemäß einer
Ausführungsform
der Erfindung. Gemäß einer
Ausführungsform
der Erfindung sind der Modellkontext und seine verknüpften Komponenten
und Klassen auf der Basis der von der Sun Microsystems, Inc. entwickelten
BeanContext-API implementiert. BeanContext ist ein Modell, welches
eine einheitliche API für
den Zugriff und die Verwendung einer Hierarchie von Containerklassen
und ihren Nachkommen bereitstellt.
-
Ein
spezieller Modellkontext beinhaltet vorzugsweise eine Basisklasse,
die als eine Modellkontextklasse 140 bezeichnet wird. Die
Modellkontextklasse stellt vorzugsweise standardmäßige Attribute, Verhaltensweisen
und Assoziationen für
einen Modellkontext bereit. Die Modellkontexte enthalten einen oder
mehr Anwendungsdienste 142, wie zum Beispiel einen Verfahrensdienst 144,
der eine öffentliche
API 150 und einen Verfahrensdatenbus 152 umfaßt. Ein
Verfahrensmodellkontext 146 ist aus der Modellkontextklasse 140 abgeleitet.
Der Verfahrenskontext 146 ist mit der öffentlichen API 148 des
Kontextes verbunden.
-
Modellkontexte
enthalten Informationen und Verhaltensweisen, die von MO dargestellt
werden. Die MO beinhalten vorzugsweise eine Basisklasse, die als
eine Klasse 154 für
verwaltete Objektelemente (MOE) und eine Klasse 156 für verwaltete
Objektimplementierung (MOD) bezeichnet wird. Die MOE Klasse 154 stellt
vorzugsweise standardmäßige Attribute,
Verhaltensweisen und Assoziationen für ein MO bereit. Die MOI Klasse 156 beschreibt
vorzugsweise, wie ein MO implementiert wird. Zum Beispiel definiert
die MOI Klasse 156 die Schnittstelle und Attribute, die
verwendet werden, um die Dienste, die von dem MO angeboten werden,
oder die Charakteristika des Elements, die durch das MO dargestellt werden,
zu beschreiben. Eine Verfahrensweise MO 158 wird vorzugsweise
aus der MOI-Klasse abgeleitet.
-
Ein
MO kann in nur einem Modellkontext erzeugt werden und sich dort
befinden. Das MO kann Assoziationen mit anderen MO aufweisen, die
sich im gleichen oder verschiedenen Modellkontext befinden. Ein
MO wird vorzugsweise außerhalb
des Kontextes über
einen Namensdienst oder einen Anwendungsdienst unter Verwendung
der API des Anwendungsdienstes öffentlich
gemacht.
-
Eine
Assoziationsklasse 160 drückt vorzugsweise eine Beziehung
zwischen zwei oder mehr MO aus. Die Assoziationsklasse 160 beinhaltet
vorzugsweise Attribute, die die Qualifikation, Einschränkungen,
Regeln einer Assoziation zwischen zwei oder mehr MO beschreiben,
die anderen Komponenten und Tools ermöglichen, auf der Basis dieser
Informationen zu arbeiten.