Request Reply
Anfrage mit eindeutig zugeordneter Antwort
Die Idee und ihr Nutzen
Ein Vergleichsportal für Kfz-Versicherungen zeigt Kunden Angebote mit Preisen an. Den Preis berechnet nicht das Vergleichsportal selbst, sondern der Tarifdienst einer Versicherung, ein eigenes Programm. Das Vergleichsportal schickt dem Tarifdienst eine Anfrage als Nachricht und braucht die Antwort mit dem Preis, bevor es das Angebot anzeigen kann. Jede Anfrage trägt dabei eine eindeutige Kennung, etwa A für das erste Angebot und B für das zweite, und der Tarifdienst schickt diese Kennung mit seiner Antwort zurück. So kann das Vergleichsportal jeden Preis dem richtigen Angebot zuordnen, auch wenn mehrere Anfragen gleichzeitig unterwegs sind und die Antworten in anderer Reihenfolge eintreffen. Dieses Vorgehen heißt Request Reply, auf Deutsch Anfrage und Antwort.
Wie funktioniert es?
Das Vergleichsportal und der Tarifdienst rufen einander nicht direkt auf, sondern schicken sich Nachrichten über eine Nachrichtenplattform, ein eigenes Programm, das Nachrichten annimmt und weiterleitet. Die Nachrichtenplattform hat dafür Kanäle mit festen Namen: Was ein Programm in einen Kanal schickt, stellt die Nachrichtenplattform dem Programm zu, das diesen Kanal liest. Ein Kunde vergleicht im Vergleichsportal zwei Angebote. Für Angebot A vergibt das Vergleichsportal die Kennung A. Das Vergleichsportal trägt die Kennung in seine Liste offener Anfragen ein, in der steht, zu welchem Angebot und zu welchem Kunden jede Kennung gehört. Dann schickt das Vergleichsportal Anfrage A über den Anfragekanal, den Kanal der Nachrichtenplattform für Anfragen an den Tarifdienst. Fast gleichzeitig schickt das Vergleichsportal Anfrage B mit der Kennung B. Die Nachrichtenplattform stellt beide Anfragen über den Anfragekanal dem Tarifdienst zu. Der Tarifdienst wird mit B zuerst fertig und schickt „B: 120 €“ in den Antwortkanal, den Kanal für Antworten an das Vergleichsportal. Kurz danach schickt der Tarifdienst „A: 95 €“. Die Antworten kommen also in umgekehrter Reihenfolge beim Vergleichsportal an. Das Vergleichsportal ordnet sie nach der Kennung zu, nicht nach der Ankunft, und der Kunde sieht „Angebot A: 95 €, Angebot B: 120 €“.
Bei einem direkten Aufruf über eine Netzwerkverbindung gehört die Antwort, die auf dieser Verbindung zurückkommt, eindeutig zur gestellten Anfrage. Über die Nachrichtenplattform sind Anfrage und Antwort dagegen zwei getrennte Nachrichten. Die Antwort kommt über einen eigenen Kanal und kann Sekunden oder Minuten später eintreffen. Zuordnen lässt sich die Antwort nur, weil der Tarifdienst die Kennung unverändert in seine Antwort übernimmt. Eine Kennung, die so in der Antwort zurückkommt, heißt Correlation Identifier, auf Deutsch etwa Zuordnungskennung. A und B sind solche Correlation Identifier. Über welchen Antwortkanal die Antwort kommt, vereinbaren Vergleichsportal und Tarifdienst entweder fest, oder das Vergleichsportal nennt den Antwortkanal in jeder Anfrage. Zusätzlich legt das Vergleichsportal für jede Anfrage eine Wartefrist fest und eine Regel für Antworten, zu denen es keine offene Anfrage mehr gibt.
Request Reply sorgt nicht dafür, dass überhaupt eine Antwort kommt, dass sie rechtzeitig kommt oder dass sie nur einmal kommt. Kommt innerhalb der Wartefrist keine Antwort für A, schließt das Vergleichsportal Angebot A ab und zeigt dem Kunden „Preis nicht verfügbar“. Trifft „A: 95 €“ danach doch noch ein, erkennt das Vergleichsportal an der Kennung, dass es keine offene Anfrage A mehr gibt. Das Vergleichsportal ändert das abgeschlossene Angebot deshalb nicht unbemerkt, sondern verwirft die verspätete Antwort oder bietet dem Kunden ausdrücklich eine neue Anfrage an. Ebenso erkennt das Vergleichsportal an der Kennung eine Antwort, die doppelt eintrifft, und behandelt sie nach derselben Regel wie eine verspätete Antwort. Eine ausgebliebene Antwort bedeutet nicht, dass der Tarifdienst die Anfrage nicht erhalten oder nicht berechnet hat. Schickt das Vergleichsportal die Anfrage erneut, berechnet der Tarifdienst den Preis womöglich ein zweites Mal. Bei einer Preisberechnung schadet das nicht. Verändert eine Anfrage dagegen einen Vertrag, muss der Empfänger eine wiederholte Anfrage mit derselben Kennung erkennen.
Request-Reply: Antworten werden über die Kennung zugeordnet
Wann ist es sinnvoll und wann nicht?
Request Reply lohnt sich
- Zwei Programme tauschen Nachrichten über eine Nachrichtenplattform aus, und eines der beiden braucht zu jeder Anfrage die zugehörige Antwort, so wie das Vergleichsportal zu jeder Anfrage den Preis vom Tarifdienst. Ohne Kennung weiß das Vergleichsportal nicht, zu welcher Anfrage eine eintreffende Antwort gehört.
- Das Vergleichsportal fragt für viele Kunden gleichzeitig Preise an. Es schickt jede Anfrage ab und arbeitet weiter, statt auf jede einzelne Berechnung zu warten. Weil die Berechnungen unterschiedlich lange dauern, kommen die Antworten oft in anderer Reihenfolge an als die Anfragen. Ordnet das Vergleichsportal die Antworten nach ihrer Ankunft zu, kann zum Beispiel die Antwort für den zweiten Kunden zuerst ankommen und beim Angebot des ersten Kunden erscheinen.
- Der Tarifdienst ist zeitweise überlastet oder kurz nicht erreichbar. Bei einem direkten Aufruf würde jede Anfrage des Vergleichsportals in dieser Zeit scheitern. Die Nachrichtenplattform nimmt die Anfragen des Vergleichsportals trotzdem an. Die Nachrichtenplattform stellt die Anfragen zu, sobald der Tarifdienst wieder Anfragen bearbeiten kann.
Request Reply ist nicht das Richtige
- Niemand erwartet eine Antwort. Ein Beispiel ist die Mitteilung „Vertrag wurde gekündigt“. Es gibt dann keine Antwort, die einer Anfrage zugeordnet werden müsste. Dann veröffentlicht der Absender die Mitteilung nach Publish Subscribe, und jedes Programm, das sich für solche Mitteilungen angemeldet hat, erhält eine Kopie. Kennung, Liste offener Anfragen, Wartefrist und Antwortkanal entfallen.
- Der Tarifdienst ist zuverlässig direkt erreichbar, und die Antwort wird sofort gebraucht, während der Kunde wartet. Eine Nachrichtenplattform, die Anfragen bei einer Überlastung des Tarifdienstes aufbewahrt, braucht das Vergleichsportal dann nicht. Stattdessen ruft das Vergleichsportal den Tarifdienst direkt über eine Netzwerkverbindung auf, zum Beispiel über eine Schnittstelle nach REST, und wartet auf dieser Verbindung auf die Antwort. Die Antwort gehört eindeutig zu diesem Aufruf, und Kennung, Liste offener Anfragen und Nachrichtenplattform entfallen.
- Es ist immer nur eine einzige Anfrage unterwegs, und eine Nachrichtenplattform gibt es noch nicht. Die Kennung hätte dann keine Antworten zu unterscheiden, und für diesen einen Austausch müsste erst eine Nachrichtenplattform eingeführt werden. Dann ruft das Vergleichsportal den Tarifdienst direkt auf. Niemand muss eine Nachrichtenplattform betreiben und überwachen, die nur diesen einen Austausch trägt.
- Dieselbe Anfrage soll an mehrere Tarifdienste gehen, und das Vergleichsportal soll die Antworten sammeln. Dann verteilt das Vergleichsportal die Anfrage nach Scatter Gather an alle Tarifdienste, sammelt die Antworten bis zu einer gemeinsamen Frist und zeigt sie zusammen an. Request Reply allein ordnet nur jede Antwort ihrer Anfrage zu und legt nicht fest, wann das Sammeln endet.
Nachteile und typische Fehler
Im Vergleich zu einem direkten Aufruf ist der Ablauf schwerer nachzuvollziehen, weil Anfrage und Antwort zwei getrennte Nachrichten sind. Wer einen falschen Preis untersucht, muss Anfrage und Antwort über die Kennung im Anfragekanal und im Antwortkanal zusammensuchen. Die Nachrichtenplattform mit Anfragekanal und Antwortkanal muss betrieben und überwacht werden. Darf keine Antwort verloren gehen, muss das Vergleichsportal seine Liste offener Anfragen dauerhaft speichern und nicht nur im Arbeitsspeicher halten, damit die Liste einen Neustart übersteht. Die Wartefrist muss zur üblichen Rechenzeit des Tarifdienstes passen: Ist sie zu kurz, sehen Kunden unnötig „Preis nicht verfügbar“. Ist sie zu lang, warten die Kunden lange auf ein Angebot.
Typische Fehler und woran man sie erkennt:
- Zuordnung nach Ankunft: Das Vergleichsportal ordnet Antworten in der Reihenfolge ihres Eintreffens zu statt nach der Kennung. Kommt „B: 120 €“ zuerst an, zeigt das Vergleichsportal die 120 € bei Angebot A an. Erkennbar ist das an Beschwerden über Preise, die nicht zum eingegebenen Fahrzeug passen.
- Verlorene Liste offener Anfragen: Das Vergleichsportal hält die Liste nur im Arbeitsspeicher und startet neu, während Anfragen offen sind. Danach eintreffende Antworten lassen sich keinem Angebot mehr zuordnen. Erkennbar ist das an Antworten ohne passende offene Anfrage kurz nach einem Neustart.
- Verspätete Antwort ändert Abgeschlossenes: Das Vergleichsportal trägt eine Antwort nach Ablauf der Wartefrist noch beim schon abgeschlossenen Angebot ein. Der Kunde hat dann „Preis nicht verfügbar“ gesehen, und später steht doch ein Preis da. Erkennbar ist das an Angeboten, deren Preis nach ihrem Abschluss geändert wurde.
- Kennung nicht eindeutig: Das Vergleichsportal läuft in mehreren Exemplaren desselben Programms gleichzeitig. Das geht, weil jedes Exemplar jeden Kunden bedienen kann. Alle Exemplare lesen denselben Antwortkanal. Jedes Exemplar zählt seine Kennungen ab 1 hoch, und so tragen zwei Anfragen verschiedener Exemplare dieselbe Kennung 17. Die Nachrichtenplattform stellt die Antwort auf die Anfrage 17 von Exemplar 1 an Exemplar 2 zu. Exemplar 2 findet die Kennung 17 in seiner eigenen Liste offener Anfragen und zeigt den Preis beim falschen Angebot an. Erkennbar ist das an doppelt vergebenen Kennungen in den Protokollen.
- Kein Antwortkanal vereinbart: Der Tarifdienst kennt den Antwortkanal nicht, weil der Antwortkanal weder fest vereinbart ist noch in der Anfrage steht. Die Antworten kommen nie beim Vergleichsportal an, und jede Anfrage läuft in die Wartefrist. Erkennbar ist das daran, dass alle Angebote „Preis nicht verfügbar“ zeigen, obwohl der Tarifdienst rechnet.
Weiterführend
Verwandte Ansätze
- Correlation Identifier: beschreibt die eindeutige Kennung, die der Empfänger in seine Antwort übernimmt, und ihre Nutzung bei der Fehlersuche.
- Messaging: beschreibt den Austausch von Nachrichten über eine Nachrichtenplattform, auf dem Request Reply aufbaut.
- Synchronous versus Asynchronous Communication: wägt ab zwischen einem direkten Aufruf, bei dem der Aufrufer wartet, und einer Nachricht, nach der er weiterarbeitet.
- Timeout: legt fest, wie lange ein Aufrufer höchstens auf eine Antwort wartet. Die Wartefrist des Vergleichsportals ist ein solcher Timeout.
Quellen
- Gregor Hohpe, Bobby Woolf: Request-Reply: beschreibt Anfrage und Antwort als zwei Nachrichten auf getrennten Kanälen und die Möglichkeiten des Absenders, auf die Antwort zu warten oder sie später zu verarbeiten.
- Gregor Hohpe, Bobby Woolf: Correlation Identifier: beschreibt, wie der Absender eine Kennung mitschickt, der Empfänger sie in die Antwort übernimmt und der Absender damit offene Anfragen zuordnet.