DE69624579T2

DE69624579T2 - System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten

Info

Publication number: DE69624579T2
Application number: DE69624579T
Authority: DE
Inventors: A. Linares; V. Shah; W. Woster
Original assignee: Alcatel USA Inc
Current assignee: Xylon LLC
Priority date: 1995-09-12
Filing date: 1996-09-11
Publication date: 2003-05-22
Anticipated expiration: 2016-09-12
Also published as: AU6978196A; WO1997010547A1; JP2000500255A; EP0850447B1; JP3846736B2; DE69624579D1; US5892946A; EP0850447A1; CA2231684A1

Description

TECHNISCHES GEBIET DER ERFINDUNG

Die Erfindung betrifft allgemein das Feld der verteilten Computersysteme für Fernmeldeanwendungen, die eine Redundanz von Hardware- und Softwarediensten aus Zuverlässigkeitsgründen an mehreren physikalischen Orten erfordern können. Genauer gesagt betrifft die Erfindung ein System und ein Verfahren für eine auf mehrere Orte verteilte Objektverwaltungsumgebung. Die Erfindung ist insbesondere anwendbar auf Telephonie, die Redundanz von Hardware- und Softwarediensten aus Zuverlässigkeitsgründen an mehreren physikalischen Orten erfordern kann.

HINTERGRUND DER ERFINDUNG

Die einfachste, verbreitetste Schnittstelle zwischen einem Client und einem Server liegt vor, wenn der Client und der Server im gleichen Prozess verbunden sind. In diesem Fall kann der Client einen Subroutinenaufruf vornehmen, um auf den Server zuzugreifen. Aufruf-Eingabeparameter können vom Client an den Server in einem gemeinsamen Speicher übergeben werden, und zurückgegebene Ausgabeparameter können vom Server an den Client zurück über den gemeinsamen Speicher übergeben werden, um den Aufruf abzuschließen.
Um die Leistungsfähigkeit einer verteilten Computerarchitektur auszunutzen, ist es häufig nötig, dass der Server sich an einem Netzwerkknoten befindet, der vom Client-Knoten entfernt ist. Mehrere Clients können den gleichen Dienst von mehreren Servern gleichzeitig anfordern. Zusätzlich ist es bei Fernmeldeanwendungen erforderlich, Hardware- und Softwareredundanz herzustellen, um eine gegen Hardware- bzw. Softwarefehler tolerante Dienstumgebung zu schaffen. Diese Umgebung besteht aus Knoten an geographisch entfernten Orten im globalen Fernmeldenetz. Dieses System muss in der Lage sein, sich an Serverausfälle an einem beliebigen Punkt im Netzwerk schnell anzupassen.
EP-A-0 474 340 beschreibt eine Technik zum Bereitstellen eines dynamischen Aufrufs von Anwendungen in einer verteilten heterogenen Umgebung. Genauer gesagt wird ein Prozess zum Aufrufen einer Serveranwendung durch eine Clientanwendung beschrieben, bei dem die Clientanwendung eine erste Nachricht erzeugt, die einen Identifikator für eine erste Instanz und einen Identifikator für eine an dieser ersten Instanz durchzuführende gewünschte Operation enthält, woraufhin ein Identifikator für ein erstes Verfahren aus der ersten Nachricht und einer Klasse, in der die erste Instanz organisiert ist, festgelegt wird, wobei der Identifikator für das erste Verfahren einen Verweis auf eine Prozedur umfasst, um es der Serveranwendung zu ermöglichen, die gewünschte Operation auf der ersten Instanz durchzuführen. Der Identifikator wird dann an einen Server übertragen, um die Serveranwendung aufzurufen.
EP-A-0 524 089 beschreibt eine Softwarestruktur, die strukturelle Objekte umfasst, von denen jedes wenigstens einen Dienstzugangspunkt umfasst, an den eine an das Objekt adressierte Nachricht gesendet werden kann. Jedes strukturelle Objekt ist anderen Objekten durch Beziehungen zugeordnet, die es mit den anderen Objekten in strukturelle Beziehung setzen. Kommunikation zwischen Objekten findet statt durch Übertragung von Nachrichten zwischen einem Dienstzugangspunktmodul eines Ursprungsobjekts und einem Dienstzugangspunktmodul eines Empfängerobjekts übe rein Kommunikationsdienstobjekt, das von den Ursprungsobjekten zu sendende Nachrichten empfängt und sie den Empfängerobjekten zur Verfügung stellt.
US-A-5 287 507 beschreibt eine Technik für Client-Programme, die zur Anwendung in einem objektorientierten verteilten Computersystem so angepasst sind, dass sie kommunizieren und Verweise auf Objekte in einer Weise nutzen können, die den Nutzen von Software-Cache-Speicherung steigert. Es wird ein Mechanismus beschrieben, durch den ein Netzobjekt-Handle (ein vergrößerter Objekt-Handle) genutzt werden kann, um sowohl auf den Server als auch auf einen lokalen Cache-Manager zu verweisen. Wenn det vergrößerte Objekt-Handle übertragen wird, wird er automatisch aktualisiert, um, wenn möglich, einen lokalen Cache-Manager in seiner Zielumgebung zu nutzen.
Der Aufsatz in IEICE Transactions an Communications, Band E75-B, Nr. 10, 1. Oktober 1992, Seiten 957 bis 968, XP000324829 von Katsumi Maruyama mit dem Titel "Object- Oriented Switching Software Technology" beschreibt eine objektorientierte Vermittlungsprogrammstruktur, in der jede logische Komponente als ein Softwareobjekt implementiert ist, wodurch die Wartbarkeit und Erweiterbarkeit der in öffentlichen Vermittlungssystemen verwendeten Vermittlungssoftware verbessert wird.

KURZBESCHREIBUNG DER ERFINDUNG

