Verfügbarkeit des MessageAuthenticationServices durch Caching‌

Der MessageAuthenticationService (Konfigurationsdatei ./etc/auth_dmz.xml, bzw. wie in ./etc/factory_dmz.xml eingetragen) in einem DMZ-Szenario beantwortet die Anfragen, die er von Kommunikationsdiensten erhält, indem er sie per synchroner Message an den AuthenticationService des inneren Servers weiterleitet. Wenn der innere Server nicht erreichbar ist, muss der MessageAuthenticationService Anfragen trotzdem bearbeiten können. Er greift dazu auf eine Kopie der Datenbank-Tabellen des AuthenticationService zu, die er lokal hält. Diese lokale Datenbank-Kopie wird als Cache-Datenbank - oder einfach Cache – bezeichnet. Um das Risiko gering zu halten, dass der DMZ-Server mit veralteten Daten aus dem Cache arbeitet, sind folgende Caching-Regeln implementiert (siehe dazu auch die Caching-Parameter in Abschnitt Konfiguration der Cache-Funktion, Zusammenfassung‌).

Caching-Regeln


1. Wenn der innere Server antwortet, wird diese Antwort verwendet (Online-Modus).

2. Wenn der innere Server nicht antwortet, wird der Cache ausgewertet (Offline-Modus).

3. Beim Neustart des DMZ-Servers werden die Daten in den Cache gefüllt, indem vollständig alle Partner, Partner-Kanäle und Zertifikate im Cache gespeichert werden. Dieser Vorgang heißt Initial-Update. Er entspricht einem vollständigen Update, siehe (7).

4. Scheitert ein Initial-Update, wird es in Abständen von jeweils 2 Minuten wiederholt, bis eine konfigurierbare Anzahl an Versuchen (maxInitAttempts, Default: 12) erreicht ist.

5. Während des Betriebes wird in regelmäßiger Periode (updatePeriod, Default: 900000 ms = 15 min) der Cache-Inhalt durch ein partielles Update aktualisiert. Dabei werden nur die Datensätze erfasst, die sich geändert haben. Datensätze, die als "deleted" gekennzeichnet sind, werden dadurch auch im Cache nach einem Update als "deleted" gekennzeichnet. Datensätze, die physisch gelöscht wurden, bleiben aber im Cache erhalten. Deshalb ist in größeren Abständen zur Datenbankbereinigung ein vollständiges Update erforderlich. Veränderungen von Datensätzen werden vom inneren Integration Server sofort an alle DMZ-MessageAuthenticationService(s) durchgereicht (push).

6. Sobald der MessageAuthenticationService des DMZs erfolgreich per Message auf den inneren AuthenticationService zugegriffen hat, wird in der Antwort-Message ein Kennzeichen "syncRequired" gesetzt, falls der innere AuthenticationService modifizierte Daten hat, die der DMZ-Server noch nicht repliziert hat. Der DMZ-Server wird daraufhin eine sofortige Replikation starten. Die Update-Periode beginnt danach wieder neu. Durch den Parameter ignoreNotification kann diese Funktion abgeschaltet werden.

7. Bei einem vollständigen Update (siehe unten) wird erst geprüft, ob der innere Server erreichbar ist. Falls nicht, bleiben die Cache-Daten unverändert. Wenn der innere Server erreichbar war, wird der Cache vollständig gelöscht und danach alle Partner, Partner-Kanäle und Zertifikate wieder gespeichert. Bei konfiguriertem Einschränken des Cachings nach Channel Types (cachedChannelTypes), werden nur die erlaubten Typen übernommen. Partner, die keinen Kanal eines erlaubten Typs haben, werden nicht übernommen.

In der Zeit zwischen dem Löschen der alten Daten und dem vollständigen Speichern der neuen Daten, ist der Cache ungültig. Anfragen der Kommunikationsdienste, die in dieser Phase eintreffen und nicht online vom inneren Server beantwortet werden können, werden zeitweilig zurückgestellt (verzögert). Nach einem konfigurierbaren Timeout (cacheUpdateTimeout, Default=8000 ms) scheitern diese Anfragen dann mit einer Exception, wenn nicht inzwischen das Update fertiggestellt ist. Diese Situation kann nur eintreten, wenn während eines vollständigen Updates das Netz ausfällt und gleichzeitig eine Anfrage eines Kommunikationsdienstes eintrifft.

Im Online-Modus (bei erreichbarem innerem Server) eintreffende Anfragen werden immer vom inneren Server bearbeitet, selbst dann, wenn gleichzeitig ein vollständiges Cache-Update läuft.

Im Offline-Modus wird das vollständige Update nicht ausgeführt, so dass Anfragen aus dem unveränderten Cache beantwortet werden können. Lediglich die Situation, wenn das Netz nach dem Start eines vollständigen Update längere Zeit ausfällt, ist kritisch. Ausfälle, die kürzer als der cacheUpdateTimeout sind, werden aber auch in dieser Situation überbrückt.

8. In folgenden Fällen wird das nächste Update als vollständiges Update ausgeführt:

  • Wenn der DMZ-Server gestartet wurde (initiales Update, d. h. vollständig mit Wiederholversuch).

  • Wenn zwischenzeitlich der innere AuthenticationService neu gestartet wurde.

  • Wenn seit dem letzten vollständigen Update die fullUpdatePeriod vergangen ist.

  • Das erste Update eines Tages (nach Datumswechsel) ist immer vollständig.

9. Wenn das nächste Update (wegen einer der Regeln in Punkt 8) vollständig sein soll, aber in dieser Zeit der innere Server nicht erreichbar war, erfolgt kein unmittelbarer Wiederholversuch (außer beim Initial-Update). Stattdessen wird das Update nicht durchgeführt. Das nächste Update wird dann aber wieder als vollständiges Update eingeplant.

10. Wenn in einem DMZ-Verbund der innere Server neu gestartet wird (oder auch nur dessen AuthenticationService) werden alle DMZ-Server ihr nächstes Update vollständig einplanen.

11. Wenn in einem DMZ-Verbund ein DMZ-Server neu gestartet wird, wird nur dessen Cache vollständig aktualisiert. Die anderen DMZ-Server haben eigene Regeln.