Microservices – Kommunikation

In den letzten zwei Artikeln der Serie wurden zum einen die organisatorische Sicht sowie die Vor- und Nachteile des Einsatzes der Microservices-Architektur vorgestellt. Nachdem das Team die Entscheidung getroffen hat, den Microservices-Ansatz zu verwenden, müssen grundlegende technische Themen besprochen werden. Schon am Anfang ergibt sich die Frage, wie Microservices miteinander kommunizieren werden. Es gibt verschiedene Wege, die vom konkreten Anwendungsfall abhängen. Das Ziel dieses Artikels ist es, einen Überblick über die Kommunikationsmethoden zwischen Microservices zu verschaffen. Man unterscheidet grundsätzlich zwischen zwei Kommunikationsarten: synchron und asynchron.

Synchrone Kommunikation

Diese Art der Kommunikation wird dann verwendet, wenn der Aufrufer die Antwort sofort braucht und gleichzeitig auf sie wartet. Dieser Ansatz kann technisch mit REST implementiert werden.

microservices5

Abbildung 1: Synchrone Kommunikation

In dem obigen Beispiel kommunizieren Logistic- und Billing- mit dem Order-Microservice, um beispielweise die Informationen einer Bestellung zu bekommen. Die Aufrufe sollen nur in einer Richtung verlaufen. Der Order-Microservice darf auf keinen Fall auf die Funktionalität des Logistic-Microservice zugreifen. Dadurch würden zyklische Abhängigkeiten entstehen, die für die Microservice-Architektur negative Folgen hätten. Der größte Nachteil dabei ist, dass eine zu enge Kopplung zwischen Microservices entsteht. Die Verwendung dieser Kommunikationsart sollte zudem immer gerechtfertigt sein. In vielen Quellen wird gerade diese Art der Kommunikation als Anti-Pattern bezeichnet, weil sie zu beträchtlichen Latenzzeiten führen kann.

Ein Microservice kann auch über eine HTTP-Schnittstelle für externe Aufrufe angeboten werden. Die gegenwärtigen Bibliotheken ermöglichen quasi asynchrone Aufrufe von einer synchronen Schnittstelle. Praktisch bedeutet das, dass die die Kommunikation trotzdem synchron bleibt, aber der Haupt-Thread wird nicht blockiert. Das heißt, dass in der Bearbeitungszeit auch andere Operationen ausgeführt werden können. Demgegenüber sollte die interne Kommunikation zwischen Microservices möglichst asynchron verlaufen.

Asynchrone Kommunikation

Man sollte also die asynchrone Kommunikationsart zwischen Microservices bevorzugen. Technisch kann das Konzept mittels Events realisiert werden. Die Abbildung 2 stellt den Prozess dar.

Abbildung 2: Asynchrone Kommunikation durch Verwendung eines Messaging-Systems

Im Mittelpunkt des Diagramms steht ein sogenanntes Messaging-System. An das Messaging-System werden die Nachrichten geschickt, die später von anderen Microservices verarbeitet werden. Der größte Vorteil besteht darin, dass die Microservices komplett voneinander entkoppelt sind. Der Absender kennt den Empfänger der Nachricht nicht. Messaging ist eine gute Grundlage für die Implementierung moderner Architekturen, wie zum Beispiel reaktive Systeme oder Event Sourcing.

Kommunikation durch Datenreplikation

Der Ausgangspunkt dieses Konzepts ist, dass jeder Microservice seine eigene Datenbank besitzt. Die Microservices abonnieren bestimmte Events, die die benötigten Daten beinhalten. Im Rahmen der Verarbeitung von Events werden die Daten in der lokalen Datenbank persistiert. Es ergibt sich zunächst die Frage, ob diese doppelte Datenhaltung effizient ist. In dem Microservice-Ansatz werden die Daten nicht automatisch 1:1 dupliziert. Jeder Microservice besitzt seinen eigenen Bounded Context. Das heißt, wenn ein Event ankommt, werden nur die Informationen verarbeitet und gespeichert, die für den Kontext relevant sind. Die Abbildung 3 stellt diese Art der Replikation dar.

micorservices-5-1

Abbildung 3: Datenreplikation und Bounded Context

