4 Message-Driven Beans - Institut für Wirtschaftsinformatik

Westfälische Wilhelms-Universität Münster

Ausarbeitung

Message-Driven Beans und Java Message Service (JMS) im Rahmen des Seminars „Softwaretechnik“

Denis Westermeyer

Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl.-Wirt.Inform. Christoph Lembeck Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

Inhaltsverzeichnis 1

Einleitung................................................................................................................... 3

2

Grundlagen ................................................................................................................ 4

3

2.1

Enterprise JavaBeans ........................................................................................ 4

2.2

Message-oriented Middleware.......................................................................... 5

Java Message Service ................................................................................................ 6 3.1

Eigenschaften.................................................................................................... 6

3.2

Übermittlungsarten ........................................................................................... 7

3.2.1 3.2.2 3.2.3

4

Publish-and-Subscribe .................................................................................. 7 Point-to-Point................................................................................................ 8 Request/Reply............................................................................................... 9

3.3

Nachrichtenarten............................................................................................... 9

3.4

Java Message Service API.............................................................................. 10

Message-Driven Beans ............................................................................................ 12 4.1

Abgrenzung von anderen Beantypen.............................................................. 12

4.2

Aufbau einer Message-Driven Bean............................................................... 13

4.2.1 4.2.2 4.2.3 4.2.4

Vorbereitungen ........................................................................................... 13 Implementierung der MDB......................................................................... 14 Bereitstellen des Deployment Descriptors.................................................. 15 Implementierung des Clientprogramms...................................................... 17

4.3

Lebenszyklus .................................................................................................. 18

4.4

Mögliche Problemquellen............................................................................... 19

4.5

Fortgeschrittene Konzepte .............................................................................. 20

5

Zusammenfassung ................................................................................................... 21

6

Literaturverzeichnis ................................................................................................. 22

2

Kapitel 1: Einleitung

1 Einleitung Enterprise JavaBeans haben sich im Laufe der letzten Jahre immer mehr als Lösung für unternehmensspezifische Software positioniert. Neue Systeme fußen häufig auf Altsystemen (Legacy-Systemen), mit denen sie in Kontakt bleiben. Außerdem wird durch

die

Netzbasierte

Infrastruktur

der

Nachrichtenaustausch

zwischen

verschiedensten Anwendungen nötig. Das ist sowohl synchron mittels Remote Procedure Calls als auch asynchron möglich. Der asynchrone Nachrichtenaustausch wird

durch

Message-oriented

Middleware

realisiert,

welche

die

eigentliche

Nachrichtenübermittlung übernimmt. Auf dieser Basis setzt der Java Message Service auf, der wiederum die Grundlage für den Nachrichtenaustausch mit Enterprise JavaBeans bildet. Ein recht neuer Beantyp, die Message-Driven Bean, kann nicht nur Nachrichten vom Java Message Service entgegennehmen, sondern auch selbst versenden. Auf den folgenden Seiten sollen zunächst ein paar Grundlagen vorgestellt werden, bevor anschließend der Umgang mit dem Java Message Service sowie Message-Driven Beans gezeigt wird.

3

Kapitel 2: Grundlagen

2 Grundlagen 2.1 Enterprise JavaBeans Enterprise JavaBeans (EJB) sind eine Javabasierte Middleware für objektorientierte Anwendungen und gehören damit in die Schicht der Geschäftslogik einer Drei- oder Vierschichtenarchitektur. Die Komponenten (Beans) werden vom so genannten Container bereitgestellt. Dieser Container (z.B. JBoss, IBM Websphere…) bietet einige Dienste an. Darunter fallen unter anderem die Verwaltung und Suche von Beans mit dem Java Naming and Directory Interface (JNDI), die Ressourcenverwaltung, Transaktionen oder der Zugriff auf entfernte Objekte. EJBs bestehen aus mehreren Beantypen, die im Folgenden kurz vorgestellt werden sollen [SE204]. Entity Beans Entity Beans bewahren den Zustand über eine Sitzung hinaus, das heißt, Daten werden in einer Datenbank hinterlegt, die später wieder eindeutig einem Client zugeordnet werden können. Darüber hinaus kapseln sie die persistenten Daten, indem sie den indirekten Zugriff auf eine Datenbank und die darin enthaltenen Daten zur Verfügung stellen. Nur Entity Beans können direkt auf die Datenbank zugreifen, was Vorteile beispielsweise hinsichtlich der Sicherheit und Integrität der Daten bietet. Session Beans Session Beans bilden den eigentlichen Geschäftsvorfall ab. Sie sind nicht persistent und bieten den Zugriff auf sich per RMI-IIOP (Java Remote Method Invocation over the Internet Inter-ORB-Protocol) an. Es gibt zwei Ausprägungen bei Session Beans. Die eine ist zustandslos und kann, nachdem sie einen Geschäftsvorfall für einen Client abgearbeitet hat, sofort von einem anderen Client genutzt werden. Die andere Art ist zustandsbehaftet und behält ihren Zustand während der gesamten Sitzung bei, nicht aber darüber hinaus. Damit könnte beispielsweise der Warenkorb eines Onlineshops abgebildet werden.

4