Es besteht also ein Bedarf nach einer Umgebung, die es ermöglicht, den einfachen Client/Server-Subroutinenaufruf durch Zugriff auf das globale Netzwerk von Servern an mehreren Orten zu ersetzen.
Gemäß der vorliegenden Erfindung, wie in den nachfolgenden Ansprüchen definiert, werden ein auf mehrere Orte verteiltes Objektnachrichtenvermittlungssystem und -verfahren geschaffen, die die mit bisherigen Systemen verknüpften Nachteile beseitigen oder wesentlich verringern.
Besondere und bevorzugte Aspekte der vorliegenden Erfindung sind in den begleitenden unabhängigen und abhängigen Ansprüchen dargelegt.
Bei einer Ausgestaltung der Erfindung sind ein verteiltes Objektnachrichtenvermittlungssystem und -verfahren für eine Mehrzahl von auf mehrere physikalisch getrennte Orte verteilten Knoten vorgesehen. Es gibt eine Mehrzahl von Prozessen, die in jedem Knoten ablaufen. Diese Prozesse registrieren eine Mehrzahl von Objekten in jedem Knoten. Die Objekte umfassen Client-Objekte und Server-Objekte. Die Server-Objekte können für globalen Dienst für Dienstverfügbarkeit für Client-Objekte in einem lokalen Knoten, einem lokalen Ort und/oder für ortsbezogen globale Dienste für Dienstverfügbarkeit für Client-Objekte an entfernten Orten registriert sein. Eine Server-Objektdatenbank wird in jedem Knoten verwendet, um eine Server-Objektbeschreibung für jedes an dem Knoten registrierte Server-Objekt und für an entfernten Knoten für globalen oder ortsbezogen globalen Dienst registrierte Objekte zu speichern. Eine Client-Server-Schnittstelle ist für Client-Objekte zugänglich und empfängt Dienstanforderungen von diesen. Die Client-Server-Schnittstelle greift auf die Server-Objektdatenbank für wenigstens ein Ziel-Server-Objekt zu, das in der Lage ist, den vom Client-Objekt angeforderten Dienst auszuführen, und gibt die Dienstanforderung an die Ziel-Server-Objekte an einem lokalen Ort oder einem entfernten Ort weiter.
Bei einer Ausgestaltung der Erfindung wird in jedem Prozess ein lokaler Cache geführt, um vergangene Dienstanforderungen und Server-Objekt-Entsprechungen aufzuzeichnen. Der lokale Cache wird bei Dienstanforderungen zunächst nach einer Entsprechung abgesucht, wenn die Server-Objektdatenbank seit dem letzten Datenbankzugriff nicht geändert worden ist.
Bei einer Ausgestaltung der Erfindung wird der gegenwärtige Dienstzustand eines Knotens in der Server-Objektdatenbank jedesmal aufgezeichnet, wenn eines seiner Objekte registriert wird. Der Inhalt der Server-Objektdatenbank kann dann in Reaktion auf eine Auf- oder Abrüstung des Dienststatus eines Knotens angepasst werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Zum besseren Verständnis der vorliegenden Erfindung kann Bezug genommen werden auf die beigefügten Zeichnungen. Es zeigen:
Fig. 1 ein Top-Level-Diagramm von Knoten an zwei Orten mit einer Kommunikationsverbindung zwischen ihnen;
Fig. 2 ein vereinfachtes Diagramm eines Knotens mit einer Mehrzahl von Prozessen;
Fig. 3 ein beispielhaftes Flussdiagramm eines DOME- Mehrort-Initialisierungsprozesses;
Fig. 4 ein beispielhaftes Flussdiagramm eines Objektregistrierungsprozesses;
Fig. 5 ein Beispiel einer Server-Objektdatenbank, die den Typ der darin gespeicherten Information zeigt;
Fig. 6 ein beispielhaftes Flussdiagramm eines Dienstanforderungsprozesses;
Fig. 7 ein beispielhaftes Flussdiagramm einer Hol-Liste eines Server-Objektprozesses;
Fig. 8 ein beispielhaftes Flussdiagramm einer Anforderungsliste eines Server-Objektprozesses;
Fig. 9 ein beispielhaftes Flussdiagramm einer Empfangsliste eines Server-Objektprozesses;
Fig. 10 ein Diagramm eines Kommunikationsprozesses zwischen Knoten;
Fig. 11 ein Diagramm eines anderen Kommunikationsprozesses zwischen Knoten;
Fig. 12 ein beispielhaftes Flussdiagramm eines Knotenstatus-Einstellprozesses; und
Fig. 13 ein beispielhaftes Zustandsdiagramm von Knoten- Dienstzuständen.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Die bevorzugte(n) Ausgestaltung(en) der vorliegenden Erfindung sind(werden) in Figs. 1 bis 13 beschrieben, wobei gleiche Bezugszeichen in den diversen Zeichnungen benutzt werden, um gleiche und entsprechende Teile zu bezeichnen.
Bezogen auf Fig. 1 ist zur Veranschaulichung ein vereinfachtes Diagramm einer verteilten Objektverwaltungsumgebung (Distributed Object Management Environment DOME) in einer allgemein mit dem Bezugszeichen 10 bezeichneten Mehrortumgebung gezeigt. Zur Veranschaulichung ist gezeigt, dass die DOME 10 zwei Orte 50 und 51, mit 12 bzw. 13 bezeichnet, umfasst, die über eine Kommunikationsverbindung wie etwa ein Computernetz oder eine Media Access Control (MAC)-Brücke 14 verbunden sind. Jeder Ort 12 und 13 umfasst eine Gruppe von Knoten 15 bis 21 bzw. 25 bis 32. Ein DOME-System kann einen, zwei oder mehrere Orte umfassen. Die Orte können physikalisch voneinander entfernt sein. Z. B. kann sich Ort 12 physikalisch in Chicago und Ort 13 physikalisch in New York befinden.
Ein Ort kann definiert werden als eine Gruppe von Knoten, die miteinander durch ein oder mehrere Computernetzwerke wie etwa Ethernet verbunden sind. Die Knoten an einem Ort sind typischerweise, wenn auch nicht notwendigerweise, eng benachbart und arbeiten kooperativ zusammen. Ein Knoten kann definiert sein als ein Arbeitsplatzrechner mit einer oder mehreren zentralen Verarbeitungseinheiten, die eine Instanz eines Betriebssystems und Anwendungssoftware oder -prozesse ausführen. Jeder Ort 12 und 13 kann einen aktiven Platform-Manager- (PM)-Knoten 15 und 25 enthalten, der bestimmte vorgegebene primäre Verwaltungsfunktionen ausführt. Ein Bereitschafts- Platform-Manager-Knoten 16 und 26 kann vorgesehen sein, um Reserveunterstützung in Fällen zu schaffen, wo der aktive Platform-Manager ausfällt. Anwendungsknoten 17 bis 21 und 27 bis 32 können auch als "Aktiv/Standby" und "Lastteilung" bezeichnet werden. Die Bezeichnung "Lastteilung" bedeutet, dass eine Funktion oder ein Prozess in gleicher Weise den lastteilenden Knoten zugewiesen ist und von ihnen durchgeführt wird. Wie in Fig. 1 angegeben, kann jeder Knoten direkt mit einem anderen Knoten an einem anderen Ort wie auch an dem gleichen Ort kommunizieren.
Bezogen auf Fig. 2 ist gezeigt, dass der Knoten APO 17 eine Anzahl von Prozessen P0-P4 40 bis 44 enthält. Jeder Prozess kann ein Client-Prozess oder ein Server-Prozess sein oder als Client eines Prozesses und Server eines anderen fungieren. Zusätzlich umfasst jeder Knoten einen DOME-Server-Prozess 48, der als Registrierungsschnittstelle zwischen den Client- Objekten und Server-Objekten fungiert, die in verschiedenen Prozessen innerhalb eines Knotens oder in verschiedenen Knoten des Systems, am gleichen Ort oder nicht, angesiedelt sind. Jeder Prozess 40 bis 44 kann eine oder mehrere Instanzen von Objekten beim DOME-Server-Prozess 48 registrieren, der Informationen von registrierten Objekten in einer Server- Objektdatenbank 46 speichert, die den Prozessen 40 bis 44 in dem Knoten und anderen Knoten am gleichen oder anderen Orten zugänglich ist. Auf die Server-Objektdatenbank 46 wird von einer DOME-Client-Schnittstelle jedes mal zugegriffen, wenn der Client einen Dienst von einem Server-Objekt anfordert. Auf alle lokalen Server-Objekte wird direkt durch die DOME- Client-Schnittstelle zugegriffen, indem die Dienstanforderung direkt in die Nachrichtenwarteschlange des Server-Objekts gestellt wird. Ein Server-Objekt ist definiert als Verkapselung von Funktionalität und Daten, die entfernten Client-Objekten durch Methodenaufrufe zugänglich sind.
In jedem Prozess 40 bis 44 gibt es auch eine Instanz von DOME 50, die Interprozess-, Interknoten- und Interort- Kommunikationen zwischen den Client- und den Dienstobjekten bereitstellt. Punkt-zu-Punkt-Kommunikation zwischen Knoten am gleichen Ort oder verschiedenen Orten ist möglich auf TCP/IP (Transmission Control Protocol/Internet Protocol)-Wegen, die durch MH-(Message Handler)-Prozesse 52 und LinkTCP-(Link Transmission Control Protocol)-Prozesse 54 geschaffen werden, die an jedem Knoten angesiedelt sind. Die Kommunikationsaspekte von DOME werden nachfolgend genauer diskutiert.
Ebenfalls bezogen auf Fig. 3 ist ein vereinfachtes Flussdiagramm einer Ausgestaltung eines Mehrort-DOME-Initialisierungsprozesses 50 gezeigt. Wenn ein System an einem Ort startet, ist einer der ersten Schritte, den DOME-Server- Prozess 48 aufzurufen und seine Objekte und Server- Mitgliedsfunktionen zu registrieren, wie in Block 52 dargestellt. Ein Server-Objekt hat ein oder mehrere Server- Mitgliedsfunktionen, die eine einzige benutzerdefinierte Schnittstelle zum Empfangen von Aufrufparametern von und Senden von Aufrufparametern an ein Client-Objekt haben. Server- Mitgliedsfunktionen werden durch Clients mit Hilfe von Identifikationsnummern referenziert, die in den Server- Objektbeschreibungen aufgezeichnet sind. Jede Mitgliedsfunktion hat eine Funktionsprototyp-Definition, die vom Server- Objekt registriert ist. Eine Server-Mitgliedsfunktion- Beschreibungsdatenbank (nicht gezeigt) wird in jedem Prozess geführt, um die registrierten Server- Mitgliedsfunktionsbeschreibungen von registrierten Server- Objekten im Prozess aufzuzeichnen.
Nach Objektregistrierung initialisiert der DOME-Server- Prozess 48 die Server-Objektdatenbank 46, wie in Block 54 gezeigt. In Blöcken 56 und 58 fordert der DOME-Server-Prozess 48 die Anzahl der Knoten an allen Orten und die detaillierten Knotenbeschreibungen für alle Knoten vom Platform-Manager- Knoten an. Der DOME-Server-Prozess 48 speichert die Knotenbeschreibungen in der Objekt-Serverdatenbank und sucht den Satz von zurückgegebenen Knotenbeschreibungen ab, um den Satzindex seines eigenen Knotens und den Namen des Orts, an dem er angesiedelt ist, herauszufinden, wie in Block 60 gezeigt. Der DOME-Server-Prozess 48 stellt dann die Kommunikationsverbindungen durch Kommunizieren mit MH- und LinkTCP-Prozessen 52 und 54 her, wie in Block 62 gezeigt. In Block 64 fordert der DOME-Server-Prozess 48 jeden entfernten Knoten auf, den Inhalt seiner Objekt-Serverdatenbank zu senden. Die Antworten auf diese Anforderungen ermöglichen es dem DOME-Server- Prozess 48, die Objekt-Serverdatenbank 46 mit Informationen über für globalen oder ortsbezogen globalen Dienst in anderen Knoten registrierte Objekte zu aktualisieren. Ein globales Server-Objekt ist für Client-Objekte am gleichen Ort sichtbar, während ein ortsbezogen globales Objekt auch für Client- Objekte an anderen Orten sichtbar ist.
Bezogen auf Fig. 5 enthält die Server-Objektdatenbank 46 Objektbeschreibungen wie etwa den Objektnamen, Knotennamen, Ortsnamen und Instanznamen. Objekt-, Knoten-, Orts- und Instanznamen können alphanumerische Zeichenketten oder Ordnungszahlen gemäß einer vorgegebenen Benennungskonvention sein. Die Knoten- und/oder Ortsnamen können auch Zeiger auf jeweils in der Server-Objektdatenbank geführte Listen sein. Außerdem können die Namen in einer vorgegebenen Weise verkettet sein. Mehrere Kopien eines Objekts können ohne den Instanznamen registriert werden, sofern die Knotenorte unterschiedlich sind. Der Instanzname ermöglicht es einem Client- Objekt, eine einzige Instanz eines Objekts in einem bestimmten Knoten auszuwählen. Wenn der Knotennamen von einem Client-Objekt nicht spezifiziert wird, nimmt DOME an, dass ein beliebiger Knoten, der das Objekt enthält, ein geeigneter Server ist.
Die Server-Objektdatenbank 46 enthält ferner den Knotenbetriebsstatus zur Registrierungszeit des Objekts. Der Knotenbetriebsstatus enthält "außer Betrieb", "Operationssystem minimal" (OS min) oder "in Betrieb". Enthalten sind auch die Betriebsmodi des Objekts, zu denen Aktiv/Standby, Lastteilung, lokaler Dienst, globaler Dienst und ortsbezogen globaler Dienst gehören können. Lastteilungsobjekte sind aktiv, und ein Auswahlverfahren wird verwendet, um die Last zwischen Objekten, die in diesem Modus arbeiten, gleichmäßig zu verteilen. Aktiv/Standby-Objekte registrieren ebenfalls einen Zugangsmodus, der spezifiziert, ob sie im aktiven oder Stand- by-Zustand Anforderungen empfangen sollen. Lokale, globale und ortsbezogen globale Dienstmodi legen fest, ob das Objekt Anforderungen von Client-Objekten, die für den Knoten oder Ort, an dem es angesiedelt ist, lokal sind oder von Client- Objekten von anderen Orten bedienen kann. Die Server- Objektdatenbank 46 enthält ferner die Kommunikationsoptionen und spezielle Informationen dafür des Objekts, wie etwa, ob TCP/IP oder eine User-Datagram-Protocol/Transport-Layer- Interface- (UDP/TLI) -Socket-Verbindung verwendet wird. Wenn TCP/IP verwendet wird, ist die bekannte Anschlussadresse des Objekts enthalten.
In Block 66 fordert der DOME-Server-Prozess 48 an, dass er immer benachrichtigt wird, wenn ein Knoten seinen Betriebszustand ändert, so dass seine Server-Objektdatenbank entsprechend den Änderungen aktualisiert werden kann. Der DOME- Server-Prozess 48 ist dann dienstbereit und wartet auf Dienstanforderungen, wie in Block 68 gezeigt.
Fig. 4 ist ein vereinfachtes exemplarisches Flussdiagramm eines Prozesses zum Registrieren eines Objekts 70. DOME konstruiert zuerst eine Struktur DOMEOBJ, um einen zeitweiligen Speicher für die Beschreibung des Objekts zu schaffen, wie in Block 72 gezeigt. Dann erfolgt in Block 74 eine Bestimmung, ob das Objekt bereits registriert ist. Wenn das Objekt bereits registriert ist, wird seine Nachrichtenwarteschlange entfernt und sein entsprechender Eintrag in der Server- Objektdatenbank 46 gelöscht, wie in Blöcken 76 und 78 gezeigt. Anschließend wird in Block 80 die Objektbeschreibung der Objektinstanz zur Server-Objektdatenbank 46 hinzugefügt.
Wenn das Objekt mit globalem Dienstmodus registriert wird, wie in Block 82 festgelegt, wird die Objektbeschreibung an alle DOME-Server-Prozesse aller anderen Knoten am gleichen Ort verbreitet, um die neu registrierte Objektinstanz auch für Client-Objekte in anderen Knoten sichtbar zu machen, wie in Block 84 gezeigt. Der Prozess endet dann in Block 86. In ortsbezogen globalem Dienstmodus registrierte Objekte werden nicht zur Zeit der Registrierung an entfernte Orte verbreitet. Ortsbezogen globale Objekte werden anderen Orten mitgeteilt, wenn Knoten entfernter Orte die Server-Objektdatenbank abfragen, was typischerweise bei einer Statusänderung des Knotens stattfindet.
Bezogen auf Fig. 6 ist ein vereinfachtes Flussdiagramm der Anforderung eines Dienstes von einem Server-Objekt durch ein Client-Objekt 90 gezeigt. Das Client-Objekt macht eine Dienstanforderung und stellt die Aufrufparameter bereit. DOME formatiert die Dienstaufrufparameter für eine Server- Mitgliedsfunktion in eine Dienstanforderungsnachricht, wie in Bock 92 gezeigt. Dann fordert DOME eine Liste von Server- Objekten an, die zu der vollständigen oder teilweisen Server- Objektbeschreibung des Clients passen, wie in Block 94 gezeigt. Die Server-Objektdatenbank 46 (Fig. 2) ist so organisiert, dass ein DOME-Prozess leicht auf eine bestimmte Objektinstanz mit einer vollen Beschreibung zugreifen kann oder auf alle Objekte zugreifen kann, die einer partiellen Beschreibung entsprechen. Z. B. kann DOME auf alle Objektinstanzen in einem Knoten für eine bestimmte Version eines Objekts zugreifen, oder DOME kann auf alle Objektinstanzen in allen Knoten für alle Versionen zugreifen. Die Dateneinträge für jedes Feld der Datenbank sind in alphabetischer Reihenfolge unter Verwendung eines Hash-Algorithmus verknüpft, der einen schnellen Zugriff auf einen Eintrag oder eine Gruppe von Einträgen ermöglicht. Ferner sind die Daten so organisiert, dass ein Objektname-Eintrag auf eine Liste von Knoteneinträgen zeigt, und jeder Knoteneintrag auf eine Liste von benannten Instanzen zeigt. DOME wählt ein Server-Objekt aus der Liste als Ziel für die Dienstanforderung, sendet die Dienstanforderungsnachricht an das ausgewählte Server-Objekt und endet, wie in Blöcken 95 bis 100 gezeigt.
Die folgenden Leitweglenkungsregeln gelten bei einem Dienstanforderungsaufruf:
1. Wenn als Ziel ein eindeutiger lokaler oder entferner Knotenname spezifiziert ist, wird die Dienstanforderung zu diesem Knoten gelenkt, ohne die nachfolgend im Detail behandelten Aktiv/Standby- und Lastteilungs- Leitweglenkungsregeln anzuwenden. Dies gilt für entfernte Knoten, die sich nicht am gleichen Ort befinden.
2. Wenn das Client-Objekt kein Ziel spezifiziert, wird die Anforderung zu dem oder den Server-Objekt(en) im lokalen Ort geleitet, die die Aktiv/Standby- und Lastteilungs- Leitweglenkungsregeln anwenden.
3. Wenn ein Ortsname oder ein Bezeichner für einen entfernten Ort als Ziel verwendet wird, werden nur ortsbezogen global registrierte Server-Objekte an diesem Ort als Ziele in Betracht gezogen, und die Aktiv/Standby- und Lastteilungs-Leitweglenkungsregeln gelten.
Server-Objekte und Knoten können entweder im Modus Aktiv/Standby oder Aktiv(Lastteilung) registriert sein. Bei aktiven Objekten wird die Last mit Hilfe eines Reihum- Auswahlalgorithmus verteilt, um festzulegen, welches Objekt die vorliegende Dienstanforderung verarbeiten soll. Erst bestimmt der Client-DOME, welcher Knoten sich im höchsten Dienststatus befindet. Dann wählt DOME die Objektinstanz mit höchstem Dienststatus innerhalb des Knotens mit höchstem Dienststatus. Der Dienststatus eines Knotens kann sein: "außer Betrieb", "OS min" oder "in Betrieb", je nachdem, ob der Platform-Manager und/oder die Anwendungssoftware läuft. Details der Dienstzustände werden nachfolgend in Verbindung mit Figs. 12 und 13 diskutiert. Wenn mehrere Knoten im gleichen Dienststatus arbeiten, kann der Reihum-Abzählalgorithmus oder ein entsprechender Algorithmus verwendet werden, um die Dienstanforderungen gleichmäßig zu verteilen. Aktive Objekte können an einem Knoten angesiedelt sein, der im Aktiv/Standby-Modus registriert ist.
Es gibt acht verschiedene Server-Objekt-Leitweglenkungsalgorithmen, die DOME bei der Verarbeitung einer Dienstanforderung eines Client verwenden kann. Wenn anstelle eines speziellen Knotennamens ein Ortsname im Zielfeld spezifiziert ist, wird der Knotenname als ungültig angesehen und die Knotenauswahl ist beschränkt auf die Knoten am angegebenen Ort. Wenn ein Zielname ein Null-Feld ist, ist der lokale Ort spezifiziert.
Die Leitweglenkungsregeln sind:
Das Ziel kann mit dem spezifischen Namen oder anhand eines beliebigen der folgenden fünf Bezeichner spezifiziert werden:
REMOTE_SITE ("&"): Leitweglenkung nur zu an entfernten Orten angesiedelten Knoten unter Verwendung von Aktiv/Standby- und Lastteilungs-Leitweglenkungsregeln für einen Dienstanforderungsaufruf. Für einen Verbreitungsaufruf, Senden an alle qualifizierten Knoten.
ALL_SITES ("$"): Leitweglenkung an alle Knoten an allen Orten, wenn in einem Verbreitungsaufruf verwendet. Verwendung von Aktiv/Standby- und Lastteilungs-Leitweglenkungsregeln bei Dienstanforderungsaufruf.
NOT_LOCAL_NOTE ("#"): Leitweglenkung zu beliebigen Knoten am lokalen Ort mit Ausnahme des Ansiedlungsknotens, sowohl bei Verbreitungsaufruf als auch bei Dienstanforderungsaufruf.
LOCAL_SITE ("?"): Leitweglenkung zu beliebigen Knoten des lokalen Orts bei Verbreitungsaufruf. Verwendung von Aktiv/Standby- und Lastteilungs-Leitweglenkungsregeln bei Dienstanforderungsaufruf.
LOCAL_NODE ("%"): Leitweglenkung zu lokalen Knoten nur für Verbreitungs- oder Dienstanforderungsaufruf.
Die in Anführungszeichen angegebenen Bezeichnerzeichen können verwendet werden, um den Typ des Ziels zu bestimmen. Die oben angegebenen Zeichen dienen nur als Beispiel, und die Erfindung ist nicht notwendigerweise hierauf beschränkt.
Wenn der Client eine Dienstanforderung macht, wird die Server-Objektdatenbank nach dem Objektnamen abgesucht, um festzustellen, ob das Objekt vom Aktiv/Standby-Typ oder vom immer aktiven Typ ist. Dann wird der Knotenname untersucht, ob er eine Null-Zeichenkette oder ein eindeutiger ASCII-Name ist. Der Instanzname wird auch untersucht, ob er eine Null- Zeichenkette oder ein eindeutiger ASCII-Name ist. Diese drei Indikatoren werden dann verwendet, um auf die Knoten- Leitweglenkung und Instanzauswahlverfahren zuzugreifen.
Jeder der acht Server-Objekt-Leitweglenkungsalgorithmen besteht aus zwei Teilen. Im Client-Knoten wählt DOME den besten Server-Knoten zum Bedienen der Anforderung und sendet die Anforderung an den Knoten. Dieser Teil der Dienstleitweglenkung ist das Server-Knotenauswahlverfahren. Im Server-Knoten wählt DOME die beste Server-Objektinstanz als Empfänger für die Anforderung. Dieser Teil der Dienstleitweglenkung ist bekannt als Server-Instanzauswahlverfahren. Die obige Tabelle enthält einen Eintrag für jede Kombination von Objekttyp, Knotenname und Instanzname. Jeder Eintrag gibt die Nummern des Knotenauswahlverfahrens und des Instanzauswahlverfahrens, die nachfolgend im Detail beschrieben werden.
1. Der Client spezifiziert einen eindeutigen Namen eines Knotens, der die Dienstanforderung verarbeiten muss. Zuerst wird auf die Server-Objektdatenbank zugegriffen, um zu bestimmen, ob das Server-Objekt am spezifizierten Knotennamen angesiedelt ist. Wenn es am spezifizierten Knoten nicht gefunden wird, gibt DOME einen "Objekt nicht gefunden"-Fehler aus. Wenn der Server-Instanzname spezifiziert ist, wird dann die Server-Objektdatenbank abgesucht, um sicherzustellen, dass die bezeichnete Instanz am spezifizierten Knotennamen angesiedelt ist. Ein "Instanz nicht gefunden"-Fehler wird zurückgegeben, wenn der genaue Instanzname am Knoten nicht existiert. Die Dienstanforderungsnachricht wird formatiert und an den spezifizierten Knoten gesendet.
2. Der Client spezifiziert einen Objektnamen, der zum Aktiv/Standby-Typ gehört und fordert keinen speziellen Knoten oder Instanz an. Der Client DOME konstruiert eine Instanzliste von allen Instanzen in allen Knoten mit dem angeforderten Objektnamen. Die registrierten Server- Objektempfangszustände werden in der Server- Objektdatenbank gefunden. Das Server-Objekt kann registriert sein als empfangend im aktiven Zustand, im Stand- by-Zustand oder im Aktiv/Standby-Zustand. Die Instanzliste wird nach Instanzen des Objekts abgesucht, die an Knoten angesiedelt sind, die sich im erforderlichen Empfangszustand aktiv, Standby- oder beides befinden. Die Dienstanforderung wird an einen oder mehrere qualifizierte Knoten geschickt. Wenn kein Knoten qualifiziert ist, erfolgt eine Fehlerrückmeldung an den Client.
3. Der Client spezifiziert einen Objektnamen, der aktiv/Standby ist, und will die Dienstanforderung an einen spezifischen Instanznamen schicken, der in einem beliebigen Knoten des Systems existieren kann. Die Server- Objektdatenbank wird überprüft, um festzustellen, an welchem Knoten der Instanzname angesiedelt ist.
4. Der Objekttyp ist immer aktiv, und der Client hat keinen spezifischen Knoten oder Instanznamen spezifiziert. Zuerst konstruiert DOME eine Liste aller Knoten, die den Objektnamen enthalten. Wenn keine gefunden werden, wird ein Fehler an den Client zurückgegeben. Als nächstes sucht DOME die Liste nach dem Knoten im höchsten Dienstzustand ab und löscht aus der Liste jeden Knoten, der nicht den höchsten gefundenen Dienstzustand hat. Dann wählt DOME einen Knoten aus der verbleibenden Liste von Knoten basierend auf einem Reihum-Auswahlalgorithmus. Der zuvor ausgewählte Index in der Liste wird inkrementiert und verwendet, um den bei dieser Dienstanforderung zu verwendenden Knoten auszuwählen.
5. Der Objekttyp ist immer aktiv, und der Client hat einen spezifischen Instanznamen spezifiziert. Zuerst konstruiert DOME eine Liste aller Knoten, die den Objektnamen und den spezifischen Instanznamen enthalten. Wenn keine gefunden werden, wird ein Fehler an den Client zurückgegeben. Dann sucht DOME die Liste nach dem Knoten mit dem höchsten Dienstzustand ab und löscht aus der Liste jeden Knoten, der nicht den höchsten gefundenen Dienstzustand hat. Schließlich wählt DOME aus der verbleibenden Liste von Knoten einen Knoten basierend auf einem Reihum-Auswahlalgorithmus. Der zuvor ausgewählte Index in der Liste wird inkrementiert und verwendet, um den bei dieser Dienstanforderung zu verwendenden Knoten auszuwählen.
Alternativ kann ein Client-Objekt eine spezifizierte Anforderung an einen Server in einem anderen Knoten machen, der nicht in der lokalen Server-Objektdatenbank gelistet ist. Dies sind Server, die nicht als ortsbezogen globale Server- Objekte registriert worden sind. Diese spezifialisierte Anforderung wird an den Nachrichtenhandhabungsprozess weitergegeben, der die Zielwarteschlange ID nach dem angeforderten Objekt absucht und die Nachricht an den DOME-Server-Prozess dieses Objekts weitergibt. Die DOME-Server-Schnittstelle des Server-Objektes empfängt die Dienstanforderungsnachricht und formatiert die in der Nachricht enthaltenen Parameter in die vom Server-Objekt erwartete Eingabefolge. Das Server-Objekt empfängt dann die Nachricht und führt den angeforderten Dienst aus.
Fig. 7 liefert einige zusätzliche Details des Prozesses zum Holen der Liste von Server-Objekten 110. Auch auf Fig. 2 bezogen umfasst die Server-Objektdatenbank 46 einen Revisionszähler 111, der jedesmal inkrementiert wird, wenn der Inhalt der Datenbank verändert wird. Jeder Prozess 40 bis 44 in dem Knoten hat einen lokalen Cache 112, dessen Inhalt eine historische Aufzeichnung von vergangenen Dienstanforderungen und entsprechenden passenden Server-Objekten zum Durchführen des angeforderten Dienstes ist. Im lokalen Cache 112 wird auch eine Aufzeichnung davon geführt, was zur Zeit des letzten Datenbankzugriffs der Zählwert des Revisionszählers war. In Blöcken 114 und 116 wird der Revisionszähler 111 gelesen und mit der lokalen Aufzeichnung des Zählwerts verglichen. Wenn die Zahlen nicht zusammen passen, ist der Inhalt der Server- Objektdatenbank 46 geändert worden, und der Inhalt des lokalen Cache 112 ist nicht mehr gültig. Deshalb wird auf die Server-Objektdatenbank 46 zugegriffen, indem zunächst der Zeichengeber (semaphore) gesperrt wird, der relevante Eintrag oder die relevanten Einträge in der Datenbank 46 gelesen werden und dann der Zeichengeber freigegeben wird, wie in Blöcken 118 bis 122 gezeigt. Wenn hingegen die lokal geführte Zählung und der Revisionszähler gleich sind, kann der lokale Cache von Objektbeschreibungen nach einer Entsprechung abgesucht werden, wie in Block 124 gezeigt. Auch wenn es zu der. Dienstanforderung keine Entsprechung gibt, wird auf die Server-Objektdatenbank 46 in ähnlicher Weise wie in Blöcken 118 bis 122 gezeigt zugegriffen. Anschließend endet der Prozess in Block 126.
Wenn ein Knoten zuerst initialisiert wird, fordert er andere Knoten am gleichen Ort auf, ihn mit den in ihren Server- Objektdatenbanken gespeicherten Objektbeschreibungen zu versorgen, wie in Block 64 von Fig. 3 gezeigt. Ortsbezogen globale Server werden nicht an entfernte Orte verbreitet, wenn sie registriert werden; ortsbezogen globale Server-Objekte werden für Clients an entfernten Orten sichtbar, wenn die Knoten am entfernten Ort nach der Server-Objektdatenbank fragen, was typischerweise bei einer Knotenstatusänderung stattfindet. Der Server-Objektlistenanforderungsprozess 130 ist in Fig. 8 gezeigt. Eine Bestimmung, ob die Anforderung von einem Knoten an einem lokalen Ort oder einem entfernten Ort aus erfolgt, findet in Block 132 statt. Wenn die Anforderung von einem lokalen Ort kommt, werden die Objektbeschreibungen von für globalen Dienst registrierten Server-Objekten erhalten, wie in Block 134. Andernfalls ist die gewünschte Objektbeschreibung eine von für ortsbezogen globalen Dienst registrierten Objekten, die in Block 136 erhalten wird. Die Objektbeschreibung wird dann dem anfordernden Knoten mitgeteilt, wie in Block 138 gezeigt. Der Prozess endet in Block 140.
Fig. 9 zeigt den Prozessfluss für den Empfang der Objektbeschreibung von einem Knoten am lokalen Ort oder einem entfernten Ort 150. Bei Empfang der Objektbeschreibung wird der Zeichengeber der Server-Objektdatenbank erhalten, um andere Prozesse zu sperren, wie in Block 152 gezeigt. In Block 154 wird der für die Datenbank geführte Revisionszähler inkrementiert, um widerzuspiegeln, dass die Datenbank verändert worden ist. Die Server-Objektbeschreibung für den betreffenden Knoten wird dann gelöscht, und die aktualisierte Beschreibung wird in die Server-Objektdatenbank eingefügt, wie in Blöcken 156 und 158 gezeigt. Dann wird in Block 160 der Zeichengeber freigegeben, und der Prozess endet in Block 162.
Wie oben dargelegt, erfolgt Kommunikation zwischen Knoten über die Message-Handler- und LinkTCP-Prozesse. Fig. 10 veranschaulicht den Kommunikationsprozess. Fig. 10 zeigt ein Client-Objekt 174 und ein Server-Objekt 176, wobei Client- und Server-Objekte an verschiedenen Knoten X und Y 170 bzw. 172 angesiedelt sind. Wenn das Server-Objekt 172 in einem anderen Knoten angesiedelt ist, verwendet DOME eine logische Verknüpfungsschnittstelle des Netzwerks, die von den zwei spezifizierten Prozessen, dem Message Handler und dem LinkTCP, für die Kommunikation zwischen Knoten bereitgestellt wird. Die Nachrichten-Handler- und LinkTCP-Prozesse erzeugen TCP/IP-Wege für die Kommunikation zwischen den Knoten. Um die Dienstanforderung zu senden, gibt DOME die Clientanforderung an einen residenten Nachrichten-Handler-Prozess 178 weiter. Der Nachrichten-Handler gibt dann die Anforderung an den LinkTCP-Prozess 180 des Zielknotens weiter, der die Dienstanforderung in die Server-Objekt-IPC-System V- Nachrichtenwarteschlange 182 für das Server-Objekt 176 stellt. Das Server-Objekt kann von der Dienstanforderung durch ein vorgegebenes Signal informiert werden, das die Ankunft dieser Nachricht ankündigt. Alternativ kann das Server- Objekt das Vorhandensein von Dienstanforderungen abfragen oder pausieren, bis eine Dienstanforderung vorliegt. Jede Nachrichtenwarteschlange 182 kann eine vorgegebene maximale Kapazitätsgrenze für die Zahl von Nachrichten und die Gesamtzahl von Bytes haben.
Wenn ein Ergebnis oder eine Antwort an das Client-Objekt 174 zurückgegeben werden soll, wird sie zuerst an einen im Knoten X 172 angesiedelten Nachrichten-Handler 184 gesendet. Der Nachrichten-Handler 184 überträgt die Rücknachricht an einen LinkTCP-Prozess 186, der im Knoten Y 170 angesiedelt ist. Die Nachricht wird dann in einer Nachrichtenwarteschlange 188 des Teilnehmerobjekts 174 platziert. Jede Teilnehmeranforderung ist mit einer eindeutigen Transaktions-ID gekennzeichnet, die mit der Serverantwort an den Client zurückgegeben wird. Das Client-Objekt ist dann sicher, dass die korrekte Antwort vom Server-Objekt für die gestellte Anforderung zurückgegeben wurde. Man beachte, dass wenn das Ziel-Server-Objekt im gleichen Knoten wie das Client-Objekt angesiedelt ist, die Dienstanforderungsnachricht direkt vom Client-Objekt an die Nachrichtenwarteschlange des Server-Objekts übertragen wird.
Fig. 11 zeigt ein anderes Verfahren für die Kommunikation zwischen Knoten. Ein in dem Knoten · 170 angesiedeltes Client-Objekt 174 kann eine Dienstanforderung über UDP an ein Server-Objekt 176 senden, das im Knoten Y 172 angesiedelt ist. Ergebnisse des durchgeführten Dienstes können, wenn vorhanden, in der gleichen Weise an das Client-Objekt 174 zurückgegeben werden. Dieses Verfahren beinhaltet weniger Überhang als das TCP/IP-Übertragungsverfahren, garantiert aber nicht die Zustellung der Nachricht. Ein globales Server- Objekt kann seine bekannte UDP-Anschluss-ID an andere Knoten, wo es registriert ist, verbreiten. Eine bekannte UDP- Anschluss-ID eines ortsbezogen globalen Server-Objekts wird Knoten an anderen Orten verfügbar gemacht, wenn die Server- Objektdatenbank des Knotens, an dem es angesiedelt ist, von den entfernten Knoten angefordert wird.
Bezogen auf Fig. 12 wird ein Knotenstatus-Einstellprozess 190 verwendet, um eine Server-Objektdatenbank automatisch zu aktualisieren oder eine Knotenstatusänderung widerzuspiegeln. Jedesmal, wenn der Status oder Dienstzustand eines entfernten Knotens geändert wird, aktualisiert der DOME-Server-Prozess 48 (Fig. 2) eines Knotens seine Server- Objektdatenbank. Der Knoten empfängt den neuen Status des entfernten Knotens, der eine Statusänderung durchgemacht hat, und setzt den alten Status gleich dem früheren Dienstzustand, wie in Block 192 gezeigt. Wenn der neue Status "außer Betrieb" ist, wie in Blöcken 194 und 196 gezeigt, was bedeutet, dass der Knoten nicht mehr läuft, muss der Inhalt der Server- Objektdatenbank aktualisiert werden, um die registrierten Objekte des herabgestuften Knotens zu entfernen. Dies geschieht, indem zunächst der Zeichengeber der Server- Objektdatenbank gesperrt und der Revisionszähler inkrementiert wird, wie in Blöcken 198 und 200 gezeigt. Dann werden die im herabgestuften Knoten angesiedelten registrierten Server-Objekte aus der Server-Objektdatenbank gelöscht, wie in Block 202 gezeigt. Der Zeichengeber wird dann in Block 204 freigegeben. Die Server-Objektdatenbank ist damit von allen registrierten Objekten befreit, die in dem außer Betrieb gegangenen Knoten angesiedelt waren.
Wenn der neue Status "OS min" ist, wie in Blöcken 194 und 210 bestimmt, oder der neue Status "in Betrieb" ist, wie in Block 216 bestimmt, kann eine Aktualisierung der Server-Objektdatenbank erforderlich sein, je nachdem, ob der Knotenstatus heraufgestuft oder herabgestuft wird, wie in Block 218 festgelegt. Eine Heraufstufung des Status, entsprechend einem Übergang in der Richtung:
außer Betrieb → OS min → in Betrieb
würde dazu führen, dass die Bedingung in Block 218: neuer Status < alter Status falsch ist. Umgekehrt würde ein Übergang in der Richtung:
in Betrieb → OS min → außer Betrieb
die Bedingung in Block 218 wahrmachen. Die Boolesche Variable UPDATE kann verwendet werden, um explizit anzufordern, dass die Datenbank von Server-Objekten befreit wird, die nicht mehr zum Dienst zur Verfügung stehen. Wenn die Bedingung in Block 218 falsch ist, wird eine Kopie der gesamten Server- Objektdatenbank des entfernten Knotens angefordert und zur lokalen Datenbank hinzugefügt, wie in Block 220 gezeigt. Die Server-Objekt-Anforderungs- und -Empfangsprozesse sind in den oben beschriebenen Figs. 8 und 9 gezeigt.
Wenn die Bedingung in Block 218 wahr ist, müssen die Inhalte der Server-Objektdatenbank des lokalen Knotens selektiv gelöscht werden. Bei einer Herabstufung des Dienstzustandes sind die Objekte, die unter einem höheren Dienstzustand als dem gegenwärtigen neuen Zustand registriert wurden, nicht mehr gültig, und ihre jeweilige Beschreibung wird aus der Server-Objektdatenbank entfernt. Dazu wird zuerst der Zeichengeber der Server-Objektdatenbank gesichert, wie in Block 222 gezeigt. Dann wird der Revisionszähler inkrementiert, um diese neue Änderung in den Inhalten der Datenbank widerzuspiegeln. Anschließend werden in Block 226 alle Objekte mit einem bei Registrierungszeit höheren Status als dem neuen Status aus der Datenbank gelöscht, da sie nicht mehr laufen.
Der Zeichengeber wird dann in Block 228 freigegeben, und die Prozedur endet in Block 230. Da der Dienstzustand des Knotens in der Server-Objektdatenbank beim Registrieren eines Objekts notiert wird, kann die Datenbank automatisch aktualisiert werden, um diejenigen Objekte zu entfernen, die nicht mehr gültig sind, wenn der Status des betreffenden Knotens herabgestuft wird.
Fig. 13 ist ein Zustandsdiagramm, das die Dienstzustandsübergänge eines Knotens zeigt. Der Übergang zwischen dem außer- Betrieb-Zustand 196 und dem OS-min-Zustand 210 wird dadurch verursacht, ob der Platform-Manager 40 und 41 (Fig. 2) läuft. Wenn der Platform-Manager steht, ist der Knoten im außer- Betrieb-Zustand 196, wenn der Platform-Manager läuft und keine Anwendungssoftware läuft, ist der Knoten im OS min-Zustand 210. Wenn hingegen der Platform-Manager läuft und die Anwendungssoftware läuft, ist der Knoten im in-Betrieb-Zustand 216. Anhand des Zustandsdiagramms kann beobachtet werden, dass alle Platform-Managerobjekte zur Registrierungszeit den außer-Betrieb-Zustand haben, und dass alle anderen Prozessobjekte zur Registrierungszeit den OS min-Zustand haben.
Vorzugsweise befinden sich alle DOME-Schnittstellen in einer in Betrieb gemeinsam genutzten Bibliothek und werden mit dem Anwendercode im Betrieb nach Bedarf gelinkt. Da auf gemeinsam genutzte Bibliotheken durch mehr als einen Prozess zugegriffen werden kann, kann der Benutzer ein DOME-Objekt im eigenen Prozessraum des Benutzers instanziieren. Wenn DOME- Mitgliedsfunktionen referenziert werden, werden sie zur Ausführungszeit aus der gemeinsam genutzten Bibliothek gelinkt.

