Prof. Dr . Frank Leymann / Thorsten Scheibler Institut für Architektur von Anwendungssystemen Universität Stuttgart Übungen „Message-basierte Anwendungen“ WS04/05 Blatt 4 und 5 – 16.01.2006 und 23.01.2006 Aufgabe 4.1 – JMS Properties JMS besitzt keine Vorkehrungen, um Sicherheit der Nachrichten zu gewährleisten. Sicherheit bedeutet dabei Authentifizierung des Senders und Verschlüsselung des eigentlichen Nachrichteninhalts. Erläutern Sie, wie mit Hilfe von JMS Properties die Nachrichten mit Informationen angereichert werden können, um Sicherheitsaspekte umsetzen zu können1. Erstellen Sie dazu ein geeignetes Protokoll, bei welchem zunächst der Benutzer authentifiziert und anschließend ein sicherer Kanal zum Server aufgebaut wird. Achten Sie darauf, dass keine sicherheitskritischen Daten (wie z.B. ein Passwort) unverschlüsselt übertragen werden. Aufgabe 4.2 – JMS Message Selectors Ein „Message Selector“ erlaubt einem JMS Konsumenten eingehende Nachrichten bereits frühzeitig zu filtern, bevor er sie (unnötigerweise) verarbeiten muss. Solche Selektoren verwenden dabei Headerfelder und Properties als Kriterien in bedingten Anweisungen. Im Folgenden werden zwei Szenarien beschrieben. Stellen Sie für jedes dieser Szenarien einen Selektor auf und erläutern Sie, welche Headerfelder dabei verwendet werden bzw. welche Properties die Nachricht enthalten muss. Ein Selektor ist dabei nichts anderes als ein boolscher Ausdruck, ähnlich der ‚where’ Klausel eines SQL Statements. Szenario 1: Eine Versicherungsanwendung möchte aus der großen Anzahl von Mängelbeschwerden, die als Nachrichten in einer Message Queue landen, alle diejenigen herausfiltern, die nicht älter als drei Wochen sind und nur von Chemikern oder Physikern stammen, die an der Universität Stuttgart angestellt sind. Szenario 2: Ein Hersteller möchte eine Mitteilung erhalten, wenn die Bestellung des Artikels mit der Inventarnummer ‚SFW374556-02’ mit mindestens 100 stück eingeht. Aufgabe 4.3 – Topics Stellen Sie ein Topic auf, das die deutsche Börse widerspiegelt. Dabei soll es neben den unterschiedlichen Indexen (DAX30, MDAX, NEMAX50, TECDAX,…) auch Topics für verschiedene Branchen geben (Fahrzeuge – Hersteller oder Zulieferer, Maschinenbauer – Hersteller oder Zulieferer,…). Firmen können dabei unter verschiedenen Zweigen vertreten sein, d.h. eine Firma kann z.B. ihre Nachrichten über das Topic DAX30 und gleichzeitig auch über das Topic Maschinenbauer – Hersteller veröffentlichen. 1 Verwenden Sie zur Authentifizierung ein Protokoll mit Hilfe von Benutzername und Passwort. Verschlüsselung soll mit Hilfe von privaten und öffentlichen Schlüsseln erfolgen. BMW möchte nun seine Nachrichten veröffentlichen. Auf welche Topics veröffentlicht er diese? Ein Kunde möchte alle Informationen der DAX30 Unternehmen sowie der Unternehmen Bosch und MAN erhalten (und keine weiteren). Auf welche Topics muss er sich in diesem Fall einschreiben. Aufgabe 5.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“2 vertraut machen (siehe Abbildung 5.1). Abbildung 5.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. 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? 2 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. Abbildung 5.2: Normaler Ablauf mit persistenten Nachrichten Aufgabe 5.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 5.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 5.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. Aufgabe 5.5 (freiwillig): 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.