Kapitel 2: Grundlagen Message-Driven Beans Die Message-Driven Beans (MDBs) sind ein Novum seit EJB Version 2.0. Diese Beans können via Java Message Service (JMS) Nachrichten empfangen und daraufhin Aktionen unternehmen. Sie sollen im Verlauf der Arbeit noch genauer betrachtet werden. Jede Bean mit Ausnahme der MDB besitzt ein Remote Interface, das die Geschäftsmethoden

bereitstellt

sowie

ein

Home

Interface,

welches

Verwaltungsoperationen anbietet, beispielsweise das Erzeugen oder Löschen einer Bean. Die Beanklasse implementiert die Verwaltungs- und Geschäftsmethoden. Zudem muss jede Bean im so genannten Deployment Descriptor beschrieben werden. Der Deployment Descriptor ist ein XML-Dokument (eXtensible Markup Languange), das die Konfiguration einer Bean unter anderem bezüglich Persistenz, Transaktionen und Primärschlüssel enthält. Der gesamte Programmcode wird in einer .jar-Datei abgelegt und später beim Deployment vom Container wie im Deployment Descriptor angegeben konfiguriert und bereitgestellt.

2.2 Message-oriented Middleware Message-oriented Middleware (MOM) bietet den Nachrichtenaustausch zwischen Programmen an [JMS01 S. 7f], ähnlich den Remote Procedure Calls (RPC). Allerdings wird der Nachrichtenversand asynchron vorgenommen, was den Vorteil bietet, dass der Sender der Nachricht nicht erst auf die Aktion des Empfängers warten muss, demzufolge geblockt wird, wie das bei den synchronen RPC-Aufrufen der Fall ist. Der Sender kann sofort andere Aufgaben wahrnehmen, nachdem die Nachricht verschickt wurde. Da es keine von Seiten Suns implementierte Nachrichtenübermittlung abgesehen von synchroner Kommunikation durch RMI gibt, bietet dies jeder Hersteller über eine eigene API (Application Programming Interface) an. Damit sind die auf der einen Plattform entwickelten Javaprogramme auf der eines anderen Herstellers nicht unbedingt lauffähig, da dieser meist eine eigene nicht kompatible API bereitstellt [MEJB02 S. 203].

5

Kapitel 3: Java Message Service

3 Java Message Service 3.1 Eigenschaften Aus dem Grund, dass Programme, welche für eine MOM des einen Herstellers programmiert wurden, nicht unbedingt auch auf der MOM eines anderen laufen, hat Sun mit den Herstellern der Entwicklungsumgebungen den Java Message Service entwickelt. Dieser setzt auf den Herstellerspezifischen Middleware-Systemen auf, aber bietet dem Programmierer oder Entwickler eine einheitliche Schnittstelle. Vergleichbar mit JMS ist die Java Database Connectivity (JDBC), welche ebenfalls eine einheitliche Schnittstelle bietet, in diesem Fall auf relationale Datenbanken, oder aber RPC

[JMS01

S.

9f].

Beide

abstrahieren

die

jeweils

darunter

liegenden

herstellerspezifischen APIs der zugrunde liegenden Systeme und ersparen dem Programmierer die Mühe, sich in viele verschiedene Systeme einzuarbeiten. Einer der großen Vorteile beim Versenden von Nachrichten mittels JMS ist der, dass diese asynchron verarbeitet werden. Das bedeutet, dass der Versender nicht auf eine Antwort warten muss. Bei Java RMI liegt der Fall anders, dort muss eine Antwort erfolgen, was den Versender von der Verfügbarkeit des EJB Servers abhängig macht. Fällt dieser in der Zwischenzeit aus, so wartet der Versender mitunter sehr lange auf eine Antwort. Natürlich kann man auch Timeouts einsetzen, die den Versender davor bewahren lange Zeit auf eine nie erfolgende Antwort zu hoffen. Trotzdem würde der Sender einige Zeit abwarten, bevor er fortfahren könnte. Bei JMS ist der Ablauf so, dass der Versender sich direkt nach dem Versand an den JMS-Server anderen Aufgaben zuwenden kann. Der JMS-Server ist dann dafür verantwortlich, die Nachricht dem richtigen Empfänger zuzuschicken. Ein weiterer Vorteil liegt darin, dass Sender und Empfänger nicht zwangsläufig zur gleichen Zeit laufen müssen. Ist der Empfänger zwischenzeitig nicht erreichbar, so werden auflaufende Nachrichten vom JMS-Server gespeichert und sobald der Empfänger wieder bereit ist, verschickt [EJB02 S. 372]. Das ist allerdings nur der Fall, wenn die MOM die Auslieferung garantieren (guaranteed delivery) kann. Auch ein Ausfall des JMS-Servers kann aufgefangen werden, wenn der Versender seine abgehenden Nachrichten ebenfalls so lange aufbewahrt, bis der Server wieder verfügbar ist (store-and-forward). Eine andere Spielart ist die Bestätigung der Konsumierung einer 6

Kapitel 3: Java Message Service Nachricht (certified message delivery). Dabei wird eine Bestätigung an den Versender geschickt [MEJB02 S. 204] Da der JMS-Server zwischen die miteinander kommunizierenden Systeme geschaltet wird, weiß der Versender auf der einen Seite nicht, wer seine Nachricht empfangen wird und auf der Seite kann auch der Empfänger nicht nachvollziehen, wer diese Nachricht verschickt hat. Dieses mögliche sicherheitstechnische Problem kann man zwar durch eine Authentifizierung gegenüber dem JMS-Server abmildern, aber trotz dieser wird der Sicherheitskontext der Nachricht nicht übermittelt. Das ist aber so gewollt, da Sender und Empfänger häufig in verschiedenen Sicherheitszonen arbeiten.