Claims

1. Verteiltes Objektnachrichtenvermittlungssystem (10) für eine Mehrzahl von geographisch voneinander entfernten und miteinander über wenigstens eine Fernmeldeverbindung gekoppelten Orten (12, 13), wobei jeder Ort eine Mehrzahl von Prozessorknoten (15-21, 25-32) aufweist, die durch wenigstens ein Fernmeldenetzwerk gekoppelt sind, mit:

einer Mehrzahl von in jedem Prozessorknoten (15-21, 27-32) ablaufenden Prozessen (40-44), wobei jeder der mehreren Prozesse (40-44) Telefonieanwendungen ausführt;

wobei die Mehrzahl von Prozessen (40, 44) eine Mehrzahl von Objekten registrieren, wobei die Objekte Teilnehmerobjekte (174) und Serverobjekte (176) umfassen und jedes Objekt wenigstens eine Instanz hat, wobei jedes Objekt eine Darstellung eines Abschnitts von Hardware und Softwarediensten ist, die von den Telefonieanwendungen bereitgestellt werden;

wobei die Mehrzahl von Serverobjekten (176) selektiv für globalen Dienst für Dienstverfügbarkeit für Teilnehmerobjekte (174) in einem lokalen Knoten und einem lokalen Ort und für ortsbezogenen globalen Dienst für Dienstverfügbarkeit für Teilnehmerobjekte (174) in einem Prozessorknoten an geographisch entfernten Orten registriert sind, wobei jeder Prozessorknoten (15-21, 25-32) Serverobjekte (176) von anderen Knoten an seinem lokalen Ort und Knoten von geographisch entfernten Orten, die für globalen oder ortsbezogenen globalen Dienst registriert worden sind, registriert, wobei für globalen Dienst registrierte Serverobjekte (176) an andere Prozessorknoten (15-21, 25-32) am lokalen Ort bei Registrierung verbreitet werden und für ortsbezogenen globalen Dienst registrierte Serverobjekte (176) an einen bestimmten Prozessorknoten an einem entfernten Ort über das Fernmeldenetz bei Anforderung von dort verschickt und nicht bei Registrierung verbreitet werden;

