DE69822283T2

DE69822283T2 - Verteilte dauerhafte Speicher für Benutzer- Anbieter- Systeme mit manchmal unterbrochenen Verbindungen

Info

Publication number: DE69822283T2
Application number: DE69822283T
Authority: DE
Inventors: Ken Yat-Wan Chan; Eric W. Parsons; A. Julian Craddock
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 1997-12-24
Filing date: 1998-11-16
Publication date: 2004-07-29
Anticipated expiration: 2018-11-17
Also published as: DE69822283D1; EP0926608A3; EP0926608A2; EP0926608B1

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf Verfahren zur Aufrechterhaltung einer gegenseitigen Konsistenz zwischen Kopien von Daten, die an Knoten in einem Netzwerk gespeichert sind, auf Verfahren zur Durchführung einer Operation an Daten, die in einem Netzwerk von Knoten gespeichert sind, auf Klienten-Knoten und auf Software für derartige Verfahren.
Stand der Technik
Es ist bekannt, für Benutzer einen Zugang zu Datenbanken von Endgeräten an geografisch entfernten Stellen aus bereitzustellen, indem Anforderungen weitergeleitet und Daten über mehrfache Netzwerke zurückgeliefert werden. Verzögerungen und Netzwerk-Überlastungen können jedoch entstehen, wenn große Mengen von Daten zurückgeliefert werden, oder wenn die Charakteristiken der Netzwerke oder die Verbindungsstrecken zwischen den Netzwerken nicht alle geeignet sind, beispielsweise hinsichtlich der Bandbreite, der Latenz oder der Abwicklung von stark asymmetrischen Verkehrslasten. Es gibt verschiedene bekannte Möglichkeiten zur Berücksichtigung der Probleme, die mit der Bereitstellung eines schnellen Zuganges an die Daten in derartigen Datenbanken verbunden sind. Die Verteilung der Datenbanken über geografisch getrennte Server stellt eine Lösung dar.
Es ist gut bekannt, derartige verteilte Datenbanken entweder durch Aufteilen des Inhaltes oder durch Replizieren oder Kopieren an den verschiedenen Stellen zu schaffen. Das Kopieren oder die Replikation kann für den Benutzer oder die Anwendung transparent sein, was bedeutet, dass Software zur Schnittstellenverbindung der Anwendung/des Benutzers mit den mehrfachen Kopien vorgesehen ist, wodurch die zwei oder mehr Kopien ohne Eingriff des Benutzers aktuell gehalten werden. Für die Benutzer/die Anwendung wird der Eindruck erweckt, als ob dies lediglich eine Kopie ist.
Die Verteilung kann vorstrukturiert sein oder dynamisch sein. Ein Beispiel des letzteren ist die örtliche Pufferungsfähigkeit einiger Datenbanken, was es ihnen ermöglicht, Daten, auf die ein Zugriff von einem Benutzer ausgeführt wurde, in einem Puffer in der Nähe des Benutzers zu halten. Beispielsweise ist es bei objektorientierten Datenbanken bekannt, örtliche Objekt-Puffer vorzusehen. Dies kann die Betriebsleistung und die Skalierbarkeit verbessern. Um eine Konsistenz oder Übereinstimmung zwischen den ursprünglichen und den gepufferten oder replizierten Versionen aufrechtzuerhalten, ist es bekannt, einen Replikationsprozess über eine dauernde Verbindung bereitzustellen. Wenn die Verbindung jedoch über irgendeine Zeitdauer unterbrochen wird, ist kein Mechanismus vorgesehen, um Daten, die inkonsistent wurden, neu zu synchronisieren.
Beispielsweise kann ein Objekt auf eine neue Maschine wandern, um die Last zwischen Maschinen auszugleichen oder weil sein ursprünglicher Prozessor ausgefallen ist; in diesem Fall würde die Netzwerkadresse, die von einem Namensdienst für das Objekt geführt wird, aktualisiert werden, um dessen neue Position wiederzugeben. Weil die von Speicherservern geführten Daten häufig einer Änderung unterworfen sind, sollte eine Prüfung, dass an Klienten zurückgelieferte gepufferte Daten immer gültig sind, in der Verantwortlichkeit entweder von Speicherservern oder Pufferverwaltungen liegen. Eine vom Server eingeleitete Pufferkonsistenz erfordert es, dass die Datenserver die Puffer immer dann informieren, wenn Daten aktualisiert werden. Eine vom Klienten initiierte Pufferkonsistenz erfordert, dass Puffer-Verwaltungen gepufferte Daten mit Speicherservern validieren, bevor sie sie an die Klienten zurückliefern. Insbesondere für sehr große Internet-Umgebungen sind beide Lösungen aufwändig und nicht sehr attraktiv, weil sie eine aufwändige Zusammenarbeit zwischen Servern und Pufferverwaltungen beinhalten. Es ist bekannt, Techniken, die z. B. Aktualisierungs-Zeitstempel verwenden, um eine Prüfung der Gültigkeit der Daten in Pufferspeichern zu ermöglichen, ohne dass diese zurückgewonnen und verglichen werden, und ohne dass Aufzeichnungen von Änderungen geführt werden.
Dennoch ist auf dem Gebiet der verteilten dauerhaften Speicherung (was eine Speicherung bedeutet, die über die Beendigung einer Anwendung hinaus überlebt, auf die sie sich bezieht) die Datenreplikation gegenüber Alternativen vorzuziehen, wie Aufteilung und Bewegen von Teilen einer Datenbank oder Senden von Anfragen und Zurückliefern von Daten über umfangreiche Netzwerke. Dies kann die Probleme der Fehlertoleranz, der hohen Verfügbarkeit und der Konsistenz von Daten berücksichtigen. Weil die meisten Daten weniger als 2% an einem vorgegebenen Tag geändert werden, erfordert der Prozess der Verwaltung von Datenänderungen typischerweise wesentlich weniger Computer- und Netzwerk-Ressourcen, als die Datenextraktion und System-Querabfragen. Somit ist die Datenreplikation eine neue Datenbewegungstechnologie, die einen effizienten asymmetrischen bidirektionalen Datenzugriff über mehrfache Systeme berücksichtigt.
Systeme zur Synchronisierung der unterschiedlichen Versionen von Daten (was bedeutet, dass die Kopien von Daten gegenseitig konsistent gemacht werden) wurden für nicht mobile verdrahtete Netzwerke entwickelt. Diese Systeme, die intermittierende Verbindungen berücksichtigen, beispielsweise nächtliche Aktualisierungen, zeichnen Transaktionen auf und geben sie wieder, wenn die Verbindung hergestellt wird. Für Klienten-Serversysteme bestimmt der Server, welche Änderungen an der Server-Kopie gemacht werden müssen. Systeme für drahtgebundene Netzwerke sind nicht notwendigerweise für ortsbewegliche drahtlos verbundene Benutzer geeignet, und zwar aufgrund der unterschiedlichen physikalischen Zwangsbedingungen, die entstehen. Derartige Zwangsbedingungen schließen eine häufige Verbindung und Trennung der Verbindung, hohe Übertragungskosten und geringe Bandbreiten für drahtlose Verbindungsstrecken, eine hohe Latenz und beschränkte Rechenressourcen und eine begrenzte Batterie-Lebensdauer ein.
Ein bekanntes System für ortsbewegliche drahtlose Benutzer wird Gold Rush genannt und ist eine mit dauerhafter Speicherung arbeitende Klienten/Server-Architektur, die hauptsächlich von dem Thomas J. Watson Research Center bei IBM entwickelt wurde. Wie dies in ihrer USENIX-Veröffentlichung beschrieben ist (Conference on Object Oriented Technology and Systems, 16.–20. Juni 1997) ist Gold Rush eine Middleware (was bedeutet, dass dies eine Schnittstellen-Software zur Umwandlung zwischen anderer Software und anderen Protokollen ist), die das Schreiben von JAVA-Anwendungen unterstützt, die sich auf einem intermittierend verbundenen mobilen Klienten-Gerät befinden und einen Zugriff auf eine Firmendatenbank auf einen zentralen Server ausführen. Während der Klient mit dem zentralen Server verbunden ist, können aus Datenbank-Einheiten konstruierte Objekte in einen dauerhaften Speicher auf der Klienten-Seite gepuffert werden. Während die Verbindung des Klienten getrennt ist, können diese Einheiten in Transaktionen manipuliert werden, die auf dem Klienten protokolliert werden. Bei einer erneuten Verbindung kann die Klienten-Anwendung diese protokollierten Transaktionen zu dem Server zurückspielen, wodurch die Datenbank modifiziert wird. Eine zurückgespielte Transaktion wird auf Konflikte mit anderen Datenbank-Aktualisierungen geprüft, die aufgetreten sind, seit der Klient die Eingangsdaten für die Transaktion gewonnen hat, und der Klient wird informiert, wenn ein derartiger Konflikt entsteht. Die Kommunikation zwischen dem Klienten und dem Server ist optimiert, um die Verwendung einer langsamen oder teuren Verbindung wirtschaftlich zu machen, wie z. B. einer Funkverbindungsstrecke.
Diese bekannte System bietet eine Transaktionszusammenführung und eine Konfliktauflösung zwischen dem Klienten und dem Server. Bezogen auf die veröffentlichten Einzelheiten scheint sie die Transaktions-Semantik ziemlich gut aufrechtzuerhalten. Sie bietet ein gutes Klienten- und Server-Rahmenwerk für eine dauerhafte Speicherung. Alle Transaktionen der mobilen Klienten werden bei einer erneuten Verbindung zu dem Server zurückgespielt. Dies ist eine typische Daten-Resynchronisations-Strategie.
Selbst bei dieser Lösung verbleibt eine Anzahl von Problemen. Zunächst kann das Führen der Transaktionsprotokolle und das Zurückspielen des Protokolls bei einer erneuten Verbindung zurück an den Server zu lange dauern. Insbesondere für „Thin Clients" oder „dünne" Klienten, was bedeutet, dass diese Klienten beschränkte Rechenressourcen haben, beispielsweise hinsichtlich Speicher und Verarbeitungsleistung, und über eine langsame Verbindungsstrecke verbunden sind oder nur in der Lage sind, mit dem Server für eine sehr kurze Zeitperiode verbunden zu werden, würde das Ergebnis darin bestehen, dass der mobile Klient immer mit dem Server unsynchronisiert ist.
Ein zweites Problem ergibt sich daraus, dass dieses System auf dem Klienten/Server-Modell beruht. Der Server führt den größten Teil der Verarbeitung und Steuerung aus und kommuniziert direkt mit allen Klienten. Somit ist die Anzahl der Klienten, die versorgt werden können, durch die Verarbeitungs- und Kommunikationsmöglichkeiten des Servers beschränkt.
Ein drittes Problem ergibt sich daraus, dass die Replikation relativ grobkörnig ist und auf der Speicherungs-/Datenbank-Ebene erfolgt. Insbesondere dann, wenn sich Beschränkungen hinsichtlich der Speichermöglichkeiten oder der Übertragungsbandbreite zu dem Klienten ergeben, können, sich unannehmbare Verzögerungen ergeben oder der Klient kann unfähig sein, die Replikation abzuwickeln.
Die EP-0 794 646 A und die Veröffentlichung von Hild, S. g. et al „Mobilising Applications", IEEE Personal Communications, US, IEEE Comms Society, Band 4, Nr. 5, 1. Oktober 1997, Seiten 26–34, XP000721303 ISSN: 1070-9916 offenbaren weitere Beispiele von bekannten Verfahren.
Zusammenfassung der Erfindung
Es ist ein Ziel der vorliegenden Erfindung, verbesserte Verfahren und Vorrichtungen zu schaffen.
Gemäß einem Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren zur Aufrechterhaltung einer gegenseitigen Konsistenz oder Übereinstimmung zwischen Kopien von Daten, die an Knoten in einem Netzwerk gespeichert sind, geschaffen, wobei die Knoten einen Server-Knoten und eine Anzahl von Klienten-Knoten an entfernt angeordneten Stellen umfassen, wobei die Knoten intermittierend verbunden werden und die Klienten-Knoten Anwendungen aufweisen, die die Daten verwenden, wobei das Verfahren die folgenden Schritte an einem entfernt angeordneten der Klienten-Knoten umfasst:
nach der Wiederherstellung einer Verbindung zwischen dem entfernt angeordneten Klienten-Knoten und einem anderen der Knoten, Empfangen von Informationen von diesem anderen Knoten, die sich auf einen Teil der Daten beziehen, von denen eine örtliche Kopie an dem anderen Knoten und eine entfernt angeordnete Kopie an dem entfernt angeordneten Klienten-Knoten vorliegt, wobei die Informationen zeigen, wie aktuell die örtliche Kopie ist;
Vergleichen, an dem entfernt angeordneten Klienten-Knoten, der Informationen, die sich auf die entfernt angeordnete Kopie beziehen, mit entsprechenden Informationen, die sich auf die örtliche Kopie beziehen, um festzustellen, ob die entfernt angeordnete Kopie aktueller als die örtliche Kopie ist, und
Aktualisieren der entfernt angeordneten Kopie auf der Grundlage der örtlichen Kopie oder Ermöglichen, dass der andere Knoten die örtliche Kopie aktualisiert, entsprechend dem Ergebnis des Vergleichs.
Einer der Vorteile, der sich aus der Durchführung des Vergleichs an den Klienten ergibt, besteht darin, dass der Server den Prozess nicht überwachen und steuern muss, so dass das System einfacher aufwärts skaliert werden kann, um mehr Klienten zu behandeln. Ein Vorteil, der sich aus der Synchronisierung auf der Grundlage des Verwerfens von weniger kürzlich aktualisierten Kopien ergibt, besteht darin, dass dies bedeutet, dass das Speichern von Transaktionsaufzeichnungen und deren Zurückspielen wahlweise wird und fortgelassen werden kann, falls passend. Dies ist in Kombination mit den anderen Merkmalen besonders vorteilhaft für intermittierend verbundene „dünne" entfernt angeordnete Plätze, wie z. B. Palmtop-Geräte mit beschränktem Speicher, die nicht in der Lage sein könnten, Transaktionen, die über eine lange Periode einer fehlenden Verbindung gesammelt wurden, zu speichern und zurückzuspielen. Diese Strategie ermöglicht weiterhin die Verteilung der Verarbeitungslast auf die Server und Klienten in einer gleichförmigeren Weise und ergibt eine größere Autonomie für die Klienten.
Vorzugsweise umfasst das Verfahren weiterhin den Schritt der Feststellung, ob der Inhalt der entfernt angeordneten Kopie der gleiche ist, wie der Inhalt der örtlichen Kopie, und die Einleitung eines Konfliktauflösungsprozesses an dem entfernt angeordneten Knoten in dem Fall, dass der Vergleich keinen Unterschied zwischen der örtlichen Kopie und der entfernt angeordneten Kopie erkennen lässt, dass sich jedoch die jeweiligen Inhalte unterscheiden. Wenn der Zeitstempel oder die Versionen der Kopien gleich sind, die Kopien jedoch unterschiedlich sind, so kann der Klient eine geeignete Konfliktauflösungsstrategie einleiten, beispielsweise den Benutzer zu einer Auswahl auffordern, statt dass der Server die Entscheidung trifft. Die Einleitung dieses Prozesses an dem Klienten ermöglicht es weiterhin, die Bearbeitungslast gleichförmiger auf die Server und Klienten aufzuteilen, und dies ergibt eine größere Autonomie für die Klienten.
Vorzugsweise umfasst das Verfahren weiterhin die vorbereitenden Schritte der Aufzeichnung, während einer Trennung der Verbindung, derjenigen Teile, die an dem anderen. Knoten modifiziert wurden, wobei die von dem entfernt angeordneten Klienten-Knoten empfangenen Informationen sich auf die Teile beziehen, die von dem anderen Knoten als modifiziert aufgezeichnet wurden. Ein Vorteil hiervon besteht darin, dass es möglich wird, die Teile, die eine Neusynchronisation erfordern, sehr schnell und einfach zu identifizieren.
Vorzugsweise wird der Vergleichsschritt für jeden der aufgezeichneten Teile, die während der Trennung der Verbindung modifiziert wurden, ausgeführt, bevor der Vergleichsschritt für einen Teil ausgeführt wird, der nachfolgend zu der Verbindungs-Wiederherstellung modifiziert wurde. Einer der Vorteile hiervon besteht darin, dass eine redundante Synchronisation vermieden wird. Bei Wiederherstellung der Verbindung synchronisiert der Klient als erstes Objekte neu, die als „unsauber" oder modifiziert in dem Speicher für „unsaubere" oder modifizierte Objekte markiert wurden. Wenn eine Anwendung eine Aktualisierung eines Objektes während einer Wiederverbindung anfordert, muss das Objekt, das als „unsauber" oder modifiziert markiert ist, zunächst eine erneute Synchronisation mit dem Netzwerk ausführen, bevor die Anwendung die Aktualisierung durchführen kann. Wenn die Anwendung als erstes weiterlaufen könnte, so muss das Objekt mehr als einmal neu synchronisiert werden, weil das Objekt erneut als modifiziert markiert werden würde und der vorhergehende Wert des Objektes verloren gehen würde.
Vorzugsweise umfasst das Verfahren weiterhin den Schritt der Sperrung der entfernt angeordneten Kopie zum Verhindern eines Zugriffs auf diese während des Vergleichsschrittes. Ein Vorteil hiervon besteht darin, dass dies eine Unteilbarkeit sicherstellen und eine Rekursion verhindern kann. Das Nachschlagen von modifizierten Objekten, Versionsvergleiche, Objektaktualisierungen und Synchronisationszuständen der Objekte, die von dem Modifikationsspeicher nachverfolgt werden, sind untrennbar oder im Betrieb synchronisiert. Dies bedeutet, dass das an einer Synchronisations-Transaktion beteiligte Objekt exklusiv gesperrt wird. Dies verhindert, dass der Zustand der Synchronisation inkonsistent wird, wodurch irgendeine mögliche rekursive Synchronisation vermieden wird. Die Untrennbarkeit oder Atomizität bedeutet in allgemeinen Worten, dass eine Gruppe von miteinander in Wechselbeziehung stehenden Operationen sich darauf verlassen kann, dass die Daten der jeweils anderen konsistent sind, ohne dass eine Störung von äußeren Operationen erfolgt. Speziell bedeutet dies, dass der Vergleichsausgang nicht ungültig gemacht wird, bevor er durch eine Änderung in einer der verglichenen Kopien ausgegeben wird.
Vorzugsweise umfasst das Verfahren den vorbereitenden Schritt der Feststellung, ob die entfernte Kopie zu verwenden ist, in Abhängigkeit davon, ob die sich auf die entfernte Kopie beziehende Informationen an dem ersten der Klienten empfangen wurden. Ein Vorteil hiervon besteht darin, dass die Verfügbarkeit von Daten verbessert werden kann, was von besonderer Bedeutung ist, wenn Verbindungen nur kurz oder wenig häufig sind. Das Gierig-Bit oder die Gierig-Flagge kann eingeschaltet werden, um zu erzwingen, dass die aktuelle Synchronisationssitzung immer die letzte Kopie von modifizierten Objekten erhält. Wenn sie abgeschaltet ist, kann die Anwendung wählen, die örtliche Kopie zu verwenden, obwohl der Klient die Verbindung mit dem Netzwerk wieder hergestellt hat. Dies ergibt eine Flexibilität für Anwendungen, die eine Konsistenz zu Gunsten eines schnellen Nachschlagens des Objektes opfern wollen.
Vorzugsweise umfassen die an den Knoten gespeicherten Kopien von Daten eine Kopie von weniger als allen Elementen einer Datenbank, und die Daten umfassen objektorientierte Daten. Ein Vorteil hiervon besteht darin, dass es dies ermöglicht, dass die Menge an Daten, die an der entfernt angeordneten Stelle gespeichert sind, begrenzt wird, was wiederum für intermittierend verbundene „dünne" entfernte Plätze, wie z. B. Palmtop-Geräte mit beschränkter Speicherkapazität vorteilhaft ist. Ein Vorteil der Anwendung des Verfahrens auf objektorientierte Daten besteht darin, dass viele Daten, auf die mobile Benutzer einen Fernzugriff ausführen wollen, bereits in dieser Form vorliegen.
Vorzugsweise umfasst das Verfahren weiterhin den Schritt der Weiterleitung der aktuelleren Kopie von dem entfernten Klienten-Knoten an einen zweiten anderen Knoten, der ebenfalls eine Kopie des Teils der Daten hat, wenn eine Verbindung mit dem zweiten anderen Knoten hergestellt wird. Ein Vorteil dieses Peer-zu-Peer-Modells (Verbindung zwischengleichrangigen Knoten), das sich daraus ergibt, dass die Synchronisation zwischen benachbarten Stellen weitergeleitet wird, besteht darin, dass eine derartige verteilte Lösung einen alternativen Pfad für eine direkte Verbindung zu dem Server ergibt und bedeutet, dass der Server nicht alle Kopien von Objekten über das Netzwerk verfolgen muss. Dies ermöglicht es weiterhin, dass das System einfacher skaliert werden kann, um mehr Klienten, mehr Daten oder eine größere Funktionalität abzuwickeln.
Vorzugsweise umfasst der andere Knoten den Server-Knoten. Es ergibt sich ein Vorteil, wenn der Server direkt verbunden ist, weil angenommen wird, dass der Server eine Kopie jedes Teils der Daten hält, so dass immer eine Kopie vorhanden ist, mit der ein Vergleich durchgeführt werden kann. Dies ist nicht notwendigerweise bei anderen Klienten-Knoten der Fall. Weil weiterhin mit größerer Wahrscheinlichkeit mehr Zugriffsanforderungen an den Server erfolgen, als an irgendeinen der Klienten, ist es wichtiger, dass der Server aktuell gehalten wird, statt irgendeiner der Klienten.
Vorzugsweise umfasst das Verfahren weiterhin die Schritte der Speicherung einer Aufzeichnung von Transaktionen, die die entfernt angeordnete Kopie betreffen, an dem entfernten Klienten-Knoten vor dem Vergleichsschritt, und Beheben zumindest einiger der Transaktionen in dem Fall, dass in dem Vergleichsschritt festgestellt wird, dass die örtliche Kopie aktueller als die entfernt angeordnete Kopie ist. Dies kann die schädlichen Auswirkungen einer Dateninkonsistenz verringern und kann die Belastung von Anwendungen verringern oder die Zuverlässigkeit vergrößern oder eine Lockerung der Synchronisationsanforderungen ermöglichen.
Gemäß einem weiteren Gesichtspunkt der Erfindung wird ein Verfahren zur Durchführung einer Operation an Daten geschaffen, die in einem Netzwerk von Knoten gespeichert sind, wobei einer der Knoten einen Server bildet, während andere der Knoten Klienten-Knoten sind, wobei die Knoten intermittierend verbunden sind, und wobei zumindest einige der Daten an einem entfernt angeordneten der Klienten-Knoten gepuffert werden, wobei das Verfahren die folgenden Schritte umfasst:
Einleiten der Operation an dem entfernt angeordneten Klienten;
Hervorrufen einer Neusynchronisation der gepufferten Daten, wobei die Neusynchronisation die folgenden Schritte umfasst:

