Jakarta Messaging

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von JMS Provider)
Zur Navigation springen Zur Suche springen

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

[Bearbeiten | Quelltext bearbeiten]

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

Implementierung

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

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
[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ J2EE: Java Message Service (JMS)
  2. ↑ Spec
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Jakarta_Messaging&oldid=238486570“