DiplomarbeitUmsetzung einer verteilten Anwendungmit der dokumentenorientiertenDatenbank CouchDBEin Gliederungseditor als replizierbares Verteiltes SystemLena HerrmannBeuth Hochschule fr Technik BerlinUniversity of Applied SciencesUpstream-Agile GmbHFachbereich VI Informatik und MedienStudiengang Medieninformatik, Schwerpunkt SoftwareMatrikelnummer 720742Betreuer: Prof. Dr. Stefan EdlichGutachter: Prof. Dr. Frank SteyerEingereicht am 14. Juli 2010For most of mankinds history we have lived in very small communities in which we kneweverybody and everybody knew us. But gradually [...] our communities became too large anddisparate [...], and our technologies were unequal to the task of drawing us together. But thatis changing.Interactivity. Many-to-many communications. Pervasive networking. ese are cumbersomenew terms for elements in our lives so fundamental that, before we lost them, we didnt evenknow to have names for them.(Douglas Adams, )AbstractAuf heutigen Webbrowsern und mobilen Endgerten knnen komplexe Anwendungenausgefhrt werden. Diese ermglichen Zusammenarbeit und Datenaustausch zwischenBenutzerInnen. Bei Laptops und Mobilfunkgerten kann keine kontinuierliche Internetver-bindung vorausgesetzt werden. Um dieses Problem zu bercksichtigen kann Datenreplika-tion eingesetzt werden, wobei die Daten regelmig synchronisiert und dabei konsistentgehalten werden mssen. In dieser Arbeit wird die Konzeption und prototypische Erstel-lung einer JavaScript-Anwendung beschrieben, die mithilfe der dokumentenorientiertenDatenbank CouchDB einen verteilten Gliederungseditor umsetzt. Mit einem Gliederungs-editor knnen z. B. Gedanken oder Konzepte hierarchisch geordnet aufgeschrieben werden.Neben der Einordnung des zu erstellenden Systems und einer Analyse der in Frage kom-menden Lsungsmglichkeiten werden die verwendeten Technologien beschrieben. Genauvorgestellt werden dabei CouchDB mit der eingebauten Master-Master-Replikation und derMglichkeit, eine komplexe Applikation ohne Middleware zu implementieren. Die erstellteAnwendung lu lokal imBrowser und ist dadurch auch oine benutzbar. Konikte werdenbei der Synchronisation vom System, teilweise mit Benutzeruntersttzung, aufgelst. In derArbeit wird abschlieend die Einsetzbarkeit von CouchDB fr eine verteilte Anwendungund speziell fr den gewhlten Anwendungsfall beurteilt.Gliederung1 Einleitung 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Textauszeichnung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Aufgabenstellung 43 Analyse 6. Anforderungen an einen Gliederungseditor . . . . . . . . . . . . . . . . . . . . . . .. Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Einsatzmglichkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anforderungen an Verteilte Systeme. . . . . . . . . . . . . . . . . . . . . . . . . . . Anforderungen an Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verschiedene Lsungsanstze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Manueller Austausch von Dokumenten . . . . . . . . . . . . . . . . . . . .. Echtzeit-Texteditoren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Versionsverwaltungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . .. Datenbanken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beschreibung des gewhlten Lsungsansatzes . . . . . . . . . . . . . . . . . . . . 4 CouchDB - eine Datenbank fr Verteilte Systeme 15. eoretische Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Einordnung der Datenbankarchitektur . . . . . . . . . . . . . . . . . . . . .. Das CAP-eorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Transaktionen und Nebenlugkeit . . . . . . . . . . . . . . . . . . . . . . .. Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. HTTP-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Abgrenzung zu relationalen Datenbanksystemen . . . . . . . . . . . . . . . Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Dokumente und Koniktbehandlung . . . . . . . . . . . . . . . . . . . . . .. HTTP-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Change Notications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Anwendungen mit CouchDB . . . . . . . . . . . . . . . . . . . . . . . . . .. Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Technische Grundlagen 32. Webtechnologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. CouchApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Sammy.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Mustache.js. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Weitere Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Stile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Vor- und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Methoden und Mittel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Testing Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Entwicklungsumgebungen. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Anforderungen an das System 53. Funktionale Anforderungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Muss-Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Kann-Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Abgrenzungs-Kriterien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Benutzeroberche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Qualittsziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Systemarchitektur 62. Gesamtberblick ber die Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . Modellierung der Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Speicherung in einem JSON-Dokument . . . . . . . . . . . . . . . . . . . .. System Prevalence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Speicherung der Versionshistorie . . . . . . . . . . . . . . . . . . . . . . . .. Ausgliedern der Zeilen in einzelne JSON-Dokumente . . . . . . . . . . . .. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Umsetzung der Zeilensortierung und -einrckung . . . . . . . . . . . . . . . . . . .. Indiziertes Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Verkettete Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Baumstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Koniktbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Gleichzeitiges Einfgen einer Zeile . . . . . . . . . . . . . . . . . . . . . . .. Gleichzeitiges ndern einer Zeile. . . . . . . . . . . . . . . . . . . . . . . .. Weitere Koniktarten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Benachrichtigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benutzeroberche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Strategien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Seitenaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Systemdokumentation 80. Projektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benutzeroberche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Umsetzung des Gliederungseditors. . . . . . . . . . . . . . . . . . . . . . .. Modizierung des DOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Rendern der Baumstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Starten der Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Benachrichtigung bei nderungen. . . . . . . . . . . . . . . . . . . . . . . Konikterkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Koniktbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Append-Konikte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Write-Konikte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Kombination aus beiden Koniktarten . . . . . . . . . . . . . . . . . . . . . Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Integration Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Testsuite fr die CouchDB HTTP-API . . . . . . . . . . . . . . . . . . . . . Deployment mit Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . Clustering mit Couchdb-Lounge . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Konguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Anwendung 102. Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. CouchDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Grundfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Koniktbehandlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Hilfestellung zur Erzeugung der Konikte . . . . . . . . . . . . . . . . . . 10Bewertung und Ausblick 113. Bewertung des Ergebnisses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Zukun der eingesetzten Technologien . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen fr die Weiterentwicklung. . . . . . . . . . . . . . . . . . . . . . . Anhang iA. Abkrzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iA. Ergnzungen zur Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiA. Ergnzungen zum Technischen Hintergrund. . . . . . . . . . . . . . . . . . . . . ivA. Ergnzungen zu den Systemanforderungen. . . . . . . . . . . . . . . . . . . . . . viA. Ergnzungen zur Systemdokumentation . . . . . . . . . . . . . . . . . . . . . . . . viiiA. Inhalt der CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiVerzeichnisse xxiiLiteraturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviiInternetquellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviiAbbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxixVerzeichnis der Quelltextauszge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xli

1Einleitung1.1MotivationWere at the dawn of a new age on the web, or maybe on a horizon, or a precipice; themetaphor doesnt matter, the point is, things are changing. Specically, as browsersbecome more and more powerful, as developers were given new opportunities torethink how we architect web applications. [Qui]Das Internet wird mehr und mehr ein Bestandteil des alltglichen Lebens. Der Anteil der regel-migen Internetnutzer in Deutschland liegt im JahrbeiProzent und steigt stetig an.Unter denbis jhrigen betrgt der Anteil der Menschen, die das Internet nie nutzen, nurnochProzent [Ini, S. ]. Mit der Anzahl der Benutzer nimmt die Normalitt zu, mit derWebanwendungen fr Zusammenarbeit, Kommunikation und Datenaustausch benutzt werden.Dabei mssen diese Webanwendungen einer steigenden Anzahl von Benutzern zeitgleichenZugri erlauben. Dem Webbrowser kommt dabei als Plattform fr Anwendungen eine immergrere Bedeutung zu [Pau, S. )]. Kaum eine Soware hat sich in den letzten zehn Jahrenso weiterentwickelt wie der Webbrowser [GJ]. Dadurch entstehen auch neue Mglichkeiten,Webanwendungen zu entwickeln: Es knnen immer hhere Anforderungen an Bedienbarkeit,Einsetzbarkeit und Verfgbarkeit der Anwendungen gestellt und auch erfllt werden.Ein weiterer Trend ist die zunehmende Verbreitung von mobilen Endgerten [Ini, S. ]. In[Kot, S. ] wird vorausgesagt, dass durch das Wachstumder Angebote imInternet in Verbindungmit der Weiterentwicklung der Informationstechnologien die Anzahl der Zugangsgerte starkansteigen wird. Mobile Endgerte sind heute vor allem Laptops und Mobiltelefone. Diese habeno eine schlechtere Konnektivitt als stationre Endgerte. Lange Phasen ohne Verbindung sinddie Norm, weitere Herausforderungen sind hohe Latenzen und limitierte Bandbreite [Guy].Es besteht also ein groer Bedarf an Technologien, die die oben aufgefhrten Ansprche anZusammenarbeit und Datenaustausch erfllen. Diese mssen die Umsetzung von Systemenermglichen, die in groem Rahmen skalieren. Gleichzeitig sollen sie aber auch den Bedarf ankontinuierlicher Konnektivitt stark reduzieren. Eine mgliche Lsung fr diese Art Problem istDatenreplikation. Diese wird bei [Guy] so umrissen:Copies of data are placed at various hosts in the overall network, [...] oen local tousers. In the extreme, a data replica is stored on each mobile computer that desires toaccess that data, so all user data access is local..Aufbau der Arbeit Die Schwierigkeit hierbei ist, die Daten regelmig zu synchronisieren und konsistent zu halten.Die berwachung der Konsistenz ist Aufgabe des Systems, das die Replikation durchfhrt. Zieleeines solchen Systems sind hohe Verfgbarkeit und Kontrolle ber die eigenen Daten. Eine solcheLsung kann gleichzeitig den hohen Ansprchen an Datenschutz gengen, die Benutzer anmoderne Webanwendungen stellen [Kraa, Krab]. Bei Systemen, die Replikation umsetzen,knnen die Benutzer selbst entscheiden, mit wem sie ihre Daten teilen. Bei entsprechenderImplementierung des Systems ist die Benutzung auerdem zumindest zeitweise unabhngigvon zentralen Servern. Der Ausfall des Netzwerks oder einzelner Knoten ist von vornherein miteingeplant.In dieser Arbeit wird die Konzeption und Umsetzung einer Soware beschrieben, die die Daten-bank CouchDB verwendet. Mit CouchDB knnen Anwendungen umgesetzt werden, die sowohlnach oben als auch nach unten skalieren: Anwendungen sollen sich auf beliebig viele Kno-ten verteilen lassen, um Verfgbarkeit und Performance Leistung) zu gewhrleisten. Sie sollenaber auch auf mobilen Endgerten einsetzbar sein und Synchronisierung von Benutzerdatenermglichen [Leh].1.2Aufbau der ArbeitZu Beginn wird die zentrale Fragestellung der Arbeit deniert (Kapitel ). Das Ziel dieser Arbeitist die fundierte Beantwortung dieser Frage. Um dies zu ermglichen, wird in Kapitelzunchsteine Einordnung des zu erstellenden Systems und eine Analyse der in Frage kommenden L-sungsmglichkeiten vorgenommen.Kapitelwidmet sich der Datenbank CouchDB. In Abschnitt . wird diese theoretisch ein-geordnet, in Abschnitt . werden die Umsetzungsdetails erklrt. In Kapitelwerden weitereTechnologien vorgestellt, die in die Umsetzung der Anwendung eingeossen sind. Beschrie-ben werden nacheinander die verwendeten Webtechnologien (Abschnitt .), Cloud Computing(Abschnitt .) sowie die untersttzenden Werkzeuge (Abschnitt .).Die Anforderungen an die Anwendung werden in Kapitelspeziziert. In Kapitelwird dieStruktur der Anwendung umrissen, auch hierbei werden verschiedene Designalternativen ge-geneinander abgewogen. Die technischen Details des fertigen Systems sind in Kapitelskizziert,ergnzt von Quelltextauszgen im Anhang. Eine Bedienungsanleitung fr die Anwendung inKapitelschliet den praktischen Teil der Arbeit ab. Eine Beurteilung des Ergebnisses der Arbeitwird abschlieend in Kapitelvorgenommen.. Textauszeichnung 1.3TextauszeichnungDie Informatik ist ein Gebiet, in dem sich viele englische Begrie im Deutschen eingebrgerthaben. Fr viele dieser englischen Begrie gibt es noch keine Entsprechung, fr manche werden inder Literatur unterschiedliche deutsche bersetzungen verwendet. In dieser Arbeit wird dort, woder englische Begri im Deutschen blicherweise verwendet wird, der englische Originalbegribeibehalten. Eine Neubersetzung von englischen Begrien wurde bewusst vermieden. Eine deut-sche bersetzung ist fr bessere Verstndlichkeit beim ersten Aureten des Begris in Klammernangegeben. Gibt es im Deutschen einen passenden Begri, wird die englische Bedeutung beimersten Aureten des Begris in Klammern angegeben.Zur besseren bersichtlichkeit und Lesbarkeit dieser Arbeit werden manche Begrie besondershervorgehoben. Im Text erklrte Fachbegrie sowie Namen von eingesetzten Technologienwerden bei ihrem ersten Aureten kursiv gesetzt. Bei erneutem Aureten werden solche Begrienicht besonders ausgezeichnet. Im Abkrzungsverzeichnis im Anhang A. knnen verwendeteAbkrzungen nachgeschlagen werden. Begrie aus dem Quelltext werden bei jedem Vorkommendurch die Verwendung der Schriart Courier gekennzeichnet. Quelltextauszge sind in einerTypewriter-Schri gesetzt, als Block gesetzte Quelltextauszge sind auerdem hell hinterlegt undmit einem Rahmen versehen. Zitatblcke sind rechts und links eingerckt. Zitate im Flietextsind in Apostrophe gesetzt.