a) Hervorrufen einer erneuten Verbindung mit einem anderen der Knoten;
b) Empfangen von Informationen von diesem anderen Knoten, die sich auf einen Teil der gepufferten Daten beziehen, von denen es eine örtliche Kopie an dem anderen Klienten und eine entfernt angeordnete Kopie an dem entfernt angeordneten Klienten-Knoten gibt, wobei die Information zeigt, wie aktuell die örtliche Kopie ist;
c) Vergleichen der sich auf die entfernt angeordnete Kopie beziehenden Informationen an dem entfernt angeordneten Klienten-Knoten mit entsprechenden Informationen, die sich auf die örtliche Kopie beziehen, um festzustellen, ob die entfernt angeordnete Kopie aktueller als die örtliche Kopie ist; und
d) Aktualisieren der entfernt angeordneten Kopie auf der Grundlage der örtlichen Kopie entsprechend dem Ergebnis des Vergleichs; und

Entsprechend einem weiteren Gesichtspunkt der Erfindung wird ein Klienten-Knoten bereitgestellt, der zur Verwendung der vorstehenden Verfahren ausgebildet ist.
Gemäß einem weiteren Gesichtspunkt der Erfindung wird Software auf einem computerlesbaren Medium zur Durchführung der vorstehenden Verfahren bereitgestellt.
Es ist wichtig, festzustellen, dass die vorstehend beschriebene Architektur besonders für ultra-dünne Klienten geeignet ist, die es sich nicht leisten können, zusätzliche Transaktionsprotokolle zu speichern und die Protokolle an den Server zurückzuspielen. Sie folgt einem verteilten Modell und ist damit besser skalierbar als bekannte Rahmenwerke. Weiterhin kann, wenn die Replikations-Körnigkeit sich auf der Wurzelobjekt-Ebene befindet, eine an einer entfernten Stelle angeordnete Datenbank A Kopien von Objekten X und Y haben, während eine Datenbank B Kopien von Objekten Y und Z haben kann, so dass sich eine stärkere Skalierbarkeit ergibt. Die Architektur kann verknüpfungssicher sein, und wenn sie auf irgendeiner OODBM aufgebaut ist, wie dies bevorzugt wird, so unterstützt sie den mehrfachen gleichzeitigen Zugriff von Anwendungen auf die Datenbank. Durch Realisieren der Architektur in Middleware ist es unabhängig von der Datenbank möglich, sie für die Verwendung mit irgendeiner vorhandenen Datenbank anzupassen. Somit wird die Flexibilität und Breite der Anwendung vergrößert.
Irgendwelche der bevorzugten Merkmale können miteinander kombiniert werden und mit irgendeinem Gesichtspunkt der Erfindung kombiniert werden, wie dies für einen Fachmann offensichtlich ist.
Um in Form eines Beispiels zu zeigen, wie die Erfindung in die Praxis umgesetzt wird, werden Ausführungsformen nunmehr ausführlicher unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.
Kurze Beschreibung der Zeichnungen
1 zeigt eine bekannte Anordnung.
2 zeigt einen Überblick über ein Netzwerk, auf dem eine Ausführungsform der Erfindung verwendet werden kann.
3 zeigt Merkmale eines Klienten-Knotens zur Verwendung in dem Netzwerk nach 2.
4 zeigt einen schematischen Überblick über eine verteilte dauerhafte Speicher-(DPS-)Architektur gemäß einer Ausführungsform der Erfindung.
5 zeigt einen weiteren schematischen Überblick über statische Merkmale einer verteilten dauerhaften Speicher-Architektur, die ein Beispiel einer Klienten-Anwendung einschließt, die DPS verwendet.
6 zeigt Merkmale der Dienste-Teilschicht nach 5.
7 zeigt einen schematischen Überblick über Komponenten der DPS-Middleware nach 3.
8 zeigt ein Beispiel von Laufzeit-Aktionen der Anwendung und der DPS-Middleware nach den 3–7.
9 zeigt die Klassenhierarchie einer Klientenanwendung (persönliche Telefonliste), die DPS verwendet.
10 zeigt in weiteren Einzelheiten die Aktionen des entfernt angeordneten Knotens nach 9.
11 zeigt in weiteren Einzelheiten die Aktionen der Verbindungsüberwachung eines entfernt angeordneten Knotens.
12 zeigt ein Ablaufdiagramm für ein DPS-Nachschlage-Objektverfahren.
13 zeigt ein Ablaufdiagramm für ein DPS-Objektänderungsvertahren.
14 zeigt ein Ablaufdiagramm für ein örtliches DPS-Objektänderungsvertahren.
15 zeigt ein Ablaufdiagramm für ein Objekterzeugungs-DPS-Verfahren.
16 zeigt ein Ablaufdiagramm für ein örtliches Objekterzeugungs-DPS-Verfahren.
17 zeigt ein Ablaufdiagramm für ein örtliches Objekt-Lösch-DPS-Verfahren.
18 zeigt ein Ablaufdiagramm für ein DPS-Verfahren zum Löschen aller Objekte.
Ausführliche Beschreibung
1 – Transaktion nach dem Stand der Technik auf der Grundlage des Klient-Server-Verfahrens
1 zeigt eine Erläuterung des bekannten „Gold Rush"-Verfahrens, bei der Klienten-Aktionen auf der linken Seite und Server-Aktionen auf der rechten Seite dargestellt sind. Bei 10 modifiziert, wenn die mobilen Klienten von dem Server getrennt sind, eine Anwendung an dem Klienten Objekte in dem örtlichen Pufferspeicher. Ein Transaktionsprotokoll wird bei 11 geführt, um alle Transaktionen aufzuzeichnen. Wenn eine Verbindung mit dem Server bei 12 hergestellt wird, werden die Transaktionen an den Server zurückgespielt. Während Objekte in dem Server durch die Transaktionen modifiziert oder gelesen werden, werden Zeitstempel der Kopien des Klienten und des Servers im Schritt 13 verglichen, um festzustellen, ob die Server-Kopie in der Zwischenzeit modifiziert wurde. Bei 15 wird die Transaktion akzeptiert, wenn die Server-Objekte unverändert sind, und falls passend, werden die Server-Kopien geändert. Dann wird bei 16 der Klient über die Akzeptierung informiert, und der klientenseitige Pufferspeicher wird entsprechend aktualisiert.
Anderenfalls wird, wenn die Transaktion zurückgewiesen wird, wie bei 17, die Anwendung über die Zurückweisung informiert und kann bei 18 Konfliktauflösungsverfahren starten.
2 – Überblick über ein Netzwerk
2 zeigt in schematischer Form ein Netzwerk, auf das die vorliegende Erfindung angewandt werden kann. Während das bekannte Klient-Server-basierte System immer direkte Verbindungen von dem Server zu jedem Klienten benötigen würde, können bei dieser Ausführungsform der vorliegenden Erfindung Klienten miteinander in Kontakt treten, ohne über den Server zu gehen. Wie dies zu erkennen ist, ist ein Server 20 mit Verbindungsstrecken zu Klienten-Knoten unter Verwendung sowohl fester Verbindungsstrecken als auch intermittierender Verbindungsstrecken, wie z. B. drahtloser Verbindungsstrecken, versehen. Eine Basisstation 40 koppelt die drahtlosen Verbindungsstrecken mit dem Server. Eine Vielzahl von Klienten-Knoten 30 kann mit dem Server verbunden werden, wobei aus Gründen der Klarheit lediglich vier gezeigt sind. Die Klienten-Knoten könnten die Form von Mobiltelefonen oder Laptop-Computern annehmen, die über Mobiltelefone miteinander verbunden sind. Klienten-Knoten können miteinander in Kontakt stehen, entsprechend dem Peer-zu-Peer-Modell, das zumindest für die Datenreplikations- und Neusynchronisationszwecke vorgeschlagen wird. Für andere Zwecke kann das Klienten-Server-Modell traditionelleren Linien folgen.
Ein Beispiel, bei dem Klienten-Knoten intermittierend miteinander verbunden sein können, ergibt sich, wenn ein Palmtop-Computer eine drahtlose Verbindungsstrecke zu einem Laptop-Computer hat. Der Palmtop kann einen Zugriff auf in dem Laptop gespeicherte Objekte ausführen und seine Daten mit denen in dem Laptop synchronisieren. Der Laptop kann eine drahtlose Verbindung zu anderen Laptops und schließlich zu einem entfernt angeordneten Server haben.
Obwohl der Server als eine einzige Einheit gezeigt ist, kann er auch verteilt sein. Auf der Grundlage dieses Peer-zu-Peer-Modells kann eine „n"-läufige Datensynchronisation und Replikation konstruiert werden.
3 – Klienten-Knoten-Überblick
Es ist zu erkennen, dass die in 2 gezeigten Klienten-Knoten 30 zwei Haupt-Softwareschichten haben, wie dies in 3 gezeigt ist. Örtliche Daten 70 können in der Form einer Datenbank gespeichert werden, obwohl auch andere Datenstrukturen in Betracht gezogen werden könnten. Die Anwendungssoftware 50 verwendet die Daten über die Middleware 60. Ein Beispiel einer Anwendung könnte ein Web-Browser sein. Ein weiteres Beispiel, das weiter unten erläutert wird, ist eine Anwendung für den Zugriff und das Führen von Informationen, wie z. B. von Listen von Telefonnummern oder Adressen. Viele andere Anwendungen können in Betracht gezogen werden. Die Middleware wird als verteilter dauerhafter Speichermechanismus bezeichnet. Wie dies funktioniert und wie die Wechselwirkung mit anderen Teilen erfolgt, wird ausführlicher weiter unten erläutert.
4 – Konzeptueller Überblick über eine verteilte dauerhafte Speicher-(DPS-)Architektur
Das konzeptuelle Modell nach 4 zeigt eine „vereinfachte Ansicht" der Funktion des verteilten dauerhaften oder persistenten Speichersystems (DPS), das Anwendungen 51, 59 auf Knoten sowohl auf einer Klienten-Seite als auch einer Server-Seite versorgt. Die Netzwerk-Begrenzung ist dargestellt, um anzuzeigen, dass die Klienten-Seite beweglich ist und von den festen Teilen des Netzwerkes entfernt angeordnet ist. Als Wiedergabe der Peer-zu-Peer-Eigenart des DPS sind die Funktionen des DPS auf dem Server-Knoten und dem Klienten-Knoten im Wesentlichen die gleichen.
Die Klienten-Anwendung 51 sollte den persistenten Speicher 56 als einzige Einheit sehen, obwohl die Datenbank tatsächlich über mehrfache Server 58 hinweg gespeichert ist. In dem nachfolgend beschriebenen Beispiel wird das Klienten/Server-Modell auf der Server-Seite gewählt, das heißt, der Server oder der Heimatstandort speichert immer die Master-Kopie der Klienten oder (wenn der Server ebenfalls verteilt ist) Besucher-Standorte speichern eine Kopie von zumindest einem Teil der Datenbank für eine größere örtliche Zugänglichkeit. Die Anwendung kann Anforderungen an die persistenten Funktionen 53 und die Replikations- oder Kopierfunktionen 55 senden. Jede dieser Funktionen kann Daten an die Anwendung zurückliefern. Die persistenten Funktionen sind in der Lage, grundlegende Operationen wie z. B. das Nachschlagen, das Erzeugen, das Löschen, das Ändern usw. an den in einer persistenten oder dauerhaften Form gespeicherten Daten abwickeln. Derartige Funktionen können die Replikationsfunktionen verwenden, die es ermöglichen, dass die Daten an mehreren Stellen gespeichert werden, um die vorstehend erläuterten Vorteile zu erzielen. Die Replikationsfunktionen dienen zur Aufrechterhaltung der verschiedenen Kopien der Daten in konsistenter Form. Sie verwenden eine Nachschlagetabelle 54 zur Benennung von Diensten. Dies ermöglicht es Benutzern, Diensten und Objekten (wenn objektorientierte Programme und Daten verwendet werden) auf Host- und Port-Identifikationen umgesetzt zu werden. Hosts oder Hauptmaschinen werden als Maschinen definiert, die durch eine IP-Adresse oder einen Namen der Maschine identifiziert sind und auf denen mehrfache Instanzen der DPS als Server oder Klienten oder Peers ablaufen können. Weil jeder DPS-Server oder Klient oder Peer einen TCP-Port für die Datensynchronisation verwendet, kann ein Host so viele DPS-Peers wie die Anzahl von freien TCP-Ports haben.
Wie dies erläutert wurde, erfolgt die Datensynchronisation durch eine Kommunikation zwischen den Replikationsfunktionen 55 von benachbarten Knoten. Wie dies weiter unten ausführlicher beschrieben wird, werden derartige Synchronisationssitzungen von einer Seite eingeleitet, und es kann zwei unabhängige Sitzungen geben.
Funktionelle Konstruktionserwägungen einer Ausführungsform der Erfindung

