| Startseite | |||||||||||
|
Google Wave Lösung mit Flex - Teil 1Echtzeitkollaboration an Dokumenten mit Wave und Adobe Flex
Die neue Welt der Rich Internet Applications erfordern tiefgreifende Mechanismen um Echtzeitkollaboration zwischen mehreren Clients zu ermöglichen. Adobe zeigt als Vorreiter mit den LiveCycle Data Services (LCDS) wie serverseitiges Realtime-Messaging mit Data Push, Offline-Fähigkeiten und Konfliktauflösung  funktionieren kann. Was ist aber, wenn gemeinsam an einem Dokument gearbeitet werden soll? Wave ist mehr als eine Mischung zwischen Instant-Messaging und E-Mail. Wie die gleichzeitige Bearbeitung von Dokumenten aussieht, kann auch über die Realisierung von EtherPad, dem Marktführer und Vorreiter einer solchen Technologie, ausprobiert werden. Google entschloss sich das Know-How von Etherpad in Google Wave mit einfliessen zu lassen und kaufte das Unternehmen AppJet im Dezember 2009 . esentri hat weltweit mit als erstes Unternehmen eine API entwickelt, mit der man beliebige Dokumentenstrukturen mit Wave in eigene Anwendungen integrieren kann. Mit einem 3-Teiligen Post wollen wir Ihnen tiefe Einblicke und Eindrücke in das Mysterium Wave geben.
Teil I - EinführungWas ist Google Wave? Google Wave ist ein internetbasiertes Echtzeit Kommunikations- und Kollaborationsprodukt, das am 27. Mai 2009 von Google Inc. vorgestellt wurde. Das System arbeitet auf Client/Server-Basis und vereinigt die Funktionalität mehrerer Kommunikations- und Kollaborationsdienste und bietet diese über ein Web-Interface den Benutzern an. Die Idee hinter Google Wave wurde von den australischen Brüdern Jens und Lars Rasmussen konzipiert, die mit ihrer ehemaligen Firma schon die Grundlagen von GoogleMaps entwickelt haben. In Google Wave werden Konversationen geführt, die sich gleichzeitig asynchron wie E-Mail oder synchron wie Instant-Messaging verhalten. Z.B. kann ein Chat fließend in das gemeinsame Editieren von Dokumenten übergehen. Änderungen von Teilnehmern werden fast in Echtzeit zu weiteren aktiven Teilnehmern propagiert. Darüber hinaus veröffentlichte Google die Spezifikation des Wave Federation Protocol und eine dazugehörige rudimentäre Client/Server Implementierung als Open Source, um es als offenen Standard zu etablieren. Auf Basis dieses Protokolls ist es möglich, von Google unabhängige Wave Systeme zu entwickeln. Die folgende Abbildung verdeutlicht den grundsätzlichen Aufbau eines Wave-Systems.
Abbildung 1: Grobarchitektur einer Wave Anwendung Architektur und Operationale Transformationen Die Grundarchitektur der Wave Plattform verfolgt das klassische Client/Server-Modell. Es existiert ein zentraler Wave Server, an dem sich beliebig viele Klienten registrieren können. Auf dem Wave Server werden XML Dokumente abgelegt. Man spricht davon, dass der Wave Server die XML Dokumente hosted. Klienten, die sich am Wave Server registriert haben, replizieren das serverseitige Dokument lokal. Nun sind die Klienten in der Lage, das lokale Dokument über Operationen zu mutieren (d.h. verändern) ohne dabei auf pessimistische Sperrmechanismen, wie z.B. in einer Datenbank, zurückgreifen zu müssen. Änderungen eines Klienten werden ohne Verzögerung auf das lokale Dokument angewendet, danach werden die Operationen weiter zum Wave Server propagiert. Der Wave Server sorgt dafür, dass das zentral gehostete Dokument immer in einen global konsistenten Zustand überführt wird, indem er wohldefiniert die konfliktbehafteten Operationen der Klienten auflöst und auf das gehostete Dokument anwendet. Es ist zu beachten, dass Operationen, die von einem Klienten zum Wave Server abgesetzt werden, durch die Latenzzeit des Übertragungsnetzes stark verzögert eintreffen können. Sobald der Wave Server die Mutationen eines Klienten übernommen hat, wird die Operation zu den restlichen Klienten im System weitergeleitet. Dabei können diese weitergeleiteten Operationen auch wieder stark verzögert bei eintreffen. Die hohe Latenzzeit des Übertragungsnetzes ist jedoch für den Benutzer nicht spürbar, da dessen lokale Änderungen sofort auf die lokalen Dokumente angewendet und sichtbar werden. Da Wave Klienten gleichzeitig Operationen auf ein Wave Dokument absetzen können, entstehen dadurch Konflikte zwischen lokal erzeugten und vom Wave Server empfangene Operationen.
Um die simultane Bearbeitung von Wave Dokumenten mit mehreren Personen zu ermöglichen, verwendet Wave die Operationale Transformation (kurz OT) als theoretisches Modell zur optimistischen Nebenläufigkeitskontrolle. Ein konfliktbehaftetes Szenario, hier in Abbildung 2 dargestellt, beschreibt zwei Klienten, die ausgehend von einem gemeinsamen Dokumentenzustand “ABCD“ gleichzeitig ihr lokales Dokument modifizieren (Zur Verdeutlichung des Prinzips wird hier bewusst auf den Wave Server verzichtet). Klient 1 führt eine Insert Operation an Position 3 durch und fügt dabei ein Item “X“ ein. Zum selben Zeitpunkt führt Klient 2 an Position 1 eine Delete Operation durch und löscht das Item “B“. Nachdem die Operationen lokal angewendet wurden, werden die Operationen zur gegenüberliegenden Seite übermittelt.
Abbildung 2: Konfliktbehaftetes Szenario zwischen zwei Klienten Werden die empfangenen Operationen jeweils auf die lokalen Dokumente angewendet, so löscht Klient 1 das zweite Item “B“ und mutiert das Dokument von Zustand “ABCXD“ in den neuen Zustand “ACXD“. Auf der Seite von Klient 2 wird die empfangene Insert Operation auf den Zustand “ACD“ angewendet und es entsteht der fehlerhafte Dokumentenzustand “ACDX“, da die Insert Operation auf Basis des Ursprungszustands “ABCD“ generiert wurde. Somit enden die beiden Klienten in unterschiedlichen Dokumenten und der Zustand ist nicht mehr konsistent. Auflösung von Konflikten Zur Lösung des gegebenen Konflikts wird eine Funktion xform definiert, die ein Paar aus lokaler und empfangener Operation in ein korrigiertes Operationspaar abbildet. Man schreibt
wobei c und s jeweils die originalen Client und Server Operationen sind. Die erzeugten Operationen c‘ und s‘ müssen die Eigenschaft besitzen, dass, wenn die Operation c und danach die Operation s‘ auf ein Dokument angewendet werden, der gleiche finale Endzustand erzeugt wird, wie wenn auf die Serveroperation s die korrigierte Operation c‘ angewendet wird.
Abbildung 3: Lösung des Konflikts mithilfe der xform Funktion
Der bestehende Konflikt für Client 2 (C2) wird mithilfe der Xform Funktion aufgelöst, indem der Positionsparameter der empfangenen Server Operation ( ins(3,X) ) um eine Position vermindert wird. Für Client 1 hat die Anwendung der XForm Funktion keine Auswirkung auf die lokale und empfangene Operation. Mithilfe dieses Transformationsprozesses werden die erzeugten Konflikte korrigiert und das Server Dokument und die replizierten Client Dokumente konvergieren somit immer gegen einen gemeinsamen konsistenten Zustand. Ausblick Im nächsten Teil werden wir unsere architektonische Lösung und einen in Adobe Flex implementierten Client vorstellen.
|
