Eine REST basierte Alternative

OLIVER WRONKA

JANUAR 2014

Polling versus Messaging

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.

3

Aspekte

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&#252;rstenstra&#223;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>

Die Elemente auf der Ebene unterhalb von <customer> bis auf <id> stellen Aspekte dar. Das sind Informationen, die logisch zusammengehören.

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.

4

Messaging

1. Das Backendsystem besteht aus einer Datenbank sowie einem Applicationserver.2. Jegliche Änderung an einem Datensatz führt zu einer Nachricht.3. Ein vorgeschalteter Dispatcher prüft, welche Aspekte des Datensatzes geändert wurden 4. Der Dispatcher kann extern konfiguriert werden.5. In dieser Konfiguration steht, welche Clients es gibt und welche Aspekte diese abonniert haben.6. 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.

Client

DB AS

Queue Client

ClientQueue

Queue

Disp

ConfDatenfluss

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.

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.

7

Polling

» 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=addressZugriff

DB AS

Client

Client

Client

Cache

Version: 2Data: person, address

Version: 5Data: person

Version: 0Data: person, address, contact

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.

9

Caching

» Insbesondere Stammdaten eignen sich optimal zumCachen da sich diese nicht so häufig ändern.

» Gab es keine Änderung, so wird die Anfrage immeraus dem Cache beantwortet.

» Gab es Änderungen, so ist die Wahrscheinlichkeithoch, dass nur die erste Anfrage auf die DB durch-schlägt, alle anderen werden dann wieder aus demCache beantwortet (aber: abhängig von den jeweiligen Aspekten).

Client

ClientDB AS

Client

Zugriff

Cache

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 HTTPS-Terminierung sowieso auf gesonderten Servern in der DMZ. Auf diesen könnte dann der Cache betrieben werden.

Unsere Standorte

Niederlassung Köln

Wilhelmstraße 351143 KölnTel +49 22 03 – 91 22 0Fax +49 22 03 – 91 22 23

Niederlassung Darmstadt

Kasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0

Hauptsitz Bonn

Kurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Niederlassung Bern

Frohbergweg 73012 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78

Consider IT done!