J2EE@K&A

Java Message Service im J2EE-Kontext Im Folgenden soll kurz das Konzept der nachrichtenorientierten Kommunikation mit Hilfe von Messaging Services vorgestellt, und im Anschluss deren Einsatzmöglichkeiten bei der Entwicklung im Umfeld der J2EE-Plattform aufgezeigt werden.

Messaging Services Mit Hilfe eines Messaging Service lässt sich eine ansynchrone Kommunikation zwischen Komponenten eines Softwaresystems umsetzen. Man spricht in diesem Fall von einer losen Kopplung der Komponenten. Die besonderen Eigenschaften dieser losen Kopplung sind dabei: § Asynchrone Kommunikation, also die zeitliche Entkopplung zwischen dem Senden einer Nachricht und deren Empfangen bzw. Bearbeitung in der empfangenden Komponente. Und auch zwischen dem evtl. zu erwartenden Ergebnis auf Grund einer gesendeten Nachricht. § Die Funktionsschnittstellen der jeweils anderen Komponente (Interfaces) müssen nicht bekannt sein. Die Kommunikation geschieht in diesem Fall über den spezifizierten Aufbau der übermittelten Nachrichten. Bereitgestellt wird diese Funktionalität durch eine so genannte Message Oriented Middleware (MOM), die für die Entgegennahme von Nachrichten von einem Sender und deren Weiterleitung an einen oder mehrere Empfänger verantwortlich ist. Hierzu existieren zwei verschiedene Ansätze, die in Abbildung 1 und Abbildung 2 dargestellt sind. Welcher der beide Ansätze verwendet wird, ergibt sich in der Regel aus dem Kontext der zu entwickelnden Anwendung und deren konkreten Anforderungen. Point-to-Point Beim Point-to-Point Ansatz verwaltet die MOM eingegangene Nachrichten eines Senders in einer Queue, aus der diese entnommen und an einen Empfänger weitergereicht werden. Eine Nachricht wird in diesem Fall also jeweils nur von einem Empfänger bearbeitet.

Abbildung 1: Point-to-Point Ansatz für den Nachrichtenaustausch (Quelle: Sun Microsystems)

Publish/Subscribe Beim Publish/Subscribe Ansatz kann eine Nachricht von mehreren Empfängern verarbeitet werden. Dazu werden von der MOM s.g. Topics verwaltet, die von Empfängern abonniert werden können. Jeder Empfänger, der ein bestimmtes Topic abonniert hat, bekommt die Nachrichten die unter diesem Topic veröffentlicht werden zugestellt.

Kölsch & Altmann GmbH, Juli 2005

J2EE@K&A

Abbildung 2: Publish/Subscribe Ansatz (Quelle: Sun Microsystems) Etwas abstrakter betrachtet besteht in einer Anwendung der Teil für die nachrichtenorientierte Kommunikation aus den Sendern und Empfängern einer Nachricht (auch als Message-Producer und Message-Consumer bezeichnet), sowie aus der bereits erwähnten MOM, also einem MessagingServer, der die Verwaltung und Übermittlung der Nachrichten realisiert. Dazu stellt er den Sendern und Empfängern die für sie notwendigen Dienste zur Verfügung, um Nachrichten senden und empfangen zu können.