a) Kleiner Platzbedarf – Der den Datenreplikationsmechanismus unterstützende Code muss einen kleinen Speicherplatzbedarf sowohl in dauerhaft gespeicherten als auch Ausführungs-(RAM-)Formaten haben. Hierdurch wird seine Auswirkung auf die Netzwerk-Server-ROM- und/oder RAM-Anforderungen zu einem Minimum gemacht werden, die aufgrund der dauernd zunehmenden Größe von Software eine dauernde Herausforderung darstellen.
b) Pfad-Sicher – Der Mechanismus muss Pfad-Sicher sein und daher JAVA-Pfade unterstützen. Dies ergibt sich daraus, dass viele JAVA-Applets mehrpfadig sein können und jeder Pfad gleichzeitig Anforderungen an den Datenreplikationsmechanismus senden kann.
c) Minimaler Speicher-Zusatzaufwand – Muss so ausgelegt werden, dass sich ein minimaler Fragmentierungs-Zusatzaufwand pro „repliziertem Datenblock" ergibt. Weiterhin muss der Speicher-Zusatzaufwand, der mit dem Indexierungsschema verbunden ist, das für die Abfrage von replizierten Datenposten verwendet wird, auf einem Minimum gehalten werden.
d) Versionsführung von Daten – Dies muss die Fähigkeit unterstützen, die Version eines vorgegebenen Datenpostens zu unterscheiden, möglicherweise auf der Grundlage von Zeitstempeln oder Versionsnummern. Dies heißt mit anderen Worten, dass eine bestimmte Anzahl von Versionen von replizierten Datenposten gespeichert und durch diesen Mechanismus verfolgt werden können.
e) Sperrfähigkeiten für gemeinsam genutzte Daten – Es ist in der Praxis kritisch, gemeinsam genutzte oder ausschließliche Sperren an Datenposten vorzusehen, auf die durch gleichzeitige Prozesse zugegriffen werden kann. Dieser Mechanismus verhindert eine Datenverfälschung und Wettlauf-Bedingungen zwischen gleichzeitigen Prozessen. Kompliziertere Arten von Sperren können erforderlich sein, um den Sperralgorithmus zu optimieren, beispielsweise gemeinsam genutzte vorgesehene ausschließliche Sperren. Weil der Datenreplikationsalgorithmus eine Ressource anfordern kann, während er einen Satz von Sperren an anderen Ressourcen hält, kann eine gegenseitige Blockierungssituation zwischen Datensynchronisationsprozessen auftreten. Somit müssen Datenreplikationsmechanismen Situationen mit gegenseitiger Blockierung verhindern.
f) Datenverfälschungs-Abwicklung oder Fehlertoleranz – Muss die Fähigkeit bereitstellen, verfälschte Daten und ihre zugehörige Information zu löschen. Datenverfälschungen können durch ein Rücksetzen des Systems, durch einen Leistungsausfall, durch Netzwerk-Verbindungszeitabläufe hervorgerufen werden. Diese Fähigkeit beruht stark auf der Fähigkeit zur Unterstützung einer Versionskennzeichnung.
g) Hohe Verfügbarkeit und Konsistenz von replizierten Daten – Der Zweck der Datenreplikation besteht in der Bereitstellung stark verfügbarer Daten, während eine Datenkonsistenz für verteilte Klienten aufrechterhalten wird. Das Ziel der Aufrechterhaltung einer Datenkonsistenz steht in Konflikt mit der Bereitstellung von stark verfügbaren Daten. Eine Konsistenz ermöglicht nur den Zugriff auf konsistente Kopien; die Verfügbarkeit verbessert sich, wenn ein Zugriff auf irgendwelche Kopien erfolgen kann. In der Praxis sind die Kosten zur Aufrechterhaltung einer Konsistenz von replizierten Daten proportional zur Verfügbarkeit der Daten (beispielsweise Kosten = Quadrat (Anzahl der Instanzen aller replizierten Daten)). Schließlich hängt diese Fähigkeit sehr stark von der Fähigkeit zur Unterstützung der Versionskennzeichnung und der Sperrung ab.
h) Interne Fehlerbehandlung – Der Datenreplikationsmechanismus hat seine eigenen internen Zustände, während er aktiv ist. Er muss seine Fehlerbedingungen sauber behandeln, so dass eine Datenverfälschung vermieden werden kann. Diese Fähigkeit ist mit der Verfälschungs-Abwicklungsfunktion verbunden.
i) Skalierbarkeit – Der Datenreplikationsmechanismus soll nicht auf die Größe des Netzwerks beschränkt sein, beispielsweise auf die Anzahl der Klienten. Ein Konstrukteur muss in der Lage sein, irgendwelche wünschenswerten oder wahlweisen Funktionalitäten dem System hinzuzufügen, sie aus dem System zu entfernen oder zu ersetzen.
j) Transparenz – Obwohl der Administrator eine Änderung der Replikationsstrategie wünschen kann, müssen die Benutzer dieses Mechanismus nicht darüber informiert sein, wie die Daten gespeichert werden und wie der Zugriff über das Netzwerk hinweg erfolgt. Vom Benutzerstandpunkt existiert ein Datenposten lediglich als eine einzige Instanz einer Netzwerk-Einheit in irgendeinem vorgegebenen Kontext. Daher muss die Anwendungsschnittstelle so „transparent" wie möglich ausgelegt werden.
k) Hoch-konsistenter Lesezugriff – Jedesmal dann, wenn ein Klient das Lesen eines Datenpostens anfordert, muss der Datenposten die neueste Version sein, die von dem dauerhaften Speicher zurückgeliefert wird. Während ein mobiler Klient örtlich gespeicherte replizierte Daten liest, sind andere mobile Klienten nicht in der Lage, den Datenposten zu lesen oder zu aktualisieren, bevor nicht die Leseoperation abgeschlossen ist. Dies bedeutet, dass wenn der Klient einen Datenposten liest, alle Instanzen des Datenposten exklusiv gesperrt werden müssen, bis die Leseoperation abgeschlossen ist. Dies verringert in schwerwiegender Weise die Verfügbarkeit des Datenpostens und ist somit ungeeignet für ein stark mobiles System. Diese Funktionalität muss jedoch immer noch für die Klienten verfügbar sein, wenn sie entscheiden, dass dies wichtig ist. Dieser Mechanismus hängt stark von den Forderungen für die Versionsführung, die Sperrung und die Hochverfügbarkeit von Daten ab.
l) Niedrig-konsistenter Lesezugriff – Wenn ein Klient das Lesen eines Datenpostens anfordert, kann der Datenposten eine ältere Version des replizierten Datenpostens sein. Während der mobile Klient die örtlich gespeicherten replizierten Daten liest, können andere mobile Klienten die anderen Kopien des Datenpostens lesen/aktualisieren. Dies vergrößert die Leseverfügbarkeit des Datenpostens. Dies ist für stark mobile Systeme geeignet, weil die meisten Datenzugriffe in einem verteilten System Lesezugriffe sind, so dass die Datenverfügbarkeit sehr stark die Netzwerk-Betriebsleistung beeinflusst. Weil eine momentane Lesekonsistenz bei diesem Modell nicht garantiert ist, müssen die Klienten über die Verwendung dieser Funktionalität selbst entscheiden. Obwohl die Daten nicht momentan während des Zugriffs konsistent sind, müssen alle Kopien schließlich wieder konsistent werden. Dieser Mechanismus beruht stark auf den Forderungen für die Versionsführung, die Sperrung und die hohe Verfügbarkeit von Daten.
m) Hoch-konsistenter Schreibzugriff – Jedesmal dann, wenn ein Klient das Zurückschreiben eines Datenpostens an den persistenten Speicher anfordert, wird der Datenposten zu der neuesten Version in dem dauerhaften Speicher. Während ein mobiler Klient örtlich gespeicherte replizierte Daten aktualisiert, sind andere mobile Klienten nicht in der Lage, den Datenposten zu lesen/aktualisieren, bevor nicht die Schreiboperation abgeschlossen ist. Dies bedingt, dass wenn der Klient einen Datenposten liest, alle Instanzen des Datenpostens exklusiv gesperrt werden müssen, bis die Schreiboperation abgeschlossen ist. Dies verringert in schwerwiegender Weise die Verfügbarkeit des Datenpostens und ist damit für ein stark mobiles System ungeeignet. Diese Funktionalität muss jedoch für die Klienten verfügbar sein, wenn sie entscheiden, dass dies wichtig ist. Dieser Mechanismus beruht stark auf den Forderungen für die Versionsführung, die Sperrung, die hohe Verfügbarkeit von Daten und dem schwach konsistenten Lesezugriff.
n) Universelle Datenreplikation – Ein Netzwerk kann in unterschiedliche Datenreplikations-Teilsysteme unterteilt werden. Kopien können über diese Teilsysteme auf dem Netzwerk hinweg gespeichert werden. Diese Teilsysteme können nicht die gleiche Version haben, doch müssen neuere Versionen der Datenreplikations-Teilsysteme rückwärts kompatibel mit den älteren Versionen sein. Weiterhin müssen Daten auf jedem Knoten dieser Teilsysteme replizierbar und zugänglich sein.
o) Bezugs-Integrität – Alle Bezugnahmen auf einen replizierten Datenposten oder ein Objekt müssen konsistent sein. Das heißt, dass wenn eine neue Instanz des replizierten Datenpostens in dem System geschaffen wird, Aktualisierungen aller Kopien mit der neuen Kopie konsistent sein müssen. Wenn eine Kopie aus dem System entfernt wird, müssen Bezugnahmen auf die obsolete Kopie ebenfalls von dem System entfernt werden.