2AufgabenstellungIn der Einleitung wurde auf die vernderten Gegebenheiten und erhhten Ansprche an An-wendungsprogramme in der heutigen Zeit (Juni ) hingewiesen. Mehr Menschen nutzengleichzeitig mit immer mehr mobilen Endgerten immer grere Systeme und stellen dabeiimmer hhere Ansprche an Benutzbarkeit und Verfgbarkeit.Gleichzeitig schreitet die Entwicklung von Technologien voran, mit der diese gestiegenen Anforde-rungen immer besser umgesetzt werden knnen. Im Bereich der Datenbanksysteme entwickeltesich im letzten Jahrzehnt eine Bewegung mit dem Namen ^oSOL [Str]. NoSQL ist einenicht nher eingegrenzte Bezeichnung fr eine Reihe nichtrelationaler Datenbanksysteme bzw.Key-Value-Stores. Sie haben gemeinsam, dass sie im Gegensatz zu relationalen Datenbanken meistkeine festen Tabellenschemata bentigen. Besonderen Schwerpunkt setzen sie auf Verteilbarkeitund eignen sich dadurch meist fr die Skalierung im groen Mastab. Die Vorzge traditionellerDatenbanksysteme, insbesondere die Konsistenz zu jedem Zeitpunkt, werden o gegen einebessere Verfgbarkeit oder Partitionstoleranz (s. Abschnitt ..) getauscht.Diese neuen Datenbanksysteme wurden jeweils fr spezische Anwendungsflle entwickelt.Ein umfassender Vergleich von NoSQL-Datenbanksystemen ist nicht Gegenstand dieser Ar-beit. Stattdessen soll die Einsetzbarkeit eines bestimmten NoSQL-Datenbanksystems anhandeines konkreten Anwendungsfalles berpr werden. Kann nach eingehender Analyse mit derausgewhlten Technologie eine funktionsfhige Soware umgesetzt werden?Die dokumentenorientierte Datenbank CouchDB [Apac] wurde in der Einleitung bereitskurz vorgestellt. Bei einer mit CouchDB implementierten Anwendung kann der Einsatz vonMiddleware vllig entfallen. Master-Master-Replikation ist eine Kernfunktion, was CouchDBbesonders geeignet fr verteiltes Arbeiten macht. CouchDB-Anwendungen laufen direkt aus demWebbrowser heraus, deshalb ist die Anzahl der fr den Betrieb zu installierenden Programmeminimal. So kann das Systemauf einer mglichst hohen Anzahl von Endgerten eingesetzt werden.Die Wahl gerade dieses Datenbanksystems wird in den Kapitelnundgenauer begrndet.Als Anwendungsfall fr den Einsatz von CouchDB wurde ein Outliner Gliederungseditor) gewhlt.Mit einem Outliner knnen z. B. Gedanken oder Konzepte hierarchisch geordnet aufgeschriebenwerden. Als Vorlage dient das ProgrammOmniOutliner [Omn], ein lokales Desktop-Programmfr Mac OS X. Ziel ist, einen Gliederungseditor mit hnlicher, aber eingeschrnkter Funktionalittprototypisch zu erstellen und dadurch die Einsetzbarkeit von CouchDB zu analysieren.Die hier konzipierte Anwendung unterscheidet sich in einem zentralen Punkt von der Vorlage:Mit ihr soll gemeinschaliches Arbeiten an Dokumenten auch verteilt ber Netzwerke ermg-Aufgabenstellung licht werden, selbst wenn der Benutzer zwischenzeitlich vom Internet getrennt ist. Die fr dieArbeit erstellte Anwendung wird lokal im Browser laufen und oine benutzbar sein. ber ei-ne Internetverbindung werden Daten von mehreren Benutzern gleichzeitig bearbeitet werdenknnen.In dieser Diplomarbeit soll also untersucht werden, ob sich CouchDB dafr eignet, verteilte An-wendungen zu erstellen. Um dies zu prfen, wird der Prototyp eines verteilten Gliederungseditorsentworfen und umgesetzt.