3.2 Übermittlungsarten 3.2.1 Publish-and-Subscribe Das Prinzip des Publish-and-Subscribe (Pub/Sub) ist ähnlich dem des Radios. Die Radiostationen senden auf verschiedenen Kanälen. Jeder Nutzer kann sich eine Radiofrequenz aussuchen und die dortige Sendung empfangen. Wechselt ein Nutzer die Frequenz oder schaltet sein Radio ab, so verpasst er natürlich alles, was dort in der Zwischenzeit auf dem Kanal passiert. Dass mehrere Produzenten auf einem Kanal senden, kann man sich wie Live-Reportagen vorstellen, die an verschiedenen Orten stattfinden können und nacheinander gesendet werden. Pub/Sub arbeitet nach dem Push-Prinzip und bildet eine n:n-Verbindung zwischen den Sendern (Produzenten) und Empfängern (Konsumenten) ab. Die Produzenten und Konsumenten kennen sich nicht, denn zwischen beiden sitzt der Mittelsmann, also das MOM-System, auf dem der JMS-Server aufbaut. Beide greifen aber auf denselben virtuellen Kanal zu, der Topic (oder Thema) genannt wird. Jeder potentielle Konsument kann sich zu einem Thema einschreiben und erhält dann, sobald eine Nachricht zu diesem Thema versandt wird, eine Kopie davon. Normalerweise sind Produzenten und Konsumenten voneinander unabhängig, da die Nachrichten über das dazwischen liegende MOM-System verschickt werden. Es gibt aber Fälle, wo die eben beschriebenen certified message delivery oder guaranteed delivery erwünscht sind. [EJB02 S. 373 und MEJB02 S. 204f]

7

Kapitel 3: Java Message Service

Produzent1

Konsument1 Nachricht1

Nachricht1

Nachricht2 Topic

Nachricht2 Nachricht1

Nachricht2 Produzent2

Konsument2

Abbildung 1: Pub/Sub mit 2 Produzenten und 2 Konsumenten

Am Beispiel [Abbildung 1] kann man erkennen, dass der Produzent1 seine Nachricht etwas früher als Produzent2 schickt, da die Sprechblase etwas weiter am Kopf des Pfeils zum MOM sitzt. Diese Nachricht wird daher auch vom MOM als erstes an beide Konsumenten dieses Topics gesendet. Erst im Anschluss wird die 2. Nachricht verschickt.

3.2.2 Point-to-Point Beim Point-to-Point (PTP) gibt es im Vergleich zum Pub/Sub nicht mehrere Konsumenten pro Nachricht, sondern die eingehenden Nachrichten werden in einer Queue

gesammelt

und

nur

jeweils

an

einen

Konsumenten

versandt.

Ein

eingeschriebener Konsument muss das System fragen (Pull), ob eine neue Nachricht vorhanden ist. Wenn dem so ist, dann versendet es meist nach dem First-in-first-outPrinzip (FIFO) die an erster Stelle in der Queue befindliche Nachricht an den Konsument und löscht diese aus der Queue. Es kann aber auch nach anderen Prinzipien vorgegangen werden. Denkbar wäre z.B., dass Nachrichten eine gewisse Priorität besitzen, die dann die Reihenfolge abbildet. Nach dem Versand einer Nachricht kann kein anderer Konsument diese mehr abholen. Dadurch ist es möglich mit mehreren parallelen Servern die Verarbeitung im Gegensatz zum Pub/Sub deutlich zu beschleunigen [MEJB02 S. 226], da bei letzterem jede Nachricht auf jedem Server verarbeitet werden muss. Als Beispiel könnte man sich ein Musikportal vorstellen. Ein Kunde, der eine bestimmte Musikdatei herunterladen möchte, schickt eine Nachricht an den JMS8

Kapitel 3: Java Message Service Server. Der schickt diese an einen gerade freien Server (Load-Balancing), der im Anschluss die Datei dem Kunden zusendet, was wiederum über den JMS-Server mittels PTP erfolgen könnte. Es besteht die Möglichkeit, auch einen Push- anstelle des Pull-Services anzubieten [EJB02 S. 373], der jedoch viele Vorteile des PTP-Prinzips vergibt.

Produzent1

Konsument1 Nachricht1

Nachricht1 Queue

Nachricht2

Nachricht2 Produzent2

Konsument2

Abbildung 2: PTP mit 2 Produzenten und 2 Konsumenten Im Beispiel [Abbildung 2] gibt es wieder zwei Produzenten, die jeweils eine Nachricht abschicken und wiederum wurde Nachricht1 zuerst versandt. Die Queue liefert hier nach dem FIFO-Prinzip aus, sodass Konsument1, der als erstes nach neuen Nachrichten fragt, Nachricht1 zugesandt bekommt. Danach wird Nachricht1 aus der Queue gelöscht und sobald Konsument2 anfragt, wird ihm die Nachricht2 geschickt.

