DE69914952T2

DE69914952T2 - Verfahren und vorrichtung zum verteilen von dienstmodulen auf verteilte dienstknoten in einem intelligenten netz

Info

Publication number: DE69914952T2
Application number: DE69914952T
Authority: DE
Inventors: Andrew Dugan; Terrence Robb; Allen Holmes; Ajay Deo
Original assignee: Holmes Allen Colorado Springs; Worldcom Inc
Current assignee: Holmes Allen Colorado Springs; Verizon Business Global LLC
Priority date: 1998-10-20
Filing date: 1999-10-20
Publication date: 2004-12-23
Anticipated expiration: 2019-10-21
Also published as: CN1336068A; AU6522099A; DE69914952D1; HK1039009A1; ATE248401T1; HK1044249A1; HK1039009B; WO2000024182A9; AU773432B2; AU770505B2; IL142663A0; DE69921169T2; MXPA01003975A; ATE279831T1; EP1123618B1; BR9914647A; AU1129100A; AU1215200A; HK1044652A1; EP1157529A4

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf intelligente Netze und im Speziellen auf ein neuartiges Verwaltungssystem für die Verteilung von Servicepaketen und Komponenten inklusive ausführbarer Programme und Daten auf Serviceknoten, die für die Serviceverarbeitung in einem verteilten intelligenten Netzwerk geeignet sind.
Im Allgemeinen dient ein Kommunikationsnetzwerk dem Transport von Informationen zwischen einer Anzahl von Standorten. Ein kommerzielles Kommunikationsnetzwerk, so wie das öffentliche Telefonnetz, gehört einem Dienstanbieter und generiert für diesen Einkommen. Abonnenten bezahlen den Dienstanbieter für den Zugang zu den Kommunikationsdienstleistungen, die von dem Netzwerk bereitgestellt werden. Es gibt eine Vielzahl von Transport-Technologien, die in Kommunikationsnetzwerken benutzt werden, und eine Vielzahl von Informationstypen und -formaten, die gemeinhin transportiert werden.
In seiner einfachsten Form ist ein Kommunikationsservice mit einem Echtzeit-Transport von Informationen verbunden, so wie Daten oder Sprachsignalen zwischen Standorten, die von dem Netzwerk bedient werden. In einem kommerziellen Telefonnetz läuft dieser Grundservice typischerweise auf das Aufbauen eines Zwei-Wege-Sprachkanals zwischen einem Paar von Telefonservice-Abonnenten hinaus.
Über grundlegende Kommunikationsverbindungen hinaus können fortgeschrittene Services von einigen Netzwerken angeboten werden. Zum Beispiel kann ein Telefonnetz fortgeschrittene Fähigkeiten wie Anrufweiterleitung oder Voicemail bereitstellen. Um auf diese Fähigkeiten zuzugreifen oder sie aufzurufen, interagiert der Abonnent üblicherweise mit dem Netzwerk in irgendeiner Weise, so wie durch das Drücken einer Tastensequenz auf einer Te lefontastatur. Durch diese Interaktion führt das Netzwerk die gewünschten Funktionen auf Anforderung von jedem Benutzer oder Abonnent aus.
Benutzeraktionen, wie das Abheben des Hörers eines Telefonapparats oder das Drücken von Tasten auf einer Telefontastatur sind Ereignisse, die von dem Kommunikationsnetzwerk wahrgenommen werden. Andere Ereignisse, wie Fehlermeldungen der Gerätschaft, können durch das Netzwerk intern während seines Betriebs erzeugt werden. Die Intelligenz, die das Netzwerk in welcher Form auch immer steuert, muss diese Ereignisse empfangen und verarbeiten und Netzwerkverkehr-Behandlungselemente anweisen, geeignete Aktionen zum Bereitstellen von Services und zum Erholen von teilweisen Netzwerkausfällen zu ergreifen.
Auch wenn ein Telefonnetz als weithin verstandenes Beispiel im vorliegenden Kontext dient, wird der Fachmann erkennen, dass andere Netzwerktypen auf analoge Weise zum Bereitstellen von Services entwickelt und betrieben werden können. Zum Beispiel kann ein Datennetzwerk dazu benutzt werden, Informationen zu transportieren, die Daten, Dateien oder Video- und Audiodaten-Streams repräsentieren. Beispiele von erweiterten Services in einem Datennnetzwerk schließen Datenspeicher- und -weiterleitungs- und Multicastfähigkeiten ein. Andere Typen von Netzwerkservices können darauf gerichtet sein, einen Netzwerkeigner in Sicherheits-, Validierungs- und Authentisierungsfragen von Benutzern und Netzwerkadministratoren zu unterstützen.
Typische Telekommunikationsnetzwerke umfassen durch Kommunikationsverbindungen verbundene Knoten. Jeder Knoten ist ein Standort, der typischerweise Ausrüstung umfasst, wie einen Ortsbereich- oder Zeitbereich-Switch oder einen Paketvermittlungs-Router, die dazu benutzt wird, den Informationsfluss zu leiten. Viele Knoten stellen auch Ausrüstungen bereit, die eine Schnittstelle für Benutzer des Netzwerkes haben. Knoten sind durch Übertragungsverbindungen verbunden, so dass Informationen von Knoten zu Knoten fließen können und dadurch von einem Herkunftsknoten zu einem Zielknoten durch das Netzwerk reisen können. Vermittlungsausrüstung, Router und andere Ausrüstung an dem Knoten in einem Netzwerk müssen richtig koordiniert sein, um zu gewährleisten, dass Informationsfluss und andere Services zur Zufriedenstellung der Bedürfnisse der Netzwerkbenutzer bereitgestellt werden.
Die Switches innerhalb der Knoten eines typischen Telefonnetzes werden durch integrierte oder eingebettete Prozessoren gesteuert, die durch proprietäre Software oder Firmware betrieben werden, welche von jedem Switch-Hersteller unterhalten wird. Hinzufügen oder Ändern eines Services erfordert Änderungen, die in der Software, die ein Kommunikationsnetzwerk steuert, gemacht werden müssen. Traditionellerweise stellt die Software oder Firmware eines Switch-Herstellers einige oder alle der Serviceverarbeitungs-Funktionen oder andere Typen von netzwerkbezogener Verarbeitung zur Verfügung. Das bedeutet, dass, wenn ein Netzwerkeigner wünscht, einen neuen Service zu implementieren oder einen bestehenden Service zu ändern, die Software von jedem Switch in dem Netz durch die verschiedenen Switch-Hersteller revidiert werden muss.
Die Tatsache, dass ein großes Netzwerk üblicherweise eine Vielfalt von Switches verschiedener Hersteller enthält, erfordert vorsichtiges Entwickeln, Testen und Einsetzen der neuen Software vor Freigabe in einem aktiven, mit Netzverkehr beaufschlagten Netzwerk. Die Zeit, die zum Entwickeln, Testen und Einsetzen der neuen Software benötigt wird, wird verlängert, weil die Codegröße mit jeder neuen Revision an jedem Switch wächst und komplizierter wird. Aus diesem Grund können Code-Änderungen viele Monate bis zur Implementierung dauern. Darüber hinaus belastet die erhöhte Komplexität zusätzlich die Switch-Prozessoren, erhöht die Wahrscheinlich von Switch-Fehlfunktionen und kann sogar die Modifikation oder den Austausch antiquierter Switch-Hardware erfordern.
Weiterhin erfordert eine neue Fähigkeit oder Funktion manchmal eine Änderung in einem grundlegenden Betriebsmodell oder einer Schnittstelle, die innerhalb der Kommunikationsindustrie standardisiert ist. Änderungen dieser Größenordnung können die Ratifikation durch Industriestandardgruppen nötig machen- ein Prozess, der die Einführung einer neuen Fähigkeit um mehrere Jahre verzögern kann.
Weitere Nachteile existieren bezüglich des Vertrauens in proprietäre Software-Komponenten in den Produkten von verschiedenen Switch-Anbietern. Die Tatsache, dass mehrere Netzwerkeigner von einer üblichen Menge von Switch-Herstellern abhängen, resultiert in unerwünschten Situationen, die den Wettbewerb beschränken. Der Software-Release eines Herstellers kann versuchen, die von mehreren Netzwerkeignern angeforderten Änderungen umzusetzen, wodurch die Netzwerkeigner gehindert werden, ihre Services von den durch ihre Wettbewerber bereitgestellten Services zu differenzieren. Auch zwingt dies einige Netzwerkeigner, auf eine gewünschte neue Fähigkeit zu warten, während der Hersteller Forderungen anderer Netzwerkeigner in die neue Release aufnimmt. Weiterhin kann eine Switch-Software-Release, die eine Funktion enthält, wie sie durch einen Netzwerkeigner zur Implementierung eines neues Services bestellt wurde, unbeabsichtigterweise anderen Netzwerkeignern zugänglich werden.
Diese Probleme wurden unerträglich, da die Nachfrage nach neuen Netzwerkdiensten sich in den letzten fünf bis zehn Jahren aufgrund erhöhter Abonnenten-Mobilität, erhöhter Vielfalt und Bandbreite des Netzverkehrs, Auflösung traditioneller Nummernpläne, Einsatz raffinierterer Services und erhöhten Wettbewerbs unter Service-Providern exponentiell erhöht hat. Somit ist allgemein erkannt worden, dass neue Netzwerk-Steuerungsarchitekturen eine flexiblere Möglichkeit zur Erzeugung, Verteilung und Ausführung von Service-Logik enthalten müssen. Solch eine Architektur ist in WO 9523483 beschrieben.
Eine neue, mit „IDNA" bezeichnete Netzwerk-Steuerungsarchitektur unterscheidet sich vom Stand der Technik in wenigstens drei wichtigen Aspekten. Erstens ist die Serviceverarbeitung vollständig von einzelnen Netzwerkverkehr beaufschlagten Elementen wie Switches und Routern entfernt. Dies beseitigt die Abhängigkeit von Servicefunktionen von proprietärer Switch- residenter Software. Zweitens findet Serviceverarbeitung in einer „virtuellen Maschine" Verarbeitungsumgebung statt, und Verarbeitungsfunktionalität existiert in Form von verwalteten Objekten innerhalb dieser Umgebung. Schließlich wird eine vereinheitlichte Plattform für Service-Erzeugung, Service-Test und Service-Verteilung und Serviceverarbeitung eingeführt, die viele wesentliche Vorteile bietet.
Der Ausdruck „Ressourcenkomplex" beschreibt die Ansammlung von Netzwerkkomponenten, die durch ein Steuerungssystem für ein intelligentes Netzwerk gesteuert werden müssen, um Services für Benutzer zu implementieren. Der Ressourcenkomplex umfasst im Allgemeinen Switches, Übertragungsausrüstung und dergleichen, die Informationsverkehr direkt handhaben und durch das Netzwerk routen. Der Ressourcenkomplex kann auch sogenannte spezielle Ressourcen, wie automatische Sprachantwortsysteme, Voicemailsysteme, Echounterdrückung, Datenspeicherungsvorrichtungen und Datenkonvertierungskomponenten, um einige zu nennen, umfassen.
Im Zusammenhang mit einem Netzwerk, das Services als verwaltete Objekte innerhalb eines Service-Prozessors implementiert, wird weiterhin ein Mittel zur Koordinierung der Verteilung von verwalteten Objekten und anderen Komponenten an Serviceprozessoren gewünscht, um somit neue Services ohne Beeinträchtigung der Zuverlässigkeit des Netzwerkes zu implementieren. Solch eine Koordinierung kann zum Beispiel eine Überprüfung der gegenseitigen Abhängigkeiten unter Softwareelementen, die in jedem Service-Prozessor anwesend sein müssen, nach sich ziehen.
Des weiteren wird, sobald eine Service-Funktion an verschiedene Serviceprozessoren verteilt ist, irgendein Mittel zur Synchronisierung und sonstigen Koordinierung der Aktivierung von neuen Services benötigt, so dass zum Zeitpunkt der Aktivierung eine adäquate Anzahl von Serviceprozessoren ausgestattet ist, um kooperativ den neuen Service zur Verfügung zu stellen. Auf ähnliche Weise wird ein Mittel gewünscht zur Koordinierung der Deaktivierung von Service-Verarbeitungskomponenten ohne den Betrieb des Netzwerkes zu beeinträchtigen.
Es kann auch gewünscht sein, Servicefunktionalität an bestimmte Serviceprozessoren zu verteilen auf der Grundlage von zum Beispiel Hardware-Fähigkeiten an bestimmten Standorten oder von eigenen, von den Netzwerkingenieuren aufgestellten Regeln oder Kriterien. Solche Regeln oder Kriterien können einen Lastausgleich erreichen oder die Verarbeitung an einem bevorzugten Standort („homing") unter Serviceprozessoren.
Wo eine Service-Erzeugungsumgebung mit einer Service-Verteilungs- und Service-Verarbeitungsumgebung verknüpft ist, wird irgendein Mittel gewünscht, um die Gültigkeit von Service-Komponenten sicher zu stellen. Zum Beispiel ist irgendein Mittel gewünscht zum Bereitstellen von sowohl Zugriffssicherheit als auch Versionskontrolle von verwalteten Objekten, um die Integrität der Service-Komponenten zu schützen. Weiterhin wird, während des Verteilens von Service-Komponenten als verwaltete „Objekte", irgendein Mittel gewünscht, um sicher zu stellen, dass eine korrekte Version eines jeden verwalteten Objektes verteilt wird, selbst wenn mehrere Versionen einer gegebenen Komponente in dem System zu einem Zeitpunkt existieren können. Dies ist besonders wichtig, weil ältere Versionen von verwalteten Objekten wahrscheinlich für back-up- und Regressionszwecke behalten werden, und weil neuere, nicht freigegebene Versionen auch in der Erzeugungs- und Verteilungsumgebung gespeichert werden, während sie entwickelt und getestet werden.
Die vorliegende Erfindung betrifft ein Kommunikationssystem, das einen Serviceadministrator umfasst, der die Verteilung von verwalteten Objekten unter Service-Verarbeitungsknoten steuert. Der Serviceadministrator unterhält ein Repository, das als „globale Datenbank von Datensätzen" (DBOR) bekannt ist, worin Servicefunktionen als verwaltete Objekte gespeichert sind. Der Serviceadministrator ist für die Namensgebung, das Katalogisieren, die Verteilung, das Aktivieren, die Prüfung, das Deaktivieren und das Entfernen von allen zur Serviceverarbeitung verwalteten Objekten und benutzter Daten in einem Netzwerk verantwortlich.
In einer bevorzugten beispielhaften Ausführungsform umfasst das Kommunikationsnetzwerk gemäß der vorliegenden Erfindung weiterhin eine Service-Erzeugungsumgebung, wo verwaltete Objekte entwickelt und getestet werden können. Die Service-Erzeugungsumgebung ist an das Netzwerk über den Serviceadministrator angekoppelt. Der Serviceadministrator stellt sowohl Zugangssicherheit als auch Versionskontrolle für die verwalteten Objekte, die in der Datenbank der Datensätze gespeichert sind, bereit. Service-Erzeugung wird durch Holen von verwalteten Objekten aus der DBOR mittels des Serviceadministrators durchgeführt. Verwaltete Objekte, die in der Service-Erzeugungsumgebung neu erzeugt oder modifiziert werden, werden ebenfalls dem Serviceadministrator zur Speicherung in der DBOR übergeben.
In einer weiteren bevorzugten beispielhaften Ausführungsform werden die verwalteten Objekte, die an jeden Service-Verarbeitungsknoten verteilt werden, in einer lokalen Datenbank von Datensätzen an jedem Knoten gehalten. Die lokale Datenbank von Datensätzen an jedem Service-Verarbeitungsknoten ist ein Auszug aus der globalen DBOR, die von der Netzwerk-Service-Verwaltungskomponente unterhalten wird.
In noch einer weiteren bevorzugten beispielhaften Ausführungsform wird die lokale Datenbank von Datensätzen an jedem Service-Verarbeitungsknoten von wenigstens einer Datenmanagement-Komponente unterhalten. Die Datenmanagement-Komponente macht verwaltete Objekte und andere Daten für Serviceprozessoren am Service-Verarbeitungsknoten verfügbar. Insbesondere dient die Datenmanagement-Komponente als ständiges Lager für ver waltete Objekte, Betriebsdaten wie Nachbarknoten-Verbindungsinformationen, und andere, während der Serviceverarbeitung erzeugte Daten. Die Datenmanagement-Komponente steuert auch die Vervielfältigung von verwalteten Objekten innerhalb verschiedener Servicelogik-Ausführugsumgebungen (SLEE's) am Service-Verarbeitungsknoten. Kraft des Unterhalts eines lokalen Speichers, leistet die Datenmanagement-Komponente schnelle Wiederherstellung des normalen Betriebs nach oder in Erwiderung auf einen Defekt der Netzwerkausrüstung, Umschaltung in Wartungsbetrieb oder andere ähnliche Umstände. Wenn zum Beispiel ein Service-Verarbeitungs-Hardwareelement plötzlich ausfällt, kann der Service-Verarbeitungskontext in einem anderen Prozessor repliziert werden, und der Service wird ohne Unterbrechung fortgesetzt. Lokale Speicherung von Daten und verwalteten Objekten an jedem Service-Verarbeitungsknoten sorgt für rasche Fehlerbeseitigung und Wiederherstellung ohne Verzögerungen, die mit dem Holen von verwalteten Objekten aus der Netzwetk-Serviceadministrator-Komponente zusammenhängen.
Netzwerkingenieure können Regeln innerhalb der Datenmanagement-Komponente implementieren, die bestimmen, wie und wann verwaltete Objekte repliziert werden. Die Datenmanagement-Komponente überprüft das erfolgreiche und akkurate Herunterladen von verwalteten Objekten von der DBOR. Die Datenmanagement-Komponente überprüft auf gleiche Weise das akkurate Kopieren von verwalteten Objekten auf die Serviceprozessoren wie benötigt.
Die netzwerkweite Service-Verwaltungsfunktion und die Datenmanagement-Komponente an jedem Service-Verarbeitungsknoten kooperieren, um sicherzustellen, dass verwaltete Objekte, welche Servicefunktionalität verkörpern, korrekt verteilt und aktiviert werden. Weiterhin können die Service-Verwaltungs- und Datenmanagement-Komponenten die Verteilung von verwalteten Objekten auf der Grundlage von Netzwerk-Hardware-Eigenschaften, wie die Verfügbarkeit von spezialisierter Ausrüstung an bestimmten Service-Verarbeitungsknoten, koordinieren. Zum Beispiel kann ein gegebener Service-Verarbeitungsknoten eine Sprachausgabeeinheit als spezielle Ressource in seinem Ressourcenkomplex-Bereich enthalten. Dementsprechend werden spezialisierte verwaltete Objekte, die mit der Steuerung und Handhabung von Netzverkehr für diese spezialisierte Ressource verbunden sind, selektiv verteilt, aktiviert und instantiiert an diesem gegebenen Service-Verarbeitungsknoten. Unter den anderen Service-Verarbeitungsknoten, die diese Ressource nicht haben, muss die lokale Daten bank von Datensätzen für jeden Knoten nicht mit der Unterhaltung der spezialisierten verwalteten Objekte zur Unterstützung dieser speziellen Ressource belastet werden.
In einer bevorzugten beispielhaften Ausführungsform der vorliegenden Erfindung übernimmt der Serviceverwalter die gleichen Steuerungs- und Überwachungsfunktionen eines traditionellen Netzwerkverwaltungssystem (NMS). Zum Beispiel werden Störmeldungen, die normalerweise von der Netzwerkausrüstung an ein Netzwerkmanagement-System berichtet werden, vom Serviceverwalter überwacht und verarbeitet. Weiterhin kommuniziert der Serviceverwalter, wie in einem traditionellen NMS, direkt mit Netzwerkausrüstung über Steuerungsverbindungen und kann eine Fernsteuerung des Betriebs der Gerätschaft ausüben. Aus praktischer Sicht teilt der Serviceverwalter in großem Umfang ein gleiches Maß an Verbindungen mit Netzwerkservice-Verarbeitungselementen und Netzwerkverkehr-Behandlungsausrüstung mit dem traditionellen NMS. Daher, um Redundanz zu vermeiden, ist es vorteilhaft, die NMS-Funktionalität im Serviceverwalter einfach zu verschmelzen. Die gleiche DBOR, die zur Speicherung von Servicefunktionen als verwaltete Objekte benutzt wird, kann auch Netzwerkdaten, wie Topologie-Informationen und Geräte-Identifikations-Indizes speichern. Diese Integration ist besonders vorteilhaft dadurch, dass aktuelle Kenntnis von Netzwerk-Topologie, Geräteeinsatz und Betriebsstatus dazu benutzt werden kann, um daraufhin zu bestimmen, wo und wann die verwalteten Objekte, die Servicefunktionen implementieren, eingesetzt werden.
In noch einer weiteren bevorzugten beispielhaften Ausführungsform der vorliegenden Erfindung umfasst das Kommunikationsnetzwerk weiterhin ein Netzwerkbetriebssystem (NOS), welches Kommunikationsverbindungen zwischen funktionalen Elementen des Kommunikationsnetzwerks untereinander herstellt. Das NOS stellt plattform-unabhängige und Standort-unabhängige Konnektivität zwischen Netzwerksteuerungs-Komponenten bereit. Weiterhin umfasst das NOS einige zusätzliche funktionale Komponenten, welche im Allgemeinen für alle Netzwerk-Steuerungselemente verfügbar sind, um zum Beispiel die Benutzung von instantiierten verwalteten Objekten zwischen all den Service-Verarbeitungsumgebungen in einem Netzwerk zu verwalten.
Die vorstehenden und weiteren Vorteile der vorliegenden Erfindungen können besser verstanden werden mit Bezug auf die folgende Beschreibung in Verbindung mit den begleitenden Zeichnungen, in denen gilt:
1 ist ein logisches und funktionales Diagramm eines Telekommunikationssystems, das eine intelligente, verteilte Netzwerkarchitektur in Übereinstimmung mit einer bevorzugten Ausführungsform der vorliegenden Erfindung einsetzt;
2 ist ein Diagramm, das darstellt, wie erforderliche Netzwerk-Steuerungsfunktionen auf funktionale Komponenten in Übereinstimmung mit einer bevorzugten Ausführungsform der vorliegenden Erfindung abgebildet werden;
3(a) illustriert begrifflich die Funktionalität der Service-Verwaltungskomponente 500;
3(b) illustriert die physikalische Architektur der Service-Verwaltungskomponente 500;
3(c) illustriert die allgemeine funktionale Architektur der Service-Verwaltungskomponente 500 des IDNA/NGIN Systems 100;
3(d) illustriert das von der SA zur Aktualisierung der DBOR eingesetzte Schema.
3(e) illustriert das von der SA zur Verteilung von Daten von der DBOR an die Datenmanagement-Komponenten eingesetzte Schema.
3(f) illustriert die funktionale Architektur der Datenmanagement-Komponente 600.
3(g) bis 3(i) illustrieren Flussdiagramme, die allgemein die Service-Erzeugungs- und -Einsatzphasen des IDNA/NGIN Systems darstellen.
Die vorliegende Erfindung richtet sich an einen Serviceverwalter, der die Entwicklung und den Einsatz von verwalteten Objekten im Kontext einer Netzwerk-Steuerungsarchitektur, die solche Objekte verwendet, leitet. Insbesondere stellt der Serviceverwalter die Integrität von verwalteten Objekten und anderen für die Netzwerksteuerung und Serviceverarbeitung benö tigten Daten sicher. Dies wiederum gewährleistet zuverlässigen Betrieb des Netzwerks, selbst wenn neue Services implementiert werden.
Im vorliegendem Kontext wird eine Netzwerk-Steuerungsarchitektur, innerhalb derer die vorliegende Erfindung verkörpert werden kann, als die intelligent verteilte Netzwerkarchitektur/Next-Generation intelligente Netzwerkarchitektur bezeichnet, oder einfach als die IDNA/NGIN Architektur oder System bezeichnet. Dementsprechend kann ein Service-Verarbeitungsknoten als IDNA/NGIN Knoten bezeichnet werden.
Nun Bezug nehmend auf 1 wird ein Telekommunikationssystem, welches eine intelligente verteilte Netzwerkarchitektur (IDNA) in Übereinstimmung mit der vorliegenden Erfindung einsetzt, beschrieben und allgemein mit 200 gekennzeichnet. Das Wide Area Network („WAN") 202 ist ein Datenkommunikationssystem, das die Verteilung von Anwendungen und Daten über ein weites geografisches Gebiet unterstützt. Vorzugsweise basiert das zur Implementierung von WAN 202 benutzte Transportnetzwerk auf einem Synchronous Optical NETwork („SONET") und verbindet die Service-Verarbeitungsknoten 204 und versetzt die Anwendungen innerhalb dieser Knoten in die Lage, mit hohen Geschwindigkeiten untereinander zu kommunizieren.
Jeder Service-Verarbeitungsknoten 204 enthält wenigstens einen Serviceprozessor 172 und einen Ressourcenkomplex. 1 illustriert einen Service-Verarbeitungsknoten 204 mit einem Ressourcenkomplex A („RCA") 206 und einen Ressourcenkomplex B („RCB") 208. Mehrere beispielhafte Benutzer Terminals 159 sind in 1 verbunden mit RCA 206 gezeigt. ISDN Terminal 159a, Faxgerät 159b, Telefon 159c und Nebenstellenanlage (PBX) 159d sind alle Beispiele von Geräten, durch die Benutzer auf Services des Netzwerks 200 zugreifen.
Ein Ressourcenkomplex wie RCA 206 umfasst Geräte, die den vom Netzwerk transportierten Informationsverkehr des Benutzers direkt handhaben. Die Geräte und andere Ressourcen innerhalb des Ressourcenkomplexes werden durch Serviceprozessoren zum Bereitstellen von Informationstransport und anderen von den Netzwerkbenutzern benötigten Services gesteuert.
Serviceprozessor 172 kann mit einem oder mehreren Nebenprozessoren 210 verbunden sein, welcher traditionell Unterstützungsfunktionen bereitstellt, wie Beschaffung, Rechnungsstellung und Wiederherstellung. Diese Funktionen können durch die von einem Netzwerkmanagement-System („NMS") 212 bereitgestellte Funktionalität absorbiert werden. In der bevorzugten Ausführungsform jedoch können diese Unterstützungsfunktionen weiter in einer zentralisierten Serviceverwaltung („SA") in einem System 500 zusammengefasst werden, wie später beschrieben.
Wie weiterhin in 1 gezeigt, kann der Serviceprozessor 172 auch mit anderen Serviceprozessoren 172, über LAN 213, zu anderen Netzwerken (nicht gezeigt) oder anderen Vorrichtungen (nicht gezeigt) über eine direkte Verbindung 214 mit einer Zeichengabe-Verbindung 216 und einer Trägerverbindung 218 verbunden sein. Eine direkte Verbindung erlaubt es Vorrichtungen, eine Zeichengabe direkt an den Serviceprozessor zu senden und die Latenz und andere Einschränkungen (wie Datenformat), die mit einer Übermittlung der Zeichengabe durch den Ressourcenkomplex verbunden sind, zu vermeiden. Der Serviceprozessor 172 ist das „Gehirn" des Service-Verarbeitungsknotens 204 und ist vorzugsweise ein Mehrzweck-Computer, welcher von einem Einprozessor-Rechnersystem zu einem Computernetzwerk in großem Maßstab reichen kann, abhängig von den Verarbeitungserfordernissen des Service-Verarbeitungsknotens 204. Vorzugsweise hat der Netzwerkcoumputer redundante Verarbeitung, Speicherung und Verbindungen.
Jeder Serviceprozessor 172 betreibt an wenigstens eine Service logische Ausführungsumgebung (SLEE) 173, worin verwaltete Objekte instantiiert werden und interagieren, um Service-Verarbeitungsfunktionen zu leisten.
Eine intelligente Peripherie („IP") 88 stellt die Fähigkeit bereit, in dem eigentlichen Anruf-Übertragungspfad enthaltene Informationen zu verarbeiten und auf diese zu agieren. IP's 88 sind allgemein in einem separaten Ressourcenkomplex wie RCB 208 und werden durch die Serviceprozessoren 172 in ähnlicher Weise wie RCA 206 gesteuert. Zum Beispiel können einige Arten von IP's Echtzeitverarbeitung von Sprachsignalen in einem Anruf-Übertragungspfad unter Benutzung von digitaler Signalverarbeitung („DSP") Technologie bereitstellen.
Das Netzwerkmanagement-System („NMS") 212 wird traditionell zum Überwachen und Steuern von Hardware und Services in der Serviceverarbeitung 200 benutzt. Die NMS 212 Implementierung kann ein Telecommunications Management Network („TMN")-kompatibles Rahmenwerk sein, welches das Management von Komponenten innerhalb des Netzwerkes 200 bereitstellt. In einer bevorzugten Ausführungsform ist aus praktischen Erwägungen NMS 212 im Serviceverwalter 500 enthalten. Das NMS 212 kann den Betriebszustand von RCA 206 und RCB 208 über eine Standard-Betriebsverbindung 226, wie sie im Stand der Technik gut bekannt ist, direkt überwachen und steuern.
Wie weiterhin in 1 gezeigt, enthält eine verwaltete Objekt-Erzeugungsumgebung („MOCE") 228 Unterkomponenten zur Erzeugung von Services, die im Kommunikationsnetzwerk 200 ablaufen. Der Service-unabhängige Erstellungsblock (SIBB) und API Repräsentationen, die ein Serviceentwickler benutzt um neue Services zu erzeugen, sind in der primären Unterkomponente der MOCE, einer grafischen Benutzerschnittstelle („GUI"), eingebettet. Die MOCE 228 ist eine zusammengefasste Sammlung von auf einer Einzelbenutzer-Umgebung oder -Plattform beherbergten Werkzeugen, alternativ mit Service-Erzeugungsumgebung (SCE) bezeichnet. Sie repräsentiert die Sammlung von Operationen, die im Laufe des Service-Erzeugungsprozesses erforderlich sind, wie Servicedokumentation, Definition verwalteter Objekte, Schnittstellen-Definition, Protokoll-Definition und Dateneingabe-Definition, die in verwalteten Objekten gekapselt sind, und Servicetests. Der Netzwerkeigner muss einen Service nur einmal unter Benutzung der MOCE 228 entwickeln, weil verwaltete Objekte in allen Knoten in seinem Netzwerk angewendet werden können. Dies steht im Gegensatz zu dem Netzwerkeigner, der jeden der verschiedenen Switch-Hersteller seine Version des Services entwickeln lässt, in welchem Fall der Service viele Male entwickelt werden muss.
2 ist ein Venn-Diagramm, das zur Beschreibung nützlich ist, wie funktionale Elemente der vorliegenden Erfindung mit für Netzwerkdaten- und Rechnerressourcen-Verwaltung benötigten funktionalen Elementen zusammenhängen.
2 enthält mehrere funktionale Elemente, die an anderer Stelle im Detail beschrieben werden. Kurz zusammengefasst dient das Repository 230 als ein zentraler Punkt der Speiche rung für alle Daten, wie verwaltete Objekte, Routing-Tabellen oder Umsetzungstabellen, die vom Kommunikationsnetzwerk benötigt werden.
Die administrative Funktion 595 in 2 repräsentiert die zentrale Steuerung des Einsatzes von Daten und verwalteten Objekten in Netzwerk-Serviceprozessoren, sowie Bereitstellung und Aktivierung von Services.
Knoten-Ressourcenmanagement (NODE RM) 575 bezieht sich auf die Echtzeit-Koordinierung von instantiierten Objekten und Datenressourcen innerhalb des Bereichs eines einzelnen Service-Verarbeitungsknotens. Dies gestattet Standort-unabhängige gemeinsame Nutzung und Aufrufen von Service-bezogenen Objekten. Zum Beispiel können mehrere Prozessoren an einem Service-Verarbeitungsknoten anwesend sein und durch ein lokales Datennetzwerk wie ein Local Area Network (LAN) verbunden sein. Wenn ein erstes auf einem ersten Computer verarbeitetes Serviceobjekt ein zweites Serviceobjekt benötigt, das auf einem anderen Computer im Knoten verfügbar ist, dann ist NODE RM 575 die Funktion, durch die das erste Serviceobjekt mühelos das zweite Objekt finden und einsetzen kann, obwohl das zweite Objekt auf einem unterschiedlichen Computer läuft.
Ähnlich bezieht sich das System Ressourcenmanagement (SYS RM) 585 in 2 auf die Echtzeit-Koordinierung von instantiierten Objekten und Rechnerressourcen in einem netzwerkweiten Maßstab, d. h. unter dem Service-Verarbeitungsknoten.
Schließlich ist eine Service-Erzeugungsumgebung, speziell eine verwaltete Objekt-Erzeugungsumgebung (MOCE) 228 in 2 enthalten, um den Punkt darzustellen, wo verwaltete Objekte ursprünglich erzeugt und getestet werden.
In Übereinstimmung mit der zuvor beschriebenen IDNA Architektur entspricht eine Verwaltungsfunktion 595 und SYS RM 585 grob einer einzelnen Einheit, nämlich NMS 212. NODE RM 575 entspricht grob einer sogenannten in der IDNA Architektur beschriebenen ICP-NMS Agentenfunktion 240.
Repository 230 und MOCE 228 sind im Wesentlichen äquivalent zu ähnlich benannten, in der IDNA Architektur beschriebenen Elementen.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung sind die Funktionen in 2 unterschiedlich zusammengefasst, wie folgt:
Die Echtzeit-Ressourcen-Koordinationsfunktionen des SYS RM 585 und NODE RM 575 werden vom Netzwerk-Betriebssystem (NOS) 700 umfasst.
Während das Repository 230 die beständige Speicherung von Netzwerk-Datenobjekten darstellt, repräsentiert die Kontur von Datenmanager (DM) 600, dass beständige Speicherung auch unter Service-Verarbeitungsknoten verteilt wird.
Weiterhin, in Übereinstimmung mit einer bevorzugten Ausführungsform der vorliegenden Erfindung, ist die Verwaltungsfunktion 595 im Repository 230 integriert, um den Serviceverwalter (SA) 500 zu bilden. Durch diese Zusammenfassung wird SA 500 zu einem Pförtner oder Bibliothekar, der die Integrität von im Repository 230 gespeicherten Datenobjekten schützt. Selbst MOCE 228 muss über SA 500 gehen, um Datenobjekte zu speichern und abzurufen.
Wie begrifflich in 3(a) gezeigt, ist die Service-Verwaltungskomponente 500 eine Komponente, die alle zum Verwalten, Speichern und Verteilen aller Services und Service-Verarbeitungsknoten benutzten Servicedaten ausführt und sowohl die Hardware- und Softwarekomponenten überall im in 1 dargestellten Netzwerk-Steuerungssystem zu konfigurieren. Allgemein, wie in 3(a) gezeigt, ist die SA Komponente 500 verantwortlich für: Katalogisierung und Speicherung der erzeugten Objekte und Daten von MOCE (Serviceerzeugung) 228; Rückgabe von offiziellen Kopien von verwalteten Objekten und Daten an MOCE 228 zu Serviceentwicklungszwecken; Empfangen von fertiggestellten und getesteten Servicepaketen, SIBBs, SLPs oder anderen Service- oder Datenkomponenten 506 von MOCE 228; Empfangen von Kundenbestelldaten 502 von Bestellungseingangs- und anderen vorhandenen Systemen 229, um das IDNA/NGIN System für die Benutzung durch Kunden vorzubereiten; Vergeben eindeutiger Namen an jede Servicekomponente; und Einsetzen von verwalteten Objekten und Daten an Netzwerk-Serviceprozessoren mittels Datenmanagement-Funktionen 600, wie hierin genauer beschrieben werden wird.
Zusätzlich unterhält die Service-Verwaltungskomponente 500, wie in 2 gezeigt, das Repository 230. Das Repository 230 enthält hauptsächlich eine globale Datenbank von Datensätzen („DBOR"), die alle IDNA Services und Daten umfasst, und von welcher jede Datenmanagement-Komponente 600 letztlich all ihre Daten erhält.
Andere Verantwortlichkeiten der Serviceverwaltung schließen ein: Aktivierung von Daten und Servicekomponenten 512, um sicher zu stellen, dass alle Daten, SIBBs und verwaltete Objekte oder Service-logische Programme SLPs für Knoten mittels der Datenmanagement-Komponente 600 verfügbar sind; Registrierung der Namen der Daten, SLPs und SIBBs 515 durch Eingabe ihrer logischen Namen an eine Netzwerk-Betriebssystem („NOS") Komponente 700, welche weiter unten genauer beschrieben wird, zur dortigen Registrierung; die Aktivierung von Daten und Servicekomponenten 518; und Entfernen von Daten und Services 521 vom IDNA/NGIN System mittels der Datenmanagement-Komponente 600. Serviceverwaltung führt zusätzlich eine Konfigurationsmanagementfunktion durch Unterhalten des Zustands von jedem SIBB und Service (vor Test, nach Test, eingesetzt, etc.) durch, zusätzlich zur Versionierung durch ihren Namensgebungsprozess. Dies stellt sicher, dass ein Service nicht eingesetzt wird, bevor alle Komponenten dieses Services erfolgreich getestet und konfiguriert wurden.
Die Service-Verwaltungskomponente 500 führt weiterhin die Funktion der Konfigurierung und Bereitstellung von IDNA/NGIN Serviceknoten 204 in Übereinstimmung mit den Konfigurationsinformationen, die die SA empfängt, durch. Speziell, basierend auf den empfangenen Konfigurationsinformationen, bestimmt die SA-Komponente 500 die Fähigkeiten von jeder Komponente an jedem Serviceknoten 204, welche Services und Daten an welche Knoten zu verteilen sind, welche Services auf welchem/welchen Server/n, der die am Serviceknoten wohnt/wohnen, und welche Daten in einem lokalen, residenten, mit dem/den IDNA/NGIN Knoten Server/n zugeordneten Speicher zwischengespeichert wird. Speziell verteilt SA Konfigurationsregeln, die in Serviceprofil-(Konfigurations-) Dateien 580 enthalten sind, an eine lokale (Knoten-) Ressourcenmanager- („LRM") Komponente 575 des NOS Systems 700 zur Speicherung in dem lokalen LRM Zwischenspeicher, der an jedem Serviceknoten ist. Wie hierin später genauer beschrieben wird, legen diese Konfigurationsdateien 580 fest, welche Services an einem IDNA Knoten auszuführen sind. Der LRM liest zunächst diese in dem lokalen Zwischenspeicher an jenem Knoten gespeicherte Service-Profildatei 580, und legt eine spezifische Serviceschicht-Ausführungsumgebung („SLEE") fest, z. B. eine virtuelle Maschine, um darauf einen Service in Übereinstimmung mit den Regeln in der Service-Profildatei ablaufen zu lassen, und welche Services aktiv ablaufen sollen (als beständige Objekte) in der SLEE oder nur auf Anfrage zu instantiieren sind.
3(b) illustriert eine bevorzugte physikalische Architektur für die Service-Verwaltungskomponente 500. Obwohl die Serviceverwaltung eine zentralisierte Funktion ist, kann sie als zwei oder mehrere redundante Service-Verwaltungsstandorte, z. B. Standorte 550a, 550b, verkörpert werden, zwecks Zuverlässigkeit, wobei jeder SA Standort umfasst: SA Servers 560, die duale, redundante Prozessoren mit einem geteilten Disc Array, das die globale DBOR 230 umfasst, umfassen können; und ein Personal Computer (PC) oder eine Workstation 556a, b, ansässig an jedem jeweiligen Standort 550a, 550b, mit einer Schnittstelle, um Benutzerzugriff auf alle Service-Verwaltungsfunktionen zu ermöglichen und insbesondere Daten- und Serviceverteilung an angegebenen IDNA/NGIN Serviceknoten auszulösen, in 3(b) als Serviceknoten 204 dargestellt. Die zuvor erwähnten Daten- und Serviceverteilungs-Aktivierungsfunktionen laufen alle auf einem oder mehreren SA Servern 560, die an jedem Standort zu finden sind, ab. Die Komponenten an jedem jeweiligen SA Standort 550a, b sind durch Ethernet LAN 559 verbunden, welches wiederum mit einem WAN 566 zur Kommunikation mit den Serviceknoten verbunden ist.
Wieder mit Bezug auf 2 tritt die NGIN Datenmanagement-Komponente 600 sowohl als Service-Lebenszyklus als auch als Service-Benutzungskapazität auf. Während die Service-Verwaltungskomponente 500 eine globale Datenbank von Datensätzen (Repository) 230 unterhält, stellt die Datenmanagement-Komponente 600 die lokale Datenspeicherungs- und Datenmanagement-Funktionen für jeden IDNA/NGIN Service-Verarbeitungsknoten 204 bereit. Dies schließt alle zur Serviceverarbeitung benötigten Datentypen ein, wie: Serviceprogramme und SIBBs, Daten für Services (Kundenprofile, Telefonnummern, etc.), Multimediadateien (wie Audiodateien für interaktive Sprachantwort („IVR") Services), etc. Speziell empfängt die Datenmanagement-Komponente 600 eines Serviceknotens einen Auszug aus der SA globalen DBOR, der alle Daten umfasst, die für die durch den lokalen NGIN Serviceknoten ausgeführten Services, wie sie durch die Serviceverwaltung spezifiziert sind, benötigt werden.
3(c) illustriert eine bevorzugte physikalische Ausführungsform, die die funktionalen Hauptkomponenten von und externen Schnittstellen zu der Service-Verwaltungskomponente 500 der Erfindung hervorhebt. Wie in 3(c) gezeigt, umfasst die Service-Verwaltungskomponente 500 eine Datenverteilungs-Subkomponente 510, die: 1) für zuverlässige Kommunikation mit externen Systemen sorgt; 2) sämtliche Datenübersetzungs- und Formatierungsfunktionen zum Empfang von Daten von externen Systemen und Verteilen von Daten von SA an externe Systeme, typischerweise durch die Vermittung einer gebräuchlichen Datenverteilungs-Anwendungsprogramm-Schnittstelle (DDAPI) 505 durchführt; 3) Daten aus von externen Systemen empfangenen Kommunikationsnachrichten zur Eingabe an eine Inventarmanager-Subkomponente 516 extrahiert; 4) eine Mehrpunkt-Verteilungsfunktion für Service/Datenpakete mit einem Speicherungs- und Weiterleitungsmerkmal und garantierter Zustellung und Wiederherstellungsservices bereitstellt; und 5) für die Zustellung von Datenreihen in Reihenfolge, zusätzlich zur Lückenüberprüfung, Duplikatsüberprüfung, Empfangsbestätigungen sorgt, und die Sicherheit von Datenübertragungen sicherstellt.
Wie in 3(c) gezeigt, enthalten die Eingaben an die SA Komponente 500: eine Einspeisung 506 von MOCE/SCE 228, von der Servicekomponenten, Pakete und zum Bauen von Services benutzte SIBB Module zugeführt werden; eine Bestelleingangs- („OE") Einspeisung 502, von der Kundendaten zur Ausführung von Service-Bereitstellungsfunktionen eingegeben werden; und eine oder mehrere Umgebungsbereitstellungs- („EP") Systemeinspeisungen 508, von denen Benutzerspezifikationen eingegeben werden, um SA 500 anzuweisen, wie und wo von der MOCE Komponente 228 erzeugte Services zu verteilen sind. Genauer mit Bezug auf die Umgebungsbereitstellungs-Systemeinspeisung 508 ist jede Serviceknoten-Komponente, die als Teil der NGIN Service-Verarbeitungsumgebung (Computer Hardware, Betriebssystem, SLEE, lokale Zwischenspeicher des Datenmanagements) angesehen wird, mit einem Serviceknoten-Profil spezifiziert, das die physikalischen Fähigkeiten dieses Knotens (z. B. Kapazität des nicht flüchtigen Speichers, Arbeitsspeicherkapazität, Rechnerverarbeitungs-Kapazität, etc.) umfasst. Über eine GUI Version des EP Systems 508 GUI (nicht gezeigt) spezifiziert ein Benutzer auf der Grundlage des Serviceknoten-Profils (Fähigkeiten) von jedem Serviceknoten ein Serviceprofil, das umfasst, welche Serviceobjekte (z. B. SLPs, SIBBs, Daten, etc.) an welche SLEEs an welchen Knoten zu verteilen sind, welche Daten an welche Knoten zu verteilen sind, und die lokale Zwischenspeicherungsstrategie von jeder SLEE und jedem Computer. Diese Spezifikationen sind Eingaben an die SA und werden von einer Umgebungsmanager-Subkomponente 530 benutzt, um die korrekte Verteilung von Services und Daten zu spezifizieren.
Spezieller wird die Umgebungsbereitstellungs-Systemschnittstelle benutzt, um die Serviceknoten-Profile einzugeben sowie die Verteilung von Serviceprofilen an die zutreffenden Serviceknoten anzuweisen. Serviceknoten können automatisch mit Serviceprofilen zusammengefügt werden auf der Grundlage von den Fähigkeiten des Serviceknotens und den Forderungen des Serviceprofils, jedoch kann ein Serviceprofil spezifizieren, dass ein Serviceknoten manuell ausgewählt wird. Falls ein Serviceprofil anfordert, dass es manuell gegen Serviceknoten zusammengeführt wird, wird der Service nicht verteilt, bis die Abstimmung unter Benutzung des EP Systems 508 gemacht wurde. Falls das Serviceprofil anfordert, dass der Service automatisch verteilt wird, kann der Service automatisch zugewiesen und verteilt werden, die Umgebungsbereitstellungs-Schnittstelle kann jedoch dieses außer Kraft setzen und die Verteilung zu einem späteren Zeitpunkt ändern.
Die Datenverteilung API 505 stellt die Standardschnittstelle zur Benutzung aller SA Funktionen bereit und interagiert weiterhin mit der Datenverteilungs-Subkomponente, um garantierte Zustellungs-/Wiederherstellungsservices bereitzustellen. Insbesondere stellt die DDAPI 505 einen Satz von Standardnachrichten zur Benutzung durch Serviceverwaltungsclients, welche die lokalen Datenmanagement-Komponenten an jedem Serviceknoten sind, bereit. Die SCE und das EP System sind auch derart entworfen, um mit der Serviceverwaltung über die DDAPI in eine Schnittstellenverbindung zu treten. Andere externe Systeme, wie OE Systeme 229, können jedoch nicht für die Benutzung von DDAPI entworfen werden und in Folge kann ein Mediationsprozess 511 benutzt werden, um das Kommunikationsprotokoll und Signalgebungs-Formate von derartigen externen Systemen an die DDAPI 505 anzupassen.
Wie in 3(c) gezeigt, sind nur eine einzelne DDAPI 505 und ein Datenverteilungsprozess 510 für alle externen Schnittstellen erforderlich. Alle externen Systeme, die mit der Serviceverwaltung eine Schnittstellenverbindung eingehen, haben Zugang zu all diesen Funktionen, abhängig von den Privilegien, die jedem eingeräumt wurden. Dies stellt sicher, dass Funktionen wie z. B. DBOR Aktualisierungen, alle auf die gleiche Weise behandelt werden, unabhängig davon, wer sie initiiert, und beseitigt darüber hinaus die Verarbeitung von Spezialfällen. Dies stellt auch sicher, dass die gleichen Datenintegritäts-Überprüfungen, die man chen Systemen (z. B. OE) bereitgestellt werden, anderen Systemen (z. B. Netzwerkelementen) bereitgestellt werden, befördert weiterhin die Entwicklung von externen Systemen mit Schnittstellen zur Serviceverwaltung.
Wie weiterhin in 3(c) gezeigt, umfasst die SA-Komponente 500 die folgenden Subkomponenten: einen Inventarmanager 516; einen DBOR-Manager 520; einen Umgebungsmanager 530; einen Prüfungs- und Abstimmungsmanager 535 und einen Überwachungs- und Protokollierungsmanager 540. Die Funktionen von all diesen werden nun detaillierter beschrieben.
Die Inventarmanager-Subkomponente 516 empfängt alle Datenentitäten von externen Quellen über den Datenverteilungsprozess 510. Diese Datenentitäten enthalten Servies und SIBBs von der Serviceerzeugung, Servicedaten und Kundendaten von Auftragseingangs-Systemeinspeisungen 502 und Umgebungskonfiguration und Bereitstellungsspezifikationen von Umgebungsbereitstellungs-Einspeisungen 508. Der Inventarmanager 516 stellt einen eindeutigen Namen für jede empfangene Datenentität bereit gemäß einer vorher festgelegten Namenskonvention. Dies schließt mehrere Versionen derselben Datenentität ein. Der Inventarmanager stellt auch die Datenintegrität innerhalb der von mehreren Quellen empfangenen Daten sicher und löst Konflikte auf. Wenn beispielsweise der Inventarmanager zwei unterschiedliche Netzwerkziele (aufgelöst durch die Anwendung irgendwelcher intelligenten Routingmerkmale) von zwei verschiedenen OE Quellen empfängt für die gleiche gebührenfreie Kundentelefonnummer, wird der Inventarmanager dies durch Durchführung einer Prüfung auf jeder empfangenen Datenentität feststellen. Nach Feststellung kann er entweder einen Auflösungsalgorithmus (z. B. Beibehalten des Netzwerkziels mit dem aktuellsten Datums-/Zeitstempel) durchführen oder den Benutzer über den Konflikt benachrichtigen. Der Inventarmanager speichert dann die benamte Datenentität in der DBOR 230. Er benutzt einen DBOR Manager 529, um die Daten tatsächlich in der DBOR zu speichern. Der Inventarmanager benachrichtigt auch den Umgebungsmanager über jegliche Aktualisierungen der DBOR.
Der DBOR Manager 520 stellt eine einzelne Schnittstelle zur DBOR 230 für mehrere funktionale Komponenten der Serviceverwaltung bereit und führt alle Datenbank-Managementfunktionen (add, delete, retrieve, modify, etc.) durch. Dies ist eine signifikante Funktion, da die DBOR tatsächlich mehrere Datenbanken zum Zwecke der Speicherung mehrerer Datenty pen enthalten kann: SLPs für Services, SIBBs, Datensätze für Kunden- und Servicedaten, Multimediadaten für IVR Services, etc. Vorzugsweise umfasst die DBOR sowohl Objektdatenbanken als auch relationale Datenbanken. Diese Datenbanken können von verschiedenen Anbietern bereitgestellt werden und erfordern daher unterschiedliche Befehlssätze für die Ausführung von Datenbankmanagement-Funktionen. Der DBOR Manager 520 kapselt diese Variationen von den anderen Service-Verwaltungskomponenten, so dass jede Komponente, die das Ausführen einer DBOR Funktion benötigt, einfach einen Satz gebräuchlicher Befehle, der vom DBOR Manager bereitgestellt wird, und einen Datenentitätennamen implementiert. Der DBOR Manager 520 benutzt den bereitgestellten Datenentitätennamen und passt den angeforderten Befehl an ein von dem spezifischen Datenbanktypen benutztes Format an, um die angeforderte Funktion auszuführen. Es gibt drei Service-Verwaltungssubkomponenten, die mit dem DBOR Manager über eine Schnittstelle kommunizieren: Den Inventarmanager 516, den Umgebungsmanager 530 und einen Prüfungs- und Abstimmungsmanager 535.
Die Umgebungsmanager-Subkomponente 530 ist verantwortlich für die Verteilung von Services und Daten von der DBOR an die lokalen Datenmanagementkomponenten an den NGIN Serviceknoten. Er macht dies durch eine anfängliche Feststellung, welche Service-/Datenentitäten an welche Knoten verteilt werden müssen; gibt sodann die entsprechenden Verteilungsbefehle, zusammen mit den aus der DBOR extrahierten Datenentitäten, an die Datenverteilung auf. Umgebungsbereitstellungs-Spezifikationen, die durch einen Benutzer mittels der EP Systemeinspeisung 508 eingegeben werden, werden in der DBOR gespeichert und vom Umgebungsmanager zur Festlegung der Verteilung benutzt. Auf diese Weise verteilt die Serviceverwaltung an jeden NGIN Serviceknoten nur solche Datenentitäten, die von jenem Serviceknoten benötigt werden. Dieses Merkmal reduziert die Speichererfordernisse an jedem Serviceknoten und die Netzbandbreite und die für die Datenverteilung benötigte Verarbeitungs-/Übertragungszeit. Es ermöglicht zusätzlich, die netzwerkweite Verteilung von NGIN Funktionen durch Vereinfachung der Datenintegrität, da die Anzahl der Kopien einer Datenentität minimiert wird. Es sollte verstanden werden, dass die Umgebungsmanager-Funktionen komplexe Verarbeitung durch die Serviceverwaltung erfordern können, aber diese Komplexität ist einfach in Verteilungsregeln gekapselt, die durch den Umgebungsmanager angewendet werden. Zusätzlich weist der Umgebungsmanager 530 eine wertvolle Ebene der Konfiguration, die der NGIN Systemarchitektur zur Verfügung gestellt wird, auf. Das heißt, dass, während alle Daten an alle Serviceknoten verteilt werden können, um alle Services an jedem Knoten zu ermöglichen, dies nicht notwendig ist. Ein Benutzer kann entscheiden, welche Services an welche Knoten zu übergeben sind, um die Netzwerkauslegung zu optimieren und dann die für diese Services benötigten Daten an diese Knoten zu verteilen.
Der Umgebungsmanager 530 kann zusätzlich durch entweder den Inventarmanager oder den DBOR Manager benachrichtigt werden, sobald die DBOR modifiziert wird, z. B. wenn ein Service durch eine neue Version ersetzt wurde. Der Umgebungsmanager 530 stellt sicher, dass jeder Serviceknoten, der betroffen ist, aktualisiert wird (d. h. die neue Serviceversion erhält). Wenn er die Benachrichtigung über eine DBOR Aktualisierung erhält, identifiziert er jeden Serviceknoten, der die aktualisierten Daten benutzt oder der den aktualisierten Service bereitstellt, und verteilt dann die Aktualisierungen an die lokalen Datenmanagement-Komponenten an jedem betroffenen Serviceknoten, wie hierin beschrieben.
Der Prüfungs- und Abstimmungs-(A/R)Manager 535 stellt die Datensynchronisierung zwischen der DBOR und deren mehrfachen Auszügen durch Ausführen von Prüfungsroutinen zum Vergleich der Daten in der DBOR 230 mit Daten in einem jeden der verschiedenen DBOR Auszüge sicher. Er legt dann Korrekturmaßnahmen zur Resynchronisierung der mehrfachen Datenbanken fest. Zur Implementierung dieser Maßnahmen erzeugt der A/R Manager ein Datenpaket, das Daten und Befehle zur Verarbeitung dieser Daten enthält. Dieses Datenpaket wird dann irgend einer Datenbank, die die Korrekturmaßnahmen zur Resynchronisierung der mehrfachen Datenbanken implementieren muss, bereitgestellt. Vorzugsweise kann dies wie folgt geleistet werden: 1) während Leerlaufzeit kann eine Prüfungsroutine zum Suchen und Auflösen irgendwelcher Diskrepanzen zwischen den Daten in der DBOR und den Daten in einem DBOR Auszug ablaufen, welcher in einer lokalen Datenmanagement-Datenbank an einem Serviceknoten residieren kann; und 2) während der Echtzeit-Anrufverarbeitung, falls eine Serviceanwendung eine Diskrepanz findet, z. B. einer Serviceanwendung wird ein Schlüssel für eine Datensuche im Datenmanagement übergeben, fragt eine Datenbank mit diesem Schlüssel ab, findet aber keinen Datensatz, erzeugt die Anwendung einen Alarm. Dieser Alarm wird an den A/R Manager 535 gesendet, der die Diskrepanz auflöst.
Die Überwachungs- und Protokollierungs-Subkomponente 540 ist ein Prozess, der die Leistung und Stabilität des Serviceverwaltungsprozesses überwacht und bestimmte oder alle aus geführten Ereignisse protokolliert, so dass ein Benutzer z. B. später sehen kann, welche Daten wann an welche Knoten verteilt wurden.
Wie beschrieben kann die globale DBOR 230 eine oder mehrere physikalische Datenbanken sein, partitioniert zur Speicherung und Verwaltung der vielen verschiedenen Datentypen und Services, einschließlich: SLPs, SIBBs, Servicedaten und Kundendaten, z. B. Kundenprofile einschließlich Anrufdatensatz-Informationen, Faxe und Routingpläne, und Multimediadateien einschließlich Voicemail-Nachrichten und anderen Audio- und Videodateien, oder Objekte für interaktive Services. Während eine Vielzahl von DBORs existieren können zwecks Redundanz und Überlebensfähigkeit, ist die DBOR 230 ein einzelner logischer Speicher von allen NGIN Services und Daten zur Verteilung an jegliche und alle anderen funktionalen NGIN Komponenten und Prozesse.
Wie weiterhin in 3(c) gezeigt, implementiert die SA-Komponente 500 die NOS-Komponente 700 zur Bereitstellung von Kommunikationen zwischen den verschiedenen Serviceverwaltungsprozessen. Zum Beispiel benutzt die DDAPI 505 NOS Services zur Bereitstellung eines Satzes von Nachrichten, der die Kommunikationsmechanismen von NOS benutzt, um Schnittstellen zwischen externen Systemen und der Datenverteilung 510 zu ermöglichen und zwischen der Datenverteilung 510 und anderen SA-Subkomponenten. Das NOS 700 ist jedoch nicht für die Kommunikation zwischen den Inventarmanager-, Umgebungsmanager-, A/R-Manager und den DBOR Manager-Komponenten erforderlich, da diese Prozesse in einer bevorzugten physikalischen Ausführungsform zur Ausführung auf dem gleichen Rechnersystem entworfen wurden. Es sollte verstanden werden, dass selbst in einer verteilten Rechnerumgebung, in der diese Prozesse auf unterschiedlichen Rechnersystemen ablaufen, diese Prozesse miteinander mittels anderer interner APIs und Kommunikationsprotokolle, z. B. TCP/IP Sockel kommunizieren können. Es wäre für ausgebildete Handwerker offensichtlich, wie alle internen Serviceverwaltungsprozesse mit den Fähigkeiten zur NOS-Benutzung für die Interprozesskommunikation bereitgestellt werden können.
Nach dieser Beschreibung der bevorzugten Ausführungsform SA-Komponente 500, wird nun eine detailliertere Beschreibung der hauptsächlichen durch die Serviceverwaltung 500 durchgeführten Services mit Bezug auf die 5(c) bis 5(e) bereitgestellt.
Als erster hauptsächlicher Service ist die SA 500 wie erwähnt verantwortlich für die Namensgebung und das Durchführen der Versionierung von Services und Daten. Das heißt, die SA stellt einen eindeutigen Namen für jede Version von jeder Service-/Datenentität bereit vor der Speicherung der Service-/Datenentität in der DBOR 230, so dass mehrfache Versionen derselben Service-/Datenentität unterhalten werden können. Wenn die SA Daten/Services an das Datenmanagenment verteilt, wird ein einziger logischer Name zusammen mit einem eindeutigen Versionsnamen mit jeder Entität bereitgestellt, so dass Prozesse wie SLPs eine Service-/Datenentität mit einem gebräuchlichen logischen Namen aufrufen können, ohne wissen zu müssen, welche Version benötigt wird. Es sollte verstanden werden, dass die Namensregistrierungserfordernisse ein detailliertes Verständnis für das Bedürfnis nach eindeutigen Daten-, SIBB- und SLP-Namen und dafür, dass die SA-Komponente 500 von NGIN die Hauptkopie dieser verschiedenen Komponenten unterhält, bereitstellt. Sobald Daten, SIBBs und SLPs der SA zur Verfügung gestellt sind, hat der Erzeuger diese Komponenten sie unter Benutzung eines Benutzernamens identifiziert. Dieser Benutzername stellt eine Möglichkeit für MOCE/SCE bereit, die Komponente in ihrer Bezeichnungsweise zu identifizieren; dieser Benutzername ist dann eindeutig identifiziert durch einen einzigen logischen Namen (d. h. eine gebräuchliche Referenz). Vorzugsweise implementiert die SA eine Namensgebungsstruktur-Konvention, wenn sie neue oder modifizierte Komponenten benamt und unterhält vorzugsweise eine Abbildung zwischen Benutzername und den eindeutigen logischen Systemnamen. Bei der Ausführung einer Daten-, SLP- und SIBB-Anfrage kann die SA den Benutzernamen bereitstellen, zusätzlich zum eindeutigen logischen Systemnamen.
Als zweiter Hauptservice ist die Serviceverwaltungskomponente 300 für die Serviceversorgung verantwortlich, d. h. Versorgen der Services mit zur Bereitstellung dieser Services benötigten Daten. Dieser Typ von Daten wird von der Auftragseingangseinspeisung 502 in die SA eingegeben und in der globalen DBOR 230 vor der Verteilung an das Datenmanagement 600 gespeichert. Dieser Typ von Daten kann einschließen, ist aber nicht beschränkt auf Kundenprofildaten, wie Kundenserviceoptionen, Kundenname und Kontodaten, Telefonzielnummern, Anrufroutingdaten und sämtliche potentiell von einem Service zur Verarbeitung und Vollendung eines Anrufs benötigten Daten. Wenn beispielsweise ein 1-800 Service in der Serviceerzeugung für einen Firmenkunden aufgebaut wird, werden der Name dieses Kunden, Konto/Rechnungsinformationen, eine oder mehrere 800 Telefonnummer(n), Zielnetzwerkadressen, Serviceoptionen (Routingmerkmale, Multimediadatei-Identifizierer), wie vom OE Sys tem empfangen, für die Versorgung des oder der besonderen Services) benötigt. In dieser Funktion geht die Serviceverwaltung 500 geeignete Auftragseingangseinspeisungen durch, um einen gemeinsamen und konsistenten Auftragseingansdatensatz an das NGIN zu erzeugen und stellt sicher, dass jede Einspeisung, die von einem Auftragseingangssystem oder von einem Versorgungssystem empfangen wurde, bestätigt wird.
Als dritten Hauptservice ist die SA-Komponente 500 für Serviceunterstützungsbereitstellung verantwortlich, d. h. Konfigurierung der NGIN Verarbeitungsumgebungen (Hardware, Betriebssysteme, SLEE(s), Standorte, Standort- LANs und Zwischen- Standort- WANs) und die Versorgung von Daten, die diese Konfigurationen spezifizieren. Speziell hat jeder IDNA/NGIN Serviceknoten ein zugeordnetes Serviceknotenprofil, das in die SA mittels der Umgebungsversorgungs- Subkomponente 508 (3(c)) eingegeben wird, und das die Fähigkeiten des Rechnersystems, die dem Rechnersystem zugewiesenen Funktionen und die Arten von Services, die an diesem Serviceknoten unterstützt werden können, spezifiziert. Ein Beispiel- Serviceknotenprofil, welches als formatierte Datendatei in der SA verkörpert sein kann, ist in Tabelle 1 wie folgt dargestellt:
TABELLE 1
Somit ist in dem Beispielprofil von Tabelle 1 spezifiziert: ein Knotenname, ein Betriebssystem für den logische Serviceprogramme ausführenden Computer, die Anzahl von Arbeitsspeicher-, Festplatten- und Datenkommunikationseinheiten, eine Anzeige, dass der Knoten fähig ist, kundenspezifische Daten von der SA (Datenmanagementzugang) zu empfangen, und dass der Knoten spezielle Servicemerkmale unterstützen kann, beispielsweise Sprachabspielfähig keiten. Es sollte verstanden werden, dass die Beispieltabelle 1 andere Typen von Informationen, die mit der mit einem bestimmten Serviceknoten verbundenen Anzahl von Ressourcen und Fähigkeiten verbunden sind, enthalten kann.
Zusätzlich wird in der SA für jeden Service ein Serviceprofil erzeugt, welches als eine formatierte Datendatei in der SA verkörpert sein kann, die die Erfordernisse dieses Services spezifiziert und an welche SLEE(s) und/oder Computer innerhalb des Netzwerks sie verteilt werden sollte. Ein Beispielserviceprofil für einen bestimmten Service, der im Netzwerk verteilt werden soll, ist in Tabelle 2 wie folgt dargestellt:
TABELLE 2
In Tabelle 2 ist spezifiziert: ein Serviceprofilname, z. B. Servicenummernzeichen 1001 für Kunden X; Anzahl der erforderlichen Verarbeitungseinheiten, des Speichers und Plattenplatzes zur Ausführung des Services, wenn dieser instantiiert ist; ein mehrere Knoteninstatiierungsfelder mit Angabe eines Zeitraums, in dem ein bestimmter Service (beispielsweise verkörpert als ein logisches Serviceprogramm) instantiiert werden soll gemäß einer vorher festgelegten Geschäftsregel oder festgelegten Geschäftsregeln, die in der Serviceverwaltung spezifiziert sind, und ein/mehrere entsprechende/s Min/Max-Felder mit der Angabe der minima len und maximalen Anzahl dieser Serviceobjekte (SLPs), die durch NOS im spezifizierten Zeitraum instantiiert werden dürfen; ein Feld oder mehrere Felder für spezielle Erfordernisse, die z. B. anzeigen, dass der Service bestimmte Serviceknotenfähigkeiten erfordert, z. B. Sprachausgabe; und ein Service- Beginndatum und ein Service- Enddatum. Es ist leicht erkennbar, dass die SA den Service (und das Serviceprofil) von dem Beispielservice 1001 von Tabelle 2 an den Serviceknoten mit dem Serviceknotenprofil, wie in Tabelle 1 dargestellt, verteilen kann, da der Knoten eindeutig die Speichererfordernisse und die Sprachausgabe-Unterstützung aufweist. Es ist zusätzlich offensichtlich, dass der Beispielservice #1001, dargestellt im Serviceprofil in Tabelle 2, einen Datensatz von Kunden X benötigt, der unter anderem eine Sprachabspielservicenachricht, die diesem Service #1001 spezifisch ist und durch Kunden X bereitgestellt wird, erfordert. Die SA-Komponente 500 wird Daten über die Auftragseingangs- Einspeisung 307 empfangen, die die Sprachabspielnachricht von Kunden X enthält, und der Inventarmanager der SA wird es als Datensatz #1001 beiordnen, z. B. zur Speicherung in der DBOR 230. Auf diese Weise kann die SA den Datensatz #1001 automatisch an den oder die Serviceknoten, der die den Service #1001 für Kunden X bereitstellten, verteilen.
Diese Serviceknotenprofile (z. B. Tabelle 1) und Serviceprofile (z. B. Tabelle 2) sind Eingaben für die SA und dort gespeichert zum Ermöglichen automatischer Nachverfolgung von: 1) den Fähigkeiten von jedem Serviceknoten, d. h. Anzahl der Computer und SLEE(s), und die Ressourcenkapazität von jedem; 2) welche Services und Daten an welche Serviceknoten zu verteilen sind und wann; und 3) die Konfiguration der Serviceausführung, d. h. zu welchen Zeiten ein SLP beispielsweise ständig im Gegensatz zu auf-Anfrage laufen sollte. Die Fähigkeiten von jedem Knoten und Computer im Netzwerk werden unterhalten, so dass einfache und komplexe Geschäftsregeln, die die Daten/Serviceverteilung, Daten/Serviceaktivierung, Daten/Serviceentfernung regieren angewendet werden können, um die Ausführung von Services auf IDNA/NGIN Serviceknoten zu optimieren. Somit ist ein Teil der Serviceunterstütungsbereitstellungsfunktion festzustellen, welche Services als ständige Objekte (zur aktiven Ausführung), auf welcher SLEE zu instantiieren sind, mit auf einem Kriterium oder mehreren Kriterien basierenden Regeln, einschließlich beispielsweise des Lastausgleichs unter den Serviceknoten, der Effizienz des Netzwerkanruf-Routings und der Servicenachfrage. Ein Beispiel dieser Serviceunterstützungsbereitstellungsfunktion folgt nun. Da einige Services zeitsensibler als andere sind, kann das Maß an Toleranz, das Anrufen gegenüber Verzögerungen in be stimmten Servicetypen haben, benutzt werden, um festzulegen, ob dieser Service in der SLEE beispielsweise aktiv als ständiges Objekt läuft. Und ob Daten für diesen Service im lokalen Speicher zur Reduzierung von Wartezeiten zwischengespeichert werden müssen. Bei Betrachtung der Servicenachfrage kann ein bestimmter Service Spitzennachfragen z. B. nachts erfahren. Die SA 500 erlaubt es somit einem Benutzer, ein SLP für diesen Service zum aktiven Ablauf (Instantiierung als ständiges Objekt in der SLEE) von 17:00 Uhr bis 00:00 Uhr mitternachts, jeweils lokale Zeit des Standorts, z. B. zum Spezifizieren, und zu anderen Zeiten nur auf Anfrage hin, zu instantiieren. Eine Regel in der Serviceprofildatei (Tabelle 2), erzeugt durch die SA, wird dies wiedergeben.
Als ein vierter Hauptservice ist die SA-Komponente 500 für die Verteilung von Services und Daten an die lokalen funktionalen Datenmanagement- Komponenten an den ausgewählten IDNA/NGIN Systemknoten verantwortlich, in Übereinstimmung mit den durch den Benutzer spezifizierten Strategien. Diese Strategien sind als Spezifikationen im Servicepaket, das in der Servicerzeugungsumgebung 228 erzeugt wurde, verkörpert und auch als Spezifierungseingaben durch den Benutzer über die SA 500 als Teil seiner Serviceunterstützungversorgungsfunktion. Eingeschlossen in dieser Funktion ist die Fähigkeit der SA, den aktuellen Zustand (z. B. getestet, verteilt) von Daten, SIBBs und SLPs zu verfolgen. Sie verfolgt nicht nur den Zustand, sondern verfolgt zusätzlich die aktuellen Versionen von Daten, SIBBs und SLPs und den verschiedenen Komponenten (d. h. Daten, SIBBs und SLPs), die benötigt werden, um eine spezifische Version (einschließlich der verschiedenen Abhängigkeiten) eines Services zu erzeugen. In der globalen DBOR speichert die SA jede Version eines Services (d. h. einschließlich aller SLPs, die in einem Service SLP gekapselt sind) und verfolgt darüber hinaus die Konfiguration (z. B. physikalische Adresse) der verschiedenen Datenmanagement Repositories, z. B. DBOR Auszüge, im IDNA/NGIN Netzwerk.
Darüber hinaus verfolgt die SA-Komponente 500 Services und Daten, die verteilt wurden, um die Integrität zu sichern. Wenn z. B. ein Service erfolgreich an einen Knoten verteilt wurde, aber die Verteilung der für diesen Service benötigten Daten fehlschlägt, detektiert die SA dieses und versucht entweder erneut die Datenverteilung oder benachrichtigt den Benutzer. Falls nach einer vorher definierten, konfigurierbaren Anzahl von Wiederholungsversuchen das ausgewiesene Repository unfähig ist, die Verteilung zu empfangen, erzeugt die SA einen Alarm und speichert die anstehende Verteilung.
Neben der SA-Verteilungsfunktion zur Verteilung von Daten, SIBBs und SLPs an das Datenmanagement, ist die SA auch verantwortlich für: 1) Verteilung von SLPs, SIBBs und Daten an eine Netzwerkintegrations-Testumgebung für Ende-zu-Ende-Prüfung; 2) einem autorisierten Benutzer die Konfiguration einer Voreinstellungszeit für eine Verteilung zu ermöglichen; z. B. jetzt (bei Bedarf), heute Mittag, morgen 15 Uhr; 3) Auflösen von Verteilungen auf der Grundlage von einer Voreinstellungszeit; z. B. Verteilen einer Sprachdatei morgen um 1:15 Uhr; 4) Definieren von Verteilungsregeln, die bestimmen, welche NGIN Datenmanagment Repositories SLPs, SIBBs und Daten zu empfangen haben; 5) Festlegen der Standorte zum Verteilen der Daten auf der Grundlage von vordefinierten Verteilungsregeln; 6) Überprüfung des Status eines ausgewählten Repositorys (durch Abfrage der NGIN NOS Komponente) vor einer Verteilung; 7) Versuchen der Verteilung an alle ausgewählten Repositories, die eine Online-Anzeige berichten, und, falls ein ausgewähltes Repository eine Offline-Anzeige berichtet, Speichern der Verteilung für dieses Repository für zukünftige Weiterleitung; 8) Weiterleiten aller anstehenden Verteilungen an ein Repository, sobald eine Online-Anzeige von dem ausgewählten Repository, das zuvor offline war, empfangen wurde; 9) Überwachung der Verteilungen an das Datenmanagement. Wenn beispielsweise eine Verteilung für eine neue Version eines existierenden SLP, SIBB oder eine existierende Datenentität ansteht, stellt die SA sicher, dass die vorhandenen Daten im Datenmanagement nicht überschrieben werden, wenn die Verteilung empfangen wird; 10) Empfang von Statusanzeigen über eine erfolgreiche oder erfolglose Verteilung von Datenmanagement und Aktualisierung des Status von allen Daten auf der Grundlage von erfolgreicher/erfolgloser Verteilungsstatus-Anzeigen, die vom Datenmanagement empfangen wurden; und 11) Protokollieren aller Verteilungen an das Datenmanagement.
An diesem Punkt ist es notwendig, zwischen internen, zur Aktualisierung der DBOR 230 benötigten Prozessen, wie in 3(d) dargestellt, und den internen, zur Verteilung von Servicepaketen und Datenauszügen aus der DBOR, wie in 3(e) dargestellt, zu unterscheiden. Getrennte Prozesse sind erforderlich, da das Format von in der DBOR 230 unterhaltenen Daten sich vom Format der Dateneingabe von externen Quellen und vom Format von Daten in Auszügen zur Verteilung unterscheidet. Um daher aussagekräftige Prüfungen durchzuführen und die Datenintegrität und-Synchronisierung sicher zu stellen, benötigt der in 3(d) dargestellte DBOR Aktualisierungsprozess den Aufruf des Inventarmanagerprozesses 516 und des DBOR Managerprozesses 520. Wenn Daten aus DBOR herausgezogen werden an die verschiedenen SA Agenten (DM Clients) ist der Aufruf des Umgebungsmanagerprozesses 530 und des DBOR Managerprozesses 520 erforderlich, wie in 3(e) dargestellt. Somit erlaubt die Implementierung dieser getrennten Prozesse. Prüfungen der DBOR mit Daten von Eingabesystemen und Prüfungen der DBOR mit extrahierten Daten, die an das Datenmanagement verteilt werden oder verteilt wurden.
Als ein fünfter Hauptservice ist die SA-Komponente 500 für die Aktivierung von Services, die erfolgreich am Serviceknoten verteilt wurden, verantwortlich, d. h. Verfügbarmachen der Daten, SLP oder SIBB für die Serviceverarbeitung. Die mit den SA Service/Datenaktivierung zusammenhängenden Erfordernisse und die erforderliche Behandlung, wenn Fehler auftreten, schließen das Folgende ein: 1) Sicherstellen, dass alle Verteilungsabhängigkeiten (in der MOCE/SCE 228 definiert) vervollständigt wurden, bevor Erlaubnis für die Aktivierung von SLPs, SIBBs oder Daten gegeben wurde. Ein Beispiel einer Abhängigkeit kann sein, dass ein SLP die Benutzung einer spezifischen Datenbank erfordert. Die SA stellt somit sicher, dass die Datenbank verteilt und aktiviert wurde, bevor die Aktivierung des SLPs erlaubt wurde; 2) Überprüfung des Status der Verteilung an die gewählten Repositories vor der Aktivierung eines SLPs, SIBBs oder einer Datenentität; 3) Festlegen, basierend auf Verteilungsstatus, Abhängigkeiten, Vollständigkeitsstatus und vordefinierten Verteilungsregeln, ob die zuvor verteilten Daten an allen Standorten, die die Verteilung erfolgreich empfangen haben, aktiviert werden kann. Wenn die SA festlegt, dass die Datenverteilung aktiviert werden kann, wird die SA versuchen, eine Aktivierungsanfrage an das Datenmanagement zu senden; 4) Überprüfung des Status eines gewählten Repositorys (durch Abfrage des NGIN NOS) vor Versendung der Aktivierungsaufforderung; 5) Aktivierung auf allen gewählten eine Online-Anzeige berichtenden Repositories und, falls ein gewähltes Repository eine Offline-Anzeige berichtet, Speichern der Aktivierungsaufforderung für dieses Repository zur zukünftigen Weiterleitung und ohne Aktivierungsversuch auf diesen Repository. Wenn ein gewähltes Repository eine Online-Anzeige berichtet und aus irgendeinem Grund unfähig ist, die Aktivierungsaufforderung zu verarbeiten, versucht die SA die Aktivierung zu diesem Repository erneut. Falls nach einer vordefinierten, konfigurierbaren Anzahl von Wiederholungsversuchen das ausgewählte Repository unfähig ist, die Aktivierungsaufforderung zu verarbeiten, erzeugt die SA einen Alarm und speichert die ausstehende Aktivierung. Sobald eine Online-Anzeige von einem Repository empfangen wird, das vorher offline war, leitet die Serviceverwaltung alle ausste henden Verteilungen und Aktivierungen an dieses Repository weiter; und 6) Empfangen von Aktivierungsantworten vom Datenmanagement. Wenn eine Aktivierungsaufforderung Erfolg bei allen gewählten Repositories anzeigt, registriert die SA den System-eindeutigen Namen der Daten, des SIBBs oder des SLPs und den physikalischen Standort der Information beim NOS. Es sollte verstanden werden, dass der physikalische Standortname eine Identifikation des Hardware-Komponentennamens einschließt.
In der bevorzugten Ausführungsform legt die SA auf der Grundlage vordefinierter Verteilungsregeln und der vom Datenmanagement 600 empfangenen Aktivierungsantworten fest, ob die Daten an ausreichend vielen Standorten aktiviert wurden, um sie für verwaltete Objekte der Servicesteuerung verfügbar zu machen. Falls die Serviceverwaltung festlegt, dass die Daten für die Servicesteuerung verfügbar gemacht werden können, registriert die SA den System-eindeutigen Datennamen und physikalische Datenstandorte aller erfolgreichen Verteilungs- und Aktivierungsstandorte beim NOS. Falls die aktivierten Daten im Netzwerk existierende Daten ersetzen sollen, stellt die SA einen glatten Übergangsprozess zum Beenden von existierender Serviceverarbeitung auf alten Daten sicher, während sie die neue Serviceverarbeitung auf den neuen Daten intiiert. Die alten Daten werden deaktiviert, sobald sämtliche Serviceverarbeitung auf ihr nen beendet ist, wie später hierin genau beschrieben werden wird.
Spezieller implementiert die SA im Rahmen des Service-/Datenaktivierungsschrittes ein Auslösesignal, das das Herunterladen des Serviceprofils zu der passenden Zeit verursacht. Wenn ein Serviceprofil (z. B. wie in Tabelle 2 gezeigt) an einem Serviceknoten heruntergeladen wird, enthält das Serviceprofil den Beginn- und Endzeitpunkt des Services. Das Serviceprofil wird an den Serviceknoten durch Bereitstellen der Information im Datenmanagement heruntergeladen, wie genauer mit Bezug auf 3(f) beschrieben wird. Das als DM-Client agierende NOS wird über die Änderung in der Serviceprofilinformation über die DM API benachrichtigt. In einer bevorzugten Ausführungsform sendet die SA eine Nachricht an eine NOS Namenübersetzungs („NT") Funktion in jeder SLEE, auf der der Service abläuft, um eine Namensübersetzungsfunktion anzuweisen, den logischen Namen für den Service mit der physikalischen Adresse oder Objektreferenz der Version, die aktiviert wird, neu zu verknüpfen.
Schließlich verfolgt die SA die Repository-Plattform-Eigenschaften, um sicherzustellen, dass, wenn Daten, SIBBs oder SLPs aktiviert werden, diese auf der passenden Plattform arbeiten; die SA aktualisiert den Status von Daten, SIBBs oder SLPs auf der Grundlage von Aktivierung oder Deaktivierung; und protokolliert alle Aktivierungen von Daten, SLPs und SIBBs in der Überwachungslogik-Komponente 540 (3(c)).
Gemäß dieser fünften SA Funktion wird nun eine Erklärung, wie das IDNA/NGIN System die Serviceerstellungs- und Einsatzphasen handhabt, mit Bezug auf die 5(g) und 5(h) bereitgestellt, welche ein Szenario von Schritten beim Erstellen und Einsetzen eines SLPs für das IDNA/NGIN System, z. B. für einen 1-800 Collect („1-800-C") Service, darstellt. Wie in den Schritten 812 in 3(g) angedeutet, ermöglicht es das MOCE/SCE Anwendungsprogamm dem Benutzer, von der SA auf alle SIBBs, SLPs, Daten und andere Baublöcke, die für die Erzeugung des 1-800-C SLPs notwendig sind, zuzugreifen. In dem als Beispiel dienenden Kontext eines 1-800-C Services können solche Baublöcke umfassen: einen Audioabspiel-Baublock, einen Ziffernaufnahme-Baublock und einen Spracherkennungs-Baublock. Kopien dieser geeigneten Baublöcke werden aus der globalen DBOR 230 durch die SA zur MOCE/SCE gezogen, um die Grundlage für die Entwicklung des 1-800-C Servicelogikprogramms, wie in Schritt 814, 3(g), angedeutet bereitzustellen. Dann, wie in Schritt 819 angedeutet, werden das 1-800-C Servicelogikprogramm und alle zugehörigen Daten wie Sprachdateien, als Einheit getestet innerhalb der MOCE/SCE Umgebung. Wie als nächstes in Schritt 820 angedeutet, wird das 1-800-C Servicelogikprogramm von einem Ende zum anderen in einer Laborumgebung, die dem Echtzeit MCI Netzwerk nahekommt, getestet, um sicherzustellen, dass das Servicelogikprogramm korrekt abläuft, wenn es einmal im Netzwerk verteilt ist. Dann, wie in Schritt 823 angedeutet, wird das 1-800-C Servicelogikprogramm der Serviceverwaltung zwecks Namensgebung und Katalogisierung in der hierin im Detail beschriebenen Weise vor seiner Verteilung übergeben.
Wie hierin beschrieben, erlaubt die Serviceverwaltungskomponente das Einführen von Regeln, die die Verteilung von Daten und Informationen, Datenaktivierung und Datenentfernung bestimmten. Somit, wie in Schritt 826 angedeutet, überprüft die SA-Komponente die Regeln, die die Datenmanagement Repositories spezifizieren, die das Servicelogikprogramm empfangen sollen, und die die Mindestanzahl von Repositories, die die Verteilung empfangen müssen vor Aktivierungserlaubnis des 1-800-C SLPs, betreffenden Regeln. Um dies zu tun, über prüft die Serviceverwaltung, wie in Schritt 830 angedeutet, den Status der Datenmanagement Repositories durch Zugriff auf die NOS Netzwerk-Ressourcen-Managementfunktion. Dann, wie in Schritt 832, 3(h) gezeigt, bestimmt die Serviceverwaltungskomponente diese DM Repositories, die einen „Online"-Status anzeigen und, in Schritt 835 verteilt das 1-800-C SLP an alle DM Repositories, die online sind. Für die Repositories, die einen Offline-Status berichten, speichert die Sericeverwaltung die Verteilung zur zukünftigen Weiterleitung an die Offline-Repositories, wie in Schritt 837 angedeutet. Dann, wie in Schritt 840 angedeutet, wartet die Serviceverwaltungskomponente, bis das Datenmanagement einen Status für jedes Repository mit der Anzeige über Erfolg oder Misserfolg der Distribution zurückgibt. Eine Feststellung wird in Schritt 842 gemacht, um festzustellen, ob die Bestätigung von dem jeweiligen DM Repository empfangen wird. Wenn die Bestätigung nicht empfangen wurde, wartet die SA auf die Bestätigung, wie in Schritt 844 angedeutet. Sobald die Bestätigung empfangen wird, geht der Prozess mit Schritt 845 weiter, wo eine Feststellung durch die Serviceverwaltung gemacht wird, ob das 1-800-C SLP in allen Repositories aktiviert werden kann, an denen die Verteilung erfolgreich empfangen wurde.
Insbesondere basiert die Festlegung der Serviceverwaltung, ob das 1-800-C SLP aktiviert werden darf, auf der Kombination der folgenden Aktivierungskriterien: 1) dem Verteilungsstatus, 2) dem Datenabhängigkeitsstatus und 3) vordefinierten Regeln. Dies ist so, weil die Serviceverwaltung 500 die Funktion des Sicherstellens erfüllt, dass alle Datenabhängigkeiten des Servicelogikprogramms vervollständigt sind; d. h. verteilt und aktiviert vor der Aktivierungserlaubnis eines von diesen Daten abhängigen SLPs. Wenn somit im Beispielkontext das 1-800-C SLP ein anderes Servicelogikprogramm (z. B. ein Schnittstellen SLP zu einer Leitungsinformationsdatenbank) während seiner Ausführung benutzt, stellt die Serviceverwaltung sicher, dass das andere SLP oder die Datenbank vor der Aktivierungserlaubnis des 1-800-C SLPs verteilt und aktiviert wurde. Es sollte verstanden werden, dass einige Services selbst dann aktiviert werden können, wenn nicht alle ausgewählten Repositories die Verteilung des Servicelogikprogramms empfangen. Dies hängt von mehreren Faktoren ab, darunter: das zu erwartende Anrufvolumen und die Servicequalität, wie sie in der Verteilung und in den Aktivierungsregeln in der SA spezifiziert sind. Zum Beispiel kann es für einen bestimmten Service mit gertngem Anrufvolumen ausreichend sein, in nur zwei DM Repositories im Netzwerk gespeichert zu sein, bevor er aktiviert wird, während andere es erfordern, dass der Service in allen gewählten Repositories vorhanden ist, bevor er für den Empfang von Netzwerkverkehr aktiviert werden kann.
Somit wird in 3(h), Schritt 847, auf der Grundlage der Erfüllung von Aktivierungskriterien eine Festlegung getroffen. Wenn das SLP nicht aktiviert werden kann, wird die SA warten, bis die SLP-Aktivierungskriterien erfüllt sind, wie in Schritt 848 angedeutet. Andernfalls, wie in Schritt 852 angedeutet, sendet die SA eine Aktivierungsaufforderung zu allen ausgewählten Datenmanagement-Repositories. Dann, wie in Schritt 854 angedeutet, verarbeitet das Datenmanagement die Aktivierungsaufforderung und leitet die Aktivierungsantwort für jedes Repository an die Serviceverwaltung weiter unter Anzeige des Erfolgs oder Misserfolgs der Aktivierung. Auf der Grundlage der vom Datenmanagement empfangenen erfolgreichen Aktivierungsantworten registriert die Serviceverwaltung den System-eindeutigen Namen und die physikalischen Datenstandorte des 1-800-C SLPs beim NOS, wie in Schritt 855 angedeutet, und nun ist der 1-800-C Service im Beispielkontext für die Benutzung verfügbar. Sämtliche Datenrepositories, denen es nicht möglich war, die Verteilung und/oder Aktivierung des 1-800-C SLPs zu empfangen, werden vom NOS nicht als gültige physikalische Datenstandorte für dieses Servicelogikprogramm registriert.
Als sechster Hauptservice sorgt die SA-Komponente 500 für die Außerbetriebnahme und Entfernung von Servicekomponenten von Serviceknoten, genauso wie die SA die Verteilung und Aktivierung von Servicekomponenten ermöglicht. Die beteiligten Hauptschritte sind Planung, Deaktivierung, Deinstallierung und/oder Außerbetriebnahme von zugehörigen Teilen und das Testen auf nachteilige Konsequenzen. Zum Beispiel wird die Serviceverwaltung, nach einer Periode der Serviceinaktivität oder wenn ein Service an einem bestimmten Knoten nicht mehr gebraucht wird, wie von einem Benutzer spezifiziert, den Service entfernen, d. h. deaktivieren, typischerweise durch Senden einer Nachricht an das NOS NT, das die Entfernung eines Services vom IDNA/NGIN Serviceknoten durch Senden einer Nachricht an die lokale Datenmanagement-Komponente zum Löschen dieses Services ermöglicht. Die mit der SA Funktion der Deaktivierung und Entfernung von Services/Daten zusammenhängenden Erfordernisse schließen ein: 1) Befähigung eines autorisierten Benutzers, um die Deaktivierung eines SLPs, SIBBs oder einer Datenentität anzufordern und einen Zeitpunkt für eine Deaktivierung anzugeben; 2) Überprüfung des Status und der Datenabhängigkeiten des SLPs, SIBBs oder der Daten vor Weiterleitung einer Deaktivierungsaufforderung an das Datenmanagement. Wenn der Status des SLPs, SIBBs oder der Daten aktiv ist, und keine Datenabhängigkeiten bestehen, entregistriert die SA das SLP, SIBB oder die Daten beim NOS bei Erreichen des angegebenen Zeitpunkts, was das SLP, den SIBB oder die Daten für die Serviceverarbeitung nicht länger verfügbar macht; 3) nach Beendigung der Namensentregistrierung beim NOS, Weiterleitung einer Deaktivierungsaufforderung des spezifischen SLPs, SIBBs oder Datenelements an das Datenmanagement. Wenn der Status des SLPs, SIBBs oder der Daten nicht aktiv ist oder, wenn Datenabhängigkeiten existieren, ignoriert die SA die Deaktivierungsaufforderung und benachrichtigt den Auffordernden; 4) Protokollierung aller Deaktivierungen von Daten, SLPs und SIBBs; 5) Befähigen eines autorisierten Benutzers, die Entfernung eines SLPs, SIBBs oder einer Datenentität anzufordern und einen Zeitpunkt für die Entfernung anzugeben; und 6) Überprüfung des Status des SLPs, SIBBs oder der Daten vor Weiterleitung einer Entfernungsaufforderung an das Datenmanagement. Wenn der Status des SLPs, SIBBs oder der Daten deaktiviert ist, leitet die SA die Entfernungsaufforderung an das Datenmanagement bei Erreichen des spezifizierten Zeitpunktes weiter. Wenn der Status des SLPs, SIBBs oder der Daten nicht deaktiviert ist, ignoriert die SA die Entfernungsaufforderung und benachrichtigt den Anfordernden; und 7) Protokollierung aller Entfernungen von Daten, SLPs und SIBBs aus dem Datenmanagement.
Wie oben mit Bezug auf die Service/Datenaktivierung beschrieben, verursacht ein Auslösesignal in der SA 500 die SA, den Befehl zum Löschen des Serviceprofils aus dem Serviceknoten zum passenden Zeitpunkt herunterzuladen. Dieser Befehl wird an den Serviceknoten durch einen Befehl an das Datenmanagement 600 geliefert. Das Datenmanagement aktualisiert seine Tabellen, was dazu führt, dass das als DM Client agierende NOS die Benachrichtigung über die Serviceänderung empfängt.
3(i) stellt den Servicedeaktivierungsprozess mit Bezug auf das Beispiel eines bereitgestellten 1-800 Collect SLP Services dar. Wie in 3(i) gezeigt, ist der erste Schritt 860 mit der Entscheidung verbunden, das 1-800-C Serviclogikprogramm abzuziehen und mit der Benutzung der MOCE/SCE zur Überprüfung des Ausmaßes des 1-800-C Servicelogikprogramms verbunden. Dann, wie in Schritt 862 angedeutet, verifiziert die SA die den Abzug des 1-800-C Servicelogikprogramms betreffenden Regeln. Insbesondere prüft die Serviceverwaltung, um sicher zu stellen, dass keine Abhängigkeiten anderer aktiver Servicelogikprogramme von dem 1-800-C Servicelogikprogramm bestehen. Wenn Abhängigkeiten existieren, ist eine weitere Untersuchung erforderlich, um festzustellen, ob die abhängigen Serviclogikprogramme tatsächlich notwendig sind, und der Planungsschritt wird wiederholt. Wenn keine Abhängigkeiten bestehen, wird die Serviceverwaltung einen autorisierten Benutzer befähigen, einen Zeitpunkt für die Deaktivierung anzugeben. Sobald festgestellt wurde, dass das SLP abgezogen werden kann, sendet die SA eine Deaktivierungsaufforderung an alle das 1-800-C SLP enthaltenden Datenmanagement Repositories, wie in Schritt 865 angedeutet. Das Datennmanagement verarbeitet die Deaktivierungsaufforderung, wie in Schritt 867 angedeutet, und sendet eine Deaktivierungsantwort an die SA unter Anzeige des Erfolgs oder Misserfolgs der Deaktivierung. Nach einer erfolgreichen Deaktivierung des 1-800-C SLPs entregistriert die SA das 1-800-C SLP beim NOS, wie im Schritt 868 angedeutet, um sicher zu stellen, dass das 1-800-C SLP für die Serviceverarbeitung nicht länger zur Verfügung steht. Zukünftige Serviceanforderungen werden also nicht in der Lage sein, das 1-800-C SLP zu benutzen. Dann erlaubt, wie in Schritt 869 angedeutet, die SA einem autorisierten Agenten, einen Zeitpunkt für die Entfernung aller 1-800-C SLPs von allen Datenmanagement Repositories, in denen diese sich aufhalten, anzugeben. Sobald der angegebene Zeitpunkt kommt, sendet die SA eine Entfernungsaufforderung an alle das 1-800-C SLP enthaltenden Datenmangement Repositories und, wie in Schritt 870 angedeutet, löscht das Datenmanagement das 1-800-C Servicelogikprogramm von seinen Repositories, wodurch der 1-800-C Service nicht länger verfügbar gemacht wird.
Als siebenten Hauptservice ist die SA-Komponente 500 verantwortlich für das Durchführen von Prüfungen. Bevor ein Service oder eine Datenentität in die DBOR eingegeben wird, prüft die Serviceverwaltung diese Entität bezüglich anderer bereits benutzter Service/Datenentitäten, um sicher zu stellen, dass keine Konflikte bestehen. Auf die gleiche Weise wird, bevor eine Service-/Datenentität an Serviceknoten verteilt wird, diese geprüft, um sicher zu stellen, dass keine Konflikte bestehen. Die Serviceverwaltung sorgt sowohl für Prozess ausgelöste Prüfungen als auch Zeitplan ausgelöste Prüfungen von sowohl Services als auch Daten in der DBOR 230, die an Serviceknoten eingesetzt werden. Eine Prozess-getriggerte Prüfung ist eine Prüfung, die als Resultat eines unerwarteten Fehlers gestartet wird. Wenn zum Beispiel die SA versucht, ein Serviceprofil herunterzuladen und das Herunterladen wird zurückgewiesen, weil das Profil bereits existiert, startet die SA eine Prüfung, um festzustellen, was zu tun ist. Zum Beispiel vergleicht die SA den bereits existierenden Service mit dem, der zum Herunterladen vorgesehen ist, um festzustellen, ob sie gleich oder unterschiedlich sind.
Wenn sie gleich sind, kann die Prüfung hier beendet werden. Wenn sie unterschiedlich sind, startet der Prüfungsprozess eine Löschung des existierenden Profils und lädt dann das korrekte herunter. Zeitplan ausgelöste Prüfungen werden in Übereinstimmung mit einem vordefinierten Zeitplan ausgelöst oder in Übereinstimmung mit programmierten Regeln, die Prüfungsroutinen während Systemleerlaufzeiten starten oder auf Anfrage durch einen Benutzer. Diese SA Prüfungsregeln werden als kompilierter Code im SA System 500 gehalten und als übersetzte Regeln, die innerhalb des SA Systems verarbeitet werden.
Nun mit Bezug auf 3(f) wird die Datenmanagement-Komponente 600 der SA-Komponente gezeigt, die lokale Datenspeicherungs- und Managementfunktionen für jeden IDNA/NGIN Serviceknoten bereitstellt. Insbesondere speichert das Datenmanagement von der Serviceverwaltung empfangene Daten in einer oder mehreren Datenbanken und macht Services/Daten unmittelbar für die Servicesteuerungsumgebung verfügbar durch Zwischenspeicherung der benötigten Daten in einem Speicher, der in den Servicesteuerungscomputern residiert, oder auf einem daneben angesiedelten Datenbankserver, so dass die Services/Daten mit minimaler Verzögerung an den Service Steuerungsservice bereitgestellt werden können. Allgemeiner führt die Datenmangagement-Komponente 600 die Echtzeitspeicherung, Replikation, Synchronisation und Verfügbarkeit von Daten aus, egal ob sie von der Serviceverwaltung oder als ein Resultat der Serviceverarbeitung empfangen wurden. Diese Datenmanagementfunktionen können weiterhin kategorisiert werden als: 1) eine Datenrepositoryfunktion; 2) eine Datenmanipulationsfunktion; 3) eine Datenhilfsfunktion; und 4) eine Rechnungssatzerzeugungsfunktion.
Datenrepositoryfunktion
Die Datenrepositoryfunktion umfasst alle spezifischen Funktionalitäten, die für die Speicherung von IDNA/NGIN Daten erforderlich sind. Allgemein ist ein Repository eine physikalische Einrichtung, die alle unterschiedlichen Typen von Informationen speichert; z. B. Sprachdateien, Objekte, SLPs, SIBBs und Datenbanken. In der Verwaltung von Datenrepositories berücksichtigt die Datenmanagementfunktionaliät die Sicherheit. Und das Fehler- und Konfigurationsmanagement von Repositories.
Der Repositoryspeicherungsaspekt des Datenmanagements schließt die Fähigkeit ein: 1) beständige Daten, SIBBs, SLPs, Audiodateien, Anrufkontextdaten, Zeitplandaten, Konfigurationsdaten, Namensservicedaten, Textdateien, z. B. Faxe, zu speichern; 2) Zurückhalten von spezifizierten Daten für eine konfigurierbare Zeitspanne, z. B. Anrufkontextdaten können vor ihrer Löschung aus den Repositories für einige Tage gespeichert werden; 3) Automatisches Löschen von spezifizierten Daten aus den Repositories nach Ablauf der Zurückhaltungszeitspanne; und 4) Bereitstellen von Unterstützung für mehrere Versionen von Repository Daten.
Als Teil der Speicherungsfunktion kann das Datenmanagement 600 den Status seiner Repositories überprüfen, um sicher zu stellen, dass Anfragen und Verteilungen nur auf Online-Repositories gemacht werden. Wenn also ein Repository offline genommen wird, werden Anfragen und Verteilungen an dieses Repository nicht versucht werden. Als Teil dieser Funktion kann das Datenmanagement: den Status der Repositories abfragen, z. B. Ermitteln eines Benutzungsstatus, welcher eine Anzeige dafür bereitstellt, wie belegt jedes Repository in Hinsicht auf die Anzahl von momentan verarbeiteten Transaktionen ist; Weiterleitung der Repository Statusinformation an das NOS 700 bei der Initialisierung und sobald Statusänderungen auftreten; Bereitstellen eines Alarms, falls ein Repository offline genommen wird oder nicht funktioniert; und das NOS 700 benachrichtigen, dass keine weiteren Anfragen oder Aktualisierungen an ein eine Offline-Anzeige berichtendes Repository gesendet werden sollten.
Des weiteren sorgt das Datenmanagement als Teil der Speicherungsfunktion für Konfigurationsmanagement, Fehlermanagement und Protokollmanagement der Datenrepositories. Die mit dem Konfigurationsmanagement zusammenhängende DM Funktion befähigt einen autorisierten Benutzer: das Schema der Datenrepositories zu definieren und zu erweitern; für ein Repository zugeteilte Systemressourcen einzusehen und zu modifizieren; und die Indizierungsstrategien eines Repositorys einzusehen und zu modifizieren. Die mit der Fehlerdetektion und Berichtgenerierung für den Unterhalt von Datenrepositories zusammenhängende DM Funktion schließt ein: Ermöglichen der Definition von Fehlerschwellwerten und Benachrichtigungen für die einem Repository zugeteilten Systemressourcen; Ermöglichen der Detektion und des Berichtens von Medienfehlern innerhalb eines Repositorys; Ermöglichen der Definition von Fehlerschwellwerten und Benachrichtigungen für die prozentuelle Auslastung der Kapazität eines Repositorys; Ermöglichen der Definition von Fehlerschwellwerten und Be nachrichtigungen für die prozentuale Füllung eines Protokolls eines Repositorys; und Bereitstellen einer Benachrichtigung, wenn ein Repository oder eine seiner Komponenten (z. B. Schema, Repositorydaten) beschädigt ist. Die mit dem Aufstellen und der Verwaltung von Protokollen auf den dem Datenmanagement gehörenden Repositories zugeordneten DM Funktionen schließen ein: das Vermögen, die Fähigkeiten von Repositories zu protokollieren einschließlich der folgenden Typen von Protokollen: a) Transaktionsprotokolle; b) Fehlerprotokolle; und c) Ereignisprotokolle, und Sicherung dieser Protokolle auf einem externen Medium. Bezüglich der Protokollierungsfunktion kann das Datenmanagement Protokolldaten für eine konfigurierbare Zeitspanne zurückhalten, bevor das Protokoll reinitialisiert wird. Zusätzlich kann ein autorisierter Benutzer Eigenschaften (z. B. Größe, Feldbeschreibungen, Ereignisberichte) von Protokollen eines Repositorys einsehen und modifizieren und die in jedes Protokoll zu schreibenden Daten spezifizieren. Zum Beispiel mag ein Benutzer auf Grund des Transaktionsvolumens nur das Festhalten von „write" Transaktionen im Transaktionsprotokoll wünschen, an Stelle aller Transaktionen.
DM Manipulationsfunktion
Die Datenmanipulationsfunktion des DM umfasst sämtliche spezifischen Funktionalitäten, die für den Empfang von Verteilungen von Daten, die Replikation von Daten über Repositories hinweg, das Abfragen, das Wiedergewinnen und die Aktualisierung von Daten in Repositories, Starten von Abbruch- und Rückgängigmachungstransaktionen und zur Durchführung von Datenprüfungen erforderlich sind. Diese Funktionalität kann auf die folgenden Gebiete aufgeteilt werden: a) Datenverteilung; b) Datenreplikation; c) Datenwiedergewinnung und -Aktualisierung; d) Datentransaktionen; und e) Datenprüfungen, von welchen jedes hierin beschrieben wird.
Datenverteilung
Datenverteilung, wie sie hierin definiert ist, bezieht sich auf die Ausgabe von Daten oder Services von der Serviceverwaltung an das Datenmanagement 600. Hinsichtlich der Datenverteilungsfunktion empfängt das DM Datenverteilungen von der Serviceverwaltung; berichtet über den Zustand von im System ausgebrachten Daten; macht Daten für die Benutzung durch Services verfügbar; und deaktiviert und entfernt vom Datenmanagement gespeicherte Daten.
Insbesondere, wie durch die Komponenten Datenserver, DDAPI, DBOR-Auszugsrepository und DBOR-Auszugsmanager (3(f)) von DM 600 verkörpert, ist das Datenmanagement befähigt, Verteilungen von Daten, Dateidefinitionen, SLPs und SIBBs von der Serviceverwaltung zu empfangen. Wenn die Kapazität des Repositorys überschritten wird, werden jedoch sämtliche weiteren Versuche, Datenverteilungen zu empfangen, fehlschlagen, ohne dass der Zugriff auf Daten im Repository blockiert wird. Als Antwort auf eine Verteilung von Daten vom DM an die SA, antworten im DM-Server ablaufende Prozesse mit einem Signal, das den Erfolg oder Misserfolg der Verteilung anzeigt. Falls ein Datenverteilungsmisserfolg aufgetreten ist, kann das DM eine beliebige Portion der Verteilung, die schon vollständig war, wieder rückgängig machen. Wie beschrieben, wird ein Aktivierungsaufforderungssignal von der SA verteilt, um anzuzeigen, dass die Daten erfolgreich zu einer Mindestanzahl von Repositories verteilt wurden und für die Serviceverarbeitung „aktiv" gemacht werden sollen. Das Datenmanagement antwortet auf den Empfang einer Aktivierungsaufforderung mit einer Aktivierungsantwort, die den Erfolg oder Misserfolg anzeigt, und bei einer jeweiligen erfolgreichen/fehlgeschlagenen Aktivierung der Daten, des SIBBs oder des SLPs an die Serviceverwaltung zurückgeschickt wird. Das DM ist auch fähig, eine Deaktivierungaufforderung von der Serviceverwaltung zu empfangen und zu verarbeiten, die von der SA gesendet wird, um spezifische Daten, einen SLP oder einen SIBB für die Serviceverarbeitung unverfügbar zu machen. Das Datenmanagement antwortet auf die Deaktivierungsaufforderung mit einer Deaktivierungsantwort, die den Erfolg oder Misserfolg der angeforderten Deaktivierung an die Serviceverwaltung anzeigt.
Gleichermaßen ist das DM zusätzlich fähig, ein Entfernungsaufforderungssignal von der Serviceverwaltung zu empfangen und zu verarbeiten, welches spezifiziert, dass das DM spezifische Daten von einem ausgewählten Repository entfernen soll. Das DM sendet eine Entfernungsantwort, die den Erfolg oder Misserfolg einer Entfernungsaufforderung zurück an die Serviceverwaltung anzeigt. Es sollte verstanden werden, dass Aktivierungs-, Deaktivierungs- und Entfernungsaufforderungen für ein SLP, einen SIBB oder eine Datenentität gelten können.
Datenreplikation
Die Datenreplikationsfunktion des DMs schließt alle spezifischen Funktionalitäten, die für das Replizieren von Daten zu spezifischen Standorten, d. h. Serviceknoten Datenrepositories, d. h. lokale Server Zwischenspeicher, und für die Benachrichtigung des NOS über erfolgreiche/misslungene Replikationen nötig sind. Das IDNA/NGIN System repliziert Daten auf der Grundlage von definierten Replikationsvorgehensweisen, die von SA Konfigurationsdateien bereitgestellt werden. Wie hierin beschrieben, bezieht sich der Term „Replikation" auf den Vorgang des Kopierens von Daten von einem Repository zu einem anderen für Daten, die im Rahmen der Serviceverarbeitung geschrieben werden.
Zum Beispiel repliziert das Datenmanagement Daten an andere Repositories, wenn Daten während der Serviceverarbeitung aktualisiert werden. Zunächst stellt das Datenmanagement eine Reihe von Standorten fest, wo Daten zu replizieren sind auf der Grundlage von aufgestellten Replikationsregeln, die der SA in Konfigurationsdateien für die Datenentität zur Verfügung gestellt werden, und stellt sicher, dass Versuche, Repositorydaten zu replizieren, wenn die Kapazität des Zielrepositorys überschritten wurde, fehlschlagen, ohne dass der Zugriff auf die bestehenden Daten in dem Repository blockiert wird. Wenn die Replikation auf Grund von überschrittener Kapazität fehlschlägt, benachrichtigt das Datenmanagement die NOS Komponente, dass die spezifischen Daten in diesem Repository nicht verfügbar sind, um sicher zu stellen, dass keine weiteren Versuche der Replikation an dieses Repository ausgeführt werden. Wenn eine Replikation an ein Repository fehlschlägt aus anderen als Kapazitätsgründen, kann das Datenmanagement die fehlgeschlagene Replikation für das Repository versuchen. Wenn nach einer vordefinierten, konfigurierbaren Anzahl von Wiederholungsversuchen das Repository immer noch unfähig ist, die Replikation zu empfangen, erzeugt das Datenmanagement einen Alarm und benachrichtigt die NOS Komponente, dass die spezifischen Daten, die gerade repliziert werden, an diesem Repository nicht verfügbar sind. Dies stellt sicher, dass auf diesen Daten an diesem Standort keine Abfragen gemacht werden. Ein Synchronierungshilfsprogramm kann somit implementiert werden, um die Repositories wieder zurück in die Synchronisation zu kriegen.
Datenabruf und Aktualisierung
Die Datenabruf- und -Aktualisierungsfunktionabilität schließen die Fähigkeit ein, auf vom Datenmanagement während der Serviceverarbeitung gespeicherte Daten zuzugreifen.
In der bevorzugten Ausführungsform empfängt das Datenmanagement an jedem bestimmten Serviceknoten Datenanforderungen von einer ablaufenden verwalteten Objektinstanz in der SLEE, d. h. durch das NOS, während der Serviceverarbeitung. Das Datenmanagement benachrichtigt den Anfrager (z. B. verwaltetes Objekt), falls es unfähig ist, die Datenanfrage zu verstehen. Falls die Datenanfrage für den Abruf einer Datenentität ist, gibt das Datenmanagement die angeforderten Daten an den Anfrager (z. B. über das NOS) zurück. Es sollte verstanden werden, dass jede Unterstützung, die für die Manipulation und das Abfragen von Daten in einem einzelnen Repository oder über mehrere Repositories vom DM bereitgestellt wird. Das Datenmanagement unterstützt zusätzlich die Sammlung und das Zusammentragen von Ergebnissen von über mehrere Repositories gehenden Abfragen. Falls das DM unfähig ist, den Namen der angefragten Entität in der Datenabrufanfrage zu lokalisieren, benachrichtigt DM die NOS Komponente. Die NOS Komponente wird auch benachrichtigt werden, wenn ein Datenbankfehler auftritt während des Abrufs einer Datenentität. Das Datenmanagement benachrichtigt zusätzlich den Anfrager (das ablaufende Servicesteuerungsobjekt) über die Unfähigkeit, eine spezifische Datenentität von einem gültigen Namen abzurufen. Wenn die Datenanfrage für die Aktualisierung einer Datenentität ist, aktualisiert das Datenmanagement die Datenentität und stellt fest, ob eine Replikation erforderlich ist. Das DM benachrichtigt den Anfrager, falls es unfähig ist, die in einer Datenanfrage spezifizierte Datenentität zu aktualisieren und benachrichtigt zusätzlich das NOS, falls es unfähig ist, den Namen der angeforderten Entität in der Datenaktualisierungsabfrage zu lokalisieren. Während des gesamten NGIN Betriebs benachrichtigt das DM das NOS über einen Datenbankfehler während der Aktualisierung einer Datenentität. Wenn die Datenabfrage für die Entfernung einer Datenentität ist, löscht das DM das Datenelement und stellt fest, ob die Transaktion auf anderen Repositories ausgelöst werden muss.
Datentransaktionen
Eine Transaktion ist definiert als eine Sequenz von Operationen auf einem Satz von Daten, die die Daten von einem schlüssigen Zustand in einen anderen schlüssigen Zustand transformiert. Beispiele von Transaktionen schließen ein: Dateneingabe, Aktualisierung bestehender Daten, Löschen von Daten und Kopieren von Daten. Im Kontext eines IDNA/NGIN Systems ist das DM fähig, eine Transaktion auf einem Repository auszulösen, eine ausgelöste Trans aktion abzubrechen, für Benachrichtigung zu sorgen, falls ein Transaktionsfehler auftritt, und alle Transaktionsfehler zu protokollieren. Das Datenmanagement implementiert zusätzlich eine Wiederherstellungsstrategie durch Zurückführen der von einer Transaktion gesteuerten Daten in deren vorherigen Zustand, als Ergebnis eines Transaktionsfehlers, und eine fehlgeschlagene Transaktion erneut auszuführen, als Ergebnis eines Transaktionsfehlers. Jede implementierte Wiederherstellungsstrategie kann zum Zeitpunkt der Transaktionsauslösung oder beim Auftritt des Fehlers definiert werden.
Das Datenmanagement ist weiterhin ausgestattet, um es einer Transaktion zu ermöglichen, in ein Time-Out zu laufen und somit fehlzuschlagen gemäß einem vorher festgelegten Time-Out Parameter, der zum Zeitpunkt der Transaktionsauslösung spezifiziert wird. Weitere Datentransaktionsfunktionalität schließt ein: die Fähigkeit, an mehreren Transaktionen gleichzeitig teilzunehmen; die Bereitstellung eines Auflösungsmechanismus für Transaktionsgleichzeitigkeit, der die Blockierung von Gleichzeitigkeitskollisionen mit Einreihung von anhängigen Transaktionen unterstützt; die Erzeugung eines Anzeigesignals, ob irgendwelche Transaktionsdaten außerhalb des Transaktionskontextes modifiziert werden (d. h. beschädigt werden); die Fähigkeit, den Zustand ihrer Daten zurück abzuwickeln, während sie an einer Transaktion teilhat; und die Fähigkeit, alle Operationen zurück abzuwickeln, während sie an einer Transaktion teilhat.
Datenüberprüfung
Die Datenüberprüfungsfunktionalität des IDNA/NGIN Systems schließt die Bereitstellung einer Überprüfungs-/Wiederherstellungsumgebung für Repository-Daten ein. Im Kontext des Datenmanagements ist ein „Audit" der Prozess des Testens der Synchronisation zwischen zwei oder mehreren Kopien von Repository-Daten und der Ergebnisberichtung. "Wiederherstellung" ist der Satz von Aktionen, die als Ergebnis auf ein Audit ergriffen werden, um die Kopien in Synchronisation zu bringen. Wie hierin beschrieben, können alle Daten, die beständig gemacht wurden und/oder repliziert wurden, geprüft werden. Zusätzlich wird angenommen, dass ein primäres Kopiermodell aufgestellt wird und als korrekt angesehen wird, zum Zwecke des Audits und der Wiederherstellung. Das Datenmanagement ist somit in der Lage, die primäre Kopie eines Repositorys zu bestimmen. Im NGIN Kontext ist das DM weiterhin in der Lage, Daten über mehrere Repositories hinweg zu prüfen, alle Prüfungsdiskrepanzen zu protokollieren, eine Benachrichtigung über Prüfungsdiskrepanzen bereit zu stellen und eine automatische Wiederherstellung auf der Grundlage von einem definierten Regelsatz bezüglich einer identifizierten Diskrepanz bereit zu stellen. In der bevorzugten Ausführungsform kann das Datenmanagement Datenprüfungen in einem Zeitplan festlegen.
Datenhilfsfunktion
Im Kontext des IDNA/NGIN Systems bezieht sich die Datenhilfsfunktion auf die Funktionalität, die erforderlich ist für das Abschalten und Initialisieren eines Repositorys Backup gespeicherter Daten, Wiederherstellung von Daten nach einem katastrophalen Ereignis, Synchronisierung von Daten zwischen Repositories und Datenrepository-Überwachung und -Unterhaltung. Das Datenmanagement ist zusätzlich in der Lage, ein Repository abzuschalten (offline zu schalten) für Wartungs- oder Wiederherstellungszwecke. Zur Feststellung, ob ein Repository abzuschalten ist, wird ein Mechanismus bereit gestellt für die Überwachung der prozentweisen Benutzung eines Datenrepositorys. Somit werden Hilfsfunktionen bereit gestellt, die es einem autorisierten Benutzer erlauben, die Datenrepositories zu unterhalten, einschließlich einer Hilfsfunktion für die Optimierung von Plattenplatz und zur Säuberung von Protokollen. Datenmanagement kann zusätzlich ein Repository unter Benutzung der Dateibefehle des lokalen Betriebsystemes sichern und wiederherstellen. Ein Repository kann ohne Verlust an Informationen wiederhergestellt werden.
Das Datenmanagement ist mit einer zusätzlichen Hilfsfunktion ausgestattet zur Archivierung von Repository-Daten auf einem externen Medium; zur Synchronisierung von Repository-Daten über mehrere Repositories; zur Synchronisierung einer Untermenge von Daten (partielle Synchronisierung) über mehrere Repositories und zur on-line Schaltung eines Repositorys.
Erfordernisse für Rechnungsdatensatz Erzeugung
Die Rechnungsdatensatz Erzeugungsfunktionalität für das NGIN-System schließt die Erfassung von Netzwerkereignissen, Formatierung der Netzwerkereignisse in geeignete Datensätze (Anrufhistorie), Übermittlung der formatierten Datensätze an den geeigneten Standort und Identifizierung von möglicherweise betrügerischen Anrufen ein. Da die Rechnungsdatensatz Erzeugungsfunktion verantwortlich ist für die Formatierung und die Übermittlung von Informationen, die benutzt werden, um Rechnungen für Kunden für Services zu schreiben, ist seine Exaktheit zertifiziert.
Sammeln von Netzwerkereignissen
Unbehandelte, für Rechnungsstellungszwecke benutzte Netzwerkereignisse werden von den Repositories des Datenmanagements gesammelt und zur Feststellung ihrer Vollständigkeit durchgesehen. Bei der Erzeugung von Anrufhistorien Datensätzen, die von verschiedenen Typen nachgeschalteter Rechnungssysteme benutzt werden, wird ein eindeutiger Netzwerkidentifizierer für jeden Anrufhistorien Datensatz bereit gestellt, so dass die Datensätze zur weiteren Verarbeitung gehandhabt werden können. In der bevorzugten Ausführungsform können Anrufhistorien Datensätze benutzt werden, um Informationen einzufangen, die für die Erzeugung der folgenden Typen von Datensätzen benutzt werden: Anrufdetaildatensätze (CDRs), welche Netzwerkereignisinformationen auf gemeinschaftlich benutzten Leitungen einfangen; Privatnetzwerkdatensätze (PNRs), welche Ereignisinformationen auf privaten Leitungen (z. B. VNET) einfangen; Vermittlungsservicedatensätze (OSRs), die zum Einfangen von Informationen benutzt werden, wenn gemeinschaftlich benutzte Leitungen für Vermittlungsservices benutzt werden; und private Vermittlungsservicedatensätze (POSRs), welche Informationen einfangen, wenn private Leitungen für Vermittlungsservices benutzt werden. Vorzugsweise kann jeder der vorgenannten Typen von Rechnungsdatensätzen erweitert werden. Somit können erweiterte Anrufdetaildatensätze (ECDRs), erweiterte private Netzwerkdatensätze (EPNRs), erweiterte Vermittlungsservicedatensätze (EOSRs) und erweiterte private Vermittlungsservicedatensätze (EPOSRs) erzeugt werden. Zusätzliche Datensätze, die durch das DM erzeugt werden können, schließen Switch-Ereignisdatensätze (SERs), die ein Switchereignis (z. B. Systemwiederherstellung, Uhrzeitänderung) und Rechnungsdatensätze (BDRs) ein. Diese Funktion schließt zusätzlich die Speicherung von Anrufhistorien Datensätzen auf einem Langzeitspeicher- und Wiederherstellungsmedium (z. B. Band) ein.
Übertragen von Anrufhistorien Datensätzenerfordernissen
Nachdem jeder dieser Anrufhistorieen Datensätze erzeugt wurde, werden sie zu den geeigneten nachgeschalteten Systemen übertragen. Zum Beispiel werden in einer bevorzugten Aus führungsform alle CDRs, PNRs, OSRs, POSRs, ihre entsprechenden erweiterten Versionen ECDRs, EPNRs, EOSRs, EPOSRs und SERs und BDRs zu einem Systemspeicherungs- und Überprüfungselement „SAVE" (nicht gezeigt) für eventuelle Verteilung an einen Netzwerkinformationskonzentrator (NIC) gesendet. Eine DM Systemfunktion sorgt für eine Überprüfung, dass SAVE jeden dieser Anrufhistorien Datensätze erfolgreich empfangen hat.
Identifizierung möglicherweise betrügerischer Anrufe
Das NGIN System hat einen eingebauten Mechanismus zur Identifizierung möglicherweise betrügerischer Anrufe. Somit stellt die DM-Komponente 600 die Fähigkeit bereit, die Netzwerkbenutzung auf Betrug zu überwachen und Verdacht auf Betrug an ein geeignetes Betrugsdetektionssystem zu berichten. Die Rechungsdatensatzerzeugungsfunktion beispielsweise: 1) erhält Profile von einem Betrugsdetektionssystem (nicht gezeigt), um Netzwerkereignisse, die an die Betrugsdetektion geschickt werden sollten, zu identifizieren; 2) wertet Netzwerkereignisse gegenüber den Betrugsprofilen aus; und 3) überträgt möglicherweise betrügerische Anrufe in Echtzeit an ein Betrugsdetektionssystem.
3(f) stellt allgemein die funktionelle Architektur der Datenmanagementkomponente 600 dar, welche umfasst: eine Servicesteuerungsserverkomponente 605 zur Verfügbarmachung der Anrufservicedaten beim Serviceknoten zur Echtzeit Anrufverarbeitung; und eine Datenbankkomponente 607, verkörpert als diskreter Datenbankserver, zur Speicherung und Verteilung der gewählten Untermenge von SA-verwalteten Daten. Speziell schließt die Servicesteuerungsserver-Komponente 605 einen Datenmanagement (DM) Client 610 ein, welcher die eigentliche Datenmanagement-Anwendung ist; eine DM API 612, welche mit der DM-Anwendung verknüpft ist und die von der DM-Anwendung zum Erhalt von Daten von der SA benutzte Schnittstelle ist; einen lokalen Zwischenspeicher 615, welcher ein gemeinschaftlich benutzter Speicherbereich auf einem Servicesteuerungsserver ist und für die Speicherung von einigen oder allen Daten aus dem DBOR-Auszug, die für die Anrufverarbeitung verfügbar sind, gemäß einer lokalen Zwischenspeicherungsstragie benutzt wird, und einen Zwischenspeichermanager 620, welcher den Zustand des lokalen Zwischenspeichers durch Implementierung einer lokalen Zwischenspeicherungsstrategie unterhält und mit dem DM-Server kommuniziert, um Daten aus dem DBOR Auszug herauszuholen. Die Datenbankkomponente 607 schließt einen DBOR-Auszug 627 ein, welcher eine oder mehrere Datenbanken mit Daten, die von den verwalteten Objektinstanzen während der Serviceausführung an diesem Knoten zu benutzen sind, umfasst; einen DBOR-Auszugsmanager 626, der die selben Funktionen wie der DBOR-Manager 520 in der Serviceverwaltung (3(d)) ausführt, aber eine ausgewählte Untermenge der von der SA gehaltenen Informationen handhabt; einen SA-Client 622, welcher von der Serviceverwaltung empfangene Daten in den DBOR-Auszugsmanager 626 eingibt, eine DDAPI 624, die die Prozessschnittstelle zwischen dem SA-Client 622 und dem Datenverteilungsprozess der SA ist; und einen Datenmanagementserver 625, der allgemein Datenauszüge von dem DBOR-Auszugsmanager 626 handhabt.
Der Datenmanagementbetrieb wird nun in weiteren Details mit Bezug auf 3(f) beschrieben. Innerhalb einer SLEE können mehrere Typen von Funktionen Daten vom Datenmanagement 600 benötigen, einschließlich aber nicht beschränkt auf verwaltete Objekte (SIBBs, SLPs, etc.) und NOS. Jede dieser ist in 3(f) als ein DM-Client dargestellt, welcher in der Servicesteuerungs-SLEE abläuft. Ein DM-Client 610 benutzt die DM API 612, um eine Datenanforderung zu machen, da die DM API 612 einen für alle DM-Clienten gebräuchlichen Satz von Nachrichten bereit stellt zur Kommunikation über eine Schnittstelle mit dem Datenmanagement. Die DM API 612 kapselt auch den spezifischen Standort, wo die Daten benötigt werden, vom DM-Client, da diese Daten in einem lokalen Zwischenspeicher 615 oder nur in dem DBOR-Auszug 627 gespeichert werden können. Der DM-Client 612 fordert Daten durch einen logischen Namen an, und die DM API 612 stellt fest, ob diese Daten aus dem lokalen Zwischenspeicher geholt werden können, oder ob es die Daten beim DBOR-Auszug mittels des DM-Servers anfragen muss. Vorzugsweise ist der lokale Zwischenspeicher 615 ein gemeinschaftlich benutzter Zwischenspeicher, der für jeden Prozess, der auf jeder im Steuerungsserver 605 bereitgestellten SLEE abläuft, verfügbar ist, d. h. es kann einen oder mehrere lokale Zwischenspeicher geben, die für unterschiedliche Anwendungen bereit gestellt werden, z. B. 1-800 Prozesszwischenspeicher, Routingmanagerzwischenspeicher, etc., wobei jeder gemeinschaftlich benutzte Zwischenspeicher seinen eigenen jeweiligen Zwischenspeichermanager hat.
Wenn DM-Client 610 eine Datenanfrage macht, überprüft die DM API zunächst den lokalen Zwischenspeicher 615, um zu sehen, ob die angefragten Daten dort gespeichert sind. Wenn die gespeicherten Daten im lokalen Zwischenspeicher 615 gespeichert sind, holt die DM API die angefragten Daten und stellt sie für den DM-Client 610 bereit unter Benutzung irgendei ner Standarddaten-Beschaffungstechnik, wie Hash-Schlüssel und -Algorithmen oder indexsequentielle Zugriffsmethoden.
Falls die angefragten Daten nicht im lokalen Zwischenspeicher 615 gespeichert sind, holt der zugehörige Zwischenspeichermanager 620 die Daten aus dem DBOR-Auszug 627 über den DM-Server 625. Insbesondere benachrichtigt die DM API 612 den Zwischenspeichermanager 620, dass sie bestimmte Daten benötigt, und der Zwischenspeichermanager reagiert durch Senden einer Anfrage an den DM-Server 625. Der DM-Server 625 wiederum holt die angefragten Daten aus dem DBOR-Auszug unter Benutzung des DBOR-Auszugsmanagers 626 für den Datenbankzugriff. Der DM-Server 625 sendet die angefragten Daten zurück an den Zwischenspeichermanager 620, und der Zwischenspeichermanager stellt die Daten dem DM-Client 610 über die DM API 612 bereit. Der Zwischenspeichermanager kann auch die angefragten Daten in den lokalen Zwischenspeicher 615 schreiben, abhängig von der lokalen Zwischenspeicherungsstrategie, welche sowohl von der Servicenachfrage als auch von den Fähigkeiten der Computer, auf denen sie abläuft, insbesondere der Speicherkapazität, abhängt. Diese Spezifikationen werden vom Service und den von der Serviceverwaltung erzeugten Computerprofilen erhalten.
In der bevorzugten Ausführungsform benutzt die Datenzwischenspeicherungsmanagerkomponente für das DM 600 der IDNA/NGIN eine 'Client-seitige Zwischenspeicherungs-' Strategie an jedem Serviceknoten. In Übereinstimmung mit dieser Strategie ist die Zwischenspeicherungsmanagerroutine und -logik im Wesentlichen in der folgenden Weise implementiert: 1) der lokale Zwischenspeicher wird als statisches Array am Anfang der Routine unterhalten; 2) die Routine überprüft zunächst, ob die angefragten Daten im lokalen Zwischenspeicher sind; 3) falls die Daten im lokalen Zwischenspeicher sind, werden sie formatiert und an den Aufrufenden zurückgegeben; 4) falls die Daten nicht im lokalen Zwischenspeicher sind, werden die Daten vom Datenserver mittels einer gewöhnlichen „QueryServer" Routine geholt; und 5) wenn die Daten vom Datenserver zurückgegeben werden, werden sie im Zwischenspeicher gespeichert, formatiert und dann an den Aufrufenden zurückgegeben. Genauer formatiert die „QueryServer" Routine eine Abfrage an den Datenserver, sendet eine Anfrage und falls sie keine Antwort erhält, sendet sie eine weitere Anfrage. Dies setzt sich fort, bis entweder eine Antwort empfangen wird oder eine festgesetzte Anzahl von Versuchen gemacht wurde, zu welchem Zeitpunkt die Routine mit einem Fehler zurückkehren wird.
In der bevorzugten Ausführungsform existiert die Ausführungslogik in einem separaten Prozess, der der 'Cache Manager' genannt wird, welcher den Zwischenspeicher dynamisch allokiert und nicht als eine 'Static Variable'. Weiterhin ist in der bevorzugten Ausführungsform der Zwischenspeichermanager eine generische Routine, enthält keine Referenzen auf spezifische Tabellen und Datenelemente. Darüber hinaus implementiert der Zwischenspeichermanager der bevorzugten Ausführungsform eine Logik zur Behandlung vieler Zwischenspeicherungsstrategien und implementiert eine Logik zur Behandlung unaufgeforderter Datennachrichten vom Datenserver.
Lokale Zwischenspeicherungsstrategien reichen von der Speicherung aller Daten im lokalen Zwischenspeicher bis zur Speicherung von nichts, schließt jedoch typischerweise eine „zuletzt benutzt" oder „am häufigsten benutzt" Strategie ein. Da die Bereitstellung eines lokalen Zwischenspeichers zur Bereitstellung von raschen Datenbeschaffungen (durch Benutzung von gemeinschaftlich benutztem Speicher) für häufig benutzte Services ist, ist die lokale Zwischenspeicherungsstrategie eng mit der SA Serviceunterstützungsbereitstellungsfunktion verknüpft, welche festlegt, welche Services auf welchen Servicesteuerungsservern laufen sollen. Genauer gibt es drei Ebenen der Datenzwischenspeicherung im System, abhängig von den Datencharakteristiken und den Services, zu denen die Daten gehören: 1) Daten der lokalen Ebene, welche ein lokales Zwischenspeicherungsschema implementieren, das hierin beschrieben ist, mit Benutzung der DM API, des Zwischenspeichermanagers und des DM-Servers und der DBOR Auszugseinrichtung; 2) Daten auf Knoten- oder Standortebene, wo die DM API-, Zwischenspeichermanager- und DM-Serverkomponenten implementiert sind zur Aktualisierung der DBOR und Rücksenden der Änderung durch den DM-Server an alle Zwischenspeichermanger an dem Knoten; und 3) Daten auf Netzwerkebene, wo die DM API-, Zwischenspeichermanager- und DM-Serverkomponenten implementiert sind, um Daten herauf zur SA zu senden und um auf die zentrale Datenbank angewendet zu werden und durch die SA und alle DM-Server zurück zu allen lokalen Zwischenspeichern im Netzwerk zu senden. Es sollte verstanden werden, dass es auch zwei Ebenen der Datenbeständigkeit gibt: 1) permanente Daten, die in die DBOR geschrieben werden sollen; und 2) transiente Daten, die zu lokalen Zwischenspeichern geschrieben werden sollen, abhängig von den Charakteristiken der Daten.
Wie weiterhin in 3(f) gezeigt, spezifiziert die lokale Zwischenspeicherungsstrategie, als Beispiel einer lokalen Datenzwischenspeicherung von transienten Daten, wenn ein SLP für einen Service aktiv ablaufen soll, d. h. als beständiges Objekt in der SLEE auf der Grundlage von der vorhergesagten Servicenachfrage instantiiert werden soll, Speicherung von Daten für diesen Service im lokalen Zwischenspeicher für die spezifizierte Zeitdauer, in Übereinstimmung mit der Konfigurationsdatei, d. h. einem Serviceprofil, von der SA. Der DM-Server sendet die Daten für diesen Service an den Zwischenspeichermanger 620 zur Speicherung des lokalen Zwischenspeichers 615 für die Aktivzeit. Insbesondere wenn eine SLEE Umgebung versorgt wird, registriert der Cache Manager 620 sich selber beim DM-Server 625 durch Spezifizieren, welche Services ausgeführt werden. Davon ausgehend, holt der DM-Server 625 vom DBOR-Auszug 627 die zur Erfüllung der lokalen Zwischenspeicherungsstrategien für den Service, für den der Zwischenspeicherungsmanager sich registriert hat, benötigten Daten und lädt diese herunter an den Cache Manager 620. Vorzugsweise kennt der DM-Server 625 die lokale Zwischenspeicherungsstrategie für jeden lokalen Zwischenspeicher und den Zwischenspeichermanager an seinem Standort. Somit kann der DM-Server 625 auch nicht verlangte Daten dem Zwischenspeichermanager bereit stellen. Wenn zum Beispiel eine Netzwerk ausgelöste Aktualisierung auftritt, kann die Aktualisierung direkt durch den DM-Server in seinem DBOR-Auszug und/oder zur Serviceverwaltung zur Validierung und Verteilung an andere Datenmanagement-Plattformen geleitet werden. Falls der DM-Server von der SA eine Aktualisierung empfängt, wird er diese Aktualisierung an den Zwischenspeichermanager zur Aktualisierung des lokalen Zwischenspeichers senden. Es sollte verstanden werden, dass in dieser Instanz der SA-Client und der DBOR-Auszugsmanager 626 den DBOR-Auszug aktualisieren werden. Das Datenmanagement stellt eine Prozessschnittstelle zwischen dem SA-Client und dem DM-Server bereit zur Benachrichtigung des DM-Servers über DBOR-Auszugsaktualisierungen.
In der bevorzugten physikalischen Ausführungsform benutzt die Datenmanagementkomponente 600 kommerzielle Datenbankprodukte, von denen die meisten einen Schnittstellenmechanismus, wie eine API, einen Object Request Broker („ORB") oder einen Netzwerkdateiservice zur Verfügung stellen. Als solches benutzt das Datenmanagement nicht die NOS-Komponente 700, jedoch kann die Servicesteuerungsschnittstelle zum Datenmanagement zur Benutzung des NOS angepasst werden. Da die Datenmanagementfunktion jedem Serviceknoten lokal zugeordnet ist, kann diese Funktion physikalisch durch unterschiedliche Objekt- und relationale Datenbanksysteme/-produkte überall im Netzwerk realisiert werden. Beispiele relationaler Datenbankprodukte schließen solche ein, die von Oracle, Informix und Sybase verfügbar sind, zusätzlich zu Versant Objekt orientierten Datenbankprodukten. Die Schnittstelle zwischen der Servicesteuerung und den Datenmangement kann von irgendeinem Datenbanksystem/-produkt unterstützt werden, das an einem bestimmten Serviceknoten benutzt wird, und kann an unterschiedlichen Knoten unterschiedlich sein. Die verteilte Verarbeitung, die durch das NOS ermöglicht wird, findet in Prozessen in der SLEE statt, wobei der Prozess über eine Schnittstelle mit seiner lokalen Datenmanagementkomponente kommuniziert, unter Benutzung von der Schnittstelle, die an dem lokalen Knoten vorhanden ist.
Einige bevorzugte Ausführungsformen wurde vorangehend im Detail beschrieben. Es ist zu verstehen, dass der Schutzbereich der Erfindung auch Ausführungsformen umfasst, die unterschiedlich von den beschriebenen, jedoch innerhalb des Schutzbereichs der Ansprüche sind.
Zum Beispiel wird der Mehrzweckcomputer als eine Rechnervorrichtung verstanden, die nicht speziell für einen Anwendungstyp gemacht ist. Der Mehrzweckcomputer kann jegliche Rechenvorrichtung von jeglicher Größe sein, die die zur Implementierung der Erfindung erforderlichen Funktionen ausführen kann.
Ein zusätzliches Beispiel ist die „Java" Programmiersprache, die durch andere äquivalente Programmiersprachen ersetzt werden kann, die ähnliche Eigenschaften haben und ähnliche Funktionen, wie sie zur Implementierung der Erfindung erforderlich sind, ausführen werden.

Claims

Serviceverwaltungssystem für die Verteilung von Serviceverarbeitungsressourcen auf einen oder mehrere Service-Knoten eines intelligenten Kommunikationsnetzwerks, wobei jeder Service-Knoten eine einem Service-Knoten zugeordnete Netzwerkressource mit Services versorgt und das System umfasst: a) eine Einrichtung zum Empfang von wiederverwendbaren Service-Komponenten zur Versorgung mit Services an einem Service-Knoten von besagtem intelligenten Kommunikationsnetzwerk, wobei jeder Service-Komponente ein Service-Profil zugeordnet ist, das benötigte Service-Knotenressourcen zur Speicherung, Wartung und Ausführung von besagtem Service definiert; b) eine Einrichtung zum Empfang von Konfigurationskriterien, einschließlich physikalischer Ressourcenkapazität eines jeden Service-Knotens von dem Netzwerk; c) eine Datenbankeinrichtung zum Speichern von empfangenen Service-Komponenten, Konfigurationskriterien für Service-Knoten und den Service-Komponenten zugeordneten Service-Profilen; d) einen Verteilungsmechanismus für die Verteilung von Kopien der Service-Komponenten an einen oder mehrere Service-Knoten gemäß der Service-Profil-Informationen, die einem Service- und einem Konfigurationskriterium des Service-Knoten zugeordnet sind; und e) einen Auslösemechanismus zur automatischen Aktivierung und Deaktivierung der an den Service-Knoten verteilten Service-Komponente, wobei die Ausnutzung von Service-Knoten-Ressourcen durch das Aktivieren der Service-Komponenten in Service-Knoten während Zeiten hoher Nachfrage nach einem zugeordneten Service und das Deaktivieren von Service-Komponenten in Service-Knoten während Zeiten niedriger Nachfrage nach dem Service optimiert ist.
Verfahren zur Verwaltung von Service-Komponenten an einem oder mehreren Service-Knoten umfassend ein intelligentes Netzwerk, wobei jeder Service-Knoten einen oder mehrere Services zur Verfügung stellt in Bezug auf ein empfangenes Ereignis an einer Netzwerkressource, die einem Service-Knoten zugeordnet ist, wobei das Verfahren die Schritte umfasset: a) Empfang von wiederverwendbaren Service-Komponenten für das Bereitstellen von Services an einem Service-Knoten von dem intelligenten Kommunikationsnetzwerk, wobei jeder Service-Komponente ein Service-Profil zugeordnet ist, das benötigte Service-Knotenressourcen zur Speicherung, Wartung und Ausführung von dem Service definiert; b) Empfang von Konfigurationskriterien einschließlich der physikalischen Ressourecenkapazität eines jeden Service-Knotens von dem Netzwerk; c) Unterhalt einer Datenbank mit Stammkopien der besagten empfangenen Service-Komponenten, der besagten Konfigurationskriterien der Service-Knoten und der den Service-Komponenten zugeordneten Service-Profilen; d) Verteilung von Kopien der Service-Komponenten an einen oder mehrere Service-Knoten, gemäß Service-Profil-Informationen einem Service und einem Konfigurationskriterium des Service-Knoten zugeordnet; und e) Weiterleiten eines Auslösesignals an den Service-Knoten zur automatischen Aktivierung und Deaktivierung einer Service-Komponente, die an besagten Service-Knoten verteilt wurde, wobei eine an den Service-Knoten verteilte Service-Komponente zu Zeiten hoher Nachfrage nach dem zugeordneten Service aktiviert und zu Zeiten niedriger Nachfrage nach besagtem Service deaktiviert wird.
Serviceverarbeitungssystem zur Steuerung eines Kommunikationsnetzwerks, das eine Vielzahl von Service-Knoten umfasst, wobei jeder Service-Knoten wenigstens eine logische Ausführungsumgebung umfaßt, die verwaltete Objekte beherbergt, wobei das Serviceverarbeitungssystem umfasst: einen Datenmanager zum Unterhalt eines lokalen Speichers an jedem Service-Knoten mit verwalteten Objekten und zur Serviceverarbeitung innerhalb des Service-Knotens benötigten Daten; wenigstens einen Service-Verwalter, der den Einsatz und die Aktivierung von Services innerhalb des besagten Serviceverarbeitungssystems steuert, durch Verteilen von verwalteten Objekten und Daten aus einem globalen Aufbewahrungsort an einen oder mehrere Datenmanager, die den Service-Knoten in dem Kommunikationsnetzwerk zugeordnet sind.
Verfahren zur Einsatz- und Aktivierungssteuerung von Services in einem Kommunikationsnetzwerk mit einer Vielzahl von Service-Knoten, wobei jeder Service-Knoten wenigstens eine logische Ausführungsumgebung umfasst, die verwaltete Objekte beherbergt, wobei das Verfahren die Schritte umfasst: Unterhalt, an jeden Service-Knoten, eines lokalen Datenspeichers für verwaltete Objekte und Daten, zur Serviceverarbeitung an dem Service-Knoten benötigt; selektives Verteilen der verwalteten Objekte und Daten von einem globalen Aufbewahrungsort an einen oder mehrere der dem Service-Knoten in dem Kommunikationsnetz zugeordneten lokalen Datenspeicher, zum Zwecke der Steuerung, wo und wann Services in besagtem Kommunikationsnetz eingesetzt und aktiviert werden.