Das Event einer neuen Bestellung enthält zwei Adressen: Rechnungsadresse und Lieferadresse. Der Logistic-Microservice speichert die Lieferadresse. Der Billing-Microservice speichert hingegen nur die Rechnungsadresse. In jedem Microservice wird ein unterschiedlicher Bounded Context implementiert und es werden nur die Daten gespeichert, die für die Domäne relevant sind. Dieser Ansatz führt zur besseren Performanz.  Wenn die Daten benötigt werden, können sie sofort aus der eigenen Datenbank ausgelesen werden. Dieser Prozess erfolgt ohne jegliche Kommunikation mit anderen Subsystemen. Zum Schluss muss noch eine wichtige Regel erwähnt werden: Es darf nur eine Stelle geben, an der Daten geändert werden können. Wenn diese Regel nicht beachtet wird, dann kommt es zu Inkonsistenzen zwischen beiden Datenbanken. In der Praxis heißt das: Die replizierten Daten dürfen nur von dem Microservice geändert werden, von dem sich ursprünglich stammen. Der Empfänger nutzt die Daten nur zum Lesen.

Fazit

Kommunikation zwischen Microservices ist ein Thema, das gleich zu Beginn des Projektes geklärt werden sollte. Es ist durchaus möglich, mehrere Kommunikationsmethoden zu verwenden, die jeweils zu einem konkreten Anwendungsfall passen. Für eine moderne Architektur mit Microservices scheint aber ein Messaging-System eine wichtige Rolle zu spielen.

Quellen:

[1] E. Wolff: Microservices, Grundlagen flexibler Softwarearchitekturen, dpunkt Verlag

[2] innoQ: Why RESTful communication between microservices can be perfectly fine.

Microservices – Vor- und Nachteile

In dem ersten Artikel der kleinen Microservices-Serie wurde anhand eines kleinen Beispiels dargestellt, wie Microservices die Organisation der Arbeit beeinflussen. Das Konzept bringt wesentliche Vorteile. Bevor man sich aber für den Einsatz von Microservices entscheidet, müssen auch andere Aspekte in Betracht gezogen werden. Der Zweck dieses Beitrags ist, die wesentlichen Vor- und Nachteile zu beleuchten.

Vorteile

Ein bedeutsamer, technischer Vorteil der Microservices ist, dass sie durch die starke Modularisierung leicht ersetzbar sind. Im Laufe der Zeit wird ein System durch Erosion der Architektur immer fehleranfälliger und ineffizienter. In einer monolithischen Anwendung müsste man entweder die ganze Anwendung refrakturieren oder aber komplett ersetzten. Das Ablösen eines alten Systems ist immer risikoreich. Dadurch, dass ein Microservice nur einen bestimmten Teil des Gesamtsystems abbildet, ist die Änderung weniger riskant. Es lässt sich also nicht leugnen, dass Microservices eine nachhaltige Softwareentwicklung unterstützen.

Moderne Anwendungen müssen auch unter hoher Last leistungsfähig sein. Aus diesem Grund sollten zukunftssichere IT-Systeme Skalierungsmöglichkeiten anbieten. Insbesondere handelt sich es hier um eine sogenannte horizontale Skalierung. Genauer gesagt muss das System bzw. Subsystem auf mehreren Maschinen parallel lauffähig sein. Der Nachteil bei einem Monolith ist, dass die ganze Anwendung komplett skaliert werden muss, was zu einem beträchtlichen Verbrauch kostbarer Ressourcen führt. Sehr häufig sind auch nur bestimmte Funktionalitäten einer hohen Last ausgesetzt. Dank einer starken Entkopplung von Komponenten untereinander kann man sehr feingranular skalieren.

In sehr vielen Projekten entscheidet man sich im Voraus für Technologien, die für die Implementierung geeignet sind. Das reale Leben zeigt aber, dass der englische Spruch „one size fits all“ nicht immer passt. Manchmal gibt es Anforderungen, die schwierig mit vorhandener Technik implementierbar sind. Beispielsweise könnte es besser sein, für eine bestimmte Subdomäne eine nichtrelationale Datenbank oder eine völlig andere Programmiersprache zu benutzen. Die fachliche Domäne beeinflusst also die Architektur. Durch die Entkopplung von Microservices genießt man die Freiheit, unterschiedliche Technologien benutzen zu können.

Nachteile

Trotz der vielen Vorteile haben Microservices aber auch Nachteile, die sorgfältig vor dem Projektbeginn durchdacht werden sollten. Ein wichtiges Argument gegen den Einsatz von Microservices sind hohe Latenzzeiten, die in dieser Architektur vorkommen können. Das Zusammenspiel von Microservices bildet ein verteiltes IT-System ab. Die Kommunikation verläuft über das Netzwerk zwischen verschiedenen Maschinen. So eine Art der Kommunikation ist selbstverständlich viel langsamer als die Kommunikation zwischen Prozessen, die auf demselben Rechner laufen.

