Polling versus Messaging

833 Aufrufe

Veröffentlicht am

Oliver Wronka, Principal Architect/ Project Manager bei axxessio, stellt in dieser Präsentation Polling gegenüber Messaging.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
833
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Polling versus Messaging

  1. 1. Polling versus Messaging Eine REST basierte Alternative JANUAR 2014 OLIVER WRONKA
  2. 2. Einführung » Häufig werden Daten zwischen Systemen verteilt. Hierbei hat ein System die Rolle des Masters, der lesen und schreiben darf. Alle anderen Systeme sind Slaves. Diese kopieren die Daten vom Master, greifen aber nur lesend darauf zu. » Dieses Szenario trifft sehr häufig bei Stammdaten zu. » Aus Gründen der Performance und der Verfügbarkeit werden diese häufig redundant je System vorgehalten. » Änderungen an den Daten auf dem Master müssen an die abonnierenden Systeme – Slaves - verteilt werden. » Die klassische Lösung hierfür ist Messaging oder Batchupdate. » Eine elegante Alternative ist Polling und wird hier beschrieben. 2
  3. 3. Aspekte Die Elemente auf der Ebene unterhalb von <customer> bis auf <id> stellen Aspekte dar. Das sind Informationen, die logisch zusammengehören. Die folgende XML-Struktur stellt die zu übertragenden Daten dar: <?xml version="1.0" encoding="UTF-8"?> <customer> <id>4711</id> <person> <salutation>Mr</salutation> <first_name>Oliver</first_name> <last_name>Wronka></last_name> </person> <address> <street>Kurfürstenstraße 5</street> <city>Bonn</city> <zip>53177</zip> </address> <contact> <email>wronka@axxessio.com</email> <phone>+49 (228) 763631-0</phone> <mobile>+49 (151) 29244214<mobile> </contact> </customer> In diesem Fall gibt es also die Aspekte: » person » address » contact Eine Slaveanwendung soll später auswählen können, welche Aspekte sie eines Kunden benötigt und nur diese werden dann übertragen. 3
  4. 4. Messaging Queue AS Disp Queue Client Queue Conf DB Client Client Datenfluss 1. 2. 3. 4. 5. 6. Das Backendsystem besteht aus einer Datenbank sowie einem Applicationserver. Jegliche Änderung an einem Datensatz führt zu einer Nachricht. Ein vorgeschalteter Dispatcher prüft, welche Aspekte des Datensatzes geändert wurden Der Dispatcher kann extern konfiguriert werden. In dieser Konfiguration steht, welche Clients es gibt und welche Aspekte diese abonniert haben. Jeder Client erhält nur die Informationen, die er benötigt und wird nur informiert, wenn ein ihn interessierender Aspekt des Datensatzes geändert wurde. 4
  5. 5. Trade-offs    Neue Clients erfordern eine angepasste Konfiguration. Je nach Volumen ist eine gesonderte Hardware für das Messaging notwendig Der initiale Load eines Clients sowie das Recovery-Delta im Falle eines Backups auf dem Client können auf diese Weise nicht abgedeckt werden. Es muss ein zusätzliche Schnittstelle aufgebaut werden um diese Daten bereit zu stellen, z. B. XML-Datei. 5
  6. 6. Versionisierung  Für die Pollinglösung müssen die Daten versioniert werden.  Hierzu wird eine Versionsnummer mitgeführt, die nach jedem Commit auf der DB um 1 inkrementiert wird.  Jeder Datensatz hat zusätzlich eine Spalte VERSION. Egal ob Neuanlage oder Update, die VERSION eines Datensatzes wird immer auf die aktuelle Versionsnummer gesetzt. 6
  7. 7. Polling Client Version: 2 Data: person, address DB AS Version: 5 Data: person Cache » Die Clients rufen zyklisch die Schnittstelle auf. » Hierbei wird das REST-Protokoll verwendet: http://{server}.{port}/customers?version=### » Optional können die Aspekte mit übergeben werden: /customers?version=###&aspect1=person&aspect2=address 7 Client Version: 0 Data: person, address, contact Client Zugriff
  8. 8. Rückgabe <?xml version="1.0" encoding="UTF-8"?> <customers> <version> <this>5</this> <last>12</last> </version> <customer> <id>4711</id> <person>...</person> <address>...</address> </customer> <customer> <id>4711</id> <person>...</person> <address>...</address> </customer> <customer> <id>4711</id> <person>...</person> <address>...</address> </customer> </customers> » Es werden Chunks von <customer> zurückgeliefert. » Jeder Datensatz beinhaltet nur die Aspekte, die zuvor angefordert wurden, hier also person und address.. » Diese können je nach Datenvolumen bis zu 1.000 Datensätze beinhalten. » Es wird die Version dieser Abfrage sowie die höchste Version mitgeliefert. Solange beide ungleich sind liegen weitere Daten vor und der Client sollte sofort den nächste Request absetzen. » Sind beide Versionen gleich wartet der Client für eine bestimmte Zeit. 8
  9. 9. Caching DB Client AS Cache » Insbesondere Stammdaten eignen sich optimal zum Cachen da sich diese nicht so häufig ändern. » Gab es keine Änderung, so wird die Anfrage immer aus dem Cache beantwortet. Client » Gab es Änderungen, so ist die Wahrscheinlichkeit hoch, dass nur die erste Anfrage auf die DB durchschlägt, alle anderen werden dann wieder aus dem Cache beantwortet (aber: abhängig von den jeweiligen Aspekten). 9 Client Zugriff
  10. 10. Vorteile » Neue Clients müssen nicht konfiguriert werden sondern können einfach die Schnittstelle nutzen. » Ein initial Load kann durchgeführt werden, indem sich der Client mit der Version 0 meldet. » Ein Deltaload nach dem Einspielen eines Backups kann durchgeführt werden, indem die höchste, bekannte Version auf dem Slave ermittelt wird und zur Sicherheit eine Anfrage aller Daten mit Version-1 durchgeführt wird. » Es ist keine gesonderte Messaginghardware notwendig. Meistens erfolgt die HTTPSTerminierung sowieso auf gesonderten Servern in der DMZ. Auf diesen könnte dann der Cache betrieben werden. 10
  11. 11. Consider IT done! Unsere Standorte Hauptsitz Bonn Niederlassung Köln Niederlassung Darmstadt Niederlassung Bern Kurfürstenallee 5 53177 Bonn Tel +49 228 – 76 36 31 0 Fax +49 228 –76 36 31 3 Wilhelmstraße 3 51143 Köln Tel +49 22 03 – 91 22 0 Fax +49 22 03 – 91 22 23 Kasinostraße 60 64293 Darmstadt Tel +49 61 51 – 78 90 0 Fax +49 61 51 – 78 90 23 0 Frohbergweg 7 3012 Bern Tel +41 31 – 534 07 06 Fax +41 31 – 536 69 78

×