3AnalyseIn Kapitelwurden Anforderungen an ein System grob skizziert. Entwurf und Implementie-rung dieser Anwendung sowie die Auswertung des Ergebnisses sind Gegenstand dieser Arbeit.Im folgenden Kapitel werden die Problemstellungen, die die Anwendung lsen soll, sowie diewissenschaliche Einordnung der Anwendung noch einmal nher untersucht. Dann werdenunterschiedliche Lsungsanstze daraufhin analysiert, mit welchen Mitteln ein solches Systemam besten umzusetzen ist. Dabei wird auf alternative Anstze eingegangen.3.1Anforderungen an einen GliederungseditorBevor der hier gewhlte Lsungsweg von anderen Mglichkeiten abgegrenzt wird, werden zu-nchst die Eigenschaen und Anforderungen der umzusetzenden Anwendung genauer festgelegt.3.1.1DefinitionEin Gliederungseditor oder Outliner wird bei Wikipedia als eine Mischung aus einer Freiform-Datenbank und einem Texteditor beschrieben [Wika]:An outliner is a computer program that allows one to organize text into discretesections that are related in a tree structure or hierarchy. Text may be collapsed into anode, or expanded and edited. [Wikc]Manche Gliederungseditoren ermglichen auerdem eine Formatierung der Eintrge und dasEinbinden von verschiedenen Medientypen. Es gibt eine Vielzahl von Implementierungen dieserArt Programm.Eine der am hchsten bewerteten Umsetzungen [Mac] ist die kommerzielle Soware Om-niOutliner [Omn] (Screenshot s. Abb. A.). Dieses Programm wird von der Firma OmniGroup fr das Betriebssystem Mac OS X entwickelt. Es hat neben den blichen Eigenschaeneines Gliederungseditors noch weitere spezielle Features. OmniOutliner soll beim Entwurf derAnwendung als Vorlage dienen, wenn auch in diesemPrototypen lngst nicht alle seine Merkmaleumgesetzt werden knnen..Anforderungen an Verteilte Systeme 3.1.2EinsatzmglichkeitenDie Einsatzmglichkeiten eines Outliners sind sehr vielfltig, hnlich wie beispielsweise dieeines Texteditors. Im Folgenden werden nur einige der mglichen Szenarien fr die Benutzungeines Outliners vorgestellt. Einige Szenarien sind an [Wika] angelehnt, einige wurden von derAutorin selbst festgelegt. Den Entwurfsentscheidungen bei der Sowareentwicklung liegen dieseAnwendungsflle zugrunde.Der ursprngliche Zweck eines Gliederungseditors wird in [Wika] als der von Geisteswissen-schalern hug verwendete Zettelkasten beschrieben:Mehr oder weniger groe Textabschnitte (z. B. Zitate) werden in einer nach Kategori-en sortierten und verschlagworteten Datei abgelegt und stehen so zur Verfgung. [...]Auf diese Weise lsst sich schnell einumfangreiches Archiv anwichtigenTextpassagenaufbauen.Ein hug zitierter Anwendungsfall fr Gliederungseditoren ist das Verfassen von literarischen,journalistischen oder wissenschalichen Texten. Zuerst kann der Umriss der Handlung struktu-riert nach Kapiteln und Szenen eingegeben werden. Anschlieend kann der Benutzer Details indie ste des Gliederungsbaums einpegen. Spter knnen Teile des Textes verschoben werden,in dem man die Knoten in der Baumstruktur hin- und herbewegt. Dies ist bei einem Texteditoroder auch einem Textverarbeitungsprogramm wesentlich schwieriger umzusetzen.Gliederungseditoren knnen auch immer dann eingesetzt werden, wenn eine grere Mengekrzerer Textpassagen gespeichert werden sollen. Dies kann z. B. Aufgaben, Ideen, Protokolle,Tagebcher oder Einkaufslisten umfassen.3.2Anforderungen an Verteilte SystemeIn diesem Abschnitt wird zunchst eine Denition von Verteilten Systemen vorgenommen. Eswird gezeigt, dass es sich bei der zu erstellenden Anwendung um ein Verteiltes System handelt. Inden darauolgenden Abschnitten wird dann begrndet, warum CouchDB fr die Umsetzungeines solchen Systems gewhlt wurde.Eine vielzitierte Denition ndet sich in [Tan, Kap. .]:Ein Verteiltes System ist eine Ansammlung unabhngiger Computer, die den Benut-zern wie ein einzelnes kohrentes System erscheinen.Diese Beschreibung kann sich auf eine beliebig groe Anzahl von Rechnern beziehen. So werdenin [Cou, Kap. .] und in [Ben, S. ] auch das Internet bzw. das World Wide Web als Verteilte.Anforderungen an Verteilte Systeme Systeme bezeichnet. Es existieren aber auch weitergefasste Denitionen, in denen nicht nur diepysikalisch verteilte Hardware, sondern auch logisch verteilte Anwendungen als Verteiltes Systembezeichnet werden [Ben, S. ]. Nach [Cou, Kap. .] ist es die grundlegende Eigenscha einesVerteilten Systems, ausschlielich ber Message Passing zu kommunizieren. Allgemein kanngesagt werden:Adistributed systemis a systemwhich operates robustly over a wide network. [And,Kap. ]Ein Systemist demnach ein Verteiltes System, wenn es in mehrere Komponenten getrennt werdenkann, die autonom sind - das heit, sie mssen jeweils fr sich wieder ein vollstndiges Systembilden. Die einzelnen Subsysteme knnen hierbei sehr inhomogen sein, was Implementierungbzw. Betriebssysteme und Hardware angeht. Die Art der Verbindung kann ebenfalls beliebigumgesetzt sein. Auerdem sollte fr Benutzer wie fr Programme, die das System benutzen, derEindruck entstehen, es mit einemeinzigen Systemzu tun zu haben. Bei der Entwicklung VerteilterSysteme stellt sich die Aufgabe festzulegen, wie die Komponenten des Systems transparent frden Benutzer zusammenarbeiten. Der innere Aufbau des Systems soll fr den Benutzer nichtersichtlich sein. Weiterhin soll mit dem System konsistent und einheitlich gearbeitet werdenknnen, unabhngig von Zeitpunkt und Ort des Zugris [Tan, Kap. .].Nach [Cou, Kap. .] und [Tan, Kap. .] mssen beim Entwurf von Verteilten Systemenfolgende Herausforderungen beachtet werden:Nebenlufigkeit (Concurrency): Komponenten eines Systems fhren Programmcode neben-lug aus, wenn sie auf gemeinsam genutzte Ressourcen gleichzeitig lesend und schreibendzugreifen, sich aber gegenseitig nicht beeinussen. Bei einem Verteilten System mssendaher auf nebenluge Prozesse ausgerichtete Algorithmen verwendet werden.Keine globale Uhr: Die Uhren der Subsysteme lassen sich nicht synchron halten. Fr Ausungvon Bearbeitungskonikten knnen daher keine Zeitstempel verwendet werden. MVCCMulti Version Concurrency Control) verwendet stattdessen o Vektoruhren [Lam] oderandere eindeutige Identikationsmechanismen wie UUIDs Universally Unique Identifer)[Lea].Ausfall von Subsystemen: Der Ausfall einer einzigen Komponente oder eine Strung im Netz-werk drfen das Gesamtsystem nicht beeintrchtigen. Die Subsysteme mssen unabhngigvoneinander funktionieren, auch wenn die Verbindung zwischen ihnen zeitweise oderlnger abbricht, oder eines von ihnen nicht mehr funktioniert.In Kapitel . wird auf diese Probleme im Detail eingegangen.. Anforderungen an Groupware 3.3Anforderungen an GroupwareGroupware-Systeme sind nach [Ell] ...... computer-based systems that support two or more users engaged in a commontask, and that provide an interface to a shared environment. ese systems frequentlyrequire ne-granularity sharing of data and fast response times.Wie bei jedemSoware-Projekt drfenbeimEntwurf eines VerteiltenSystems nicht nur technischeMglichkeiten eine Rolle spielen. Ebenso mssen die realen Anforderungen der angestrebtenBenutzergruppen bei der Planung miteinbezogen werden. So soll hier der Frage nachgegangenwerden, was die spezischen Fragen und Probleme bei der Benutzung einer Groupware sind, undwas demzufolge bei Entwurf, Entwicklung und Schulung besonders zu beachten ist.Die in dieser Arbeit eingesetzte Datenbank CouchDB wird o mit Lotus Notes verglichen. DamienKatz, der Ernder von CouchDB, ist ehemaliger Notes-Entwickler und war nach eigenen Aussa-gen bei der Entwicklung von CouchDB von Notes stark inspiriert [Sch]. Notes ist CouchDBinsofern hnlich, als dass eine Datenbank in Notes eine Sammlung von halbstrukturierten Doku-menten ist, die durch Views organisiert sind [Kaw, Kap. ]. Nach [Kaw] ist Lotus Notes einKommunikationssystem, das es Gruppen erlaubt, unterschiedliche Informationen wie Texte undNotizen zu teilen und gemeinsam zu bearbeiten:e system supports groups of people working on shared sets of documents and isintended for use in a personal computer network environment in which the databaseservers are rarely connected. [Kaw, Kap. ]Die Parallelen zwischen Lotus Notes und der hier entwickelten Anwendung liegen also darin, dassletztere zumindest gleiche Teilaufgaben von Notes erfllen soll. Auerdem erfolgt die Synchroni-sierung der Dokumente ebenfalls durch Datenbank-Replikation. Demnach sind wissenschalicheErkenntnisse ber die Benutzung von Lotus Notes fr die Konzeption der Anwendung durchausinteressant.Mehrere Studien haben die Auswirkungen der Einfhrung von Lotus Notes auf die Zusammenar-beit in verteilten Gruppen untersucht.In [Van] wurde der Einuss von Notes auf die Zusammenarbeit in einer groen Versicherungs-gesellscha analysiert. Obwohl die Mitarbeiter mit dem Produkt sehr zufrieden waren, wurdekeine verstrktere oder bessere Zusammenarbeit unter ihnen festgestellt. Die Studie kommt zudemSchluss, dass ein Systemsehr genau zu der Zielgruppe passen muss, und dass der grndlichenSchulung in dieser neuen Technologie eine zentrale Bedeutung beikommt.Die Autorin von [Kar] stellt fest, dass Benutzer, die noch nie vorher mit einer Groupwaregearbeitet haben, das neue Programm meist wie ein ihnen vertrautes (also lokales Single-User-).Verschiedene Lsungsanstze Programm benutzen:[e] ndings suggest that when people neither understand nor appreciate the co-operative nature of groupware, it will be interpreted as an instance of some morefamiliar technology and used accordingly. is can result in counter-productive anduncooperative practice and low levels of use. [Kar, S. ]Dies wird von einer anderen Untersuchung besttigt:e ndings suggest that where peoples mental models do not understand or ap-preciate the collaborative nature of groupware, such technologies will be intepretedand used as if they were more familiar technologies, such as personal, stand-alonesoware (e.g., a spreadsheet or word processing program). [Orl, S. ]Wenn die Konstruktion der Soware von der Organisationskultur der Gruppe abweicht, wirddie Soware mit hoher Wahrscheinlichkeit nicht dazu beitragen, sinnvoll kollektiv genutzt zuwerden. Eine Groupware muss vielmehr auf die bestehenden Arbeitsablufe innerhalb einerGruppe angepasst werden, um Arbeitsprozesse zu verbessern. Umfasst die Aufgabe der SowareKoniktbearbeitung, ist es fr einen Erfolg der Soware ebenfalls wichtig, dass diese die blichenKoniktlsungsstrategien des Teams untersttzt. [Mon]Es bleibt festzustellen, dass eine Soware, mit deren zentralen Charakteristika die Benutzer nochnicht vertraut sind, zum einen genau an die Zielgruppe angepasst werden muss. Dies ist beidieser Aufgabenstellung schwierig, da der Prototyp fr die geplante Anwendung fr keine genauabgegrenzte Zielgruppe entwickelt wird. Die Aufgabe der Eingrenzung der Zielgruppe verbleibtfr eine sptere Entwicklungsphase. Zum anderen muss der Schulung bzw. der Dokumentationfr die Benutzer eine hohe Bedeutung zu kommen. Die hier entwickelte Arbeit soll einen Beitragdazu leisten, Menschen an die verstrkte Kooperation mithilfe von Soware zu gewhnen.3.4Verschiedene LsungsanstzeIm Folgenden werden unterschiedliche Lsungsanstze fr die Bearbeitung der Aufgabenstellungvorgestellt. Vor- und Nachteile bestehender Lsungen werden diskutiert und die angestrebteAlternative wird herausgehoben.Das zu lsende Problem ist: Wie knnen Dokumente von mehreren Benutzern gemeinsambearbeitet werden, auch wenn manche von ihnen fr lngere Zeit vom Internet getrennt sind?Wie kann das System auretende Bearbeitungskonikte mglichst automatisch behandeln odersie in einer fr den Benutzer geeigneten Form zur Lsung aufbereiten?.Verschiedene Lsungsanstze 3.4.1Manueller Austausch von DokumentenDas trivialste Verfahren ist das manuelle Synchronisieren. Dabei werden Dokumente direkt zwi-schen den einzelnen Benutzern ausgetauscht, z. B. per Email oder FTP, und nebenlug bearbeitet.Verschiedene Versionen mssen von einem Benutzer umstndlich per Hand zusammengefhrtwerden, das Resultat dessen muss selbst wieder ausgetauscht werden. Details knnen hierbeileicht verlorengehen.Manche Webdienste stellen Netzwerkdateisysteme bereit, mit dem das Synchronisieren der Datenautomatisch erledigt werden kann. Der Anbieter Dropbox [Dro] beispielsweise erlaubt es,Verzeichnisse und Dateien zwischen verschiedenen Rechnern auf einem Stand zu halten. Trittzwischenzeitlich ein Konikt auf, werden die verschiedenen Revisionen als einzelne Dateienabgelegt. Es ist dann wieder Sache des Benutzers, die Konikte aufzulsen.3.4.2Echtzeit-TexteditorenEin anderer Ansatz, der zunehmend Verbreitung ndet, sind zentralisierte Kooperationssystemeber das Internet. Benutzer knnen mit solchen Webanwendungen meist in Echtzeit gemeinsaman Dokumenten arbeiten. Beispiele sind Etherpad [Fou], Google Docs [Bel] und das neuereGoogle Wave [Goo]. In letzterem steht der Kommunikationscharakter im Vordergrund, dochknnen auch hiermit lngere Texte gleichzeitig bearbeitet werden. Google Docs hat im Vergleichzu Google Wave mehr die Eigenschaen eines Textverarbeitungsprogramms.Desktop-Programme wie der Texteditor SubEthaEdit [e] zeigen ihre Vorteile auch nur beifunktionierender Netzwerkverbindung. Mit SubEthaEdit knnen sich Benutzer ber das Bonjour-Protokoll imlokalen Netz oder ber das Internet nden und gegenseitig dazu einladen, gemeinsamein Dokument zu bearbeiten.Die in den beiden vorhergehenden Abstzen vorgestellten Anstze haben gemeinsam, dass sieentweder nur mit einer Internetverbindung funktionieren, oder die Koniktbehandlung nuruntersttzt wird, wenn von allen Clients gleichzeitig eine Verbindung zu einem Server hergestelltwird. Ansonsten muss das Zusammenfhren der konikthaen Versionen auch hier wiedermanuell geschehen.Bei manchen hier vorgestellten Programmen knnen die Tastaturanschlge der anderen Autorenlive mitverfolgt werden. Dies wird nicht nur positiv bewertet. In [Man] wird das Arbeiten mitGoogle Wave als like talking to an overcurious mind reader beschrieben - das Bewusstsein,dass andere Benutzer einem direkt beim Denken zusehen, lhmt hierbei den eigenen Gedanken-und Arbeitsuss. Auch bei Anwendungsfllen, bei denen Benutzer lnger an einem einzelnenDokument arbeiten und dadurch eine Art Besitzanspruch entsteht, fllt es unter Umstndenschwer, die nderungen am eigenen Text live mitansehen zu mssen [Edl]..Verschiedene Lsungsanstze Da die zu entwickelnde Anwendung durchaus auch fr das Arbeiten an lngeren Texten vorgese-hen ist, kann auf das Feature Live-Typing verzichtet werden.3.4.3VersionsverwaltungssystemeIm Bereich der Sowareentwicklung ist schon lange der Einsatz von Versionsverwaltungssyste-men wie Subversion [Apab] oder Git [Cha] weit verbreitet. Mit solchen Systemen werdennderungen an Dokumenten mitsamt Autor und Zeitstempel erfasst und in einzelnen Commitsgespeichert. Die Versionen knnen spter wiederhergestellt werden. Ebenfalls knnen mehrerenderungen von unterschiedlichen Benutzern an einer einzigen Datei vom System automatischzusammengefhrt werden.Ein solches System ist fr reine Textdateien sehr zweckmig. Deshalb werden solche Programmehauptschlich fr Soware-Verwaltung eingesetzt. Gngige Implementierungen haben aber keinInterface, das sich auch an weniger technisch versierte Menschen richtet. Die Umsetzung einerAnwendung mit beispielsweise einem Git-Backend ist aber eine erwgenswerte Option.3.4.4DatenbankenEs liegt nahe, einen Ansatz mit Datenbanken, insbesondere den in Kapitelvorgestellten neuenschemalosen Datenspeicher in Betracht zu ziehen. Einige Datenbanken oder Key-Value-Stores un-tersttzen Master-Master-Replikation und speichern die Daten auf der Festplatte. Diese kommengrundstzlich fr die Lsung der Aufgabe in Betracht.Die dokumentenorientierte Datenbank CouchDB unterscheidet sich von den Alternativen da-durch, dass sie einen eigenen Webserver mitbringt. Mit diesem knnen nicht nur die Datenausgeliefert, sondern auch in der Datenbank gespeicherte JavaScript-Dateien direkt ausgefhrtwerden. Dadurch kann die gesamte Anwendung in der Datenbank laufen. Das resultierende Pro-gramm ist dadurch automatisch von jedem Rechner bedienbar, auf dem CouchDB installiert ist,und der ber einen Browser verfgt. Diese Eigenschaen bringt keine der anderen untersuchtenDatenbanken mit.Die freien relationalen Datenbanken PostgreSQL [Groa] und MySQL [Cora] knnen fr Master-Master-Replikation zwischen zwei Mastern konguriert werden. Fr PostgreSQL existieren eineVielzahl an Erweiterungen [Grob], mit denen sich unter anderem ein Master-Master-Setupeinrichten lsst. MySQL bedient sich dazu der Technik MySQL-Cluster [Cord], die Master-Master-Replikation mit einer Shared-Nothing-Architektur ermglicht [Sto, Kap. ]. Unter [Max] istbeschrieben, wie eine Replikation auch zwischen mehreren Knoten umgesetzt werden kann.. Beschreibung des gewhlten Lsungsansatzes Der Key-Value-Store Riak [Bas] hat ebenfalls ein HTTP-Interface und speichert seine Datenverteilt - es handelt sich dabei aber nicht um Peer-to-Peer-Replikation wie in CouchDB, sondernumein Autobalancing fr bessere Verfgbarkeit und Performance Leistung) in greren Systemen.MongoDB [g] untersttzt beschrnkt Master-Master-Replikation und ermglicht EventualConsistency (vgl. Abschnitt ..), was sich fr ein verteiltes Konzept anbietet. Die Fhigkeit vonCouchDB, Anwendungslogik direkt in der Datenbank bzw. im Browser auszufhren, ist aberauch hier nicht vorhanden. Beide Technologien sind deshalb weniger gut als CouchDB fr dieUmsetzung der geplanten Anwendung geeignet.Replikation und Clustering in den beschriebenen Systemen sind in etwa vergleichbar mit derFunktionalitt von CouchDB-Lounge, die in Abschnitt . beschrieben ist. Automatische Markie-rung von Konikten untersttzt ebenfalls keines der Systeme. Fr die Umsetzung der Replikationinnerhalb der Anwendungslogik bietet sich deshalb keiner dieser Anstze an.Im direkten Vergleich wird deutlich, dass sich CouchDB am besten fr die Lsung der obengenannten Probleme eignet, da es Mglichkeiten zur Master-Master-Replikation, Koniktbe-handlung sowie ein passendes Konsistenz-Modell mitbringt, und Anwendungen direkt von derDatenbank ausgeliefert werden knnen. Im nchsten Abschnitt wird der gewhlte Lsungsansatznoch nher beschrieben.3.5Beschreibung des gewhlten LsungsansatzesDie Anwendung wird als lokales, aber netzwerkfhiges Programm erstellt. Die Daten werdendabei in einer CouchDB-Datenbank gespeichert, die Anwendungslogik wird als clientseitigesJavaScript im Browser ausgefhrt. Der Funktionsumfang des Gliederungseditors wird mindestensdas Erstellen und Lschen von Outlines umfassen; zeilenbasiert kann Text eingetragen und editiertwerden; Zeilen werden beim Verlassen automatisch gespeichert und knnen ein- und ausgercktwerden.Der Austausch der Daten sowie der Anwendung geschieht ber die in CouchDB eingebauteMaster-Master-Replikation. Hierbei drfen die Daten auf allen Rechnern, die eine Kopie haben,gleichberechtigt verndert werden. Auf einem Server lu eine weitere CouchDB-Instanz. DieReplikation zu diesem Server erfolgt automatisch, sobald von einem Benutzer dem Dokumentetwas hinzugefgt wird. Weitere Benutzer knnen die gesamte Anwendung in die CouchDB-Installation auf ihrem Rechner herunterladen. Wenn eine Internetverbindung besteht, werdenUpdates an den Daten automatisch zum Server repliziert, und von ihm an weitere Benutzerweitergegeben, die gerade online sind. Die Anwendung benachrichtigt den Benutzer, sobaldnderungen vorliegen. Er kann sich diese dann durch ein Neuladen der Seite anzeigen lassen.Die zentrale Aufgabe wird der Umgang mit Bearbeitungskonikten in den Daten sein, die durch. Beschreibung des gewhlten Lsungsansatzes das gleichzeitige Bearbeiten entstehen knnen. Gerade wenn ein Benutzer lngere Zeit oine istund dann repliziert, mssen durch Andere vernderte oder neu dazugekommene Zeilen eingefgtoder aktualisiert werden. CouchDB kann von sich aus auf aufgetretene Konikte hinweisen. DieEntscheidung, wie diese Konikte angezeigt und/oder automatisch gelst werden knnen, mussaber beim Design der Anwendung getroen werden. Da der begrenzte Bearbeitungszeitraum diesnicht zulsst, werden nicht alle mglicherweise auretenden Konikte bercksichtigt. Stattdessenwerden einige Koniktarten exemplarisch untersucht.Des Weiteren werden Deployment und Skalierungsmglichkeiten mit dem Clustering Frame-work CouchDB-Lounge und Amazon Elastic Compute Cloud (Amazon EC) untersucht. DieAnwendung wird prototypisch deployt, Mglichkeiten zur Umsetzung einer hohen Verfgbarkeitdes Servers werden beschrieben.

