Jakarta-Nachrichten - Jakarta Messaging
Die Jakarta Messaging API (ehemals Java Message Service oder JMS API) ist eine Java- Anwendungsprogrammierschnittstelle (API) für nachrichtenorientierte Middleware . Es bietet generische Messaging-Modelle, die das Producer-Consumer-Problem bewältigen können und das Senden und Empfangen von Nachrichten zwischen Softwaresystemen erleichtern können . Jakarta Messaging ist ein Teil von Jakarta EE und wurde ursprünglich durch eine bei Sun Microsystems entwickelte Spezifikation definiert, bevor sie vom Java Community Process geleitet wurde .
Allgemeine Idee von Messaging
Messaging ist eine Form der lose gekoppelten verteilten Kommunikation, wobei der Begriff „Kommunikation“ in diesem Zusammenhang als Austausch von Nachrichten zwischen Softwarekomponenten verstanden werden kann. Nachrichtenorientierte Technologien versuchen, die eng gekoppelte Kommunikation (wie TCP- Netzwerk- Sockets , CORBA oder RMI ) durch die Einführung einer Zwischenkomponente zu lockern. Dieser Ansatz ermöglicht es Softwarekomponenten, indirekt miteinander zu kommunizieren. Dies hat den Vorteil, dass Nachrichtensender keine genauen Kenntnisse über ihre Empfänger haben müssen.
Zu den Vorteilen von Messaging zählen die Möglichkeit, heterogene Plattformen zu integrieren, Systemengpässe zu reduzieren, die Skalierbarkeit zu erhöhen und schneller auf Änderungen zu reagieren.
Versionsgeschichte
- JMS 1.0
- JMS 1.0.1 (5. Oktober 1998)
- JMS 1.0.1a (30. Oktober 1998)
- JMS 1.0.2 (17. Dezember 1999)
- JMS 1.0.2a (23. Dezember 1999)
- JMS 1.0.2b (27. August 2001)
- JMS 1.1 (12. April 2002)
- JMS 2.0 (21. Mai 2013)
- JMS 2.0a (16. März 2015)
JMS 2.0 wird derzeit unter dem Java Community Process als JSR 343 verwaltet.
JMS 3.0 befindet sich in der frühen Entwicklungsphase als Teil von Jakarta EE.
Elemente
Die folgenden JMS-Elemente sind:
- JMS-Anbieter
- Eine Implementierung der JMS-Schnittstelle für nachrichtenorientierte Middleware (MOM). Provider werden entweder als Java-JMS-Implementierung oder als Adapter für ein 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 sendet.
- JMS-Verbraucher/-Abonnent
- Ein JMS-Client, der Nachrichten empfängt.
- JMS-Nachricht
- Ein Objekt, das die Daten enthält, die zwischen JMS-Clients übertragen werden.
- JMS-Warteschlange
- Ein Staging-Bereich, der Nachrichten enthält, die gesendet wurden und darauf warten, gelesen zu werden (von nur einem Verbraucher). Wie der Name Queue vermuten lässt, werden die Nachrichten in der gesendeten Reihenfolge 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 übermittelt werden.
Modelle
Die JMS-API unterstützt zwei verschiedene Modelle:
- Punkt zu Punkt
- Veröffentlichen und abonnieren
Punkt-zu-Punkt-Modell
Unter dem Punkt-zu-Punkt- Nachrichtenübermittlungssystem werden Nachrichten an einzelne Verbraucher geleitet, die Warteschlangen für eingehende Nachrichten verwalten. Dieser Nachrichtentyp basiert auf dem Konzept von Nachrichtenwarteschlangen , Sendern und Empfängern. Jede Nachricht wird an eine bestimmte Warteschlange adressiert, und die empfangenden Clients extrahieren Nachrichten aus den Warteschlangen, die zum Halten ihrer Nachrichten eingerichtet wurden. Während eine beliebige Anzahl von Produzenten Nachrichten an die Warteschlange senden kann, wird jede Nachricht garantiert zugestellt und von einem Consumer verarbeitet. Warteschlangen bewahren alle an sie gesendeten Nachrichten auf, bis die Nachrichten verbraucht sind oder bis die Nachrichten ablaufen. Wenn keine Consumer registriert sind, um die Nachrichten zu konsumieren, hält die Warteschlange sie, bis sich ein Consumer registriert, um sie zu konsumieren.
Publish-and-Subscribe-Modell
Das Publish-and-Subscribe- Modell unterstützt das Publizieren von Nachrichten zu einem bestimmten Nachrichten-"Thema". Abonnenten können Interesse am Empfangen von Nachrichten registrieren, die zu einem bestimmten Nachrichtenthema veröffentlicht wurden. Bei diesem Modell wissen weder der Herausgeber noch der Abonnent voneinander. Eine gute Analogie dafür ist ein anonymes Schwarzes Brett.
- Null oder mehr Verbraucher erhalten die Nachricht.
- Es besteht eine zeitliche Abhängigkeit zwischen Herausgebern und Abonnenten. Der Herausgeber muss ein Nachrichtenthema erstellen, damit Clients abonnieren können. Der Abonnent muss ständig aktiv bleiben, um Nachrichten zu empfangen, es sei denn, er hat ein dauerhaftes Abonnement eingerichtet. In diesem Fall werden Nachrichten, die veröffentlicht werden, während der Abonnent nicht verbunden ist, bei jeder erneuten Verbindung neu verteilt.
JMS bietet eine Möglichkeit, die Anwendung von der Transportschicht der Datenbereitstellung zu trennen . Dieselben Java- Klassen können verwendet werden, um mit verschiedenen JMS-Providern zu kommunizieren, indem die Java Naming and Directory Interface (JNDI)-Informationen für den gewünschten Provider verwendet werden. Die Klassen verwenden zuerst eine Verbindungsfactory , um eine Verbindung mit der Warteschlange oder dem Thema herzustellen , und verwenden dann Auffüllen und Senden oder Veröffentlichen der Nachrichten. Auf der Empfangsseite empfangen oder abonnieren dann die Clients die Nachrichten.
URI-Schema
RFC 6167 definiert ein jms: URI-Schema für den Java Message Service.
Anbieterimplementierungen
Um JMS verwenden zu können, muss ein JMS-Provider vorhanden sein, der die Sitzungen, Warteschlangen und Themen verwalten kann. Ab Java EE Version 1.4 muss ein JMS-Provider in allen Java EE-Anwendungsservern enthalten sein. Dies kann über das Message Inflow Management der Java EE Connector Architecture realisiert werden , das in dieser Version erstmals zur Verfügung gestellt wurde.
Im Folgenden finden Sie eine Liste gängiger JMS-Anbieter:
- Amazon SQS ‚s Java Messaging - Bibliothek
- Apache ActiveMQ
- Apache Qpid , mit AMQP
- IBM MQ (ehemals MQSeries, dann WebSphere MQ)
- Service Integration Bus (SIBus) von IBM WebSphere Application Server
- JBoss Messaging und HornetQ von JBoss
- JORAM vom OW2-Konsortium
- Nachrichtenwarteschlange von Oracle öffnen
- OpenJMS von der OpenJMS-Gruppe
- Oracle WebLogic Server und Oracle AQ
- RabbitMQ von Pivotal Software
Siehe auch
- Message Driven Beans
- Nachrichtenwarteschlange – das JMS zugrunde liegende Konzept
- Serviceorientierte Architektur
- Zu den Messaging-Technologien, die die JMS-API nicht implementieren, gehören:
- Advanced Message Queuing Protocol (AMQP) – standardisiertes Message Queuing Protocol mit mehreren unabhängigen Implementierungen
- Data Distribution Service (DDS) – Ein standardisiertes Echtzeit-Messaging-System der Object Management Group (OMG) mit über zehn Implementierungen, die die Interoperabilität zwischen Herausgebern und Abonnenten bewiesen haben
- Microsoft Message Queuing – ähnliche Technologie, implementiert für .NET Framework
Verweise
Weiterlesen
- Richards, Mark; Richard Monson-Häfel; David A. Chappell (2009). Java Message Service, Zweite Ausgabe . O'Reilly. ISBN 978-0-596-52204-9.