Jakarta Messaging

Jakarta Messaging (früher Java Message Service; JMS API) ist eine Programmierschnittstelle (API) für die Ansteuerung einer Message Oriented Middleware (MOM) zum Senden und Empfangen von Nachrichten aus einem Client heraus, der in der Programmiersprache Java geschrieben ist. JMS hat das Ziel, lose gekoppelte, verlässliche und asynchrone Kommunikation zwischen den Komponenten einer verteilten Anwendung zu ermöglichen.[1]

JMS ist Teil der Jakarta EE; die Spezifikation des Dienstes sowie die zugehörige API wurden durch den Java Community Process im Rahmen des JSR 914 genormt. Die aktuelle Version von JMS ist die Version 2.0 vom 21. Mai 2013 und ist Bestandteil der Java Enterprise Edition 7.0.[2]

Für die Anwendung braucht man einen Provider, der die API umsetzt und somit den Dienst bereitstellt. Dafür gibt es sowohl kommerzielle Produkte als auch Open-Source-Projekte.

Funktionsweise

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 als auch die Wartung und Wiederverwendung der Komponenten erhöht.

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).

Implementierung

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

JMS-Provider

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.

NameFirmaLizenzBetriebsmodiURL
ActiveMQApacheOpen Source (Apache 2)eigenständig, eingebettetapache.org
FuseMQRed HatOpen Source (Apache 2), kommerzieller Support möglicheigenständig, eingebettetfusesource.com
ApolloApacheOpen Source (Apache 2)apache.org
FioranoMQFioranokommerziell
iBus//MessageServerSoftwiredkommerziell
HornetQ (ehemals bekannt unter "JBoss Messaging")Red HatOpen Source (Apache 2)eigenständig, eingebettetjboss.org
JORAMOW2Open Source (LGPL)eigenständig, eingebettetow2.org
MantaRayCoridanOpen Source (Mozilla Public License)eigenständig, eingebettet
Mom4jMom4j development teamOpen Source (LGPL)eingebettet
MRG MessagingRed Hatkommerziellredhat.com
MuleMQMuleSoft Inc.kommerziellmulesoft.com
OpenJMSOpen Sourceeigenständig, eingebettetsourceforge.net
Open Message QueueSun MicrosystemsOpen Sourceeigenständigmq.java.net
Oracle Advanced Queuing (OAQ)Oraclekommerzielleingebettetoracle.com
QpidApacheOpen Source (Apache 2)apache.org
SAP JMSSAPkommerzielleingebettetsap.com
SonicMQProgress Softwarekommerziell
SwiftMQIIT SoftwareOpen Source (Apache 2)eigenständigswiftmq.com
TIBCO Enterprise Message ServiceTIBCOkommerziell
webMethods BrokerSoftware AGkommerzielleigenständig, eingebettetsoftwareag.com
webMethods Universal MessagingSoftware AGkommerzielleigenständig, eingebettetsoftwareag.com
Websphere MQIBMkommerzielleigenständig, eingebettetibm.com
WSO2 Message BrokerWSO2Open Source (Apache 2)eigenständigwso2.com

Weblinks

Einzelnachweise

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