eine Serverobjekt-Datenbank (46) an jedem Prozessorknoten (15-21, 25-32), die eine Serverobjektbeschreibung für jedes registrierte Serverobjekt (176) speichert, wobei die Serverobjektbeschreibung einen Objektnamen, einen Knotennamen, einen Ortsnamen und einen Instanznamen, sofern mehr als eine Instanz eines Objekts in dem gleichen Prozessorknoten registriert ist, umfaßt; und

eine Teilnehmer-Server-Schnittstelle (48), die durch die Teilnehmerobjekte zugänglich ist und Dienstanforderungen von dort empfängt, die auf die Serverobjekt-Datenbank (46) für wenigstens ein Ziel-Serverobjekt zugreift, das in der Lage ist, den angeforderten Dienst auszuführen, die Dienstanforderung in eine Nachricht formatiert und die Nachricht an die Ziel-Serverobjekte (176) an einem lokalen Knoten, lokalen Ort oder einem Prozessorknoten an einem geographisch entfernten Ort weitergibt.

2. System nach Anspruch 1, bei dem die Mehrzahl von Prozessen (40-44) ferner einen lokalen Cache (112) für zurückliegende Serverobjektdatenbank-Zugriffsanforderungen und Ziel-Serverobjekte (176) umfaßt.

