RHEINISCHE FACHHOCHSCHULE KÖLN
University of Applied Sciences
Fachbereich: Wirtschaft & Recht
Studiengang: Wirtschaft II
Diplomarbeit
Vergleichende Untersuchungen von Verfahren zur
Serverlast-Verteilung in Java für J2EE-Anwendungen
Diplomarbeit vorgelegt von: Fabian Rossbacher
Abgabedatum 15.11.2007
1. Prüfer: Prof. Dr. Schönefeld
2. Prüfer: Dr. Trittmann
Wintersemester 07/08
1 Einleitung. 1
1.1 Abgrenzung. 3
1.2 Aufbau der Arbeit 3
2 Architektur J2EE-Webanwendung. 4
2.1 N-Tier-Architekturen. 5
2.1.1 2-Tier-Architektur 6
2.1.2 3-Tier-Architektur 7
2.1.3 4- und Mehr-Tier-Architektur 8
2.2 Eingesetzte Frameworks und Standards. 9
2.2.1 Design-Patterns. 10
2.2.1.1 Begriffsklärung MVC. 13
2.2.1.2 Patternvariation MVC im Web. 15
2.2.2 Struts2 16
2.2.2.1 Geschichte. 17
2.2.2.2 Einsatzgebiet 18
2.2.2.3 Architektur 18
2.2.2.4 Vorteile. 22
2.2.3 Hibernate. 22
2.2.3.1 Geschichte. 22
2.2.3.2 Architektur 23
2.2.3.3 Einsatzgebiet 25
2.2.3.4 Vorteile. 28
2.2.4 Spring-Framework. 28
2.2.4.1 Geschichte. 28
2.2.4.2 Architektur 29
2.2.4.3 Einsatzgebiet 32
2.2.4.4 Vorteile. 32
3 Tools für Messungen. 32
3.1 Begriffsdefinition Performance. 33
3.2 JMX-Standard für Monitoring. 33
3.2.1 Hintergrund. 33
3.2.2 JConsole. 34
3.3 JMeter 35
4 Verteilte Anwendungen. 37
4.1 Grenzen von nicht verteilten Anwendungen. 37
4.2 Definition des Begriffs „Verteilte Systeme“ 38
4.3 Arten von verteilten Anwendungen. 39
4.4 Mögliche Probleme innerhalb verteilter Webanwendungen. 40
4.4.1 Session-Replikation. 40
4.4.2 OR-Mapper-Cache. 42
4.4.3 POJO-Clustering. 42
5 Strategien zur Serverlast-Verteilung. 43
5.1 Programmatische Strategien. 43
5.1.1 Remote Method Invocation (RMI) 43
5.1.1.1 Geschichte. 43
5.1.1.2 Architektur 43
5.1.1.3 Beispiel 45
5.1.1.4 Aufwand. 49
5.1.2 JMS 50
5.1.2.1 Geschichte. 50
5.1.2.2 Architektur 51
5.1.2.3 Beispiele. 52
5.1.2.4 Aufwand. 55
5.1.3 Webservices. 56
5.1.3.1 Geschichte. 56
5.1.3.2 Architektur 56
5.1.3.3 Beispiele. 58
5.1.3.4 Aufwand. 61
5.2 Nicht-programmatische Strategien. 62
5.2.1 Vertikale Skalierung. 62
5.2.2 Aufwand. 62
5.2.3 Horizontale Skalierung. 64
5.2.3.1 Beispiel JBoss-Cluster 65
5.2.3.2 Aufwand. 67
5.2.3.3 Alternative Terracotta. 68
5.2.3.4 Aufwand. 71
6 Fazit 72
7 Anhangsverzeichnis. 77
Darstellungsverzeichnis. 78
Abkürzungsverzeichnis. 80
Abkürzungsverzeichnis. 80
Literaturverzeichnis. 81
Erklärung
Lebenslauf
Die Programmiersprache „Java” ist in den letzten 12 Jahren von einer anfänglich belächelten Programmiersprache für Waschmaschinen und Toaster, zu einer global eingesetzten Technologie für Web -und Desktop-Systeme herangereift. Besonders der von den Java-Machern (Sun) entwickelte J2EE Standard[1] erfreut sich immer größerer Beliebtheit und wird gerade von großen, kommerziellen Internetplattformen wie Amazon, Ebay uvw. eingesetzt.
Die Gründe hierfür liegen auf der Hand:
Neben den oben beschriebenen Vorteilen existieren mehrere kostenpflichtige und kostenfreie Implementierungen für den JSR-00154[4] (Servlet-Spezifikation). Diese ermöglichen den Einsatz von serverseitigem Java in der Welt des WWW. Java ist zu 100% objektorientiert und stellt ebenfalls eine Möglichkeit für die Entwicklung mit Threads (parallele Prozesse) zur Verfügung. In der Client-Server-Architektur spielt die Verwendung von Server-Threads, hinsichtlich System-Ressourcen, eine zentrale Rolle. Systeme mit hohen Benutzerzahlen benötigen entsprechende System-Ressourcen (Hardware), um gewünschte Antwortzeiten zu garantieren. Die entsprechenden Hardware-Bausteine sind sehr kostspielig und müssen von Spezialisten gewartet und aufgesetzt werden. Mit erhöhter Benutzeranzahl steigen auch die Anforderungen an die Systeme. Es müssen leistungsstärkere Hardware-Bausteine beschafft und die alten ausgetauscht werden.
Im Rahmen der hier vorliegenden Arbeit werden diese Anforderungen untersucht und die Grenzen von Hardware-Systemen aufgezeigt. Dabei stehen die folgenden Fragen im Mittelpunkt:
Häufig werden Web-Projekte mit niedrigem Budget entwickelt und es kann dabei nur selten ein komplettes Team aus erfahrenen Software-Architekten eingesetzt werden. Daher werden nichtfunktionale Anforderungen gerade bei der Erstentwicklung von Anwendungen oft nur unzureichend beachtet, weil schnell Ergebnisse erzielt und Investoren überzeugt werden müssen. Steht die Finanzierung, werden viele Internetseiten jedoch schon nach den ersten Promotion-Aktionen (Bannerwerbung, Plakatwerbung etc.) mit der Problematik mangelnder Performance konfrontiert. Als Ad-hoc-Lösung werden dann häufig leistungsstärkere Maschinen eingesetzt. Diese erreichen jedoch ihre Leistungsgrenzen schnell und es muss eventuell ein weiteres Hardware-Update durchgeführt werden. Wenn eine einzelne Maschine nicht weiter aufgerüstet werden kann, muss ein aufwendiger und kostenintensiver Hardware-Cluster aufgesetzt werden. Bei diesem Verfahren gibt es unterschiedliche Varianten (Sticky-Session, Non-Sticky-Session, Session-Replication, Load-Balancing etc.). Darüber hinaus muss die Java-Anwendung selbst gewisse Anforderungen erfüllen (z. B. müssen Session-Objekte serialisierbar sein). Neben speziellen Programmiertechniken und Hardware-Loadbalancing werden die Alternativen „Anwendungsclustering” und „Javagrid“ beleuchtet. Dieses Verfahren ermöglicht es, beliebig viele Systeme über eine Anwendungsschicht miteinander zu verbinden und in einem Grid[5] zu nutzen. Hierbei werden die unterschiedlichen JVMs der Systeme miteinander verbunden, in einer Software-Abstraktionsschicht gekapselt und somit zu einer gemeinsamen Java-Virtual-Machine vereinigt. Die Vorteile dieser Cluster-Variante sollen den zuvor vorgestellten Techniken gegenübergestellt und hinsichtlich Kosten, Wartbarkeit und Pflege bewertet werden.
[1] Standard für Webanwendungen in Java
[2] Quellcode offene Software, welche von einer freiwilligen Gruppe von Entwicklern programmiert und gepflegt wird
[3] Lösungswege für Anwendungen, welche von einer großen Anzahl von Entwicklern genutzt werden
[4] Ein von Sun definierter Standard für den Aufruf einer speziellen Java-Klasse aus einer Web-Anwendung
[5] Ein Netz von Systemen
Die in dieser Arbeit behandelten Themen beziehen sich ausschließlich auf den Bereich J2EE. Der Fokus liegt hierbei auf Standard-Anwendungen wie Portalen, E-Shops oder Online-Börsen. Untersuchungen von Anwendungen wie „Second Life“[1] der Firma Linden Lab oder Bittorrent-Netzwerke[2] (Wikipedia: BitTorrent) sind nicht Bestandteil dieser Arbeit. Da zudem der Aspekt der Wirtschaftlichkeit im Vordergrund steht, wird auch das Supercomputing bzw. Grid-Computing im klassischen Sinne im Vorfeld ausgeklammert.
Diese Arbeit ist in 7 Kapitel untergliedert. Kapitel 1 gibt eine Einführung in das untersuchte Thema und grenzt themenverwandte Bereiche ab. Im nachfolgenden Kapitel 2 wird ein Überblick über den Untersuchungsgegenstand (eine Webanwendung) gegeben. Dabei wird auch auf die Architektur von Webanwendung sowie die eingesetzten Frameworks eingegangen. Kapitel 3 stellt die in dieser Arbeit verwendeten Mess- und Lastwerkzeuge für Performance-/Antwortzeit-Messungen und Ergebnisauswertungen vor. Die vorgestellten Tools dienen als Basis für die Untersuchung. In Kapitel 4 wird zunächst der Begriff “Verteilte Anwendung” definiert sowie unterschiedliche Arten von verteilten Anwendungen voneinander abgegrenzt. Dabei wird im Detail auf verwendete Technologien und in der Praxis auftretende Probleme bei hoher Last eingegangen. Ebenso werden Anforderungen an eine verteilte Webanwendung definiert. Kapitel 5 demonstriert den Einsatz spezieller Programmiertechniken mittels Standard-Java-Technologien (RMI, Corba und Webservices), um eine einzelne JVM hinsichtlich Speicher- und CPU-Verbrauch zu entlasten. Die Alternative zur programmatischen Entlastung von Server-Systemen, das Clustering, wird ebenfalls vorgestellt. Untersucht wird jeweils der JBoss-Cluster und das Javagrid-Framework openTerracotta. Anschließend wird ein Fazit hinsichtlich der jeweiligen Eignung der untersuchten Strategien gezogen und eine Empfehlung hinsichtlich Aufwand/Kosten und Wartbarkeit sowie des jeweiligen Einsatzgebiets ausgesprochen.
Die Begriffe J2EE, Webanwendung und Internet bzw. Web sind in aller Munde. Dies ist nicht weiter verwunderlich, wenn man die Umsatzzahlen von Firmen wie Google (mit einem Unternehmenswert größer als die Summe der Deutschen Bank und DaimlerChrysler), Ebay, Amazon oder Myspace betrachtet. Nach eher ruhigen vier Jahren erlebt das Internet aktuell eine Erneuerung unter der Bezeichnung „Web 2.0“.
Investoren erkennen zunehmend das Potenzial sogenannter „Social-Platforms“[1] und erhoffen sich durch die Bindung einer möglichst breiten Benutzergruppe in Zukunft eine gefestigte Position im globalen Markt. Insofern ist es nicht erstaunlich, dass für Plattformen dieser Art derzeit Beträge in mehrstelliger Millionenhöhe gezahlt werden. Der zu diesem Zeitpunkt (Stand: Oktober 2007) größte Verkauf in Deutschland mit 85 Millionen Euro gelang drei Entwicklern der Plattform studiVZ[2].
Aufgrund der täglich wachsenden Benutzerzahlen solcher Plattformen steigen auch die Anforderungen an die den Webanwendungen zugrunde liegenden Softwaremodule. Es reicht heutzutage nicht mehr aus, eine Webanwendung für 100 oder 1.000 Benutzer abrufbar zu gestalten. Vielmehr müssen die Softwaresysteme die Anforderungen vieler tausend Benutzer gleichzeitig verarbeiten können.
Diese Arbeit behandelt Webanwendungen, die dem J2EE-Standard der Firma Sun entsprechen. Dieser Standard wurde erstmals 1997 veröffentlicht und befindet sich aktuell in der Version 5. Der von Sun entwickelte Standard schafft einen Rahmen für Webanwendungen, der es Entwicklern ermöglicht, entsprechende Softwaremodule für bestehende Systeme zu entwickeln, alte auszutauschen oder in neuem Code zu nutzen.
Trotz des von Sun entwickelten Standards für Webanwendungen zeigt sich in der Praxis eine heterogene Vielfalt von angewandten Variationen für die Umsetzung einer J2EE-Anwendung in Java.
Dabei kommen unterschiedliche Frameworks und Programmierparadigmen zum Einsatz, welche sowohl kommerzieller Natur, als auch per Open-Source verfügbar sind.
Die Anzahl der Entwicklungsumgebungen[3] und Applikations-Server ist kaum überschaubar, so dass ein projektübergreifender Standard für J2EE-Anwendungen nicht zu definieren ist. Die in dieser Arbeit eingesetzten Frameworks werden daher in den folgenden Kapiteln vorgestellt und beschrieben.
Unabhängig von den eingesetzten Frameworks und Programmierparadigmen lässt sich jede J2EE-Anwendung in eine sogenannte Tier-Architektur (ein Schichtenmodell) einteilen. Im Folgenden werden daher die existierenden Tiers
Der Begriff N-Tier-Architektur ist als Erweitung des klassischen Client-Server-Modells anzusehen. Dabei beschreibt die sogenannte „tier“ (zu deutsch „Schicht“) den Aufbau des mit dem Client kommunizierenden Servers. Für den Client selbst ist der Aufbau des aufgerufenen Servers, also die gewählte N-Tier-Architektur, nicht transparent. Er kommuniziert lediglich mit der obersten Schicht, der GUI[1]. Aufgrund der unterschiedlichen Anforderungen an eine J2EE-Anwendung kann der Entwickler verschiedene N-Tier-Architekturen wählen, um somit einen ersten Schritt in Richtung Entlastung der einzelnen Schichten „Datenhaltung“, „Businesslogik“ und „Präsentation (GUI)“ vorzunehmen. Die Wahl der N-Tier-Architektur für ein Projekt wird zu Beginn der Entwicklung von Software-Architekten und Projektmanagern vorgenommen. Sie bildet gleichsam den Grundstein der gesamten Anwendung und ist hinsichtlich einer späteren Optimierung von Lasten elementar. Nicht zu verwechseln ist eine N-Tier-Architektur mit dem eigentlichen Aufbau von Java-Klassen oder Paketen. Die N-Tier-Architektur liegt eine Ebene tiefer und damit noch unterhalb der JVM selbst.
Grundsätzlich werden N-Tier-Architekturen in drei Kategorien eingeteilt. Diese werden in den nachfolgenden Unterkapiteln vorgestellt.
Die 2-Tier-Architektur ist die simpelste in der N-Tier-Familie. Sie besteht aus einer Client- und einer Server-Tier (s.o.). Die Client-Tier (s.o.) ist verantwortlich für die Präsentation der Daten und stellt somit die eigentliche UI dar. Businesslogik und Datenhaltung werden durch die Server-Tier bereitgestellt.
Abbildung 1 verdeutlicht die Aufteilung der drei Schichten „Präsentation“, „Businesslogik“ und „Datenhaltung“ auf die Client- und die Server-Tier.
Abbildung 1: 2-Tier-Architektur J2EE-Anwendung
Quelle: Eigene Darstellung
Aufgrund der Tatsache, dass Datenhaltung und Businesslogik sich in einer Tier und somit auch physikalisch auf einem System befinden, ergeben sich erste Einschränkungen hinsichtlich der Verteilung der beiden Ebenen. Eine verbesserte Variante dieser Architektur wird im folgenden Kapitel 3-Tier-Architektur vorgestellt.
Im Gegensatz zur 2-Tier-Architektur wird bei der 3-Tier-Architektur die Server-Tier (analog: Server-Schicht) weiter aufgeteilt. Businesslogik und Datenhaltung werden getrennt und jeweils in eine eigenständige Tier (s.o.) verschoben. Die herausgetrennte Businesslogik bzw. Anwendungsschicht wird in der Praxis oft mit dem Begriff Middleware umschrieben. Da in ihr die eigentliche Programmlogik und damit verbundene rechenintensive Prozesse enthalten sind, steht sie oft im Fokus von performanceverbessernden Maßnahmen. Die 3-Tier-Architektur ermöglicht es, Businesslogik und Datenhaltung auf getrennten Systemen zu verwalten und somit eine bessere Skalierbarkeit zu erreichen. Die Systeme der Datenhaltung und der Businesslogik können getrennt voneinander besser an die jeweiligen Anforderungen einer Anwendung angepasst werden. In der Praxis wird für die Schicht der Datenhaltung häufig ein Datenbankserver wie Oracle, MySQL oder Postgres eingesetzt. Dies wiederum bringt weitere Strategien für eine mögliche Lastverteilung mit sich, auf die in dieser Arbeit aber nicht weiter eingegangen werden kann.
Abbildung 2 verdeutlicht die Abhängigkeiten der Schichten innerhalb des 3-Tier-Architektur-Modells:
Abbildung 2: 3-Tier-Architektur J2EE-Anwendung
Quelle: Eigene Darstellung
Im Idealfall greift die Präsentationsschicht ausschließlich über definierte Businesslogik-Schnittstellen auf persistierte Daten der Datenhaltung zu. In der Praxis findet jedoch in Einzelfällen ein direkter Zugriff statt. Dies kann zu Problemen bei hoher Last führen, da sich die Lastverteilung in der Regel auf die Businesslogik und nicht auf die Präsentations-Schicht fokussiert. In Kapitel 2.2.1 wird auf dieses Problem näher eingegangen und erläutert, wie man es mit den eingesetzten Frameworks umgehen kann.
Die zuletzt vorzustellende Tier-Architektur unterscheidet sich nur geringfügig von der 3-Tier-Architektur. Der maßgebliche Unterschied besteht in der Aufteilung der herausgelösten Businesslogik. Diese kann bei einer 4- und Mehr-Tier-Architektur (s.o.) aus mehreren Schichten aufgebaut sein. Dabei erhalten die eingesetzten Tiers individuelle Namen wie Web-Tier oder Application-Tier etc.
Abbildung 3 erweitert die bisher vorgestellten Schichtenmodelle um zwei individuell eingesetzte Tiers.
Abbildung 3: 4- und Mehr-Tier-Architektur J2EE-Anwendung
Quelle: Eigene Darstellung
Die weitere Unterteilung der Businesslogik in individuelle Tiers ermöglicht eine feinere Verteilung der Komponenten hinsichtlich ihrer Skalierung. Dies ist für die Lastverteilung insofern von Vorteil, da die einzelnen Tiers auf diese Weise separat betrachtet und optimiert werden können. In der Praxis wird häufig die 4-Tier-Architektur für Webanwendungen gewählt. Dabei wird die Web-Tier durch einen Apache-Webserver realisiert, der ausschließlich für die Bereitstellung statischer Inhalte wie HTML-Seiten, Javascripts oder Bilder verantwortlich ist. Für aufwendige und rechenintensive Aufgaben leitet dieser an einen Application-Server, z. B. Apache Tomcat/JBoss, Websphere etc. weiter. Dies hat unter anderem den Vorteil, dass bei späteren Tuningmaßnahmen zwei unterschiedliche Teams Web-Tier und Application-Tier untersuchen können.
© 2012 java freelancer – Fabian Rossbacher