Download (5Mb) - oops/ - Oldenburger Online-Publikations-Server

106 Umsetzung des Prototyps
Form (z.B. eine Chat-Sitzung) zu einer dauerhaften Form (z.B. die Archivierung einer Konversation)
per “Anfrage” umgewandelt werden sollen.
Des Weiteren wird das nicht-relationale Datenbanksystem “Redis” für die Speicherung und bzw.
Anfrage des aktuellen Online-Zustandes eines Benutzers (z.B. Online oder Offline) eingesetzt. Eine
weitere Entwicklung des “Präsenz” Konzeptes wäre die Speicherung verschiedener Metadaten über
die Präsenz, wie z.B. Ereignisse wie “tippt gerade” (engl. is typing) oder “zuletzt gesehen am .. Zeit”
(engl. last seen at).
Die technische Infrastruktur für die Realisierung des Kommunikationskanals ist das amqp Ruby
Gem, welches nicht nur eine Schnittstelle zum AMQP-Netzwerkprotokoll und zu den dazugehörigen
Broker-Systemen bereitstellt, sondern nutzt auch spezifische Erweiterungen von Brokers (wie z.B.
die RabbitMQ-Erweiterungen) nutzt.
Zusammenfassung
In diesem Abschnitt wurde die Umsetzung des Kommunikationskanals vorgestellt. Zu beachten
ist jedoch die prototypische Gewährleistung eingeschränkter Funktionalitäten. Es wurde nur ein beispielhaftes
Szenario der Übersendung von einfachen Nachrichten (“Instante Nachrichten” oder IM)
zwischen Wohnungseigentümer und -mieter getestet (d.h. nicht evaluiert).
Der Grund für diese Entscheidung ist die ubiquitäre Präsenz und Nutzung anderer Kanäle für die
Kommunikation (z.B. Google Talk / IM-Anbieter, E-Mail oder SMS) von den Benutzern. Andererseits
besteht der Vorteil des Konzeptes zum Kommunikationskanal darin, dass eine sichere Kommunikation
hinsichtlich der Vertraulichkeit (siehe auch 1.5.5) und Teilnehmerauthentizität (siehe auch die
Erklärungen aus Paragraph 7.3.3 und 7.3.5) entstehen kann.
Im folgenden Abschnitt wird ein anderer Teil der Implementierung vorgestellt, welche das Datenmodell
für die Client-Anwendungen anhand einer REST-basierten Schnittstelle zur Verfügung stellt.
7.3.5 REST Implementierung
Ein wesentliches Kriterium, das während der Suche nach einem geeigneten Framework für die Umsetzung
einer REST API gestellt wurde, ist die “Leichtigkeit” der Lösung. Es wurde ein Framework
gesucht, welches die Rack Schnittstelle (siehe auch 5.2.1) umsetzt und ein geeignetes DSL (Domain
Specific Language, eine domänenspezifische Sprache, womit Lösungen für ein bestimmtes Problemfeld
möglichst kompakt definiert werden können) für die Beschreibung der einzelnen Methoden (die
so genannten “Routen”) bereitstellt.
Ein erster Gedanke war das Web Framework namens “Sinatra”: die zur Verfügung gestellte DSL ist
kompakt, jedoch wird Sinatra als ein voll entwickeltes Framework für die Umsetzung Web-basierter
Anwendungen (Web Applications, Kurzform “Webapps”) angesehen und nicht “nur” als ein Framework
für die Definition eines REST API. In dieser Hinsicht wurde die Entscheidung getroffen, eine
nicht unbedingt bekannte 13 aber mächtige Softwarelösung für die Definition von REST APIs namens
“Grape” 14 anzuwenden.
13 Grape hat 1900 Watchers und 162 Forks auf Github, während Sinatra wesentlich populärer ist, mit 4160 Watchers und
615 Forks
14
http://intridea.github.com/grape/