3. System nach Anspruch 2, bei dem die Serverobjektdatenbank (46) ferner einen Revisionszähler (111) umfaßt, der eine Zählung von an der Serverobjektdatenbank (46) durchgeführten Revisionen aufzeichnet, wobei die Teilnehmer- Server-Schnittstelle (48) auf den lokalen Cache (112) zugreift, um Serverobjekte (176) in Reaktion auf die Gleichheit einer lokalen Revisionszählung mit der Zählung des Revisionszählers (111) in der Serverobjektdatenbank (46) zu paaren, und auf die Serverobjektdatenbank (46) in Reaktion auf eine Ungleichheit des lokalen Revisionszählers mit dem Zählwert des Revisionszählers (111) in der Serverobjektdatenbank (46) zugreift.

4. System nach Anspruch 1, ferner mit

einem Nachrichtenhandhabungsprozess (178, 174) in jedem Prozessorknoten (15-21, 25-32) zum Senden von Nachrichten an Ziel-Serverobjekte (176), die in Prozessorknoten an geographisch entfernten Orten vorhanden sind; und

einem Link-TCP-Prozeß (180, 186), der in jedem Prozessorknoten (15-21, 25-32) vorhanden ist, zum Empfangen von Nachrichten von Teilnehmerobjekten (174), die in Prozessorknoten an geographisch entfernten Orten vorhanden sind.

