Softwarearchitektur verstehen und entscheiden

Aaron KreisÜber mich
Nachrichten und Ereignisse

Claim Check

Große Inhalte auslagern und nur einen Verweis senden

Die Idee und ihr Nutzen

Ein Kunde einer Versicherung meldet einen Sturmschaden und lädt zwölf Fotos mit zusammen 45 Megabyte hoch. Der Meldedienst, der die Meldung annimmt, muss andere Programme mit einer Nachricht darüber informieren, darunter einen Statistikdienst und einen Gutachterdienst. Die Nachrichtenplattform, die solche Nachrichten verteilt, ist aber für viele kleine Nachrichten gebaut und begrenzt die Größe einer Nachricht. Statt die Fotos in die Nachricht zu packen, legt der Meldedienst sie deshalb in einem Objektspeicher ab, einem eigenen Speicher für Dateien. Der Meldedienst verschickt nur eine kleine Nachricht mit Schadenart, Datum und zwölf Verweisen, also den Adressen, unter denen die Fotos liegen. Wer die Fotos braucht, holt sie beim Objektspeicher ab. Dieses Vorgehen heißt Claim Check, englisch für Abholschein.

Bausteine: Meldedienst: nimmt die Meldung mit 12 Fotos an; Objektspeicher: hält die Fotos, prüft Leserechte; Nachrichtenplattform: verteilt die kleine Nachricht; Gutachterdienst: braucht die Fotos. Verbindungen: Meldedienst → Objektspeicher (Fotos, 45 MB); Meldedienst → Nachrichtenplattform (Nachricht mit 12 Verweisen); Nachrichtenplattform → Gutachterdienst; Objektspeicher → Gutachterdienst (Fotos, 45 MB). Die Fotos liegen im Objektspeicher; die Nachricht trägt nur Verweise auf die Fotos.

Wie funktioniert es?

Der Kunde meldet den Sturmschaden 4711 an seinem Dach und lädt zwölf Fotos mit zusammen 45 Megabyte beim Meldedienst hoch. Der Meldedienst legt die Fotos im Objektspeicher ab und erhält für jedes Foto einen Verweis zurück. Erst nachdem das Ablegen gelungen ist, verschickt der Meldedienst über die Nachrichtenplattform die Nachricht „Schaden 4711 gemeldet“ mit Schadenart Sturm, Schadendatum und den zwölf Verweisen. So verweist keine Nachricht auf ein Foto, das noch fehlt. Die Nachricht ist nur etwa drei Kilobyte groß. Die Nachrichtenplattform verteilt die Nachricht an den Statistikdienst und an den Gutachterdienst. Der Statistikdienst liest Schadenart und Datum, zählt einen weiteren Sturmschaden und lädt keine Fotos. Der Gutachterdienst liest die zwölf Verweise und fragt die Fotos beim Objektspeicher an. Der Objektspeicher prüft, ob der Gutachterdienst die Fotos lesen darf, und liefert ihm die zwölf Fotos. Mit den Fotos bewertet der Gutachterdienst den Schaden. Die großen Datenmengen fließen so nur einmal vom Kunden in den Objektspeicher und einmal zum Gutachterdienst, statt an jeden Empfänger der Nachricht. Nach der festgelegten Frist von zwei Jahren löscht der Objektspeicher die Fotos. Das IT-Team der Versicherung hat die Frist so gewählt, dass ein Sturmschaden bis dahin gewöhnlich abgeschlossen ist und kein Empfänger die Fotos mehr braucht.

Meldedienst, Statistikdienst und Gutachterdienst sind getrennte Programme, die sich nicht direkt aufrufen. Sie tauschen Nachrichten aus, also kleine Datenpakete, die ein Programm über die Nachrichtenplattform an andere Programme schickt. Der Meldedienst legt dabei nicht fest, welche Programme seine Nachrichten lesen; neue Empfänger können sich jederzeit an der Nachrichtenplattform anmelden. Bei manchen Nachrichtenplattformen liegt die voreingestellte Größengrenze bei etwa einem Megabyte. Jeder Empfänger entscheidet selbst, ob er den großen Inhalt überhaupt braucht.