Wie eben erwähnt wurde, gehört die technische Unabhängigkeit zu den größten Vorteilen von Microservices. Aus einer anderen Sicht kann der Vorteil aber auch als ein Nachteil betrachtet werden, wenn zum Beispiel hohe Wiederverwendbarkeit von Code eine große Rolle im Projekt spielt. Dadurch, dass die Teams isoliert arbeiten und gegebenenfalls unterschiedliche Technologien benutzten, sinkt die Wiederverwendbarkeit von Code deutlich.

Microservices sind unabhängige Deployment-Einheiten. Das heißt, dass sie einen eigenen Deployment-Prozess benötigen. Um das zu ermöglichen, muss eine separate Infrastruktur eingesetzt werden, was zugleich zusätzliche Kosten generiert.

Fazit

Die Entscheidung, ob für das Projekt Microservices ein passender Ansatz sind, scheint zunächst schwerwiegend zu sein. Man muss hierbei alle Pro- und Contra-Argumente berücksichtigen. Ein wichtiger Schritt in dem Prozess der Analyse ist die Bestimmung von qualitativen Zielen, die das System erfüllen soll. Die Microservices-Architektur muss anschließend im Kontext der Realisierbarkeit der qualitativen Ziele erforscht werden.

Quellen

[1] E. Wolff: Microservices, Grundlagen flexibler Softwarearchitekturen, dpunk Verlag

[2] Dev + Ops bei Otto.de: Why Microservices?

Microservices – Organisatorische Sicht

Microservices scheinen heutzutage ein ganz wichtiger Trend in der IT-Branche zu sein. In sehr vielen Quellen wird das Thema nur aus der technologischen Perspektive besprochen. Die Thematik ist aber viel breiter. Microservices haben nicht nur Einfluss auf die angewandten Technologien, sondern auch auf die Organisation des Teams. Im folgendem Artikel wird der Schwerpunkt auf die Auswirkungen von Microservices auf die alltägliche Arbeit im Projekt gelegt. Als Grundlage für die Darstellung des Themas wird beispielhaft ein Projekt aus dem Bereich E-Commerce analysiert.

Beschreibung des Beispielprojektes

Das Ziel des Projekts ist die Implementierung eines kompletten IT-Systems für die Verwaltung eines Online-Shops. Das Team arbeitet mit der Scrum-Methodik. Die Anforderungen werden als User Stories definiert und später von dem gesamten Team geschätzt. In dem kommenden Sprint sollte folgende Story implementiert werden:

Als Kunde möchte ich Produkte bestellen, sodass ich diese später geliefert bekomme.

Eine vollständige User Story sollte ebenfalls Akzeptanzkriterien beinhalten:

  • Produkte aus dem Warenkorb werden in die Bestellung aufgenommen.
  • Die Bestellung wird im System registriert.
  • Der Kunde bekommt eine Bestätigung per E-Mail.

Das Scrum-Team hat eine Schätzung abgegeben, die 5 Story-Points beträgt. In sehr vielen Projekten werden die User Stories erst im Laufe der Implementierung präzisiert. In diesem Fall wurden zusätzliche Akzeptanzkriterien definiert, die eigentlich als eigenständige User Stories gelten könnten.

  • Eine Rechnung sollte zur Bestellung generiert werden.
  • Der Lagerservice sollte informiert werden.

Das Team hat sich bereit erklärt, die Story vollständig zu implementieren. Während der Entwicklung stellt das Team fest, dass die Story zu komplex ist und leider falsch eingeschätzt wurde.

Das Projekt ist ein monolithisches System, deswegen lässt sich die Arbeit sehr schlecht verteilen, z. B. wegen zahlreicher Codeabhängigkeiten und unklarer Abgrenzung der Fachlichkeiten. Das Ergebnis: die Anforderung war nur zu 75% fertiggestellt und konnte nicht produktiv eingesetzt werden.

Analyse

Aus dem obigen Beispiel resultiert die Frage, welche Fehler begangen wurden, sodass die Umsetzung der User-Story scheiterte?

Der Product Owner und/oder Architekt hätten feststellen können, dass diese Anforderung mehrere Domänen betrifft:

  • Die Bestellung wird im System registriert => Bestellprozess
  • Eine Rechnung sollte zur Bestellung generiert werden => Buchhaltung
  • Der Lagerservice sollte informiert werden => Logistik

