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

7.3 Backend 105
Die Entwicklung der “nicht dauerhaften” Art von Queues ist mehr mit der nicht-relationalen Datenbank
namens Redis verbunden, wie im kommenden Paragraph erläutert wird.
Redis ist ein “Server für Datenstrukturen”, der ein In-Memory Datenspeicherungsmodell für eine
schnelle Anfragebearbeitung verwendet. Im Vergleich zu anderen “key-value store” Datenbanksystemen
ist Redis in der Lage, komplexere Datenstrukturen zu persistieren, wie Maps (Hashes/Dictionaries),
Mengen, sortierte Mengen und Listen. Weitere Details sind in [MO11] zu finden.
AMQP-Modell und .Architektur für die Realisierung des Kommunikationskanals
Konkret wurde das folgende Modell für den Kommunikationskanal in der AMQP-Terminologie
umgesetzt, zusammen mit dem genannten “NoSQL”, echtzeitfähigen Datenbanksystem namens Redis:
Abbildung 7.2: Überblick des Kommunikationskanals, in der AMQP-Terminologie, mit
dauerhaften und kurzlebigen Queues sowie anwendungsspezifischen Erweiterungen.
In der Abbildung 7.2 wird das verwendete AMQP-Modell für den Kommunikationskanal dargestellt.
Die Anwendungen können die Rollen wechseln, sodass die Wohnungseigentümer Android App
auch in der Lage ist, Mitteilungen zu empfangen und umgekehrt. Es wurde jeweils ein Exchange implementiert,
der die dauerhaften (d.h. “Offline” oder persistierte) Mitteilungen und entsprechend die
nicht langlebigen Mitteilungen (d.h. Mitteilungen des Typs “Instant Messaging”) zu einer Queue weiterleitet
bzw. routet.
Die Skalierbarkeit der Lösung kann durch die Existenz mehrerer Queues begründet werden, obwohl
für den Basis-Anwendungsfall nur eine Queue pro Mieter erstellt wird. In weiteren Fällen wie z.B.
eine höhere Anzahl von Mietern, die einzelne Kommunikationen mit dem Mieter durchführen möchten,
bleibt die Architektur bestehen. Ein weiterer Aspekt der Implementierung ist die Darstellung der
“flush” Operation. Hiermit wird der Umgang mit Queues definiert, die von einer nicht dauerhaften