DE69624579T2 - System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten - Google Patents
System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren ortenInfo
- Publication number
- DE69624579T2 DE69624579T2 DE69624579T DE69624579T DE69624579T2 DE 69624579 T2 DE69624579 T2 DE 69624579T2 DE 69624579 T DE69624579 T DE 69624579T DE 69624579 T DE69624579 T DE 69624579T DE 69624579 T2 DE69624579 T2 DE 69624579T2
- Authority
- DE
- Germany
- Prior art keywords
- server
- node
- objects
- server object
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 116
- 230000008569 process Effects 0.000 claims description 84
- 230000006854 communication Effects 0.000 claims description 19
- 238000004891 communication Methods 0.000 claims description 16
- 230000004044 response Effects 0.000 claims description 15
- 230000008859 change Effects 0.000 claims description 6
- 125000004122 cyclic group Chemical group 0.000 claims 1
- 230000001737 promoting effect Effects 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 11
- 238000010187 selection method Methods 0.000 description 5
- 230000000644 propagated effect Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 230000003190 augmentative effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Description
- 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.
- 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.
- 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.
- 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.
- 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 (31)
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/526,953 US5892946A (en) | 1995-09-12 | 1995-09-12 | System and method for multi-site distributed object management environment |
PCT/US1996/014755 WO1997010547A1 (en) | 1995-09-12 | 1996-09-11 | System and method for multi-site distributed object management environment |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69624579D1 DE69624579D1 (de) | 2002-12-05 |
DE69624579T2 true DE69624579T2 (de) | 2003-05-22 |
Family
ID=24099505
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69624579T Expired - Lifetime DE69624579T2 (de) | 1995-09-12 | 1996-09-11 | System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten |
Country Status (7)
Country | Link |
---|---|
US (1) | US5892946A (de) |
EP (1) | EP0850447B1 (de) |
JP (1) | JP3846736B2 (de) |
AU (1) | AU6978196A (de) |
CA (1) | CA2231684A1 (de) |
DE (1) | DE69624579T2 (de) |
WO (1) | WO1997010547A1 (de) |
Families Citing this family (63)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6041362A (en) * | 1995-10-20 | 2000-03-21 | Electronics Data Systems Corporation | Method and system for integrating disparate information technology applications and platforms across an enterprise |
AT1751U1 (de) | 1996-09-30 | 1997-10-27 | Kuehn Eva | Koordinations-system |
US6496870B1 (en) * | 1997-01-31 | 2002-12-17 | Sun Microsystems, Inc. | System, method and article of manufacture for collaboration with an application |
US6742050B1 (en) | 1997-03-31 | 2004-05-25 | Intel Corporation | Inter-object messaging |
US7490169B1 (en) | 1997-03-31 | 2009-02-10 | West Corporation | Providing a presentation on a network having a plurality of synchronized media types |
US6134597A (en) * | 1997-05-28 | 2000-10-17 | International Business Machines Corporation | CRC hash compressed server object identifier |
JP3490256B2 (ja) | 1997-06-12 | 2004-01-26 | 三菱電機株式会社 | エージェント方式 |
US7082553B1 (en) * | 1997-08-25 | 2006-07-25 | At&T Corp. | Method and system for providing reliability and availability in a distributed component object model (DCOM) object oriented system |
US6779030B1 (en) * | 1997-10-06 | 2004-08-17 | Worldcom, Inc. | Intelligent network |
US7024450B1 (en) * | 1997-10-06 | 2006-04-04 | Mci, Inc. | Method and apparatus for deploying service modules among service nodes distributed in an intelligent network |
US6425005B1 (en) * | 1997-10-06 | 2002-07-23 | Mci Worldcom, Inc. | Method and apparatus for managing local resources at service nodes in an intelligent network |
US6804711B1 (en) * | 1997-10-06 | 2004-10-12 | Mci, Inc. | Method and apparatus for managing call processing services in an intelligent telecommunication network |
US6594355B1 (en) | 1997-10-06 | 2003-07-15 | Worldcom, Inc. | Method and apparatus for providing real time execution of specific communications services in an intelligent network |
US6018805A (en) * | 1997-12-15 | 2000-01-25 | Recipio | Transparent recovery of distributed-objects using intelligent proxies |
US6516354B2 (en) * | 1997-12-18 | 2003-02-04 | Sun Microsystems, Inc. | Method and apparatus for efficient representation of variable length identifiers in a distributed object system |
US6249803B1 (en) | 1997-12-18 | 2001-06-19 | Sun Microsystems, Inc. | Method and apparatus for executing code during method invocation |
US6405264B1 (en) | 1997-12-18 | 2002-06-11 | Sun Microsystems, Inc. | Marshaling and unmarshaling framework for supporting filters in a distributed object system |
US6510460B1 (en) | 1997-12-18 | 2003-01-21 | Sun Microsystems, Inc. | Method and apparatus for enforcing locking invariants in multi-threaded systems |
US6397252B1 (en) * | 1997-12-19 | 2002-05-28 | Electronic Data Systems Corporation | Method and system for load balancing in a distributed object system |
US6061729A (en) * | 1997-12-31 | 2000-05-09 | Alcatel Usa Sourcing, L.P. | Method and system for communicating service information in an advanced intelligent network |
US6314172B1 (en) * | 1997-12-31 | 2001-11-06 | Alcatel Usa Sourcing L.P. | Method and system for providing service information in an advanced intelligent network |
US6038301A (en) * | 1997-12-31 | 2000-03-14 | Alcatel Usa Sourcing, L.P. | Method and system for engineering a service in an advanced intelligent network |
US5963947A (en) * | 1998-01-27 | 1999-10-05 | International Business Machines Corporation | Technique of dynamically adding functionality from a client to manipulated data at a server |
US6862736B2 (en) | 1998-02-06 | 2005-03-01 | Microsoft Corporation | Object manager for common information model |
US6247017B1 (en) * | 1998-03-20 | 2001-06-12 | Sun Microsystems, Inc. | Server-client communication over a network |
US6170014B1 (en) * | 1998-03-25 | 2001-01-02 | Community Learning And Information Network | Computer architecture for managing courseware in a shared use operating environment |
US6788649B1 (en) | 1998-08-03 | 2004-09-07 | Mci, Inc. | Method and apparatus for supporting ATM services in an intelligent network |
US6862733B1 (en) * | 1998-11-19 | 2005-03-01 | Unisys Corporation | Generic method for programmatically locating and executing any application |
KR100309803B1 (ko) * | 1998-12-26 | 2001-12-17 | 서평원 | 망관리시스템과관리대상장비간의데이터베이스동기화장치및방법 |
US7062454B1 (en) | 1999-05-06 | 2006-06-13 | Jarbridge, Inc. | Previewing system and method |
US6578068B1 (en) | 1999-08-31 | 2003-06-10 | Accenture Llp | Load balancer in environment services patterns |
US7181539B1 (en) * | 1999-09-01 | 2007-02-20 | Microsoft Corporation | System and method for data synchronization |
US7418407B2 (en) * | 1999-10-14 | 2008-08-26 | Jarbridge, Inc. | Method for electronic gifting using merging images |
US7917397B1 (en) | 1999-10-14 | 2011-03-29 | Jarbridge, Inc. | Merging private images for gifting |
US6903756B1 (en) | 1999-10-14 | 2005-06-07 | Jarbridge, Inc. | Merged images viewed via a virtual storage closet |
US20040168174A1 (en) * | 2000-03-08 | 2004-08-26 | Baker Tyler Foley | System for object cloing and state synchronization across a network node tree |
US6941510B1 (en) * | 2000-06-06 | 2005-09-06 | Groove Networks, Inc. | Method and apparatus for efficient management of XML documents |
EP1202172A1 (de) * | 2000-10-31 | 2002-05-02 | Universiteit Gent | Sofortige topologische Klassifizierung von Objekten nach einem globalen Satz und einem lokalen Satz |
US7203755B2 (en) * | 2000-12-29 | 2007-04-10 | Webex—Communications, Inc. | System and method for application sharing in collaborative setting |
WO2002054264A1 (en) | 2000-12-29 | 2002-07-11 | Webex Communications, Inc. | Distributed network system architecture for collaborative computing |
US20030167418A1 (en) | 2000-12-29 | 2003-09-04 | Min Zhu | Fault-tolerant server for collaborative computing |
US6901448B2 (en) * | 2000-12-29 | 2005-05-31 | Webex Communications, Inc. | Secure communications system for collaborative computing |
US6925645B2 (en) | 2000-12-29 | 2005-08-02 | Webex Communications, Inc. | Fault tolerant server architecture for collaborative computing |
US20030164853A1 (en) * | 2000-12-29 | 2003-09-04 | Min Zhu | Distributed document sharing |
US6567813B1 (en) | 2000-12-29 | 2003-05-20 | Webex Communications, Inc. | Quality of service maintenance for distributed collaborative computing |
US7069298B2 (en) | 2000-12-29 | 2006-06-27 | Webex Communications, Inc. | Fault-tolerant distributed system for collaborative computing |
US6744753B2 (en) * | 2001-11-01 | 2004-06-01 | Nokia Corporation | Local service handover |
US7340214B1 (en) | 2002-02-13 | 2008-03-04 | Nokia Corporation | Short-range wireless system and method for multimedia tags |
US7636754B2 (en) * | 2002-03-21 | 2009-12-22 | Cisco Technology, Inc. | Rich multi-media format for use in a collaborative computing system |
FI117153B (fi) * | 2002-04-19 | 2006-06-30 | Nokia Corp | Laajennettu nimipalvelukehys |
KR100462886B1 (ko) * | 2002-10-15 | 2004-12-17 | 삼성전자주식회사 | 부하 분담 구조와 프라이머리/백업 구조가 혼합된 시스템 |
US7269623B2 (en) * | 2003-01-09 | 2007-09-11 | Raytheon Company | System and method for distributed multimodal collaboration using a tuple-space |
US8745124B2 (en) * | 2005-10-31 | 2014-06-03 | Ca, Inc. | Extensible power control for an autonomically controlled distributed computing system |
US20070127438A1 (en) * | 2005-12-01 | 2007-06-07 | Scott Newman | Method and system for processing telephone technical support |
US7606937B2 (en) * | 2005-12-02 | 2009-10-20 | Microsoft Corporation | Next site for distributed service connections |
US20080046966A1 (en) * | 2006-08-03 | 2008-02-21 | Richard Chuck Rhoades | Methods and apparatus to process network messages |
US8212805B1 (en) | 2007-01-05 | 2012-07-03 | Kenneth Banschick | System and method for parametric display of modular aesthetic designs |
US8856344B2 (en) | 2009-08-18 | 2014-10-07 | Verisign, Inc. | Method and system for intelligent many-to-many service routing over EPP |
US8327019B2 (en) * | 2009-08-18 | 2012-12-04 | Verisign, Inc. | Method and system for intelligent routing of requests over EPP |
WO2019142337A1 (ja) * | 2018-01-19 | 2019-07-25 | 三菱電機株式会社 | 通信制御装置、通信制御方法および通信制御プログラム |
US11196737B2 (en) | 2019-04-30 | 2021-12-07 | Bank Of America Corporation | System for secondary authentication via contactless distribution of dynamic resources |
US10998937B2 (en) | 2019-04-30 | 2021-05-04 | Bank Of America Corporation | Embedded tag for resource distribution |
US11234235B2 (en) | 2019-04-30 | 2022-01-25 | Bank Of America Corporation | Resource distribution hub generation on a mobile device |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5551035A (en) * | 1989-06-30 | 1996-08-27 | Lucent Technologies Inc. | Method and apparatus for inter-object communication in an object-oriented program controlled system |
EP0953900A3 (de) * | 1989-07-21 | 2000-05-24 | Hewlett-Packard Company | Objektbasierte Systeme |
US5301319A (en) * | 1989-09-15 | 1994-04-05 | Emtek Health Care Systems, Inc. | Data storage audit trail |
DE69126223T2 (de) * | 1990-02-14 | 1997-09-18 | Fujitsu Ltd | System zur Erstellung eines Übertragungsweges in einem eng gekoppelten Rechnersystem |
DE69130197T2 (de) * | 1990-03-05 | 1999-02-11 | Fujitsu Ltd., Kawasaki, Kanagawa | Datenverarbeitungssystem zur nachrichtenübertragung |
EP0459912B1 (de) * | 1990-05-30 | 1996-09-11 | Fujitsu Limited | Verarbeitungssystem zur Ausgabe vom Verwendungsrecht vom Betriebsmittel |
AU639802B2 (en) * | 1990-08-14 | 1993-08-05 | Oracle International Corporation | Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment |
DE69131094T2 (de) * | 1991-01-31 | 1999-07-29 | Hewlett Packard Co | Konferenzsystem |
US5303375A (en) * | 1991-04-26 | 1994-04-12 | Hewlett-Packard Company | System and method for facilitating selection of running functional process in object-oriented environments |
FR2679350B1 (fr) * | 1991-07-16 | 1995-06-23 | Cit Alcatel | Structure de logiciel pour systeme de traitement de donnees, notamment pour systeme de telecommunications. |
GB2263797B (en) * | 1992-01-31 | 1996-04-03 | Plessey Telecomm | Object orientated system |
US5287507A (en) * | 1992-03-27 | 1994-02-15 | Sun Microsystems, Inc. | Method and apparatus for portable object handles that use local caches |
US5307490A (en) * | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
US5396630A (en) * | 1992-10-06 | 1995-03-07 | International Business Machines Corporation | Method and system for object management across process boundries in a data processing system |
US5377350A (en) * | 1993-04-30 | 1994-12-27 | International Business Machines Corporation | System for cooperative communication between local object managers to provide verification for the performance of remote calls by object messages |
US5522077A (en) * | 1994-05-19 | 1996-05-28 | Ontos, Inc. | Object oriented network system for allocating ranges of globally unique object identifiers from a server process to client processes which release unused identifiers |
-
1995
- 1995-09-12 US US08/526,953 patent/US5892946A/en not_active Expired - Fee Related
-
1996
- 1996-09-11 JP JP51215197A patent/JP3846736B2/ja not_active Expired - Fee Related
- 1996-09-11 CA CA002231684A patent/CA2231684A1/en not_active Abandoned
- 1996-09-11 EP EP96930881A patent/EP0850447B1/de not_active Expired - Lifetime
- 1996-09-11 WO PCT/US1996/014755 patent/WO1997010547A1/en active IP Right Grant
- 1996-09-11 DE DE69624579T patent/DE69624579T2/de not_active Expired - Lifetime
- 1996-09-11 AU AU69781/96A patent/AU6978196A/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
AU6978196A (en) | 1997-04-01 |
WO1997010547A1 (en) | 1997-03-20 |
JP2000500255A (ja) | 2000-01-11 |
EP0850447B1 (de) | 2002-10-30 |
JP3846736B2 (ja) | 2006-11-15 |
DE69624579D1 (de) | 2002-12-05 |
US5892946A (en) | 1999-04-06 |
EP0850447A1 (de) | 1998-07-01 |
CA2231684A1 (en) | 1997-03-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69624579T2 (de) | System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten | |
DE69723612T2 (de) | Datenbanknetzwerk | |
EP0825524B1 (de) | Verfahren zur Verwaltung der Benennung von Objekten | |
DE69916928T2 (de) | Zugriffsverfahren und Server für Netzwerkverzeichnis | |
DE69902804T2 (de) | Anwendungsunabhängiges nachrichtensystem | |
DE69122830T2 (de) | Verteiltes Konfigurationsprofil für ein Rechnersystem | |
DE69719620T2 (de) | Vorrichtung und Verfahren zur Bestimmung von Server-Cluster-Topologien | |
DE68918765T2 (de) | Verfahren zur wirksamen Aktualisierung der Knotentopologiedatenbanken in einem Datenkommunikationsnetzwerk. | |
DE69534411T2 (de) | Offenes Transaktionverwaltungszugriffsystem und Verfahren | |
DE3854909T2 (de) | Cacheverwaltungsverfahren und System in einem anteilig genutzten Dateisystem | |
DE68927508T2 (de) | Zeitweilige Zustandsbewahrung für einen verteilten Dateidienst | |
DE60103088T2 (de) | Verfahren zur Herstellung von Weiterleitungslisten für Netzwerkgruppe | |
DE69025846T2 (de) | Verfahren zur Verwendung gespeicherter partieller Bäume zur Berechnung eines Weges in einem Datenkommunikationsnetz | |
EP1194865B1 (de) | Verfahren zur datenpflege in einem netzwerk teilweise replizierter datenbanksysteme | |
DE69727438T2 (de) | Zwischenspeicher-Protokoll für verbesserte Webleistung | |
DE69032191T2 (de) | Anordnung und Verfahren zur Realisierung von Hochleistungskommunikation zwischen Softwareprozessen | |
DE69628631T2 (de) | Dateneingangs/-ausgangsvorrichtung durch Referenzierung zwischen zentralen Verarbeitungseinheiten und Ein-/Ausgabevorrichtungen | |
DE69521839T2 (de) | Datenbanksystem | |
DE69533838T2 (de) | Verfahren und System zur Aktualisierung der nachgebildeten Datenbanken in Fernsprechnetzen | |
DE3689990T2 (de) | Flexible Datenübertragung für nachrichtenorientierte Protokolle. | |
DE69228621T2 (de) | Objektorientiertes verteiltes Rechnersystem | |
DE69838739T2 (de) | Verfahren und Vorrichtung zum Darstellen und Verwenden von Netzwerktopologiedaten | |
DE69216130T2 (de) | Verfahren und Vorrichtung zur verbesserten Verteilung von elektronischen Mitteilungen | |
DE69331356T2 (de) | Kontrolleinrichtung für Migrationskommunikation | |
DE60204031T2 (de) | Hierarchische cachespeicherung in telekommunikationsnetzen |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8327 | Change in the person/name/address of the patent owner |
Owner name: ALCATEL, PARIS, FR |
|
8327 | Change in the person/name/address of the patent owner |
Owner name: NAXOS DATA LLC, LAS VEGAS, NEV., US |