4CouchDB - eine Datenbank frVerteilte SystemeNachdem der gewhlte Lsungsansatz im vorherigen Kapitel begrndet und kurz skizziert wurde,sollen in diesem und im nchsten Teil die fr die Umsetzung der Aufgabenstellung verwendetenTechnologien und Konzepte vorgestellt werden.Im Mittelpunkt des Kapitels steht die ausfhrliche Darstellung der verwendeten DatenbankCouchDB. Apache CouchDB Cluster of unreliable commodity hardware Data Base) ist ein doku-mentenorientiertes Datenbanksystem[Apac]. CouchDB wird seitals Open-Source Projektentwickelt und ist seit Novemberein ozielles Projekt der Apache Soware Foundation[Apad]. CouchDB wurde ursprnglich in C++ geschrieben, wird aber seitgrtenteils inder Programmiersprache Erlang [Eri] entwickelt. Erlang wurde Ende der er Jahre des letztenJahrhunderts fr Echtzeitsysteme wie Telefonanlagen entworfen und zeichnet sich infolgedessendurch hohe Fehlertoleranz, Parallelitt und Stabilitt aus [Len]. Das Erlang/OTP-System (THeOpen Telecom Platform) umfasst neben der Programmiersprache Erlang auch Bibliotheken unddas Laufzeitsystem.Im ersten Teil dieses Kapitels werden die theoretischen Grundprinzipien von CouchDB erlutert.Der zweite Teil ist der Beschreibung der Datenbank aus der Sicht der Anwendungsentwickleringewidmet.4.1Theoretische EinordnungUm die Motivation fr die Entwicklung von CouchDB zu verstehen, wird zunchst kurz aufdie jngere Geschichte der Datenbanksysteme eingegangen und CouchDB im Hinblick auf dieDrei-Schema-Architektur (s. Abschnitt ..) eingeordnet. Danach werden das CAP-eorem undder Umgang von CouchDB mit nebenlugen Transaktionen vorgestellt sowie die RESTfulnessder HTTP-Schnittstelle untersucht. Des Weiteren wird der Unterschied im Ansatz von CouchDBim Vergleich zu traditionellen relationalen Datenbanken dargestellt. Dabei werden die einzelnenAspekte von Aufbau, Eigenschaen und Funktionen angerissen, die dann im weiteren Verlaufdieses Kapitels ausfhrlich beschrieben werden.. eoretische Einordnung 4.1.1Einordnung der Datenbankarchitektur entwarf das Standards Planning and Requirements Committee SPARC) des American ^ationalStandards Institute A^SI) ein Modell, das Anforderungen an den Aufbau eines Datenbanksys-tems beschreibt [H]). Dieses Modell wird A^SI-SPARC-Architektur oder auch Drei-Schema-Architektur genannt.Fr die Benutzer einer Datenbank sollten nderungen in den unteren Ebenen, also von Hardware,interner Speicherstruktur oder logischer Struktur, keine Auswirkungen haben [Cod, S. ]. Isteine Datenbank nach der Drei-Schema-Architektur aufgebaut, wird die Sicht der Benutzer aufdie Datenbank von der technischen Umsetzung getrennt. Die interne Datenspeicherung wirdalso transparent fr die Benutzer.Nach [Mat, Kap. .], lassen sich die drei Ebenen des Schemas wie folgt unterteilen:Externe Schemata/Benutzersichten: Teilbereiche der Datenbank sind fr verschiedene Be-nutzergruppen freigegeben. Hier knnen abgeleitete Daten eingetragen werden, ohne dassdie zugehrigen Grunddaten sichtbar gemacht werden mssen.Konzeptionelles Schema: Diese Ebene enthlt die Beschreibung aller Datenstrukturen fr dieDatenbank, also die Datentypen und -verknpfungen. Dabei ist unerheblich, auf welcheWeise die Daten abgelegt werden. Das konzeptionelle Schema ist sehr stark von Datenbank-entwurf und benutztem Datenmodell abhngig.Internes Schema: Hier sind die Einzelheiten der physischen Datenspeicherung festgelegt, alsodie Aueilung der Datenbank auf verschiedene Rechner oder Festplatten, oder Indizes zurBeschleunigung der Zugrie.Diese Architektur kann unabhngig von der Frage angewendet werden, ob das dem Datenbank-system zugrunde liegende Datenbankmodell relational, objektorientiert, netzwerkartig oder aneinem anderen Modell orientiert ist.CouchDB lsst sich ebenfalls dem ANSI-SPARC-Standard gem beschreiben. Den externenSchemata entsprechen dabei die CouchDB-Views. Das konzeptionelle Schema ist hier die Repr-sentation der Dokumente als JSON-Objekte, also die Gesamtansicht der Datenbank. Das interneSchema ist die Art und Weise der Datenspeicherung, die bei CouchDB ber einen B+-BaumB+-Tree) umgesetzt wird. Diese drei Schichten werden in spteren Abschnitten dieses Kapitelsdetailliert beschrieben.. eoretische Einordnung 4.1.2Das CAP-TheoremCAP steht fr Consistency Konsistenz), Availability Verfgbarkeit) und Partition Tolerance Parti-tionstoleranz). Bei der Modellierung von Verteilten Systemen ist der Begri der Partitionstoleranzvon groer Bedeutung [Var, S. ]. Er besagt, dass Subsysteme auch bei physikalischer Tren-nung und Verlust einzelner Nachrichten untereinander autonom weiter funktionieren knnenmssen. Eine Operation auf dem System muss auch dann erfolgreich durchgefhrt werden, wennein Teil der Komponenten nicht erreichbar ist. Ein Verteiltes System muss jedoch noch zweiweitere Anforderungen erfllen: Konsistenz ist gegeben, wenn alle Komponenten zur selben Zeitdie gleichen Daten sehen. Verfgbarkeit bedeutet, dass das System auf jede Anfrage eine Antwortsendet, mit einer denierten und niedrigen Latenz. Die folgende Darstellung, sofern nicht andersangegeben, basiert auf [Gil, S. -] und [And, Kap. ].Professor Brewer von der University of California hat mit dem CAP-eorem die Annahmeformuliert, dass die drei Eigenschaen Konsistenz, Verfgbarkeit und Partitionstoleranz zwar vonWeb Services erwartet werden, es aber in der Realitt nur mglich ist, zwei der drei Ansprchezu erfllen [Bre]. Da Partitionstoleranz bei Verteilten Systemen unabdingbar ist, muss beimEntwurf die Entscheidung zwischen Konsistenz und Verfgbarkeit getroen werden.In traditionellen Relationalen Datenbanksystemen (RDBMS) kann Konsistenz meist vorausgesetztwerden, da diese standardmig die ACID-Kriterien (Atomizitt, Konsistenz, Isolation, Dauerhaf-tigkeit) erfllen. Vollstndige Konsistenz meint in diesem Kontext die Eigenscha, dass auf einenSchreibzugri folgende Lesezugrie sofort auf die aktuellen Daten zugreifen knnen. Dies wirdals One-Copy-Serializability oder auch Strong Consistency bezeichnet [Mos]. In RDBMS wirddies durch Locking-Mechanismen erzwungen (s. Abschnitt ..). In einem Verteilten System, indem Daten auf mehr als einem Rechner verteilt sind, gestaltet sich die Umsetzung von Konsistenzschwieriger. Verschiedene in den letzten Jahren entwickelte nichtrelationale Datenspeicher wie et-wa Bigtable [Cha], Hypertable [Hyp], HBase [Apai], MongoDB [g] und MemcacheDB[Mem] entscheiden sich trotzdem fr die absolute Konsistenz und gegen eine Optimierungder Verfgbarkeit.Andere Projekte wie Cassandra [Apaa], Dynamo [Vog], Project Voldemort [Pro] undCouchDBlegen ihre Schwerpunkte stattdessen auf Verfgbarkeit. Dabei greifen sie auf unterschiedlicheStrategien zurck, wie Konsistenz trotzdem umgesetzt werden kann. Durch einen sog. ConsensusAlgorithm wie Paxos [Lam] kann garantiert werden, dass Komponenten auch dann zur gleichenLsung fr einen Konikt kommen, wenn keine Verbindung zwischen ihnen besteht [Pea].Ein anderer Ansatz ist der Einsatz von Time-Clocks, mit denen eine Sortierung von Daten inVerteilten Systemen umgesetzt werden kann [Lam].Die Strategie von CouchDB unterscheidet sich von den meisten anderen, weil sie neben Ver-fgbarkeit und Partitionstoleranz Eventual Consistency vorsieht. Diese besagt, dass in einem. eoretische Einordnung beschrnkten Zeitfenster zwischen Schreib- und Lesezugri auf ein DatumInkonsistenzen (Wider-sprche) aureten knnen. Innerhalb dieses Zeitraums werden womglich noch die alten Datenausgegeben, danach jedoch spiegeln alle Lesezugrie das Resultat des Schreibzugris wieder. Beiauretenden Fehlern oder hoher Latenz knnen Datenstze also zeitweise inkonsistent erscheinen,die Konsistenz der Daten ist nur schlussendlich gegeben:e storage systemguarantees that if no newupdates are made to the object, eventuallyall accesses will return the last updated value. [Vog]Eventual Consistency ist nicht fr alle Bereiche ein praktikables Konzept. Wenn Benutzereingabenstark aufeinander aufbauen, also die Eingaben voneinander abhngen und die Benutzer zeitweiseauf veralteten Daten arbeiten, knnen sich Fehler kumulativ fortpanzen und die Konsistenzdes Gesamtsystems ist kompromittiert (bspw. im Finanzsektor). Mit CouchDB knnen daherebenfalls Systeme mit Strong Consistency umgesetzt werden. Bei vielen Anwendungen jedochist es von grerer Bedeutung, dass ein Update jederzeit erfolgreich durchgefhrt werden kann,ohne dass die Datenbank blockiert ist (bspw. bei einem Social ^etwork oder beim vorliegendenAnwendungsfall).4.1.3Transaktionen und NebenlufigkeitJedes Datenbanksystem, das fr mehrere Benutzer ausgelegt ist, muss sich mit Fragen der Neben-lugkeit beschigen. Beantwortet werden muss die Frage was passiert, wenn zwei Benutzergleichzeitig versuchen, denselben Wert zu verndern. Gleichzeitig meint hier nicht den exaktselben Zeitpunkt. Eine Operation, die Lesen, ndern und Zurckspeichern eines Datums umfasstund die eine gewisse Zeit dauert, kann ein Problem mit Nebenlugkeit verursachen, wenn einanderer Benutzer eine ebensolche Operation innerhalb dieser Zeitspanne beginnt und dabei denvom ersten Benutzer zwischenzeitlich genderten Wert berschreibt. Die Aufgabe der Datenbankist es, eine solche Operation serialisierbar zu machen: Die beiden beschriebenen Operationensollen dasselbe Ergebnis haben, wie wenn sie nacheinander stattgefunden htten [Var, S. ].Auch wenn es hier um sehr kurze Intervalle geht und Koniktflle in der Praxis unwahrscheinlichscheinen, mssen diese von vornherein in Design und Architektur einbezogen werden [Vog].Bei dem von RDBMS hauptschlich benutzten Locking belegt eine Operation die Ressourcen,die sie ndern mchte, mit einer Sperre. Andere Operationen mssen auf die Aufhebung dieserSperre warten, dann haben sie exklusiven Zugri auf die Daten. Locking ist fr nichtverteilteDatenbanksysteme eine Herangehensweise mit guter Performance [Var, S. ]. Operationenmssennicht warten, nur weil sie nebenlug sind. Andererseits ist Locking voneinigemOverheadbegleitet und schwer umzusetzen, wenn die Teilnehmer der Transaktion verteilt sind. Es existierenProtokolle, die auch in Verteilten Systemen Sperren setzen und ausen knnen [Ber], diesesind allerdings langsam und fr die umzusetzende Anwendung unpraktikabel.. eoretische Einordnung CouchDB verwendet daher zur Kontrolle von Nebenlugkeit eine Umsetzung von OptimisticConcurrency, die sogenannte Multi-Version Concurrency Control MVCC):MVCC takes snapshots of the contents of the database, and only these snapshots arevisible to a transaction. Once the transaction is complete, the modications that weredone are applied to the newest copy of the relation and the snapshot is discarded.is means that in any given time multiple dierent versions of the same data exists.[Par, Kap. .]MVCC bringt Vorteile bei Verfgbarkeit und Performance, dafr sehen Benutzer teilweise in-konsistente Daten. Es gibt mehrere Wege, diesen Mechanismus umzusetzen. Entweder knnenmit Zeitstempeln oder Vektoruhren die Modikationszeiten von Transaktionen und dadurchdie Gltigkeit eines Updates bestimmt werden. Das Update wird dann entweder zugelassen oderzurckgewiesen. In [Lam] ist dies nher beschrieben. Bei CouchDB werden den Objekten keineVektoren zugewiesen, sondern eine UUID und eine Revisionsnummer. Auerdem verwendetCouchDB das Copy-On-Vrite-Verfahren, bei dem zwei Prozesse nie auf einen Eintrag zugreifen,sondern ihn hintereinander in ein Log schreiben. Felix Hupfeld beschreibt in [Hup, Kap. .]einen Log-based Storage Mechanismus, siehe auch [Joh]:e basic organization of a log structured storage system is, as the name implies, alog - that is, an append-only sequence of data entries. Whenever you have new datato write, instead of nding a location for it on disk, you simply append it to the endof the log.Genau dieser Mechanismus wird in CouchDB angewendet, wenn die Versionen von Dokumentenin Revisionen oder auch die Daten im B+-Baum gespeichert werden. Dies wird in Abschnitt ..genauer erklrt.Der Nachteil von MVCC ist, dass zustzliche Schichten von Komplexitt in der Anwendungslo-gik bearbeitet werden mssen, die ein RDBMS still behandeln wrde. CouchDB bietet hierfrMglichkeiten, die in Abschnitt .. erklrt werden. In [Var, S. ] wird dies jedoch als Vorteildiskutiert: Mit RDBMS werden Anwendungen so entworfen, dass bei steigendem Durchsatzleicht Bottlenecks (Engpsse) entstehen, die dann nicht mehr beseitigt werden knnen. MVCCuntersttzt die Entwickler darin, von Anfang an mgliche Koniktquellen sauber zu behandeln.Dadurch wird ein Zuwachs der Zugriszahlen die Performance der Anwendung weniger wahr-scheinlich beeintrchtigen. Auch unter hoher Last kann die Rechenleistung des Servers vollausgelastet werden, ohne dass auf gesperrte Ressourcen gewartet werden muss, Requests werdenparallel ausgefhrt.. eoretische Einordnung 4.1.4ReplikationAllgemein werden mithilfe von Replikation Daten zwischen Komponenten eines Verteilten Sys-tems synchronisiert. Bei CouchDB bedeutet dies, dass der Inhalt einer Datenbank in eine anderebertragen wird; Dokumente, die in beiden Datenbanken existieren, werden auf denselben Standgebracht. Replikation lsst sich anhand mehrerer Dimensionen einteilen:4.1.4.1Conservative oder Optimistic ReplicationDie vielleicht wichtigste Designentscheidung, die bei dem Konzept Replikation getroen werdenmuss, ist die Frage nach dem Umgang mit nebenlugen Updates: Wie soll sich das Systemverhalten, wenn verschiedene Repliken dasselbe Datum gleichzeitig aktualisieren wollen? Aufdiese Frage wurde bereits in Abschnitt .. nher eingangen. [Guy, Kap. ] nennt zwei Her-angehensweisen: Bei Conservative oder nach [Sai] Pessimistic Replication muss die Konsistenzvor jedem Update berpr werden. Ein Update wird abgelehnt, wenn es nebenlug stattndet.Fr den vorliegenden Anwendungsfall ist diese Strategie nicht umsetzbar, da die Repliken nichtdauerha verbunden sind. Stattdessen setzt CouchDB eine Optimistic Replication um [Sai, S.].Bei Optimistic Replication werden nderungen an replizierten Datensets akzeptiert, ohne dass dieRepliken sich im gleichen Moment darber abstimmen mssen oder ein Locking-Mechanismuseingesetzt wird. Die dadurch entstehenden Konikte an den replizierten Daten zu bearbeitenist Sache des Systems. CouchDB untersttzt dies durch automatische Konikterkennung und-markierung, dies wird in Abschnitt .. beschrieben.4.1.4.2Client-Server- oder Peer-to-Peer-ModellNach [Guy, Kap. ] wird bei Replikation nach dem Client-Server-Modell ein Update zuersteinem Server mitgeteilt, der es dann an alle Clients ausliefert. Das System wird dadurch simpler.Allerdings ist das System an einen nie ausfallenden Server gebunden. Replikation nach demPeer-to-Peer-Modell erlaubt es den Repliken, sich gegenseitig ihre Updates mitzuteilen. Dadurchknnen Updates zum einen schneller verbreitet werden: Sobald Konnektivitt vorhanden ist, egalzwischen welchen Komponenten, kann diese genutzt werden. Eine CouchDB-Installation kannmit jeder anderen CouchDB-Instanz in beide Richtungen Master-Master-Replikation betreibenund ist daher fr beide Modelle geeignet. Welche Strategie umgesetzt werden soll, hngt vomkonkreten Anwendungsfall ab.. eoretische Einordnung 4.1.4.3BenachrichtigungstrategienBei den Benachrichtigungstrategien [Guy, Kap. ] wird zwischen Immediate Propagation undPeriodic Reconsiliation unterschieden. Bei Immediate Propagation werden die anderen Repli-ken sofort nach einem Update benachrichtigt. Bei Periodic Reconsiliation werden die Replikenregelmig, zu einer passenden Zeit, ber stattgefundene Updates benachrichtigt. CouchDBuntersttzt beide Benachrichtigungstrategien. Da das hier zu erstellende System einen Betriebauch ohne Netzverbindung erlaubt, muss es eine Form von Periodic Reconsiliation untersttzen,da Immediate Propagation fehlschlagen wird, wenn Knoten oine sind.4.1.4.4Eager oder Lazy ReplicationWeiterhin nimmt Jim Gray in [Gra, Kap. ] eine Einteilung in Eager Replication und LazyReplication vor. Bei ersterer werden alle Repliken immer sofort aktualisiert, sie mssen also immerverbunden sein. Dies ist fr den in dieser Arbeit behandelten Anwendungsfall nicht praktikabel:In Systemen, die ber Weitverkehrsnetze kommunizieren oder mobile Endgerteeinschlieen, mu das Replikationssystem mit groen Kommunikationslatenzenumgehen knnen. Deshalb werden in solchen Systemen in der Regel nur asynchroneReplikationsalgorithmen [...] eingesetzt. [Hup, S. IV]Die Replikation von CouchDB ist demnach lazy - Updates werden asynchron verbreitet. Durchden Replikationsalgorithmus von CouchDB kann eine CouchDB-Instanz die nderungen eineranderen dann anfordern, wenn zwischen beiden eine Verbindung besteht.4.1.5HTTP-SchnittstelleIn [KT] wird fr dezentrale und unabhngige Verteilte Systeme der Architekturstil RESTRepresentational State Transfer) empfohlen. REST-konform oder RESTful ist eine Schnittstelle,mit der ber HTTP [Fie] Daten bertragen werden knnen, wenn jede Ressource mit einereigenen URL angesprochen werden kann [Fie]. Weitere Vorgaben sind die Zustandslosigkeit desProtokolls, wohldenierte Operationen, und die Mglichkeit, unterschiedliche Reprsentationeneiner Ressource anzufordern.Nicht alle APIs Programmierschnittstellen), die RESTful genannt werden, die also angeblichdem REST-Architekturstil entsprechen, sind zurecht so eingeordnet. In der von NORD SowareConsulting vorgenommenen Klassizierung von HTTP-basierten APIs [NOR] wird zwischenverschiedenen Stufen von RESTfulness unterschieden. Die meisten APIs fallen demnach in dieKategorien HTTP-based Type I, HTTP-based Type II oder REST. APIS, die in die ersten. eoretische Einordnung beiden Kategorien eingeordnet sind, verletzen eine der REST-Einschrnkungen, da Client undServer durch das Schnittstellendesign fest aneinander gekoppelt sind.Dies tri auch auf die API von CouchDB zu, obwohl diese z. B. in [Apab] als RESTful be-zeichnet wird. Nach [NOR] muss eine RESTful API keine dierenzierte Dokumentation ent-halten, stattdessen wrde eine Aufzhlung der verfgbaren Medientypen und Felder gengen.Die CouchDB-API kann nach dieser Studie auch nicht in die Kategorie HTTP-based Type IIeingeordnet werden, da ein generischer Medientyp verwendet wird, der die Ressourcen nichtselbsterklrend macht. Da die API allerdings korrekt bezeichnete Methodennamen in den URIsverwendet, kann sie als HTTP-based Type I bezeichnet werden.In [And, Kap. ] wird die eingeschrnkte RESTfulness von manchen Teilen der API besttigt.Beispielsweise hnelt die API fr die Replikation traditionellen Remote Procedure Calls. Eineausschlielich lose Kopplung, wie es die REST-Architektur vorsieht, ist bei einer Datenbank-API jedoch nicht unbedingt ntig [NOR]. Trotzdem kann die API von CouchDB mithilfeder in Abschnitt .. erwhnten show- und list-Funktionen auch HTTP-based Type II- undREST-konform gemacht machen.4.1.6Abgrenzung zu relationalen DatenbanksystemenDas relationale Datenmodell wurde Anfang der er Jahre von Edgar Codd [Cod] erstmals wis-senschalich beschrieben. IBMund Oracle implementierten Ende der er Jahre die ersten daraufbasierenden Datenbanksysteme. Datenbanken liefen zu dieser Zeit noch auf einzelnen, nichtvernetzten Grorechnern. Diese mussten regelmig grere Operationen ausfhren, die vielDatenbanklogik erforderten [Leh]. Bei jeder dieser Operationen datenbankweit die Konsistenzzu berprfen stellte kein Problem dar, da die Operationen einfach nacheinander abgearbeitetwurden [And, Kap. ]. Daten wurden durch physische Backups gegen Verlust abgesichert,Replikation kam erst spter auf. RDBMS sind fr eine solche Nutzungsweise optimiert.4.1.6.1Replikation und KonfliktbehandlungAb Anfang der er Jahre setzten sich relationale Datenbanksysteme auch in anderen Anwen-dungsbereichen immer mehr durch. Die Einsatzszenarien sehen allerdings heute o anders ausals damals: Im Bereich der Internetanwendungen mssen Server meist eine Vielzahl einzelnerAbfragen gleichzeitig abarbeiten. Das Verhltnis zwischen Komplexitt der Abfragen und Anzahlder Zugrie hat sich stark verndert. Hinzu kommt die bei Verteilten Systemen unweigerlichaufkommende Frage nach der Umsetzung von Replikation und Koniktlsungsstrategien.Trotz dieser Nachteile wird zur Implementierung von Webanwendungen heute die relationaleDatenbank MySQL [Cora] mit Abstand am hugsten eingesetzt [Alf, S. ]. Replikation bei. eoretische Einordnung MySQL ist nach dem Prinzip des Log Replay aufgebaut [Corc]. In einem Master-Master-Setuptreten jedoch regelmig nebenluge, sich widersprechende Schreibzugrie auf. Wenn die Da-tenbank Inkonsistenzen nicht deniert behandelt, mssen die Konikte mit selbst zu erstellendenDatenbankfunktionen oder Anwendungslogik gelst werden [Max]. Die Replikationsstrategievon CouchDB dagegen ist inkrementell, auch bei Verbindungsabbruch whrend des Replikati-onsvorgangs bleiben die Daten stets in einem konstanten Zustand. Dies wird in Abschnitt ..erlutert. Die Fhigkeit von CouchDB, mit nebenlugen Updates und entstandenen Koniktenumzugehen, wird in Abschnitt .. dargelegt, und ist in Abschnitt .. durch die Darstellungder Implementierung von CouchDB erklrt.4.1.6.2Keine MiddlewareCouchDB wurde entwickelt, um den vernderten Ansprchen und heutigen Anforderungen aneine Datenbank fr Webanwendungen gerecht zu werden - [it is] built of the web [Kap].Die mit CouchDB umgesetzten Konzepte sind nicht neu. In [Ass, S. ] wurde beschrieben,wie sich statische Webanwendungen der ersten Generation zum bisher verbreiteten Modellweiterentwickelten: Datenbank- und Anwendungsentwicklung wird vllig getrennt vorgenommen,zur Kommunikation mit den Anwendern werden Interfaces wie CGI [WC] eingesetzt. DerEinsatz von Middleware ist dabei ntig, um ...... ausgehend von den vorhandenen Schnittstellen gngiger Web-Server und Daten-banksysteme den bergang zwischen den Systemen fr einen Entwickler so einfachund transparent wie mglich [zu] gestalten. [Ass, S. ]Fr die Zukunder sog. Internetdatenbankenwurde in[Ass, S. ] vorausgesagt, dass diese nichtnur Zugri auf die Daten ermglichen, sondern auch die Interaktion mit demAnwendungssystemeinbeziehen mssen. Bei einer mit CouchDB erstellten Anwendung kann diese Middlewareentfallen. Stattdessen kann ein Anwendungsprogrammdirekt mit der Datenbank kommunizieren.Dies geschieht ber eine HTTP-API, die in Abschnitt .. vorgestellt wird. Auf diese Weiseknnen stabile Anwendungen mit vergleichsweise geringem Aufwand umgesetzt werden.4.1.6.3SchemalosigkeitViele der Probleme beimEntwurf einer modernen Webanwendung (vgl. Kapitelund .) beinhal-ten unvorhersehbares Verhalten der Benutzer und Input von einer groen Menge von Menschenmit einer groen Menge von Daten [Var, S. ]. Dies umfasst beispielsweise die Suche imInternet, das Erstellen von Graphen in Social Networks, Auswertung von Kaufgewohnheiten etc.Diese Aufgaben bringen o unbersichtliche Datenstrukturen mit sich, die vorher nur schwer. eoretische Einordnung genau deniert und modelliert werden knnen. Laut [Bar] sind solche Daten fr die Abbildungals relationale Datenstrukturen nicht gut geeignet:RDBMSs are designed to model very highly and statically structured data which hasbeen modeled with mathematical precision. Data and designs that do not meet thesecriteria, such as data designed for direct human consumption, lose the advantagesof the relational model, and result in poorer maintainability than with less stringentmodels.Eine dokumentenorienterte Datenbank besteht aus einer Reihe von unabhngigen Dokumenten;alle Daten fr ein Dokument sind in diesem selbst enthalten:In fact, there are no tables, rows, columns or relationships in a document-orienteddatabase at all. is means that they are schema-free; no strict schema needs to bedened in advance of actually using the database. If a document needs to add a neweld, it can simply include that eld, without adversely aecting other documents inthe database. [Len]Die Schemalosigkeit von CouchDB ist fr die Umsetzung des Prototypen zwar relevant, fr dieKonzeption aber nicht zentral. Dies kann sich aber in spteren Versionen der Anwendung andersdarstellen, wenn der Gliederungseditor mehrere Spalten mit unterschiedlichen Datentypen undMedien enthalten wird (vgl. Kapitel ).4.1.6.4Unique IdentifiersIn relationalen Datenbanken werden Zeilen einer Tabelle blicherweise mit einemPrimrschlsselidentiziert, der o durch eine auto-increment-Funktion bestimmt wird [Len]. Eindeutigsind diese Schlssel jedoch nur fr die Datenbank und die Tabelle, in der sie erzeugt wurden.Wenn auf zwei unterschiedlichen Datenbanken, die spter synchronisiert werden, ein Eintraghinzugefgt wird, wird hier ein Konikt aureten [Corb]. In CouchDB wird jedem Dokumentbei der Erstellung eine UUID Universally Unique Identifer) zugewiesen. Auf diese Weise wirdein Konikt statistisch nahezu unmglich. Ein berblick ber Dokumente in CouchDB ndetsich in Abschnitt ...4.1.6.5Views statt JoinsEiner der wichtigsten Unterschiede zwischen dokumentenorienterten und relationalen Daten-banken ist die Art und Weise, wie Abfragen an die Datenbank gestellt werden. Da CouchDBkeine Primr- und Fremdschlssel kennt, knnen Daten nicht direkt verknp und ber Joinsabgerufen werden. Stattdessen kann mithilfe von Views eine Beziehung zwischen beliebigen.Beschreibung Dokumenten der Datenbank hergestellt werden, ohne dass diese Beziehung in der Datenbankvordeniert sein muss. Views werden in Abschnitt .. erklrt. O werden Joins auch schondurch die Modellierung der Daten in Dokumenten berssig gemacht.4.2BeschreibungIn diesem Abschnitt werden die Features und einige Implementierungsdetails von CouchDBvorgestellt. In einem CouchDB-Datenbanksystem knnen beliebig viele Datenbanken angelegtwerden, in denen Dokumente enthalten sind. Die Administrationsoberche Futon kann in einemBrowser unter der URL http://localhost:5984/_utils besucht werden. In Abbildung A.ndet sich ein Screenshot von einer CouchDB-Instanz und den darin enthaltenen Datenbanken,Abbildung A. zeigt den Inhalt einer Datenbank. Operationen auf der Datenbank werden entwederber diese Oberche oder programmatisch vorgenommen.Mit CouchDB lsst sich eine dierenzierte Zugriskontrolle mit Benutzerverwaltung und Rech-tevergabe umsetzen. Dies wird aus Platzgrnden in dieser Arbeit nicht behandelt. Ebenfallswerden in dieser Darstellung manche Datenbank-Funktionen sowie einige Teile der HTTP-APIausgespart. Die Informationen in den folgenden Abschnitten, soweit nicht anders angegeben,knnen in [And], [Apab] und [Len] nachgelesen werden.4.2.1Dokumente und KonfliktbehandlungIn CouchDB-Dokumenten werden die eigentlichen Datenstze als JSON-Objekte (siehe auchAbschnitt ...) gespeichert. Ein Dokument kann eine beliebige Anzahl von beliebig groenFeldern haben, die einen innerhalb des Dokuments eindeutigen Namen tragen mssen. BinreAttachments knnen ebenfalls an ein Dokument angehngt werden. Ein Dokument ist mit einereindeutigen ID (_id) versehen, die beim Erstellen angegeben oder als UUID zu mathematischnahezuProzent eindeutig erzeugt wird. Abbildung A. zeigt beispielha ein Dokument.Als weiteres Metadatum enthlt das Dokument eine Revisionsnummer, genannt _rev. Werdennderungen an einem Dokument vorgenommen, wird dieses nicht verndert; stattdessen wirdeine neue Version des gesamten Dokuments erzeugt, das bis auf die vorgenommenen nderungenund die neue Revisionsnummer identisch ist. Auf diese Weise beinhaltet die Datenbank eine kom-plette Versionsgeschichte jedes Dokuments. Mit dieser Art der Datenspeicherung implementiertCouchDB ein lockless and optimistic document update model (s. Abschnitt ..).Ein Dokument wird nach dem folgenden Muster gendert: Das Dokument wird vom Clientgeladen, verndert und mit Angabe von ID und Revision in der Datenbank gespeichert. Wenn einanderer Client inzwischen seine nderungen amselben Dokument gespeichert hat, wird der erste.Beschreibung Client beim Speichern eine Fehlermeldung bekommen (HTTP Status-Code : conict). Umdiesen aufzulsen, muss die aktuelle Version des Dokuments noch einmal geladen und modiziertwerden, bevor ein neuer Speicherversuch gemacht werden kann. Dieser schlgt entweder komplettfehl oder wird vollstndig durchgefhrt, zu keinem Zeitpunkt werden unvollstndige Dokumentegespeichert.Das Lschen eines Dokuments verlu auf eine hnliche Weise. Vor dem Lschen muss dieaktuellste Version des Dokuments vorliegen. Der eigentliche Lschvorgang besteht darin, demDokument das Feld _deleted=true hinzuzufgen. Gelschte Dokumente werden genau wieltere Versionen aufbewahrt, bis die Datenbank kompaktiert wird.Konikte knnen dennoch aureten, wenn an einem replizierten Datenset unabhngig von-einander Updates vorgenommen wurden. CouchDB verfgt allerdings ber eine automatischeKonikterkennung, wodurch die Koniktbehandlung vereinfacht wird. Die in beiden Kopien gen-derten Dokumente werden hnlich wie in einem Versionskontrollsystem beim Zusammenfhrenautomatisch als koniktha gekennzeichnet. Dafr wird ihnen ein Array namens _conflictshinzugefgt, in dem alle konikthaen Revisionen gespeichert sind. Durch einen deterministi-schen Algorithmus wird eine der Revisionen als die Gewinnerversion gespeichert. Nur diesewird in den Views angezeigt. Die andere Revision wird in der Geschichte des Dokuments gespei-chert, auf sie kann noch zugegrien werden. Es ist Aufgabe der Anwendung bzw. der Benutzer, dieKonikte aufzulsen; dies kann durch Zusammenfhren, Rckgngig machen oder Akzeptierender nderungen geschehen. Auf welcher Replik dies geschieht, ist unerheblich, solange am Endeder gelste Konikt durch Replikation allen Kopien bekannt gemacht wird.4.2.2HTTP-SchnittstelleDie Daten aus einer CouchDB-Datenbank knnen ber eine API abgefragt und geschrieben wer-den. Diese API ist ber die HTTP-Methoden GET, POSTund PUTansprechbar. Die Daten werdenals JSON-Objekte zurckgegeben. Da JSON und HTTP von vielen Sprachen und Bibliotheken un-tersttzt werden, knnen von einer beliebig umgesetzten Anwendung aus Datenbankoperationenauf CouchDB vorgenommen werden.Fr die JavaScript-HTTP-API von CouchDB wurde im Verlauf dieser Arbeit eine Testsuite erstellt,dies wird in Abschnitt .. erlutert.Die CouchDB-API verfgt ber eine Reihe von Funktionen, die sich nach [And, Kap. ] in vierBereiche unterteilen lassen. Fr jeden der Bereiche werden einige Einsatzmglichkeiten und einBeispiel fr die Abfrage mit dem Kommandozeilen-Werkzeug cURL genannt..Beschreibung 4.2.2.1Server-APIWird ein einfacher GET-Request an die URI des CouchDB-Servers gerichtet, sendet dieser die Ver-sionsnummer der CouchDB-Installation: curlhttp://localhost:5984/ liefert das JSON-Objekt{"couchdb":"Welcome","version":"0.11.0b902479"} zurck. Mit anderen Funktionen knnen ei-ne Liste aller Datenbanken abgefragt oder Kongurationseinstellungen vorgenommen werden.Benutzeridentikation wird ebenfalls direkt ber den Server abgewickelt, Benutzer knnen sichgegenber dem Server identizieren oder ausloggen.4.2.2.2Datenbanken-APIMit dem Befehlcurl-XPUThttp://localhost:5984/exampledb kann eine Datenbank erstelltwerden. Im Erfolgsfall wird hier{"ok":true} zurckgegeben. Schlgt das Anlegen fehl, weileine Datenbank mit diesem Namen bereits existiert, erhlt man eine Fehlermeldung. Datenban-ken knnen ebenfalls gelscht, kompaktiert oder es knnen Informationen ber sie abgefragtwerden. Ein neues Dokument kann durch curl-XPOSThttp://localhost:5984/exampledb-d{"foo":"bar"} angelegt werden. CouchDB gibt als Antwort die ID und die Revision desangelegten Dokuments zurck: {"ok":true,"id":"6651b95e15b411dbab3d2a7a7d000452","rev":"1-303d5e305201766b21a42747173681d6"}. Wird statt POST die Methode PUT verwendet, kann dieID des zu erstellenden Dokuments selbst gewhlt werden.4.2.2.3Dokumenten-APIMit einem GET-Request auf die URI des Dokuments (http://localhost:5984/exampledb/6651b95e15b411dbab3d2a7a7d000452) kann das Dokument aus dem obigen Beispiel wieder angefordertwerden. Das Dokument kann durch einen PUT-Request gendert werden. Dabei muss die ID, daskomplette genderte Dokument und die letzte Revision des Dokuments mit angegeben werden.Fehlt die Revision oder ist sie unkorrekt, schlgt das Update fehl.4.2.2.4Replikations-APIMit dem Befehl curl-XPOSThttp://127.0.0.1:5984/_replicate-d{"source":"exampledb","target":"exampledb-replica"} wird Replikation zwischen zwei Datenbanken gestartet. Solleine Replikation in beide Richtungen realisiert werden, wird der Befehl ein zweites mal mitvertauschter Quelle und Ziel aufgerufen. Auf Parameter wird im nchsten Abschnitt nher einge-gangen..Beschreibung 4.2.3ReplikationDamit eine Replik sofort von Updates auf anderen Repliken erfhrt, kann die Replikation mit derOption continuous=true gestartet werden. Dieser Mechanismus wird Continuous Replicati-on genannt. Dadurch wird die HTTP-Verbindung oen gehalten, und jede nderung an einemDokument wird automatisch sofort repliziert. Continuous Replication muss explizit neu gestartetwerden, wenn eine Netzwerkverbindung wieder verfgbar wird. Auch nach einemServer-Neustartwird sie nicht automatisch fortgesetzt.Es werden nur die Daten repliziert, die seit dem letzten Replikationsvorgang gendert wurden.Der Prozess ist also inkrementell. Wenn die Replikation durch Netzwerkprobleme oder pltzlicheAusflle von Knoten fehlschlgt, wird der nchste Replikationsvorgang an der Stelle fortgesetzt,an der der letzte unterbrochen wurde. Replikation kann durch sogenannte Filter-Funktionengeltert werden, so dass nur bestimmte Dokumente repliziert werden.4.2.4Change NotificationsCouchDB-Datenbanken haben eine Sequenznummer, die bei jedem Schreibzugri an die Da-tenbank inkrementiert wird. Gespeichert werden auch die nderungen zwischen zwei Sequenz-nummern. Dadurch knnen Unterschiede zwischen Datenbanken ezient festgestellt werden,wenn Replikation nach einer Pause wieder aufgenommen wird. Diese Unterschiede werdennicht nur intern fr die Replikation benutzt, sie knnen in Form des Changes-Feeds auch frAnwendungslogik benutzt werden.Mit dem Changes-Feed kann die Datenbank auf nderungen berwacht werden. Die Abfragevon http://localhost:5984/exampledb/_changes gibt ein JSON-Objekt zurck, das sowohl dieaktuelle Sequenznummer als auch eine Liste aller nderungen der Datenbank enthlt: {"results":[ {"seq":1,"id":"test","changes":[{"rev":"1-aaa8e2a031bca334f50b48b6682fb486"}]}, {"seq":2,"id":"test2","changes":[{"rev":"1-e18422e6a82d0f2157d74b5dcf457997"}]} ], "last_seq":2}Der Changes-Feed kann mit unterschiedlichen Parametern versehen werden. So knnen mitsince=n nur nderungen seit einer bestimmten Sequenznummer angefordert werden. Mitfeed=continuous kann der Feed, hnlich wie die Replikation, so konguriert werden, dasser nach jeder nderung in der Datenbank einen Eintrag zurckgibt. Die bereits erwhntenFilter-Funktionen ermglichen, nur Dokumente mit bestimmten nderungen zurckzugeben..Beschreibung 4.2.5Anwendungen mit CouchDBIn Dokumenten kann auch Programmcode enthalten sein, der von CouchDB ausgefhrt werdenkann. Solche Dokumente werden Designdokumente genannt. blicherweise ist jeder Anwendung,die von CouchDB ausgeliefert werden soll, ein Designdokument zugeordnet.Ein Designdokument ist nach festen Vorgaben strukturiert. Im Folgenden ndet sich eine Auis-tung der in einem Designdokument typischerweise enthaltenen Dokumente:_id: Enthlt das Prx _design/ und den Namen des Designdokuments bzw. der Anwendung,z. B. _design/doingnotes._rev: Von Replikation und Koniktbehandlung werden Designdokumente behandelt wie nor-male Dokumente, deswegen enthalten sie eine Revisionsnummer._attachments: In diesem Feld enthaltener Programmcode kann clientseitig im Browser ausge-fhrt werden. Hier kann die Anwendungslogik fr eine CouchDB-Applikation enthaltensein._views: Ebenso wie list-, show- und filter-Felder enthlt dieses Feld Funktionen, mitdenen der Inhalt einer Datenbank geltert, strukturiert und/oder modiziert ausgegebenwerden kann. Dieser Code wird serverseitig, also von der Datenbank ausgefhrt.Abbildung A. enthlt einen Screenshot von einem in Futon geneten Designdokument.4.2.6ViewsIn relationalen Datenbanken werden die Beziehungen zwischen Daten ausgedrckt, in dem glei-che Daten in einer Tabelle gespeichert werden, und zusammengehrige Daten mit Primr- undFremdschlsseln verknp sind. Aufgrund dieser Beziehungen knnen dann durch dynamischeAbfragen aggregierte Datensets angefordert werden. CouchDB whlt hier einen gegenteiligenAnsatz. Auf Datenbankebene sind keine Verknpfungen realisiert. Verbindungen zwischen Doku-menten knnen auch dann noch gezogen werden, wenn die Daten schon vorhanden sind. Dafrwerden die Abfragen dieser Daten und ihre Ergebnisse statisch in der Datenbank gespeichert. Siehaben keine Auswirkungen auf die Dokumente in der Datenbank. Diese Abfragen werden alsIndizes gespeichert, die Views genannt werden.Views werden in Designdokumenten abgelegt und beinhalten JavaScript-Funktionen, die Abfra-gen mithilfe von MapReduce [Yan] formulieren. Eine Map-Funktion bekommt nacheinanderalle Dokumente als Argument bergeben und bestimmt anhand dessen, ob es oder einzelneFelder durch den View verfgbar gemacht werden sollen. Wenn eine View eine Reduce-Funktionenthlt, wird diese zum Aggregieren der Ergebnisse verwendet. Listing . zeigt eine View, mit.Beschreibung der alle Dokumente auf das Feld kind mit dem Wert Outline berpr werden. Wenn einDokument solch ein Feld enthlt, wird dem resultierenden JSON-Objekt ein Eintrag hinzugefgt,der als Schlssel die Dokumenten-ID und als Wert das Dokument enthlt. function(doc){ if(doc.kind==Outline){ emit(doc._id,doc); } }Listing .: View: Map-Funktion zum Ausgeben aller OutlinesWird diese View unter dem Namenoutlines in einem Designdokumentdesignnamegespeichert, kann sie mithilfe eines HTTP GET-Requests auf die URI http://localhost:5984/exampledb/_design/designname/outlines abgerufen werden. Views werden bei ih-rem ersten Abrufen erstellt und dann mitsamt ihrem Index, wie auch normale Dokumente, ineinem B+-Baum gespeichert. Werden weitere Dokumente hinzugefgt, die im Ergebnis der Viewenthalten sind, werden sie automatisch zur gespeicherten View hinzugefgt, wenn diese dasnchste mal abgerufen wird.Der Zugri auf eine View kann ber Schlssel Keys) und Schlsselbereiche Key Ranges) einge-grenzt werden. Die Abfrage vonhttp://localhost:5984/exampledb/design/designname/outlines?key="5" gibt nur das Outline mit der ID 5 zurck. Mit http://localhost:5984/exampledb/design/designname/outlines?startkey="2"&endkey="7" knnen alle Out-lines angefordert werden, deren ID zwischen 2 und 7 liegt. Es existieren eine Vielzahl weitererParameter, mit denen die Abfrage weiter przisiert werden kann. Die Schlssel bzw. Schlsselberei-che werden direkt auf den Datenbankengine gemappt, dadurch sind die Zugrie sehr performant.Dies wird im nchsten Abschnitt erklrt.4.2.7ImplementierungEine CouchDB-Datenbank ist immer in einem konsistenten Zustand, auch wenn der CouchDB-Server mitten in einem Speichervorgang abstrzen sollte. Dies wird in diesem Abschnitt mit einerCharakterisierung des verwendeten Datenbankengines begrndet. Die Darstellung sttzt sich auf[Ho,] und [And, Kap. G].Die eingesetzte Datenstruktur ist ein B+-Baum, eine Variation des B-Baums. Ein B+-Baum ist aufdie Speicherung von groen Datenmengen und schneller Abfrage dieser ausgerichtet. Auch frextremely large datasets wird eine Zugriszeit von unterMillisekunden garantiert [Bay].B+-Bume wachsen in die Breite; auch mit mehreren Millionen Eintrgen haben sie gewhnlicheine einstellige Tiefe. Dies ist vorteilha, da CouchDB als Speichermedium Festplatten verwendet,wo jeder Traversierungsschritt ein zeitintensiver Vorgang ist..Beschreibung Ein B+-Baum ist ein vollstndig balancierter Suchbaum, in dem Daten nach Schlsseln sortiertgespeichert werden [Bay]. In einem Knoten knnen mehrere Schlsselwerte enthalten sein.Jeder Knoten verweist auf mehrere Kindknoten. Bei CouchDB sind die eigentlichen Daten aus-schlielich in den Blttern gespeichert. In den B+-Bumen werden sowohl die Dokumente alsauch die Views indiziert. Dabei wird fr jede Datenbank und jede View ein eigener B+-Baumangelegt.Pro Datenbank ist nur ein gleichzeitiger Schreibzugri erlaubt, die Schreibzugrie werden seriali-siert. Lesezugrie knnen nebenlug zueinander und zu Schreibzugrien stattnden. Daten-banken und Views knnen demnach gleichzeitig abgefragt und erneuert werden. Da CouchDBseine Daten im Append-Only-Modus ablegt, enthlt die Datenbankdatei eine komplette Versions-geschichte aller Dokumente. MVCC kann dadurch eektiv umgesetzt werden.Wie in Abschnitt .. beschrieben, wird beim ndern eines Dokuments dieses nicht berschrie-ben, sondern eine neue Revision erstellt. Danach werden die Knoten des B+-Baums nacheinanderaktualisiert, bis sie alle auf den Speicherort der neusten Version des Dokuments verweisen. Diesgeschieht ausgehend vom Blatt des Baums, der das Dokument enthlt, bis hoch zum Wurzel-knoten. Dieser wird also am Ende jedes Schreibzugris modiziert. Wenn ein Lesezugri nochdie Referenz auf den alten Wurzelknoten hat, verweist dieser zu einer veralteten, aber konsisten-ten Momentaufnahme der Datenbank. Alte Revisionen der Dokumente werden erst bei einervom Benutzer eingeleiteten Compaction Verdichtung) gelscht. Deshalb knnen Lesezugrie ihrErgebnis fertig abfragen, auch wenn gleichzeitig eine neue Version des Dokuments erstellt wird.Wenn ein B+-Baumauf die Festplatte geschrieben wird, werden die nderungen stets an das Endeder Datei angehngt. Dadurch wird die Zugriszeit beim Schreiben auf die Festplatte minimiert.Auerdem wird verhindert, dass unvorhergesehene Beendigung des Prozesses oder Stromausflleden Index korrumpieren:If a crash occurs while updating a view index, the incomplete index updates aresimply lost and rebuilt incrementally from its previously committed state. [Apab]

