DE60312624T2 - Verfahren und Vorrichtung zur Konsistenzunterhaltung eines geteilten Raums über mehrere Endpunkte in einem gleichrangigen kollaborativen Computersystem - Google Patents

Verfahren und Vorrichtung zur Konsistenzunterhaltung eines geteilten Raums über mehrere Endpunkte in einem gleichrangigen kollaborativen Computersystem Download PDF

Info

Publication number
DE60312624T2
DE60312624T2 DE60312624T DE60312624T DE60312624T2 DE 60312624 T2 DE60312624 T2 DE 60312624T2 DE 60312624 T DE60312624 T DE 60312624T DE 60312624 T DE60312624 T DE 60312624T DE 60312624 T2 DE60312624 T2 DE 60312624T2
Authority
DE
Germany
Prior art keywords
delta
endpoint
deltas
log
endpoints
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
Application number
DE60312624T
Other languages
English (en)
Other versions
DE60312624D1 (de
Inventor
Ransom Beverly Richardson
Raymond E. Manchester Ozzie
Jack E. Chester Ozzie
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Groove Networks Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Groove Networks Inc filed Critical Groove Networks Inc
Publication of DE60312624D1 publication Critical patent/DE60312624D1/de
Application granted granted Critical
Publication of DE60312624T2 publication Critical patent/DE60312624T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99938—Concurrency, e.g. lock management in shared database

Description

  • Gebiet der Erfindung
  • Die Erfindung betrifft kollaborative Peer-to-Peer-Computersysteme, welche Kommando- und Datenblöcke direkt austauschen, um die Konsistenz eines geteilten Raumes zwischen den Kollaborateuren aufrechtzuerhalten.
  • Stand der Technik
  • Die Kollaboration umfaßt die Fähigkeit jeden Mitgliedes in einer Gruppe von Mitgliedern, „Kollaborateure" genannt, Informationen automatisch an andere Kollaborateure in der Gruppe zu übertragen und von diesen zu erhalten. Zum Vereinfachen einer solchen Kollaboration wurden verschiedene Systeme entwickelt, die es ermöglichen, daß solche Informationen zwischen PC-Systemen, Kommunikationsvorrichtungen oder anderen Kommunikationsgeräten, einschließlich Handheld- und Funk-Geräten, übertragen werden. In dieser Beschreibung werden diese Geräte zusammen als „Computer" bezeichnet.
  • Computerbasierte Kollaboration kann lokal zwischen Benutzern stattfinden, die mit einem Computer oder Server verbunden sind oder mit diesem arbeiten. Alternativ dazu kann die Kollaboration über ein Netz wie das Internet erfolgen, wobei sich jeder der Benutzer an einem Computer befindet, welcher mit dem Netz verbunden ist. Es kann auch ein Server mit dem Netz verbunden sein. Derzeit werden mehrere Kollaborationsmodelle als Netzcomputer-Kollaborationssysteme implementiert. Eines dieser Modelle ist ein Client-Server-Modell, bei dem alle Kollaborateure über das Netz mit einem Zentralserver verbunden sind. Die durch jeden Kollaborateur erzeugten Informationen werden über das Netz an den Server gesendet, welcher dann die Informationen über das Netz zurück an jeden anderen Kollaborateur überträgt. Ein weiteres Modell ist ein „Peer-to-Peer"-Modell, bei dem über das Netz direkte Verbindungen zwischen allen Kollaborateurcomputern aufgebaut werden. Die von jedem Kollaborateur erzeugten Informationen werden dann direkt an jeden anderen Kollaborateur gesendet. Bei einem solchen System kommunizieren die Kollaborateure in einem privaten „virtuellen" geteilten Raum.
  • Bei beiden dieser Modelle gibt es mehrere Verfahren, mittels welcher die Informationen zwischen Kollaborateuren übertragen werden. Zum Beispiel können bei einem Client-Server-System Daten, die kollaborativ modifiziert werden, auf dem Server gespeichert werden. Dann sendet jeder Kollaborateur, der die Daten modifizieren möchte, ein Kommando an den Server, um eine Änderung der Serverdaten zu bewirken. Der Server modifiziert seine Kopie der Daten und sendet dann Informationen, die eine „Ansicht" der modifizierten Daten darstellen, an alle Kollaborateure, so daß jeder Kollaborateur die Daten lokal anzeigen kann.
  • Ein zentraler Datenspeicher ist bei einem Peer-to-Peer-Kollaborationssystem nicht möglich, weil kein Kollaborateur als ein Server agiert. Somit weist bei solchen Systemen jeder Kollaborateur eine lokale Kopie der kollaborativ modifizierten Daten auf. Zum Ändern der Daten erzeugt ein Kollaborateur eine Datenänderungsanforderung, die an jeden anderen Kollaborateur weitergeleitet wird. Die eingehenden Datenänderungsanforderungen werden dann von jedem Kollaborateur zum Modifizieren seiner lokalen Datenkopie verwendet.
  • Der letztgenannte Typ des Kollaborationssystems ist detailliert beschrieben in WO 01/06365 A2 „METHOD AND APPARATUS FOR ACTIVITY-BASED COLLABORATION BY A COMPUTER SYSTEM EQUIPPED WITH A COMMUNICATION MANAGER", WO 01/06361 A2 „METHOD AND APPARATUS FOR ACTIVITY-BASED COLLABORATION BY A COMPUTER SYSTEM EQUIPPED WITH A DYNAMICS MANAGER" und WO 01/06364 A2 „METHOD AND APPARATUS FOR PRIORITIZING DATA CHANGE REQUESTS AND MAINTAINING DATA CONSISTENCY IN A DISTRIBUTED COMPUTER SYSTEM EQUIPPED FOR ACTIVITY-BASED COLLABORATION" und WO 01/95155 A2 „METHOD AND APPARATUS FOR EFFICIENT MANAGEMENT OF XML DOCUMENTS".
  • Bei diesem Kollaborationssystem besitzt jeder Kollaborateur ein Programm, „Aktivität" genannt, welches auf seinem oder ihrem Computer läuft. Das Aktivitätsprogramm enthält ein Werkzeug, welches auf Benutzerinteraktionen durch das Erzeugen von Datenänderungskommandos reagiert. Diese Datenänderungskommandos werden einer Datenänderungsvorrichtung bereitgestellt, welche die lokale Datenkopie durch die Durchführung der Änderungen an den Daten angefordert durch die Datenänderungskommandos pflegt. Die Kommandos werden in ein Behältnis, „Delta" genannt, eingefügt, und Deltas werden von einem Kollaborateur zum anderen durch ein Programm, Kommunikationsmanager genannt, verteilt.
  • Wenn ein Peer-to-Peer-Kollaborationssystem über ein Netz verwendet wird, sind spezielle Überlegungen anzustellen. Eine Hauptüberlegung ist die Netzlatenz. Insbesondere wenn ein Delta über das Netz an eine Gruppe anderer Kollaborateure übertragen wird, kann es aufgrund ungleicher Übertragungszeiten über das Netz einige Kollaborateure früher erreichen als andere. Da alle Kollaborateure Deltas „asynchron" senden und empfangen, können die Anforderungen durch unterschiedliche Kollaborateure in unterschiedlicher Reihenfolge empfangen werden. Dies kann potentiell ein Problem verursachen, weil die korrekte Ausführung einiger Kommandos von anderen Kommandos abhängen kann, die vorausgehend ausgeführt wurden. Um sicherzustellen, daß die lokalen Datenkopien konsistent bleiben, muß das Kollaborationssystem Kausalität wahren. Insbesondere fordert die Kausalität, daß, wenn ein aktuelles Datenänderungskommando empfangen von einem ersten Kollaborateur durch einen zweiten Kollaborateur ausgeführt wird, der zweite Kollaborateur alle vorausgehenden Datenänderungskommandos ausgeführt hat, die der erste Kollaborateur bereits ausgeführt hatte, als das aktuelle Datenänderungskommando erzeugt wurde.
  • Eine weitere Bedingung, die erfüllt sein muß, ist Konvergenz. Konvergenz stellt sicher, daß, wenn alle Kollaborateure den gleichen Satz von Operationen ausgeführt haben, die abschließende Ausführungsreihenfolge der Datenänderungskommandos durch alle Kollaborateure die gleiche ist. Bei dem in den zuvor genannten Patentanmeldungen beschriebenen Kollaborationssystem empfängt und interpretiert ein Spezialprogramm, Dynamikmanager genannt, in jedem Computer die Deltas erzeugt in diesem Computer und empfangen durch diesen Computer von anderen Computer zum Wahren der Kausalität und zum Sicherstellen der Konvergenz.
  • Ein weiteres potentielles Problem bei einem Peer-to-Peer-System betrifft Kollaborateure, die während einer andauernden Sitzung in die Kollaborationsgruppe eintreten und diese wieder verlassen, indem sie ihre Computer vom Netz trennen oder die Computer herunterfahren. Da die Integrität der lokalen Datenkopie eines Kollaborateurs abhängig ist vom Empfang von Datenänderungskommandos von anderen Kollaborateuren und der korrekten Interpretation dieser Kommandos, benötigen Kollaborateure, die eine Kollaborationssitzung verlassen, entweder eine komplette aktuelle Kopie der lokalen Daten oder eine Sammlung von Datenänderungskommandos, die während ihrer Abwesenheit von anderen Kollaborateuren übertragen wurden, um ihr System neu zu starten. In vielen Fällen kann die Kopie der lokalen Daten und die Sammlung von Datenänderungskommandos recht groß sein, was zu einer übermäßig langen Startverzögerung für einen Kollaborateur führen kann, der in eine andauernde Kollaborationssitzung eintritt.
  • Die oben zitierte Internationale Patentanmeldung WO 01/06364 A2 offenbart ein dezentrales aktivitätsbasiertes Kollaborationssystem, bei welchem Datenänderungsanforderungen, welche Deltas umfassen, über ein Netz zwischen netzfähigen Geräten, auch Endpunkte genannt, kommuniziert werden. Dieses System verwendet ein Prioritätsschema für Datenänderungsanforderungen zum Bestimmen einer Reihenfolge der Ausführung von Datenänderungsanforderungen beim Bewirken von Änderungen an lokalen Kopien von Daten zum Optimieren der Datenkonsistenz bei kollaborativen Aktivitäten. Das Prioritätsschema für Datenänderungsanforderungen umfaßt das Codieren der Datenänderungsanforderungen mit Anforderungsfolgenummern und einem Identifikator, welcher den Eigenschaften der netzfähigen Geräte entspricht, welche die Anforderung erzeugt haben. Ferner umfaßt das Prioritätsschema für Datenänderungsanforderungen das Codieren der Datenänderungsanforderungen mit einem Abhängigkeitsidentifikator, welcher eine Datenänderungsanforderung spezifiziert, von der die codierte Datenänderungsanforderung abhängt. Als Reaktion auf den Abhängigkeitsidentifikator können Datenänderungen an den Daten vorgenommen, rückgängig gemacht und erneut vorgenommen werden. Das System umfaßt in jedem der netzfähigen Geräte eine Datenänderungsvorrichtung, welche mit einem lokalen Speicher gekoppelt ist und auf eine Vielzahl von Datenänderungsanforderungen zum Steuern der Speicherung der lokalen Kopie der Daten im lokalen Speicher reagiert, sowie einen Dynamikmanager, welcher mit der Datenänderungsvorrichtung gekoppelt ist und auf die Datenänderungsanforderungen zum Steuern der Datenänderungsvorrichtung und zum Koordinieren der Ausführung der Datenänderungsanforderungen reagiert. Zu diesem Zweck pflegt der Dynamikmanager ein Deltaprotokoll, bei welchem es sich um eine Aufzeichnung aller Deltas ausgeführt durch das netzfähige Gerät und eine Vektoranordnung zum Spezifizieren der höchsten Folgenummer von Deltas, welche durch das lokale Gerät erzeugt oder von anderen Geräten empfangen wurden, handelt. Die Vektoranordnung speichert einen Endpunktidentifikator, eine dem Endpunkt entsprechende Folgenummer aller Deltas empfangen von allen Endpunkten und den Abhängigkeitsidentifikator.
  • Kurzfassung der Erfindung
  • Die Erfindung stellt Verbesserungen dieses bekannten Systems bereit und betrifft ein System und ein Verfahren zum Aufrechterhalten der Konsistenz eines geteilten Raumes über eine Vielzahl von Endpunkten in einem kollaborativen Computersystem. Das kollaborative Computersystem gemäß der Erfindung, wie in den Ansprüchen definiert, umfaßt in jedem Endpunkt einen Mechanismus, welcher den Einsetzungspunkt eines Deltas in das Deltaprotokoll bestimmt, so daß das Deltaprotokoll Ketten von Deltas enthält, wobei jede Kette Deltas von einem Endpunkt in der Reihenfolge der Erzeugung aufweist. Die Ketten sind organisiert in Gruppen von Ketten von unterschiedlichen Endpunkten und die Gruppen sind basierend auf der Zeit des Empfangs der Deltas innerhalb der Gruppe geordnet.
  • Gemäß der Grundlagen der Erfindung ist die Deltaprotokoll-Datenstruktur in Blöcken organisiert und die Blöcke enthalten wiederum Gruppen, Gruppen enthalten Ketten und Ketten enthalten Deltas. Deltablöcke werden verwendet, um Prioritätsdeltas zu implementieren, die verwendet werden, um die Sammlung von Datenänderungskommandos einzuschränken, die zu übertragen sind. Innerhalb eines Blocks sind die Deltas nach Gruppen organisiert, von denen jede ein Satz von Deltas organisiert in Ketten ist. Die Deltagruppe wird verwendet, um zu bestimmen, welche Deltas zu eliminieren sind. Die Ketten sind nach ansteigender Erzeuger-ID des Endpunktes geordnet, welcher die Kette erzeugt hat. Das Organisieren des Deltaprotokolls auf diese Art und Weise hält die Deltas auf allen Endpunkten in einer konsistenten Reihenfolge. Dies macht es möglich, das Deltaprotokoll „abzuschreiten", um Konvergenz auf allen Endpunkten zu erreichen.
  • Zum Erreichen der Kausalitätserhaltung besitzt jedes Delta eine Liste von Abhängigkeiten, welche andere Deltas darstellen, die auszuführen sind, bevor das aktuelle Delta ausgeführt werden kann. Der Dynamikmanager nutzt die Fähigkeit zum Vornehmen (Ausführen) und Rückgängigmachen von Kommandos zum Durchführen von Wiederholungs- und Überspringen-Operationen an Deltas, um Konvergenz zu erreichen.
  • Um zu verhindern, daß das Deltaprotokoll zu groß wird, verwendet eine Eliminierungstechnik gemäß der Grundlagen der Erfindung Endpunktimpulse zwischen den Endpunkten in einem geteilten Raum übertragen. Jeder Endpunkt beinhaltet in einem Endpunktimpulse Informationen, welche eine Deltagruppe identifizieren, zu deren Eliminierung er bereit ist (basierend auf der höchsten Gruppe, deren Empfang jeder Endpunkt quittiert hat). Dann eliminieren alle Endpunkte Deltas in Gruppen ausgewählt durch Vergleichen der Gruppen, für welche die Endpunkte erklärt haben, daß sie zu deren Eliminierung bereit sind.
  • Gemäß einer weiteren Ausführungsform werden spezielle Deltas, Prioritätsdeltas genannt, verwendet, um die Ausführungsreihenfolgebildung unabhängiger Deltas zu steuern. Zum Beispiel kann ein Delta, welches einen Endpunkt in einen geteilten Raum einlädt, ein Prioritätsdelta sein, so daß Deltas, die von dem einladenden Delta unabhängig sind, keine Wiederholung verursachen, die zum Erreichen von Konvergenz notwendig ist, und daher ist es nicht notwendig, den Inhalt des gesamten Deltaprotokolls an einen neuen eingeladenen Endpunkt zu senden.
  • Gemäß noch einer weiteren Ausführungsform werden spezielle Deltas, asynchrone Deltas genannt, verwendet, um große Dateien zu übertragen, ohne die Übertragung anderer Deltas während des Datenübertragungsprozesses zu blockieren. Asynchrone Deltas sind so angeordnet, daß es keine anderen Deltas gibt, die von ihnen abhängig sind. Dementsprechend müssen Endpunkte nicht warten, bis das Verarbeiten eines asynchronen Deltas abgeschlossen ist, um weitere Deltas zu übertragen.
  • Gemäß noch einer weiteren Ausführungsform werden bleibende Daten gespeichert, welche den Zustand aller Endpunkte im geteilten Raum darstellen. Deltas werden nur an aktive Endpunkte gesendet, und die Verarbeitung eingehender Deltas ist abhängig vom Zustand des Endpunktes, welcher das Delta gesendet hat. Diese Zustande unterstützen die Implementierung von Mitgliedschaftsveränderungen, wie Einladen und Ausladen, in einer dezentralen und sicheren Art und Weise. Außerdem ist es möglich, einen inaktiven Endpunkt im geteilten Raum zu suspendieren, um zuzulassen, daß Teile des Deltaprotokolls eliminiert werden.
  • Kurzbeschreibung der Zeichnungen
  • Die obengenannten und weiteren Vorteile der Erfindung sind möglicherweise unter Verweis auf die folgende Beschreibung in Verbindung mit den beiliegenden Zeichnungen besser verständlich, wobei:
  • 1 ein schematisches Blockdiagramm eines veranschaulichenden Kollaborationssystems des Standes der Technik ist, in dem die Erfindung verwendet werden kann.
  • 2 ein detaillierteres schematisches Blockdiagramm eines veranschaulichenden Computersystems des Standes der Technik ist, auf dem Kollaborationssoftware läuft, die verwendet wird, um das in 1 gezeigte System zu implementieren.
  • 3A und 3B zusammengenommen ein Flußdiagramm bilden, welches die Schritte bei der Verarbeitung eines Deltas auf dem Endpunkt, welcher das Delta gemäß der Grundlagen der Erfindung erzeugt hat, veranschaulicht.
  • 4 ein schematisches Blockdiagramm ist, welches die Hauptkomponenten des Dynamikmanagers veranschaulicht, welche an der Erzeugungs-, Übertragungs- und Empfangsverarbeitung von Deltas beteiligt sind.
  • 5 ein Diagram ist, welches eine XML-Datenstruktur veranschaulicht, welche ein typisches Delta mit einem Datenänderungskommando und ohne Rückgängigmachen-Informationen darstellt.
  • 6 ein Diagram ist, welches die XML-Datenstruktur veranschaulicht, welche ein typisches Delta mit zwei Datenänderungskommandos und Rückgängigmachen-Informationen für beide Kommandos darstellt.
  • 7 ein Diagramm ist, welches die Struktur eines bleibenden XML-Dokumentes veranschaulicht, welches Deltas und Deltaverarbeitungsstrukturen in einem Dynamikmanager darstellt.
  • 8A und 8B zusammengenommen ein Diagramm einer XML-Datenstruktur eines Deltas bilden, welche zwei erzeugungsverschachtelte Deltas darstellt, von denen beide Rückgängigmachen-Informationen aufweisen.
  • 9A und 9B zusammengenommen ein Diagramm einer XML-Datenstruktur eines Deltaprotokolls bilden, welches die Deltas während der Verarbeitung enthält.
  • 10A und 10B zusammengenommen ein Flußdiagramm bilden, welches die Schritte bei einem Prozeß zum Empfangen und Verarbeiten eines Deltas an einem Endpunkt veranschaulicht.
  • 11A und 11B zusammengenommen ein Flußdiagramm bilden, welches die Schritte bei einem Prozeß zum Assimilieren eines neuen Deltas veranschaulicht.
  • 12 ein Diagramm ist, welches eine XML-Datenstruktur eines Deltahalters zeigt, welcher Deltas während der Verarbeitung enthält.
  • 13 ein Flußdiagramm ist, welches die Schritte eines veranschaulichenden Prozesses zum Einschränken des übermäßigen Holens während der Verarbeitung eines Deltas zeigt.
  • 14A und 14B zusammengenommen ein Diagramm bilden, welches eine XML-Datenstruktur zum Speichern von Endpunktinformationen darstellt.
  • 15A und 15B zusammengenommen ein Flußdiagramm bilden, welches die Schritte bei einem Prozeß zum Ausführen eines neuen Deltas veranschaulicht.
  • 16 ein Diagramm ist, welches eine veranschaulichende XML-Datenstruktur eines Identität-Verbreitet-Deltas zeigt.
  • 17 ein Flußdiagramm ist, welches die Schritte eines veranschaulichenden Prozesses zum Assimilieren von Prioritätsdeltas zeigt.
  • 18 ein Flußdiagramm ist, welches die Schritte eines veranschaulichenden Prozesses zum Eliminieren von Deltaprotokollen zeigt.
  • 19 ein schematisches Diagramm ist, welches Endpunkt-Zustände und Übergänge zwischen den Endpunkt-Zuständen für einen Endpunkt darstellt.
  • Detaillierte Beschreibung
  • 1 veranschaulicht in sehr schematischer Form ein Peer-to-Peer-Kollaborationssystem 100, bei welchem kollaborierende Computer durch ein Netz 110 wie das Internet miteinander verbunden sind. Obwohl bei diesem System verschiedene Netze verwendet werden können, wird in der nachfolgenden Diskussion das Netz 110 als das Internet angenommen. Bei diesem System bestehen die kollaborierenden Computersysteme aus den Peer-Einheiten 102–108, und Kommunikationen über das Internet 110 können von einem Peer zu einem anderen gerichtet sein, ohne Zwischengeräte. Jeder Peer-Einheit 102–108 kann als ein PC oder eine andere Form eines netzfähigen Gerätes, wie eine Set-Top-Box oder ein Handheld-Gerät, implementiert sein.
  • Peer-to-Peer-Kommunikationen können direkt zwischen Peer-Einheiten erfolgen. Zum Beispiel kann die Peer-Einheit 102 direkt mit den Peer-Einheiten 104, 106 und 108 kommunizieren, wie schematisch durch die gepunkteten Links 112, 116 bzw. 114 angegeben. In einer ähnlichen Art und Weise kann die Peer-Einheit 104 mit den Einheiten 108 und 106 über die Verbindungen 120 bzw. 118 verbunden sein. Und schließlich können die Einheiten 106 und 108 über die Verbindung 122 kommunizieren. Ein Kollaborationssystem wie das in 1 gezeigte ist erhältlich von Groove Networks, Inc., 100 Cummings Center, Suite 535Q, Beverly, Massachusetts 01915 und ist im GrooveTM Plattform Development Kit detailliert beschrieben, welches von Groove Networks, Inc. und online unter http://www.groove.net erhältlich ist. In der nachfolgenden Diskussion wird das Kollaborationssystem als ein solches System angenommen. Jedoch dürfte dem Fachmann auf dem Gebiet klar sein, daß auch andere Kollaborationssysteme mit der vorliegenden Erfindung verwendet werden können.
  • Bei diesem Kollaborationssystem befindet sich ein Programm, „Aktivität" genannt, in jedem kollaborierenden Computersystem, Kommunikationsgerät oder anderen netzfähigen Gerät. Die Aktivität ermöglicht es, eine geteilte, fokussierte Aufgabe (Task), wie zum Beispiel einen „Chat", Spiele oder Geschäftsanwendungen, in Kollaboration mit anderen entfernten Kollaborateuren durchzuführen. Diese Kollaboration beinhaltet geteilte und gemeinsame Aktivitäten zwischen Einzelpersonen und kleinen Gruppen in privaten geteilten Räumen. Jeder geteilte Raum ist eine konkrete Darstellung einer oder mehrerer Aktivitäten, die auf jedem der kollaborierenden Computer von Mitgliedern dieses geteilten Raumes betriebfähig sind.
  • Bei dem System greifen Teilnehmer oder Mitglieder eines geteilten Raumes auf das System zu, indem sie „Konten" eröffnen, die mit „Endpunkten" in Zusammenhang stehen. Da ein einzelner Kollaborateur über mehr als ein Gerät auf das System zugreifen kann, ist ein Endpunkt als eine einmalige Kombination einer Einzelperson und eines Gerätes definiert. Jeder Endpunkt speichert eine einzelne, lokale Kopie der Daten des geteilten Raumes.
  • Jede Aktivität umfaßt ein oder mehrere Werkzeuge, von denen jedes mit einem Kollaborateur interagiert, zum Beispiel durch das Empfangen von Maus- und Tastaturereignissen, und initiiert Datenänderungsanforderungen als Antwort auf die Interaktionen. Diese Datenänderungsanforderungen werden lokal verwendet und an andere Mitglieder des geteilten Raumes gesendet. Jede Aktivität umfaßt auch eine oder mehrere Datenänderungsvorrichtungen getrennt von den Werkzeugen, zum Pflegen der lokalen Kopie der Daten des geteilten Raumes gemäß eines gemeinsamen Datenmodells. Das Datenmodell ist zum Beispiel aktivitätsspezifisch und ist bevorzugt das gleiche über alle Mitglieder des geteilten Raumes hinweg. Jeder kollaborierende Computer umfaßt auch einen Dynamikmanager, welcher Datenänderungsanforderungen, die lokal erzeugt wurden und anderen Mitgliedern des geteilten Raumes empfangen wurden, prüft, die Ausführung der lokalen und anderer Datenänderungsanforderungen koordiniert und die Datenänderungsvorrichtung steuert, die angeforderten Änderungen an der lokalen Kopie der Daten vorzunehmen.
  • 2 zeigt die interne Architektur 200 des Kollaborationssystems wie auf einer der Peer-Einheiten 102–108, wie zum Beispiel Peer-Einheit 102, implementiert, detaillierter. Das Kollaborationssystem auf der Peer-Einheit 102 umfaßt einen Rahmen 202, mindestens einen geteilten Raum 204, der eine oder mehrere Aktivitäten 205 umschreibt, und eine Benutzerschnittstelle 206.
  • Der Rahmen 202 kann eine Plattform für die Wartung einer Reihe geteilter Räume bereitstellen, von denen der geteilte Raum 204 gezeigt ist. Der Rahmen 202 ist bevorzugt eine modulare Konstruktion mit einer Anwendungsprogrammierungsschnittstelle (application programming interface – API), auf der die Aktivitäten laufen und durch welche diese mit den Rahmenkomponenten kommunizieren. Der Rahmen 202 umfaßt einen Benutzerschnittstellenmanager 208, einen Identitätsmanager 210, einen Manager für den geteilten Raum 212, einen Aktivitätsmanager 214, einen Speichermanager 216, einen Dynamikmanager 220 und einen Kommunikationsmanager 222.
  • Der Benutzerschnittstellen-(user interface – UI)Manager 208 ist verantwortlich für das Verwalten geteilter Dienste für eine Reihe von Benutzerschnittstellen-Controllern (nicht separat gezeigt). Der UI-Manager 208 verwaltet das graphische Layout von Aktivitätsbildschirmanzeigen innerhalb von Feldern eines Anzeigefensters, und ansonsten stellt er ein gewünschtes „Aussehen und Gefühl” für die Benutzerschnittstelle bereit. Der UI-Manager 208 verwaltet auch die Aktivitätsnavigation (zum Beispiel „Gehe zu", „Nächstes", „Vorhergehendes" usw.) und pflegt die Navigationsgeschichte.
  • Der Identitätsmanager 210 ist verantwortlich für das Pflegen einer „Identität" für jedes Mitglied des geteilten Raumes. Eine Identität ist der Name und eine entsprechende Internetadresse (uniform resource locator – URL), unter welcher jeder Benutzer bei anderen bekannt ist. Einzelne Benutzer können eine oder viele Identitäten haben. Der Identitätsmanager 210 pflegt eine Aufzeichnung oder Tabelle im lokalen Speicher der Identitäten. Der Identitätsmanager 210 kann auch eine Aufzeichnung oder Tabelle von URLs für die Mitglieder des geteilten Raumes und ihre entsprechenden Geräte-URLs pflegen. Alternativ dazu kann ein separater Mitgliedsmanager implementiert werden.
  • Der Manager des geteilten Raumes 212 ist verantwortlich für das Verwalten jedes der geteilten Räume 204, die auf der Peer-Einheit 102 geöffnet sein können. Jeder geteilte Raum 204 ist eine konkrete Darstellung von einer oder mehreren Aktivitäten. Jeder geteilte Raum 204 besitzt einen entsprechenden Aktivitätsmanager 214.
  • Jeder Aktivitätsmanager 214 ist verantwortlich für (a) das Hinzufügen neuer Aktivitäten zu einem geteilten Raum, (b) das Öffnen bestehender Aktivitäten in einem geteilten Raum und (c) das Aktualisieren von Aktivitäten des geteilten Raumes. Jede Aktivität ist definiert durch eine Aktivitäts-„Vorlage", welche die Anfangsaktivitätskonfiguration für einen geteilten Raum definiert, und ist eine bleibende Darstellung des Werkzeugs und der Vorrichtungskomponenten, welche die Aktivität umfassen. Zum Erzeugen einer Aktivitätsvorlage kann ein Softwareentwickler ein Werkzeug schreiben oder ein/e bestehende/s Werkzeug und Vorrichtung für die Verwendung innerhalb des Rahmens anpassen. Zum Beispiel kann eine Aktivitätsvorlage als eine eingeschweißte Software vertrieben oder über das Internet von einem entfernten Server zur Peer-Einheit 102 heruntergeladen werden. Die Aktivitätskomponenten können als Web-Dokumente angesehen werden, und sie werden bleibend über URLs dargestellt. Die Aktivitätsvorlage selbst besitzt bevorzugt eine URL, welche das Verfolgen von Aktivitätsdesignänderungen ermöglicht. Die Aktivitätsvorlage kann eine einzelne Aktivitätsvorlage oder eine Aktivitätssammlungsvorlage sein. Eine einzelne Aktivitätsvorlage betrifft nur eine Aktivität, wie einen „Chat". Eine Aktivitätssammlungsvorlage betrifft eine Sammlung von Aktivitäten, wie „Chat und Übersicht".
  • Zum Hinzufügen einer neuen Aktivität wird dem Aktivitätsmanager 214 durch die oben beschriebenen Mittel die URL einer Vorlage für die neue Aktivität bereitgestellt. Zum Öffnen der neuen Aktivität oder einer bestehenden Aktivität öffnet der Aktivitätsmanager die Vorlage, extrahiert die Vorlageninformationen (wie Komponenten-URLs) und verbreitet die Information in den geteilten Raum. Ein Kollaborateur kann bei Bedarf zusätzliche Aktivitäten zum geteilten Raum 204 hinzufügen. Nach dem Hinzufügen ist eine Aktivität „Teil des" geteilten Raumes und sichtbar für alle Mitglieder des geteilten Raumes, und jedes Mitglied des geteilten Raumes besitzt eine Aktivitätsvorlage für den geteilten Raum, die auf seiner oder ihrer Peer-Einheit zur Verfügung steht.
  • Jeder geteilte Raum, wie der geteilte Raum 204, weist ein Tag zum Identifizieren seines entsprechenden Aktivitätsmanagers 214 und zum Binden des Aktivitätsmanagers mit Daten in Zusammenhang mit der Aktivität auf. Bevorzugt befinden sich die Daten in einem Dokument im lokalen Speicher und jedes Dokument besitzt ein lokales Register, welches damit über die Tag-Namen verlinkt ist, die im Register gepflegt werden, um eine Abbildung (Referenzzeiger oder Assoziationen) in einer erweiterbaren, plattformunabhängigen Art und Weise zwischen dem Dokument und seinem entsprechenden geteilten Raum auszudrücken.
  • Jede Aktivität, wie die Aktivität 205, umfaßt ein Werkzeug, wie das Werkzeug 224, und eine Vorrichtung, wie die Vorrichtung 226. Das Werkzeug 224 zusammen mit der Benutzerschnittstelle 206 erlauben es einer Aktivität, mit einem Kollaborateur zu interagieren. Zum Beispiel kann das Werkzeug Benutzerschnittstellenereignisse, wie Tastatur- oder Mausereignisse, empfangen, die erzeugt werden, wenn der Benutzer mit der Benutzerschnittstelle 206 interagiert. Als Antwort auf solche Benutzerschnittstellenereignisse kann das Werkzeug 224 Datenänderungsanforderungen an seine entsprechende Vorrichtung 226 stellen. Das Werkzeug 224 implementiert auch APIs für das Interagieren mit Hintergrunddiensten.
  • Die Vorrichtung 226 ist verantwortlich für das Pflegen und Ändern der Daten, welche den geteilten Raum 204 unterstützen und/oder aus einer Benutzerinteraktion erhalten durch das Werkzeug 224 resultieren. Sie reagiert auf Datenänderungsanforderungen vom Werkzeug 224 mit dem Zurücksenden von Kommandos an das Werkzeug 224, die notwendig sind, um die Datenänderungsanforderungen zu implementieren. Unter der Anleitung und Kontrolle des Dynamikmanagers 220, kann die Vorrichtung 226 Änderungen an der Datenkopie des geteilten Raumes vornehmen, welche lokal unter Kontrolle des Speichermanagers 216 gespeichert ist. Wenn diese Änderungen vorgenommen werden, erzeugt die Vorrichtung 226 asynchron Datenänderungsbenachrichtigungen. Das Werkzeug 224 kann sich bei der Vorrichtung 226 anmelden, um diese Datenänderungsbenachrichtigungen zu erhalten, damit das Werkzeug 224 die Benutzerschnittstelle asynchron aktualisieren kann, wenn die Datenänderungen erfolgen.
  • Der Dynamikmanager 220 empfangt lokale Datenänderungskommandos vom Werkzeug 224 und empfängt Datenänderungskommandos von anderen kollaborierenden Computer über den Kommunikationsmanager 222 von einer Netzverbindung 228. Diese Kommandos können für die Übertragung zwischen Kollaborateuren verschlüsselt sein und der Dynamikmanager 220 kann den Sicherheitsmanager 230 verwenden, um die Kommandos zu entschlüsseln. Der Dynamikmanager 220 trifft Entscheidungen darüber, welche Kommandos zu implementieren sind, um die Synchronisation unter allen Kollaborateuren aufrechtzuerhalten, und leitet diese Kommandos an die Vorrichtung 226 weiter, um die Vorrichtung 226 zu veranlassen, Änderungen an der lokalen Datenkopie vorzunehmen.
  • Während des Betriebs erhält das kollaborative System 200 die Identität eines Mitglieds vom Identitätsmanager 210 und öffnet einen Manager für den geteilten Raum 212. Das System 200 fordert dann an, daß der Manager des geteilten Raumes 212 einen geteilten Raum identifiziert durch eine URL öffnet und einen Aktivitätsmanager 214 erzeugt. Nach dem Erzeugen öffnet der Aktivitätsmanager 214 eine Aktivität, üblicherweise durch Verwendung der URL der Aktivität zu Identifizieren der Aktivität. Dann ist das Kollaborationssystem 200 zum Verwenden des geteilten Raumes durch Mitglieder bereit, um die geteilten, fokussierten Aufgaben angeboten durch die bestimmte Aktivität durchzuführen.
  • Wie bereits zuvor erwähnt werden Datenänderungsanforderungen erzeugt durch die Vorrichtung 226 in einem „Delta" genannten Behältnis plaziert, welches verwendet wird, um die Datenänderungsanforderungen an andere Kollaborateure zu senden. Bei dem veranschaulichenden Kollaborationssystem ist ein Delta eine atomische Änderungseinheit in einem geteilten Raum und es ist die einzige Möglichkeit, Änderungen des geteilten Raumes vorzunehmen, welche eine Vielzahl von Endpunkten betreffen. Der Dynamikmanager 220 in jedem Endpunkt ist verantwortlich für das Sicherstellen, daß die Datenänderungskommandos in jedem Delta korrekt ausgeführt werden, so daß die Reihenfolgebildung der Datenänderungskommandos auf einer Vielzahl von Endpunkten in einem geteilten Raum konsistent ist. Um dies zu tun, arbeitet der Dynamikmanager 220 mit verschiedenen Vorrichtungen 226 zum Ausführen und „Rückgängigmachen" von Datenänderungskommandos.
  • Der Dynamikmanager stellt eine Reihe von Rahmen bereit, welche verschiedene Dienste handhaben, die notwendig sind, um die zuvor erwähnte Kausalitätserhaltung und Konvergenz sicherzustellen. Zu den Rahmen zählen ein Kommandoausführungsrahmen, eine Empfehlungsrahmen, ein Verteilungsrahmen und ein Deltaprotokollmanagementrahmen.
  • Zum Erreichen der Kausalitätserhaltung weist jedes Delta eine Liste von Abhängigkeiten auf, die andere Deltas darstellen, welche ausgeführt werden müssen, bevor das aktuelle Delta ausgeführt werden kann. Der Dynamikmanager verwendet die Fähigkeit zum Vornehmen (Ausführen) und Rückgängigmachen von Kommandos zum Durchführen von Wiederholungs- und Überspringen-Operationen an Deltas zum Erreichen von Konvergenz. Wenn zwei Endpunkte A und B unabhängig die Deltas DA bzw. DB erzeugen und ausführen und die Deltas an den jeweils anderen Endpunkt senden, dann muß ein Endpunkt seine Deltaausführung „Wiederholen", damit beide Endpunkte konvergieren. Zum Beispiel wird auf dem Endpunkt A Delta DA ausgeführt, bevor Delta DB empfangen wird. Auf dem Endpunkt B wird Delta DB ausgeführt, bevor Delta DA empfangen wird. Um Konvergenz sicherzustellen, muß ein Endpunkt wiederholen. Wenn die korrekte Ausführungsreihenfolge bestimmt durch den Dynamikmanager Do(DA) Do(DB) ist, dann muß der Endpunkt B eine Wiederholung durchführen. Die Reihenfolge der Operationen auf B ist: Do(DB) Undo(DB) Do(DA) Do(DB). Somit ist die abschließende Ausführungsreihenfolge auf beiden Endpunkten die gleiche.
  • Als Teil des Kommandoausführungsrahmens stellt der Dynamikmanager 220 auch die Handhabung von Ausnahmen bereit, welche auftreten, wenn Kommandos ausgeführt werden. Der Dynamikmanager 220 stellt auch APIs bereit, um es Werkzeugen zu ermöglichen, Rückgängigmachen- und erneute Ausführungsoperationen auf dem Benutzerlevel auszuführen. Der Dynamikmanager 220 verwendet die gleiche Implementierung für das Rückgängigmachen und die erneute Ausführung, die auch von Wiederholungs- und Überspringen-Operationen verwendet wird, um die Rückgängigmachen- und erneute Ausführungsoperationen durch den Benutzer zu unterstützen.
  • Der Dynamikmanager wendet bei der Operation auch Einschränkungen an, die durch Vorrichtungen als Teil der Ausführen- und Rückgängigmachen-Verfahren durchgeführt werden können. Insbesondere können die Vorrichtungen während dieser Verfahren keine Komponenten höherer Levels (wie Ansichten) aufrufen. Um Vorrichtungen beim Implementieren von Ansichtbenachrichtigungen zu unterstützen, stellt der Dynamikmanager 220 einen asynchronen Benachrichtigungsdienst in Verbindung mit „Empfehlungs"-Elementen bereit. Diese Elemente werden dem Dynamikmanager 220 bereitgestellt und der Dynamikmanager 220 benachrichtigt dann asynchron jede Einheit, welche registriert ist, um diese Benachrichtigungen zu empfangen. Die Benachrichtigungen werden auch für die Benachrichtigung über Ereignisse verwendet, bei denen es sich nicht um die Ausführung eines Kommandos handelt.
  • Der Dynamikmanager 220 ist ferner verantwortlich für das Garantieren, daß Deltas von allen aktiven Endpunkten im geteilten Raum gesendet und empfangen werden. Um dies zu tun, pflegt der Dynamikmanager 220 Kontaktinformationen für alle Endpunkte im Raum. Deltas, welche lokal ausgeführt werden, werden auch an alle Mitglieder des Raumes verbreitet, zum Ausführen auf anderen Endpunkten. Üblicherweise ist das Kommunikationsnetz zwischen Endpunkten nicht komplett zuverlässig, und somit ist der Dynamikmanager 220 verantwortlich für die Rückübertragung von Deltas, die möglicherweise während der Übertragung verloren gegangen sind. Der Dynamikmanager 220 verwendet die Abhängigkeiten von Deltas zum Erkennen, ob Deltas fehlen. Der Dynamikmanager 220 sendet auch periodisch Impulse, wenn es Änderungen im geteilten Raum gegeben hat. Wie die Deltas enthalten auch die Impulse Abhängigkeiten, welche verwendet werden können, um fehlende Deltas zu erkennen.
  • Wenn der Dynamikmanager 220 erkannt hat, daß ein Delta fehlt, versucht er normalerweise, das fehlende Delta von einem oder mehreren anderen Endpunkten im geteilten Raum zu holen. Die Deltas werden in einer Datenstruktur, Datenprotokoll genannt, in jedem Endpunkt gespeichert, so daß normalerweise andere Endpunkte die Anforderung erfüllen können und das fehlende Delta erneut senden. Der Dynamikmanager 220 bietet auch eine Schnittstelle, die es anderen erlaubt, Informationen an die Endpunkte in einem geteilten Raum zu verbreiten.
  • Der Dynamikmanager 220 pflegt das zuvor erwähnte Deltaprotokoll, welches alle Deltas enthält, die im Raum ausgeführt wurden. Das Protokoll wird aus drei Gründen geführt: die Deltas müssen möglicherweise wiederholt werden, um Konvergenz sicherzustellen, die Deltas müssen möglicherweise von einem anderen Endpunkt geholt werden und die Deltas werden möglicherweise vom Benutzer rückgängig gemacht oder erneut ausgeführt. Der Dynamikmanager 220 erkennt, wenn ein Delta aus einem dieser Gründe nicht mehr geführt werden muß. Zu diesem Zeitpunkt kann der Dynamikmanager 220 das Delta in einem Verfahren, Eliminierung genannt, aus dem Deltaprotokoll entfernen. Damit der Dynamikmanager 220 erkennen kann, daß er ein Delta nicht mehr benötigt, muß er Impulse von allen anderen Endpunkten empfangen. Wenn ein Endpunkt für einen vorbestimmten Zeitraum keinen Impuls sendet, kann der Dynamikmanager 220 entscheiden, daß der Endpunkt ein „Nachzügler" ist. Ein Nachzügler-Endpunkt ist definiert als ein Endpunkt, der scheinbar die Verbindung zum geteilten Raum verloren hat. Im Allgemeinen ist es wünschenswert, einen solchen Endpunkt zeitweilig aus dem Raum zu entfernen, so daß seine Deltas aus dem Deltaprotokoll eliminiert werden können, um die Größe des Deltaprotokolls zu verringern. Wenn auch andere Endpunkte entscheiden, daß ein Endpunkt ein Nachzügler ist, wird der Nachzügler-Endpunkt vom geteilten Raum getrennt. Wenn der Nachzügler-Endpunkt wieder im geteilten Raum aktiv wird, muß er eine neue Kopie des Raumes von einem der aktiven Endpunkte empfangen.
  • Es sind mehrere Schritte am Prozeß des Erzeugens und Ausführens von Datenänderungskommandos in Deltas beteiligt und viele Komponenten des kollaborativen Systems sind an diesem Prozeß beteiligt. 3A and 3B zusammengenommen bilden ein Flußdiagramm, welches die Hauptschritte veranschaulicht, die an der Erzeugung eines Deltas und der Einfügung des Deltas in einen geteilten Raum beteiligt sind. Dieses Flußdiagramm wird in Verbindung mit 4 beschrieben, welche die Hauptkomponenten veranschaulicht, die an dem Prozeß beteiligt sind, einschließlich Komponenten am Quellendpunkt, von dem das Delta erzeugt wird und einem Zielendpunkt, an den das Delta gesendet wird.
  • Der Prozeß beginnt mit Schritt 300 und fährt fort mit Schritt 302, wo ein Dynamikmanager wie der Manager 420 in einem Quellendpunkt 400 (der Endpunkt, welcher das Delta erzeugt) bei der Anforderung eines Werkzeugs 418 ein Delta erzeugt. Der Dynamikmanager 420 stellt das Delta mittels XML-Code dar. Ein neu erzeugtes Delta ist ein leeres Behältnis für Datenänderungskommandos. Die Struktur eines typischen Deltas variiert abhängig vom Typ des Deltas, der Anzahl der Kommandos enthalten in dem Delta und ob „Rückgängigmachen"-Informationen vorliegen, die das „Rückgängigmachen" der Kommandos erlauben. 5 zeigt die grundlegende XML-Codestruktur eines Deltas 500 mit einem Kommando und ohne Rückgängigmachen-Informationen, und 6 zeigt die grundlegende XML-Codestruktur eines Deltas 600 mit zwei Kommandos und Rückgängigmachen-Informationen für beide Kommandos. Gemäß der typischen XML-Struktur besteht dieser XML-Code aus einer Vielzahl hierarchischer Elemente, die miteinander verschachtelt sind. Jedes Element kann damit in Zusammenhang stehende Attribute und spezifischen Inhalt aufweisen. Der gesamte XML-Code befindet sich in einem Namensraum, wo „g" für die URL „urn:groove.net" steht.
  • Das LDel-Element 502, 602 ist ein lokales Delta-Element und es weist Attribute auf, die nur für den lokalen Endpunkt relevant sind. Aus diesem Grund wird dieses Delta-Element nicht an andere Endpunkte gesendet, wenn die Deltas an andere Endpunkte gesendet werden. Es weist mehrere Attribute auf. Attribute sind nur dann in einem Element enthalten, wenn sie relevant sind, deswegen sind nicht alle Attribute in 5 und 6 gezeigt. Zu den Attributen des LDel-Elements 502, 602 zählt ein AssPrevGenDel-Attribut, welches eingestellt ist, wenn das Delta zum Zweck des Rückgängigmachens mit einem vorhergehenden Delta in Zusammenhang steht (das heißt die Deltas werden zusammen rückgängig gemacht). Das BlkDel-Attribut ist eingestellt, wenn dieses Delta die höchste Priorität im aktuellen Block hat. Das DeltaToRedoIP- Attribut ist auf einem erneut auszuführenden Delta eingestellt. Es wird auf den Einsetzungspunkt des Deltas eingestellt, welches erneut ausgeführt wird. Das DoError-Attribut ist eingestellt, wenn das letzte Mal, als das Delta ausgeführt wurde, ein Fehler aufgetreten ist.
  • Das Done-Attribut ist eingestellt, wenn das Delta auf dem Endpunkt ausgeführt wurde. Es existiert nicht, wenn das Delta nicht ausgeführt wurde. Das Redone-Attribut ist eingestellt, wenn das Delta rückgängig gemacht und dann erneut ausgeführt wurde. Das ReKeys-Attribut enthält Schlüsselinformationen für das Delta, welche beim Verschlüsseln des Deltas zum Senden an andere Endpunkte verwendet werden. Es existiert nur an dem Endpunkt, welcher der Erzeuger des Deltas ist. Das SenderUID-Attribut ist auf die einmalige ID des Senderendpunktes auf Deltas eingestellt, die aufgrund einer Holen-Anforderung durch den Dynamikmanager 420 empfangen wurden.
  • Das Ses-Attribut ist die Delta-Sitzung verwendet bei Rückgängigmachen- und erneuten Ausführungsoperationen. Es existiert nur auf dem Endpunkt, welcher das Delta erzeugt hat. Das Undo-Attribut ist eingestellt, wenn das Delta ein Rückgängigmachen-Delta ist. Das UndoError-Attribut ist eingestellt, wenn ein Fehler aufgetreten ist, als das letzte Mal versucht wurde, das Delta rückgängig zu machen. Das Undone-Attribut ist eingestellt, wenn ein Delta rückgängig gemacht wurde. Das URL-Attribut speichert eine URL, wenn für das Delta eine spezifiziert wurde. Diese URL wird als die Nachrichten-URL verwendet und erlaubt dem Dynamikmanager das Unterstützen von Deltafortschrittbenachrichtigungen.
  • Der Inhalt des LDel-Elements 502, 602 umfaßt das Del-Element 504, 604 und das SEC-Element 506, 606. Das Del-Element 504, 604 ist das Delta-Element, das an andere Endpunkte gesendet wird. Es sei darauf hingewiesen, daß nur das Kommando-Element (oder Kommandos-Element) verbreitet wird. Alle Kommando-Rückgängigmachen-Informationen werden nicht verbreitet. Das Sec-Element 506, 606 ist das Sicherheitselement, wo der Sicherheitsmanager 414 Delta-spezifische Sicherheitsinformationen speichern kann.
  • Die Attribute des Del-Elements 504, 604 umfassen ein AddEpt-Attribut, welches eingestellt ist, wenn dieses Delta einen Endpunkt zum geteilten Raum hinzufügt. Ein AddNewEpt-Attribut ist eingestellt, wenn dieses Delta einen neuen Endpunkt zum geteilten Raum hinzufügt. Dieses Attribut wird nur verwendet, wenn ein Kontoraum auf ein neues Gerät importiert wird. Ein CR-Attribut enthält die Konfliktregion des Deltas, die eingestellt ist, wenn das Delta erzeugt wird. Deltas, die unterschiedliche Konfliktregionen aufweisen, erfordern keine konsistente Ausführungsreihenfolge. Deltas ohne Konfliktregion kollidieren mit allen anderen Deltas. Das CR-Attribut enthält eine Zeichenkette, und eine leere Zeichenkette zeigt an, daß das Delta mit allen anderen Deltas kollidieren wird. Wenn zwei unterschiedliche Regionen auf dem gleichen Delta eingestellt sind, dann ist die Konfliktzeichenkette auf leer eingestellt, so daß das Delta mit allen anderen Deltas kollidiert. Üblicherweise weist jedes Werkzeug eine einmalige Konfliktregion auf, die es auf einem Delta einstellt. Jedoch stellen Systemwerkzeuge wie der Sicherheitsmanager und Mitgliedsmanager keine Konfliktregion ein, so daß ihre Deltas mit allen anderen Deltas kollidieren. Dies ist wichtig, weil jedes Werkzeug auf die Daten in den Systemwerkzeugen zugreifen kann.
  • Ein DepSeq-Attribut ist der Satz von Abhängigkeitsfolgen des Deltas. Dieses existiert möglicherweise nicht, wenn die einzigen Abhängigkeiten impliziert sind. Abhängigkeiten werden unten detaillierter beschrieben.
  • Ein Gp-Attribut ist die Gruppennummer des Deltas. Ein PurNot-Attribut ist eingestellt, wenn eine Vorrichtung, welche eines der Kommandos in dem Delta erzeugt hat, benachrichtigt werden muß, wenn das Delta eliminiert wird. Ein Seq-Attribut beinhaltet eine Sequenznummer des Deltas wie unten beschrieben. Ein Version-Attribut beinhaltet die Version des Dynamikmanagers 420, der das Delta erzeugt hat.
  • Der Inhalt des Del-Elements 504, 604 umfaßt ein Kommando-Element 508, wenn nur ein Kommando vorliegt, oder ein Kommandos-Element 608, wenn mehr als ein Kommando vorliegt. Dem Kommando-Element 508 folgt ein Inhaltsabschnitt, welcher den Kommandoinhalt umfaßt, und dem Kommandos-Element 608 folgt ein Inhaltsabschnitt, welcher die Kommandos-Elemente 610, 612 für jedes Kommando in dem Delta umfaßt. Wenn das Delta nur ein Kommando aufweist, ist das Kommando-Element 508 ein direkter Nachkomme des Delta-Elements. Wenn das Delta eine Vielzahl von Kommandos aufweist, so sind diese im Kommandos-Element 608 enthalten, welches ein direkter Nachkomme des Deltas ist. Die Cmd-Elemente 508, 610 und 612 stehen jeweils für ein Kommando in dem Delta. Der Inhalt und die meisten der Attribute dieser Elemente sind eingestellt durch die Vorrichtung, welche das Kommando erzeugt hat. Zu den Attributen zählt ein EngineURL-Attribut, welches auf die URL der Vorrichtung eingestellt ist, welche das Kommando erzeugt hat. Ein PurNot-Attribut ist eingestellt, wenn die Vorrichtung, welche das Kommando erzeugt hat, eine Benachrichtigung erfordert, wenn das Kommando eliminiert wird.
  • Wenn keine Rückgängigmachen-Informationen für das Kommando vorliegen, wird ein leerer Kommentar „<!--->" 510 als ein Platzhalter verwendet. Wenn Rückgängigmachen-Informationen vorliegen, enthält ein CmdU-Element 614, 616 Kommando-Rückgängigmachen- Informationen für eines der Kommandos im Delta. Der Inhalt und die Attribute auf diesem Element sind eingestellt durch die Vorrichtung, welche das Kommando ausgeführt hat.
  • Wenn ein Delta erzeugt wird, ist es ein ungebundenes oder unabhängiges XML-Codefragment innerhalb eines größeren, bleibenden XML-Dokuments 440, welches die Deltas im Dynamikmanager 420 darstellt. Eine typische XML-Darstellung des Dokuments 440 ist in 7 gezeigt. Das XML-Dokument 700 umfaßt ein EngineData-Element 702, welches das Stammelement für das Dynamikmanager-Dokument ist. Der Inhalt dieses Elements umfaßt eine Reihe weiterer Elemente. Zu diesen zählen ein BlockedDels-Element 704, welches der Ursprung für alle Deltas ist, die blockiert werden. Dieses Element wird als ein Ursprung für alle Nachrichten verwendet, die blockiert werden. Es enthält ein EptPul-Element, welches ein Impuls-Element von einem unterschiedlichen Element enthält, und ein LocalDel-Element, welches ein Delta einschließlich Informationen spezifisch für den lokalen Endpunkt darstellt. Ein CmdU-Element 706 dient als ein leeres Nur-Lese-Kommando-Rückgängigmachen-Element. Es wird als das Rückgängigmachen-Element für alle Kommandos verwendet, welche keine expliziten Rückgängigmachen-Informationen aufweisen. Die Attribute und der Inhalt des CmdU-Elements sind spezifisch für die Vorrichtung, welche das Kommando ausführt.
  • Hin und wieder kann der Dynamikmanager 420 CmdU-Elemente erzeugen, die später als überflüssig bestimmt werden. Diese CmdU-Elemente werden für die zukünftige Verwendung in CmdUParent-Elementen gespeichert. Zum Beispiel werden die CmdUParent-Elemente 708 und 710 als Ursprünge für zusätzliche CmdU-Elemente verwendet. Ein DelHldr-Element 712 wird verwendet, um eine Datenstruktur, „Delta-Halter" 442 genannt, darzustellen. Diese Struktur ist unten detaillierter beschrieben. Ähnlich stellt das DelLog-Element 714 eine Datenstruktur, „Deltaprotokoll" 438 genannt, dar. Auch diese ist unten detailliert beschrieben.
  • Ein DisconnectNotifications-Element 716 wird als ein temporärer Ursprung für eingehende Trennbenachrichtigungen verwendet. Ein Disseminator-Element 718 wird verwendet, um Elemente darzustellen, welche darauf warten, an andere Endpunkte gesendet oder „verbreitet" zu werden. Auch diese Struktur ist unten detailliert beschrieben. Ein Epts-Element 720 wird verwendet, um Endpunkte in dem geteilten Raum darzustellen. Es wird unten detaillierter beschrieben. Ein InboundDeltas-Element 722 wird als eine temporäre Schlange für eingehende Nachrichten an den Dynamikmanager 420 verwendet und es wird unten beschrieben. Es enthält ein Del-Element, welches den Teil eines Deltas darstellt, der allen Endpunkten gemeinsam ist, ein DisNtfy-Element, welches eine Trennbenachrichtigung von einem unterschiedlichen Endpunkt enthält, ein EptPul-Element, welches ein Impulselement von einem unterschiedlichen Element enthält und ein LocalDel-Element, welches ein Delta einschließlich Informationen spezifisch für den lokalen Endpunkt enthält.
  • Zu den Attributen des EngineData-Elements 702 zählen ein Blocked-Attribut, welches den Einsetzungspunkt eines Deltas enthält, welches den Dynamikmanager 420 veranlaßt hat, in einen blockierten Zustand zu wechseln. Ein BlockedCount-Attribut enthält die Anzhal, wie oft der Dynamikmanager 420 blockiert wurde. Ein Divergent-Attribut ist eingestellt, wenn der Dynamikmanager 420 für einen geteilten Raum von anderen Mitgliedern des geteilten Raumes abweichend ist. Das Attribut ist eingestellt auf eine Zeichenkette, welche den Grund für die Abweichung darstellt. Ein LastEptPulse-Attribut enthält die Zeit, zu welcher der lokale Endpunkt zum letzten Mal eine Impulsnachricht gesendet hat. Ein PurgingDisabled-Attribut ist eingestellt, wenn das Eliminieren deaktiviert ist. Ein UnackedDel-Attribut ist eingestellt, wenn ein Delta existiert, welches nicht durch einen Impuls quittiert wurde. Wie unten detailliert diskutiert werden wird, werden dieser letzten drei Attribute verwendet, wenn das oben erwähnte Deltaprotokoll periodisch eliminiert wird. Ein PingSeq-Attribut enthält eine Folgenummer, welche das letzte Mal anzeigt, wann ein Relaisserver kontaktiert wurde. Ein Uninvited-Attribut ist eingestellt, wenn der lokale Endpunkt aus dem Raum ausgeladen wurde. Ein Version-Attribut enthält die Version des Dynamikmanager-Datenmodells. Und schließlich wird ein Watermark-Attribut verwendet, um den im lokalen Cache gespeicherten Zustand konsistent mit dem bleibenden Zustand zu halten, indem erkannt wird, wenn Transaktionen abgebrochen werden.
  • Dieses bleibende XML-Dokument 440 wird durch einen Speichermanager 216 gepflegt. Ein Speichermanager 216, der für die Verwendung mit der vorliegenden Erfindung geeignet ist, ist in der zuvor erwähnten US-Patentanmeldung mit der Seriennummer 09/588,195 detailliert beschrieben. Zusätzlich zum Erzeugen der bleibenden XML-Darstellung 440 erzeugt der Dynamikmanager 420 ein COM-Objekt, welches das Delta darstellt. Das letztgenannte Objekt implementiert eine Reihe von Schnittstellen, welche das Werkzeug 418 verwenden kann, um Kommandos zu dem Delta hinzuzufügen und Eigenschaften des Deltas einzustellen.
  • Das Erzeugen eines Deltas erzeugt auch automatisch eine Transaktion in einer Transaktionsdatenbank, welche mit dem geteilten Raum in Zusammenhang steht (nicht gezeigt). Transaktionen stellen ein exklusives Verfahren des Zugriffs auf die Datenbank des geteilten Raumes bereit und ermöglichen es, sämtliche Änderungen komplett rückgängig zu machen, die aufgrund eines bestimmten Deltas eingeleitet wurden. Eine Transaktion wird abgebrochen, wenn das Delta, welches die Transaktion erzeugt hat, abgebrochen wird, oder wenn während der Deltaaus führung Fehler auftreten. Die Transaktion wird übergeben, wenn das Delta übergeben und erfolgreich ausgeführt wird.
  • Als nächstes fügt das Werkzeug 418 in Schritt 304 ein oder mehrere Datenänderungskommandos zum Deltabehältnis hinzu, entweder direkt oder durch die Verwendung von „erzeugungsverschachtelten" Deltas, wie unten beschrieben. Ein Kommando ist eine Änderungseinheit erzeugt und ausgeführt durch eine Vorrichtung wie die Vorrichtung 430, und ein Delta ist eine Gruppierung von Kommandos mit der Absicht, daß alle diese Kommandos immer zusammen ausgeführt werden. Daher ist ein Delta „atomisch" in dem Sinne, daß entweder alle Kommandos in dem Delta ausgeführt werden oder keines wird ausgeführt. Es gibt eine Ausnahme zu dieser Regel, welche während der Handhabung von Ausnahmen während der Kommandoausführung stattfindet, und sie wird unten diskutiert.
  • Die Schnittstellen auf dem COM-Objekt, welches mit dem Delta erzeugt wird und dieses darstellt, ermöglichen das Hinzufügen von Kommandos zu dem Delta. Ein Kommando wird mit Hilfe des Dynamikmanagers 420 hinzugefügt, um ein leeres Kommando-XML-Element (ein Cmd-Element) innerhalb des zuvor erwähnten XML-Fragments zu erzeugen, welches das Delta innerhalb des XML-Deltadokuments darstellt. Zu dem Zeitpunkt, zu dem das Delta erzeugt wird, muß dem Dynamikmanager 420 eine bindbare URL einer Vorrichtung wie der Vorrichtung 430 bereitgestellt werden, welche später das Kommando ausführt. Obwohl in 4 nur eine Vorrichtung 430 gezeigt ist, dürfte dem Fachmann auf dem Gebiet verständlich sein, daß eine Vielzahl von Vorrichtungen vorliegen kann. In der folgenden Beschreibung wird die Vorrichtung 430 verwendet, um auf alle diese Vorrichtungen zu verweisen. Diese URL ist ein einmaliger Name dieser Vorrichtung, so daß der Dynamikmanager die Vorrichtung später finden kann, wenn sie benötigt wird. Das zuvor erwähnte EngineURL-Attribut ist auf das zutreffende XML-Kommandoelement eingestellt. Der Erzeuger des Deltas kann dann sämtliche Attribute und Inhalte hinzufügen, die zum Ausführen des Kommandos erforderlich sind. Zum Beispiel besitzt eine Vorrichtung, welche einen Skizzenblock implementiert, Kommandos zum Zeichnen von Objekten. Wenn der Benutzer ein Objekt auf dem Skizzenblock zeichnet, wird ein Kommando mit Attributen erzeugt, welche die Form, Farbe und Position des Objekts beschreiben. Wenn dieses Kommando ausgeführt wird, werden sowohl auf dem Quellendpunkt, welcher das Delta erzeugt hat, als auch auf den entfernten Zielendpunkten die Änderungen in dem Kommando auf das Datenmodell 432 in Zusammenhang mit der Vorrichtung 430 angewandt.
  • Eine alternative Art und Weise, um Kommandos zu einem Delta hinzuzufügen, ist durch „erzeugungsverschachtelte" Deltas. Erzeugungsverschachtelte Deltas bieten eine einfache Möglichkeit, Komponenten zu kombinieren, um komplexere Werkzeuge herzustellen. Zum Beispiel könnte ein Werkzeug eine Reihe anderer Komponenten verwenden, welche andere Werkzeuge sein können. Wenn der Benutzer eine Handlung in dem Werkzeug ausführt, erzeugt dieses Werkzeug einen Delta-Behälter. Das Werkzeug ruft dann die anderen Komponenten auf, um Kommandos zu dem Deltabehälter hinzuzufügen. Anstelle des direkten Hinzufügens von Kommandos zu dem Delta kann ein Werkzeug ein weiteres Delta erzeugen und dieses neue Delta zu dem ersten Delta hinzufügen. Aufgrund der Erzeugung dieses Deltas verschachtelt innerhalb der Erzeugung eines weiteren Deltas wird es ein erzeugungsverschachteltes Delta genannt. Zum Beispiel könnte ein Satz von Schritten während der Erzeugung eines Deltas Folgender sein:
    • Delta 1 erzeugt Kommando A hinzugefügt Delta 2 erzeugt (dieses ist erzeugungsverschachtelt) Kommando B erzeugt Delta 2 übergeben Kommando C hinzugefügt
    • Delta 1 übergeben
  • Die XML-Struktur eines Deltas 800, welches zwei erzeugungsverschachtelte Deltas enthält, von denen beide Rückgängigmachen-Informationen aufweisen, ist in 8A und 8B zusammengenommen gezeigt. Ein erzeugungsverschachteltes Delta weist die gleichen Elemente auf wie ein Standard-Delta mit einigen Änderungen am Kommando-Element. Zum Beispiel ist ein Nested-Attribut im Cmd-Element eingestellt, wenn das Kommando als Teil eines erzeugungsverschachtelten Deltas erzeugt wurde. Das Nested-Attribut ist auf die ID des erzeugungsverschachtelten Deltas eingestellt. Außerdem ist ein Nord-Attribut auf dem Cmd-Element auf die Ordnungszahl des Kommandos innerhalb des verschachtelten Deltas eingestellt.
  • Wenn ein erzeugungsverschachteltes Delta wie unten beschrieben übergeben wird, werden alle Kommandos in dem Delta ausgeführt, genau wie dies bei einem nichtverschachtelten Delta der Fall wäre. Jedoch fügt anstelle des Speicherns des Deltas in einem Deltaprotokoll 438 nach dem Ausführen der Kommandos der Dynamikmanager 420 die Kommandos und Rückgängigmachen-Informationen automatisch zum Beginn des enthaltenden Deltas hinzu. Wenn das enthaltende Delta abgebrochen wird, werden auch die erzeugungsverschachtelten Deltakommandos abgebrochen. Wenn das enthaltende Delta durchgeführt wird, wurden die erzeugungsver schachtelten Kommandos bereits ausgeführt und sie werden nicht noch einmal ausgeführt. Es sei darauf hingewiesen, daß Kommandos im abschließenden enthaltenden Delta in der Reihenfolge vorliegen, wie sie ausgeführt werden. Weil sie nicht ausgeführt werden, bis das Delta, in dem sie enthalten sind, ausgeführt wurde, ist die Ausführungsreihenfolge der Kommandos in Delta 1 oben B, A, C.
  • Wenn ein Werkzeug wie das Werkzeug 418 das Hinzufügen von Kommandos zu dem Delta abgeschlossen hat, kann das Werkzeug 418 das Delta in Schritt 306 entweder übergeben oder abbrechen. Wenn das Delta abgebrochen wird, wird keines der Kommandos ausgeführt und die auch Transaktion, die gestartet wurde, als das Delta erzeugt wurde, wird abgebrochen. Weil in diesem Fall nichts weiter passiert, wird angenommen, daß das Delta in Schritt 306 übergeben wird. Wenn ein Delta übergeben wird, führen die übrigen Schritte tatsächlich die Kommandos in dem lokalen Endpunkt aus und verbreiten das Delta und seine Kommandos an die Zielendpunkte. Die Transaktion, die gestartet wurde, als das Delta erzeugt wurde, wird nicht übergeben, bis das Delta ausgeführt und zur Verbreitung aufgereiht worden ist.
  • Als nächstes bestimmt in Schritt 308 der Dynamikmanager 420, wo das neu übergebene Delta in ein Deltaprotokoll 438 eingefügt wird. Das Deltaprotokoll ist eine XML-Datenstruktur, die eigentlich Teil des XML-Dokumentes 440 im Dynamikmanager 420 ist. Die Struktur weist eine typische XML-Codestruktur wie die in 9A und 9B zusammengenommen gezeigte auf.
  • Die XML-Struktur des Deltaprotokolls besteht aus mehreren Elementen, einschließlich eines DelLog-Elements 902, welches das Deltaprotokoll darstellt. Das DelLog-Element 902 weist mehrere Attribute auf, einschließlich eines NeedToDelete-Attributs, welches eingestellt ist, wenn es Gruppen gibt, die eliminiert, jedoch noch nicht gelöscht wurden. Ein PenGrpNum-Attribut enthält die Zahl der höchsten Gruppe, deren Eliminierung ansteht, d.h. die zum Eliminieren berechtigt erklärt wurde. Ein PurGrpNum-Attribut enthält die Zahl der höchsten Gruppe, die eliminiert wurde.
  • Das DelLog-Element 902 umfaßt auch weitere Elemente als seinen Inhalt. Dazu zählen ein oder mehrere DelBlk-Elemente 904 und 922, von denen jedes einen Block von Deltas darstellt. Deltablöcke werden verwendet zum Implementieren von Prioritätsdeltas wie unten beschrieben. Innerhalb eines Blocks sind die Deltas nach der Gruppe organisiert. Jeder Block weist ein Inhaltselement für jede Gruppe von der ersten Gruppe in dem Block zur höchsten Gruppe in dem Block auf, selbst wenn die Gruppe keine Deltas innerhalb des Blocks aufweist.
  • Jedes DelBlk-Element, zum Beispiel das Element 904, enthält ein oder mehrere DelGrp-Elemente 906, 912 und 914, von denen jedes eine Gruppe von Deltas darstellt. Eine Deltagruppe ist ein Satz von Deltas organisiert in Ketten. Es gibt ein XML-Element für jede Kette innerhalb einer Gruppe. Die Ketten sind nach ansteigender Erzeuger-ID des Endpunktes, welcher die Kette erzeugt hat, geordnet. Ein DelGrp-Element 906 kann zwei Attribute aufweisen: ein DoneTime-Attribut, welches den Zeitpunkt enthält, zu dem die nächste Gruppe erzeugt wurde, und ein Number-Attribut, welches die Nummer der Gruppe enthält.
  • Jedes DelGrp-Element, zum Beispiel das Element 906, enthält ein oder mehrere DelChn-Elemente 908, welche eine Kette von Deltas darstellen. Jedes DelChn-Element 908 weist ein CreatorID-Attribut auf, welches die ID des Erzeugers der Kette enthält. Jedes DelChn-Element 908 enthält ein oder mehrere LDelChn-Elemente 910, von denen jedes ein Delta darstellt.
  • Jede Position in dem Deltaprotokoll 438 weist eine einmalige Adresse auf, ein „Einsetzungspunkt" genannt. Ein neues Delta wird immer am Ende des Deltaprotokolls 438 eingefügt und dementsprechend muß zum Einfügen eines neuen Deltas der Einsetzungspunkt, welcher dem Ende des Deltaprotokolls 438 entspricht, bestimmt werden. Bei einer Ausführungsform besteht jeder Einsetzungspunkt aus der Kombination einer Gruppennummer, einer Erzeuger-ID und einer Folgenummer. Die Erzeuger-ID wiederum besteht aus einer Kombination einer Endpunkt-ID und einer Zufallszahl als Erzeuger-ID. Die Endpunkt-ID ist eine Kombination (zum Beispiel ein Rautenzeichen) der Geräte-URL und der Kontakt-URL des Endpunktes und ist ein einmaliger Identifikator des Endpunktes. Jedes Mal, wenn ein Endpunkt einen geteilten Raum öffnet, wird dem Endpunkt eine neue Zufallszahl als Erzeuger-ID zugewiesen. Die Erzeuger-ID ist dazu gedacht, das Auftreten von Kollisionen während des Einfügens eines neuen Deltas in das Deltaprotokoll mit Deltas erzeugt durch den gleichen Endpunkt zu vermeiden. Diese Kollisionen können in Fällen eines Systemcrashs oder einer Wiedereinladung in einen geteilten Raum auftreten, was dazu führt, daß der Endpunkt seine interne Aufzeichnung vorausgehender Deltas, die er erzeugt hatte, verliert.
  • Nachdem die Erzeuger-ID bestimmt wurde, kann die Gruppennummer bestimmt werden. Bei einer bestimmten Ausführungsform in der Diskussion und wie oben dargelegt, sammelt das Deltaprotokoll 438 Deltas in Ketten und Ketten in Gruppen. Eine Kette besteht aus Deltas erzeugt durch den gleichen Erzeuger bis zu einer vorbestimmten maximalen Zahl von Deltas. Zum Bestimmen der Gruppennummer bestimmt der Dynamikmanager 420 zuerst, ob das neu durchgeführte Delta zu der letzten gebildeten Kette hinzugefügt werden kann, d.h., ob die Kette Deltas von dem Erzeuger enthält, und daß sich weniger als die maximale Anzahl von Deltas bereits auf der Kette befindet. Wenn das Delta zu dieser letzten Kette hinzugefügt werden kann, ist die Gruppennummer die Nummer der Gruppe, welche die letzte Kette enthält. Wenn das Delta nicht hinzugefügt werden kann, muß eine neue Kette erzeugt werden.
  • Als nächstes muß eine Bestimmung durchgeführt werden, ob die neue Kette in der aktuellen Gruppe erzeugt werden kann oder ob eine neue Gruppe erzeugt werden muß. Gemäß der Ausführungsform müssen innerhalb jeder Gruppe die Ketten in ansteigender Reihenfolge nach der Erzeuger-ID vorliegen. Weil sich der Einsetzungspunkt für das neue Delta am Ende des Deltaprotokolls 438 befinden muß, muß die Erzeuger-ID für das neue Delta mit der Erzeuger-ID der letzten Kette in dem Deltaprotokoll verglichen werden. Wenn diese größer ist, dann kann die neue Kette zur letzten Gruppe hinzugefügt werden, und die Nummer dieser Gruppe ist die Gruppennummer für das Delta.
  • Ansonsten muß eine neue Gruppe erzeugt werden. Die neue Gruppe, und das neue Delta, weisen eine Nummer auf, die um eins höher ist als die vorherige Gruppe. Schließlich wird die Folgenummer bestimmt. Das erste durch einen Erzeuger erzeugte Delta hat eine Folgenummer „1". Jedes nachfolgend erzeugte Delta hat eine Folgenummer, die um eins höher ist als die des vorherigen Deltas.
  • Zusammengenommen sind die Erzeugungs-ID und die Folgenummer eine Nummer, „Deltafolge" genannt. Die Gruppennummer ist verknüpft mit der Deltafolge zum Erzeugen des Einsetzungspunktes. Um das Indexieren zu vereinfachen, werden die Gruppennummer und die Folge als separate Attribute auf dem Delta gespeichert.
  • In Schritt 308 wird der Einsetzungspunkt auf das Delta „gestempelt", indem der berechnete Wert in das Delta-Attribut eingefügt wird, jedoch wird das Delta zu diesem Zeitpunkt nicht automatisch in das Deltaprotokoll 438 eingefügt. Der Einsetzungspunkt muß in das Delta eingeschlossen sein, weil bestimmte Spezialkommandos wie das Hinzufügen eines Mitglieds zum geteilten Raum den Deltaeinsetzungspunkt verwenden. Es wäre theoretisch möglich, das Delta zu diesem Zeitpunkt tatsächlich an der korrekten Stelle im Deltaprotokoll 438 zu plazieren, jedoch ließe sich dadurch das „Delta-Rückgängigmachen"-Kommando viel schwieriger implementieren.
  • Nachdem der Einsetzungspunkt gestempelt wurde, führt der Dynamikmanager 420 in Schritt 310 die Kommandos in dem Delta aus (dieser Prozeß wird „Ausführen des Deltas" genannt). Zum Durchführen dieses Schrittes iteriert der Dynamikmanager 420 über alle Kommando-Elemente und öffnet das Attribut, welches die bindbare URL der Vorrichtung enthält, welche das Kommando ausführen soll. Der Dynamikmanager 420 verbindet sich dann mit dieser Vorrichtung – dieser Prozeß nimmt die URL und findet die Vorrichtung, welche mit dieser URL in Zusammenhang steht. Nachdem der Dynamikmanager 420 die Vorrichtung lokalisiert hat (zum Beispiel Vorrichtung 430), ruft er die Vorrichtung 430 auf, das Kommando auszuführen. Zusätzlich zum Bereitstellen des Kommando-Elements, welches das Kommando beschreibt, an die Vorrichtung 430, stellt der Dynamikmanager 420 auch ein leeres Kommando-Rückgängigmachen-Element an die Vorrichtung 430 bereit. Die Vorrichtung 430 kann dieses Element verwenden, um alle Informationen zu speichern, welche möglicherweise im Anschluß zum Rückgängigmachen oder Umkehren der Ausführung des Kommandos benötigt wird. Wenn die Vorrichtung 430 Informationen zu dem Kommando-Rückgängigmachen-Element hinzufügt, wird das Element in dem Delta gespeichert. Aus Gründen der Leistung verwendet, wenn die Vorrichtung 430 keine Informationen in dem Rückgängigmachen-Element speichert, der Dynamikmanager 420 dann einen leeren Kommentar als Platzhalter für das Rückgängigmachen-Element in dem Delta.
  • Die beim Ausführen eines Kommandos durchgeführten Schritte sind abhängig von der Vorrichtung, welche das Kommando ausführt, und dem Kommando, welches ausgeführt wird. Eine Vorrichtung 430 führt das Kommando aus und wendet alle Änderungen auf sein bleibendes Datenmodell 432 an. Die Vorrichtung 430 kann auch „Empfehlungen" erzeugen, die sie asynchron benachrichtigen, daß die Änderung erfolgt ist. Häufig fügt sie Rückgängigmachen-Informationen zu dem Kommando-Rückgängigmachen-Element hinzu, wobei die Rückgängigmachen-Informationen notwendig sein können, wenn das Kommando in der Zukunft rückgängig gemacht werden muß. Jede Vorrichtung 430 kann auch eine Zugangskontrollprüfung durchführen, um sicherzustellen, daß der Erzeuger des Deltas die Erlaubnis hat, dieses Kommando durchzuführen. Diese Prüfung erfolgt auf jedem Endpunkt, bevor das Kommando ausgeführt wird. Wenn einer der Endpunkte keine Erlaubnis hat, so kann die Vorrichtung 430 eine Ausnahme zulassen, die wie unten beschrieben gehandhabt wird.
  • Außerdem kann die Vorrichtung 430 ausführungsverschachtelte Deltas erzeugen. Ein ausführungsverschachteltes Delta wird während der Ausführung von Kommandos in einem anderen Delta erzeugt. Ausführungsverschachtelte Deltas sind ähnlich erzeugungsverschachtelten Deltas, außer daß sie erzeugt werden, während die Kommandos in dem enthaltenden Delta ausgeführt werden, anstatt wenn das enthaltende Delta erzeugt wird. Wenn erzeugungsverschachtelte Deltas ausgeführt werden, wie oben diskutiert, werden Kommandos und Rückgängigmachen-Informationen zu dem enthaltenden Delta hinzugefügt. Jedoch werden, wenn ausführungsverschachtelte Deltas ausgeführt werden, die Kommandos, die sie enthalten, und sämtliche Rückgängigmachen-Informationen für diese enthaltenen Kommandos in den Rückgängigmachen-Informationen des enthaltenden Deltas gespeichert.
  • Erzeugungsverschachtelte Deltas werden nur auf dem Endpunkt 400 erzeugt, welcher das Delta erzeugt, und die Kommandos darin werden dann automatisch auf allen Endpunkten ausgeführt, welche das enthaltende Delta ausführen. Im Gegensatz dazu werden ausführungsverschachtelte Deltas üblicherweise auf allen Endpunkten erzeugt, welche das enthaltende Delta ausführen. Die Kommandos in ihnen werden nicht verbreitet, also müssen sie möglicherweise auf jedem Endpunkt erzeugt werden, welcher das enthaltende Delta ausführt. Das Ausführen des Deltas kann unterschiedliche Auswirkungen auf unterschiedliche Endpunkte haben, zum Beispiel, aufgrund von Unterschieden in der Rolle des Mitgliedes, welches das Delta ausführt. In diesen Fällen können die Rückgängigmachen-Informationen unterschiedlich sein und ausführungsverschachtelte Deltas müssen möglicherweise nicht erzeugt werden oder sie können unterschiedlich sein. Zugangskontrollprüfungen erfolgen in ausführungsverschachtelten Deltas nicht, da die Prüfung durch das enthaltende Delta ausreichend ist.
  • Wenn ein Delta rückgängig gemacht wird, macht der Dynamikmanager 420 sämtliche ausführungsverschachtelten Deltas rückgängig, bevor er das Kommando rückgängig macht, welches das Erzeugen des ausführungsverschachtelten Deltas veranlaßt hat.
  • Ausnahmen, welche während der Kommandoausführung auftreten, werden durch den Dynamikmanager 420 gehandhabt. Die Ausnahmehandhabung in dem Fall, wenn das Delta auf dem Endpunkt 400 ausgeführt wird, welcher es erzeugt hat, ist geradlinig. Die Ausnahme wird an das Werkzeug 430 übermittelt, welches versucht, das Delta zu übergeben. Es ist unbedingt darauf zu achten, daß jegliche Änderungen, die bereits als Teil dieses Deltas vorgenommen wurden, rückgängig gemacht werden. Um sicherzustellen, daß diese Änderungen rückgängig gemacht werden, erzeugt der Dynamikmanager 420 eine „Transaktion" um die Ausführung jeden Kommandos. Wenn eine Ausnahme während der Ausführung des Kommandos auftritt, dann wird die Transaktion um dieses Kommando abgebrochen. Dieser letztgenannte Prozeß macht sämtliche Änderungen rückgängig, die als Ergebnis der teilweisen Ausführung des Kommandos erfolgt sind.
  • Danach ruft der Dynamikmanager 420 andere geeignete Vorrichtungen auf, um sämtliche anderen Kommandos rückgängig zu machen, die bereits als Teil des Deltas ausgeführt wurden. Diese Aufrufe erlauben den Vorrichtungen das Rückgängigmachen jeglicher Informationen, die nicht Teil des geteilten Raumes sind und dementsprechend nicht automatisch rückgängig gemacht werden, wenn der Dynamikmanager 420 die Transaktion abbricht, welche das gesamte Delta enthält. Zusätzlich zu der Transaktion um die Ausführung jeden Kommandos führt der Dynamikmanager 420 jedes Delta innerhalb einer Transaktion aus. Nachdem die Vorrichtungen aufgerufen wurden, jegliche erfolgreich ausgeführten Kommandos rückgängig zu machen, bricht der Dynamikmanager 420 auch diese letztgenannte Transaktion ab. Diese Transaktion stellt sicher, daß jegliche Änderungen in dem geteilten Raum, die als Teil des Deltas erfolgt sind und nicht korrekt rückgängig gemacht wurden, automatisch rückgängig gemacht werden. Wenn der Dynamikmanager 420 sichergestellt hat, daß die als Teil des Deltas, welches die Ausnahme aufwies, erfolgten Änderungen rückgängig gemacht wurden, sendet er den ursprünglichen Fehler zurück an das Werkzeug 430, welches versucht hat, das Delta zu übergeben.
  • Nach der Ausführung fügt der Dynamikmanager 420 in Schritt 312 das neue Delta in das Deltaprotokoll 438 ein. Dieser Schritt ist geradlinig, da der Dynamikmanager 420 bereits in Schritt 308 den korrekten Einsetzungspunkt für das Delta bestimmt hat. Der Prozeß fährt dann über die Konnektoren 314 und 316 fort mit Schritt 318.
  • Wie zuvor beschrieben ist eine wichtige Eigenschaft eines Kollaborationssystems „Kausalität", welche erfordert, daß, wenn ein aktuelles Datenänderungskommando empfangen von einem ersten Kollaborateur durch einen zweiten Kollaborateur ausgeführt wird, der zweite Kollaborateur bereits alle vorhergehenden Datenänderungskommandos ausgeführt hat, die der erste Kollaborateur schon ausgeführt hatte, als das aktuelle Datenänderungskommando erzeugt wurde. Eine der durch den Dynamikmanager 420 bereitgestellten Haupteigenschaften ist die „vorherige Ausführung". Insbesondere stellt der Dynamikmanager 420 sicher, daß ein Endpunkt kein Delta ausführt, bis er alle Deltas ausgeführt hat, die durch den Erzeuger des Deltas bereits ausgeführt worden waren als das Delta erzeugt wurde. Zum Sicherstellen der vorherigen Ausführung werden in Schritt 318 Abhängigkeiten in jedem Delta gespeichert.
  • Deltaabhängigkeiten beschreiben alle vorhergehenden Deltas, die auf dem Endpunkt ausgeführt wurden, welcher das Delta erzeugt hat. Zum Beispiel ist die folgende Transaktion in Betracht zu ziehen, die in fünf Schritten stattfindet:
    • 1) Endpunkt A erzeugt Delta A1.
    • 2) Endpunkt A erzeugt Delta A2.
    • 3) Nach Empfang von Delta A2 erzeugt Endpunkt B Delta B1.
    • 4) Nach Empfang von Delta B1 erzeugen die Endpunkte A und B gleichzeitig die Deltas A3 und B2.
    • 5) Nach Empfang der Deltas A3 und B2 erzeugt der Endpunkt C Delta C1.
  • In dieser Situation ist für jedes Delta, wie Delta A2, 2 die Folgenummer, und A ist als ein Kurzschriftvermerk für die Erzeugungs-ID wie oben beschrieben gedacht. Somit steht der Vermerk A2 für die Deltafolge. „Gleichzeitige" Erzeugung bedeutet, daß der Endpunkt A Delta A3 erzeugt, bevor er Delta B2 empfängt, und Endpunkt B erzeugt Delta B2, bevor er Delta A3 empfangt. Die entstehenden Deltas sollen „unabhängig" sein.
  • Eine Möglichkeit zum Angeben der Abhängigkeiten wäre das Stempeln jeden Deltas mit den Deltafolgen aller Deltas, die zuvor ausgeführt wurden. Wenn dies in dem oben angegebenen Beispiel erfolgt, wäre der Abhängigkeitssatz auf jedem Delta wie in der folgenden Deltaliste in Klammern angegeben:
    A1 {}
    A2 {A1}
    B1 {A1,A2}
    A3 {A1,A2,B1}
    B2 {A1,A2,B1}
    C1 {A1,A2,B1,A3,B2}
  • Wenn immer mehr Deltas erzeugt werden, wächst der Satz von Abhängigkeiten kontinuierlich an. Um die Zahl der Abhängigkeiten zu verringern, werden implizite Abhängigkeiten eliminiert. Zum Beispiel ist Delta B1 abhängig von Delta A2 und Delta A2 ist abhängig von Delta A1. Daher ist die Abhängigkeit von Delta B1 von Delta A1 bereits in der A2-Abhängigkeit von Delta B1 impliziert. Die Eliminierung dieser impliziten Abhängigkeiten führt zu den folgenden expliziten Abhängigkeiten auf den Deltas:
    A1 {}
    A2 {A1}
    B1 {A2}
    A3 {B1}
    B2 {B1}
    C1 {A3,B2}
  • Als eine weitere Optimierung kann eine implizite Abhängigkeit eines Deltas von einem vorhergehenden Delta von dem gleichen Erzeuger angenommen werden. Zum Beispiel kann angenommen werden, daß Delta A2 implizit von Delta A1 abhängig ist. Durch diese weitere Optimierung sind die entstehenden Abhängigkeiten für diese Deltas:
    A1 {}
    A2 {}
    B1 {A2}
    A3 {B1}
    B2 {}
    C1 {A3,B2}
  • Es sei darauf hingewiesen, daß es notwendig sein kann, daß ein Delta eine Vielzahl von Abhängigkeiten aufweist, wie im Fall unabhängiger Deltas. Zum Beispiel ist in der letztgenannten Abhängigkeitsliste Delta C1 abhängig sowohl von Delta A3 als auch B2, weil jedoch keine Beziehung zwischen diesen beiden Deltas besteht, muß Delta C1 explizit die Abhängigkeit von ihnen beiden beinhalten.
  • Das Pflegen einer Liste von Abhängigkeiten für das nächste Delta erzeugt durch einen Endpunkt ist geradlinig. Der Dynamikmanager 420 enthält einen Satz neuer Abhängigkeiten. Jedes Mal, wenn ein neues Delta übergeben oder assimiliert wird, wird dieser Satz durch das Entfernen jeglicher Abhängigkeiten des neuen Deltas und das anschließende Hinzufügen des neuen Deltas aktualisiert. Wenn zum Beispiel ein weiterer Endpunkt, D, in dem oben angegebenen Beispiel existiert, würde sein neuer Abhängigkeitssatz nach dem Empfang von jedem der Deltas erzeugt durch die anderen Endpunkte A, B und C oben wie Folgt erscheinen:
    A1 {A1}
    A2 {A2}
    B1 {B1}
    A3 {A3}
    B2 {A3,B2}
    C1 {C1}
  • Wenn der Endpunkt D ein neues Delta erzeugt hat, nachdem Delta C1 empfangen wurde, dann müßte Delta C1 die einzige explizite Abhängigkeit des neuen Deltas sein. Zu dem Zeitpunkt, an dem Abhängigkeiten zu dem neuen Delta hinzugefügt werden, erfolgt eine Prüfung auf jegliche Abhängigkeit von einem vorhergehenden Delta von dem gleichen Erzeuger, weil diese Abhängigkeit immer implizit ist.
  • Bevor jedes Delta an andere Kollaborateure gesendet wird, muß es „gesichert" werden. Dies beinhaltet das Verschlüsseln und den Integritätsschutz des Deltas. Weil diese Operationen relativ komplex und zeitaufwendig sein können, führt der Dynamikmanager 420 diese Operationen asynchron durch (nicht auf der Hauptleitung der Ausführung), wenn keine Transaktionen auf der Datenbank des geteilten Raumes stattfinden. Dies verhindert, daß die Verschlüsselung andere Operationen im geteilten Raum stört. Zum asynchronen Sichern eines Deltas ist es notwendig, zu diesem Zeitpunkt einige Sicherheitsinformationen in dem Delta zu speichern. Diese Sicherheitsinformationen werden später durch den Sicherheitsmanager 414 verwendet, um das Delta zu sichern. In Schritt 319 veranlaßt der Dynamikmanager 420 den Sicherheitsmanager 414 zur Speicherung sämtlicher Information, welche später benötigt werden, um das Delta zu verschlüsseln.
  • Die asynchrone Verschlüsselung und Weiterleitung des Deltas zu anderen Kollaborateuren („Verbreitung" genannt) wird eigentlich durch eine Verbreiterkomponente 425 im Dynamikmanager 420 implementiert. Diese Komponente 425 umfaßt ein Verbreiteraufreihungselement 426 in dem XML-Dokument 440, wo Deltas und andere Nachrichten, die zu verbreiten sind, aufgereiht werden. Ein Element mit einem Attribut eingestellt auf die Folgenummer des neuen Deltas wird in Schritt 320 zum Verbreiterelement 426 aufgereiht. Das Aufreihen erzeugt ein Ereignis, welches dazu führt, daß der Dynamikmanager 420 asynchron auf einem unterschiedlichen Pfad der Ausführung aufgerufen wird, um die Verbreitung tatsächlich durchzuführen. Wenn der Dynamikmanager 420 später asynchron zurückgerufen wird, ruft er wiederum die Verbreiterkomponente 425 auf, um sämtliche Deltas in der Schlange 426 zu verarbeiten. Der Verbreiter 425 nimmt das Element aus der Aufreihung, liest das Folgenummer-Attribut, öffnet das entsprechende Delta aus dem Deltaprotokoll und verarbeitet es. Nachdem das Delta für die asynchrone Verarbeitung aufgereiht wurde, wird die Transaktion auf der Datenbank des geteilten Raumes, die bei der Erzeugung des Deltas gestartet wurde, übergeben.
  • Bevor es an andere Kollaborateure gesendet wird, wird jedes Delta durch Verschlüsselung und Integritätsschutz gesichert. Die Verschlüsselung verhindert, daß, wer immer die Deltanachricht abfängt, nützliche Informationen erhält. Der Integritätsschutz ermöglicht dem Dynamikmanager zu erkennen, wenn eine andere Partei das Delta modifiziert. Beim Verarbeiten eines Deltas verwendet die Verbreiterkomponente 425 des Dynamikmanagers 420 in Schritt 322 den Sicherheitsmanager 414 zum Sichern des Deltas mit zuvor gespeicherten Informationen. Das Delta wird in einem Zweiphasenprozeß gesichert. Die erste Phase wird mit gesperrter Datenbank des geteilten Raumes initiiert. Während dieser Phase werden die relevanten Sicherheitsinformationen, wie Schlüssel, aus der Datenbank des geteilten Raumes ausgelesen. Während der zweiten Phase, welche stattfindet, ohne daß die Datenbank des geteilten Raumes gesperrt ist, wird das Delta tatsächlich gesichert.
  • Es wird nur ein Teil des Deltas an andere Kollaborateure gesendet, und nur dieser Teil wird gesichert. Sämtliche Informationen im lokalen Deltaelement werden nicht verbreitet oder gesichert. Auch werden sämtliche Kommando-Rückgängigmachen-Informationen, die nur für den lokalen Endpunkt 400 relevant sind, nicht verbreitet oder gesichert. Das Sichern eines Deltas hinterläßt das Deltaelement selbst, welches die Gruppennummer, die Folgenummer und die Abhängigkeiten unverschlüsselt (jedoch integritätsgeschützt) enthält. Diese Informationen werden möglicherweise benötigt, bevor das Delta entschlüsselt werden kann, also müssen sie unverschlüsselt gesendet werden. Die Kommando-Elemente werden verschlüsselt und als Inhalt des Sicherheitsprozesses gesendet. Ein lokales Deltaelement weist auch ein Inhaltselement auf, welches der Sicherheitsmanager 414 verwenden kann, um lokale Daten zu speichern, die für das Delta gespeichert werden müssen. Ein gesichertes Delta sieht wie Folgt aus:
    Figure 00310001
    Figure 00320001
  • Hier ist Del das Deltaelement, mit Attributen wie unten beschrieben. Das SE-Element ist das gesicherte Element mit einem einzigen Attribut, bei welchem es sich um die für das Delta verwendete Sicherheitsversion handelt. Das EC-Element ist der verschlüsselte Inhalt, der das Ergebnis der Verschlüsselung der Kommandos in dem Delta ist. Das EC-Element enthält eine base64-Codierung der verschlüsselten Kommandos (wenn die verschlüsselten Kommandos sehr groß sind, wird ein binäres Dokument anstelle eines binären Attributs verwendet). Das IV-Element ist ein Initialisierungsvektor verwendet im Verschlüsselungsalgorithmus, das KID-Element ist die Sicherheitsschlüssel-ID und das KV-Element ist die Schlüsselversionsnummer. Das Auth-Element enthält das Echtheitszeichen, welches für den Integritätsschutz des Deltas verwendet wird. Das PTSig-Element ist eine base64-codierte Signatur für das Delta.
  • Nach dem Sichern wird das Delta in Schritt 324 serialisiert. Zum Beispiel werden die Daten bei einer Ausführungsform als WBXML serialisiert, eine standardmäßige binäre Codierung für XML. Wenn das Delta binäre Dokumente aufweist, so können diese als eine MIME-Nachricht gebündelt werden.
  • Schließlich wird in Schritt 326 das serialisierte Delta an eine ausgehende Deltaschlange 408 in dem Kommunikationsmanager 406 weitergeleitet, welcher das Delta an andere Endpunkte in dem geteilten Raum sendet. Der Prozeß endet dann in Schritt 328.
  • 10A und 10B zusammengenommen veranschaulichen die Schritte in einem Prozeß zum Empfangen eines Deltas an einem Zielendpunkt 402 von einem Quellendpunkt 400. Dieser Prozeß startet in Schritt 1000 und fährt fort mit Schritt 1002, wo an einem Zielendpunkt 402 in dem geteilten Raum ein serialisiertes Delta durch den Kommunikationsmanager 410 in diesem Endpunkt 402 empfangen wird. Der Kommunikationsmanager 410 lokalisiert dann den korrekten geteilten Raum zum Handhaben des Deltas und ruft den Dynamikmanager 422 in diesem geteilten Raum auf, das empfangene Delta zu verarbeiten.
  • Der Dynamikmanager 422 deserialisiert dann das Delta in Schritt 1004. Dieser Prozeß wandelt die Deltadaten zurück in XML-Code, der in dem XML-Dokument 423 im Dynamikmanager 422 gespeichert wird. An dieser Stelle kann der Dynamikmanager 422 erkennen, daß dies ein Deltaelement ist. Alle neuen eingehenden Deltas werden in einer eingehenden Deltaschlange 434 im Dynamikmanager-XML-Dokument 423 plaziert. Diese Schlange 434 dient als eine zeitweilige Aufbewahrungsstelle, bis der Dynamikmanager 422 bereit ist, sie zu verarbeiten. Häufig wartet der Dynamikmanager 422, bis er alle Deltas von anderen Quellen, wie einem Relaisserver, empfangen hat, bevor er mit dem Verarbeiten der Deltas beginnt. Wenn der Dynamikmanager 422 bereit ist, die Daten zu verarbeiten, wird das Delta aus der eingehenden Deltaschlange 434 entfernt.
  • In Schritt 1006 erfolgt eine Prüfung, ob sich der Endpunkt, der das Delta gesendet hat, in einem „aktiven" Zustand befindet (Endpunktzustände werden unten diskutiert). Das Delta wird in Schritt 1008 „auf Eis gelegt", wenn sich der Endpunkt, der es gesendet hat, nicht in einem aktiven Zustand befindet. Dies ist erforderlich, weil das Delta, welches den Endpunkt zu dem geteilten Raum hinzugefügt hat, möglicherweise noch nicht ausgeführt wurde, und empfangene Deltas können nicht verarbeitet werden, bis es ausgeführt wurde. Somit werden alle Deltas empfangen von einem Endpunkt auf Eis gelegt, bis das Delta, welches den Endpunkt erzeugt hat, erhalten wird. Ähnlich verarbeitet, wenn ein Endpunkt, der die Deltas erzeugt hat, aus dem geteilten Raum „ausgeladen" wurde, das System kein Delta von diesem Endpunkt, es sei denn, ein anderer Endpunkt, der noch in dem geteilten Raum aktiv ist, hat dieses Delta auch ausgeführt. Auf Eis gelegte Deltas werden in einem Element für auf Eis gelegte Deltas 428 unter dem entsprechenden Erzeuger gespeichert, bis eine Entscheidung zum Ausführen des Deltas getroffen wird. Das Element für auf Eis gelegte Deltas 428 wird periodisch eliminiert. Wenn die auf Eis gelegten Deltas nicht ausgeführt werden, werden sie gelöscht, wenn die Gruppe, in welcher sie enthalten sind, aus dem Element für auf Eis gelegte Deltas 428 eliminiert wird.
  • Wenn das Delta nicht wie in Schritt 1006 bestimmt auf Eis gelegt wird, ist der sendende Endpunkt bekannt und das Delta kann in Schritt 1010 durch den Sicherheitsmanager 416 auf Integrität geprüft werden. Zu diesem Zeitpunkt ist es wichtig zu verifizieren, daß das Delta nicht verfälscht wurde, bevor mit dem Lesen der Abhängigkeiten und anderer Informationen von dem Delta fortgefahren wird. Wenn das Delta eine Integritätsprüfung nicht besteht, wird es in Schritt 1014 verworfen und der Prozeß fährt über die Konnektoren 1018 und 1022 fort, um in Schritt 1036 abgeschlossen zu werden.
  • Wenn das Delta die Integritätsprüfung in Schritt 1012 besteht, fährt der Prozeß über die Konnektoren 1016 und 1020 mit Schritt 1024 fort, wo ein Versuch unternommen wird, das Delta zu entschlüsseln. Es ist möglich, das Delta bei Schritt 1024 zu entschlüsseln, wenn der korrekte Schlüssel vorhanden ist. Weil die Abhängigkeiten des Deltas noch nicht geprüft wurden, ist es möglich, daß bestimmte Schlüssel für das Delta fehlen. Wenn dies der Fall ist, wird das Delta später entschlüsselt. Der Entschlüsselungsschritt wandelt das SE-Element im verschlüsselten Delta zurück in die Kommandos in dem Delta.
  • Als nächstes werden in Schritt 1026 die Abhängigkeiten des Deltas durch den Dynamikmanager 422 abgerufen, indem er das Abhängigkeitsattribut des Deltas prüft. Da das Abhängigkeitsattribut nicht verschlüsselt ist, können die Abhängigkeiten auch dann abgerufen werden, wenn die Entschlüsselung in Schritt 1024 nicht möglich war. Die Abhängigkeiten werden dann wie in 11A und 11B detaillierter gezeigt assimiliert, welche zusammengenommen ein Flußdiagramm bilden, welches die Schritte in dem Prozeß veranschaulicht.
  • Die Abhängigkeitsverarbeitung beginnt in Schritt 1100 und fährt fort mit Schritt 1102, wo die Liste expliziter Abhängigkeiten aus dem Attribut in dem Delta geöffnet wird. Wenn dies nicht das erste Delta von einem Erzeuger ist, wird das vorhergehende Delta von dem Erzeuger zum Beginn der Abhängigkeitsliste hinzugefügt. In Schritt 1104 erfolgt eine Bestimmung, ob alle Deltas, bei denen es sich um Abhängigkeiten handelt, verarbeitet wurden. Wenn dem so ist, fährt die Abhängigkeitsverarbeitung über die Konnektoren 1116 und 1124 fort, um in Schritt 1130 abgeschlossen zu werden.
  • Alternativ dazu ruft, wenn in Schritt 1104 bestimmt wurde, daß nicht alle Abhängigkeiten verarbeitet wurden, der Dynamikmanager 422 in Schritt 1106 die nächste Abhängigkeit von der Liste der Abhängigkeiten auf. Für jedes dieser Abhängigkeitsdeltas erfolgt in Schritt 1108 eine Prüfung, um zu bestimmen, ob dieses Abhängigkeitsdelta wie unten beschrieben assimiliert wurde. Wenn dieses Abhängigkeitsdelta bereits assimiliert wurde, kehrt der Prozeß zu Schritt 1104 zurück, um zu prüfen, ob weitere Abhängigkeiten verbleiben.
  • Wenn eines der Deltas in dem Abhängigkeitssatz nicht assimiliert wurde, dann erfolgt in Schritt 1110 eine Bestimmung, ob das nächste Delta auf Eis gelegt wurde. Wenn das Delta nicht auf Eis gelegt wurde, fährt der Prozeß über die Konnektoren 1116 und 1124 fort, um in Schritt 1130 abgeschlossen zu werden, weil das nächste Delta fehlt. Alternativ dazu fährt der Prozeß, wenn das nächste Delta wie in Schritt 1110 bestimmt auf Eis gelegt wurde, über die Konnektoren 1114 und 1120 mit Schritt 1126 fort, wo ein Versuch unternommen wird, das auf Eis gelegte Delta zu assimilieren. Wenn die Versuche erfolgreich sind, wie in Schritt 1128 bestimmt, kehrt der Prozeß über die Konnektoren 1118 und 1112 zurück zu Schritt 1104, um zu bestimmen, ob weitere Abhängigkeiten zu verarbeiten sind. Alternativ dazu wird, wenn das auf Eis gelegte Delta nicht assimiliert werden kann, wie in Schritt 1128 bestimmt, der Prozeß in Schritt 1130 abgeschlossen, weil die Abhängigkeit fehlt.
  • Wenn das neue Delta nicht assimiliert werden kann, weil einige seiner Abhängigkeiten nicht verarbeitet werden können, wird es in ein Deltabehältnis 442 verschoben. Das Deltabehältnis ist eine XML-Datenstruktur in dem XML-Dokument 423 in Zusammenhang mit dem Dynamikmanager 422. Es weist eine Struktur 1200 wie in 12 gezeigt auf. Das Deltabehältnis 1200 umfaßt ein DelHldr-Element 1202, welches das Deltabehältnis darstellt. Dieses Element weist ein ActiveBlockNum-Attribut auf, welches die Nummer des derzeit aktiven Blocks enthält. Das DelHldr-Element 1202 wiederum umfaßt ein oder mehrere HldGrp-Elemente, von denen jedes eine Gruppe gehaltener Deltas und Endpunktimpulse, die alle auf die gleiche Abhängigkeit warten, darstellt. Jedes dieser Elemente weist ein Dep-Attribut auf, welches die Abhängigkeit spezifiziert, auf die alle gehaltenen Deltas und Impulse warten. Jedes HldGrp-Element umfaßt ein oder mehrere LDel-Elemente, von denen jedes ein gehaltenes Delta darstellt, und ein oder mehrere EptPul-Elemente, von denen jedes einen gehaltenen Impuls darstellt. Das neue Delta wird in einem HldGrp-Element des Deltabehältnisses 442 gespeichert, welches dem fehlenden Abhängigkeitsdelta entspricht.
  • Wenn das fehlende Abhängigkeitsdelta nicht auf Eis gelegt ist, wie in Schritt 1110 bestimmt, dann versucht der Dynamikmanager 422, das Abhängigkeitsdelta von anderen Endpunkten in dem geteilten Raum zu holen. Insbesondere wird eine Holen-Anforderung an einen anderen Endpunkt gesendet, bei einem Versuch, das Delta abzurufen. Zum Erhöhen der Effizienz können Holen-Anforderungen für alle Deltas gesammelt und mit einer Anforderung angefordert werden.
  • Da die Zahl der Deltas, die von einem anderen Endpunkt zu holen sind, groß sein kann und daher das Holen über einen signifikanten Zeitraum hinweg stattfinden kann, ist es notwendig zu verhindern, daß ein Endpunkt mehrfache Holen-Anforderungen für die gleichen Deltas ausgibt, während er noch die Deltas von einer vorhergehenden Anforderung empfängt. Mehrfaches erneutes Holen wird durch Zuweisung einer Folgenummer zu jeder Holen-Anforderung verhindert. Wenn die eingehende Holen-Anforderung eine Folgenummer aufweist, die nicht hoch genug ist, dann sendet ein Endpunkt, der die Anforderung empfängt, die angeforderten Deltas nicht. Eine Holen-Beantworten-Folgenummer ist für jeden Endpunkt gespeichert und wird verwendet, wenn eine Holen-Anforderung durch diesen Endpunkt empfangen wird. Außerdem ist eine Holen-Anforderung-Folgenummer für jeden Endpunkt gespeichert und wird verwendet, wenn dieser Endpunkt eine Holen-Anforderung an einen anderen Endpunkt erzeugt. Diese Folgenummern beginnen beide mit Null und werden auf folgende Art und Weise verwendet.
  • Der Holen-Prozeß ist in 13 veranschaulicht, welcher mit Schritt 1300 beginnt und mit Schritt 1302 fortfährt, wo eine Holen-Anforderung in einem ersten Endpunkt, zum Beispiel Endpunkt A, erzeugt wird und in Schritt 1304 an einen anderen Endpunkt, zum Beispiel Endpunkt B, gesendet wird. Wenn eine solche Holen-Anforderung erzeugt wird, umfaßt sie die Holen-Anforderung-Folgenummer. Wenn in Schritt 1306 eine Holen-Anforderung empfangen wird, wird die Holen-Anforderung-Folge in der Anforderung mit der gespeicherten Holen-Beantworten-Folgenummer im empfangenden Endpunkt verglichen. Wenn die beiden Folgenummern gleich sind, dann ist die Holen-Anforderung gültig, und in Schritt 1308 werden die angeforderten Deltas zurück an den Endpunkt A geleitet. Der empfangende Endpunkt erhöht dann seinen gespeicherten Wert der Holen-Beantworten-Folge wie in Schritt 1310 dargelegt. Als nächstes sendet der empfangende Endpunkt in Schritt 1312 eine Holen-Folgenummer-Aktualisierungsnachricht, die den Wert der Holen-Beantworten-Folgenummer enthält, an den anfordernden Endpunkt. Wenn jedoch die Holen-Anforderung ungültig ist, wie in Schritt 1306 bestimmt, dann werden die angeforderten Deltas nicht gesendet. Statt dessen wird in Schritt 1312 nur die Aktualisierungsnachricht gesendet.
  • Wenn die Holen-Folge-Aktualisierungsnachricht am sendenden Endpunkt empfangen wird, aktualisiert der sendende Endpunkt seine Holen-Anforderung-Folgenummer wie in Schritt 1314 dargelegt. Insbesondere wenn die Holen-Beantworten-Folgenummer in der empfangenen Nachricht größer ist als die durch den sendenden Endpunkt verwendete aktuelle Holen-Anforderung-Folgenummer, stellt der Endpunkt seine Holen-Anforderung-Folgenummer auf die Folgenummer in der Aktualisierungsnachricht ein. Ansonsten ändert der sendende Endpunkt seine Holen-Anforderung-Folgenummer nicht. Der Prozeß endet dann in Schritt 1316.
  • Folgendes ist ein Beispiel der Verwendung dieser Folgenummern. Es wird angenommen, daß zwei Endpunkte A und B existieren, jeder mit internen gespeicherten Werten der Holen-Anforderung-Folgenummern und Holen-Beantworten-Folgenummern mit Werten von Null. Der Endpunkt A realisiert, daß ihm die Deltas 1–100 fehlen und er sendet eine Holen-Anforderung für diese Deltas an den Endpunkt B. Diese Holen-Anforderung hat eine Holen-Anforderung-Folgenummer mit einem Wert von Null. Der Endpunkt B empfangt die Holen-Anforderung, vergleicht die Folgenummer darin mit seiner gespeicherten Holen-Beantworten-Folgenummer (mit einem Wert von Null) und bestimmt, daß die Holen-Anforderung gültig ist. Der Endpunkt B sendet dann die angeforderten Deltas an Endpunkt A und erhöht seine gespeicherte Holen-Beantworten-Folge für den Endpunkt A auf einen Wert von Eins. Der Endpunkt B sendet auch eine Holen-Folge-Aktualisierungsnachricht an den Endpunkt A, welche eine Folgenummer von Eins trägt.
  • Angenommen Endpunkt A empfangt die Deltas 1–20, entscheidet jedoch, die Deltas 21–100 noch einmal anzufordern, auch wenn sich diese Deltas und die Holen-Folge-Aktualisierungsnachricht noch in der Übertragung befinden. Der Endpunkt A sendet eine weitere Anforderung mit einer Holen-Anforderung-Folgenummer mit einem Wert von Null. Der Endpunkt B empfangt die neue Holen-Anforderung von Endpunkt A und realisiert, daß die Anforderung ungültig ist, weil die Holen-Anforderung-Folgenummer darin (mit einem Wert von Null) niedriger ist als seine aktuelle Holen-Beantworten-Folgenummer für den Endpunkt A (mit einem Wert von Eins). Daher sendet der Endpunkt B die Deltas 21–100 nicht noch einmal, sondern er sendet statt dessen eine weitere Holen-Folge-Aktualisierungsnachricht, welche eine Aktualisierungsfolgenummer mit einem Wert von Eins trägt.
  • Der Endpunkt A schließt dann den Empfang der Deltas 21–100 ab und empfangt auch die erste Holen-Folge-Aktualisierungsnachricht. Dementsprechend aktualisiert der Endpunkt A seine interne Holen-Anforderung-Folgenummer auf einen Wert von Eins. Der Endpunkt A ignoriert die zweite Holen-Folge-Aktualisierungsnachricht, weil der darin getragene Wert der Aktualisie rungsfolgenummer niedriger als oder gleich seiner gespeicherten Holen-Anforderung-Folgenummer ist. Dadurch werden die gleichen Deltas nicht zweimal gesendet.
  • Die Holen-Anforderung- und Holen-Beantworten-Folgenummern sind in der Datenstruktur eines Endpunktes gespeichert, die Teil des XML-Dokuments 423 ist. Eine Beispiel-XML-Datenstruktur zum Aufnehmen von Endpunktinformationen ist in 14A und 14B gezeigt, die zusammengenommen eine veranschaulichende XML-Struktur 1400 zum Speichern von Informationen in bezug auf die Endpunkte zeigen. Die Struktur umfaßt eine Reihe von XML-Elementen. Das Epts-Element 1402 stellt die Sammlung von Endpunkten dar. Dieses Element 1402 weist ein NDeps-Attribut auf, welches die neuen Abhängigkeiten enthält, die auf dem nächsten Delta eingestellt werden müssen, welches dieser Endpunkt erzeugt. Das Epts-Element enthält ein oder mehrere Ept-Elemente 1404, 1406, von denen jedes einen einzelnen Endpunkt darstellt.
  • Jedes Ept-Element 1404 weist eine Reihe von Attributen auf, einschließlich eines ContactURL-Attributs, welches die Kontakt-URL des Endpunktes enthält. Ein CreationId-Attribut enthält die Folge des Deltas, welches den Endpunkt erzeugt hat, oder die Bemerkung „Erster", wenn dieser Endpunkt den geteilten Raum erzeugt hat. Ein DeviceURL-Attribut enthält die Geräte-URL des Endpunktes. Ein HGN-Attribut enthält die höchste Gruppennummer für diesen Endpunkt, erklärt durch einen Impuls oder durch Erzeugung eines Deltas. Das HIP-Attribut speichert den höchsten Einsetzungspunkt für ein Delta erzeugt durch den Endpunkt. Ein OldCreationIds-Attribut enthält Folgen von Deltas, die zuvor diesen Endpunkt in den geteilten Raum eingeladen hatten.
  • Ein OutOfDateTime-Attribut ist eingestellt auf die Zeit, zu der das erste lokale Delta seit der letzten Nachricht empfangen von dem Endpunkt erzeugt wurde. Ein PendingLaggard-Attribut ist eingestellt, wenn der Endpunkt ein Nachzügler wie unten beschrieben ist. Das PurGrp-Attribut enthält die höchste Gruppe, für die dieser Endpunkt seine Bereitschaft zum Eliminieren erklärt hat. Ein Reqs-Attribut speichert Deltas, die benötigt werden, um enthaltene Deltas von dem Endpunkt zu assimilieren, und ein ReqSeq-Attribut enthält die Holen-Anforderung-Folgenummer, die zu verwenden ist, wenn die nächste Holen-Anforderung an dem Endpunkt empfangen wird. Ein RespSeq-Attribut enthält die letzte Holen-Beantworten-Folgenummer, die an den Endpunkt gesendet wurde, nachdem auf eine seiner Holaktionen reagiert wurde.
  • Das SPG-Attribut speichert eine sekundäre Eliminierungsgruppe, die verwendet wird, um zu bestimmen, was unter Randbedingungen, wie wenn ein Endpunkt keine Deltas erzeugt hat, eliminiert wird. Ein State-Attribut enthält den Zustand des Endpunktes für die Verwendung bei Eliminierungsentscheidungen, die unten diskutiert werden. Das UID-Attribut enthält die einmalige ID des Endpunktes. Bei einer Ausführungsform ist dies ein Rautenzeichen des Wertes im ContactURL- und DeviceURL-Attribut.
  • Jedes der Ept-Elemente, zum Beispiel das Element 1404, enthält ein oder mehrere Erzeuger-Elemente 1408–1418, von denen jedes einen Erzeuger darstellt, und ein PndgDels-Element 1420, welches als ein Ursprung für ausstehende Deltas verwendet wird. Jedes Creator-Element steht für einen Erzeuger. Jedes Mal, wenn ein Endpunkt einen Raum wieder öffnet, erzeugt er einen neuen Erzeuger zur Verwendung, wenn er Deltas erzeugt. Dieser Erzeuger weist eine zufällige ID auf, die verwendet wird, um im Falle eines Crashs oder eines anderen Ereignisses, welches den Verlust von Informationen verursachen kann, sicherzustellen, daß Delta-Folgen einmalig sind. Jedes Creator-Element weist mehrere Attribute auf, einschließlich eines HIP-Attributs, welches den Einsetzungspunkt des höchsten Deltas erzeugt durch den Erzeuger enthält. Ein LastUID-Attribut enthält die letzte Folge verwendet beim Erzeugen einer einmaligen ID für diesen Erzeuger. Ein PurgeGrp-Attribut speichert die Nummer einer Gruppe, die, wenn sie eliminiert wird, zuläßt, daß der Erzeuger gelöscht wird. Ein SubNum-Attribut enthält die letzte Teil-Folgenummer verwendet auf einem identitätsgerichteten oder asynchronen Delta erzeugt durch diesen Erzeuger wie unten beschrieben.
  • Das PndgDels-Element (434, 4) ist der Ursprung jedes ausstehenden Deltas. Wie bereits zuvor erwähnt, sind ausstehenden Deltas Deltas, welche der Dynamikmanager assimilieren möchte oder nicht. Ausstehende Deltas treten nur auf, wenn Deltas empfangen werden, bevor ein Endpunkt zu dem Raum hinzugefügt wird oder nachdem ein Endpunkt entfernt wurde. Das PndgDels-Element 1420 enthält ein oder mehrere LDel-Elemente 1422, von denen jedes ein Delta darstellt.
  • Zurückkehrend zu 10A und 10B, fährt, nachdem der Dynamikmanager in Schritt 1026 versucht hat, alle Abhängigkeiten zu assimilieren, der Prozeß mit Schritt 1028 fort, wo eine Bestimmung erfolgt, ob alle Abhängigkeiten assimiliert wurden. Wenn nicht, fährt der Prozeß mit Schritt 1030 fort, wo das ursprüngliche Delta gehalten wird. Der Prozeß wird dann in Schritt 1036 abgeschlossen.
  • Wenn alternativ dazu in Schritt 1028 bestimmt wird, daß alle Abhängigkeiten assimiliert wurden, fährt der Prozeß mit Schritt 1032 fort, wo das neue Delta auch assimiliert wird. Das Assimilieren eines Deltas besteht aus der Erzeugung einer Transaktion in der Datenbank des geteilten Raumes und dem Verschieben des Deltas in das Deltaprotokoll 444. Wie oben disku tiert, wurde jedes Delta zuvor mit einer Gruppennummer und einer Folge gestempelt. So beginnt der Prozeß des Einfügens eines Deltas in das Deltaprotokoll 444 mit der Bestimmung des korrekten Gruppenelements in dem Deltaprotokoll 444. Wenn die Gruppe nicht existiert, wird sie an dieser Stelle erzeugt. Dann wird die Gruppe auf eine Kette geprüft, welche der ErzeugerID in der Delta-Folge entspricht. Auch hier, wenn die Kette nicht existiert, dann wird sie erzeugt. Das zu assimilierende Delta wird an das Ende der Kette hinzugefügt.
  • Nachdem ein Delta assimiliert wurde, wird es ausgeführt, bevor der Dynamikmanager 422 die aktuelle Transaktion auf der Datenbank des geteilten Raumes übergibt. Fehler, die während der Deltaausführung auftreten, werden durch Überspringen oder Wiederholen von Kommandos, die ausgeführt worden sind, gehandhabt. Außerdem wird die Transaktion, die um die Deltaausführung herum gestartet wurde, abgebrochen. Die Deltaausführungsfehler werden gehandhabt, wenn jedes Delta ausgeführt wird und bevor die aktuelle Transaktion übergeben wird. Um das Überspringen und Wiederholen einzuschränken, versucht der Dynamikmanager 422, so viele Deltas wie möglich vor deren Ausführung zu assimilieren. Daher verfolgt das Deltaprotokoll 444, wie viele Deltas assimiliert, jedoch nicht ausgeführt wurden. Diese Zahl wird verwendet, um sicherzustellen, daß alle Deltas ausgeführt werden.
  • Nach dem Assimilieren des Deltas, kann es nun möglich sein, weitere Deltas zu assimilieren, welche von dem assimilierten Delta abhängig sind. Diese Deltas werden „Abhängige" genannt. Diese letztgenannte Assimilierung erfolgt in Schritt 1034. Speziell werden innerhalb des Deltabehältnisses 442 Deltas basierend auf dem Delta gruppiert, auf welches sie warten. Wann immer also ein Delta assimiliert wird, erfolgt eine Prüfung zum Bestimmen, ob es Deltas in dem Deltabehältnis 442 gibt, die auf dieses Delta gewartet haben. Wenn solche Deltas existieren, wird versucht, diese Deltas zu assimilieren. Während dieser letztgenannten Assimilierung erfolgt eine Prüfung zu den Abhängigkeiten von diesen Deltas, und wenn sie nun alle assimiliert sind, können auch die abhängigen Deltas assimiliert werden. Die Deltaverarbeitung wird in Schritt 1036 abgeschlossen.
  • Der Ausführungsprozeß ist in 15A und 15B detaillierter veranschaulicht. Dieser Prozeß beginnt mit Schritt 1500 und fährt fort mit Schritt 1502, wo der Dynamikmanager 422 das Deltaprotokoll 444 rückwärts abschreitet, beginnend vom Ende des Deltaprotokolls, und sich zum Beginn des Protokolls vorarbeitet. Insbesondere da das Protokoll in Ketten, Gruppen und Blöcken angeordnet ist, ist das Ende des Protokolls das letzte Delta in der letzten Kette in der letzten Gruppe im letzten Block. Jedes Delta in der letzten Kette wird geprüft, und dabei erfolgt eine Bewegung in Richtung des Beginns der Kette. Wenn der Beginn der letzten Kette erreicht ist, fährt der Prozeß fort mit dem letzten Delta in der vorletzten Kette und so weiter, bis alle Deltas in der ersten Kette in der Gruppe geprüft wurde. Dann fährt der Prozeß fort mit dem letzten Delta in der letzten Kette in der vorhergehenden Gruppe. Wenn die erste Gruppe in einem Block erreicht ist, fährt der Prozeß fort mit dem letzten Delta der letzten Kette der letzten Gruppe in dem vorhergehenden Block. Die Operation wird in dieser Art und Weise fortgesetzt, bis alle neu assimilierten Deltas gefunden sind.
  • Wenn ein gerade geprüftes Delta nicht ausgeführt wurde, kehrt der Prozeß wie in Schritt 1504 bestimmt zu Schritt 1502 zurück, wo das nächste Delta geprüft wird. Wenn jedoch das gerade geprüfte Delta wie in Schritt 1504 bestimmt ausgeführt wurde, prüft der Dynamikmanager 422 in Schritt 1506, um zu bestimmen, ob es mit einem der anderen assimilierten Deltas kollidiert. Während des zuvor beschriebenen Assimilierungsprozesses wird ein Satz der zuvor erwähnten Konfliktzeichenketten aller assimilierten Deltas aufgebaut. Die Konfliktprüfung erfolgt durch Vergleichen der Konfliktzeichenkette des gerade geprüften Deltas mit allen Konfliktzeichenketten im Konfliktzeichenkettensatz. Wenn die Zeichenketten in einem Paar von Zeichenketten die gleichen sind oder wenn eine der verglichenen Zeichenketten leer ist, dann kollidieren die entsprechenden Deltas. Wenn es nicht zu einem Konflikt kommt, kehrt der Prozeß zu Schritt 1502 zurück, wo das nächste Delta geprüft wird.
  • Wenn es, wie in Schritt 1506 bestimmt, zu einem Konflikt kommt, dann wiederholt der Dynamikmanager in Schritt 1508 das Delta. Wie zuvor erwähnt, muß der Dynamikmanager 422 sicherstellen, daß unterschiedliche Endpunkte konvergieren, indem sichergestellt wird, daß alle der Deltas in einer konsistenten Reihenfolge in jedem Endpunkt ausgeführt werden. Es besteht die Möglichkeit, daß eines der neu assimilierten Deltas an einer Stelle im Deltaprotokoll 444 vor der Stelle eines unabhängigen Deltas, welches bereits ausgeführt wurde, assimiliert wurde. Wenn es zu einer solchen Situation kommt, muß zum Sicherstellen der Konvergenz das bereits ausgeführte Delta „wiederholt" werden, bevor die assimilierten Deltas ausgeführt werden, und dann wird es „übersprungen", nachdem die assimilierten Deltas ausgeführt worden sind.
  • Das Wiederholen eines Deltas besteht aus der Iteration über die Kommandos in dem Delta in umgekehrter Reihenfolge. Wenn jedes Kommando gefunden ist, wird die Vorrichtung 436 aufgerufen, um die Auswirkung des Kommandos rückgängig zu machen. Die Vorrichtung 436 hat Zugang zum Kommando-Element und dem Kommando-Rückgängigmachen-Element in jedem Delta, welches die Vorrichtung zuvor erzeugt hat, als das Delta das letzte Mal ausgeführt wurde. Wenn während der Wiederholung eines Kommandos in dem Delta ein Fehler auftritt, versucht der Dynamikmanager 422, sämtliche Kommandos in diesem Delta, welches bereits wiederholt worden war, erneut auszuführen, so daß das Delta im ausgeführten Zustand verbleibt. Der Prozeß fährt dann fort mit Schritt 1510, wo eine Bestimmung erfolgt, ob alle neuen Deltas geprüft wurden. Wenn nicht, kehrt der Prozeß zurück zu Schritt 1502, um die Prüfung von Deltas fortzusetzen.
  • Wenn alle neuen Deltas wie in Schritt 1510 bestimmt geprüft wurden, fährt der Prozeß über die Konnektoren 1512 und 1514 fort mit Schritt 1516, wo der Überspringen-Prozeß beginnt. In Schritt 1516 wird das Deltaprotokoll durchsucht und jedes Delta noch einmal geprüft. In Schritt 1518 erfolgt eine Bestimmung, ob das gerade geprüfte Delta wiederholt wurde. Wenn dem so ist, fährt der Prozeß mit Schritt 1520 fort. Alternativ dazu, wenn das Delta nicht wiederholt wurde, entweder weil es nicht zu einem Konflikt wie in Schritt 1506 bestimmt kam, oder weil während der Wiederholung ein Fehler aufgetreten ist, bestimmt der Dynamikmanager 422 in Schritt 1522, ob es sich bei dem Delta um ein neues Delta handelt. Wenn das Delta kein neues Delta ist, tut der Dynamikmanager 422 nichts und der Prozeß fährt fort mit Schritt 1528. Wenn jedoch der Dynamikmanager in Schritt 1522 bestimmt, daß das Delta ein neues Delta ist, dann wird in Schritt 1524 und 1526 das neue Delta entschlüsselt und ausgeführt. Der Prozeß fährt dann fort mit Schritt 1528.
  • Wenn das Delta erfolgreich wiederholt wurde, wie in Schritt 1518 bestimmt, dann beginnt der Dynamikmanager 422 in Schritt 1520 mit einem Überspringen oder einer erneuten Ausführung aller Kommandos in dem Delta. Dieser Prozeß ist genau wie der Prozeß der Ausführung des Deltas zuerst. Während dieser Überspringen-Operation findet der Dynamikmanager 422 alle neu assimilierten Deltas, einschließlich des Deltas, welches die Verarbeitung initiiert hat. Obwohl der Dynamikmanager dieses letztgenannte Delta bereits auf Integrität geprüft hat, wäre es möglich, daß es zu dem Zeitpunkt wie oben erläutert nicht entschlüsselt werden konnte. Wenn das Delta zuvor nicht entschlüsselt wurde, dann wird es als Teil des Überspringen-Prozesses entschlüsselt. An dieser Stelle sind alle Abhängigkeitsdeltas ausgeführt worden. Daher steht der zum Entschlüsseln des Deltas benötigte Schlüssel zur Verfügung und die Entschlüsselung sollte erfolgreich sein.
  • Die erneute Ausführung der Kommandos in dem Delta erfolgt auf die gleiche Art und Weise wie die oben beschriebene Ausführung von Kommandos zum Ausführen eines Deltas auf dem Endpunkt, welches es erzeugt hat. Jedoch ist es im Falle eines Fehlers während der Ausführung nicht möglich, dem Werkzeug, welches das Delta erzeugt hat, eine Ausnahme zuzuweisen, weil sich das Werkzeug auf einem unterschiedlichen Gerät befindet. Statt dessen wird, wenn solche Fehler auftreten, nach dem Wiederholen jeglicher erfolgreich ausgeführter Kommandos und dem Abbruch der Transaktionen, das Delta nur markiert, daß es eine Ausnahme bei der Ausführung aufwies, und der Dynamikmanager fahrt mit dem Prozeß fort.
  • Ausnahmen während der Ausführung von Deltas, welche neue Endpunkte zum Raum hinzufügen, werden unterschiedlich behandelt. Wenn ein Endpunkt in dem Raum erfolgreich den neuen Endpunkt hinzufügt, ist es notwendig, daß der Dynamikmanager den Endpunkt auf allen anderen Endpunkten in dem geteilten Raum hinzufügt. Dies kann in bestimmten Situationen ein Problem sein, zum Beispiel wenn dem Einladenden des neuen Endpunktes die Zulassung für das Hinzufügen eines Mitglieds unabhängig von der Einladung entzogen wurde. Um diese Fälle zu handhaben, fährt der Dynamikmanager nach einer Ausnahme mit dem Ausführen weiterer Kommandos in einem Delta zum Hinzufügen eines Endpunktes fort.
  • In jedem Fall fährt der Prozeß dann mit Schritt 1528 fort, wo eine Bestimmung erfolgt, ob der Überspringen-Prozeß abgeschlossen ist. Wenn nicht, kehrt der Prozeß zurück zum Durchsuchen des Deltaprotokolls in Schritt 1516. Wenn die Überspringen-Operation abgeschlossen ist, endet der Prozeß mit Schritt 1530.
  • Die oben beschriebenen Prozesse veranschaulichen das Erzeugen, Übertragen und Empfangen normaler Deltas. Jedoch wurden gemäß der Grundlagen der Erfindung, spezielle Deltas erzeugt, um mehrere spezielle Situationen zu handhaben. Zu diesen letztgenannten Deltas zählen asynchrone Deltas, Identität-verbreitet-Deltas und Prioritätsdeltas. Asynchrone Deltas werden nicht als Teil des normalen Kommunikationsverkehrs innerhalb eines geteilten Raumes gesendet. Statt dessen werden sie für das Übertragen sehr großer Dateien verwendet, um zu verhindern, daß die Deltas, welche diese enthalten, die Übertragung anderer Deltas in dem geteilten Raum für einen langen Zeitraum blockieren, sowie zum Unterstützen der Übertragung asymmetrischer Dateien. Asynchrone Deltas weisen bestimmte Unterschiede gegenüber normalen Deltas auf. Der wichtigste dieser Unterschiede ist, daß keine zukünftigen Deltas von einem asynchronen Delta abhängig sein können. Daher können weitere Deltas in dem geteilten Raum ausgeführt werden, bevor das asynchrone Delta ankommt und asynchrone Deltas müssen nicht ausgeführt werden, um die Konsistenz zu wahren. Außerdem holt der Dynamikmanager keine fehlenden asynchronen Deltas von anderen Endpunkten und somit ist ihre Bereitstellung nicht so zuverlässig wie die normale Deltabereitstellung. Und schließlich ist es, weil keine Deltas von einem asynchronen Delta abhängig sind, nicht notwendig, asynchrone Deltas an alle Endpunkte in dem geteilten Raum zu senden. Diese Eigenschaft macht das Übertragen asynchroner Deltas an spezifische Endpunkte viel einfacher als dies bei normalen Deltas der Fall ist und es ermöglicht die Unterstützung asymmetrischer Dateien.
  • Jedoch weisen asynchrone Deltas Abhängigkeiten auf, die es dem Dynamikmanager ermöglichen, die vorherige Ausführung zu garantieren, d.h., wenn ein asynchrones Delta an einem entfernten Endpunkt ausgeführt wird, dann sind alle nichtasynchronen Deltas, die der Erzeuger zur Erzeugungszeit des asynchronen Deltas ausgeführt hatte, auch auf dem entfernten Endpunkt ausgeführt worden. Asynchrone Deltas weisen auch einen gut definierten Einsetzungspunkt im Deltaprotokoll auf und können vor der Ausführung von Deltas mit niedrigeren Deltaprotokoll-Einsetzungspunkten wiederholt werden. Weitere Deltas mit einem höheren Deltaprotokoll-Einsetzungspunkt werden vor der Ausführung eines asynchronen Deltas wiederholt. Bei asynchronen Deltas kann keine Ausführung in der gleichen relativen Reihenfolge auf allen Endpunkten garantiert werden und daher besteht im Falle asynchroner Deltas keine Konvergenz.
  • Asynchrone Deltas können mit anderen Deltas im geteilten Raum verschachtelt sein und sie können mit einer niedrigeren Priorität gesendet werden. Zum Beispiel kann eine große Datei mit einer Kombination aus normalen und asynchronen Deltas übertragen werden. Normale Deltas werden verwendet, um einen Dateideskriptor zu senden und asynchrone Deltas werden verwendet, um den Dateiinhalt zu senden. Ein GUID wird verwendet, um Deskriptoren mit Inhalten am Ziel abzugleichen. Das asynchrone Delta, welches den Dateiinhalt enthält, kann gesendet werden, sobald die Datei hinzugefügt ist (symmetrische Dateien), oder es kann nur gesendet werden, wenn ein entfernter Endpunkt die Datei anfordert (asymmetrische Dateien). Die XML-Struktur eines asynchronen Deltas ist die gleiche wie ein normales Delta, wie in 5 veranschaulicht, außer daß ein Async-Attribut auf dem Del-Element eingestellt ist, wenn das Delta asynchron ist.
  • Identitätsgerichtete Deltas sind dazu ausgelegt, ungelesene Markierungen und andere Informationen zu unterstützen, die nur anderen Instanzen des geteilten Raumes für eine Identität bekannt sein müssen. Identitätsgerichtete Deltas können nur bei der lokalen Identität adressiert werden. Diese Deltas werden nur an einen Teilsatz der Endpunkte in dem geteilten Raum gesendet, wo dieser Teilsatz aus den Endpunkten des Mitglieds besteht, welches das Delta erzeugt hat. Wie bei asynchronen Deltas können keine anderen Deltas von einem Identitätverbreitet-Delta abhängig sein, somit unterstützen Identität-verbreitet-Deltas die Konvergenz oder Zuverlässigkeit nicht.
  • Der Dynamikmanager 422 handhabt asynchrone und Identität-verbreitet-Deltas als „Teil-Deltas". Anstatt der Identifizierung durch eine Delta-Folge weisen Teil-Deltas eine Delta-„Teil-Folge" auf. Eine Teil-Folge ist die Folge des letzten Deltas, welches durch den Erzeuger erzeugt wurde, gefolgt von einer Teil-Nummer. Die Teil-Nummer wird jedes Mal erhöht, wenn ein neues Teil-Delta ausgeführt wird. Wenn zum Beispiel der Erzeuger A ein Delta ausführt, dann zwei Identität-verbreitet-Deltas, dann ein anderes Delta und abschließend ein anderes Identität-verbreitet-Delta, dann hätten diese Deltas und Teil-Deltas die folgenden Folgen und Teil-Folgen:
    A1, A1.1, A1.2, A2, A2.1
  • Wie normale Deltas werden Teil-Deltas immer am Ende des Deltaprotokolls eingefügt und weisen eine/n feste/n Gruppennummer und Einsetzungspunkt in dem Deltaprotokoll auf. Im obigen Beispiel wird A1.1 immer nach A1 und vor A2 eingefügt. Es könnte in der gleichen Gruppe vorliegen wie A1, in der gleichen Gruppe wie A2 oder in einer Gruppe zwischen den beiden. Weil Teil-Deltas möglicherweise nicht an alle Endpunkte gesendet werden, gibt es eine viel höhere Wahrscheinlichkeit, daß andere Endpunkte Deltas erzeugen, die in bezug auf Teil-Deltas unabhängig sind. Dies erhöht die Wahrscheinlichkeit enorm, daß ein Teil-Delta wiederholt wird. Jedoch sendet wegen einer begrenzten Zahl von Deltas pro Gruppe ein Endpunkt, welcher unabhängige Deltas erzeugt, die Gruppennummer voraus, und dann kommen die unabhängigen Deltas nach den Teil-Deltas. Dadurch wird die Anzahl der Wiederholungen von Teil-Deltas eingeschränkt.
  • Abhängigkeiten werden auf einem Teil-Delta in einer Art und Weise eingestellt, die ähnlich der eines normalen Deltas ist. Weil das Teil-Delta nicht an alle Endpunkte gesendet wird, werden die Abhängigkeiten nicht von der neuen Abhängigkeit entfernt, welche eingestellt wurde, nachdem die Abhängigkeiten auf einem Teil-Delta eingestellt wurden. In dem Beispiel oben, würden die Deltas folgende Abhängigkeiten aufweisen:
    A1 {}
    A1.1 {A1}
    A1.2 {A1}
    A2 {A1}
    A2.1 {A2}
  • Es sei darauf hingewiesen, daß, weil sie sich alle auf vorhergehenden Deltas von diesem Endpunkt befinden, diese Abhängigkeiten nicht explizit auf den Deltas eingestellt sind. Weil Teil-Deltas nicht an alle Endpunkte gesendet werden, können sie keine neuen Sicherheitsschlüs sel für den Raum enthalten. Beim Sichern von Deltas sendet der Dynamikmanager keinen erneuten Schlüssel in einem Teil-Delta.
  • Eine XML-Datei auf einem Identität-verbreitet-Delta ist in 16 gezeigt. Dieses Delta 1600 umfaßt ein Kommando und Rückgängigmachen-Informationen für dieses Kommando und ein ausführungsverschachteltes Delta mit einem Kommando und Rückgängigmachen-Informationen für dieses Kommando. Das IdDiss-Attribut 1602 des Del-Elements 1604 ist eingestellt, wenn es sich bei dem Delta um ein Identität-verbreitet-Delta handelt. Das SubSeq-Attribut 1606 des Del-Elements 1604 enthält eine Teil-Folge des Deltas.
  • Prioritätsdeltas werden verwendet, um zwei Situationen zu adressieren, welche im oben beschriebenen Delta-Verbreitungssystem auftreten. Die erste Situation ist die, daß wenn ein neuer Endpunkt in einen geteilten Raum eingeladen wird, dieser den Inhalt eines Deltaprotokolls senden muß, welches alle vorhergehenden Deltas enthält, die in dem geteilten Raum erzeugt wurden, weil Deltas, die unabhängig mit Deltas ausgeführt wurden, welche der Einladende vor der Einladung ausgeführt hatte, die Wiederholung dieser vorherigen Deltas verursachen könnten. Aus diesem Grund benötigt der neu eingeladene Endpunkt alle diese vorhergehenden Deltas. Der Inhalt eines Deltaprotokolls ist häufig viel größer als die tatsächlichen Daten in dem geteilten Raum und die Übertragung solchen Inhalts kann zu einer erheblichen Zeitverzögerung beim Starten eines neuen Endpunktes führen.
  • Die zweite Situation kann in einem geteilten Raum veranschaulicht werden, in dem es zehn Endpunkte gibt. Ein Endpunkt geht offline und führt ein Delta aus. Die übrigen neun Endpunkte sind alle online, und jeder von ihnen führt einhundert Deltas aus. Wenn der Offline-Endpunkt wieder online kommt, empfangen alle anderen Endpunkte das Delta, welches ausgeführt wurde, als der Endpunkt offline war, und der (nun) Online-Endpunkt empfängt die Deltas, die erzeugt wurden, als dieser Endpunkt offline war. Zum Erreichen von Konvergenz gibt es zwei Möglichkeiten. Wenn das Delta von dem Endpunkt, welcher offline ist, nach den anderen Deltas kommt, müßte der Endpunkt, welcher offline gegangen ist, dieses Delta wiederholen, die neunhundert Deltas von den anderen Endpunkten ausführen und dann dieses Delta überspringen. Keiner der anderen Endpunkte müßte eine Wiederholung ausführen. Wenn jedoch das Delta von dem Offline-Endpunkt zuerst in das Deltaprotokoll kam, müßten die anderen neun Endpunkte alle die neunhundert Deltas wiederholen, das eine Delta ausführen und dann die neunhundert Deltas überspringen. Offensichtlich erfordert die erstgenannte Situation viel weniger Arbeit, jedoch wäre es, aufgrund der Art und Weise, in welcher Gruppennummern zugewiesen werden, am wahrscheinlichsten, daß die letztgenannte Situation, oder zumindest eine, die dieser gleicht, auftritt.
  • Beide Situationen werden durch Prioritätsdeltas adressiert, welche eine Möglichkeit bereitstellen, die Reihenfolgebildung unabhängiger Deltas zu steuern. Diese können verwendet werden, um die erste Situation durch das Ordnen unabhängiger Deltas so zu adressieren, daß Deltas, die nicht von einem einladenden Delta abhängig sind, keine Wiederholung verursachen und daher ist es nicht notwendig, das gesamte Deltaprotokoll an einen neuen Eingeladenen zu senden. Ähnlich kann eine solche Ordnung verwendet werden, um die Menge von Wiederholungen zu verringern, um die zweite Situation zu adressieren. Prioritätsdeltas werden so verarbeitet, daß ein Delta unabhängig von einem Prioritätsdelta nach sämtlichen Deltas eingeordnet wird, von denen das Prioritätsdelta abhängig ist. Zum Beispiel, wenn unabhängig voneinander A die Deltas A1 und A1 erzeugt, und A1 ein Prioritätsdelta ist, und B B1 erzeugt, dann wird, weil A2 ein Prioritätsdelta ist, B1 immer nach A1 eingeordnet. B1 kann vor oder nach A2 kommen.
  • Zum Adressieren der oben genannten ersten Situation, weist jedes Mal, wenn ein neuer Endpunkt zu dem geteilten Raum hinzugefügt wird, das Delta, welches ihn hinzufügt, die höchstmögliche Priorität auf. Somit muß keines der vorhergehenden Deltas wiederholt werden. Zum Adressieren der zweiten Situation machen Endpunkte, welche online sind und Deltas erzeugen, periodisch eines der Deltas zu einem Prioritätsdelta. In dem oben angegebenen Beispiel bedeutet dies, daß die neunhundert Deltas erzeugt durch die neun Online-Endpunkte eine Reihe von Prioritätsdeltas enthalten. Der Offline-Endpunkt erzeugt kein Prioritätsdelta, so daß nur sehr wenige der neunhundert Deltas wiederholt werden müssen und sich der Arbeitsaufwand erheblich verringert.
  • Zum Verhindern von Interferenz zwischen simultanen Prioritätsdeltas, wird die Priorität von einem Delta ignoriert, wenn es ein unabhängiges Delta mit einer höheren Priorität (oder der gleichen Priorität, jedoch einem niedrigeren Einsetzungspunkt) gibt. Diese Operation ist von daher problematisch, daß wenn es zwei unabhängige Deltas gibt, welche einen neuen Endpunkt zu dem Raum hinzufügen, einer der neu hinzugefügten Endpunkte eine Wiederholung von Deltas durchführen muß, die er möglicherweise nicht besitzt. Diese letztgenannte Situation wird adressiert, indem einer der neu eingeladenen Endpunkte als „Synchronisationsverlust" markiert wird, und er muß dadurch erneut in den geteilten Raum eingeladen werden.
  • Prioritätsdeltas werden implementiert, indem eine Strukturschicht zu dem Deltaprotokoll, welches ein Delta-„Block" genannte wird, hinzugefügt wird. Deltablöcke sind der größte Abschnitt in dem Deltaprotokoll. Blöcke enthalten Gruppen, Gruppen enthalten Ketten und Ketten enthalten Deltas. Eine Gruppe kann unter mehreren Blöcken aufgeteilt sein. Jeder Block enthält eine Reihe von Gruppen und jeder Block weist ein bestimmtes Delta auf, welches das Prioritätsdelta ist, welches verursacht hat, daß der Block erzeugt wird. Wenn ein neues Prioritätsdelta ankommt, verursacht es, daß ein neuer Block erzeugt wird, solange dieser neue Block die erneute Assimilierung eines anderen Deltas mit einer höheren Priorität verursacht. Sämtliche assimilierten unabhängigen Deltas werden aus dem vorhergehenden Block entfernt und in den neuen Block verschoben (dies erfordert ein Zurückkehren zur vorherigen Position eines unabhängigen Deltas und dann ein Überspringen mit dem unabhängigen Delta in der neuen Position). Diese unabhängigen Deltas können erkannt werden, wenn Prioritätsdeltas eine komplette Darstellung des Deltaprotokollzustandes enthalten. Der Deltaprotokollzustand besteht aus einer Liste, welche die höchste Folge empfangen von jedem Endpunkt darstellt. Es sei darauf hingewiesen, daß es möglich ist, daß eine Gruppe zwischen unterschiedlichen Blöcken aufgeteilt ist, damit diese absolute Deltaordnung nach Gruppe und Folge nicht länger wahr ist.
  • Unter Bezugnahme auf die XML-Implementierung eines Deltaprotokolls wie in 9A und 9B veranschaulicht, werden Deltablöcke durch das Einfügen von einem von mehreren DelBlk-Elementen in das Deltaprotokoll implementiert. Ein Block ist definiert als ein Satz von Deltas mit einem Blockdelta, welches das Delta mit der höchsten Priorität in dem Block ist. Alle Deltas von denen das Blockdelta abhängig ist, befinden sich in vorhergehenden Blöcken. Alle Deltas, die nicht von dem Blockdelta abhängig sind, befinden sich in seinem Block. Deltas, die von dem Blockdelta abhängig sind, können in seinem Block oder in anschließenden Blöcken sein. Diese Anordnung stellt sicher, daß alle Deltas, die von dem Blockdelta unabhängig sind, nach allen Deltas, von denen das Blockdelta abhängig ist, assimiliert werden.
  • Ein DelBlk-Element wie das Element 904 weist mehrere Attribute auf, einschließlich eines DelSeq-Attributs, welches eine Folgenummer des Prioritätsdeltas für diesen Block enthält. Diese Folgenummer ist wie oben beschrieben konstruiert. Ein HighGrpNum-Attribut enthält die Nummer der höchsten Gruppe in dem Block. Ein NoUndo-Attribut ist eingestellt, wenn Deltas in diesem Block nicht durch einen Benutzer rückgängig gemacht werden können. Jedes DelBlk-Element 904 weist eines von mehreren DelGrp-Elementen enthalten darin auf. Diese DelGrp-Elemente stellen die Delta-Gruppen dar.
  • Bei dieser Implementierung kann das zuvor genannte Problem, welches bei unabhängigen Operationen zum Hinzufügen eines Endpunkts auftreten kann, erkannt werden, wenn zwei Deltas zum Hinzufügen eines Endpunktes die gleiche Blocknummer aufweisen. In diesem Fall wird ein neuer Endpunkt zum „Gewinner" erklärt und der andere Endpunkt wird als „Synchronisationsverlust" erklärt.
  • Prioritätsdeltas werden mit den in 17 veranschaulichten Schritten verarbeitet. Wenn ein Prioritätsdelta assimiliert werden soll, muß zuerst eine Entscheidung getroffen werden, ob seine Priorität ignoriert wird. Wie zuvor beschrieben wird die Priorität ignoriert, wenn ein unabhängiges Delta mit einer höheren Priorität vorliegt. So beginnt der Prozeß in Schritt 1700 und fährt fort mit Schritt 1702, wo alle unabhängigen Deltas lokalisiert werden. Jedes Prioritätsdelta weist ein Attribut auf, welches den Zustand des Deltaprotokolls auf dem Endpunkt, welches es erzeugt hat, beschreibt. Dieser letztgenannte Zustand wird verglichen mit dem Zustand des Deltaprotokolls auf dem Endpunkt, welcher das Delta assimiliert. Aus diesen Informationen können die unabhängigen Deltas lokalisiert werden.
  • Dann werden in Schritt 1704 die Prioritäten der unabhängigen Deltas verglichen. Wenn, wie in Schritt 1706 bestimmt, keines der lokalisierten unabhängigen Deltas eine höhere Priorität hat, als das Prioritätsdelta, welches assimiliert wird, dann wird die Priorität des neuen Deltas anerkannt. In Schritt 1708 beginnt jedes Prioritätsdelta einen neuen Block im Deltaprotokoll. Prioritätsdeltas teilen das Deltaprotokoll in Blöcke, so daß alle Deltas, von denen das Prioritätsdelta abhängig ist, früher in Blöcke assimiliert werden als Deltas in dem Block des Prioritätsdeltas. Dann werden in Schritt 1712 alle Deltas, die unabhängig von dem Prioritätsdelta sind, und Deltas, die von den Prioritätsdeltas abhängig sind, in den gleichen Block oder einen späteren Block assimiliert.
  • Insbesondere nachdem der neue Block erzeugt wurde, muß jedes Delta, welches vom Prioritätsdelta unabhängig ist, neu in seine neue Position im Deltaprotokoll assimiliert werden. Während der Wiederholungsphase ist es notwendig, diese Deltas in ihrer alten Position zu wiederholen und sie dann in der neuen Position zu überspringen, um die Konvergenz zu wahren. Der Prozeß wird dann in Schritt 1714 abgeschlossen.
  • Alternativ dazu, wenn in Schritt 1706 ein Delta mit einer höheren Priorität lokalisiert wurde, wird die Priorität des gerade assimilierten Prioritätsdeltas nicht anerkannt. In diesem Fall fährt der Prozeß mit Schritt 1710 fort, wo das Delta in den bestehenden aktuellen Block assimiliert wird. Der Prozeß wird dann in Schritt 1714 abgeschlossen.
  • Um zu verhindern, daß Deltaprotokolle in jedem Endpunkt aufgrund des Hinzufügens neuer Deltas kontinuierlich in der Größe anwachsen, werden die Protokolle periodisch eliminiert. Um jedoch die vorzeitige Zerstörung von Deltainformationen zu verhindern, ist der Eliminierungsprozeß ein Zwei-Schritt-Prozeß. Zuerst erklärt jeder Endpunkt die Gruppe, zu deren Eliminierung er bereit ist (basierend auf der höchsten Gruppe in jedem Endpunkt). Dann eliminieren alle Endpunkte Deltas in Gruppen ausgewählt durch Vergleichen der Gruppen, zu deren Eliminierung sich die Endpunkte bereit erklärt haben. Dieser Prozeß ist in 18 veranschaulicht.
  • Der Prozeß beginnt in Schritt 1800 und fährt fort mit Schritt 1802. Insbesondere übertragen in Schritt 1802 alle Endpunkte periodisch Eliminierungsinformationen in Übertragungen, die Endpunktimpulse genannt werden. Jeder Impuls enthält Informationen zum Identifizieren der höchsten Gruppennummer für diesen Endpunkt und Informationen zum Identifizieren einer Gruppe, für welche eine Entscheidung zu einer ausstehenden Eliminierung getroffen wurde. Ferner weist jeder Endpunktimpuls Abhängigkeiten in der gleichen Art und Weise auf, in der Deltas Abhängigkeiten aufweisen. Wenn die Abhängigkeiten von dem Endpunkt fehlen, welcher den Impuls empfangt, wird der Impuls gehalten, genau wie ein Delta gehalten werden würde. In Schritt 1804 werden die höchsten Gruppennummern für die Endpunkte verglichen. In Schritt 1806 wird eins weniger als das Minimum der höchsten Gruppennummern für alle aktiven Endpunkt als die Gruppe identifiziert, welche zum Eliminieren aussteht. Und schließlich eliminiert dann in Schritt 1808 jeder Endpunkt bis zum Minimum der ausstehenden Gruppen aller aktiven Endpunkte. Der Prozeß endet dann in Schritt 1810.
  • In einer ähnlichen Art und Weise können die Endpunkte selbst aus der Endpunkt-XML-Struktur eliminiert werden, in Abhängigkeit davon, ob sie aktiv sind oder nicht. Jeder Endpunkt weist einen Zustand auf, der im State-Attribut des EPT-Elements in der oben diskutierten Endpunkt-XML-Struktur gespeichert ist. Das State-Attribut kann jeden der folgenden Werte aufweisen:
    Figure 00500001
    Figure 00510001
  • Jeder Endpunkt bewegt sich abhängig von ausgewählten Bedingungen zwischen definierten Zuständen. Ein Zustandsdiagramm für die verschiedenen Zustände und die Übergänge zwischen Zuständen ist in 19 gezeigt. Zum Beispiel wechselt ein Endpunkt in den Lokal-Zustand 1902, wie durch den Pfeil 1912 veranschaulicht, wenn ein neuer geteilter Raum erzeugt wird. Ein anderer Endpunkt als der lokale Endpunkt wechselt in den Aktiv-Zustand 1904, wie durch den Pfeil 1914 veranschaulicht, wenn ein AddMember-Delta (Einladung) für diesen Endpunkt ausgeführt wird oder wenn ein AddDeviceForMember-Delta für diesen Endpunkt (geteilten Raum holen) ausgeführt wird. Ähnlich wechselt ein Endpunkt in den Neu-Zustand 1906, wie angegeben durch den Pfeil 1916, wenn ein Delta von dem zuvor unbekannten Endpunkt empfangen wird.
  • Ein Endpunkt wechselt vom Lokal-Zustand 1902 zum Aktiv-Zustand 1904, wie angegeben durch den Pfeil 1918, wenn mit dem Serialisieren eines Raumes für einen unterschiedlichen Endpunkt begonnen wird. In diesem Fall wechselt der lokale Endpunkt in den Aktiv-Zustand 1904. Ähnlich wechselt ein Endpunkt vom Aktiv-Zustand 1904 zu einem Lokal-Zustand 1902, wie angegeben durch den Pfeil 1920, wenn ein Raum auf einem Endpunkt deserialisiert wird. In diesem Fall wechselt dieser Endpunkt in den Lokal-Zustand 1902. Dieser letztgenannte Übergang kann zustande kommen, wenn ein Konto erneut auf ein Gerät importiert wird, auf dem es bereits vorher installiert war.
  • Ein Endpunkt kann vom Aktiv-Zustand 1904 in den Neu-Zustand 1906 wechseln, wie angegeben durch den Pfeil 1924, wenn ein Konto erneut auf ein Gerät importiert wird, auf dem es bereits vorher installiert war. Ein Endpunkt kann von einem Aktiv-Zustand 1904 zu einem Trennung-Zustand 1908 wechseln, wie angegeben durch den Pfeil 1930, wenn der aktive Endpunkt durch den lokalen Endpunkt zu einem „Nachzügler" erklärt wird. Ein Nachzügler-Endpunkt ist als ein Endpunkt definiert, von dem für einen bestimmten Zeitraum keine Deltas assimiliert wurden. Die Zeitprüfung erfolgt üblicherweise während des oben erwähnten Eliminierungserklärungsprozesses. Dieser Übergang kann auch stattfinden, wenn ein Delta von dem aktiven Endpunkt ausgeführt wird, wobei der lokale Endpunkt informiert wird, daß der aktive Endpunkt den Raum gelöscht hat. Es kann ferner passieren, wenn ein Delta, welches den aktiven Endpunkt aus dem Raum auslädt, ausgeführt wird. Und schließlich kann dieser Übergang erzeugt werden, wenn eine Trennen-Benachrichtigung durch den lokalen Endpunkt empfangen wird, welche diesen darüber informiert, daß der aktive Endpunkt nun getrennt ist.
  • Ein Übergang vom Neu-Zustand 1906 zum Aktiv-Zustand 1904 findet statt, wie angegeben durch den Pfeil 1923, wenn ein AddMember-Delta (Einladung) für diesen Endpunkt ausgeführt wird oder wenn ein AddDeviceForMember-Delta (geteilten Raum holen) ausgeführt wird. Dieser Übergang kann auch erfolgen, wenn ein AddEndpoint-Delta (Kontoimport) ausgeführt wird.
  • Ein Übergang vom Neu-Zustand 1906 zum Trennung-Zustand 1908 kann stattfinden, wie angegeben durch den Pfeil 1926, wenn ein Delta von einem neuen Endpunkt empfangen wird, dessen Einsetzungspunkt als ausstehend zum Eliminieren markiert wurde. Er kann auch stattfinden, wenn der lokale Endpunkt den Einsetzungspunkt eines Deltas von dem neuen Endpunkt als „ausstehend zu Eliminieren" erklärt. Außerdem kann dieser Übergang stattfinden, wenn eine Trennen-Benachrichtigung durch den lokalen Endpunkt empfangen wird, welche ihn informiert, daß der neue Endpunkt nun getrennt ist.
  • Ein Übergang vom Neu-Zustand 1906 zum Getrennt-Zustand 1910 kann stattfinden, wie angegeben durch den Pfeil 1938, wenn ein Delta von einem neuen Endpunkt empfangen wird, dessen Einsetzungspunkt eliminiert wurde. Er kann auch stattfinden, wenn der Einsetzungspunkt eines Deltas empfangen durch den lokalen Endpunkt von dem neuen Endpunkt durch den lokalen Endpunkt eliminiert wurde.
  • Ein Übergang vom Trennung-Zustand 1908 zum Aktiv-Zustand 1904, wie angegeben durch den Pfeil 1932, kann stattfinden, wenn ein AddMember-Delta (Einladung) ausgeführt wird oder wenn ein AddDeviceForMember-Delta (geteilten Raum holen) ausgeführt wird. Ein solcher Übergang kann auch stattfinden, wenn ein AddEndpoint-Delta (Kontoimport) ausgeführt wird.
  • Ein Übergang vom Trennung-Zustand 1908 zum Neu-Zustand 1906 kann stattfinden, wie angegeben durch den Pfeil 1926, wenn ein Konto erneut auf ein Gerät importiert wird, auf dem es bereits zuvor installiert war. Ein Übergang vom Trennung-Zustand 1908 zu Getrennt-Zustand 1910 kann stattfinden, wie angegeben durch den Pfeil 1934, wenn der Einsetzungspunkt eines Deltas empfangen durch den lokalen Endpunkt von dem in Trennung befindlichen Endpunkt durch den lokalen Endpunkt eliminiert wird. Ein Übergang vom Getrennt-Zustand 1910 zum Aktiv-Zustand 1904 kann stattfinden, wie angegeben durch den Pfeil 1922, wenn der lokale Endpunkt ein AddMember-Delta (Einladung) oder ein AddDeviceForMember-Delta (geteilten Raum holen) oder ein AddEndpoint-Delta (Kontoimport) ausführt.
  • Ein Übergang vom Getrennt-Zustand 1910 zu einem Neu-Zustand 1906 kann stattfinden, wie angegeben durch den Pfeil 1936, wenn ein Konto erneut auf ein Gerät importiert wird, auf dem es bereits zuvor installiert war.
  • Eine Softwareimplementierung der oben beschriebenen Ausführungsform kann eine Reihe von Computeranweisungen entweder fest auf einem greifbaren Medium, wie einem computerlesbaren Medium, zum Beispiel eine Diskette, eine CD-ROM, einen ROM-Speicher oder eine Festplatte, oder übertragbar auf ein Computersystem über ein Modem oder ein anderes Schnittstellengerät über ein Medium umfassen. Das Medium kann entweder ein greifbares Medium sein, einschließlich, jedoch nicht darauf beschränkt, optische oder analoge Kommunikationsleitungen, oder es kann mit drahtlosen Techniken implementiert sein, einschließlich, jedoch nicht darauf beschränkt, Mikrowellen-, Infrarot- oder andere Übertragungstechniken. Es kann auch das Internet sein. Die Reihe von Computeranweisungen umschließt die gesamte oder einen Teil der zuvor hierin hinsichtlich der Erfindung beschriebenen Funktionalität. Dem Fachmann auf dem Gebiet wird klar sein, daß solche Computeranweisungen in einer Reihe von Programmiersprachen geschrieben sein können, für die Verwendung mit vielen Computerarchitekturen oder Betriebssystemen. Ferner können solche Anweisungen unter Verwendung jeder gegenwärtigen oder zukünftigen Speichertechnologie gespeichert werden, einschließlich, jedoch nicht darauf beschränkt, Halbleiter-, magnetische, optische oder andere Speichergeräte, oder übertragen mittels jeder gegenwärtigen oder zukünftigen Kommunikationstechnologie, einschließlich, jedoch nicht darauf beschränkt, optische, Infrarot-, Mikrowellen- oder andere Übertragungstechnologien. Es wird erwägt, daß ein solches Computerprogrammprodukt als ein entfernbares Medium mit beiliegender gedruckter oder elektronischer Dokumentation vertrieben werden kann, z.B. eingeschweißte Software, vorinstalliert auf einem Computersystem, z.B. auf dem System-ROM oder der Festplatte, oder von einem Server oder einer elektronischen Anschlagtafel über ein Netz, z.B. das Internet oder das World Wide Web.
  • Obwohl eine exemplarische Ausführungsform der Erfindung offenbart wurde, dürfte dem Fachmann auf dem Gebiet klar sein, daß verschiedene Änderungen und Modifikationen vorgenommen werden können, welche einige der Vorteile der Erfindung erreichen, ohne sich vom Gedanken und dem Umfang der Erfindung zu entfernen.

Claims (45)

  1. Kollaboratives Computersystem (100), das eine Vielzahl von Endpunkten (400, 402) umfasst und angepasst ist zur Wahrung der Konsistenz des Zugriffs zu einem geteilten Raums über die Vielzahl von Endpunkten, worin jeder Endpunkt eine lokale Datenkopie aufweist und Endpunkte übertragen gegenseitig Datenänderungskommandos, die in Deltas enthalten sind, zur Aktualisierung der lokalen Datenkopien und worin jeder Endpunkt einen Mechanismus enthält, der zur Ausführung der Datenänderungskommandos in einem Delta (310, 910) angepasst ist, eine Deltaprotokoll-Datenstruktur (438, 444) aufweist, die Deltas und ihren Inhalt speichert, und einen Mechanismus (420, 422) aufweist für das selektive Rückgängigmachen und erneute Ausführen von Datenänderungskommandos zum Erreichen von Konvergenz der Datenänderungskommandos in allen Endpunkten, gekennzeichnet dadurch, dass das kollaborative Computersystem umfasst: in jedem Endpunkt einen Mechanismus (308), der den Einsetzungspunkt eines Delta in das Deltaprotokoll bestimmt, so dass das Deltaprotokoll Ketten von Deltas (908) enthält, jede Kette enthält Deltas von einem Endpunkt in der Reihenfolge der Erzeugung, und die Ketten sind in Gruppen (906, 912, 914) von Ketten von verschiedenen Endpunkten organisiert, und die Gruppen sind auf der Basis der Zeit des Empfangs der Deltas innerhalb der Gruppe geordnet.
  2. Das kollaborative Computersystem von Anspruch 1, worin das Deltaprotokoll Information enthält, die durch den Mechanismus zum selektiven Rückgängigmachen und zum erneuten Ausführen von Datenänderungskommandos benutzt wird.
  3. Das kollaborative Computersystem von Anspruch 1, worin jedes Delta am Ende des Deltaprotokolls eingesetzt wird, wenn das Delta verarbeitet ist und der Mechanismus, der den Einsetzungspunkt bestimmt, wahlweise eine Kette oder Gruppe zum Deltaprotokoll vor der Bestimmung des Einsetzungspunkts hinzufügt.
  4. Das kollaborative Computersystem von Anspruch 1, worin jeder Endpunkt eine Folgenummer an jedes Delta anfügt und jede Kette in einem Deltaprotokoll Deltas umfasst, die von einem einzelnen Endpunkt empfangen wurden geordnet durch die Folgenummern der Deltas, die durch den einzelnen Endpunkt angefügt wurden.
  5. Das kollaborative Computersystem von Anspruch 1, worin jede Kette in einem Deltaprotokoll eine Länge aufweist, die kleiner ist als eine vorbestimmte Maximallänge.
  6. Das kollaborative Computersystem von Anspruch 1, worin jeder Endpunkt eine Erzeuger ID aufweist und innerhalb jeder Gruppe Ketten in der Ordnung einer ansteigenden Erzeuger ID angeordnet sind.
  7. Das kollaborative Computersystem von Anspruch 1 umfasst weiter einen Mechanismus zur Erzeugung von Endpunktimpulsen, die zwischen den Endpunkten des geteilten Raumes (1802) übertragen werden, und worin jeder Endpunktimpuls durch einen Endpunkt erzeugt wird und Informationen enthält, die eine oder mehrere Gruppen von Deltas im Deltaprotokoll identifiziert, zu deren Löschung dieser Endpunkt bereit ist.
  8. Das kollaborative Computersystem von Anspruch 7 umfasst weiter in jedem Endpunkt Mittel, die von anderen Endpunkten erzeugte Endpunktimpulse empfangen und Gruppen im Deltaprotokoll in dem Endpunkt löschen, die gelöschten Gruppen werden ausgewählt durch Vergleich der Informationen in den Endpunktimpulsen zur Bestimmung von Deltagruppen, für die alle Endpunkte zur Löschung bereit sind (1804, 1806).
  9. Das kollaborative Computersystem von Anspruch 1, worin der Mechanismus in jedem Endpunkt, der die Datenänderungskommandos in einem Delta ausführt, einen Mechanismus umfasst, der das Deltaprotokoll zur sequentiellen Prüfung von Deltas auf Rückgängigmachen-Datenänderungskommandos in den ausgewählten Deltas benutzt (1516).
  10. Das kollaborative Computersystem von Anspruch 9, worin der Mechanismus in jedem Endpunkt, der die Datenänderungskommandos in einem Delta ausführt, einen Mechanismus umfasst, der das Deltaprotokoll zur sequentiellen Prüfung von Deltas auf erneutes Ausführen von Datenänderungskommandos benutzt, die vorausgehend rückgängig gemacht wurden (1518, 1520).
  11. Das kollaborative Computersystem von Anspruch 1, worin jedes erste Delta eine Liste von Abhängigkeiten aufweist, die eines oder mehrere zweite Deltas darstellen, die vor dem ersten Delta auszuführen sind (318).
  12. Das kollaborative Computersystem von Anspruch 11, worin der Mechanismus in jedem Endpunkt, der die Datenänderungskommandos in einem Delta ausführt, einen Mechanismus umfasst, der in einem ersten Delta enthaltene Rückgängigmachen-Information zum Rückgängigmachen von Datenänderungskommandos benutzt, die in dem ersten Delta enthalten sind (614, 616).
  13. Das kollaborative Computersystem von Anspruch 12 umfasst weiter eine Datenänderungsvorrichtung, die Rückgängigmachen-Information zur gleichen Zeit in das Deltaprotokoll einfügt, in der die Datenänderungskommandos in den Deltas ausgeführt werden.
  14. Das kollaborative Computersystem von Anspruch 11, worin die Gruppen in dem Deltaprotokoll in Blöcken angeordnet sind und der Mechanismus in jedem Endpunkt, der den Einsetzungspunkt von jedem Delta in das Deltaprotokoll bestimmt, selektiv einen Block dem Deltaprotokoll hinzufügt, so dass jeder Block ein Delta mit der höchsten Priorität enthält, alle Deltas, von denen das Delta mit der höchsten Priorität abhängt, werden in Blöcken lokalisiert, die vor dem besagten Block erzeugt wurden, alle Deltas, die von dem Delta mit der höchsten Priorität unabhängig sind, sind in besagtem Block und alle Deltas, die von dem Delta mit der höchsten Priorität abhängen, sind entweder in besagtem Block oder in Blöcken, die nach dem besagten Block erzeugt werden (1712).
  15. Das kollaborative Computersystem von Anspruch 11 umfasst weiter einen Mechanismus zur Erzeugung eines asynchronen Deltas, worin keine anderen Deltas von dem asynchronen Delta abhängen.
  16. Das kollaborative Computersystem von Anspruch 11 umfasst weiter einen Mechanismus in einem ersten Endpunkt zur Identifizierung eines fehlenden Deltas (1110), von dem ein empfangenes Delta abhängt und das nicht im Deltaprotokoll des ersten Endpunkts enthalten ist, und zum Holen des fehlenden Delta von einem zweiten Endpunkt (422).
  17. Das kollaborative Computersystem von Anspruch 16, worin der Mechanismus zum Holen von Deltas eine Holen-Anforderung zu einem anderen Endpunkt sendet (1304), die eine Holen-Anforderung-Folgenummer enthält, und worin der andere Endpunkt einen Holen-Beantworten-Mechanismus umfasst, der eine Holen-Beantworten-Folgenummer enthält, und worin der Holen-Beantworten-Mechanismus ein angefordertes Delta zum Mechanismus für das Holen von Deltas zurückgibt, wenn die Holen-Anforderung-Folgenummer gleich der Holen-Beantworten-Folgenummer ist (1306, 1308).
  18. Das kollaborative Computersystem von Anspruch 17, worin der Holen-Beantworten-Mechanismus eine Aktualisierungsnachricht zum Mechanismus für das Holen von Deltas sendet, wenn die Holen-Anforderung-Folgenummer nicht gleich der Holen-Beantworten-Folgenummer ist (1312).
  19. Das kollaborative Computersystem von Anspruch 18, worin der Mechanismus zum Holen auf die Aktualisierungsnachricht anspricht zur Inkrementierung der Holen-Anforderung-Folgenummer (1314).
  20. Das kollaborative Computersystem von Anspruch 11 umfasst weiter einen Mechanismus zur Erzeugung eines Identität-verbreitet-Deltas, das zu einem Teilsatz von Endpunkten im geteilten Raum gesendet wird und das in ein Deltaprotokoll an einem Punkt eingesetzt wird, der durch den Endpunkt bestimmt wird, welcher dieses Delta und eine Teil-Folgenummer erzeugt hat.
  21. Das kollaborative Computersystem von Anspruch 1 umfasst weiter in jedem Endpunkt einen Mechanismus zur Speicherung bleibender Daten, die einen Zustand von Endpunkten in dem geteilten Raum repräsentieren, die Zustände enthalten einen aktiven Zustand (1904), und die Einrichtung umfasst weiter einen Mechanismus zum Senden von Deltas nur zu solchen Endpunkten, die sich im aktiven Zustand befinden.
  22. Das kollaborative Computersystem von Anspruch 21, worin in jedem Endpunkt der Mechanismus zur Ausführung der Datenänderungskommandos in einem Delta auf einen Zustand des Endpunktes anspricht, der das Delta erzeugt hat, zum selektiven Ausführen des Datenänderungskommandos in dem Delta.
  23. Das kollaborative Computersystem von Anspruch 21, worin jeder Endpunkt einen laufenden Zustand aufweist (1902, 1904, 1906) und jeder Endpunkt einen Mechanismus umfasst, der den laufenden Zustand in einen anderen Zustand ändert als Antwort auf ein vorbestimmtes Ereignis (1918, 1920).
  24. Ein Verfahren zu Aufrechterhaltung der Konsistenz eines geteilten Raumes über eine Vielzahl von Endpunkten (400, 402) in einem kollaborativen Computersystem (100), worin jeder Endpunkt eine lokale Datenkopie aufweist und Endpunkte gegenseitig Datenänderungskommandos übertragen, die in Deltas enthalten sind, zur Aktualisierung der lokalen Datenkopien und worin jeder Endpunkt einen Mechanismus enthält, der Datenänderungskommandos in einem Delta (310, 910) ausführt, eine Deltaprotokoll-Datenstruktur (438, 444) aufweist, die Deltas und ihren Inhalt speichert, und einen Mechanismus (420, 422) aufweist zum selektiven Rückgängigmachen und zum erneuten Ausführen von Datenänderungskommandos zum Erreichen von Konvergenz der Datenänderungskommandos in allen Endpunkten, gekennzeichnet dadurch, dass das Verfahren umfasst: in jedem Endpunkt Bestimmung eines Einsetzungspunkts eines Deltas in das Deltaprotokoll (308), so dass das Deltaprotokoll Ketten von Deltas (908) enthält, und jede Kette enthält Deltas von einem Endpunkt in der Reihenfolge der Erzeugung, und die Ketten sind in Gruppen (906, 912, 914) von Ketten von verschiedenen Endpunkten organisiert und die Gruppen sind auf der Basis der Zeit des Empfangs der Deltas innerhalb der Gruppe geordnet.
  25. Das Verfahren von Anspruch 24, worin die Bestimmung des Einsetzungspunkts die Einsetzung eines Deltas in das Deltaprotokoll an einem Punkt umfasst, der durch den das Delta erzeugenden Endpunkt und eine Folgenummer bestimmt wird.
  26. Das verfahren von Anspruch 24, worin jede Kette in einem Deltaprotokoll aus Deltas besteht, die von einem Endpunkt empfangen werden geordnet durch die Folgenummer.
  27. Das Verfahren von Anspruch 24, worin jede Kette in einem Deltaprotokoll eine vorbestimmte maximale Länge aufweist.
  28. Das Verfahren von Anspruch 24, worin die Bestimmung des Einsetzungspunkts die Anordnung der Ketten in dem Deltaprotokoll in Gruppen umfasst, worin innerhalb jeder Gruppe Ketten in der Ordnung einer ansteigenden Erzeuger ID angeordnet sind und worin die Erzeuger ID die Kombination einer Endpunkt ID für einen Endpunkt und einer Zufallszahl ist, die jeweils zu der Zeit erzeugt wird, wenn dieser Endpunkt den geteilten Raum öffnet.
  29. Das Verfahren von Anspruch 24 umfasst weiter: Erzeugung von Endpunktimpulsen, die zwischen den Endpunkten des geteilten Raumes (1806) übertragen werden, und worin jeder Endpunktimpuls durch einen Endpunkt erzeugt wird und Informationen enthält, die eine Deltagruppe identifiziert, zu deren Löschung dieser Endpunkt bereit ist.
  30. Das Verfahren von Anspruch 29 umfasst weiter: Empfangen von Endpunktimpulsen, die von anderen Endpunkten erzeugt werden und Löschen von Deltas in Gruppen, die durch Vergleich der Informationen in den Endpunktimpulsen ausgewählt werden zur Bestimmung von Deltagruppen, für die alle Endpunkte zur Löschung bereit sind (1804, 1806).
  31. Das Verfahren von Anspruch 24, worin das Verfahren die Ketten in einem Deltaprotokoll zur sequentiellen Prüfung von Deltas auf Rückgängigmachen-Datenänderungskommandos in den ausgewählten Deltas benutzt.
  32. Das Verfahren von Anspruch 31, worin das Verfahren die Ketten in einem Deltaprotokoll zur sequentiellen Prüfung von Deltas auf erneutes Ausführen von Datenänderungskommandos benutzt, die vorausgehend rückgängig gemacht wurden (1518, 1520).
  33. Das Verfahren von Anspruch 24, worin jedes erste Delta eine Liste von Abhängigkeiten aufweist, die eines oder mehrere zweite Deltas darstellen, die vor dem jeden ersten Delta auszuführen sind (318).
  34. Das Verfahren von Anspruch 33, worin in dem ersten Delta enthaltene Rückgängigmachen-Information zum Rückgängigmachen von Datenänderungskommandos benutzt wird, die in dem ersten Delta enthalten sind (614, 616).
  35. Das Verfahren von Anspruch 34 umfasst weiter das Einsetzen von Rückgängigmachen-Information in das Deltaprotokoll zur gleichen Zeit, zu der die Datenänderungskommandos in den Deltas ausgeführt werden, worin die Gruppen in dem Deltaprotokoll in Blöcken organisiert sind und die Verfahrenskommandos ausgeführt werden.
  36. Das Verfahren von Anspruch 33 umfasst zusätzlich, vor der Bestimmung des Einsetzungspunktes, ein wahlweises Hinzufügen eines Blocks zum Deltaprotokoll, so dass jeder Block ein Delta mit der höchsten Priorität enthält, alle Deltas, von denen das Delta mit der höchsten Priorität abhängt, werden in Blöcken lokalisiert, die vor dem besagten Block erzeugt werden, alle Deltas, die von dem Delta mit der höchsten Priorität unabhängig sind, sind in besagtem Block und alle Deltas, die von dem Delta mit der höchsten Priorität abhängen, sind entweder in besagtem Block oder in Blöcken, die nach dem besagten Block erzeugt werden (1712).
  37. Das Verfahren von Anspruch 33 umfasst weiter die Erzeugung eines asynchronen Deltas, worin keine anderen Deltas von dem asynchronen Delta abhängen.
  38. Das Verfahren von Anspruch 33 umfasst weiter in einem ersten Endpunkt das Holen eines Deltas von anderen Endpunkten, das in einer Liste von Abhängigkeiten, aber nicht im Deltaprotokoll des ersten Endpunkts enthalten ist (422, 1110).
  39. Das Verfahren von Anspruch 38, worin das Holen umfasst: Senden einer Molen-Anforderung von dem ersten Endpunkt zu einem anderen Endpunkt (1304), die eine Holen-Anforderung-Folgenummer enthält, und worin der andere Endpunkt einen Holen-Beantworten-Mechanismus umfasst, der eine Holen-Beantworten-Folgenummer enthält; Zurücksenden eines angeforderten Deltas von dem anderen Endpunkte zu dem ersten Endpunkt, wenn die Holen-Anforderung-Folgenummer gleich der Holen-Beantworten-Folgenummer ist (1306, 1308).
  40. Das Verfahren von Anspruch 39, worin das Holen weiter umfasst: Senden einer Aktualisierungsnachricht zum ersten Endpunkt, wenn die Holen-Anforderung-Folgenummer nicht gleich der Holen-Beantworten-Folgenummer ist (1312).
  41. Das Verfahren von Anspruch 40, worin das Holen weiter das Inkrementieren der Holen-Anforderung-Folgenummer umfasst als Antwort auf die Aktualisierungsnachricht (1314).
  42. Das Verfahren von Anspruch 24 umfasst weiter die Erzeugung eines Identität-verbreitet-Deltas, das zu einem Teilsatz von Endpunkten im geteilten Raum gesendet wird und Einsetzen des Identität-verbreitet-Deltas in das Deltaprotokoll an einem Punkt, der durch den Endpunkt bestimmt wird, welcher dieses Delta und eine Teil-Folgenummer erzeugt hat.
  43. Das Verfahren von Anspruch 24 umfasst weiter: Speicherung bleibender Daten in jedem Endpunkt, die einen Zustand von allen Endpunkten in dem geteilten Raum repräsentieren, einschließlich eines aktiven Zustands (1904); und selektives Senden von Deltas nur zu solchen Endpunkten, die sich im aktiven Zustand befinden.
  44. Das Verfahren von Anspruch 43, worin das Verfahren weiter ein selektives Ausführen der Datenänderungskommandos in dem Delta umfasst als Antwort auf einen Zustand des Endpunktes, der das Delta erzeugt hat.
  45. Das Verfahren von Anspruch 43, worin jeder Endpunkt einen laufenden Zustand aufweist (1902, 1904, 1906) und das Verfahren weiter umfasst: Änderung des laufenden Zustands des Endpunkts in einen anderen Zustand als Antwort auf ein vorbestimmtes Ereignis (1918, 1920).
DE60312624T 2002-10-24 2003-10-22 Verfahren und Vorrichtung zur Konsistenzunterhaltung eines geteilten Raums über mehrere Endpunkte in einem gleichrangigen kollaborativen Computersystem Expired - Lifetime DE60312624T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/279,785 US7340502B2 (en) 2002-10-24 2002-10-24 Method and apparatus for maintaining consistency of a shared space across multiple endpoints in a peer-to-peer collaborative computer system
US279785 2002-10-24

Publications (2)

Publication Number Publication Date
DE60312624D1 DE60312624D1 (de) 2007-05-03
DE60312624T2 true DE60312624T2 (de) 2007-11-29

Family

ID=32106809

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60312624T Expired - Lifetime DE60312624T2 (de) 2002-10-24 2003-10-22 Verfahren und Vorrichtung zur Konsistenzunterhaltung eines geteilten Raums über mehrere Endpunkte in einem gleichrangigen kollaborativen Computersystem

Country Status (8)

Country Link
US (2) US7340502B2 (de)
EP (1) EP1418726B1 (de)
JP (1) JP4684546B2 (de)
KR (1) KR101021399B1 (de)
AT (1) ATE357700T1 (de)
CA (1) CA2446283C (de)
DE (1) DE60312624T2 (de)
IL (1) IL158508A (de)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6859821B1 (en) * 1999-07-19 2005-02-22 Groove Networks, Inc. Method and apparatus for prioritizing data change requests and maintaining data consistency in a distributed computer system equipped for activity-based collaboration
US7509378B2 (en) * 2003-03-11 2009-03-24 Bea Systems, Inc. System and method for message ordering in a message oriented network
US20050033625A1 (en) * 2003-08-06 2005-02-10 International Business Machines Corporation Method, apparatus and program storage device for scheduling the performance of maintenance tasks to maintain a system environment
US7383302B2 (en) * 2003-09-15 2008-06-03 International Business Machines Corporation Method and system for providing a common collaboration framework accessible from within multiple applications
US7945675B2 (en) * 2003-11-03 2011-05-17 Apacheta Corporation System and method for delegation of data processing tasks based on device physical attributes and spatial behavior
US20050204297A1 (en) * 2003-12-22 2005-09-15 International Business Machines Corporation Combined synchronous and asynchronous logical components in a collaborative context
US8171387B2 (en) * 2004-05-13 2012-05-01 Boardwalk Collaboration, Inc. Method of and system for collaboration web-based publishing
JP4972901B2 (ja) * 2004-11-10 2012-07-11 日本電気株式会社 情報共有空間提供システム、情報共有空間提供方法及びコンピュータプログラム
CN1972200B (zh) * 2005-02-21 2010-12-22 索尼计算机娱乐公司 网络系统、构成网络上节点的计算机及网络可视化方法
US20060265395A1 (en) * 2005-05-19 2006-11-23 Trimergent Personalizable information networks
US20060265394A1 (en) * 2005-05-19 2006-11-23 Trimergent Personalizable information networks
US20060265396A1 (en) * 2005-05-19 2006-11-23 Trimergent Personalizable information networks
US7610287B1 (en) 2005-06-28 2009-10-27 Google Inc. System and method for impromptu shared communication spaces
US7930346B2 (en) * 2005-08-24 2011-04-19 Microsoft Corporation Security in peer to peer synchronization applications
US8819536B1 (en) 2005-12-01 2014-08-26 Google Inc. System and method for forming multi-user collaborations
US20070198992A1 (en) * 2006-01-26 2007-08-23 International Business Machines Corporation Changing submitted asynchronous business events to synchronous business events in a Business processing system
US8965874B1 (en) 2006-08-04 2015-02-24 Google Inc. Dynamic aggregation of users
US20080148368A1 (en) * 2006-12-14 2008-06-19 Mary Ellen Zurko Secure extranet access to collaborative activities in a collaborative computing environment
US7900142B2 (en) * 2007-01-15 2011-03-01 Microsoft Corporation Selective undo of editing operations performed on data objects
US7986867B2 (en) * 2007-01-26 2011-07-26 Myspace, Inc. Video downloading and scrubbing system and method
US20080270629A1 (en) * 2007-04-27 2008-10-30 Yahoo! Inc. Data snychronization and device handling using sequence numbers
GB0712935D0 (en) * 2007-07-04 2007-08-15 Deltamxl Ltd Representation of multiple markup language files in one file for the productionof new new markup language files
US9401957B2 (en) * 2007-09-14 2016-07-26 International Business Machines Corporation System and method for synchronization between servers
US8774374B2 (en) * 2007-12-13 2014-07-08 Verizon Patent And Licensing Inc. Managing visual voicemail from multiple devices
KR101425621B1 (ko) * 2008-01-15 2014-07-31 삼성전자주식회사 컨텐츠를 안전하게 공유하는 방법 및 시스템
US8151145B2 (en) * 2008-04-03 2012-04-03 Oracle America, Inc. Flow control timeout mechanism to detect PCI-express forward progress blockage
KR101467512B1 (ko) 2008-04-30 2014-12-02 삼성전자주식회사 피투피 네트워크 시스템 및 그의 운용 방법
US8010487B2 (en) 2008-06-27 2011-08-30 Microsoft Corporation Synchronization and collaboration within peer-to-peer and client/server environments
US8140478B2 (en) * 2009-01-29 2012-03-20 Microsoft Corporation Commit rate management with decoupled commit operations
US8275869B2 (en) * 2009-08-05 2012-09-25 Tellabs Operations, Inc. Re-synchronizing data between network elements and network management system using partial node discovery
US8732247B2 (en) * 2009-09-28 2014-05-20 Bjorn Michael Dittmer-Roche System and method of simultaneous collaboration
US8949346B2 (en) * 2010-02-25 2015-02-03 Cisco Technology, Inc. System and method for providing a two-tiered virtual communications architecture in a network environment
US20120036188A1 (en) * 2010-08-06 2012-02-09 Nokia Corporation Method and Apparatus for Aggregating Document Information
US9170123B2 (en) 2010-08-06 2015-10-27 Nokia Technologies Oy Method and apparatus for generating information
US8935214B2 (en) * 2010-08-16 2015-01-13 Mimosa Systems, Inc. Storing electronic content with time-varying properties
US9092499B2 (en) * 2012-01-20 2015-07-28 Blackberry Limited Synchronizing endpoint data stores having disparate schemas
US20130244792A1 (en) * 2012-03-13 2013-09-19 Zynga Inc. Game environment utilizing a lock free memory system
US9087105B2 (en) * 2012-10-04 2015-07-21 Adobe Systems Incorporated Rule-based extraction, transformation, and loading of data between disparate data sources
US10528610B2 (en) * 2014-10-31 2020-01-07 International Business Machines Corporation Customized content for social browsing flow
US20160344677A1 (en) 2015-05-22 2016-11-24 Microsoft Technology Licensing, Llc Unified messaging platform for providing interactive semantic objects
US10216709B2 (en) 2015-05-22 2019-02-26 Microsoft Technology Licensing, Llc Unified messaging platform and interface for providing inline replies
US10261756B2 (en) * 2015-06-01 2019-04-16 Brigham Young University Method for preventing reference invalidation when reversing operations in synchronous collaborative applications
US20170180131A1 (en) * 2015-12-16 2017-06-22 Intel Corporation Secure unlock to access debug hardware
US11048722B2 (en) * 2018-07-31 2021-06-29 EMC IP Holding Company LLC Performance optimization for data persistency in asynchronous replication setups

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5170480A (en) * 1989-09-25 1992-12-08 International Business Machines Corporation Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time
GB2297181B (en) * 1993-09-24 1997-11-05 Oracle Corp Method and apparatus for data replication
US5787262A (en) 1996-06-26 1998-07-28 Microsoft Corporation System and method for distributed conflict resolution between data objects replicated across a computer network
US6317754B1 (en) * 1998-07-03 2001-11-13 Mitsubishi Electric Research Laboratories, Inc System for user control of version /Synchronization in mobile computing
US6148383A (en) * 1998-07-09 2000-11-14 International Business Machines Corporation Storage system employing universal timer for peer-to-peer asynchronous maintenance of consistent mirrored storage
US6327671B1 (en) * 1998-11-18 2001-12-04 International Business Machines Corporation Delta compressed asynchronous remote copy
US6859821B1 (en) 1999-07-19 2005-02-22 Groove Networks, Inc. Method and apparatus for prioritizing data change requests and maintaining data consistency in a distributed computer system equipped for activity-based collaboration
US7587467B2 (en) * 1999-12-02 2009-09-08 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US6898642B2 (en) * 2000-04-17 2005-05-24 International Business Machines Corporation Synchronous collaboration based on peer-to-peer communication
GB0018042D0 (en) * 2000-07-21 2000-09-13 Monsell Edm Ltd Method of and software for recordal and validation of changes to markup language files
JP3955181B2 (ja) 2001-02-05 2007-08-08 株式会社エヌジェーケー ピア・ツー・ピアで情報を共有し活用する方法
US6865599B2 (en) * 2001-09-04 2005-03-08 Chenglin Zhang Browser-to-browser, dom-based, peer-to-peer communication with delta synchronization
US6889229B1 (en) * 2001-09-28 2005-05-03 Oracle International Corporation Techniques for peer-to-peer replication of objects in a relational database
US9350782B2 (en) * 2002-01-29 2016-05-24 Antonio Ortega Method and system for delivering media data
US7386753B2 (en) * 2004-09-02 2008-06-10 International Business Machines Corporation Subscription-based management and distribution of member-specific state data in a distributed computing system

Also Published As

Publication number Publication date
US20040083263A1 (en) 2004-04-29
CA2446283A1 (en) 2004-04-24
DE60312624D1 (de) 2007-05-03
IL158508A (en) 2008-11-03
EP1418726A3 (de) 2005-06-01
KR20040036633A (ko) 2004-04-30
KR101021399B1 (ko) 2011-03-14
US7340502B2 (en) 2008-03-04
EP1418726B1 (de) 2007-03-21
ATE357700T1 (de) 2007-04-15
IL158508A0 (en) 2004-05-12
CA2446283C (en) 2009-12-22
JP4684546B2 (ja) 2011-05-18
EP1418726A2 (de) 2004-05-12
US20070255787A1 (en) 2007-11-01
US8073905B2 (en) 2011-12-06
JP2004152289A (ja) 2004-05-27

Similar Documents

Publication Publication Date Title
DE60312624T2 (de) Verfahren und Vorrichtung zur Konsistenzunterhaltung eines geteilten Raums über mehrere Endpunkte in einem gleichrangigen kollaborativen Computersystem
DE60038705T2 (de) Verfahren und vorrichtung für die aktivitäts-basierte zusammenarbeit eines rechnersystems, ausgestattet mit einem kommunikations-manager
US7818679B2 (en) Method, system, and apparatus for enabling near real time collaboration on an electronic document through a plurality of computer systems
DE602004012485T2 (de) Vorrichtung, Verfahren und Rechnerprogramm zur Verwaltung von digitalen Zertifikaten
DE69929095T2 (de) Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels
DE60207251T2 (de) Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE4436677B4 (de) Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem Telekonferenzsystem
DE60204729T2 (de) Objektenlöschen von einem Vorrichtungspeicher
DE60220418T2 (de) Verfahren und Anbieter zur Systemsynchronisation
DE202011110895U1 (de) Echtzeitsynchronisierte Bearbeitung von Dokumenten durch mehrere Benutzer für das Bloggen
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
DE69937715T2 (de) Verbessertes Zwei-Phasen-Bindungsprotokoll
DE112020005289T5 (de) Teilweise sortierte blockchain
DE112021005116T5 (de) Abstimmungsbasierter ansatz für differentiell privates föderiertes lernen
DE69636993T2 (de) Informationsverarbeitungssystem und Kommunikationsverfahren
WO2006040139A1 (de) Serverlose replikation von datenbanken
DE112013001175T5 (de) Erzeugen von elektronischen Stammbäumen
DE102010033536A1 (de) Gemeinschaftliches dreidimensionales Echtzeit-Asset-Management-System
DE112018001561T5 (de) Verteiltes speichernetzwerk
WO2014095001A1 (de) Reputationssystem und verfahren
DE102021123579A1 (de) Identifizieren von schwesterknoten auf der grundlage eines kontextknotens
WO2022022997A1 (de) Kanalbasierte kommunikation in einem iot-netzwerk
EP3591925A1 (de) Verschlüsselungssystem für vertrauensunwürdige umgebungen
DE102004050348B3 (de) Verfahren zur Initialisierung eines Datennetzes

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: MICROSOFT CORP., REDMOND, WASH., US