JMS (Java message service)

Der Java Message Service (JMS) definiert einen offenen Standard für eine einheitliche Java-Schnittstelle hinsichtlich Message Oriented Middleware (auch MOM oder nachrichtenorientierte Middleware). Im Sinne von MOM wird eine Message-Service-Implementierung mit ihren ggf. weiteren Funktionen wie Sicherheitsfunktionen, Load Balancing oder Werkzeuge zur Administration auch als JMS-Provider bezeichnet.


Die Nutzer dieses Dienstes werden allgemein Client oder auch Producer und Consumer genannt. Producer und Consumer kommunizieren nicht direkt sondern über den Provider miteinander. Der sendende Client ist in Beziehung zum Provider immer asynchron, währenddessen der empfangende Client sowohl asynchron als auch synchron agieren kann. Vorteilhaft ist in jedem Fall, dass der JMS so unterschiedliche Plattformen einheitlich miteinander verbinden kann. Die JMS API unterstützt im Wesentlichen zwei Verfahren des Messagings - das Point-to-Point- sowie das Publish-and-Subscribe-Verfahren. Diese Verfahren werden auch als Messaging Domains bezeichnet. JMS wurde von Sun Microsystems entwickelt und ist Bestandteil der Java Enterprise Edition (JEE).

Die JMS-Spezifikation ist sehr umfangreich. Dies liegt zu einem gewissen Teil auch daran, dass zur Zeit der Erstellung dieser Spezifikation die Struktur von MOM-Systemen sehr uneinheitlich war, da diese bereits eine erhebliche Zeit vorher existierten. Die aktuelle Spezifikation ist in vollständigem Umfang unter dem u.g. Link verfügbar.

JMS-Clients und Provider

JMS-Clients und Provider

Die Abbildung zeigt den Provider mit seinen Clients - einen Producer, der die Nachricht generiert und sendet - sowie - einen Consumer, der die Nachricht empfängt und entsprechend agiert - in einer prinzipiellen Grundanordnung.

JMS unterstützt die folgenden Nachrichtenmodelle:

Point-to-Point (PTP) Hierbei wird die Nachricht - die genau einen Empfänger hat - an eine Warteschlange (Queue) gesendet. Der Sender wird als Producer, der Empfänger als Consumer bezeichnet. Beide sind zeitlich völlig unabhängig voneinander. Die Queue dient der Speicherung persistenter Nachrichten, die entweder vom Consumer gelesen werden oder in Abhängigkeit eines Zeit-Limits ungültig werden können. Anwendung findet dieses Modell vor allem dort, wo eine zeitliche Entkopplung von Producer und Consumer möglich oder notwendig ist.

Publish-and-Subscribe (Pub/Sub) Analog wird in diesem Modell der Producer zum Publisher und der Consumer zum Subscriber. Die Nachrichten werden sogenannten Themen (Topics) zugeordnet. Viele Producer publizieren (publish) ihre Nachrichten zu einem Topic währenddessen wiederum beliebig viele Consumer die Nachrichten von dem Topic abonnieren (subscribe). Bei mehreren Consumern spricht man auch von multicast. Dieses Modell findet Anwendung bei Systemen, bei denen Nachrichten in Echtzeit zum Beispiel RSS-Feeds oder Börsendienste verteilt werden müssen.

Eine JMS-Applikation kann nun eines dieser Nachrichtenmodelle verwenden oder auch Kombinationen dieser sogenannten Message Domains. In jedem Fall setzt sich die Architektur einer JMS Applikation aus den folgenden Elementen zusammen:

  • Mit JMS-Clients werden die Java-Programme bezeichnet, die Messages senden und empfangen.
  • Nicht-JMS-Clients ( legacy clients) nutzen die API des Message Systems aber nicht JMS. Ein Message System unterstützt in der Regel beide Formen von Clients.
  • Mit Messages werden die Nachrichten bezeichnet, die den Austausch von Informationen zwischen den Clients ermöglichen.
  • JMS-Provider definieren ein Message System, welches JMS zusätzlich zu administrativen Funktionen implementiert.
  • JMS-Objekte werden als administrative Objekte bezeichnet. Diese werden vom JMS-Provider administriert und stellen den JMS-Clients Verbindungsinformationen zur Verfügung.
JMS berücksichtigt nun, dass sich JMS-Provider u.U. hinsichtlich ihrer Konfiguration oder auch Technologie erheblich unterscheiden. Diese Eigenschaften werden auch als proprietär bezeichnet, und das Ziel ist die Portabilität von JMS-Clients und eingesetztem JMS-Provider. Dies wird durch die vom JMS-Provider erzeugten administrativen Objekte sichergestellt, von denen es zwei verschiedene Ausführungen gibt:

  • ConnectionFactory - ein Objekt zum Aufbau einer Verbindung durch den JMS-Client.
  • Destination - ein Objekt, welches Quelle und Ziel der Nachrichten definiert. Das Objekt bildet dabei eine Queue für die Nachrichten ab.
Die administrierten Objekte werden vom JMS-Provider ein JNDI (Java Naming and Directory Interface) eingetragen. Dadurch sind sie jedem JMS-Client auf portable Weise verfügbar, und auf die Objekte kann über die JMS API zugegriffen werden.

Zusammenhänge der Kommunikation über JMS

Allgemeines 
   JMS-Modell

Allgemeines JMS-Modell

Die Abbildung verdeutlicht den Zusammenhang zwischen Verbindungsaufbau und Kommunikation über JMS. Zunächst wird dazu eine Verbindung ( Connection) zwischen JMS-Client und JMS-Provider aufgebaut. Der JMS-Standard definiert dazu die Objekte Connection, Session, Message-Producer und MessageConsumer, über die ein JMS-Client die Dienste seines JMS-Providers erreichen kann. Die geeignete Implementierung der Schnittstellen ist Aufgabe des JMS-Providers, wobei der Ablauf je nach gewähltem Nachrichtenmodell unterschiedlich sein kann.

Für einen Verbindungsaufbau und die Kommunikation muss ein JMS-Client die folgenden Schritte generieren:

  • Über den Namensdienst (JNDI) die administrativen Objekte (ConnectionFactory und Destination) abfordern.
  • ConnectionFactory ist für die Verbindung zuständig, Destination implementiert die Queue des Providers.
  • Es wird eine Session zur Steuerung der Kommunikation eröffnet, der MessageProducer wird mit dem Queue-Objekt verbunden.
Beim Senden einer Nachricht muss folgender Ablauf eingehalten werden: Die vom JMS-Client generierte Nachricht wird an den MessageProducer zur Ablage in der Queue übergeben.

Beim Empfang einer Nachricht muss unterschieden werden in: Asynchronen Empfang: Dazu installiert der JMS-Client einen MessageListener, der diesen informiert, wenn eine Nachricht für ihn beim JMS-Provider vorliegt, und synchronem Empfang: der JMS-Client wartet solange, bis der MessageConsumer eine Nachricht für ihn empfangen hat, was zu einer Blockade des JMS-Clients führen kann.

JMS ist nicht Multithreading fähig aber mit Einschränkungen unterstützt das Design von JMS mehrere User. So unterstützen die JMS-Objekte Destination, ConectionFactory und Connection sogenannte Concurrent Uses.

http://java.sun.com/products/jms/

http://www.sun.com/software/products/message_queue

http://openjms.sourceforge.net/

Informationen zum Artikel
Deutsch:
Englisch: Java message service - JMS
Veröffentlicht: 27.10.2013
Wörter: 891
Tags: #Java
Links: Administration, Analog, Anschluss, API (application programming interface), Architektur