5Technische GrundlagenIn diesem Kapitel werden zunchst die einzelnen Webtechnologien dargestellt, die in die An-wendung eingeossen sind. Anschlieend wird auf die Hintergrnde von Cloud Computingeingegangen, das zum Deployment der Anwendung verwendet wurde. Der letzte Abschnitt stelltdie Methoden und Mittel dar, die zur Entwicklung der Anwendung untersttzend beigetragenhaben.5.1WebtechnologienDie Interaktionsmglichkeiten mit der Oberche der zu erstellenden Anwendung fallen geringaus. Der Einsatz eines aufwndigen ViewFrameworks ist deshalb nicht notwendig; die Umsetzungkann mit den vergleichsweise einfachen Technologien, Frameworks und Programmiersprachenerfolgen, die hier im Einzelnen vorgestellt werden.5.1.1CouchAppDie zu entwickelnde Anwendung wird als sogenannte CouchApp [Che] umgesetzt. Das ProjektCouchApp stellt eine Reihe von untersttzenden Komponenten zur Verfgung, die die Entwick-lung einer Standalone-Anwendung mit CouchDB erleichtern. Das Design sieht vor, dass jederBenutzer eine eigene CouchDB-Instanz oine auf seinem Endgert installiert hat, in der dieAnwendung lu. Dadurch ist die Verfgbarkeit auch ohne Internetanbindung gegeben.Damien Katz, der Urheber von CouchDB, erklrt in [Kat] CouchApps in folgenden Worten:CouchDB, being an HTTP server, can host applications directly, so you can writeapplications and forward the HTML, CSS, and JavaScript through CouchDB. Whenyou point your browser at it, the browser comes alive and starts the JavaScript. Itbecomes interactive as you query and update the server and everything. When every-thing is served from CouchDB, thats a CouchApp and you can replicate it around,just like the data.Eine CouchApp kann auf dem lokalen Rechner, einem Mobiltelefon, einem lokalen Server oderin der Cloud deployt sein, immer wird sie ber einen Browser angesprochen. Durch Replikationknnen die Daten und auch das Programm immer wieder auf einen Stand gebracht werden.. Webtechnologien Nach der Installation von CouchApp (erklrt in Abschnitt ..) kann das Gerst fr eineneue Beispiel-Applikation von der Kommandozeile mit dem Befehl couchappgenerateexample-couchapp erzeugt werden. Dies generiert ein Verzeichnis example-couchapp, das eine Ver-zeichnisstruktur vorgibt (s. Abb. .). Dieses Verzeichnis entspricht einemCouchDB-Designdokument,wie es in Abschnitt .. beschrieben ist.Abbildung .: Generierte Beispiel-CouchappDas Verzeichnis _attachments enthlt alle JavaScript-, HTML- und CSS-Dateien, die frAnwendungslogik und Darstellung bentigt werden. In der Beispiel-Anwendung ist eine einfacheHTML-Startseite sowie ein Stylesheet vorgegeben. Die Verzeichnisse lists, show, views undfilters enthalten entsprechend die List-, Show- bzw. Filter-Funktionen von CouchDB bzw. dieViews. Imvendor-Verzeichnis werden externe Bibliotheken abgelegt, die fr die Entwicklungbentigt werden.Die Einstellungen fr das Deployment werden in der Datei .couchapprc vorgenommen. Dieseist folgendermaen formatiert: { "env":{ "default":{. Webtechnologien "db":"http://user:password@localhost:5984/example-couchapp-dev" }, "production":{ "db":"http:///user:password@example.com/example-couchapp" } } }Listing .: Couchapp: .couchapprcDabei mssen fr die Entwicklungs- und ggf. Produktionsumgebung Benutzername und Passwortdes CouchDB-Administrators angegeben werden. Diese Information kann weggelassen werden,wenn sie nicht gesetzt sind. Mit dem Befehl couchapppush bzw. couchapppushproduction wirdder Inhalt des CouchApp-Verzeichnisses in die CouchDB-Instanz kopiert.Das URL-Schema einer CouchApp wird in Abschnitt . erlutert. In Abschnitt .. wird erklrt,wie die in der Arbeit erstellte Anwendung mithilfe von CouchApp deployt wird.5.1.2HTML5HTML Hypertext Markup Language) ist das Hypertextformat im World Wide Web. HTML,[Hica] ist eine vom WC entworfene Spezikation, die in Zukun die bisherigen HTML- undXHTML-Standards ersetzen soll. HTML wird mittlerweile von den meistbenutzten Browsernin den aktuellsten Versionen weitgehend untersttzt, mit der Ausnahme des Microso InternetExplorer [Smi]. Diese Einschrnkung verhindert bisher noch die Entwicklung der meistenWebanwendungen, da im Normalfall auf ltere oder nicht standardkonforme Browser Rcksichtgenommen werden muss.Wegen in Abschnitt .. nher ausgefhrten Einschrnkungen ist die Anwendung auf denBrowser Firefox ab der Version . festgelegt (siehe Release Notes [Mozb]). Dies erlaubt es, auchbei zentralen Anwendungseigenschaen auf die Funktionen zuzugreifen, die HTML mit sichbringt. So bietet HTML neben vielen Verbesserungen die Mglichkeit, Custom Data Attributeszu denieren. Diese Technik wird in der Arbeit verwendet und wird deshalb kurz erklrt.Laut Spezikation [Hicb] ist ein Custom Data Attribute ein Attribut ohne Namespace, dessenName mit dem String data- beginnt und nach dem Bindestrich mindestens einen Buchstabenhat, der keine Grobuchstaben enthlt. In Custom Data Attributes knnen eigene private Datenfr die Seite oder die Anwendung gespeichert werden, wenn es keine passenden Attribute oderElemente dafr gibt. Die Attribute sind dafr gedacht, von den eigenen Skripten der Seite benutztzu werden, nicht als entlich nutzbare Metadaten. Jedes HTML-Element kann beliebig vieleCustom Data Attributes haben.. Webtechnologien 5.1.3JavaScriptJavaScript ist eine vielseitige Skriptsprache, deren Assoziation mit dem Webbrowser sie zu einerder populrsten Programmiersprachen der Welt macht [Cro, S. ]. ber das DOM DocumentObject Model) [WC] knnen mi