3.2.3 Request/Reply Request/Reply wird seltener genutzt, da es im Grunde dasselbe Verhalten wie RMI anbietet. Der Produzent muss somit mit dem weiteren Programmablauf so lange warten, bis er eine Antwort vom Konsumenten erhält. Häufig wird dieses Prinzip mit Hilfe der beiden oben genannten Methoden Pub/Sub bzw. PTP implementiert. [MEJB02 S. 206]

3.3 Nachrichtenarten Eine Nachricht ist ein Objekt das aus zwei Teilen besteht; dem Header und dem Body. Im Header werden Informationen zum Versand und Metadaten angegeben, der Body enthält die eigentliche Nachricht, die mehrere Formen wie beispielsweise Text oder 9

Kapitel 3: Java Message Service Byteströme

haben

kann.

In

der

JMS

API

werden

einige

Arten

von

Nachrichteninterfaces definiert, die einmal kurz vorgestellt werden sollen [JMS01 S. 42ff]. TextMessage

ist

ein

einfacher

java.lang.String.

Die

MapMessage

enthält

Schlüssel/Wert-Paare (z.B. „Name“, „Anton“). Dabei enthalten die Schlüssel Strings und die Werte primitive Datentypen. Die Werte können dann über den Schlüssel ausgelesen werden. Eine BytesMessage enthält ein Array mit primitiven Bytes und die Interpretation dieser Daten muss der Empfänger übernehmen. Das Interface kann beispielsweise benutzt werden, um Dateien im Rohformat zu übermitteln (z.B. MP3Dateien). Die StreamMessage ist ähnlich der ByteMessage. Sie enthält aber einen Strom primitiver Datentypen. Die ObjectMessage enthält ein serialisierbares Java Objekt. Das Message-Interface enthält keine Nutzdaten und dient meist nur dazu, Ereignisse (Events) auszulösen. Hier werden nur die Headerdaten und keine Nutzdaten gesendet.

3.4 Java Message Service API Um als Client den JMS-Dienst nutzen zu können, sind einige Schritte notwendig, die im Folgenden vorgestellt werden sollen [MEJB02 S. 206f]. 1. JMS-Treiber finden und einbinden Der produktspezifische JMS-Treiber wird über JNDI lokalisiert und eingebunden. Der Treiber wird ConnectionFactory genannt. 2. JMS-Verbindung aufbauen Mit Hilfe der ConnectionFactory wird eine Verbindung (Connection) zum JMSProvider

aufgebaut.

Die

Connection

managt

die

zugrunde

liegende

Netzwerkverbindung. 3. JMS-Sitzung eröffnen Eine Sitzung wird mit dem Hilfsobjekt Session zum empfangen bzw. versenden von Nachrichten benötigt und mit Hilfe der Connection aufgebaut. Außerdem können damit Nachrichten in Transaktionen gekapselt werden. 4. Suche des Topics bzw. der Queue Eine JMS Destination bezeichnet den Kanal, über den Nachrichten empfangen bzw. gesendet werden können. Dieser wird mittels JNDI ermittelt. 10

Kapitel 3: Java Message Service 5. Erstellen eines Produzenten bzw. Konsumenten Sollen Nachrichten gesendet werden, so wird ein Produzent (Producer) erstellt. Im umgekehrten Fall wird ein Konsument (Consumer) aufgesetzt. Die Erstellung wird mittels der Session und Destination vorgenommen. 6. Senden bzw. empfangen der Nachricht Um eine Nachricht mit dem Produzenten zu verschicken, muss die Nachricht erst aufgebaut werden, bevor der Versand stattfinden kann. Im Empfangsfalle muss nach Erhalt der Nachricht durch den Konsumenten geschaut werden, was in der Nachricht steht. Die oben kursiv geschriebenen Interfaces werden im Anwendungsfall des Topics oder der Queue durch die der Art der Nachrichtenübermittlung entsprechenden Interfaces [Tabelle 1] ersetzt. Eltern-Interface

Pub/Sub

PTP

ConnectionFactory

QueueConnectionFactory

TopicConnectionFactory

Connection

QueueConnection

TopicConnection

Destination

Queue

Topic

Session

QueueSession

TopicSession

MessageProducer

QueueSender

TopicPublisher

MessageConsumer

QueueReceiver, QueueBrowser

TopicSubscriber

Tabelle 1: Interfaceausprägungen für Pub/Sub und PTP [MEJB02 S. 208]

11

Kapitel 4: Message-Driven Beans

