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.
| Name | Firma | Lizenz | Betriebsmodi | URL |
|---|---|---|---|---|
| ActiveMQ | Apache | Open Source (Apache 2) | eigenständig, eingebettet | apache.org |
| FuseMQ | Red Hat | Open Source (Apache 2), kommerzieller Support möglich | eigenständig, eingebettet | fusesource.com |
| Apollo | Apache | Open Source (Apache 2) | apache.org | |
| FioranoMQ | Fiorano | kommerziell | ||
| iBus//MessageServer | Softwired | kommerziell | ||
| HornetQ (ehemals bekannt unter "JBoss Messaging") | Red Hat | Open Source (Apache 2) | eigenständig, eingebettet | jboss.org |
| JORAM | OW2 | Open Source (LGPL) | eigenständig, eingebettet | ow2.org |
| MantaRay | Coridan | Open Source (Mozilla Public License) | eigenständig, eingebettet | |
| Mom4j | Mom4j development team | Open Source (LGPL) | eingebettet | |
| MRG Messaging | Red Hat | kommerziell | redhat.com | |
| MuleMQ | MuleSoft Inc. | kommerziell | mulesoft.com | |
| OpenJMS | Open Source | eigenständig, eingebettet | sourceforge.net | |
| Open Message Queue | Sun Microsystems | Open Source | eigenständig | mq.java.net |
| Oracle Advanced Queuing (OAQ) | Oracle | kommerziell | eingebettet | oracle.com |
| Qpid | Apache | Open Source (Apache 2) | apache.org | |
| SAP JMS | SAP | kommerziell | eingebettet | sap.com |
| SonicMQ | Progress Software | kommerziell | ||
| SwiftMQ | IIT Software | Open Source (Apache 2) | eigenständig | swiftmq.com |
| TIBCO Enterprise Message Service | TIBCO | kommerziell | ||
| webMethods Broker | Software AG | kommerziell | eigenständig, eingebettet | softwareag.com |
| webMethods Universal Messaging | Software AG | kommerziell | eigenständig, eingebettet | softwareag.com |
| Websphere MQ | IBM | kommerziell | eigenständig, eingebettet | ibm.com |
| WSO2 Message Broker | WSO2 | Open Source (Apache 2) | eigenständig | wso2.com |
Weblinks
- 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.