Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik

Transkript

1 Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik Verteilte Systeme (Masterstudiengänge) Wintersemester 2015/2016 München, September 2015 Prof. Dr. Peter Mandl, LBA Benjamin Fischer, M.Sc. LBA Martin Häusl, M.Sc Inhalt 1 Einführung Aufgabenstellung Hinweise zur Vorgehensweise und zum Ablauf Literatur... 5

2 1 Einführung Im Modul Verteilte Systeme aus dem Masterstudiengang ist eine begleitend zur Vorlesung anzufertigen. Diese geht mit einem Anteil von 0,4 in die Gesamtnote des Moduls ein. Ziel der ist es, ergänzend zur Vorlesung innovative Lösungsansätze und Konzepte im Umfeld der verteilten Systeme zu erforschen, zu erproben und zu diskutieren. 2 Aufgabenstellung Die befasst sich in diesem Semester mit der Entwicklung verteilter Systeme auf Basis von Middleware-Technologien, im Speziellen mit EIA (Enterprise Integration Application) und Enterprise Services Bussen (ESB) sowie deren Anwendung. In Gruppen zu je maximal vier Studierenden soll eine Lösung für eine vorgegebene Problemstellung erarbeitet werden. Als Middleware soll ein EAI-Produkt (Enterprise Integration Application) eingesetzt werden. Die Auswahl des Middleware-Produktes ist prinzipiell freigestellt. Bereits an der Hochschule verfügbar ist die Produktpalette von TIBCO (ActiveMatrix BusinessWorks (BW) inkl. Designer-Tool, ActiveMatrix Service Bus (). Es besteht auch die Möglichkeit, das Szenario mittels Application Server-Middleware umzusetzen. Es soll vor allem auf die Installation und Inbetriebnahme der verwendeten Produkte, auf die Nutzung von Message s, Topics und Webservices, auf die Möglichkeiten der verteilten Transaktionsverarbeitung sowie auf eine Leistungsbewertung Wert gelegt werden. Für die Installation, die Erprobung und die Tests werden in der Virtualisierungsumgebung des Labors für Middlewaretechnologien je Gruppe zwei virtuelle Maschinen bereitgestellt. Das zu verwendende Szenario ist eine einfache Echo-Anwendung. Echo-Clients, deren Anzahl skalierbar ist, senden Nachrichten an den Echo-Process, der die Nachrichten nach einer einfachen Verarbeitung an die Clients zurücksendet. Der Echo-Client stellt dabei Echo-Requests in eine Request-. Diese werden nach dem FIFO-Prinzip in einem aus der Request- ausgelesen (entkoppelte Kommunikation) und mit Hilfe der beiden e -Process und -Process in den zwei Datenbanken gespeichert. Hat ein Client alle Nachrichten abgesendet, wird dies in Form eines Reports über ein Topic an die angebundenen Report-Clients kommuniziert. Die Response-Nachricht wird anschließend in eine Response- eingetragen. Jeder Echo-Client soll schlussendlich auch nur die Nachrichten aus der Response- abholen, die er auch gesendet hat. In Abbildung 1 ist die geplante Architektur am Beispiel eines ESBs grob skizziert. Als Komponenten sind ein Benchmarking-Client mit mehreren Threads, die Echo-Clients darstellen und ein Echo- zu erkennen. Beide kommunizieren über Message s. Weiterhin sind zwei e (-Process, -Process), ein Service (Admin Service) und zwei getrennte Datenbanken ( und ) skizziert. Schließlich zeigt das Bild noch einen einfachen Admin-Client, der über einen Webservice angebunden ist und über den Admin-Service auf die beiden Datenbanken zugreift. Des Weiteren ist ein Topic abgebildet, über welches Informationen aller fertig abgearbeiteten Clients an die Report-Clients verteilt werden soll. Prof. Dr. Peter Mandl Seite 1

3 JMS Erweiterung Benchmarking Client Thread JMS Message C3:Report Client C2:Report Client C1:Report Client Admin Client <<subscribe>> WS Request Durable Topic Durable Durable Response Read EchoPDU Update Update Publish Finished Client run Send PDU Echo Process Admin Service Process Process Transaktion ESB Abbildung 1: Grobe Architektur des Anwendungsszenarios Die Art der Implementierung des Admin- und des Report-Clients ist jeder Gruppe freigestellt (GUI oder zeilenorientiertes User Interface). Die Verarbeitung im Server nutzt passende Aktionen (z.b. TIBCO-Activities) für das Zählen der Echo-Requests in der -Datenbank sowie für das Wegschreiben jedes Echo-Requests in die -Datenbank. In die -Datenbank sollen dabei der Name des Clients und ein Zähler über die empfangenen Nachrichten pro Client gespeichert werden. Die -Datenbank persistiert den Clientthread-Namen, den Serverthread- Namen, die Nachricht sowie die Angabe, ob es sich um den letzten Request eines Clients handelt. Prof. Dr. Peter Mandl Seite 2

4 Es sollen hierfür zwei Datenbankinstanzen (Maria) benutzt werden. Die serverseitige Bearbeitung einschließlich des Einstellens der Echo-Response-Nachricht in die Response soll in einer verteilten Transaktion stattfinden. Der Ablauf der Kommunikation für einen Echo-Request mit vollständiger Bearbeitung ist in Abbildung 2a und Abbildung 2b dargestellt. Echo Client Request Response Echo echo(echopdu) echo(echopdu) RTT echo(echopdu) Abbildung 2a: Kommunikationsablauf für Echo-Requestbearbeitung Echo Topic count(clientid) trace(echopdu) insert / update insert publish (lastechopdu) Abbildung 2b: Kommunikationsablauf für Echo-Requestbearbeitung In Abbildung 3 ist schließlich noch der einfache Zugriff des Admin-Clients auf den Admin- Service skizziert. Der Admin-Service stellt nur zwei Methoden zum Auslesen des Zählers für alle ausgeführten Echo-Requests eines Echo-Clients und zum Löschen aller Daten aus den beiden Datenbanken zur Verfügung. Prof. Dr. Peter Mandl Seite 3

5 Admin Client Admin Service getclient(clientid) select deletealldata() delete delete Abbildung 3: Kommunikationsablauf für Administrationszugriff c1:reportclient c2:reportclient :ReportTopic :ReportServer : register(topic) subscribe(topic) subscribe(topic) getreportdata(clientid) push(topic, reportdata) publish(topic, reportdata) push(topic, reportdata) Abbildung 4: Kommunikationsablauf für Reportzugriff Die Umsetzung der Aufgabe soll in zwei Schritten erfolgen. Der erste Schritt sieht die Implementierung des Szenarios ohne verteilte Transaktion vor. Im zweiten Schritt soll die Umsetzung der verteilten Transaktion erfolgen. Die Anwendung soll gründlich getestet werden. Vor allem soll auch die Transaktionssicherheit bei Fehlersituationen erprobt werden (Transaktionsabbruch, Recovery) und es soll überprüft werden, ob die Entkopplung von Echo-Client und Echo- durch die s ordnungsgemäß funktioniert. Weiterhin soll ein Leistungstest durchgeführt werden. Die folgende Skizze soll die Ergebnisdarstellung des Leistungstests verdeutlichen. Die Anzahl der Clients soll im Test Zug um Zug erhöht werden, um die Last auf den ESB zu steigern. Die Lasttests sind mehrfach zu wiederholen, um gesicherte Aussagen zu erhalten. Dabei soll die durchschnittliche Round Trip Time (RTT) der Echo-Bearbeitung ermittelt werden. Prof. Dr. Peter Mandl Seite 4

6 Durchschnittl. RTT in ms Messung: Variation der Threads Nachrichtenlänge: 50 Byte Anzahl Nachrichten je Client: 100 Denkzeit: 100 ms Anzahl Threads Abbildung 5: Darstellung der Messergebnisse Als Basislösung wird ein Java-basiertes Benchmarking-Framework (aus der Vorlesung Datenkommunikation bekannt) bereitgestellt. Dieses Framework ist um die spezielle Anbindung an die eigene Lösung über Message-s zu erweitern. 3 Hinweise zur Vorgehensweise und zum Ablauf Hier einige Hinweise zur : Die ist eine wissenschaftliche Arbeit. Ein methodisches Vorgehen, eine entsprechende Strukturierung der Arbeit sowie eine korrekte Zitation sind erforderlich. Die en werden in Gruppen ausgearbeitet, aber jeder Teilnehmer bearbeitet sein eigenes Thema im Themenkomplex selbstständig in Abstimmung mit dem Dozenten und den anderen Gruppenmitgliedern. Umfang der Arbeit: Es sind je Gruppe zehn Seiten im IEEE-Format in Form eines technischen Artikels zu schreiben und es ist der lauffähige Sourcecode für das gegebene Anwendungsszenario abzugeben. Als Textverarbeitungssystem wird Microsoft Word verwendet. Eine Präsentation mit maximal 20 Powerpoint-Folien je Gruppe (einheitliches Format) ist vorzubereiten. Die Präsentationszeit beträgt 30 Minuten inkl. Demo der implementierten Lösung mit anschließender Diskussion. Die Gruppen stellen ihre Ergebnisse gemeinsam vor. Abgegeben werden alle Ergebnisse der Arbeit (Artikel im Word-Format, Folien, Sourcecode,...) in elektronischer Form per (Adresse des Dozenten). Abgabe- und Präsentationstermine werden noch abgestimmt. 4 Literatur Einstiegsliteratur für das wissenschaftliche Arbeiten: Rechenberg, Peter: Technisches Schreiben, Hanser Verlag, 3. Auflage, 2006 Prof. Dr. Peter Mandl Seite 5

7 Balzert, H. u.a.: Wissenschaftliches Arbeiten, W3I Verlag, 2008 Mandl, P.; Löwe, R.: Hinweise zur Erstellung technischer Dokumente (internes CCWI- Dokument) Produktinformationen sind aus den entsprechenden Produktseiten des TIBCO ActicMatrix Service Bus zu besorgen. Als Einstieg kann die TIBCO Produkt Dokumentation 1 verwendet werden. 1 abgefragt am Prof. Dr. Peter Mandl Seite 6