Jakarta Messaging

Messaging ist eine Möglichkeit der lose gekoppelten und verteilten Kommunikation in Form von zwischen Softwarekomponenten verschickten Nachrichten. Messaging versucht, die sonst enge Kopplung anderer Kommunikationsmöglichkeiten wie TCP Kommunikation über Sockets, CORBA oder RMI durch die Einführung einer zwischen den Clients gelegenen Komponente aufzubrechen. Damit wird sichergestellt, dass die Clients kein näheres Wissen über die Gegenstelle(n) ihrer Kommunikation haben müssen, was sowohl den Einsatzbereich erhöht als auch die Wartung und Wiederverwendung der Komponenten erleichtert.

JMS und der durch diese angesteuerte Dienst unterstützen zwei unterschiedliche Ansätze zum Versenden von Nachrichten, zum einen die Nachrichtenwarteschlange (englisch queue) für sogenannte point-to-point Verbindungen und zum anderen ein Anmelde-Versendesystem (engl. topic) für Publish-Subscribe-Kommunikation:

• Bei der Warteschlange sendet der Sender an eine Queue, an der ein Empfänger hängt. Ist kein Empfänger verfügbar, kann die Nachricht optional gespeichert werden und potentielle Empfänger können sie jederzeit später abholen. Für den Fall nur eines Empfängers, kann man dies am besten mit einem Paketdienst vergleichen. Jede Sendung hat genau einen Empfänger. Ist dieser nicht zu Hause, kann er sich die Sendung zu einem beliebigen Zeitpunkt später abholen. Bei mehreren Empfängern wird bei der Zustellung der Nachrichten sichergestellt, dass jede eingereihte Nachricht exakt einmal zugeteilt wird. Hierdurch lässt sich Load Balancing realisieren, bei dem Empfänger beliebig hinzugefügt und entfernt werden können.

• Bei dem Anmelde-Versendesystem werden die Nachrichten an ein Topic geschickt, auf das eine beliebige Anzahl von Empfängern hört. Wird die Nachricht nicht konsumiert, weil kein Empfänger sich an das Topic angemeldet hat, dann ist dies unerheblich. Man kann dies am besten mit einem Fernsehsender vergleichen (Broadcasting). Entweder man schaltet den Fernseher ein und sieht die Nachricht oder man lässt den Fernseher aus und sieht die Nachricht nicht. Wahlweise können die Nachrichten auch zwischengespeichert werden (durable-subscription).

Um Nachrichten senden bzw. empfangen zu können, muss zunächst eine Queue bzw. ein Topic bestimmt werden, über die die Kommunikation läuft. Dies wird üblicherweise mittels eines JNDI-Lookups gelöst:

Context ctx = new InitialContext();
QueueConnectionFactory factory = (QueueConnectionFactory) ctx.lookup("QueueConnectionFactory");
Queue myQueue = (Queue) ctx.lookup("MyQueue");

Anschließend wird eine Connection erzeugt, auf der eine Session gestartet wird. Darauf wird dann, je nachdem, ob gesendet oder empfangen wird, ein Sender bzw. ein Receiver geöffnet, über den Messages gesendet bzw. empfangen werden können:

QueueConnection connection = factory.createQueueConnection();
QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
QueueSender sender = session.createSender(myQueue);
TextMessage message = session.createTextMessage();
sender.send(message);

bzw.

...
QueueReceiver receiver = session.createReceiver(myQueue);
connection.start();
Message message = receiver.receive();

Das Senden und Empfangen via Topic erfolgt ähnlich zum Senden und Empfangen via Queue. Es werden einerseits andere Klassen verwendet (TopicSession, TopicConnection, TopicPublisher, TopicSubscriber, Topic), andererseits holt man beim Empfang einer Nachricht via Topic diese nicht mittels receiver.receive() ab, sondern implementiert einen MessageListener.onMessage(Message) EventHandler, der die Nachrichten via Message Events bekommt.

Die unterschiedlichen über Queues und Topics versendbaren Nachrichtentypen sind folgende:

Message

Nachricht ohne Inhalt (Body)

StreamMessage

Nachricht mit einem Stream von Java-Primitiven

MapMessage

Nachricht mit einer Map von Java-Objekten

TextMessage

Nachricht mit einem String (z. B. für XML-Messages)

ObjectMessage

Nachricht mit einem serialisierten Java-Objekt

BytesMessage

Nachricht mit einem Stream von Bytes

Um JMS nutzen zu können, wird ein JMS-Provider benötigt, der die Topics, Queues und Sessions verwaltet. Die folgende Liste führt JMS-Provider auf. Sie nennt sowohl kommerzielle als auch freie Software, erhebt aber keinen Anspruch auf Vollständigkeit.

Nicht aufgeführt sind jedoch solche JMS-Provider, die ausschließlich als Bestandteil eines Java-EE-Containers (Java-Anwendungsservers) angeboten werden. Eine Übersicht von Java-EE-Containern ist separat verfügbar.

In der untenstehenden Tabelle bedeuten die in der Spalte „Betriebsmodi“ enthaltenen Angaben folgendes:

eigenständig

Der JMS-Provider läuft als eigenständiger Prozess (stand alone) und damit separat von den JMS-Client-Prozessen. Die Kommunikation mit den Clients erfolgt beispielsweise über TCP/IP oder Unix Domain Sockets.

eingebettet

Der JMS-Provider läuft in derselben JVM (embedded, colocated) wie einer der JMS-Clients. Ein Vorteil ist die schnellere Nachrichtenübertragung.

Moderne JMS-Provider erlauben beide Betriebsmodi.

• JMS-Übersicht
• JMS-Spezifikation
• JMS mit Oracle Advanced Queueing Detailliertes Tutorial mit Java-Codebeispielen zum JMS mit Oracle Advanced Queuing
• Um dem Leser ein unnötiges Nachschlagen der Links zu ersparen, sind die Links zu den JMS-Providern unmittelbar in der obigen Tabelle enthalten.

1. J2EE: Java Message Service (JMS)
2. Spec