5. System nach Anspruch 4, bei dem der Nachrichtenhandhabungs-(178, 184) und Link-TCP-Prozeß (180, 186) Punkt-zu- Punkt TCP/IP-Wege zwischen lokalen Knoten und Prozessorknoten an geographisch entfernten Orten zum Senden und Empfangen der Nachrichten erzeugen.

6. System nach Anspruch 1, bei dem die in der Serverobjektdatenbank (46) gespeicherte Serverobjektbeschreibung ferner einen Prozessorknoten-Dienstzustand zur Objektregistrierungszeit enthält.

7. System nach Anspruch 6, bei dem der Prozessorknoten- Dienstzustand einen Ausserbetriebszustand (196), einen Minimalbetriebszustand (210) und einen In-Betrieb-Zustand (216) umfaßt.

8. System nach Anspruch 6, bei dem in der Serverobjektdatenbank (46) registrierte Objekte mit einem höheren Betriebszustand als einem gegenwärtigen Betriebszustand eines Aufenthaltsknotens der registrierten Objekte in Reaktion auf eine Herunterstufung des Betriebszustandes des Aufenthaltsknotens gelöscht werden.

9. System nach Anspruch 6, bei dem die Serverobjektdatenbank (46) durch eine neue Kopie einer Serverobjektdatenbank (46) eines Prozessorknotens an einem geographisch entfernten Ort in Reaktion auf eine Heraufstufung des Betriebszustandes des Prozessorknotens an dem geographisch entfernten Ort ersetzt wird.