Für das Löschen braucht es eine feste Regel wie die Frist von zwei Jahren. Die Regel „löschen, wenn alle Empfänger den Inhalt abgeholt haben“ funktioniert nur, wenn sicher feststeht, welche Empfänger den Inhalt noch brauchen. Weil sich jederzeit neue Empfänger anmelden können, steht das selten fest. Abgelegte Fotos sollten nicht mehr verändert werden, damit alle Empfänger dieselben Fotos erhalten, die der Meldedienst abgelegt hat. Dass ein Empfänger die Fotos später auch erhält, garantiert Claim Check nicht. Ist der Objektspeicher ausgefallen oder wurde ein Foto schon gelöscht, kommt die kleine Nachricht trotzdem an, aber der Objektspeicher liefert unter dem Verweis kein Foto. Ablegen und Versenden sind außerdem zwei getrennte Vorgänge in zwei Systemen. Scheitert einer der beiden Vorgänge, wird der andere nicht automatisch rückgängig gemacht. Scheitert zum Beispiel das Versenden der Nachricht, bleiben die zwölf Fotos trotzdem im Objektspeicher liegen.

Claim Check: Fotos im Speicher, kleine Nachricht im Kanal

Beteiligte: Kunde: meldet Sturmschaden 4711 mit 12 Fotos, 45 MB; Meldedienst: legt Fotos ab und sendet eine kleine Nachricht; Objektspeicher: hält die Fotos, prüft Leserechte, löscht nach 2 Jahren; Nachrichtenplattform: verteilt die kleine Nachricht; Statistikdienst: braucht nur Schadenart und Datum; Gutachterdienst: braucht die Fotos. Ablauf: 1. Der Kunde meldet den Sturmschaden 4711 am Dach und lädt zwölf Fotos mit zusammen 45 Megabyte hoch. 2. Der Meldedienst legt die zwölf Fotos im Objektspeicher ab. 3. Der Meldedienst erhält für jedes Foto einen Verweis, also eine Adresse, unter der das Foto liegt. 4. Der Meldedienst schickt über die Nachrichtenplattform die Nachricht „Schaden 4711 gemeldet“ mit Schadenart, Datum und den zwölf Verweisen, aber ohne Fotos. 5. Der Statistikdienst zählt einen Sturmschaden und lädt keine Fotos. 6. Der Gutachterdienst liest die zwölf Verweise. 7. Der Gutachterdienst fragt die Fotos beim Objektspeicher an. Der Objektspeicher prüft, ob der Gutachterdienst die Fotos lesen darf. 8. Der Objektspeicher liefert die zwölf Fotos an den Gutachterdienst. Die großen Datenmengen fließen nur einmal in den Objektspeicher und einmal zum Gutachterdienst, nicht an jeden Empfänger.

Wann ist es sinnvoll und wann nicht?

Ein Claim Check lohnt sich

  • Nachrichten haben regelmäßig große Anhänge wie Fotos oder Dokumente. Packt der Meldedienst die zwölf Fotos direkt in die Nachricht, wird sie 45 Megabyte groß. Die Nachricht überschreitet dann die Größengrenze der Nachrichtenplattform oder verlangsamt die Nachrichtenplattform für alle anderen Nachrichten.
  • Nur einige Empfänger brauchen den großen Inhalt. Der Gutachterdienst braucht die Fotos, der Statistikdienst kommt mit Schadenart und Datum aus. Ohne Claim Check erhielte auch der Statistikdienst die Fotos, die er nie ansieht, und Speicher und Netz würden mit Daten belastet, die er nicht braucht.
  • Sensible Inhalte sollen nicht über die Nachrichtenplattform laufen, sondern nur in einem besonders geschützten Speicher mit eigener Zugriffsprüfung liegen. Ohne Claim Check stecken die Fotos in jeder Nachricht, und jedes Programm, das die Nachrichtenplattform überwacht, kann sie sehen. Mit Claim Check sehen diese Programme nur die Verweise.