Weitere Funktionalitäten, die berücksichtigt werden müssen, schließen Folgendes ein:

p) Einfache API – Der persistente Speichermechanismus sollte für JAVA-Applet-Programmierer einfach zu verstehen und zu verwenden sein.
q) Schnelle Lese-/Schreib-Fähigkeit – Sollte eine kleine Lese-/Schreib-Latenz zur Unterstützung des Entwurfs von Applets bereitstellen, die die persistente Speicherung behandeln und mit optimalen Geschwindigkeiten ablaufen.
r) Minimaler persistenter Speicherungs-Zusatzaufwand – Sollte so ausgelegt werden, dass sich ein minimaler Fragmentierungs-Zusatzaufwand der persistenten Speicherung ergibt. Weiterhin sollte der Zusatzaufwand der persistenten Speicherung, der mit dem zur Abfrage gespeicherter Datenposten verwendeten Indexierungsschema verbunden ist, minimal gehalten werden.
s) Komprimierte Speicheroption – Sollte eine Unterstützung für die Konfiguration zur Speicherung seiner Daten in komprimierter Form und transparent für den Benutzer bereitstellen. Dies optimiert die Nutzung des persistenten Speichers (möglicherweise unter Inkaufnahme verringerter Zugriffsgeschwindigkeiten).
t) Effiziente Rückgewinnung – Sollte eine effiziente Möglichkeit zur Lokalisierung eines vorgegebenen Datenpostens und zu dessen Vorbereitung zum Lesen und/oder Schreiben bereitstellen.
u) Synchrone/asynchrone/zukünftige Rücklieferung des Ergebnisses – Wenn eine synchrone Anforderung für eine gültige Operation der Datenreplikation (beispielsweise Lesen/Schreiben) gemacht wird, liefert der Schnittstellenaufruf keine Antwort (mit/ohne Antwortcode), bevor nicht die Ausführung der Operation abgeschlossen ist. Wenn eine asynchrone Anforderung gemacht wird, wird der Aufruf zurückgeliefert, solange er in einem gültigen Kontext erfolgt. Wenn eine zukünftige (zukünftige asynchrone) Anforderung gemacht wird, wird der Aufruf zurückgeliefert, solange er sich in einem gültigen Kontext befindet, und der Rücklieferungscode ist verfügbar, wenn die Ausführung abgeschlossen ist.
v) Intelligenz – Der Datenreplikationsmechanismus kann die Intelligenz (entweder statisch, dynamisch oder adaptiv) haben, um die Speicherung, den Lastausgleich und die Kosten zu optimieren. Dies könnte durch Einstellen von Speichergrenzen, was eine frühzeitige Neuverbindung erzwingt, durch Wählen einer Verzögerung der Neuverbindung zu stärker beschäftigten Knoten, usw. erzielt werden. Eine statische Intelligenz wird während der Codekompilation des Datenreplikationssystems hinzugefügt. Eine dynamische Intelligenz kann von dem Administrator in Echtzeit hinzugefügt werden, während eine adaptive Intelligenz die Fähigkeit hat, das Verhalten des Systems durch Lernen der Tatsachen zu ändern, die zur Echtzeit erhalten werden.

Der klientenseitige, persistente Datenspeichermechanismus
Ein Dateisystem ist eine mögliche Lösung. Sie wird jedoch nicht bevorzugt, weil sie nicht zum Speichern von Objekten geeignet ist, und weil ein Zusatzaufwand aufgrund der Fragmentierung des Speichermediums und der Verzeichnisstrukturen hervorgerufen wird.
Eine Datenbank-Lösung ist besser als die Dateisystem-Lösung, weil eine Datenbank eine persistente Speicherung ist. Zusätzlich zur Datenkonsistenz ergibt eine Datenbank weiterhin eine Vielzahl von Funktionalitäten: Abfrage, Wartung, Replikation und Fehlertoleranz. Aus diesen Gründen ist eine Datenbank die bessere Wahl auf Langzeit gesehen. Wenn der Klient jedoch eine ultra-dünne persistente Speicherung benötigt, kann die Dateisystem-Lösung eine brauchbare Alternative sein. Wenn eine Wahl zwischen einer traditionellen relationalen Datenbank, wie z. B. Oracle oder DB2, und einer OODB zur Verfügung steht, wird die OODB bevorzugt, weil die Umsetzung von JAVA-Objekten auf OODB sehr einfach und elegant ist. Es besteht keine Notwendigkeit, zusätzlichen Code zur Umsetzung von Objekten auf eine relationale Datenbanktabelle zu schreiben. Weiterhin ist eine Objekt-Sperrung eine allgemeine Fähigkeit einer OODB. Ein Beispiel einer OODBM für JAVA ist ObjectStore 5.0 mit einer JAVA-Schnittstelle.
Grundlegende DPS-Funktionalität
Eine grundlegende Ausführungsform der verteilten persistenten Speicherung (DPS) für zumindest einen Klienten-Knoten und einen Server-Knoten könnte die folgenden Funktionalitäten einschließen:

