Jakarta Messaging

Jakarta Messaging (ehemals Java Message Service oder JMS ) ist eine Java -Programmierschnittstelle (API) für nachrichtenorientierte Middleware . Sie bietet generische Messaging-Modelle, die das Produzenten-Konsumenten-Problem lösen können und das Senden und Empfangen von Nachrichten zwischen Softwaresystemen erleichtern . ^{[ 1 ]} Jakarta Messaging ist Bestandteil von Jakarta EE und wurde ursprünglich durch eine Spezifikation von Sun Microsystems definiert, bevor sie vom Java Community Process weiterentwickelt wurde . ^{[ 2 ]}

Messaging ist eine Form der lose gekoppelten, verteilten Kommunikation, wobei der Begriff „Kommunikation“ in diesem Kontext als Austausch von Nachrichten zwischen Softwarekomponenten verstanden wird. Nachrichtenorientierte Technologien versuchen, die enge Kopplung von Kommunikationsschnittstellen (wie TCP- Netzwerk- Sockets , CORBA oder RMI ) durch die Einführung einer Vermittlungskomponente zu lockern. Dieser Ansatz ermöglicht es Softwarekomponenten, indirekt miteinander zu kommunizieren. Ein Vorteil ist, dass die Absender keine genauen Kenntnisse über ihre Empfänger benötigen.

Zu den Vorteilen von Messaging gehören die Möglichkeit, heterogene Plattformen zu integrieren, Systemengpässe zu reduzieren, die Skalierbarkeit zu erhöhen und schneller auf Veränderungen zu reagieren. ^{[ 3 ]}

• JMS 1.0 ^{[ 4 ]}
• JMS 1.0.1 (5. Oktober 1998) ^{[ 4 ]}
• JMS 1.0.1a (30. Oktober 1998) ^{[ 5 ] [ 6 ]}
• JMS 1.0.2 (17. Dezember 1999) ^{[ 7 ]}
• JMS 1.0.2a (23. Dezember 1999) ^{[ 8 ]}
• JMS 1.0.2b (27. August 2001) ^{[ 9 ]}
• JMS 1.1 (12. April 2002) ^{[ 10 ]}
• JMS 2.0 (21. Mai 2013). ^{[ 11 ] [ 12 ]} Es wurde im Rahmen des Java Community Process als JSR 343 weiterentwickelt. ^{[ 13 ]}
• JMS 2.0a (16. März 2015) ^{[ 14 ] [ 15 ]}
• Jakarta Messaging 2.0.2 ist die erste Veröffentlichung unter Eclipse Foundation und Jakarta EE ^{[ 16 ].}
• Jakarta Messaging 3.0.0 ist Teil von Jakarta EE 9 ^{[ 17 ]}
• Jakarta Messaging 3.1.0 ist Teil von Jakarta EE 10 ^{[ 18 ]}

Folgende Elemente sind JMS-Elemente: ^{[ 19 ]}

JMS-Anbieter

Eine Implementierung der JMS-Schnittstelle für nachrichtenorientierte Middleware (MOM). Provider werden entweder als Java-JMS-Implementierung oder als Adapter für eine Nicht-Java-MOM implementiert.

JMS-Client

Eine Anwendung oder ein Prozess, der Nachrichten erzeugt und/oder empfängt.

JMS-Produzent/Herausgeber

Ein JMS-Client, der Nachrichten erstellt und versendet.

JMS-Verbraucher/Abonnent

Ein JMS-Client, der Nachrichten empfängt.

JMS-Nachricht

Ein Objekt, das die zwischen JMS-Clients übertragenen Daten enthält.

JMS-Warteschlange

Eine Warteschlange (Queue) ist ein Zwischenspeicher, der gesendete Nachrichten enthält, die darauf warten, gelesen zu werden (von genau einem Empfänger). Wie der Name schon sagt, werden die Nachrichten in der Reihenfolge ihres Versands zugestellt. Eine JMS-Warteschlange garantiert, dass jede Nachricht nur einmal verarbeitet wird.

JMS-Thema

Ein Verteilungsmechanismus zum Veröffentlichen von Nachrichten, die an mehrere Abonnenten zugestellt werden.

Die JMS-API unterstützt zwei unterschiedliche Modelle:

• Punkt-zu-Punkt
• Veröffentlichen und abonnieren