4 Message-Driven Beans 4.1 Abgrenzung von anderen Beantypen Message-Driven Beans verarbeiten JMS-Nachrichten [MEJB02 S. 212] und können als einziger Beantyp selbst JMS-Nachrichten erstellen. MDBs haben im Unterschied zu den bisherigen Beantypen kein Home-, LocalHome-, Remote- oder Local-Interface. Es ist darum nicht möglich, eine MDB über RMI zu erreichen und eine bestimmte Handlung ausführen zu lassen. Die einzige Möglichkeit ihnen Aufgaben zu geben besteht darin, ihnen eine JMS-Nachricht zukommen zu lassen. Dabei kann eine MDB entweder Nachrichten eines Topics oder einer Queue empfangen. Rückgabewert MDBs haben keinen Rückgabewert. Der Grund liegt darin, dass MDBs und der Produzent der Nachricht voneinander unabhängig sein sollen, der Produzent demnach schon mit seinem Programm fort fährt und nicht auf eine Rückgabe wartet. Trotzdem ist es möglich, diesem eine Bestätigung (certified message delivery) zukommen zu lassen. Exceptions Einer MDB ist es nicht möglich, Exceptions auszulösen, die an den Produzenten zurückgeschickt werden, da dieser, wie oben schon beschrieben, nicht auf Ergebnisse der MDB wartet. Eine MDB kann nur System-Exceptions nutzen, die vom Container entgegengenommen und weiterverarbeitet werden. Dabei sollte darauf geachtet werden, dass im Falle einer Exception die ejbRemove()-Methode nicht mehr aufgerufen wird. Folglich sind eventuelle Aufräumarbeiten vor dem Werfen der Exception vorzunehmen. Geschäftsmethode MDBs haben nur eine Geschäftsmethode, die onMessage() heißt. Da sie nicht weiß, was für einen Nachrichtentyp sie übermittelt bekommt, muss sie zuerst überprüfen, ob sie den Nachrichtentyp übermittelt bekommen hat, den sie erwartet. Dies wird meist mit dem instanceOf-Operator realisiert. Stimmt der empfangene Nachrichtentyp mit dem erwarteten überein, so wird die eingegangene Nachricht in den entsprechenden Typ umgewandelt (gecastet). Wenn der Typ falsch ist, terminiert die Methode häufig einfach nur. Ein Problem ist, dass nicht schon zur Compile-Zeit feststeht, welchen 12

Kapitel 4: Message-Driven Beans Nachrichtentyp sie übermittelt bekommen wird. Das ist bei den anderen Beans möglich, da dort nur durch die Parameter einer Methode definierten Datentypen genutzt werden dürfen. Zustandslosigkeit MDBs sind zustandslos. Ansonsten könnten Nachrichten nicht mehr an einen Cluster mehrerer Container mit baugleichen MDB-Instanzen geschickt werden, da eine Nachricht möglicherweise nur an eine bestimmte Instanz mit einem gegebenen Zustand geschickt werden darf. Da es aber keinen Zustand für sie gibt, ist es dem Container möglich, alle auf Vorrat gehaltenen MDB-Instanzen auch gleichwertig zu behandeln. Insofern ist es nicht relevant, welche Instanz welche Nachricht bekommt. Dauerhafter vs. zeitweiser Konsum MDBs können sich dauerhaft oder nur zeitweise als Konsumenten zu einem Topic oder einer Queue anmelden. Der Container übernimmt stellvertretend die Einschreibung, damit er die eingehenden Nachrichten den im Pool befindlichen MDBs zuteilen kann. Er nimmt dabei jede Nachricht, auch die eines Topics nur ein Mal stellvertretend für seine MDB-Instanzen ab, sodass dieselbe Nachricht nicht von mehreren Instanzen eines Containers konsumiert werden können. Sollen Nachrichten mehrfach verarbeitet werden, so ist ein zweiter Container mit eigenen Instanzen derselben MDB notwendig. Der Vorteil der dauerhaften Einschreibung liegt darin, dass die Nachrichten auch bei einer Nichtverfügbarkeit des Servers, auf dem die MDB liegt, vom JMS-Server gespeichert werden und sobald er wieder verfügbar ist, abgeholt werden können (PTP) oder aber zugesandt werden (Pub/Sub). Handelt es sich nur um eine zeitweise Einschreibung, so gehen alle in der Zwischenzeit aufgelaufenen Nachrichten verloren. [MEJB02 S. 213, EJB02 S. 377]

4.2 Aufbau einer Message-Driven Bean 4.2.1 Vorbereitungen Um den Aufbau und die Interaktion der einzelnen Komponenten besser darstellen zu können soll hier das Beispiel eines Internetradios angeführt werden. Die Nutzer können in einem Webformular einen beliebigen Titel und/oder Interpreten angeben, der dann,

13

Kapitel 4: Message-Driven Beans wenn er in der Datenbank gefunden wurde in eine Playlist aufgenommen und abgespielt wird, sobald er an der Reihe ist. Für die Implementierung einer MDB werden zwei Interfaces benötigt. Das MessageListener-Interface stellt die onMessage()-Methode zur Verfügung. Das Interface MessageDrivenBean bietet die beiden Methoden ejbRemove() und setMessageDrivenContext() an. Es werden hier separate Interfaces benutzt, da man sich vorbehalten möchte, in Zukunft auch andere Nachrichten als die eines JMS-Servers mit MDBs zu verarbeiten. Diese Nachrichtenarten, wie z.B. SMTP (Simple Mail Transport Protocol), werden nicht die JMS-spezifische Methode onMessage() benutzen, sondern eigene Methoden mitbringen. Deshalb wurde das Interface MessagDrivenBean von der Art der Nachricht durch den MessageListener entkoppelt [EJB02 S. 383].

4.2.2 Implementierung der MDB Nun folgt der Code für eine MDB, der das oben geschilderte Beispiel eines Internetradios illustrieren soll. package beispiele; import javax.ejb.*; import javax.jms.*; // Die Internet-Radio-Bean public class RadioBean implements MessageDrivenBean, MessageListener { protected MessageDrivenContext kontext; // Übergibt der Bean-Instanz den aktuellen Kontext. public void setMessageDrivenContext(MessageDrivenContext ctx) { kontext = ctx; } // MDB Initialisieren. public void ejbCreate() { // Ausgabe zum Mitloggen System.err.println("Es wurde ejbCreate() aufgerufen"); } // Die einzige Geschäftsmethode der MDB public void onMessage(Message msg) { // Es dürfen hier nur Textnachrichten eintreffen. if (msg instanceOf TextMessage) { TextMessage nachricht = (TextMessage) msg; try { String text = nachricht.getText(); // Nun muss hier der Code für das Aufschlüsseln der // Textnachricht in die Teile Interpret und Titel // folgen. System.err.println("Aufschlüsseln erfolgreich."); b.w.

