WS 08/09 Blatt 3 – 03.12.2008 - Institut für Architektur von

Prof. Dr . Frank Leymann / Thorsten Scheibler
Institut für Architektur von Anwendungssystemen
Universität Stuttgart
Übungen
„Message-basierte Anwendungen“
WS 08/09
Blatt 3 – 03.12.2008
Aufgabe 3.1: Guaranteed Messaging und Transactions
Einige Quality of Services (QoS) können auch auf Session-Ebene (TopicSession,
QueueSession) gesetzt werden. Dazu gehört u.a. die Persistenz von Nachrichten,
„nicht dauerhafte“ bzw. „dauerhafte“ Abonnenten und einiges mehr. Ein
dauerhafter Abonnent erhält alle Nachrichten, auch wenn zwischenzeitlich die
Verbindung zum JMS Server abbricht. Welches Problem kann auftreten, wenn ein
Herausgeber eine nicht-persistente Nachricht versendet und der JMS Server
ausfällt, bevor er die Nachricht an den Abonnenten weiterleiten kann? In diesem
Zusammenhang ist es wichtig, dass Sie sich mit den unterschiedlichen
„Acknowledge Modes“ 1 vertraut machen (siehe Abbildung 5.1).
Abbildung 3.1: Normaler Ablauf mit persistenten Nachrichten
Warum kann der oben erwähnte Fehlerfall mit Hilfe von persistenten Nachrichten
nicht auftreten?
Eine Anwendung versendet eine Gruppe von Nachrichten. Erst nachdem die
letzte Nachricht versendet ist, soll der Empfänger damit beginnen die
Nachrichten zu verarbeiten- die bereits gesendeten Nachrichten hat er auch
empfangen, also lokal zwischen gespeichert. Die Kommunikation soll nicht in
einer JMS-Transaktion durchgeführt werden. Überlegen Sie sich, wie der
Empfänger erkennt, dass die Gruppe der Nachrichten komplett ist und er mit der
eigentlichen Verarbeitung beginnen kann.
1
Nachzulesen in der JMS-Spezifikation: http://java.sun.com/products/jms/docs.html
oder im Buch: JMS API Tutorial and Reference von Mark Happner et.al.
Seite 1 von 3
Message-basierte Anwendungen
WS 08/09
Übungsblatt 3
03.12.2008
Mehrere Nachrichten können auch in einer JMS-Transaktion ausgeführt werden
(Beispiel siehe Abbildung 5.2). Ein Request-Reply Schema, also eine SendenOperation gefolgt von einer Empfangen-Operation darf allerdings nicht
zusammen gruppiert werden. Warum ist dies der Fall?
Abbildung 3.2: Normaler Ablauf mit persistenten Nachrichten
Aufgabe 3.2: Entwicklung eines Publish-Subscribe Verbindung
Die in den vorangegangenen Aufgaben entwickelten Grundlagen werden nun in
einem praktischen Beispiel umgesetzt. Gegeben sei ein Börsensystem, das in
unregelmäßigen Abständen Börsenkurse einzelner Firmen per JMS auf einem
Server veröffentlicht (PubSub).
Entwickeln Sie zunächst die StockServer-Klasse, die sich mit einem Topic auf
einem Nachrichtensystem verbindet, im Anschluss JMS-Nachrichten generiert
und diese an das Topic veröffentlicht. Verwenden Sie als Nachrichtentyp eine
MapMessage.
Als Gegenpart wird die StockSubscriber-Klasse entwickelt. Diese Klasse schreibt
sich auf einem Topic ein und lauscht als MessageListener solange, bis eine neue
Nachricht eintrifft. Aus dieser Nachricht liest sie den Firmenname und den
Aktienkurs, um entsprechend des Inhaltes reagieren zu können (siehe nächste
Aufgabe). Die StockSubscriber-Klasse soll auch in einem Fehlerfall alle
versendeten Nachrichten des StockServers irgendwann erhalten. Erläutern Sie
außerdem, welche Einstellungen bzw. Konfigurationen am JMS Provider (JMS
Server) vorzunehmen sind.
Aufgabe 3.3: Entwicklung einer Point-to-Point Verbindung
Nachdem die StockSubscriber-Klasse Nachrichten entgegengenommen hat,
wertet Sie diese aus. Geht dabei der Kurs einer Aktie bis zu einem bestimmten
Wert zurück (100-90 €), versucht die Klasse Aktien der Firma zu verkaufen.
Erreicht der Wert einen bestimmten Minimalbetrag (10-1 €), werden die Aktien
gekauft.
Um dies zu simulieren wird die Klasse Sender implementiert. Sie verbindet sich
mit zwei Queues mit den Namen Buy_Queue und Sell_Queue (Point-to-Point),
erzeugt eine TextMessage mit Kundennummer, Anzahl der Aktien und Wert und
sendet diese an die entsprechende Queue.
Erläutern Sie außerdem, welche Einstellungen bzw. Konfigurationen am JMS
Provider (JMS Server) vorzunehmen sind.
Aufgabe 3.4: Entwicklung der Queue-Empfänger
Damit die Verkauf- bzw. Kaufnachrichten auch verarbeitet werden, wird ein
SellAgent bzw. BuyAgent entwickelt. Diese verbinden sich mit der jeweiligen
Queue, nehmen die Nachrichten entgegen und geben Sie auf der Konsole aus.
Stellen Sie den entsprechenden Quellcode auf.
Seite 2 von 3
Message-basierte Anwendungen
WS 08/09
Übungsblatt 3
03.12.2008
Aufgabe 3.5: Zusammenführen aller Teil zu einer Anwendung
Wenn Sie alle Teile implementiert haben, können Sie die komplette Anwendung
zusammenfügen. Dabei ergibt sich folgendes Bild:
Publish-Subscribe
Messaging
Point – to – Point
Messaging (Queues)
Messaging
Server
Messaging
Server
Subscriber
„DTAG“
Stock Quote
Stock Server
„DCAG“
Stock Quote
„MAN“
Stock Quote
DAX Topic
ck
Sto tes
o
Qu
Dax
Subscriber
Buy Queue
Buy
Message
Buy Agent
Sell Queue
Sell
Message
Sell Agent
Buy
Message
Buy or Sell
Sender
Sell
Message
Zur Ausführung müssen Sie zunächst ihren JMS-Provider konfigurieren. Im
Anschluss starten Sie den StockServer, der in unregelmäßigen Abständen
Aktienkurse unterschiedlicher Firmen veröffentlicht. Starten Sie im Anschluss den
StockSubscriber, der nach Erhalt von Nachrichten den Sender anstößt, der
wiederum Kaufen- oder Verkaufen-Nachrichten in die entsprechende Queue
stellt. Ein BuyAgent bzw. SellAgent empfängt diese Nachrichten und gibt eine
Meldung auf der Konsole aus.
Anmerkung zur Programmierung:
Falls sie nicht die Möglichkeit haben die Java Klassen am Computer zu
entwickeln, dürfen Sie eine Art Pseudo-Code schreiben. Verwenden Sie aber die
Methoden der Java- und JMS-Bibliotheken.
Seite 3 von 3