10. System nach Anspruch 1, bei dem die in der Serverobjektdatenbank (46) gespeicherte Serverobjektbeschreibung ferner einen Betriebsmodus der registrierten Objekte umfaßt, wobei die Betriebsmodi Aktiv-Bereitschafts- und Lastteilungsmodi umfassen.

11. System nach Anspruch 1, bei dem die in der Serverobjektdatenbank (46) gespeicherte Serverobjektbeschreibung ferner eine Identität einer Nachrichtenwarteschlange für jedes registrierte Objekt umfaßt.

12. System nach Anspruch 1, bei dem die in der Serverobjektdatenbank (46) gespeicherte Serverobjektbeschreibung ferner eine bekannte Anschluß-Identität für jedes registrierte Objekt umfaßt.

13. System nach Anspruch 1, bei dem der bestimmte Prozessorknoten an dem entfernten Ort eingerichtet ist, bei Initialisierung oder Statusänderung eine Anforderung für die für ortsbezogenen globalen Dienst registrierten Serverobjekte (176) zu machen.

14. Verfahren zur verteilten Objekt-Nachrichtenvermittlung für eine Mehrzahl von geographisch entfernten Orten (12, 13), wobei jeder Ort eine Mehrzahl von untereinander verbundenen Knoten (15-21, 25-32) hat und jeder Knoten eine Mehrzahl von darauf laufenden Prozessen (40-44) hat, mit den Schritten:

- Registrieren wenigstens einer Instanz einer Mehrzahl von Serverobjekten (176) durch eine Mehrzahl von Prozessen (40-44) in jedem Knoten (15-21, 25-32), wobei die Serverobjekte (176) für lokalen, globalen und/oder ortsbezogen globalen Dienst registriert werden, wobei jeder aus der Mehrzahl von Prozessen (40-44) Telefonieanwendungen durchführt, wobei jedes Serverobjekt (176) eine Darstellung eines Abschnitts von Hardware- oder Softwarediensten bereitstellt, die von den Telefonieanwendungen bereitgestellt werden;

- Speichern einer Serverobjektbeschreibung jedes registrierten Objekts in einer Serverobjektdatenbank (46), wobei die Serverobjektbeschreibung einen Objektnamen, einen Knotennamen, einen Ortsnamen und einen Instanznamen, wenn mehr als eine Instanz eines Objekts in dem gleichen Knoten registriert ist, umfaßt;

