Asynchrone Integration · Prio 9 · Version 4

Message Queue / JMS / IBM MQ

Entkopplung ueber Queues, garantierte Zustellung, Dead Letter Queues, Retry, Reihenfolge und idempotente Verarbeitung.

← Startseite
0 Treffer
Kurzverständnis und Systemgrenze

Asynchrone Integration ist ein typisches Herzstueck gewachsener Enterprise-Landschaften. MQ entkoppelt Systeme, schuetzt Backends vor Lastspitzen und erlaubt Wiederanlauf. Gleichzeitig macht es Ursache-Wirkung schwerer sichtbar.

JMS-Code sieht oft einfach aus: Nachricht empfangen, verarbeiten, bestaetigen. Die echten Fragen sind aber: Was passiert bei Timeout? Ist die Verarbeitung idempotent? Wie erkennt der Fachbereich haengende Nachrichten? Was passiert mit Poison Messages?

Modernisierung muss Queue-Semantik erhalten. Ein Wechsel auf Kafka, RabbitMQ oder Cloud Messaging ist kein reines Tool-Thema, sondern betrifft Ordering, Transaktionsgrenzen, Retention, Reprocessing und fachlichen Ausgleich.

Daten- und Verantwortungsgrenze: Queue-Systeme besitzen nicht die Fachlogik, aber sie besitzen zeitliche Entkopplung und Zustellgarantie. Fachlicher Schaden entsteht, wenn Nachrichten doppelt, zu spaet, in falscher Reihenfolge oder ohne idempotente Verarbeitung ankommen.
Fachliche und technische Darstellung
Fachliche Sicht Message Queue / JMS / IBM MQ
Fachliche Sicht: Prozess, Verantwortung, Nachweis.
Technische Sicht Message Queue / JMS / IBM MQ
Technische Sicht: Komponenten, Protokolle, Betriebsbezug.
Wichtige Begriffe und Artefakte

Point-to-Point Queue

Eine Nachricht wird von genau einem Consumer verarbeitet.

Backout Queue

Ablage nach mehrfach fehlgeschlagener Verarbeitung.

DLQ

Dead Letter Queue fuer unzustellbare Nachrichten.

Idempotency Key

Fachlicher Schluessel, der doppelte Verarbeitung verhindert.

Typischer Ablauf Schritt für Schritt
  1. Monolith schreibt Datenbank und sendet Ereignis an Queue.
  2. MQ speichert Nachricht dauerhaft und entkoppelt Sender und Empfaenger.
  3. MDB oder Listener konsumiert Nachricht in Transaktion.
  4. Consumer prueft Idempotency und fuehrt Folgeaktion aus.
  5. Bei Fehler wird Retry, Backout oder manuelle Klaerung ausgeloest.
Ausführliche Praxisbeispiele mit Code und Konfiguration

Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.

Message Driven Bean mit Idempotenzpruefung
@MessageDriven(activationConfig = {
  @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "jms/InvoiceEvents"),
  @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
public class InvoiceEventConsumer implements MessageListener {
    @EJB private ProcessedMessageRepository processed;
    @EJB private ShippingService shippingService;

    public void onMessage(Message message) {
        String eventId = message.getStringProperty("eventId");
        if (processed.alreadyHandled(eventId)) {
            return; // Idempotent Consumer Pattern
        }
        InvoiceCreated event = InvoiceCreated.fromJson(message.getBody(String.class));
        shippingService.prepareDocuments(event.invoiceId());
        processed.markHandled(eventId);
    }
}
SQL fuer Idempotency-Tabelle
CREATE TABLE PROCESSED_MESSAGE (
  EVENT_ID        VARCHAR2(80) PRIMARY KEY,
  CONSUMER_NAME   VARCHAR2(80) NOT NULL,
  PROCESSED_AT    TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
  BUSINESS_KEY    VARCHAR2(80) NOT NULL
);
MQ Betriebsnotiz als Runbook-Ausschnitt
queue: BILLING.INVOICE.EVENTS
backoutQueue: BILLING.INVOICE.BOQ
deadLetterQueue: SYSTEM.DEAD.LETTER.QUEUE
alerting:
  queueDepthWarning: 1000
  oldestMessageAgeWarning: 15m
manual-action:
  - pruefe Correlation-ID im Billing-Log
  - pruefe PROCESSED_MESSAGE auf doppelte Event-ID
  - entscheide Requeue oder fachliche Korrektur
Risiken, Fehlerbilder und Diagnose
AspektBeschreibung
Fachliches RisikoUnklare Verantwortung fuer Ereignis fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem.
Technisches RisikoJMS und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen.
BetriebsrisikoFehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert.
MigrationsrisikoNeue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern.
Typische Fallen:
  • Nachrichten enthalten unvollstaendige Fachkontexte und erfordern DB-Nachlesen mit Race Conditions.
  • Doppelte Nachrichten erzeugen doppelte Rechnungen, Buchungen oder Versandauftraege.
  • DLQ wird technisch ueberwacht, aber fachlich nicht bearbeitet.
  • Queue-Depth-Alarm fehlt oder wird erst erkannt, wenn Nachtbatch nicht fertig wird.
Modernisierungspfad und geeignete Entwurfsmuster
PatternEinsatz in diesem System
Strangler Fig PatternNeue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen.
Anti-Corruption LayerAltbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen.
FacadeKomplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln.
AdapterProtokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen.
Golden Master TestBestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen.
Empfohlene Schritte:
  • Fuehre Idempotent Consumer konsequent ein.
  • Dokumentiere Queue-Vertrag: Payload, Header, Correlation-ID, Retry, Ordering, DLQ.
  • Nutze Outbox Pattern, wenn DB-Commit und Event-Publikation zusammenhaengen.
  • Migriere Queue fuer Queue mit Shadow Consumer und Reprocessing-Plan.
Analysefragen für echte Projekte
  • Wer besitzt fachlich die Wahrheit fuer Ereignis?
  • Welche technische Komponente ist kritisch: JMS, IBM MQ, MDB?
  • Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
  • Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
  • Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
  • Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
  • Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
  • Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung

Erstelle fuer eine Queue eine Betriebs- und Fachsicht: Wer sendet, wer empfaengt, welche Header existieren, welcher Idempotenzschluessel gilt, wann wird wiederholt, wann landet etwas in DLQ, wer entscheidet ueber Requeue?

⌂ Cockpit