© Excellent backgrounds/Shutterstock.com
Java Magazin
Umstellung der Kommunikation von Pull auf Push

Don’t call us, we’ll call you

Mobile Anwendungen zeigen oftmals gänzlich andere Kommunikationsmuster auf als ihre Pendants aus der Webwelt. Die App öffnen, den aktuellen Status abfragen und gleich wieder schließen, und das viele Male am Tag. So in etwa sieht das typische Nutzungsverhalten aus. Nicht selten kommt es dabei durch die vielen kleinen Requests zu einer erhöhten Last auf dem Server, die so ursprünglich nicht geplant war - die damit verbundenen Probleme eingeschlossen. Eine mögliche Lösung, dem erhöhten Lastaufkommen Herr zu werden, stellt die Umstellung des Kommunikationsmusters von Pull auf Push dar.

Arne Limburg, Lars Röwekamp


Klassische Webanwendungen kommunizieren in der Regel nach dem bekannten Request-Response-Muster. Der Client fragt gezielt Informationen bzw. Daten beim Server an, und der Server sendet diese, nach dem Processing, an den Client zurück. Zur Reduzierung des Lastaufkommens wird dabei häufig auf AJAX oder ähnliche Mechanismen gesetzt. Das Grundprinzip bleibt aber stets das gleiche. Das eben beschriebene Kommunikationsmuster geht so lange gut, wie sich die Anzahl der Anfragen in überschaubaren Grenzen hält. Gleichzeitig ergibt es nur dann Sinn, wenn bei wiederholter Anfrage an den Server auch tatsächlich neue bzw. geänderte Daten für den anfragenden Client vorliegen.

Während das eben beschriebene Pattern für typische Webanwendungen durchaus valide erscheint, sieht dies bei Apps häufig anders aus. Wieder und wieder fragen diese beim Server nach neuen Informationen bzw. Daten, ohne dass sich der serverseitige Status in der Zwischenzeit geändert hat. Das Resultat sind eine Vielzahl unnötiger Server-Requests und eine damit verbundene hohe Auslastung des Servers ohne wirklichen Nutzermehrwert.

Ist dies wirklich ein reales oder eher ein theoretisches Problem? Eine Studie der IBM [1], bezogen auf Apps im Bankenumfeld, zeigte bei der Analyse des Use Cases „check bank account“ einen Overhead von knapp 80 Prozent. Anders formuliert haben vier von fünf Anfragen lediglich Traffic auf dem Server erzeugt, ohne dem Nutzer einen zusätzlichen Mehrwert zu bieten. Was liegt also näher, als nur dann zu kommunizieren, wenn wirklich neue Informationen bzw. Daten am Server vorliegen, und als logische Konsequenz das Kommunikationsprotokoll entsprechend von Pull auf Push umzustellen?

Push ist nicht gleich Push

In Artikeln, Blogs oder anderen Publikationen findet man unterschiedlichste Beschreibungen des Begriffs „Push“. Bevor wir also zeigen, wie sich eine Server-side-Push-Kommunikation unter Android realisieren lässt, wollen wir kurz auf die unterschiedlichen Varianten eingehen:

Simulated Push via repeated Pull RequestPush Notification, Pull PayloadReal Push with Payload

Die erste Variante ist nicht wirklich ein Push-Mechanismus, sondern simuliert diesen lediglich. Der Client triggert regelmäßig den Server an und fragt, ob neue Daten vorhanden sind. Ist dies der Fall, sendet der Server die Daten an den Client, wo sie im Anschluss verarbeitet, also z. B. in einer lokalen DB gespeichert werden. Der Vorteil dieser Variante gegenüber einer klassischen Request-Response-Kommunikation aus der...

Java Magazin
Umstellung der Kommunikation von Pull auf Push

Don’t call us, we’ll call you

Mobile Anwendungen zeigen oftmals gänzlich andere Kommunikationsmuster auf als ihre Pendants aus der Webwelt. Die App öffnen, den aktuellen Status abfragen und gleich wieder schließen, und das viele Male am Tag. So in etwa sieht das typische Nutzungsverhalten aus. Nicht selten kommt es dabei durch die vielen kleinen Requests zu einer erhöhten Last auf dem Server, die so ursprünglich nicht geplant war - die damit verbundenen Probleme eingeschlossen. Eine mögliche Lösung, dem erhöhten Lastaufkommen Herr zu werden, stellt die Umstellung des Kommunikationsmusters von Pull auf Push dar.

Arne Limburg, Lars Röwekamp


Klassische Webanwendungen kommunizieren in der Regel nach dem bekannten Request-Response-Muster. Der Client fragt gezielt Informationen bzw. Daten beim Server an, und der Server sendet diese, nach dem Processing, an den Client zurück. Zur Reduzierung des Lastaufkommens wird dabei häufig auf AJAX oder ähnliche Mechanismen gesetzt. Das Grundprinzip bleibt aber stets das gleiche. Das eben beschriebene Kommunikationsmuster geht so lange gut, wie sich die Anzahl der Anfragen in überschaubaren Grenzen hält. Gleichzeitig ergibt es nur dann Sinn, wenn bei wiederholter Anfrage an den Server auch tatsächlich neue bzw. geänderte Daten für den anfragenden Client vorliegen.

Während das eben beschriebene Pattern für typische Webanwendungen durchaus valide erscheint, sieht dies bei Apps häufig anders aus. Wieder und wieder fragen diese beim Server nach neuen Informationen bzw. Daten, ohne dass sich der serverseitige Status in der Zwischenzeit geändert hat. Das Resultat sind eine Vielzahl unnötiger Server-Requests und eine damit verbundene hohe Auslastung des Servers ohne wirklichen Nutzermehrwert.

Ist dies wirklich ein reales oder eher ein theoretisches Problem? Eine Studie der IBM [1], bezogen auf Apps im Bankenumfeld, zeigte bei der Analyse des Use Cases „check bank account“ einen Overhead von knapp 80 Prozent. Anders formuliert haben vier von fünf Anfragen lediglich Traffic auf dem Server erzeugt, ohne dem Nutzer einen zusätzlichen Mehrwert zu bieten. Was liegt also näher, als nur dann zu kommunizieren, wenn wirklich neue Informationen bzw. Daten am Server vorliegen, und als logische Konsequenz das Kommunikationsprotokoll entsprechend von Pull auf Push umzustellen?

Push ist nicht gleich Push

In Artikeln, Blogs oder anderen Publikationen findet man unterschiedlichste Beschreibungen des Begriffs „Push“. Bevor wir also zeigen, wie sich eine Server-side-Push-Kommunikation unter Android realisieren lässt, wollen wir kurz auf die unterschiedlichen Varianten eingehen:

Simulated Push via repeated Pull RequestPush Notification, Pull PayloadReal Push with Payload

Die erste Variante ist nicht wirklich ein Push-Mechanismus, sondern simuliert diesen lediglich. Der Client triggert regelmäßig den Server an und fragt, ob neue Daten vorhanden sind. Ist dies der Fall, sendet der Server die Daten an den Client, wo sie im Anschluss verarbeitet, also z. B. in einer lokalen DB gespeichert werden. Der Vorteil dieser Variante gegenüber einer klassischen Request-Response-Kommunikation aus der...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang