© Excellent backgrounds/Shutterstock.com
Java Magazin
Elegante Einbindung in Java-EE-Umgebungen

RabbitMQ und CDI

RabbitMQ erfreut sich im Markt der leichtgewichtigen Message Broker zunehmend wachsender Beliebtheit. Die Kombination aus Simplizität und Robustheit machen den Broker besonders in kleinen und mittleren Unternehmen zu einer ernstzunehmenden Alternative zu etablierten Messaging-Plattformen. Dieser Artikel stellt vor, wie mithilfe von CDI eine elegante Einbindung von RabbitMQ insbesondere in Java-EE-Umgebungen implementiert werden kann.

Christian Bick


RabbitMQ ist eine Open-Source-Message-Broker-Software, die das Advanced Message Queuing Protocol (AMQP) implementiert. Mithilfe dieser Middleware ist das Zusammenspiel von Komponenten einer Event-driven-Architektur über verschiedene Plattformen hinweg deutlich einfacher geworden: Zusammen mit einer aktiven Community hat die Firma VMware Clients für die meisten gängigen Programmiersprachen hervorgebracht. RabbitMQ präsentiert sich damit insbesondere in einer heterogenen, Java-dominierten Systemlandschaft als interessante Option gegenüber dem klassischen JMS-Ansatz.

Der bereits angesprochene Java-Client von VMware ist sehr robust und unterstützt das vollständige Featureset von RabbitMQ. Dessen ungeachtet ist die Integration in Java EE suboptimal, was u. a. daran liegt, dass sich deutlich zu viele technische Details im fachlichen Teil des Codes befinden und – im Gegensatz zu JMS – kein standardisierter Weg der Broker-Konfiguration existiert. Diese Nachteile der RabbitMQ Middleware können aber behoben werden.

Der naive Ansatz, JMS mit RabbitMQ zu verbinden, führt schnell zu unerfreulichen Kompromissen. Besonders heikel wird es bei dem Versuch, die verschiedenen Philosophien hinter Transaktionen zu integrieren: Während bei AMQP und somit auch bei RabbitMQ Transaktionen am Broker enden, können sie bei JMS mehrere Clients überspannen. Unter solchen Voraussetzungen erscheint es wenig erstrebenswert, diesen Ansatz weiterzuverfolgen.

Es existieren durchaus weitere Möglichkeiten, z. B. mithilfe von Spring-Integration eine Brücke zwischen JMS und AMQP zu schlagen, doch alle haben signifikante Nachteile, sodass es sich lohnt, über Alternativen jenseits von JMS nachzudenken. Mit der Etablierung von Java EE 6 und der damit verbundenen Auseinandersetzung mit CDI (Contexts and Dependency Injection) entsprang deshalb die Überlegung, CDI Events als Ausgangspunkt für die Integration von RabbitMQ in Java EE zu nutzen.

Die Idee hinter diesem Ansatz ist folgende: CDI Events werden für das Publizieren zum Broker und das Konsumieren vom selbigen an die entsprechenden Broker-Entitäten gebunden. Bei AMQP 0.9.1 werden zum Publizieren Exchanges in Verbindung mit Routing Keys genutzt, während Queues als Quellen der Konsumenten dienen. Abbildung 1 veranschaulicht, wie CDI Events mithilfe von RabbitMQ über Applikationsgrenzen hinweg ausgetauscht werden.

Abb. 1: Austauschen von CDI Events

Werden in der Applikation CDI Events gefeuert (1), so wird für zuvor gebundene Events (2) eine AMQP-Nach...

Java Magazin
Elegante Einbindung in Java-EE-Umgebungen

RabbitMQ und CDI

RabbitMQ erfreut sich im Markt der leichtgewichtigen Message Broker zunehmend wachsender Beliebtheit. Die Kombination aus Simplizität und Robustheit machen den Broker besonders in kleinen und mittleren Unternehmen zu einer ernstzunehmenden Alternative zu etablierten Messaging-Plattformen. Dieser Artikel stellt vor, wie mithilfe von CDI eine elegante Einbindung von RabbitMQ insbesondere in Java-EE-Umgebungen implementiert werden kann.

Christian Bick


RabbitMQ ist eine Open-Source-Message-Broker-Software, die das Advanced Message Queuing Protocol (AMQP) implementiert. Mithilfe dieser Middleware ist das Zusammenspiel von Komponenten einer Event-driven-Architektur über verschiedene Plattformen hinweg deutlich einfacher geworden: Zusammen mit einer aktiven Community hat die Firma VMware Clients für die meisten gängigen Programmiersprachen hervorgebracht. RabbitMQ präsentiert sich damit insbesondere in einer heterogenen, Java-dominierten Systemlandschaft als interessante Option gegenüber dem klassischen JMS-Ansatz.

Der bereits angesprochene Java-Client von VMware ist sehr robust und unterstützt das vollständige Featureset von RabbitMQ. Dessen ungeachtet ist die Integration in Java EE suboptimal, was u. a. daran liegt, dass sich deutlich zu viele technische Details im fachlichen Teil des Codes befinden und – im Gegensatz zu JMS – kein standardisierter Weg der Broker-Konfiguration existiert. Diese Nachteile der RabbitMQ Middleware können aber behoben werden.

Der naive Ansatz, JMS mit RabbitMQ zu verbinden, führt schnell zu unerfreulichen Kompromissen. Besonders heikel wird es bei dem Versuch, die verschiedenen Philosophien hinter Transaktionen zu integrieren: Während bei AMQP und somit auch bei RabbitMQ Transaktionen am Broker enden, können sie bei JMS mehrere Clients überspannen. Unter solchen Voraussetzungen erscheint es wenig erstrebenswert, diesen Ansatz weiterzuverfolgen.

Es existieren durchaus weitere Möglichkeiten, z. B. mithilfe von Spring-Integration eine Brücke zwischen JMS und AMQP zu schlagen, doch alle haben signifikante Nachteile, sodass es sich lohnt, über Alternativen jenseits von JMS nachzudenken. Mit der Etablierung von Java EE 6 und der damit verbundenen Auseinandersetzung mit CDI (Contexts and Dependency Injection) entsprang deshalb die Überlegung, CDI Events als Ausgangspunkt für die Integration von RabbitMQ in Java EE zu nutzen.

Die Idee hinter diesem Ansatz ist folgende: CDI Events werden für das Publizieren zum Broker und das Konsumieren vom selbigen an die entsprechenden Broker-Entitäten gebunden. Bei AMQP 0.9.1 werden zum Publizieren Exchanges in Verbindung mit Routing Keys genutzt, während Queues als Quellen der Konsumenten dienen. Abbildung 1 veranschaulicht, wie CDI Events mithilfe von RabbitMQ über Applikationsgrenzen hinweg ausgetauscht werden.

Abb. 1: Austauschen von CDI Events

Werden in der Applikation CDI Events gefeuert (1), so wird für zuvor gebundene Events (2) eine AMQP-Nach...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang