Enterprise Experte

Message-Driven Bean vs. Reactive Messaging

Ersetze JMS-Message-Driven-Beans durch MicroProfile Reactive Messaging für einfachere Ereignisverarbeitung.

✕ Java EE
@MessageDriven(activationConfig = {
    @ActivationConfigProperty(
        propertyName = "destinationType",
        propertyValue = "jakarta.jms.Queue"),
    @ActivationConfigProperty(
        propertyName = "destination",
        propertyValue = "java:/jms/OrderQueue")
})
public class OrderMDB implements MessageListener {
    @Override
    public void onMessage(Message message) {
        TextMessage txt = (TextMessage) message;
        processOrder(txt.getText());
    }
}
✓ MicroProfile 4+
@ApplicationScoped
public class OrderProcessor {
    @Incoming("orders")
    public void process(Order order) {
        // automatically deserialized from
        // the "orders" channel
        fulfillOrder(order);
    }
}
Problem mit diesem Code entdeckt? Sag uns Bescheid.
🪶

Minimaler Code

Eine einzige @Incoming-Methode ersetzt die MDB-Klasse, das MessageListener-Interface und die Aktivierungskonfiguration.

🔌

Broker-agnostisch

Tausche Kafka-, AMQP- oder JMS-Connectoren per Konfiguration aus, ohne den Anwendungscode zu ändern.

☁️

Cloud-native geeignet

Reaktive Streams-Gegendruck und leichtgewichtige Laufzeit machen es ideal für containerisierte Deployments.

Alter Ansatz
Message-Driven Bean
Moderner Ansatz
Reactive Messaging
Seit JDK
11
Schwierigkeitsgrad
Experte
Message-Driven Bean vs. Reactive Messaging
Verfügbar

Verfügbar seit MicroProfile 4.0 / SmallRye Reactive Messaging

Message-Driven Beans erfordern die Implementierung von MessageListener, die Konfiguration von Aktivierungseigenschaften und die manuelle Deserialisierung von JMS-Nachrichten. MicroProfile Reactive Messaging verwendet eine einfache @Incoming-Annotation an einer Methode, die typisierte Objekte direkt empfängt. Die Kanal-Konfiguration wird ausgelagert, was den Code broker-agnostisch und wesentlich einfacher zu testen macht.

Teilen 𝕏 🦋 in