Ein Claim Check ist nicht das Richtige

  • Die Nachrichten sind klein, etwa eine Schadenmeldung ohne Fotos mit Schadenart, Datum und einer kurzen Beschreibung. Eine solche Nachricht bleibt weit unter der Größengrenze und verlangsamt die Nachrichtenplattform nicht. Dann schickt der Sender den ganzen Inhalt in der Nachricht mit. Jeder Empfänger erhält alles mit dieser einen Nachricht, und die zusätzliche Anfrage beim Objektspeicher über das Netz entfällt.
  • Jeder Empfänger braucht den vollständigen Inhalt sofort, und die Nachrichtenplattform kann ihn innerhalb ihrer Größengrenze übertragen. Mit Claim Check müsste dann jeder Empfänger den Inhalt zusätzlich beim Objektspeicher abholen, und keinem Empfänger bliebe eine Übertragung erspart. Stattdessen schickt der Sender den Inhalt ebenfalls in der Nachricht mit. Das IT-Team muss dann keinen Objektspeicher betreiben, sichern und überwachen und keine Zugriffsrechte und Löschfristen dafür verwalten.
  • Die Empfänger dürfen oder können keinen Zugang zum Objektspeicher bekommen. Ein Beispiel sind Empfänger, die außerhalb des eigenen Netzes laufen und nur die Nachrichtenplattform erreichen. Diese Empfänger können die Verweise nicht einlösen. Dann schickt der Sender den Inhalt über die Nachrichtenplattform mit, auch wenn er einen großen Inhalt dafür in mehrere Nachrichten zerlegen muss. So erhalten diese Empfänger den Inhalt auf dem einzigen Weg, den sie erreichen.
  • Der Inhalt liegt nur knapp über der Größengrenze, und jeder Empfänger braucht ihn ganz. Dann komprimiert der Sender den Inhalt, verkleinert ihn also so, dass der Empfänger ihn wiederherstellen kann, und schickt ihn in der Nachricht mit. Oder der Sender zerlegt den Inhalt in mehrere kleine Nachrichten. Der Empfänger setzt die Teile wieder zusammen und prüft dabei Reihenfolge und Vollständigkeit der Teile. Beide Wege kommen ohne den Objektspeicher als zweites System aus.

Nachteile und typische Fehler

Zur Nachrichtenplattform kommt mit dem Objektspeicher ein zweites System hinzu, das das IT-Team betreiben, sichern und überwachen muss. Jeder Abruf eines Fotos ist eine zusätzliche Anfrage über das Netz und verlängert die Verarbeitung beim Gutachterdienst. Das IT-Team muss eine Löschfrist festlegen und durchsetzen. Wird ein Inhalt nie gelöscht, wächst der Speicher unbegrenzt. Jeder Empfänger, der Inhalte holen soll, braucht eigene Zugriffsrechte im Objektspeicher, und diese Zugriffsrechte müssen zusätzlich verwaltet werden. Sender und Empfänger hängen außerdem nicht nur von der Nachrichtenplattform ab, sondern auch von der Form der Verweise und vom Zugang zum Objektspeicher. Ändert das IT-Team zum Beispiel die Form der Verweise, muss auch der Gutachterdienst angepasst werden, damit er die Fotos weiter abrufen kann.