Im Punkt-zu-Punkt -Messaging-System werden Nachrichten an einzelne Empfänger weitergeleitet, die Warteschlangen für eingehende Nachrichten verwalten. Dieses Messaging-System basiert auf dem Konzept von Nachrichtenwarteschlangen , Sendern und Empfängern. Jede Nachricht wird an eine bestimmte Warteschlange adressiert, und die empfangenden Clients entnehmen die Nachrichten aus den für sie eingerichteten Warteschlangen. Obwohl beliebig viele Sender Nachrichten an die Warteschlange senden können, ist die Zustellung jeder Nachricht an einen Empfänger garantiert. Warteschlangen speichern alle an sie gesendeten Nachrichten, bis diese verarbeitet wurden oder ablaufen. Sind keine Empfänger für die Nachrichten registriert, werden diese in der Warteschlange gespeichert, bis sich ein Empfänger registriert.

Das Publish-Subscribe- Modell ermöglicht das Veröffentlichen von Nachrichten zu einem bestimmten Themenbereich. Abonnenten können ihr Interesse am Empfang von Nachrichten zu einem bestimmten Themenbereich bekunden . In diesem Modell wissen weder der Herausgeber noch der Abonnent voneinander. Man kann dies gut mit einem anonymen Schwarzen Brett vergleichen.

• Null oder mehr Verbraucher werden die Nachricht erhalten.
• Zwischen Publishern und Subscribern besteht eine zeitliche Abhängigkeit. Der Publisher muss ein Nachrichtenthema erstellen, das Clients abonnieren können. Der Subscriber muss kontinuierlich aktiv bleiben, um Nachrichten zu empfangen, es sei denn, er hat ein dauerhaftes Abonnement eingerichtet. In diesem Fall werden Nachrichten, die veröffentlicht wurden, während der Subscriber nicht verbunden war, erneut verteilt, sobald er sich wieder verbindet.

JMS ermöglicht die Trennung von Anwendung und Transportschicht . Dieselben Java- Klassen können zur Kommunikation mit verschiedenen JMS-Providern verwendet werden, indem die JNDI-Informationen ( Java Naming and Directory Interface ) des jeweiligen Providers genutzt werden. Die Klassen stellen zunächst über eine Verbindungsfactory eine Verbindung zur Queue oder zum Topic her und verwenden anschließend die Methoden `populate` und `send` bzw. `publish`, um Nachrichten zu senden oder zu veröffentlichen. Auf der Empfängerseite können Clients die Nachrichten dann empfangen oder abonnieren.

RFC 6167 definiert ein jms:URI-Schema für den Java Message Service.

Um JMS zu verwenden, wird ein JMS-Provider benötigt, der Sessions, Queues und Topics verwalten kann. Ab Java EE Version 1.4 muss ein JMS-Provider in allen Java EE-Anwendungsservern enthalten sein. Dies kann mithilfe des Message-Inflow-Managements der Java EE Connector Architecture implementiert werden , die erstmals in dieser Version verfügbar war.

Nachfolgend eine Liste gängiger JMS-Anbieter:

• Die Java Messaging Library von Amazon SQS
• Apache ActiveMQ Classic
• Apache ActiveMQ Artemis
• Apache Qpid , unter Verwendung von AMQP ^{[ 20 ]}
• IBM MQ (ehemals MQSeries, dann WebSphere MQ)
• IBM WebSphere Application Server 's Service Integration Bus (SIBus) ^{[ 21 ]}
• JBoss Messaging und HornetQ von JBoss
• JORAM vom OW2-Konsortium
• Nachrichtenwarteschlange von Eclipse Foundation öffnen
• OpenJMS von der OpenJMS-Gruppe
• Oracle WebLogic Server und Oracle AQ
• PubSub+ von Solace
• RabbitMQ von Pivotal Software
• TIBCO Enterprise Message Service ^{[ 22 ]}

• Message Driven Beans
• Nachrichtenwarteschlange – das Konzept, das JMS zugrunde liegt
• serviceorientierte Architektur
  • Ereignisgesteuerte SOA
• Zu den Messaging-Technologien, die die JMS-API nicht implementieren, gehören:
  • Advanced Message Queuing Protocol (AMQP) – standardisiertes Nachrichtenwarteschlangenprotokoll mit mehreren unabhängigen Implementierungen
  • Data Distribution Service (DDS) – Ein von der Object Management Group (OMG) standardisiertes Echtzeit-Messaging-System mit über zehn Implementierungen, die die Interoperabilität zwischen Herausgebern und Abonnenten nachgewiesen haben.
  • Microsoft Message Queuing – eine ähnliche Technologie, implementiert für das .NET Framework.

• Richards, Mark; Richard Monson-Haefel; David A. Chappell (2009). Java Message Service, Zweite Auflage . O'Reilly. ISBN 978-0-596-52204-9Die

• Offizielle Website
• JSR 343: Java Message Service 2.0
• javax.jmsAPI- Javadoc -Dokumentation
• Oracle Java EE 7 JMS-Tutorial
• Eine historische Vergleichsmatrix der JMS-Anbieter