Mit der Aufteilung der Domäne in kleinere Subdomänen lässt sich die Arbeit gut parallelisieren. Die Bestimmung von Subdomänen ist ein Ausgangspunkt für den Entwurf von Microservices.
Der Microservice-Ansatz setzt voraus, dass der Entwicklungsprozess von Subsystemen eigenständig verlaufen soll. Die folgenden Grafiken zeigen, wie die Arbeit in den unterschiedlichen architektonischen Ansätzen organisiert wird [1].

microservices6_test2

Abbildung 1: Aufteilung für monolithisches System

Bei der Entwicklung eines monolithischen Systems arbeitet das Team an einem gemeinsamen Backlog. Eine Anforderung kann also mehrere Domänen betreffen, die aber nicht klar definiert sind. Das heißt, die Anforderung betrifft das ganze System und deswegen lässt sich die Arbeit schlecht parallelisieren.

 

microservices7

Abbildung 2: Aufteilung für Microservices

In dem Microservices-Ansatz sieht das anders aus. Das Team wird in mehrere kleinere Teams geteilt, die für eigene Subsysteme (Microservices) verantwortlich sind. Selbst die Einführung eines neuen Teams sollte in dieser Architektur kein Problem sein. Die User-Story kann schon am Anfang nach Subdomänen gesplittet und danach jedem Team zugewiesen werden. Die Teams arbeiten damit unabhängig und effizient an den Anforderungen. Als Konsequenz ergibt sich eine bessere Schätzbarkeit und Planbarkeit. Dadurch sinkt auch das gesamte Risiko des Projekts. Die Features werden separat ausgeliefert, was einen signifikanten Vorteil hinsichtlich „Time to Market“ ausmacht. In dem monolithischen System müsste entweder alles oder nichts deployt werden.

Fazit

Microservices haben nicht nur einen Einfluss auf die technologische Basis des Projektes, sondern auch auf die Organisation der Arbeit. Ein großes Projekt wird durch kleinere Projekte, d. h. Microservices, ersetzt. Die Teams können eigenverantwortlich arbeiten und haben mehr Freiheit, wenn es um die Wahl der Technologie geht. Aus der Geschäftssicht wird weniger zentrale Koordinierung benötigt. Der Microservices-Ansatz steht eng im Zusammenhang mit Scrum, bei dem selbstorganisierte Teams im Vordergrund stehen.

Quellen

[1] E. Wolff: Microservices, Grundlagen flexibler Softwarearchitekturen, dpunkt Verlag

[2] Dev + Ops bei Otto.de: Why Microservices?

JavaScript testen – Testumgebung und Auswahl des Frameworks

Das Ausführen von manuellen Tests reicht heutzutage nicht, um die gesamte Komplexität der Anwendung abzudecken. Es sollte die Aufgabe der Entwickler sein, um sicherzustellen, dass die Funktionalität die implementiert wird, tatsächlich funktioniert. Die Testfälle sollten vor allem automatisch reproduzierbar sein. Um dieses Ziel zu erreichen kommen Unit Tests zum Einsatz. In JavaScript sollten sie besonders von Bedeutung sein, da die Sprache über keine strenge Typisierung verfügt. Immer mehr Logik wird clientseitig implementiert, deshalb ist die Komplexität der Webanwendungen heutzutage signifikant gestiegen.

Gliederung des Testframeworks

In JavaScript existiert eine große Menge der Bibliotheken und Testframeworks. Es ist nämlich ganz wichtig das entsprechende Testframework fürs Projekt zu wählen. Die Testframeworks oder genauer gesagt die Konzepte der Testumgebung kann man nach drei Kategorien gliedern:

  • Clientseitige Frameworks – sind Frameworks, die nur den Webbrowser zum Funktionieren brauchen. Beispiele: Jasmine, QUnit
  • Serverseitige Frameworks – sind Frameworks, die die Serverkomponente zum Ausführen von Tests brauchen. Beispiel: JSTestDriver
  • Hybride Lösungen – ein clientseitiges Testframework und zusätzlich ein Testrunner, der als Serverkomponente dient. Beispiele: Jasmine oder QUnit mit Karma

Clientseitige Frameworks: QUnit und Jasmine