Java Message Service Für die Java-Plattform wurde die Java Message Service API (JMS-API) spezifiziert. Mit diesem kann — in Verbindung mit einem so genannten JMS-Provider (Messaging-Server) — die nachrichtenorientierte Kommunikation in Java-Anwendungen implementiert werden. Stellt ein Hersteller eines Messaging-Systems eine Implementierung des JMS-API in Form eines JMSProviders für sein Produkt zur Verfügung, kann auf diese Weise theoretisch jedes Messaging-System an eine Java-Anwendung angebunden bzw. neue Java-Anwendungen beispielsweise in bestehende Workflowsysteme integriert werden. In Abbildung 3 sind die Komponenten einer JMS-Anwendung dargestellt. Eine besondere Gruppe bilden darin die administrierbaren Komponenten. Zu diesen zählen die Connection Factories und die Destinations. § Bei den Destinations handelt es sich entweder um ein Topic oder eine Queue (siehe Abschnitte Point-to-Point und Publish/Subscribe). § Über eine Connection Factory erhalten die Sender und Empfänger eine Verbindung zum JMS-Provider, über die wiederum eine Session zur Nachrichtenübermittlung eröffnet werden kann. Eine Session bildet nun den notwendigen Kontext einer Nachrichtenübertragung, über den auch die Steuerung von Transaktionen für die Nachrichtenübertragung zur Verfügung steht.

Kölsch & Altmann GmbH, Juli 2005

J2EE@K&A

Abbildung 3: Komponenten einer JMS-Anwendung (Quelle: Sun Microsystems) Wenn es darum geht, robuste und komplexe verteilte Anwendungen zu entwickeln, stellt sich JMS als attraktive Basis für die Anwendungsarchitektur dar. Denn zum einen bietet es die Zusicherung der Zustellung von Nachrichten durch die JMS-API selbst, wodurch die Komplexität der selbst zu entwickelnden Komponenten diesbezüglich gering gehalten wird. Zum anderen verfügt es über weitere Features, wie die Einbeziehung der Nachrichtenübermittlung in verteilten Transaktionen und die so genannten Durable Subscriptions.

Abbildung 4: M3 und M4 werden vom Subscriber nicht empfangen (Quelle: Sun Microsystems) Beim Publish/Subscribe Modell ermöglichen die Durable Subscriptions die Zustellung von Nachrichten eines Topics auch an Consumer, die nicht durchgehend eine Session zu diesem Topic besitzen. Somit erhalten auch Consumer beispielsweise nach einem Absturz eines Systems alle Nachrichten, die an das Topic versendet wurden während sie nicht aktiv waren. (siehe Abbildung 4 und Abbildung 5)

Kölsch & Altmann GmbH, Juli 2005

J2EE@K&A

Abbildung 5: Auch M2, M4 und M5 werden vom Subscriber empfangen (Quelle: Sun Mircosystems)

Einsatz von JMS in J2EE-Anwendungen Das JMS-API ist fester Bestandteil der J2EE-Plattform, und somit zusätzlich zur J2EE-ConnectorArchitecture (JCA) eine weitere Möglichkeit zur Anbindung von J2EE-Anwendungen an vorhandene Systeme. Aber auch die gängigen Application-Server enthalten einen JMS-Provider, und stellen somit die Infrastruktur für nachrichtenbasierte Komponenten von J2EE-Anwendungen bereit. Zu beachten ist bei der Produktauswahl jedoch die Tatsache, dass nicht bei allen auf dem Markt befindlichen Application-Server oder JMS-Provider alle oben beschriebenen Funktionalitäten implementiert wurden.

Message Driven Beans Unterscheidet sich das Versenden von Nachrichten in J2EE-Anwendungen noch nicht zum Versenden einer Nachricht in einer reinen JMS-Anwendung, so bietet die J2EE-Plattform zum Empfang von Nachrichten eine Erweiterung, die Message Driven Beans (MDB). Diese MDBs sind in einer J2EEAnwendung die Consumer einer Nachricht (siehe Abbildung 3), und realisieren ausschliesslich das asynchrone Empfangen von Nachrichten. Synchrones Empfangen von Nachrichten in Session oder Entity Beans ist nicht empfehlenswert. Ebenfalls unterschiedlich gestaltet sich das Steuern von Transaktionen innerhalb eines MDB im Vergleich zu einem Consumer einer JMS-Anwendung außerhalb der J2EE-Plattform. Die Transaktionen werden hier in der Regel vom EJB-Container bereitgestellt. Diese können, wie bei Session Beans und Entity Beans, vom MDB über dessen EJB-Context beeinflusst werden.

