DE60109709T2

DE60109709T2 - Datenverwaltungsrahmenwerk für Verfahrensverwaltung

Info

Publication number: DE60109709T2
Application number: DE60109709T
Authority: DE
Inventors: Karl Apex Thiele
Original assignee: Alcatel SA
Current assignee: Alcatel Lucent SAS
Priority date: 2000-11-06
Filing date: 2001-11-05
Publication date: 2006-03-09
Anticipated expiration: 2021-11-06
Also published as: US20020069267A1; EP1204259B1; DE60109709D1; EP1204259A2; EP1204259A3; US7028307B2

Description

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.

Claims

Datenverwaltungsrahmenwerk für ein Datenübertragungsnetz, umfassend: einen Client (100) und einen Server (102), in welchem der Server (102) ein dynamisch aufgebautes Modell aus einem oder mehr Elementen des Datenübertragungsnetzes bereitstellt, wobei das Modell eine einheitliche Programmierschnittstelle bereitstellt, um dem Client (100) zu ermöglichen, dynamisch auf ein oder mehr Elemente zuzugreifen und dynamisch ein neues Element bei der Durchführung der Netzverwaltungsfunktionen hinzuzufügen, wobei der Server beinhaltet: mindestens einen Controller (110, 112, 114), der mit dem Client kommuniziert; einen Modellkontext (140) einen Verfahrenskontext (146), der mit einer Anwendungsprogrammierschnittstelle (148) für Verfahrenskontext verknüpft ist, die aus einem Modellkontext (140) abgeleitet ist, wo der Modellkontext beinhaltet: eine Modellkontextklasse, die standardmäßige Attribute, Verhaltensweisen und Assoziationen bereitstellt, einen Anwendungsdienst, der eine Anwendungsprogrammierschnittstelle aufweist, und ein verwaltetes Objekt, das betriebsfähig mit dem Anwendungsdienst verbunden ist, und ein verwaltetes Objektelement aufweist, dadurch gekennzeichnet, daß das verwaltete Objekt ein verfahrensverwaltetes Objekt (158) beinhaltet, das von einer Implementierung des verwalteten Objekts (156) abgeleitet ist, wobei die Implementierung des verwalteten Objektes die Charakteristika eines Elementes definiert, des einen oder mehr Elemente, das durch das verwaltete Objekt dargestellt wird und wobei die Implementierung des verwalteten Objektes (156) von dem verwalteten Objektelement abgeleitet ist, wobei das verwaltete Objektelement (154) standardmäßige Attribute, Verhaltensweisen und Assoziationen für das verwaltete Objekt bereitstellt.
Datenverwaltungsrahmenwerk nach Anspruch 1, wobei der Anwendungsdienst einen Verfahrensdienst (144) beinhaltet, der eine öffentliche Anwendungsprogrammierschnittstelle (150) und eine Verfahrensdatenbank (152) aufweist.
Datenverwaltungsrahmenwerk nach Anspruch 1, wobei das Modellobjekt angepaßt ist, um sich über eine Assoziationsklasse (160) zu verbinden; wobei die Assoziationsklasse Attribute aufweist, die Qualifikationen, Einschränkungen und Regeln der Assoziation zwischen einer Vielzahl von verwalteten Objekten beschreiben.
Datenverwaltungsrahmenwerk nach Anspruch 1, wobei der Anwendungsdienst einen Trägerdienst (40) aufruft, wobei der Trägerdienst aus einer Gruppe ausgewählt wird, die aus einer Datenbank (122) für reduziertes Directory-Zugriffsprotokoll, einem einfachen Netzverwaltungsprotokoll (124), einem Datenbank-Verwaltungsdienst (126), einem Fehlerbehandlungsdienst (128) und einem Dienst für automatische Auffindung besteht.
Datenverwaltungsrahmenwerk nach Anspruch 1, wobei der Anwendungsdienst ein Verfahrensverwaltungsdienst (115) ist.
Verfahren zur Datenverwaltung in einem Datenübertragungsnetz, wobei das Verfahren die Schritte umfaßt: Bereitstellen eines Client (100) und eines Servers (102), wobei der Server umfaßt: mindestens einen Controller (110, 112, 114), der mit dem Client (100) kommuniziert, und einen Modellkontext (140), der eine Modellkontextklasse aufweist, einen Anwendungsdienst, der eine Anwendungsprogrammierschnittstelle aufweist, und ein verwaltetes Objekt, das betriebsfähig mit dem Anwendungsdienst verbunden ist, und ein verwaltetes Objektelement (154) aufweist; und Bereitstellen, durch die Modellkontextklasse, standardmäßiger Attribute, Verhaltensweisen und Assoziationen; Ableiten aus dem Modellkontext eines Verhaltenskontextes, der mit einer Anwendungsprogrammierschnittstelle des Verhaltenskontextes verknüpft ist; Bereitstellen, durch den Server, eines dynamisch aufgebauten Modells von ein oder mehr Elementen des Datenübertragungsnetzes; Bereitstellen, durch das dynamisch aufgebaute Modell von Elementen, einer einheitlichen Programmierschnittstelle, um dem Client zu erlauben, Netzverwaltungsfunktionen durchzuführen, dynamisch auf ein oder mehr Elemente zuzugreifen und dynamisch ein neues Element hinzuzufügen, und gekennzeichnet durch die Schritte: Bereitstellen, durch das verwaltete Objektelement (154), standardmäßiger Attribute, Verhaltensweisen und Assoziationen für das verwaltete Objekt; Ableiten einer Implementierung (156) für das verwaltete Objekt aus dem verwalteten Objektelement; Ableiten eines verfahrensverwalteten Objektes (158) aus der Implementierung des verwalteten Objektes; und Erzeugen, durch die Implementierung (156) des verwalteten Objektes, der Charakteristika eines Elementes, die durch das verwaltete Objekt dargestellt werden, wobei das verwaltete Objekt das verfahrensverwaltete Objekt beinhaltet, das von der Implementierung des verwalteten Objektes (156) abgeleitet wurde.
Verfahren zur Datenverwaltung in einem Datenübertragungsnetz nach Anspruch 6, überdies umfassend den Schritt des dynamischen Hinzufügens eines neuen Anwendungsdienstes (142) zu dem Server über einen neuen Modellkontext (140).
Verfahren zur Datenverwaltung in einem Datenübertragungsnetz nach Anspruch 6, wobei der Anwendungsdienst (142) einen Verfahrensdienst (144) beinhaltet, der eine öffentliche Anwendungsprogrammierschnittstelle (150) und eine Verfahrensdatenbank (152) aufweist.
Verfahren zur Datenverwaltung in einem Datenübertragungsnetz nach Anspruch 6, wobei das Modellobjekt angepaßt ist, um sich über eine Assoziationsklasse zu verknüpfen; wobei die Assoziationsklasse Attribute aufweist, die Qualifikationen, Einschränkungen und Regeln der Assoziation zwischen einer Vielzahl von verwalteten Objekten beschreiben.
Verfahren zur Datenverwaltung in einem Datenübertragungsnetz nach Anspruch 6, wobei der Anwendungsdienst einen Trägerdienst aufruft, wobei der Trägerdienst aus einer Gruppe ausgewählt ist, die aus Datenbanken (122) für reduziertes Directory-Zugriffsprotokoll, einfachem Netzverwaltungsprotokoll (124), Datenbank-Verwaltungsdiensten (126), Fehlerbehandlung (128) und Dienst für automatisches Auffinden besteht.
Verfahren zur Datenverwaltung in einem Datenübertragungsnetz nach Anspruch 6, wobei der Anwendungsdienst ein Verfahrensverwaltungsdienst (115) ist.