Zu den gängigsten clientseitigen Frameworks gehört QUnit und Jasmine. QUnit wurde von denselben Entwicklern gebaut, die JQuery implementiert haben. Am Anfang war also die Bibliothek ganz stark mit JQuery verbunden. Jetzt hat sich das geändert, und QUnit ist ein separates Framework für das Unit Testing. Die Tests werden so gebaut, wie in den anderen „klassischen“ Unit Tests Frameworks. Die Lernkurve sollte in diesem Fall ziemlich gering sein.

   1: test('Divide 4 by 2', function () {

   2:     var result = divide(2,2);

   3:     equal(result, 2, '4 divided by 2 equals 2');

   4: });

Der Testfall wird in der Funktion test() ausgeführt und die Prüfung findet in equal() statt.

Jasmine ist hingegen ein BDD (Behaviour Driven Development Framework) Testframework. Der Unterschied an den man sich gewöhnen sollte, ist die deskriptive Art und Weise, wie man die Tests schreibt.

   1: describe("calulates discount for tablets", function() {

   2:  

   3:     it("returns 10% discount for 2 items", function () {

   4:  

   5:         // Arrange

   6:         var product = new Product("Test", "Tablets", 10, 2);

   7:  

   8:         // Act

   9:         var result = App.Logic.dicountCalculator.calculateForProduct(product);

  10:  

  11:         // Assert

  12:         expect(result.hasDiscount()).toBe(true);

  13:         expect(result.newPrice).toBe(18);

  14:     });

  15:  

Describe() ist eine Funktion, die die Tests gruppiert. Ein bestimmter Testfall sollte in der it() Funktion implementiert werden.

Jasmine erfreut sich sehr großer Popularität und wird ständig um neue Funktionalitäten erweitert. Ein großer Vorteil von Jasmine ist, dass es sich gut für das Testen von AngularJS eignet. Der Umfang der Funktionalität ist bei beiden Frameworks fast gleich. Der Entwickler muss selber entscheiden, welche Art der Syntax für ihn mehr überzeugend ist.

Das Problem bei der Entwicklung von JavaScript ist, dass der Code in mehreren Browsern lauffähig sein sollte. Die clientseitigen Frameworks verfügen zwar über eine angenehme Syntax aber das Ausführen von Tests lässt sich alleine damit schwierig automatisieren.

Serverseitige Frameworks und Hybride Lösungen

Diese Möglichkeit wird zwar von den serverseitigen Frameworks angeboten, aber sehr oft müssen die Tests in demselben Framework geschrieben werden, das die Serverkomponente unterstützt. Wenn man aber von beiden Optionen profitieren möchte, dann kann ein clientseitiges Testframework und zusätzlich eine Serverkomponente benutzt werden, die nur zum Ausführen von Tests dient und gleichzeitig mehrere clientseitige Testframeworks unterstützt, wie zum Beispiel Karma. Karma ist ein Testrunner, der auf node.js basiert.

Die Funktionsweise der Testumgebung wurde in der folgenden Abbildung dargestellt.

image

Serverseitige Testumgebung für JavaScript

Das zentrale Element der Testumgebung ist der Server, der über die Config Datei konfiguriert ist. Der Server gibt eine Schnittstelle frei, mit der sich die Browser verbinden. Auf den verbundenen Browser werden die Tests ausgeführt. Der ganze Prozess wird mit der Kommandozeile gesteuert.

Von Installation bis zum Ausführen von Tests ist der Entwickler nur ein paar Schritte entfernt.

   1: # Installation von Karma:

   2: $ npm install karma --save-dev

   3:  

   4: # Installation von Plugins, die in der Testumgebung benutzt werden:

   5: $ npm install karma-jasmine karma-chrome-launcher --save-dev

   6:  

   7: # Starten von Karma mit einer bestimmten Konfigurationsdatei:

   8: $ karma start my.conf.js

imageAnzeige welche Browser mit dem Browser verbunden sind

image

Ergebnis der Ausführung von Tests

In Hinblick darauf, dass Karma sich ganz gut mit dem CI-Server verbinden lässt, scheint die gleichzeitige Anwendung des clientseitigen Testframeworks und der serverseitige Komponente eine vernünftige Lösung zu sein. Der nächste Schritt nach der Auswahl von Technologien ist die Erstellung einer testfreundlichen Architektur der Applikation.

Quellen:

[1] https://code.google.com/p/js-test-driver/

[2] http://karma-runner.github.io/0.12/index.html

[3] http://jasmine.github.io/

[4] https://qunitjs.com/

[5] Sebastian Springer, Testgetriebene Entwicklung mit JavaScript, dpunkt Verlag, 2015

Offlinefähigkeit in mobilen Applikationen

Die Anzahl von mobilen Applikationen wächst heutzutage immer schneller an. Diese Feststellung gilt sowohl für die sog. Store-Apps (die öffentlich den Kunden zur Verfügung gestellt werden) als auch für Enterprise Applikationen, die in dem Backend des Unternehmens intergiert werden. Viele von diesen Anwendungen funktionieren aber nur dann, wenn eine Verbindung mit dem Internet besteht.

Manchmal, selbst im Fall von kurzen Verbindungsabbrüchen, ist die weitere Arbeit mit der Anwendung unmöglich. Dies kann allerdings in manchen Geschäftsszenarien nicht akzeptabel sein. Um die Benutzererfahrung zu verbessern und dieses Problem zu lösen, bieten viele Anwendungen Offlinefähigkeit an. Wenn man sich diese mobilen Anwendungen genauer anschaut, scheint die Verwendung des Begriffs der Offlinefähigkeit inkonsistent zu sein. Es gibt keine einheitliche Implementierung von Offlinefähigkeit.

Man kann folgende Varianten von Offlinefähigkeit unterschieden:

Varianten der Offlinefähigkeit

  • Variante 0: Keine Offlinefähigkeit

Die Anwendung hört auf zu funktionieren oder stürzt einfach ab, wenn sie die Verbindung verliert.

  • Variante 1: Erkennung von Verbindungsabbrüchen

Bei dieser Variante erkennt die Anwendung lediglich Verbindungsabbrüche. Die weitere Arbeit ist nicht möglich, aber die Applikation wird weiterhin ausgeführt und stürzt nicht ab. Der Benutzer wird aber eventuell eine Fehlermeldung bekommen.

  • Variante 2: Überwindung von kurzen Verbindungsabbrüchen

Die Applikation funktioniert trotz kurzfristiger Verbindungsabbrüche. In dieser Variante gibt es aber keine lokale Persistenz von Daten und Synchronisation mit dem Server. Die Anwendung kann beispielweise die Verbindung automatisch wiederherstellen. Daten hingegen werden zumindest teilweise auch in Voraus geladen werden, damit die App auch offline funktioniert.

  • Variante 3: „Echte“ Offlinefähigkeit

Die Anwendung ist ohne Internetverbindung funktionsfähig. Der Benutzer kann nicht nur Daten einsehen, sondern diese auch hinzufügen und löschen. Diese werden lokal auf dem Endgerät zwischengespeichert. Dazu müssen sie aber auch mit dem Server synchronisiert werden. Der Benutzer kann kontinuierlich arbeiten, ohne darauf zu achten, ob er gerade online oder offline ist. Diese letzte Variante ist die Schwierigste, wenn es um die praktische Umsetzung geht.

Bei der Implementierung der Offlinefähigkeit muss man sich also zunächst die Frage stellen, um welche Art von Offlinefähigkeit es sich handeln soll.

Sollte man sich für Variante 3 entscheiden, steht man vor einigen Herausforderungen:

  • Persistenz der lokalen Daten – unterschiedliche Plattformen bieten diverse Möglichkeiten der Datenpersistenz. Die können sowohl in relationaler, wie beispielsweise bei WebSQL oder SQLLite, als auch in unstrukturierter Form (z. B. im Filesystem) vorliegen.
  • Art und Weise der Integration mit dem bestehenden Backend – das heißt wie die Endanwendung auf dem Server integriert wird.
  • Synchronisierung von Daten – die Daten von sämtlichen Endgeräten müssen mit dem Server synchronisiert werden. Sämtliche Aspekte, wie z.B. Konflikterkennung und Konfliktlösung müssen sorgfältig durchdacht werden.

Die Architektur für diese Variante wird auf dem folgenden Bild schematisch dargestellt:

flurfunkOffline1

 

Fazit

Offlinefähigkeit ist ein sehr interessantes Feature, das die Benutzererfahrung mit mobilen Anwendungen erheblich verbessern kann. Wenn der Anwender ständigen Verbindungsabbrüchen ausgesetzt ist, scheint diese Funktionalität ein unabdingbares Element der modernen Entwicklung von mobilen Apps zu sein.

Für die Art der Umsetzung muss man sich entsprechend Gedanken machen, ob die einfachste Variante reicht oder ob das Businessszenario die echte Offlinefähigkeit notwendig macht. Der Fokus muss hierbei auf der Erkennung der Bedürfnisse des Kunden liegen, um die passende Variante zu wählen.