a) Persistente Speicherung von Objekten zwischen Speichern an unterschiedlichen geografischen Stellen.
b) Auf der Server-Seite, wenn sie verteilt ist, sowie auf der Klienten-Seite, ergibt sich ein Konzept von Heimat- gegenüber Besucher-Datenbanken. Eine Hauptkopie der Datenbank wird an den Heimat-Server gespeichert und die Slave-Kopien werden an den Besucher-Servern gespeichert.
c) Die Master-Kopie wird örtlich auf die Besucher-Knoten gepuffert, wenn der mobile Klient einen Zugriff auf die Datenbank versucht.
d) Änderungen, die an einem Master- oder Besucher-Knoten durchgeführt werden, müssen zu den replizierten Knoten zurückgeliefert werden.
e) Die Bewegung eines Benutzers wird in einem Benutzer-Positionsregister verfolgt, das dauerhaft oder persistent in der Datenbank gespeichert wird.
f) Ein mobiler Klient kann von dem Netzwerk über eine lange Zeitperiode getrennt sein. Er kann einen Zugriff auf die Datenbank über den Heimat- oder den Besucher-Knoten ausführen, üblicherweise in Abhängigkeit davon, welcher Knoten geografisch am nächsten liegt. Eine örtliche Kopie der Datenbank wird auf dem mobilen Klienten in einem Puffer gespeichert und kann modifiziert werden, während der Klient von dem Netzwerk getrennt ist.
g) Eine Datensynchronisation der mobilen Klienten wird bei einer Wiederherstellung der Verbindung ausgeführt. Weil ein mobiler Klient üblicherweise derjenige ist, der die Verbindung zu dem Server einleitet, sollte die Daten-Neusynchronisation ebenfalls von dem Klienten eingeleitet oder ausgelöst werden. Andererseits kann auch der Server die Verbindung zu seinem Klienten einleiten, und die Datensynchronisation kann auch von dem Server eingeleitet oder ausgelöst werden. Dies ist analog zu der Push-Pull-Technologie, die auf bekannten Klienten-/Server-Umgebungen verfügbar ist, doch ist sie wesentlich skalierbarer, weil sie auf einem verteilten Modell beruht.

Die Konfliktauflösungsrichtlinie für die Daten-Neusynchronisation besteht in einem Ersatz der älteren Version der Daten durch die neuere Version auf der Grundlage von deren modifizierter Zeit. Diese Richtlinie wird aus Vereinfachungsgründen gewählt, und es könnten kompliziertere Richtlinien in Betracht gezogen werden, die besser geeignet sein könnten, entsprechend den Notwendigkeiten der Anwendungen. Wenn die Versionen die gleichen sind, die Kopien jedoch unterschiedlich sind, würde eine Benachrichtigung an die zwei synchronisierenden Knoten gesandt, und es würde keine Änderung an irgendeinem Ende durchgeführt. Wenn der Klient von dem Netz getrennt ist, werden modifizierte Objekte als „unsauber" markiert und würden zu einer Neusynchronisation mit dem Server bei erneuter Verbindung gezwungen.

h) Die „unsauberen" Objekte auf dem mobilen Klienten haben die höchste Priorität bei der Neusynchronisation.