14

Kapitel 4: Message-Driven Beans // Im Anschluss daran wird nach // den eingegebenen Schlüsselwörtern gesucht. System.err.println("Suche nach: " + text); // Wird ein passendes Stück gefunden, System.err.println(text + " gefunden."); // so wird es in die Playlist aufgenommen System.err.println(text + "aufgenommen"); } catch(JMSException e) { e.printStackTrace(); } } } // Löschen der Bean public void ejbRemove() { System.err.println("Es wurde ejbRemove() aufgerufen"); } }

Programmcode 1: Implementierung einer MDB

Die Geschäftsmethode [Programmcode 1] versucht, eine eingegangene Textnachricht, die das Format „Titel=’’, Interpret=’’“ haben soll, weiter zu verarbeiten. Zunächst soll nach dem Titel und Interpreten gesucht werden. Ist die Suche erfolgreich, so wird der Titel in die Playlist eingereiht. Die Suche könnte durch eine zustandslose Session Bean realisiert werden, die den Primary Key des Musikstücks oder Null bei einer erfolglosen Suche zurückgibt. Anschließend könnte die MDB den Primary Key des Musikstücks als JMS-Nachricht selber an eine Queue senden, die eine Playlist mit gültigen Titeln darstellt. Damit wäre der Auftrag der MDB erledigt. Sollten nicht erfolgreiche Suchen oder ungültige Textnachrichten eintreffen, so soll einfach terminiert werden, ohne Exceptions zu werfen, die sowieso nur System-Exceptions sein dürften. Die Nachrichten in der Queue, welche die Playlist darstellt, wird von einer anderen MDB in Empfang genommen, die nur eine einzige Instanz haben darf, da die Titel ja nicht parallel abgespielt werden sollen. Sie ruft dann die zum Primary Key gehörende Entity Bean über RMI auf, die beispielsweise die Methode abspielen() bieten soll.

4.2.3 Bereitstellen des Deployment Descriptors Es sind nur wenige Tags für den Deployment Descriptor einer MDB im Gegensatz zu anderen Beantypen anwendbar. Dafür gibt es aber auch einige Tags, die speziell für MDBs vorgesehen sind [EJB02 S. 386ff, MEJB02 S. 219ff].

15

Kapitel 4: Message-Driven Beans Der Message-Selector definiert, welche Eigenschaften Nachrichten haben müssen, die von dieser Bean verarbeitet werden sollen. Der Container kann dann schon im Vorfeld unerwünschte Nachrichten aussortieren und infolgedessen den Overhead verringern und die Performanz steigern. Das folgende Beispiel zeigt, dass nur Nachrichten, die dem Typ

„TextMessage“

entsprechen,

angenommen

werden:

„

JMSType=“TextMessage“ “. Es können auch kompliziertere SQLähnliche Statements verwendet werden. Der muss angegeben werden, wenn die Bean selbst Transaktionen steuert (bean-managed transactions). Denn im Gegensatz zu containermanaged transactions wird beim Rollback (Wiederherstellung des Zustands, der vor der gescheiterten Transaktion galt) einer Transaktion nicht die gerade ausgelieferte Nachricht zurück in die Queue gelegt, da die Konsumierung der Nachricht außerhalb der Transaktion liegt. Deshalb muss im Fall der bean-managed transactions dem Container mitgeteilt werden, dass er Nachrichten bestätigen muss. Beim Autoacknowledge wird der Erhalt einer Nachricht bestätigt, wenn die onMessage()Methode ordnungsgemäß ausgeführt wurde. Wird Dups-ok-acknowledge gewählt, so kann der Container selbst entscheiden, wann er den Erhalt einer Nachricht bestätigt. Das kann dazu führen, dass der JMS-Server annimmt, die Nachricht sei nicht angekommen und schickt diese nochmals. Deswegen empfiehlt sich diese Einstellung nur, wenn man mit doppelten Nachrichten umgehen kann. Der -Tag gibt an, ob es sich um ein Topic (javax.jms.Topic) oder eine Queue (javax.jms.Queue) handeln soll, bei der sich die Bean einschreibt. Sofern es sich um ein Topic handelt, kann noch ein zusätzliches -Tag benutzt werden, das entweder durable oder nondurable sein darf, und angibt, ob die Bean dauerhaft oder nur zeitweise eingeschrieben sein soll.

16

Kapitel 4: Message-Driven Beans

Im Folgenden ein beispielhafter Deployment Descriptor

Internet-Radio-Bean Beispiele.RadioBean Container

javax.jms.Queue

Programmcode 2: Deployment Descriptor einer Message-Driven Bean

Es fällt auf, dass nur angegeben wird, welche Art der Nachrichtenübermittlung gewählt wird. Nicht erwähnt ist, welche genaue Destination verwendet werden soll. Dies wird bewusst so gemacht, damit Beans zwischen Applikationsservern portierbar bleiben, da die Namen der Destinationen bei jedem Server unterschiedlich lauten [MEJB02 S. 223].