Abbildung 6: Message Driven Bean als Consumer von Nachrichten in einer J2EE-Anwendung (Quelle: Sun Microsystems)

Kölsch & Altmann GmbH, Juli 2005

J2EE@K&A

Genau wie Stateless Session Beans besitzen auch die MDBs keinen Zustand, und sind somit gut geeignet, die Lasten zu verteilen, die durch eingehende Nachrichten in einer J2EE-Anwendung entstehen können. So kann ein Application-Server mehrere Instanzen eines MDB erzeugen, die die eingehenden Nachrichten parallel verarbeiten können. In Abbildung 6 ist ein einfaches Szenario für die Verwendung von MDBs in einer J2EE-Anwendung dargestellt. Auf der Seite des Client ergibt sich durch die Verwendung der asynchronen, nachrichtenorientierten Kommunikation, neben den bereits erwähnten Vorteilen auch eine bessere Antwortzeit aus Sicht des Benutzers. In der Regel ist in einem solchen Szenario kein sofortiges Ergebnis auf Grund der versendeten Nachricht notwendig. Der Benutzer muss also nicht die Beendigung eines Aufrufs über ein Remote Interface auf einem Objekt auf dem Application-Server abwarten. Dieser Aufruf würde wesentlich mehr Zeit in Anspruch nehmen. Einsatzmöglichkeit: Logging mit Message Driven Beans Neben der Integration von J2EE-Anwendungen in existierende Systeme (z.B. Workflowsysteme) oder der Anbindung von existierenden Systemen als Informationsquelle für J2EE-Anwendungen, bietet sich JMS auch für die Kommunikation zwischen den serverseitigen Komponenten innerhalb einer J2EEAnwendung an. Da in einer verteilten Anwendung ein lokales Logging ungeeignet erscheint, könnte beispielsweise das Logging der serverseitigen Klassen über ein MDB laufen. D.h. ein Logging-Eintrag wird von den Anwendungsklassen in Form einer JMS-Message , bzw. über das Logging-API, lokal erzeugt und an ein MDB versendet. Dieses MDB ist die Anlaufstelle für alle Logging-Einträge, und bildet so eine Art Zwischenpuffer für die eingehenden Logging-Einträge. Die Pufferung der Logging-Einträge entsteht auf Grund der Tatsache, dass ein Application-Server mehrere Instanzen eines MDB erzeugen kann. Für die Anwendungsklasse, also das Session oder Entity Bean ergibt sich dadurch der bereits angesprochene Laufzeitvorteil, da die Logging-Einträge nicht über eine Methode eines Remote Interface abgesetzt werden müssen, und die Anwendungsklasse somit auch nicht die vollständige Bearbeitung des Logging-Eintrags abwarten muss. Im MDB kann nun die vergleichsweise mehr Zeit in Anspruch nehmende Behandlung des LoggingEintrags durchgeführt werden. Mehraufwand ist bei diesem Ansatz dafür bei die Verwendung von Zeitstempeln in einem Logging-Eintrag notwendig. Damit diese weiterhin in der korrekten zeitlichen Reihenfolge ausgewertet werden können, kann nicht die Zeit verwendet werden, zu der der LoggingEintrag in der Anwendungsklasse ausgelöst wird. Die Anwendungsklassen können sich in diesem Fall auf unterschiedlichen Server befinden, für die nicht zwingend eine gemeinsame Systemzeit verfügbar ist. Auch die Empfangszeit eines Logging-Eintrags über die JMS-Message im MDB ist nicht brauchbar, da JMS keine zeitlichen Zusicherungen, was das tatsächliche Versenden der JMS-Message und deren Zustellung durch den JMS-Provider angeht, spezifiziert. Nach Überwindung dieser Schwierigkeiten ist das Logging über JMS in verteilten Anwendungen aber ein guter Ansatz.

Kölsch & Altmann GmbH, Juli 2005