Zur Demonstration der verteilten Aspekte der persistenten oder dauerhaften Speicherung hat die Realisierung des Klienten mit getrennter Verbindung eine feinere Replikations-Körnigkeit: unterschiedliche Wurzelobjekte in einer Datenbank können eine unterschiedliche geografische Replikationsstrategie haben.
5, 6 und 7 – Statisches Modell der DPS
Die DPS-Middleware besteht aus drei Schichten unterhalb der Anwendung: Abstraktion, Gleichzeitigkeit und Datenbank. Die Abstraktionsschicht 62, 64, 66 dient zur Bereitstellung einer Abstraktion der Struktur der persistenten Speicherung, der kundenspezifischen Dienste und der Software-Einsprungsmöglichkeiten zur Verbesserung der Verfügbarkeit von von dritter Seite gelieferten Datenbankfähigkeiten für die Anwendung. Sie umfasst eine Dienste-Teilschicht 66, eine Datenbankunabhängige Teilschicht 62 und eine Kennungs-Teilschicht 64. Die Gleichzeitigkeitsschicht 68 ist zur Bereitstellung einer kundenspezifischen Datenbank-Gleichzeitigkeitssteuerung für die Anwendung bestimmt, wie z. B. ein Mehrpfade-Zugriff an die Datenbank, eine verbundene Transaktion zwischen Mehr-Leser-Pfade und einem einzelnen Schreiber-Pfad. Die Datenbankschicht 70 ist einfach eine Datenbank von dritter Seite. Die Datenbank kann eine objektorientierte Datenbank (OODB) oder eine relationale Datenbank (RDB) sein. Die Schichtung ist dazu bestimmt, die Anwendung von der darunterliegenden persistenten Speicherstruktur zu isolieren. In dem Beispiel des in der Figur gezeigten statischen Modells kann sie durch Root_PS dargestellt werden. Sie enthält den Code zur Ermöglichung eines Mehrpfadezugriffs auf eine einzige Datenbank. Die Strategie besteht in einer Serialisierung einzelner Transaktionen jedes Pfades (mehrfache Leser oder ein einziger Schreiber) in einer einzigen Transaktion. Obwohl dies nicht die beste Datenzugriffs-Gleichzeitigkeit für die Pfade ergibt, stellt dies eine gute Lösung zur Überwindung eines Mangels von OODB's dar, wie z. B. ObjectStore.
Die Dienste-Teilschicht besteht aus unterschiedlichen Arten von persistenten Speicherdiensten. Einige grundlegende Dienste, die unterstützt werden, sind: Replikation 67, Verbindungsüberwachung und Neusynchronisation 105 und Konfliktauflösung 69. Der Replikationsdienst ergibt eine Daten- oder Objekt-Replikation über das verteilte persistente Speichersystem hinweg. Der Konfliktauflösungsdienst ist vorgesehen, um inkonsistente Aktualisierungen zwischen Klienten mit getrennter Verbindung aufzulösen. Eine grundlegende Strategie hierfür besteht darin, die ältere Version eines Objektes durch die neuere Version örtlich in der Neusynchronisationsphase zu ersetzen, was für dünne Klienten ausreichend ist. Höher entwickelte Konfliktauflösungstechniken sind gut bekannt und könnten realisiert werden, wenn dies erwünscht ist. Der Verbindungsüberwachungsdienst ergibt sowohl für die persistente Speicherung als auch die Anwendung eine Möglichkeit zur Überwachung des Verbindungszustandes zu anderen Knoten und zur Durchführung einer Neusynchronisation, wenn dies passend ist. Er könnte als ein Pfad oder als ein Verfahren realisiert werden, der bzw. das von anderen aufgerufen wird. Es wird angenommen, dass dieser Dienst einen Zugang auf den Zustand der Verbindung auf der Hauptmaschine hat und somit der DPS oder der Anwendung eine Möglichkeit geben kann, um den Datenzugriff auf der Grundlage des Zustandes der Verbindung zwischen den Hosts zu liefern.
Die Datenbank-unabhängige Teilschicht ist dazu vorgesehen, die tatsächliche Datenbank-Struktur gegenüber der Anwendung zu verbergen. Vom Gesichtspunkt der Anwendung ist eine Datenbank, die sie erzeugt, eine einzige logische Einheit. Sie sollte in der gleichen Weise unabhängig von der geografischen Position der mobilen Klienten zugänglich sein. In dem statischen Modell, beispielsweise einer Telefonverzeichnis-Anwendung könnte diese Teilschicht durch Telefonverzeichnis_PS oder Benutzerprofil_PS (oder <Anwendungsobjekt>_PS) dargestellt sein, wie dies gezeigt ist und weiter unten unter Bezugnahme auf 9 erläutert wird. Sie ergibt eine Kennung für die tatsächliche verteilte Datenbank. Die Funktionen dieser und anderer Teile werden ausführlicher weiter unten unter Bezugnahme auf das dynamische Modell nach 8 beschrieben.
Die Kennungs-Teilschicht liefert (Persistenz-bewusste) Kennungen an alle zu einer persistenten Speicherung fähigen Objekte in der Datenbank.
Wenn die Instanzen einer Klasse mit persistenten Objekten arbeiten könen, als solche jedoch nicht in der DPS-Datenbank gespeichert werden können, so ist die Klasse Persistenz-bewusst. Wenn man ein Objekt in einer DPS-Datenbank speichern kann, so ist das Objekt Persistenz-fähig. Wenn man die Instanzen einer Klasse in einer Datenbank speichern kann, so ist die Klasse Persistenz-fähig. Dies verbirgt den tatsächlichen Datenzugriffsmechanismus auf das Objekt gegenüber der Anwendung. Dies ist erforderlich, weil Einsprungstellen hinzugefügt werden, um einen transparenten Zugriff auf persistente Speicherdienste zu ermöglichen, wie z. B. die Objekt-Replikation. Wenn der „."-Operator in JAVA überladen werden kann, so kann diese Teilschicht transparenter gemacht werden, als sie es nunmehr ist. Ein Beispiel eines Kennungsobjektes ist wie folgt: Telefonverzeichnis H, wie dies weiter unten unter Bezugnahme auf 9 erläutert wird.
Eine weitere Ansicht einiger der Bestandteile der DPS-Middleware für einen Klienten-Knoten ist in 7 gezeigt. Einige Komponenten 75 werden dupliziert, um eine für jede Datenbank bereitzustellen, und es kann verschiedene Datenbanken geben, die von verschiedenen Anwendungen oder von der gleichen Anwendung verwendet werden. Ein Replikationsregister 90 führt eine Aufzeichnung darüber, welche Objekte in seiner Datenbank auf benachbarten Knoter repliziert werden, zusammen mit der Identität dieser Knoten.
Das Replikationsregister könnte wie folgt realisiert werden: für jedes Objekt werden zwei Abbildungen geführt. Eine erste Abbildung ergibt ein direktes Nachschlagen der Speicher-ID der Objekte auf der Grundlage des Objektnamens und der Host-Namens-Port-ID. Eine zweite Abbildung ist vorgesehen, um ein direktes Nachschlagen der Port-ID des Objektes auf der Grundlage des Objektnamens, der Speicher-ID und des Host-Namens zu erzielen. Es ist erforderlich, die Port-ID zu gewinnen, um die Herstellung einer Verbindung zu ermöglichen. Es ist erforderlich, die Speicher-ID zu gewinnen, wenn es mehrfache Kopien des gleichen Objektes auf dem gleichen Host ergibt, beispielsweise wenn eine Redundanz vorgesehen ist. Die Bereitstellung von zwei Abbildungen oder Umsetzungen ermöglicht das Erzielen eines schnelleren Nachschlagens.
Eine Liste von Objekten 100 ist eine Liste der Identität der Objekte, die in der Datenbank an dem Klienten-Knoten gepuffert sind. Ein Fach oder Speicher 80 für „unsaubere" Objekte ist vorgesehen, um alle diejenigen Objekte aufzuzeichnen, die örtlich gepuffert wurden und die geändert wurden, während der Knoten nicht verbunden war. Das Führen einer derartigen Aufzeichnung macht es einfacher, zu identifizieren, welche Objekte eine Neusynchronisation benötigen, wenn eine Verbindung hergestellt wird. Sie kann als ein FIFO-Mechanismus (erste eingespeicherte Daten werden als erste ausgespeichert) realisiert werden, um die Reihenfolge der Einträge beizubehalten. Ein geändertes Objekt kann mehrfache Einträge in dem Fach oder Speicher hervorrufen, so dass es einen Eintrag für jede Replikation des Objektes auf unterschiedlichen benachbarten Knoten gibt. Dies kann unter Verwendung der Information in dem Replikationsregister erzielt werden. Dann kann, während eine Neusynchronisation mit jeder der benachbarten Knoten erfolgt, der entsprechende Eintrag in dem Fach beseitigt werden, während die Einträge verbleiben, die sich auf noch nicht verbundene Knoten beziehen.
Die Steuerfunktionen zur Durchführung der Synchronisationen, die dem Peer-zu-Peer-Modell folgen, sind bei 115 gezeigt. Sie verwenden die vorstehend beschriebenen Komponenten 75 und entsprechende Komponenten 85 für eine andere Datenbank. Eine Tabelle 110 des Zustandes von Verbindungen zu benachbarten Knoten ist ebenfalls gezeigt.
8 – Dynamisches Modell
Das in 8 gezeigte dynamische Modell erläutert das Laufzeitverhalten der DPS und einer Anwendung. Die Aktionen der Anwendung sind auf der linken Seite gezeigt, und die der DPS-Middleware, die über die Klienten-Knoten und den Server verteilt ist, sind auf der rechten Seite gezeigt. Die Aktionen können in drei Teile aufgeteilt werden, Initialisierung, Verbindungs-Änderungen und die Ausführung von Operationen an den Daten.
Der Aufruf eines Objekt-persistenten Grundelementes leitet einen Mitteilungsaustausch zwischen zwei replizierten Knoten ein. Dieser Austausch kann als eine „virtuelle Objekt-persistente Sitzung" zwischen zwei persistenten Objekt-Datenbanken betrachtet werden. Um sicherzustellen, dass sich die Sitzung passend verhält, muss die Anwendung das Replikationsregister mit einer genauen Replikationseintrag-Information konfigurieren.
Weil mobile Klienten keine stabile Verbindungen haben, ist die DPS so ausgelegt, dass die mobilen Klienten die Aktivierung ihrer DPS-Sitzung auslösen können. In der Praxis würde es der mobile Klient (drahtloses Telefon) sein, der (beispielsweise Ortsbereichswechsel) Diensteanforderungen einleitet. Somit ist diese Architektur konsistent mit dem Verhalten von mobilen Klienten in der realen Welt. Der Server kann jedoch ebenso die Aktivierung seiner DPS-Sitzung zu seinen Klienten einleiten. Auf diese Weise bietet diese Erfindung eine maximale Flexibilität für den Mobilsystem-Entwickler.
Um eine Konsistenz von replizierten Objekten aufrechtzuerhalten, beruht der Synchronisationsalgorithmus auf seiner Wechselwirkung mit der Verbindungstabelle und dem Replikationsregister.
Die Initialisierungsaktionen werden als erstes beschrieben. Nach der Datenbank-Initialisierung bei 118 gewinnt die Anwendung eine Datenbank-Kennung (Telefonverzeichnis_PS in dem nachfolgend unter Bezugnahme auf 9 erläuterten Beispiel) in dem derzeitigen Pfad bei 120. Die DPS initialisiert die Datenbank-Kennung mit Verbindungen zu der Verbindungstabelle und dem Replikationsregister bei 122. Die Anwendung verwendet dann die Datenbank-Kennung, um das Wurzel-Objekt nachzuschlagen oder zu erzeugen. Die Datenbank-Kennung liefert die entsprechende Objekt-Kennung an die Anwendung zurück. Die Anwendung muss die Schnittstellen der Objekt-Kennung für einen Zugriff an das jeweilige Objekt verwenden. Diese Kennungen enthalten alle die notwendige Kenntnis zur Wechselwirkung mit der Kern-DPS-Software. Die DPS initialisiert die Objekt-Kennung mit Verknüpfungen auf die Datenbank und die Verbindungstabellen-Kennungen bei 126 (wie dies in 9 gezeigt ist). Die Anwendung aktualisiert das Replikationsregister und bindet alle Replikationseinträge von replizierten Objekten an das Register bei 128. Schließlich bindet die DPS bei 130 die Einträge an die Datenbank.
Entsprechend den Notwendigkeiten der Anwendung oder der Anwendungen können diese Verbindungen zu anderen Knoten einleiten, wie dies bei 132 gezeigt ist. Die DPS reagiert durch Aktualisieren der Verbindungstabelle bei 134.
Wenn eine Anwendung eine Operation an den an dem Server gespeicherten oder örtlich gepufferten Daten ausführen möchte, ruft sie ein DPS-Grundelement auf, wie z. B. Erzeugung, Änderung, Nachschlagen, Puffern, Löschen, usw. Dies ist bei 136 gezeigt. Dies bewirkt, dass die DPS bei 138 feststellt, ob dies ein örtliches Grundelement oder eine API (Anwendungsprogrammierschnittstelle) ist, und wenn dies der Fall ist, beginnt sie mit der Ausführung. Wenn dies ein entfernt angeordnetes Grundelement ist, so würde ein entfernter Verfahrensaufruf-Mechanismus verwendet, um die entfernte Ausführung der Operation zu ermöglichen, beispielsweise auf dem Server. Wie dies weiter unten ausführlicher erläutert wird, schließen einige Operationen eine Neusynchronisation der gepufferten Daten ein. Wenn dies erfolgt, prüft die DPS das Fach für „unsaubere" Objekte und erzwingt eine Neusynchronisation der unsauberen Objekte, wenn eine Verbindung zu einem Nachbarn besteht, der eine Replikation derartiger Objekte hat. Wenn sie das Fach für unsaubere Objekte durchlaufen hat, erzwingt die DPS eine Synchronisation der Objekte, die derzeit verwendet werden, jedoch noch keinen Eintrag in dem Fach für unsaubere Objekte haben. Nach jeder erforderlichen Neusynchronisation verarbeitet die Anwendung bei 139 die rückgelieferten Ergebnisse und irgendwelche Abbrüche.
9 – Klassenhierarchie
Eine objektorientierte Klassenhierarchie zur Realisierung einer Ausführungsform der Erfindung ist in 9 gezeigt. Die Klassen- oder Objekte werden wie folgt erläutert:
Root_PS, 142 ist ein Persistenz-bewußtes Objekt, das die Datenbankunabhängige Abstraktions-Teilschicht für die Anwendung bereitstellt. Sie setzt sich direkt in eine Datenbank um und enthält außerdem die Gleichzeitigkeitsschicht-Funktionalität, die einen Mehrfachpfad-Zugriff auf die Datenbank ermöglicht („gleichzeitig vom Blickwinkel eines Benutzers aus").
DRoot_PS, 144 erweitert die Root_PS-Fähigkeiten; es bietet eine verteilte dauerhafte oder persistente Speicherung für die Anwendung. Jede Datenbank speichert eine Kopie ihres Replikationsregisters, das für die Bestimmung der Replikations-Strategie an dem aktuellen Knoten von wesentlicher Bedeutung ist. PhoneList_PS 146 ist die anwendungsspezifische DPS-Kennung für eine Telefonverzeichnis-Anwendung.
PhoneListCore 148 ist eine persistenzfähige Klasse. Es enthält die nicht-UI-Komponente (nicht-UI bedeutet, dass es keine Benutzerschnittstellen-Komponente des persönlichen Telefonverzeichnisses enthält) des Kerns von PhoneList 161 (die UI-Version eines Telefonverzeichnisses). PhoneListCore ist die Wurzelobjektklasse für PhoneList_PS. PhoneListSerialCore 164 ist ein Objekt-Umschlag für PhoneListCore. Dieser Umschlag ermöglicht eine Serialisierung von PhoneListCore (beispielsweise für RMI der DPS). Weil derzeitige OODB's, wie z. B. Objekte von ObjectStore nicht serialisierbar sind, wird diese Klasse geschaffen, um diese Beschränkung zu umgehen.
PSReplicationRegistry 166 ist das Replikationsregister für DRoot_PS. Es enthält diese Elemente: Objekt, Rechnername, Port-Nummer, Positions-ID. Ein Replikationsknoten ist ein eindeutiges <Rechnername, Port-Nummer>-Paar. Jeder Knoten hat eine Replikation oder eine Kopie des Objektes, so dass dies eine maximale Flexibilität hinsichtlich der Objekt-Replikation ergibt. Derzeit wird der Schlüssel des Root- oder Wurzelobjektes (der eine Zeichenkette ist) auf das Register statt auf das Objekt selbst umgesetzt. Im Fall der PhoneList-(Telefonverzeichnis-)Anwendung ist das Wurzelobjekt ein personalisiertes Telefonverzeichnis, das auf eine eindeutige Schlüssel-Zeichenkette umgesetzt oder abgebildet ist, die der Inhaber des Telefonverzeichnisses ist.
PSConnectionTable (Verbindungstabelle) 168 wird zum Speichern des Verbindungszustandes von Knoten mit ihren Nachbarn erzeugt. Die Endpunkte der Verbindung sind die Computernamen der zwei DPS-Knoten. Diese Tabelle wird von der Verbindungsüberwachung oder Anwendungen aktualisiert, die den Verbindungszustand des örtlichen Computers kennen. Dieser Zustand kann verbunden oder nicht verbunden sein. Wenn der Knoten B keinen Eintrag in der Verbindungstabelle des Knotens A hat, bedeutet dies, dass B und A keine benachbarten Knoten sind. Wenn die Anwendung den Zustand ihrer Verbindung aktualisiert, kann das System in der realen Welt von drahtlosen mobilen Klienten arbeiten. Die Verbindungstabelle ist nicht persistenzbewusst oder -fähig, weil Verbindungen zwischen mobilen Klienten oder Servern Laufzeitereignisse sind.
Die Kennung (Handle) 143 ist die Klasse, die die Kennungs-Teilschicht-Abstraktion für die Anwendung ergibt. DHandle 145 erweitert Handle, um die verteilte Persistenz für die Anwendung bereitzustellen. Um eine effiziente Berechnung zu schaffen, hat DHandle einen impliziten (nicht gezeigten) Bezug auf seine Datenbankkennung, weil PHoneListH von Dhandle erbt, und PhoneList_PS von DRoot_PS erbt, so dass ein schnellerer Zugriff auf die Datenbank-API's erfolgen kann. Im Fall eines nicht verbundenen mobilen Klienten ist dessen verteiltes persistentes Speicher-Rahmenwerk auf dem Server-Rahmenwerk aufgebaut. DRoot_PS, DHandle werden bereitgestellt, um eine tatsächliche verteilte Objekt-Speicherfähigkeit zu schaffen. PhoneListH 149 ist ein Beispiel eines Kennungs-Objektes für die Telefonverzeichnis-Anwendung. Es hat einen Verweis auf PhoneListCore und auf PhoneList_PS. PhoneListH enthält die erforderlichen persönlichen Telefonverzeichnis-Schnittstellen für den Benutzer, wie z. B. das Hinzufügen/Löschen/Ändern/Durchsuchen/Nachschlagen eines Telefoneintrags, wobei die Realisierungen der Schnittstellen deren Wechselwirkung mit der DPS gegenüber dem Benutzer verdecken.
DirtyObjectsBin (Fach für unsaubere Objekte) 147 ist eine persistenzfähige Hash-Tabelle, die alle modifizierten Objekte speichert, die mit anderen replizierten Knoten neu synchronisiert werden müssen. Wenn ein Objekt in eine Hash-Tabelle codiert werden muss, wird ein eindeutiger Hash-Code (beispielsweise eine lange ganze Zahl) auf der Grundlage des Wertes des Objektes zugeordnet. Der Hash-Code dient als ein Index zum Nachschlagen des Objektes. Die Hash-Tabelle besteht aus einem endlichen Satz von Hash-Speicherbereichen, die auf mehr als einen Hash-Code umgesetzt werden können. Die Umsetzung wird auf der Grundlage einer voreingestellten Hash-Funktion berechnet. Daher kann jeder Hash-Speicherbereich mehrfache Hash-Einträge enthalten, die jeweils ein eindeutig Hash-codiertes Objekt speichern. Jede Datenbank weist ein DirtyObjectsBin auf. Während einer Verbindungswiederherstellung wird erzwungen, dass Objekte in dem DirtyObjectsBin als erstes neu synchronisiert werden. Wenn ein Objekt seine Neusynchronisation beendet hat, wird es aus der Hash-Tabelle entfernt.
10 – Neusynchronisations-Aktionen zwischen Knoten
Die Hauptschritte bei einer Ausführungsform des Neusynchronisationsprozesses sind in 10 für irgendwelche zwei Knoten gezeigt, die aus Bequemlichkeitsgründen als ein örtlicher Knoten und als ein entfernt angeordneter Knoten bezeichnet werden. Die an dem örtlichen Knoten durch die Überwachungs- und Neusynchronisationsfunktionen ausgeführten Schritte sind auf der linken Seite gezeigt, und diejenigen für den entfernt angeordneten Knoten sind auf der rechten Seite gezeigt. Bei 110 wartet der örtliche Knoten auf eine Verbindung. Sobald eine Verbindung festgestellt wird, prüft der entfernt angeordnete Knoten sein Replikationsregister, um festzustellen, ob der verbundene Knoten eine Kopie irgendeines der Objekte hat, die an dem örtlichen Knoten gepuffert sind. Wenn dies der Fall ist, sendet der örtliche Knoten bei 150 eine Nachricht, wie aktuell die örtlichen Kopien eines oder mehrerer derartiger Objekte sind, an den entfernt angeordneten Knoten. Vorzugsweise wird dies lediglich für diejenigen Objekte durchgeführt, die der örtliche Knoten geändert hat. Der entfernt angeordnete Knoten kann diese Informationen dann mit entsprechenden Informationen für seine Kopien dieser Objekte bei 152 vergleichen.
Wenn der entfernt angeordnete Knoten feststellt, dass die entfernt angeordnete Kopie aktueller ist, sendet er eine Kopie (oder Einzelheiten über die Unterschiede) an den örtlichen Knoten bei 154, um es diesem zu ermöglichen, seine Kopie bei 156 zu aktualisieren. Der örtliche Knoten kann dann die Änderung an andere Knoten in ähnlicher Weise weiterleiten. Weiterhin kann an diesem Punkt auch eine Konfliktauflösung in dem örtlichen Knoten begonnen werden, wenn dies erforderlich ist. Dies kann erleichtert werden, wenn der örtliche Knoten eine Aufzeichnung von Transaktionen unter Verwendung der Objekte, die geändert wurden, geführt hat. Vorzugsweise deckt die Aufzeichnung weiterhin Objekte ab, auf die ein Zugriff ausgeführt wurde, die jedoch nicht geändert wurden, für den Fall, dass sie von einem anderen Knoten geändert wurden oder bei ihrem Zugriff zeitlich überholt waren.
Wenn der entfernt angeordnete Knoten feststellt, dass die örtliche Kopie aktueller ist, aktualisiert er seine eigene Kopie bei 158, indem er die erforderlichen Informationen von dem örtlichen Knoten anfordert. Wenn die entfernt angeordnete Kopie und die örtliche Kopie das gleiche Datum oder die gleiche Version haben, so wird der örtliche Knoten bei 160 informiert. Der Prozess wird bei 162 wiederholt, bis alle örtlichen Daten synchronisiert sind. Die gleiche Art von Prozess kann für alle Objekte durchgeführt werden, die der entfernt angeordnete Knoten geändert hat. Dies könnte als Teil des vorstehenden Prozesses ausgeführt werden, indem der entfernt angeordnete Knoten den örtlichen Knoten informiert, welche Objekte an dem entfernt angeordneten Knoten geändert wurden. Dies wird jedoch vorzugsweise als ein paralleler unabhängiger Prozess durchgeführt, der von dem entfernt angeordneten Knoten eingeleitet wird und exakt den gleichen Schritten folgt, wie sie vorstehend angegeben wurden, wobei jedoch der entfernt angeordnete und der örtliche Knoten vertauscht sind. Dies liegt näher an dem Peer-zu-Peer-Prinzip, was eine verbesserte Skalierbarkeit und eine leichtere Realisierung ermöglicht, wenn alle Knoten gleich sind und ein Minimum an anfänglicher Anpassung erfordern.
Die Information, wie aktuell die Daten sind, kann beispielsweise eine Versionsnummer oder ein Zeitstempel sein. Für objektorientierte Daten sollte jedesmal dann, wenn die Attribute eines Objektes oder dessen Attribut-Objekte geändert werden, die Version oder der Zeitstempel geändert werden. Verschiedene Möglichkeiten können in Betracht gezogen werden, um dies zu erzielen. Wenn das Objekt an allen Attribut-Objekten teilnimmt, kann unabhängig davon, ob eine Änderung in diesen Attribut-Objekten auftritt, die Versionsnummer des Objektes vergrößert werden oder sein Zeitstempel kann aktualisiert werden. Alternativ kann eine globale Versionskontrollverwaltung realisiert werden, die ein baumartiges Aufrufdiagramm aller der Objekte führt. Eine Änderung in einem Objekt bewirkt, dass die Verwaltung Aktualisierungen in allen Stammobjekten auslöst, die durch einen Aufwärts-Durchlauf des baumartigen Aufrufdiagrammes erfasst werden.
11 – Neusynchronisations-Aktionen an dem entfernten Knoten
Ein ausführlicheres Ablaufdiagramm der Aktionen an dem entfernten Knoten nach 10 ist in 11 gezeigt. Nachdem auf eine Verbindung bei 170 gewartet wurde, wird ein Posten von dem Fach für unsaubere Objekte an dem örtlichen Knoten bei 172 empfangen. Der entfernt angeordnete Knoten sperrt die Kopie des betreffenden Objektes an dem entfernten Knoten bei 174. Bei 176 wird festgestellt, ob der Posten eine „lösche-alles"-Operation ist. Wenn dies der Fall ist, so wird ein örtliches Löschverfahren aufgerufen, um die Kopie in dem entfernt angeordneten Knoten zu löschen, und dann wird der nächste Posten, der von dem Fach für unsaubere Objekte des örtlichen Knotens empfangen wird, überprüft. Wenn festgestellt wird, dass dieser Posten keine „lösche-alles"-Operation ist, so wird bei 152 die Versions- oder Zeitstempel-Information verglichen, um festzustellen, ob die Kopie an dem entfernten Knoten überholt ist. Wenn dies der Fall ist, so wird bei 178 die Kopie in dem entfernten Knoten aktualisiert, indem ein örtliches Änderungsverfahren aufgerufen wird. Weitere Einzelheiten dieses Verfahrens werden weiter unten erläutert. Anderenfalls wird dieser Schritt umgangen. Das Auftreten irgendwelcher Fehler oder Unterbrechungen wird bei 180 festgestellt und dem örtlichen Knoten bei 182 mitgeteilt, und der Eintrag in dem Fach für unsaubere Objekte an dem örtlichen Knoten wird ungelöscht gelassen. Bei 184 wird dem örtlichen Knoten eine erfolgreiche Aktualisierung mitgeteilt, und bei 186 wird das betreffende Objekt in dem entfernten Knoten entsperrt.
Die Hauptschritte, die beteiligt sind, wenn Operationen an einem Objekt durchgeführt werden, das örtlich gepuffert sein kann und eine Synchronisation erfordern kann, werden nunmehr beschrieben. Diese Verfahren können von Anwendungen aufgerufen werden, oder, wie dies weiter oben gezeigt wurde, können einige als Teil der DPS-Funktionen aufgerufen werden, wie z. B. durch die Neusynchronisation. Allgemein würde eine Anmeldung nicht in der Lage sein, die örtlichen Operationen zu verwenden, sondern lediglich die globalen, weil anderenfalls die Neusynchronisation von Anwendungen übersteuert werden könnte und eine Konsistenz nicht garantiert werden könnte.
12 – Objekt-Nachschlage-Ablaufdiagramm
Ein Verfahren 200 für eine Nachschlageoperation an dem Objekt A beginnt mit dem Schritt 205 des Prüfens, ob eine Verbindung zu dem betreffenden Knoten besteht, beispielsweise zu dem Server, und Prüfen, ob ein „Gierig"-Bit gesetzt ist. Dieses Bit zeigt an, ob es wünschenswert ist, über die örtlich gepufferte Version des Objektes hinaus zu suchen, um eine aktuellere Kopie an anderer Stelle zu finden. Dieses Bit kann von einem Benutzer, durch eine Anwendung oder durch andere Teile der DPS gesetzt werden, beispielsweise, um die DPS dynamisch an sich ändernde Bedingungen anzupassen, beispielsweise eine Netzwerk-Überlastung. Wenn die Bedingungen bei 205 nicht erfüllt sind, so wird ein örtliches Nachschlageverfahren bei 225 aufgerufen. Anderenfalls wird die örtliche Kopie des Objektes A bei 215 betrachtet. Eine Zeitstempel- oder Versionsanzeige wird zu einem verbundenen benachbarten Knoten bei 235 gesandt, und Antworten werden bei 245 verarbeitet. Wenn die örtliche Kopie überholt ist, so wird ein örtliches Objektänderungsverfahren bei 255 aufgerufen. Anderenfalls wird dieser Schritt umgangen. Bei 265 wird festgestellt, ob alle verbundenen Nachbarn geantwortet haben. Wenn dies nicht der Fall ist, kann der Prozess wiederholt werden, bis alle geantwortet haben. Wenn keine aktuelleren Kopien gefunden werden, so führt dies dazu, dass ein Zugriff auf die örtliche Kopie ausgeführt wird. Unterbrechungen oder Fehler während der Operation führen ebenfalls, wie dies im Schritt 227 gezeigt ist, dazu, dass ein Zugriff auf die örtliche Kopie erfolgt. Anderenfalls wird die aktuellste Kopie bei 275 zurückgeliefert.
13 – Objektänderungs-Ablaufdiagramm
Ein Verfahren 300 für eine Änderungsoperation am Objekt A ist in 13 gezeigt und beginnt in ähnlicher Weise wie die Nachschlageoperation mit einem Prüfschritt 305 und einem Sperrschritt 315. Wenn die Bedingungen bei 305 nicht erfüllt sind, so wird ein örtliches Änderungsverfahren bei 325 aufgerufen. Es gibt weiterhin einen entsprechenden Schritt 335 des Sendens eines Zeitstempels an einen benachbarten Knoten, und Antworten werden bei 345 verarbeitet. Wenn die örtliche Kopie überholt ist, so wird ein örtliches Objektänderungsverfahren bei 355 aufgerufen. Anderenfalls wird dieser Schritt umgangen. Bei 365 wird festgestellt, ob alle verbundenen Nachbarn geantwortet haben. Wenn dies nicht der Fall ist, kann der Prozess wiederholt werden, bis alle geantwortet haben. Wenn keine aktuelleren Kopien gefunden werden, so führt dies zu einer Änderung der örtlichen Kopie im Schritt 325. Unterbrechungen oder Fehler während der Operation führen ebenfalls in der im Schritt 227 gezeigten Weise zu einer Rückkehr ohne Ändern der örtlichen Kopie. In jedem Fall kehrt das Verfahren bei 375 zurück.
14 – Ablaufdiagramm für örtliche Objektänderung
Ein Verfahren 400 zur örtlichen Änderung eines Objektes beginnt mit dem Sperren der örtlichen Kopie des Objektes A bei 415. Bei 425 wird das Objekt in der Datenbank durch das Objekt A' ersetzt. Der Zeitstempel oder die Version des Objektes A wird im Schritt 435 geändert, um die Zeit oder Version des Objektes A' wiederzugeben, ohne dass die aktuelle Zeit verwendet wird oder die Versionsnummer über die von A' hinaus vergrößert wird. Bei 445 wird A' in das Fach für unsaubere Objekte Hash-codiert, und die Sperrung von A wird bei 455 aufgehoben. Bei 465 kehrt das Verfahren zurück. Unterbrechungen oder Fehler während des Betriebs führen in der im Schritt 227 gezeigten Weise zu einer Rückkehr ohne Ändern der örtlichen Kopie.
15 – Ablaufdiagramm für die Erzeugung eines Objektes
Ein Verfahren 500 zum Erzeugen eines Objektes A beginnt mit einem Prüfschritt 505 ähnlich zu dem in der Nachschlageoperation. Wenn die Bedingungen bei 505 nicht erfüllt sind, so wird ein örtliches Erzeugungsverfahren bei 515 aufgerufen.
Anderenfalls wird ein örtlicher Zeitstempel für das neue Objekt mit der aktuellen Zeit bei 525 gesetzt. Es gibt weiterhin einen entsprechenden Schritt 535 des Sendens eines Zeitstempels an einen benachbarten Knoten, und Antworten werden bei 545 verarbeitet. Wenn ein weiterer Knoten das gleiche Objekt in der Zwischenzeit erzeugt hat, so wird kein neues Objekt erzeugt, und die entfernt angeordnete Kopie kann verwendet werden. Anderenfalls wird das Verfahren zur örtlichen Objektänderung bei 515 aufgerufen. Anderenfalls kehrt das Verfahren ohne die Erzeugung einer neuen Instanz zurück. Unterbrechungen oder Fehler während der Operation führen ebenfalls in der im Schritt 227 gezeigten Weise zu einer Rückkehr ohne Erzeugen einer neuen Instanz.
16 – Ablaufdiagramm für die örtliche Objekterzeugung
16 zeigt ein Verfahren 600 zur örtlichen Erzeugung eines Objektes A. Ein Zeitstempel für das Objekt wird als erstes bei 605 auf die aktuelle Zeit gesetzt. Eine Instanz des Objektes A wird als nächstes in der örtlichen Datenbank bei 615 erzeugt. Bei 625 wird das Objekt A in der örtlichen Datenbank gesperrt. Es wird in das Fach für unsaubere Objekte bei 356 Hash-codiert, bei 645 entsperrt und das Verfahren kehrt bei 655 zurück.
17 – Ablaufdiagramm für örtliches Löschen eines Objektes
17 zeigt ein Verfahren 700 zum örtlichen Löschen eines Objektes A. Eine Instanz des Objektes A wird als nächstes in der örtlichen Datenbank bei 615 erzeugt. Bei 705 wird das Objekt A in der örtlichen Datenbank gesperrt. Es wird aus der Datenbank bei 715 entfernt. Hash-Code-Einträge in dem Fach für unsaubere Objekte werden bei 725 entfernt, das Objekt wird bei 735 enssperrt, und das Verfahren kehrt bei 745 zurück.
18 – Ablaufdiagramm für das Löschen aller Objekte
Ein Verfahren 800 zum Löschen aller Objekte dient zum Löschen aller Kopien eines Objektes. Es beginnt mit einem Aufruf eines örtlichen Löschverfahrens bei 805. Eine Anforderung zum Löschen aller Objekte wird zu dem Fach für unsaubere Objekte bei 815 hinzugefügt, und das Verfahren kehrt zurück.
Ein Beispiel einer Anwendung
Eine Anwendung für ein personalisiertes Telefonverzeichnis kann verwendet werden, um die verteilten Aspekte der persistenten oder dauerhaften Speicherung zu zeigen, deren Inhalte örtlich gepuffert werden können. Weil die DPS so ausgelegt ist, dass sie sehr skalierbar ist, kann jeder Klient „Verbindungen oder Verknüpfungen" zu so vielen Klienten herstellen, wie es die Systemressourcen zulassen. Die Fähigkeit des Klienten, die Neusynchronisation anzustoßen, zeigt, dass diese DPS-Architektur mit einem Vorteil der bekannten Klienten/Server-Push- und Pull-Technologie übereinstimmt.
Das Telefonverzeichnis kann eine kleine spezielle Anwendung oder ein Applet sein, das unter einer Betrachter-Anwendung läuft. Jeder Benutzer kann sein eigenes Telefonverzeichnis oder seine eigenen Telefonverzeichnisse haben, das bzw. die durch den Benutzernamen identifiziert ist (sind). Telefoneinträge können hinzugefügt, gelöscht, modifiziert, sortiert und abgefragt werden. Eine Verbindung kann durch Drücken des Verbindungsknopfes simuliert werden. Eine derartige Anwendung ist insbesondere für die vorstehend beschriebene Neusynchronisationsstrategie geeignet, weil sie Daten handhabt, die schließlich konsistent sein müssen, und für die die Verfügbarkeit eine hohe Priorität aufweist, wobei jedoch der umgehende Zugang an die aktuellste entfernt liegende Information eine geringere Priorität hat.
Die bekannte auf einer zentralisierten Transaktion beruhende Strategie kann gegebenenfalls nicht für ultradünne Klienten-Knoten geeignet sein, weil das Zurückspielen langer Transaktionsprotokolle zurück zum Server von dem Klienten bei einer erneuten Verbindung, nicht gut arbeiten würde, wenn die Neuverbindungszeit kurz und kostspielig ist. Während des größten Teils der Zeit benötigt ein dünner mobiler Klient lediglich eine sehr einfache und leichte Daten-Neusynchronisation, um seine Datenkonsistenz aufrechtzuerhalten. In diesem Fall ist die verteilte Strategie der Erfindung vorteilhaft.
Ein Beispiel einer Klientenknoten-Hardware und von Verbindungsprotokollen für das Netzwerk
Das Klienten-Knoten-Gerät könnte ein Notebook-Computer sein, der beispielsweise auf einem 32-Bit-Prozessor mit beispielsweise 8 MB an Arbeitsspeicher beruht, in der Lage ist, auf Java beruhende Programme laufen zu lassen, und der eine drahtlose Zellulartelefon-Hardware für Daten und wahlweise Sprachkommunikation mit dem öffentlichen Telefonnetz und mit Internet-Diensteanbietern (ISP) oder mit Servern hat, die von dem Zellularnetz-Betreiber bereitgestellt werden, um beispielsweise Datendienste bereitzustellen. Ein Benutzer kann versuchen, einen Zugriff auf sein/ihr persönliches Telefonverzeichnis auf dem Zellulartelefon oder PCS (persönliches Kommunikationsgerät) durchzuführen. Ein Notebook-Computer kann eine Andock-Station für das drahtlose Telefon haben. Wenn das Telefon an dem Notebook-Computer angedockt ist, kann das Telefonverzeichnis des PCS seine Daten mit dem auf dem Notebook gespeicherten persönlichen Telefonverzeichnis neu zu synchronisieren. Wenn der Benutzer das Notebook in einen Bereich zurückbringt, in dem es seine Daten mit dem ISP über eine Funk-Basisstation synchronisieren kann, kann das Notebook das modifizierte persönliche Telefonverzeichnis mit dem Telefonverzeichnis synchronisieren, das auf dem Server gespeichert ist, und das von dem ISP unterhalten wird.
Andere Abänderungen
Ein Benachrichtigungsdienst kann hinzugefügt werden, um die Anwendung über Ergebnisse zu informieren. Eine Mischung von Transaktions-basierter und auf der letzten Modifikation basierter Synchronisation kann in dem vorstehend beschriebenen Rahmenwerk verwendet werden. Obwohl die Anmeldung unter Bezugnahme auf objektorientierte Daten beschrieben wurde, ist es verständlich, dass sie auf in anderer Weise gespeicherte Daten anwendbar ist. Obwohl mobile drahtlos verbundene Klientenknoten beschrieben wurden, ist es verständlich, dass die Vorteile der Erfindung auch auf andere Arten von Geräten anwendbar sind, beispielsweise Netzwerk-Computer, die periodisch über Telefon/Modem oder andere nicht drahtlose Strecken mit einem Netzwerk verbunden sind. Statt der vorstehend beschriebenen Anordnung eines Faches für unsaubere Objekte könnte die Information darüber, was geändert wurde, dadurch gewonnen werden, dass alle gepufferten Objekte betrachtet werden, erforderlichenfalls beispielsweise durch Vergleichen von Zeitstempeln mit der Zeit der letzten Neusynchronisation, obwohl dies unpraktisch sein kann, wenn es viele gepufferte Objekte gibt. Obwohl eine Verbindungstabelle geführt wird, ist es vorstellbar, den Verbindungszustand bei Bedarf ohne Führen einer Tabelle festzustellen.
Zusammenfassend ist festzustellen, dass die vorliegende Erfindung ein Verfahren zum Aufrechterhalten einer gegenseitigen Konsistenz zwischen Kopien von Daten bereitstellt, die an Knoten in einem Netzwerk gespeichert sind, wobei die Knoten einen Server-Knoten und eine Anzahl von Klienten-Knoten an entfernten Stellen umfassen, wie z. B. Laptop-Computer, die über Zellulartelefon-Verbindungen verbunden sind, wobei die Knoten intermittierend verbunden sind.
Nach einer erneuten Verbindung zwischen dem entfernt angeordneten Klienten-Knoten und einem anderen der Knoten werden Zeitstempel-Informationen an Objekten, die an dem anderen Knoten gepuffert sind, zu dem entfernt angeordneten Klienten-Knoten gesandt. An dem entfernt angeordneten Klienten-Knoten werden die Zeitstempel-Informationen mit entsprechenden Informationen bezüglich der örtlichen Kopie verglichen, um festzustellen, ob jedes der gepufferten Objekte aktueller als die örtliche Kopie ist. Die gepufferten Objekte werden auf der Grundlage der örtlichen Kopie entsprechend dem Ergebnis des Vergleichs aktualisiert. Diese Peer-zu-Peer-Neusynchronisation bedeutet, dass der Server den Prozess nicht überwachen und kontrollieren muss, so dass das System einfacher skalierbar ist, um mehr Klienten abzuwickeln.
Andere Abänderungen sowie die vorstehend erläuterten sind für den Fachmann ersichtlich und sollen nicht ausgeschlossen sein. Der Schutzumfang der beanspruchten Erfindung ist lediglich durch die Definitionen der Ansprüche beschränkt.

Claims

Verfahren zur Aufrechterhaltung einer gegenseitigen Konsistenz zwischen Kopien von Daten, die an Knoten in einem Netzwerk gespeichert sind, wobei die Knoten einen Server-Knoten (20) und eine Anzahl von Clienten-Knoten (30) an entfernt angeordneten Stellen umfassen, wobei die Knoten intermittierend miteinander verbunden werden, und die Clienten-Knoten Anwendungen aufweisen, die die Daten verwenden, wobei das Verfahren die Durchführung der folgenden Schritte an einem entfernt angeordneten der Clienten-Knoten umfasst: nach der Wiederherstellung einer Verbindung zwischen dem entfernt angeordneten Clienten-Knoten und einem anderen der Knoten, Empfangen von Information von diesem anderen Knoten, die sich auf einen Teil der Daten bezieht, von denen eine örtliche Kopie an dem anderen Knoten und eine entfernt angeordnete Kopie an dem entfernt angeordneten Clienten-Knoten vorliegt, wobei die Information zeigt, wie aktuell die örtliche Kopie ist; Vergleichen (152), an dem entfernt angeordneten Clienten-Knoten, der empfangenen Information, die sich auf die örtliche Kopie bezieht, mit entsprechender Information, die sich auf die entfernt angeordnete Kopie bezieht, um festzustellen, ob die entfernt angeordnete Kopie aktueller ist als die örtliche Kopie, und wenn der entfernt angeordnete Knoten feststellt, dass die entfernt angeordnete Kopie aktueller ist, Senden einer Kopie oder Einzelheiten der Unterschiede von dem entfernt angeordneten Knoten zu dem örtlichen Knoten (154), um es diesem zu ermöglichen, seine Kopie (156) zu aktualisieren, und wenn der entfernt angeordnete Knoten feststellt, dass die örtliche Kopie aktueller ist, Aktualisieren, an dem entfernt angeordneten Knoten, seiner eigenen Kopie (158) durch Anfordern der erforderlichen Information von dem örtlichen Knoten.
Verfahren nach Anspruch 1, das weiterhin den Schritt der Feststellung umfasst, ob der Inhalt der entfernt angeordneten Kopie der gleiche ist, wie der Inhalt der örtlichen Kopie, und Einleiten, an dem entfernt angeordneten Knoten, eines Konfliktauflösungsprozesses in dem Fall, in dem der Vergleich keine Differenz zwischen der Information, die anzeigt wie aktuell die örtliche Kopie ist und der entsprechenden Information zeigt, die sich auf die entfernt angeordnete Kopie bezieht, sich die jeweiligen Inhalte jedoch unterscheiden.
Verfahren nach Anspruch 1 oder 2, das weiterhin den vorangehenden Schritt umfasst, dass während einer Trennung der Verbindung aufgezeichnet wird, welche Teile an dem anderen Knoten modifiziert wurden, wobei die von dem entfernt angeordneten Clienten-Knoten empfangene Information sich auf die Teile bezieht, die von dem anderen Knoten als modifiziert aufgezeichnet wurden.
Verfahren nach Anspruch 3, bei dem der Vergleichsschritt für jeden der aufgezeichneten und während der Trennung der Verbindung modifizierten Teile ausgeführt wird, bevor der Vergleichsschritt für einen Teil ausgeführt wird, der nach der Wiederherstellung der Verbindung modifiziert wird.
Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin den Schritt der Sperrung der entfernt angeordneten Kopie zum Verhindern eines Zugriffs auf diese während des Vergleichsschrittes umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die an den Knoten gespeicherten Kopien der Daten eine Kopie von weniger als allen Elementen einer Datenbank umfassen, und bei dem die Daten objektorientierte Daten umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin den Schritt der Weiterleitung der aktuelleren Kopie von dem entfernt angeordneten Clienten-Knoten zu einem zweiten anderen Knoten umfasst, der ebenfalls eine Kopie des Teils der Daten hat, wenn eine Verbindung mit dem zweiten anderen Knoten hergestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der andere Knoten den Server-Knoten umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin die folgenden Schritte umfasst: Speichern, an dem entfernten Clienten-Knoten, einer Aufzeichnung von Transaktionen, die die entfernt angeordnete Kopie betreffen, vor dem Vergleichsschritt; und Rückgängigmachen zumindest einiger der Transaktionen in dem Fall, in dem von dem Vergleichsschritt festgestellt wird, dass die örtliche Kopie aktueller ist als die entfernt angeordnete Kopie.
Clienten-Knoten zur Verwendung in einem Netzwerk von Knoten, wobei Kopien von Daten an den Knoten gespeichert werden und einer der Knoten einen Server bildet, während andere der Knoten für andere Klienten an entfernt angeordneten Stellen bestimmt sind, wobei die Knoten intermittierend miteinander verbunden werden, und der Clienten-Knoten eine Anwendung aufweist, die die Daten verwendet, wobei der Clienten-Knoten folgendes umfasst: eine Verbindungs-Abwicklungs-Einrichtung, um nach der Wiederherstellung einer Verbindung zwischen dem Clienten-Knoten und einem anderen der Knoten, von dem anderen Knoten Informationen bezüglich eines Teils der Daten zu empfangen, von denen eine entfernt angeordnete Kopie an dem Clienten-Knoten und eine örtliche Kopie an dem anderen Knoten vorliegt, wobei die Information zeigt, wie aktuell die örtliche Kopie ist; einen Vergleicher zum Vergleich der empfangenen Informationen, die sich auf die örtliche Kopie beziehen, mit entsprechenden Informationen, die sich auf die entfernt angeordnete Kopie beziehen, um festzustellen, ob die örtliche Kopie aktueller ist als die entfernt angeordnete Kopie; und eine Datenabwicklungseinrichtung, um zu bewirken, dass, wenn der entfernt angeordnete Knoten feststellt, dass die entfernt angeordnete Kopie aktueller ist, der entfernt angeordnete Knoten eine Kopie oder Einzelheiten hinsichtlich der Unterschiede an den örtlichen Knoten (154) sendet, um es diesem zu ermöglichen, seine Kopie (156) zu aktualisieren, und wenn der entfernt angeordnete Knoten feststellt, dass die örtliche Kopie aktueller ist, der entfernt angeordnete Knoten seine eigene Kopie (158) durch Anfordern der erforderlichen Information von dem örtlichen Knoten aktualisiert.
Clienten-Knoten nach Anspruch 10, der weiterhin eine Überwachungseinrichtung zur Überwachung des Zustands von Verbindungen zu benachbarten Knoten umfasst.
Clienten-Knoten nach Anspruch 10 oder 11, der weiterhin eine Registratur zur Speicherung einer Anzeige darüber umfasst, welche Teile der Daten durch Knoten gespeichert werden, die dem Clienten-Knoten benachbart sind.
Clienten-Knoten nach einem der Ansprüche 10 bis 12, der weiterhin einen Prozessor zur Erzeugung und Speicherung einer Anzeige umfasst, ob die örtliche Kopie geändert wurde.