Typische Fehler und woran man sie erkennt:

  • Zu früh gelöschte Fotos: Ein Sturmschaden ist nach zwei Jahren noch nicht abgeschlossen, zum Beispiel weil der Kunde gegen die Bewertung klagt. Der Objektspeicher löscht die Fotos trotzdem nach der Frist von zwei Jahren. Fragt der Gutachterdienst die Fotos danach für eine neue Bewertung noch einmal an, findet der Objektspeicher sie nicht mehr. Erkennbar ist das an Abrufen beim Objektspeicher, die mit „nicht gefunden“ beantwortet werden.
  • Verwaiste Fotos: Das Versenden der Nachricht scheitert, nachdem die Fotos schon gespeichert sind. Im Objektspeicher bleiben Fotos zurück, auf die keine Nachricht verweist. Erkennbar ist das an Dateien im Objektspeicher, zu denen es keine Schadennummer in den Nachrichten gibt.
  • Nachricht vor dem Ablegen: Der Meldedienst verschickt die Nachricht, bevor das Ablegen der Fotos abgeschlossen ist. Der Gutachterdienst fragt ein Foto an, das noch nicht oder gar nicht im Objektspeicher liegt. Erkennbar ist das an fehlgeschlagenen Abrufen kurz nach dem Eingang einer Nachricht, die bei einem späteren Versuch gelingen.
  • Fehlende Leserechte: Ein neuer Empfänger meldet sich an der Nachrichtenplattform an, hat aber kein Leserecht im Objektspeicher. Der neue Empfänger erhält die Nachrichten, aber keine Fotos. Erkennbar ist das an abgelehnten Abrufen eines einzelnen Empfängers.
  • Nachträglich geänderter Inhalt: Der Gutachterdienst hat die zwölf Fotos abgerufen und den Schaden bewertet. Danach lädt der Kunde ein Foto noch einmal hoch, und der Meldedienst überschreibt das alte Foto im Objektspeicher unter demselben Verweis. Ruft der Gutachterdienst die Fotos für eine Nachprüfung erneut ab, erhält er über denselben Verweis ein anderes Bild. Erkennbar ist das an abweichenden Ergebnissen für denselben Schaden.

Weiterführend

Verwandte Ansätze

  • Messaging: beschreibt den Austausch von Nachrichten über eine Nachrichtenplattform, die durch die kleinen Nachrichten entlastet wird.
  • Publish Subscribe: Eine Nachricht geht an viele Empfänger, von denen oft nur einige den großen Inhalt brauchen.
  • Event Driven Architecture: Bauweise, in der Programme über Ereignisnachrichten zusammenarbeiten. Die Ereignisse bleiben klein, große Anhänge liegen daneben im Speicher.

Werkzeuge und Umsetzungen

Apache Camel und Spring Integration setzen den Ablauf mit Ablegen, Verweis und späterem Abholen um. Ein Objektspeicher hält die ausgelagerten Inhalte; um Verweise, Zugriffsrechte und Aufräumen muss sich das IT-Team zusätzlich kümmern.

  • Apache Camel: enthält Claim Check als fertigen Baustein für Nachrichtenabläufe.
  • Spring Integration: bietet das Claim-Check-Muster mit einem austauschbaren Speicher für die ausgelagerten Inhalte.
  • Ceph: verteiltes Speichersystem, das unter anderem einen Objektspeicher für große Dateien bereitstellt.
  • MinIO: Objektspeicher mit der verbreiteten Schnittstelle von Amazon S3. Der Quellcode steht unter der Open-Source-Lizenz AGPL. Der Hersteller hat das öffentliche Repository, also die frei zugängliche Ablage des Quellcodes, im April 2026 archiviert. Das Repository wird also nicht mehr weiterentwickelt, und fertige Programmpakete gibt es dafür nicht mehr. Für neue Vorhaben sollte das IT-Team deshalb Alternativen oder die Ausgaben des Herstellers prüfen.

Quellen

  • Gregor Hohpe, Bobby Woolf: Claim Check: Originalbeschreibung aus dem Buch „Enterprise Integration Patterns“; sie legt dar, wie nicht sofort benötigte Daten in einem dauerhaften Speicher abgelegt werden und die Nachricht nur einen Schlüssel dafür trägt.
  • Microsoft: Claim Check Pattern: beschreibt den Ablauf und behandelt Löschfristen, Zugriffsschutz, die fehlende gemeinsame Bestätigung von Ablegen und Versenden sowie die Verfügbarkeit des Speichers.