- Verbreiten der Serverobjektbeschreibungen von für globalen Dienst registrierten Serverobjekten (176) an andere Knoten an einem lokalen Ort bei Registrierung;

- Bereitstellen der Serverobjektbeschreibungen von für ortsbezogenen globalen Dienst registrierten Serverobjekten (176) für Knoten an geographisch entfernten Orten auf Anfrage von dort, aber nicht durch Verbreiten bei Registrierung;

- Anfordern von Serverobjektbeschreibungen von für ortsbezogenen globalen Dienst registrierten Serverobjekten (176) von Knoten an geographisch entfernten Orten;

- Empfangen und Registrieren der Serverobjektbeschreibungen von für globalen Dienst registrierten Serverobjekten (176) von anderen Knoten an dem lokalem Ort;

- Empfangen und Registrieren der Serverobjektbeschreibungen von für ortsbezogenen globalen Dienst registrierten Serverobjekten von Knoten an geographisch entfernten Orten über das Fernmeldenetz;

- Speichern der empfangenen Serverobjektbeschreibungen in der Serverobjektdatenbank (46);

- Empfangen von Dienstanforderungen von Teilnehmerobjekten (174), Durchsuchen der Serverobjektdatenbank (46) nach einem Ziel-Serverobjekt (176), das in der Lage ist, die Dienstanforderungen zu erfüllen, Formatieren der Dienstanforderungen in Nachrichten und Weiterleiten der Nachrichten an das Ziel-Serverobjekt (176) am lokalen Knoten, lokalen Ort oder einem geographisch entfernten -rt.

15. Verfahren nach Anspruch 14, ferner mit den Schritten:

- Speichern einer Revisionszählung in der Serverobjektdatenbank (46) in Reaktion auf die Anzahl von an der Serverobjektdatenbank (46) durchgeführten Zahl von Revisionen.

- Speichern eines lokalen historischen Caches (112) für zurückliegende Dienstanforderungen und Ziel-Serverobjekte (176), die in der Lage waren, die Dienstanforderungen auszuführen, in jedem Prozeß (40-44);

- Speichern eines lokalen Revisionszählwerts in dem lokalen historischen Cache (112);

- Zugreifen auf den lokalen historischen Cache (112) in Reaktion auf eine Dienstanforderung und die Gleichheit des lokalen Revisionszählwerts mit dem Revisionszählwert der Zählerobjektdatenbank (46); und

- Zugreifen auf die Serverobjektdatenbank (46) in Reaktion auf eine Dienstanforderung und die Ungleichheit des lokalen Revisionszählwerts mit dem Revisionszählwert der Serverobjektdatenbank.

16. Verfahren nach Anspruch 15, bei dem der Schritt des Speicherns der Serverobjektbeschreibung ferner den Schritt des Speicherns eines Knoten-Betriebszustands zur Zeit der Objektregistrierung für jedes registrierte Objekt umfaßt.

17. Verfahren nach Anspruch 16, bei dem der Schritt des Speicherns eines Knoten-Betriebszustands ferner den Schritt des Speicherns eines Ausser-Betrieb-Zustands (196), eines Minimalbetriebszustands (210) oder eines In-Betrieb- Zustands (216) umfaßt.

18. Verfahren nach Anspruch 16, ferner mit dem Schritt:

- Herunterstufens eines Knotens auf einen niedrigeren Betriebszustand; und

- Löschen von in dem heruntergestuften Knoten vorhandenen registrierten Objekten, die einen höheren Betriebszustand als diesen niedrigeren Betriebszustand des heruntergestuften Knotens haben, aus der Serverobjektdatenbank (46)

19. Verfahren nach Anspruch 16, ferner mit dem Schritt:

- Heraufstufen eines Knotens auf einen höheren Betriebszustand;

- Benachrichtigen aller anderen Knoten am lokalen Ort und an geographisch entfernten Orten über den höheren Betriebszustand des heraufgestuften Knotens;

- Anfordern einer Kopie von Inhalten der Serverobjektdatenbank (46) des heraufgestuften Knotens; und

- Speichern der Kopie in der Serverobjektdatenbank (46) in allen anderen Knoten.

20. Verfahren nach Anspruch 14, bei dem der Schritt des Speicherns der Serverobjektbeschreibung ferner den Schritt des Speicherns eines Betriebsmodus der registrierten Objekte umfaßt, wobei die Betriebsmodi Aktiv- /Bereitschafts- und Lastteilungsmodus umfassen.

21. Verfahren nach Anspruch 14, bei dem der Schritt des Speicherns der Serverobjektbeschreibung ferner den Schritt des Speicherns einer Identität einer Nachrichtenwarteschlange für jedes registrierte Objekt umfaßt.

22. Verfahren nach Anspruch 14, bei dem der Schritt des Speicherns der Serverobjektbeschreibung ferner den Schritt des Speicherns einer bekannten Anschlußidentität für jedes registrierte Objekt umfaßt.

23. Verfahren nach Anspruch 14, bei dem der Schritt des Speicherns der Serverobjektbeschreibung ferner den Schritt des Speicherns eines Betriebsmodus umfaßt, der einen Aktiv-/Bereitschaftsmodus oder Lastteilungsmodus spezifiziert.

24. Verfahren nach Anspruch 23, bei dem der Schritt des Durchsuchens der Serverobjektdatenbank (46) nach Ziel- Serverobjekten (176) den Schritt des Verteilens von Dienstanforderungen im wesentlichen gleichmässig auf die Ziel-Serverobjekte (176) in Reaktion auf die Registrierung der Serverobjekte (176) für den Lastteilungsbetriebsmodus umfaßt.

25. Verfahren nach Anspruch 23, bei dem der Schritt des Durchsuchens der Serverobjektdatenbank (46) nach Ziel- Serverobjekten (176) den Schritt des Verteilens der Dienstanforderungen im wesentlichen gleichmäßig auf die Ziel-Serverobjekte (176) unter Verwendung eines zyklischen Multiplexalgorithmus in Reaktion auf die Registrierung der Serverobjekte (176) für den Lastteilungsbetriebsmodus umfaßt.

26. Verfahren nach Anspruch 14, bei dem der Schritt des Weiterleitens der Nachrichten an die Ziel-Serverobjekte (176) den Schritt des Herstellens einer Kommunikationsverbindung mit einem Zielknoten umfasst, in dem das Ziel- Serverobjekt (176) vorhanden ist.

27. Verfahren nach Anspruch 14, bei dem der Schritt des Weiterleitens der Nachrichten an die Ziel-Serverobjekte (176) den Schritt des Herstellens einer TCP-IP- Kommunikationsverbindung mit einem Zielknoten umfasst, in dem das Ziel-Serverobjekt (176) vorhanden ist.

28. Verfahren nach Anspruch 14, bei dem der Schritt des Weiterleitens der Nachrichten an die Ziel-Serverobjekte (176) den Schritt des Weiterleitens der Nachricht über eine UDP/TLI-Socket-Verbindung eines Zielknotens umfaßt, in dem das Ziel-Serverobjekt (176) vorhanden ist.

29. Verfahren nach Anspruch 26, bei dem der Schritt des Weiterleitens der Nachrichten an die Ziel-Serverobjekte (176) folgende Schritte umfaßt:

- Weiterleiten der formatierten Nachricht an einen Nachrichtenhandhabungsprozeß (178, 184), wobei der Nachrichtenhandhabungsprozeß (178, 184) die Nachricht an einen Link- TCP-Prozeß (180, 186) in dem Zielknoten sendet, und

- Weiterleiten der Nachricht an das Ziel-Serverobjekt.

30. Verfahren nach Anspruch 14, mit dem weiteren Schritt des Empfangens einer Antwort von dem Ziel-Serverobjekt (176).

31. Verfahren nach Anspruch 14, bei dem der Schritt des Anforderns von Ziel-Objektbeschreibungen von für ortsbezogenen globalen Dienst registrierten Serverobjekten von Knoten an geographisch entfernten Orten bei Knoteninitialisierung oder Statusänderung vorkommt.