4.2.4 Implementierung des Clientprogramms Der Client kann wie unten implementiert werden. Die einzelnen Schritte werden analog zum weiter oben [Kap. 3.4] beschriebenen Vorgehen durchgeführt. Da der Client einen Musikwunsch abschicken kann, dieser aber nicht von mehr als einer Bean bearbeitet werden soll, wird PTP genutzt, also eine Queue benötigt. import javax.naming.*; import javax.jms.*; import java.util.*; public class RadioClient{ public static void main (String[] args) throws Exception { // 1. Initialisierung des Kontextes, also des JNDI Context kontext = new InitialContext(System.getProperties()); // 2. JMS-Treiber finden und einbinden QueueConnectionFactory fabrik =(QueueConnectionFactory) kontext.lookup("javax.jms.QueueConnectionFactory"); // 3. JMS-Verbindung aufbauen QueueConnection verbindung = fabrik.createQueueConnection();

b.w.

17

Kapitel 4: Message-Driven Beans // 4. JMS-Sitzung eröffnen QueueSession sitzung = verbindung.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); // 5. Suche der Destination (hier: Queue) via JNDI Queue inetradio = (Queue) kontext.lookup("Internet-Radio"); // Erstellen des Nachrichtenproduzenten QueuePublisher versender = sitzung.createPublisher(inetradio); // 6. Versand einer Nachricht, hier eines Musikwunsches. TextMessage nachricht = session.createTextMessage(); nachricht.setText("Titel=’SuperSound’, Interpret=’Rambazamba’"); versender.publish(nachricht); } }

Programmcode 3: Der Internetradio Client

4.3 Lebenszyklus MDBs haben einen sehr einfachen Lebenszyklus. Eine MDB befindet sich in einem von zwei Zuständen [Abbildung 3]. Der erste Zustand „Does Not Exist“ gilt, wenn die Bean noch nicht instanziiert wurde. Um in den Zustand „Pooled“ zu gelangen, muss der Container der Bean zuerst eine neue Instanz der Bean erzeugen, ihr danach den aktuellen Kontext übergeben und anschließend mit ejbCreate() der Bean die Möglichkeit geben, selbst weitere Aktionen vorzunehmen.

newInstance() setMessageDrivenContext()

ejbRemove()

ejbCreate()

onMessage()

Abbildung 3: Lebenszyklus einer Message-Driven Bean [MEJB02 S. 217 bzw. EJB02 S. 395]

Beim Start des Applikationsservers werden meist schon einige Instanzen einer MDB generiert und im Pool vorgehalten, damit der aufwändige Prozess der Instanziierung nicht erst dann beginnen muss, wenn die erste Nachricht eintrifft. Kommen so viele Nachrichten auf einmal, dass der Vorrat an Instanzen nicht mehr ausreicht, so wird der 18

Kapitel 4: Message-Driven Beans Pool um weitere aufgestockt. Sobald zu viele Instanzen für zu wenige Nachrichten bestehen, werden überflüssige Instanzen dem Pool entnommen und zerstört, damit nicht unnötig viele Ressourcen belegt werden [EJB S. 395]. Diesen Auf- und Abbau kontrolliert der Container. Bei den Anbietern, die keinen Pool mit MDB-Instanzen vorhalten, werden diese meist für jede Nachricht generiert und wieder zerstört [EJB02 S. 395]. Die gepoolten Instanzen sind immer bereit, Nachrichten zu verarbeiten. Wird nun einer Instanz eine Nachricht übergeben, so kann sie während der Verarbeitung keine weiteren Nachrichten übernehmen. Sobald aber die onMessage()-Methode terminiert, der Verarbeitungsprozess demnach abgeschlossen ist, steht sie sofort wieder bereit, um neue Nachrichten anzunehmen. Bei jeder neuen Nachricht wird der Bean der aktuelle Kontext vom Container übergeben. Eine Instanz gelangt erst in den DoesNotExist-Status, wenn der Server diese nicht mehr benötigt.

Dabei

wird

die

ejbRemove()-Methode

aufgerufen,

die

einige

Aufräumarbeiten übernehmen kann. Allerdings ist die Lebensdauer einer MDB häufig sehr lang, sodass sie erst beim Herunterfahren des Servers oder wenn das Deployment zurückgezogen wird in den DoesNotExist-Status versetzt wird.

4.4 Mögliche Problemquellen Im Folgenden werden einige Probleme angesprochen, die bei der Verwendung von MDBs auftreten können [MEJB02 S. 225ff]. Es kann zum wiederholten Versand von bereits empfangenen Nachrichten kommen, wenn man den Container Transaktionen kontrollieren lässt (container-managed transactions). Der erneute Versand der Nachrichten kann auftreten, wenn die Transaktion, in welcher die Nachricht unter anderem an die MDB ausgeliefert wird, wieder und wieder fehlschlägt und jedes Mal ein Rollback durchgeführt wird. Ein Beispiel wäre ein Musikshop im Internet, wenn ein Nutzer sich gerade neu angemeldet hat, aber die Nachricht, diesen Nutzer anzulegen, noch nicht verarbeitet wurde, dieser aber schon die ersten Musikstücke herunterladen möchte. Seinen Bestellungen kann deshalb kein existierender Nutzer zugeordnet werden. Dabei wird die Nachricht wieder in die Queue des JMS-Servers eingereiht und sofort wieder abgeschickt. Das kann zu erheblichen Performanzverlusten bis hin zum Stillstand des 19

Kapitel 4: Message-Driven Beans Systems führen. Abhilfe kann z.B. die bean-managed transaction sein oder das Einfügen nicht bearbeiteter Nachrichten in eine spezielle Queue, die dann später abgearbeitet wird oder eine Nachricht wird, nachdem eine sie schon zum x. Mal nicht verarbeitet werden kann, beispielsweise gelöscht, um das System nicht unnötig zu belasten. Implizit wurde hier noch ein zweites Problem aufgezeigt, das in der nicht garantierten sequentiellen Abarbeitung von Nachrichten liegt. Der Kunde konnte im obigen Beispiel schon Musik bestellen, obwohl der Anmeldevorgang intern noch gar nicht abgeschlossen war. Der Container versucht zwar, darauf zu achten, aber spätestens bei einem Cluster mit mehreren konkurrierenden Containern ist es nicht mehr einfach zu gewährleisten, dass alle Nachrichten in richtiger Reihenfolge bearbeitet werden.

4.5 Fortgeschrittene Konzepte Es sollen nun ein paar Konzepte vorgestellt werden, die über die eigentliche Funktionalität von MDBs hinausgehen. Antworten an den Versender von Nachrichten sind laut der Spezifikation der EJBs nicht vorgesehen. Um dies aber trotzdem zu ermöglichen, natürlich wiederum asynchron, bietet es sich an, mit zwei Queues oder Topics zu arbeiten. Die eine Destination wird temporär geschaltet, um den Versand der Bestätigungen zu organisieren. Die andere wird wie gewohnt gehandhabt. Der Client erstellt eine temporäre Destination, die für die Dauer der Verbindung (Connection) aufrechterhalten wird. Dann verschickt der Client die Anfrage-Nachricht mit der Information der temporären Destination an den regulären Kanal, von wo aus sie an alle Konsumenten versand wird. Diese schicken dann an die temporäre Destination ihre Antwort. Diese Methodik ähnelt der certified message delivery, die schon im Kapitel 3.1 angesprochen wurde. Ein anderes Konzept wäre Load-Balancing mittels PTP zu realisieren, das beispielhaft schon im Kapitel 3.2.2 angesprochen wurde und eine optimale Auslastung der Netzinfrastruktur ermöglicht, da kein Applikationsserver außer Acht gelassen bzw. überlastet wird, denn diese melden sich selbstständig, sobald sie neue Aufgaben erfüllen können.

20

Kapitel 5: Zusammenfassung

5 Zusammenfassung Auf den vorhergehenden Seiten wurde zunächst der Java Message Service vorgestellt, der es ermöglicht unabhängig von der Message-oriented Middleware asynchron Nachrichten zu versenden und damit den Sender unabhängig von der Verfügbarkeit und Geschwindigkeit des Empfängers zu machen. Der Sender kann damit sofort mit seiner Arbeit fortfahren, ohne auf eine Antwort oder das Ende der Bearbeitung einer gestellten Aufgabe abzuwarten, wie es beispielsweise bei dem synchronen RMI der Fall wäre. Der JMS-Server bietet dazu verschiedenste Nachrichtentypen an, die mit unterschiedlichen Konzepten der Nachrichtenverteilung versand werden können. Die Message-Driven Beans wurden im Anschluss behandelt und können aufgrund einer eingehenden Nachricht vom JMS-Server bestimmte Aktionen durchführen. Dabei bedienen sie sich ihrer einzigen Geschäftsmethode, die Nachricht zu verarbeiten und möglicherweise selber neue Nachrichten an den JMS-Server zu versenden, was keine andere Enterprise JavaBean kann. Ein EJB Container kann dabei mehrere MDBInstanzen vorhalten, die parallel eingehende Nachrichten verarbeiten. Dadurch kann eine Nebenläufigkeit ermöglicht werden, ohne diese explizit zu programmieren. MDBs gestatten somit, dass sich verschiedenste Java-Anwendungen bzw. Anwendungen, die ebenfalls auf den JMS-Server zugreifen, gegenseitig Nachrichten zukommen lassen können, ohne aber ihren weiteren Verlauf von der Zielapplikation abhängig zu machen.

21

6 Literaturverzeichnis [EJB02]

Richard Monson-Haefel: Enterprise JavaBeans, 3rd ed., O'Reilly 2002.

[JMS01]

Richard Monson-Haefel, David A. Chappell: Java Message Service, 1st ed., O'Reilly 2001.

[JMS02]

Kim Haase: Java Message Service API Tutorial, Sun Microsystems Inc., 2002. Link: http://java.sun.com/products/jms/tutorial/.

[MEJB02] Ed Roman: Mastering Enterprise JavaBeans, 2nd ed., John Wiley, 2002. [SE204]

Herbert Kuchen: Vorlesung Software Engineering II, Kap. 2a S. 33ff, Institut für Wirtschaftsinformatik - Lehrstuhl Praktische Informatik in der Wirtschaft an der westfälischen Wilhelms-Universität Münster, 2004. Link: http://danae.uni-muenster.de/lehre/kuchen/SS04/SE2k2b.pdf.