Erklärung

Ich versichere, dass ich die Studienarbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegt und von dieser als Teil einer Prüfungsleistung angenommen wurde.

Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet.

Bayreuth, den 08. Juli 2003

Markus Preißner

1 nach den Erzählungen des Dichters Pindar aus der siebten olympischen Ode für die Insel Rhodos und das Geschlecht der Diagoras [Bengtson et al. 1971, S.77]

Inhaltsverzeichnis

Inhaltsverzeichnis

  Erklärung..............................................................................................................................III  

Inhaltsverzeichnis..................................................................................................................V

Abbildungsverzeichnis........................................................................................................VII

Tabellenverzeichnis...........................................................................................................VIII

  Abkürzungsverzeichnis........................................................................................................IX  

  Themenstellung.....................................................................................................................X  

1.  Einführung 1  

2.  TPC Benchmark W 3  

2.1.  Transaction Processing Performance Council 3  

2.2.  Grundlegende Eigenschaften des TPC Benchmark W 3  

2.3.  Datenbanktabellen 4  

2.3.1.  Datenbankbestand 5  

2.3.2.  Identifikation des Benutzers 7  

2.4.  Webseiten 8  

2.4.1.  Übersicht Seitennavigation 9  

2.4.2.  Web-Elemente 9  

2.5.  Zugriffsprotokollierung 14  

3.  Architektur 15  

3.1.  Schichtenmodell 15  

3.2.  Schicht 5: Benutzer 16  

3.3.  Schicht 3 4: Darstellungs- und Kommunikationsschicht 16  

3.3.1.  Entscheidung: PHP oder JSP 17  

3.3.2.  Tomcat und Coyote 17  

3.4.  Schicht 2: Verarbeitung 18  

3.4.1.  Anforderungen und Softwarevergleich 18  

3.4.2.  JBoss 19  

3.5.  Schicht 1: Datenhaltung 20  

3.5.1.  Ideallösung 20  

3.5.2.  HypersonicDB 21  

3.5.3.  MySQL 22  

3.6.  Gesamtarchitektur 23  

V

Inhaltsverzeichnis

4.  Grundlagen 24  

4.1.  Java Server Pages 24  

4.1.1.  Historische Entwicklung 24  

4.1.2.  Grundlagen von Java Server Pages 26  

4.2.  Enterprise JavaBeans 28  

4.2.1.  Historisches 28  

4.2.2.  Definition Enterprise JavaBeans 29  

4.2.3.  Grundlegende Modelle 29  

4.2.4.  Architektur für verteilte Objekte 32  

4.2.5.  Enterprise JavaBean Komponenten 33  

5.  Implementierung 39  

5.1.  Installation von MySQL 39  

5.1.1.  Master-Slave-Architektur 39  

5.1.2.  Datenbankinstallation 39  

5.1.3.  Benutzer anlegen 40  

5.1.4.  Standardkonfiguration anpassen 41  

5.2.  Installation JBoss 43  

5.2.1.  Installation JBoss 43  

5.2.2.  Hilfsprogramme 44  

5.2.3.  Änderungen an der Standard-JBoss-Konfiguration 47  

5.3.  Implementierung der Enterprise JavaBeans 54  

5.3.1.  Entity-Beans 55  

5.3.2.  Session-Beans 66  

5.3.3.  Sonstige Klassen 80  

5.3.4.  Java Server Pages 83  

5.4.  Sonstige Software 87  

5.4.1.  Payment Gateway Emulator 88  

5.4.2.  Datengenerator 88  

6.  Ausblick 90  

6.1.  DB-Änderung 90  

6.2.  Cache reaktivieren 92  

6.3.  Implementierung des Lastgenerators 92  

6.4.  Instrumentierung 94  Instrumentierung........................................................................................................94

  Literaturverzeichnis............................................................................96  

Anhang A:  UML Aktivitätsdiagramme 99  

Anhang B:  CD  Inhalt........................................................................156

VI

Abbildungsverzeichnis

Abbildungsverzeichnis

  Kapitel  2:

  Abbildung 2-1: Tabellenlayout nach TPC-W 4  

  Abbildung 2-2: Beispiel für eine Buchgrafik 6  

  Abbildung 2-3: Benutzerregistrierung durch Cookies 7  

  Abbildung 2-4: Seitennavigation nach TPC-W 8  

  Abbildung 2-5: Startseite des Buchladens 9  

  Abbildung 2-6: Best-Seller - Seite  10

  Abbildung 2-7: Warenkorb  11

  Abbildung 2-8: Ausgabe der PGE-Autorisierungen  12

  Abbildung 2-9: Suchmaske  13

  Kapitel  3:

  Abbildung 3-1: Schichtenmodell  15

  Abbildung 3-2: Synchrones Update  20

  Abbildung 3-3: Inkonsistenz bei asynchronen Änderungen  21

  Abbildung 3-4: Aktualisierung nur auf der Master-Instanz  22

  Abbildung 3-5: Schichtenmodell mit Softwareprodukten  23

  Kapitel  4:

  Abbildung 4-1: Ordnerstruktur für WAR-Dateien  27

  Abbildung 4-2: Veränderung des von TM bekannten drei-Schichten-Modells  29

  Abbildung 4-3: Verschiedene Technologien in JBoss  31

  Abbildung 4-4: Fernaufruf einer Methode durch Stub und Skelett  32

  Abbildung 4-5: Lebenszyklus einer Enterprise JavaBean  34

  Abbildung 4-6: Bindung zustandloser Beans  36

  Kapitel  5:

  Abbildung 5-1: Ordnerstruktur Ant  46

  Abbildung 5-2: Aktualisierung wird durch Caching nicht beachtet  54

  Abbildung 5-3: Übersicht verwendbarer Methoden der Session-Beans  70

  Abbildung 5-4: setNewRelated() Methode der ItemManagementBean  73

  Abbildung 5-5: processBuyConfirm() Methode der OrderManagementBean  77

  Kapitel  6:

  Abbildung 6-1: Clusterdesign mit Buchladen  95

VII

Tabellenverzeichnis

Tabellenverzeichnis

  Kapitel  2:

Tabelle 2-1:  Tabellenbeschreibung der Datenbank 5  

  Kapitel  4:

Tabelle 4-1:  Vergleich verschiedener Programmiertechnologien für dynamische Webseiten  25

Tabelle 4-2:  Übersicht der JSP Start-Tags  26

  Kapitel  5:

Tabelle 5-1:  Zuordnung Entity-Bean - ID-Generator  63

Tabelle 5-2:  Bedeutung der Meta-Bean Daten  65

Tabelle 5-3:  Zuordnung Webelement JSP-Seite  83

  Kapitel  6:

Tabelle 6-1:  Beispiel für eine Schwellwert-Matrix des Lastgenerators TPCW  93

Tabelle 6-2:  Verteilung der Webinteraktionen  93

VIII

Abkürzungsverzeichnis

Abkürzungsverzeichnis

ACID Atomicity, Consistency, Isolation, Durability

ASP Active Server Pages

BMP Bean Managed Persistence

CGI Common Gateway Interface

CLF Common Log Format

CMP Container Managed Persistence

CTM Component Transaction Monitor

DB Database

EJB Enterprise Java Beans

EJB-QL Enterprise Java Beans Query Language

HA High Availability (im JBoss-Umfeld)

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocoll Security

IIS Internet Information Server

IP Internet Protocol

J2EE Java 2 Enterprise Edition

J2SE Java 2 Second Edition

JAR Java Archive

JDBC Java Database Connectivity

JMS Java Messaging Service

JMX Java Management Extension

JNDI Java Naming and Directory Interface

JRE Java Runtime Environment

JSP Java Server Pages

PHP Personal Home Page / PHP Hyptertext Preprocessor

RMI Remote Method Invocation

SQL Structured Query Language

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TLD Tag Library Descriptor

TPC Transaction Processing Performance Council

TPC-W TPC Benchmark W

W3C World Wide Web Consortium

WAR Web Archive

WIPS Web Interactions Per Second

XML Extended Markup Language

IX

Themenstellung

Themenstellung

Ziel der Arbeit ist die Implementierung einer eCommer- ce-Plattform nach dem TPC Benchmark W im Cluster- labor des Lehrstuhls. Die Verwendung aktueller Tech- nologien soll dabei fokusiert werden. Einer späteren In- strumentierung soll Rechnung getragen werden

X

Einführung

1. Einführung

Der Wandel hin zu einer leistungsorientierten Gesellschaft, welche den Menschen nur als Produktionsmaschine sieht und dessen Wert lediglich anhand der erfüllten und geleisteten Arbeit festlegt, hat unser Verhalten nachhaltig verändert. Wir suchen unser persönliches Glück nicht mehr in der Familie, der Freizeit oder unseren sozialen Kontakten, denn diese Faktoren werden von unserem Umfeld nicht gewertet: Nur der Erfolg zählt. Wer zu wenig leistet, also seine Aufgaben nicht ganz erfüllt oder diese gar verweigert, gerät schnell un- ter die Räder dieser Gesellschaft, wird nicht mehr respektiert und akzeptiert.

Doch der Mensch setzt sich zur Wehr. Der ständige Erfolgsdruck verleitet ihn zu einer Verherrlichung der Tatsachen und Erfolge. Das eigene Können wird, solange es niemand bemerkt, selbst überbewertet, denn schließlich wird hohe Leistung erwartet und man weiß, dass der potentielle Konkurrent ebenfalls so denkt. Die Folgen sind fatal. Die Gesellschaft nimmt bei jeder Bewertung einer Arbeit an, dass diese in einer Form angegeben wurde, die ein möglichst hohes Potential aufweist. Wer den wahren Erfolg angibt, wird unter Wert verkauft. Ein objektiver Vergleich ist hier nicht mehr möglich.

Wir haben gelernt dieses Verhalten nicht nur auf andere Menschen, sondern auch auf Produkte der Industrie zu übertragen. Die Informationsgesellschaft besitzt die Möglichkeit, Produkte verschiedener Hersteller einfach miteinander vergleichen zu können. Um das eigene Überleben zu sichern, verwenden Firmen das genannte Verhalten und werten die einzelnen Produktdetails überdurchschnittlich hoch. Jede Eigenschaft wird mit einem an- deren Testszenario versehen, bei dem ein Maximum an Leistung erreicht wird. Vergleiche mit anderen Produkten werden so ausgelegt, dass die eigene Firma bereits zu Beginn der Tests klar im Vorteil ist. Anscheinend unabhängige Tests von Zeitschriften oder Vereinen werden zum Teil erkauft, indem über Werbeverträge und Spenden Druck auf die Tester ausgeübt wird. Ein objektiver Vergleich ist hier nicht mehr möglich.

Um einen möglichst realen Vergleich verschiedener Produkte einer Gruppe zu erhalten, muss oft ein schwerer Weg gegangen werden. Es sind viele Statistiken und Tests auszu- werten, um ein möglichst objektives Bild zu erhalten. Da potentiell jede Gegenüberstellung manipuliert sein kann, müssen die einzelnen Resultate genau geprüft und abgewogen werden. Starken Abweichungen von der durchschnittlichen Bewertung ist dabei ein gerin- geres Vertrauen entgegenzubringen, während durchschnittliche Ergebnisse das objektive Produkterscheinen verstärken. Ein solches Vorgehen benötigt eine große Menge an Da-

1

Einführung

ten, die jedoch in den meisten Fällen nicht zur Verfügung stehen. Je weniger Informatio- nen zur Verfügung stehen, umso ungenauer wird die Auswertung.

Einen möglichen Ausweg aus dieser Vergleichsmethodik bilden die sogenannten Bench- marks, deren Ziel es ist, objektive Vergleichsdaten für eine bestimmte Produktgruppe zu definieren. Den Kunden werden damit einheitliche und möglichst unabhängige Daten zur Verfügung gestellt, anhand derer ein objektiver Vergleich möglich ist. Dafür werden exakt bestimmte Szenarien definiert, welche von den entsprechenden Produkten abzuarbeiten sind.

Aufgabe eines solchen Benchmarks ist damit vor allem, dessen Details für die Ansprüche so genau wie möglich zu definieren. Den einzelnen Produkten soll keine Möglichkeit ge- geben werden, auf das Endergebnis zu ihren Gunsten Einfluss zu nehmen. Die Objektivi- tät steht an vorderster Stelle.

Eine weitere Aufgabe eines solchen Benchmarks ist eine möglichst hohe Aktualität des Szenarios. Der Wunsch eines Kunden an ein Produkt ist natürlich, einen alltagstauglichen Einsatz zu garantieren. Benchmarks die sich nicht an den aktuellen Anforderungen orien- tieren sind somit für einen Vergleich nicht sinnvoll und meist destruktiv. Eine ständige Weiterentwicklung und Anpassung ist daher sehr oft nötig.

Durch das Mittel des Benchmarking ist es möglich, das Verhalten von Produkten in All- tagssituationen verlässlich und objektiv miteinander vergleichen zu können. Der Betrach- ter ist damit nicht mehr den Herstelleraussagen und unzuverlässigen Tests ausgeliefert, sondern kann einfach und leicht diese miteinander vergleichen.

Diese Arbeit implementiert das zu testende System eines solchen Benchmarks in Form eines Buchladens und prüft damit das Zusammenspiel verschiedener Technologien. Seine Hauptaufgabe wird aber nicht darin liegen, mit anderen Implementierungen verglichen zu werden, sondern dessen Verhalten unter verschiedenen Situationen im Voraus zu bestimmen. Auch für diese Art der Verwendung ist eine einheitliche Testplattform beson- ders wichtig. Die Verwendung von Benchmarks gewinnt aus diesen vielfältigen Einsatz- möglichkeiten immer mehr an Bedeutung und wird in der Zukunft einen wichtigen Faktor darstellen.

2

TPC Benchmark W

2. TPC Benchmark W

Der TPC Benchmark W wurde vom Transaction Procession Performance Council spezifi- ziert und besitzt eine hohe Akzeptanz der Industrie. Mit objektiven Leistungsdaten sowie einer realitätsnahen Aufgabenstellung wurde er zum Vorbild für Benchmarks, welche das Zusammenspiel verschiedener Technologien, wie Datenbanken und Applikationsserver, beinhalten.

2.1. Transaction Processing Performance Council

Das Transaction Processing Performance Council (TPC) wurde im August 1988 durch Omri Serlin zusammen mit acht Firmen gegründet. Ziel dieser non-profit Organisation ist es, „Transaktionsprozesse und Datenbankbenchmarks zu definieren und die objektiven und verifizierbaren TPC-Leistungsdaten der Industrie zugänglich zu machen“ 1 . Das TPC

spezifiziert hierfür neben dem zu testenden System das Anwenderverhalten und die Be- rechnung der Testergebnisse. Diese werden meist in Transaktionen pro Sekunde ange- geben. Als weiterer Wert werden die Leistungskosten pro Transaktion in US-Dollar be- stimmt, dem die Kosten der Hardware zugrundeliegen.

2.2. Grundlegende Eigenschaften des TPC Benchmark W

Der TPC Benchmark W (TPC-W) ist ein transaktionaler Webbenchmark und wurde im Dezember 1999 zum ersten Mal veröffentlicht. Zwischenzeitlich ist er in Version 1.8 er- hältlich. Er stellt dem Lastgenerator eine Internethandelsplattform in Form eines Buchla- dens zur Verfügung, welche die Aktivitäten eines geschäftsorientierten, transaktionalen Webservers simuliert. Es wird hierbei versucht auf beiden Seiten ein möglichst reales System zu definieren. Daher zählt zu den Charakteristika des Benchmarks unter anderem die dynamische Webseitengenerierung durch Datenbankzugriffe, mehrere parallele Brow- sersessions und eine hohe Anzahl an Datenbanktabellen, welche in Größe und Attribut- charakteristika stark variieren.

Die Leistung des zu testenden Systems wird in durchgeführten Webinteraktionen pro Se- kunde angegeben. Die Interaktionen bestehen aus drei Kategorien: primäres Einkaufen (WIPS), Durchsehen des Angebots (WIPSb) und webbasiertes Ordern (WIPSo). Es wird dabei vor allem der WIPS-Rate sowie dem Preis pro WIPS in US-Dollar Beachtung ge- schenkt.

1 Selbstbeschreibung des TPC [TPCABOUT]

3

TPC Benchmark W

2.3. Datenbanktabellen

Die primären Datenbanktabellen werden durch den TPC-W genau spezifiziert 1 . Wie be-

reits erwähnt arbeitet der Benchmark mit einer hohen Anzahl an Datenbanktabellen, bei denen sowohl in der Anzahl an Spalten als auch der Tupel hohe Variationen auftreten. Abbildung 2-1 zeigt das Tabellenlayout.

1 Abbildung 2-1: Tabellenlayout nach TPC-W

Ein Beispiel für geringe Datenmenge zeigt Tabelle COUNTRY auf. Neben nur vier Attri- buten besitzt sie lediglich 46 Landeseinträge 2 . Tabelle ITEM hingegen besitzt die meisten

Attribute und speichert in den Spalten I_IMAGE und I_THUMBNAIL die beiden Grafiken eines jeden Buches. Die Tabellen SHOPPINGCARTLINE und ORDER_LINE speichern eine mittlere Anzahl an Attributen, deren Datenmenge ebenfalls durchschnittlich ausfällt. Im Gegensatz zu den vorherigen Tabellen wird es hier aber eine hohe Anzahl an Tupeln geben, da die einzelnen Buchtitel jedes Warenkorbes beziehungsweise jeder Bestellung gespeichert werden.

1 TPC-W Spezifikation, Abschnitt 1.3 2 TPC-W Spezifikation, Abschnitt 4.6.2.15

4

TPC Benchmark W

Tabelle 2-1: Tabellenbeschreibung der Datenbank

Tabelle 2-1 zeigt die einzelnen Tabellen mit einer Kurzbeschreibung auf. Die Tabelle USERSESSION ist als einzige nicht im TPC-W spezifiziert. Sie dient der Verwaltung der einzelnen Benutzersessions und speichert neben einer eindeutigen ID die Kundennummer und das letzte Besuchsdatum des Besuchers. Das Anlegen dieser zusätzlichen Tabelle ist gemäß TPC-W Spezifikation 1 erlaubt.

2.3.1. Datenbankbestand Der TPC-W Benchmark geht davon aus, dass entsprechend der Testskalierung ein Grunddatenbestand vorhanden ist. Dieser enthält nicht nur die entsprechenden Bücher, sondern erstreckt sich über die gesamten Datenbanktabellen. Die entsprechenden Werte sowie die zu produzierenden Datensätze werden in den Abschnitten 4.6 bis 4.8 der Benchmark-Spezifikation beschrieben. Für jeden Test muss die Anzahl der Bücher sowie die Anzahl der emulierten Browser festgelegt werden.

Die Testskalierung geht bei der Buchanzahl von 1.000, 10.000, 100.000, 1.000.000 oder

10.000.000 Einträgen aus 23 . Entsprechend ist die Anzahl der Autoren jeweils ein Viertel

dieser Zahl. Die Anzahl der vorhandenen Kundendaten wird auf Basis der emulierten 1 TPC-W Spezifikation, Abschnitt 1.3.1, Comments [TPCW] 2 TPC-W Spezifikation, Abschnitt 4.7.1 [TPCW]

3

5

TPC Benchmark W

Browser ermittelt und beträgt hiervon das 2.880-fache. Die Anzahl der Kunden legt sowohl die Anzahl der Bestellungen fest (Faktor 0.9) als auch die Einträge in der Adressentabelle (Faktor 2). Zu jeweils einer Bestellung wird eine Kreditkarteninformation angelegt und ein bis fünf bestellte Buchtitel. Die meisten Werte sind unabhängige Zufallswerte.

Für die Einträge der Buchtitel und Autorennachnamen stellt der TPC-W ein Programm namens WGEN zur Verfügung. Dieses produziert anhand der vorgegebenen Buchanzahl die entsprechende Anzahl an Einträgen. Die Autorennamen besitzen die Form [BA]*[Buchstabe]*. Für die Titel kommt die Form [Phrase][BA]*[Buchstabe]*[Phrase] zum Einsatz. Eine Phrase besteht dabei aus realen Teilen von Buchtiteln. Die Anzahl der „BA“- Zeichenfolgen und der anschließenden Buchstaben ergibt sich aus der Anzahl der Buch- titel beziehungsweise der Autoren. Diese Form der Einträge erlaubt es dem emulierten Browser, nach bestimmten Kriterien Suchanfragen zu stellen, um einheitliche Ergebnis zu erhalten.

Das Kommandozeilenprogramm LAST generiert aus den übergebenen Parametern eine Buch-Grafik, wie zum Beispiel in Abbildung 2-2. Dabei muss sowohl der Dateiname als auch die Bildgröße in Bytes definiert werden. Die Verteilung der einzelnen vorgegebenen Dateigrößen ist in Abschnitt 1.5.1 und 1.5.2 der Benchmark-Spezifikation angegeben und reicht von 5kB bis 250kB.

Abbildung 2-2: Beispiel für eine Buchgrafik

Ein weiteres Augenmerk sollte auf die Generierung des Benutzernamens und des dazu- gehörigen Passworts gelegt werden. Grundlage dieser Werte ist die Kundennummer C_ID. Der Benutzername errechnet sich durch die Funktion DigSyl(D, N) 1 , wobei Para- meter D ein positiver Integer ist und N die Stellenanzahl von D angibt. Besitzt D weniger Ziffern als von N vorgegeben, so wird D mit vorangestellten 0 entsprechend vergrößert. Wird der Parameter N mit dem Wert Null übergeben, so wird D ohne Auffüllen umgewan- 1 TPC-W Spezifikation, Abschnitt 4.6.2.9 [TPCW]

6

TPC Benchmark W

delt. Jeder Ziffer von D wird ein vorgeschriebener String der Länge zwei zugeordnet und das Ergebnis zurückliefert. Der Benutzername C_UNAME ergibt sich aus DigSyl(C_ID, 0). Da jede Kundennummer eindeutig ist, muss dies auch der Benutzername sein. Das Passwort ergibt sich aus dem in Kleinbuchstaben umgewandelten Benutzernamen.

2.3.2. Identifikation des Benutzers Um den Benutzer während seiner Einkaufssession identifizieren zu können, wird das ent- sprechende Verhalten der beiden Seiten in den Absätzen 2.2.3 bis 2.2.5 der TPC-W- Spezifikation beschrieben. Zur Identifikation aller Besucher wird serverseitig jedem emu- lierten Browser ein Cookie mit einer eindeutigen Nummer zugeordnet. Diese wird in der Tabelle USERSESSION zusammen mit dem aktuellen Datum gespeichert. Damit ist es jederzeit möglich, diesen Benutzer zu identifizieren. Des weiteren kann, falls der Besucher sich registriert und damit zum Kunden wird, die Kundennummer mit gespeichert werden. Der Vorgang wird in Abbildung 2-3 dargestellt.

Abbildung 2-3: Benutzerregistrierung durch Cookies

Ruft ein Benutzer zum ersten Mal die Startseite des Buchladens auf, so muss er, falls er bereits Kunde ist, seine Kundennummer an das System übermitteln. In diesem Fall erhält er ebenfalls eine eindeutige Identifikationsnummer in Form eines Cookies zugewiesen. Im Gegensatz zu einem anonymen Benutzer kann an dieser Stelle sofort die Kundennummer mit gespeichert werden. Der Fall, dass ein Kunde sich erst im späteren Verlauf seiner Ein- kaufssession als bereits registrierter Kunde erweist, wird durch die TPC-W Spezifikation ausgeschlossen 1 .

1 TPC-W Spezification, Abschnitt 2.2.3, Comment [TPCW]

7

TPC Benchmark W

2.4. Webseiten

Die Webseiten bilden das grafische Frontend des Buchladens und sind dynamisch ge- staltet. Sie sind die einzige Kommunikationsmöglichkeit zwischen Benutzer und Laden- system. Der Aufruf der einzelnen Seiten und die Übergabe von Parametern startet ver- schiedene Geschäftsprozesse und führt schließlich zu Ausgabeergebnissen, die in der Antwortseite enthalten sind.

Abbildung 2-4: Seitennavigation nach TPC-W

8

TPC Benchmark W

2.4.1. Übersicht Seitennavigation Der TPC-W spezifiziert in Abschnitt 2.2.20 die Möglichkeiten des Benutzers, durch die Internetseiten zu navigieren. Ein Abweichen ist nicht erlaubt und sollte daher bei den ser- verseitigen Überprüfungen ebenfalls keine Berücksichtigung finden. Die einzelnen Web- interaktionen der Abbildung 2-4 1 zeigen die Möglichkeiten der Navigation auf, welche in den einzelnen erzeugten Webseiten fest verlinkt sind. 2 Die Pfeile stellen die Navigations- richtung dar, deren Beschriftung die Button-Namen. Ein Linkpuffer (Cached URLs = CURL) ermöglicht es, mehrere Detail-Seiten nacheinander zu laden.

2.4.2. Web-Elemente Als Startseite für jede Session muss die Home-Seite verwendet werden. Auf dieser Seite wird der Benutzer, sofern seine Kundeninformationen vorhanden sind, mit seinem Vor- und Nachnamen begrüßt. Handelt es sich nicht um einen Kunden, so wird eine allgemeine Willkommensformel angezeigt, wie in Abbildung 2-5 zu sehen ist.

Abbildung 2-5: Startseite des Buchladens

1 TPC-W Spezifikation, Grafik 2.2.20 [TPCW]

2

9

TPC Benchmark W

Weitere Elemente sind fünf eingeblendete Werbethumbnails. Die einzelnen Buchtitel wer- den dabei wie folgt ermittelt: Der Server wählt aus der Menge der vorhandenen Buch-IDs eine aus und holt ihre verwandten IDs (I_RELATED1 bis I_RELATED5). Es werden die jeweiligen fünf Thumbnails und ein Link auf die Detailseite der einzelnen Bücher darge- stellt. Dieser Vorgang wird vom TPC-W als Promotional Processing bezeichnet 1 .

Die Webseite für neue Produkte wählt die 50 neuesten Bücher der jeweiligen Kategorie aus, sortiert nach ihrem Erscheinungsdatum. Die Best-Seller-Seite (Abbildung 2-6) arbei- tet ähnlich. Hier werden allerdings die letzten 3.333 Bestellungen herangezogen und de- ren 50 meist verkauftesten Bücher der jeweiligen Kategorie angezeigt, sortiert nach ihrer Verkaufsanzahl. Angezeigt wird jeweils der Vor- und Nachname des Autors, sowie der Buchtitel und ein Link auf dessen Detailseite.

Abbildung 2-6: "Best-Seller" - Seite

Die Detailseite zeigt nahezu alle Informationen an, die über das jeweilige Buch verfügbar sind. Als Bilddatei wird hier nicht das Thumbnail, sondern das meist größere I_IMAGE

1 TPC-W Spezifikation, Abschnitt 2.2.18 [TPCW]

10

TPC Benchmark W

angezeigt. Diese Seite stellt zudem als Einzige die Möglichkeit zur Verfügung das Buch dem Warenkorb hinzuzufügen, sowie auf dessen Administrationsseite zu gelangen.

Die Seite des Warenkorbs kann auf zwei unterschiedliche Arten erreicht werden: Zum ei- nen durch verschiedene Seiten mit einem einfachen Link oder durch die Detailseite eines Buches, wodurch ein Flag übergeben wird, welches ein Hinzufügen zum Warenkorb aus- löst.

Wurde die zweite Möglichkeit gewählt, so fügt der Server das Buch mit einer Bestellmen- ge von eins dem Warenkorb hinzu oder erhöht die Bestellmenge um eins, falls das Buch bereits vorhanden ist. Die Anzahl der zu bestellenden Bücher kann durch den Benutzer manuell geändert werden. Der Link Refresh verweist wieder auf den Warenkorb und übergibt die geänderten Mengen. Eine Anzahl von Null löscht das jeweilige Buch aus der Bestellliste. Das Aktualisieren der Anzahl der einzelnen Posten geschieht dabei auf Ser- verseite zufallsgesteuert 1 .

1 TPC-W Spezifikation, Abschnitt 2.4.5.1 [TPCW]

11

  TPC Benchmark W  

  Wird der Warenkorb lediglich durch einen normalen Link aufgerufen so wird nur dessen  

Inhalt angezeigt, ohne Änderungen vorzunehmen. Eine Ausnahme bildet allerdings ein

  leerer Warenkorb In diesem Fall wird wie beim Promotional Processing ein zufälliges  

  Buch ausgewählt Dessen Wert I RELATED1 wird dem Warenkorb mit einer Anzahl  von

  eins hinzugefügt Es soll damit sicher gestellt werden dass sich immer mindestens ein  

  Buch im Warenkorb befindet  

  Durch den Button Checkout gelangt der Benutzer zur Registrierungsseite Hier muss ge-  

  wählt werden ob es sich um einen bereits registrierten Benutzer handelt oder nicht Re-  

  gistrierte Benutzer müssen nur Benutzername und Passwort angeben für eine Erstregist-  

  rierung sind weitere Daten notwendig Durch Buy Request gelangt der Benutzer zum  

  nächsten Einkaufsschritt Abbildung 2-7 zeigt einen Screenshot des Warenkorbs  

  Die Verbindung zu dieser Seite wird mit dem Secure Sockets Layer (SSL) vor fremden  

  Zugriff geschützt Der Benchmark fordert hierfür einen entsprechenden Handshaking-  

  Prozess Auf dieser Seite wird ein neuer Kunde angelegt falls nötig Der eingegebene  

  Kundenname und das Passwort wird wie in Absatz 2 3 1 beschrieben mit der Funktion  

  DigSyl(D N) neu errechnet und gespeichert Die Webseite enthält die eingegebenen Per-  

  sonen- und Bestelldaten Außerdem wird dem Kunden zusätzlich die Möglichkeit gegeben  

  eine alternative Lieferadresse anzugeben Zur Bestellabwicklung ist die Eingabe der Kre-  

  ditkarteninformationen erforderlich Ein Link auf Process Order beendet den Bestellvor-  

  gang.  

  Abbildung 2-8: Ausgabe der PGE-Autorisierungen  

  Die per SSL gesicherte Kaufbestätigungsseite zeigt dem Kunden noch einmal alle be-  

  stellten Artikel und eine Übersicht über die Gesamtkosten Außerdem wird die Bestell-  

  nummer angezeigt Intern werden die Daten der Tabellen SHOPPINGCART und SHOP-  

  PINGCARTLINE entsprechend in ORDERS und ORDERLINE kopiert und anschließend  

  der Warenkorb geleert Zur Zahlungsabwicklung nimmt der Server Kontakt mit dem extern  

  gelegenen Payment Gateway Emulator auf der ein Kreditkarteninstitut und dessen  

12

TPC Benchmark W

Clearingstelle simuliert. Dessen Autorisationen werden wie in Abbildung 2-8 ausgegeben. Wurde keine zusätzliche Lieferadresse angegeben, so wird diese mit der Rechnungs- adresse gleich gesetzt. Der Einkaufsvorgang ist für den Kunden an dieser Stelle abge- schlossen.

Um einen Einblick in die letzte Bestellung zu erlangen, kann jeder Kunde von der Home- Seite aus auf die per SSL gesicherte Bestellabfrageseite (Buy Request) gelangen. Hier muss er seinen Benutzernamen und das Passwort angeben, um auf die ebenfalls per SSL gesicherte Bestellanzeigeseite (Buy Confirm) zu gelangen.

Die Bestellanzeigeseite zeigt nun sämtliche zur Bestellung gehörige Daten, wie Rech- nungs- und Lieferadresse, Kreditkarteninformationen, Daten der einzelnen Buchtitel und Gesamtsummen der Bestellung an.

Die Suchseite ist von nahezu jeder Webseite erreichbar. Sie bietet die Möglichkeit, nach den Attributen Autor, Titel und Kategorie zu suchen, wie in Abbildung 2-9 gezeigt. Der entsprechende Suchbegriff muss eingegeben werden und die Anfrage wird durch Wahl des Submit-Buttons übermittelt.

Die Suchergebnisseite zeigt die Ergebnisse der Suchanfrage an. Wurde nach dem Autor gesucht, so muss sich der Suchbegriff am Anfang irgendeines Wortes des Nachnamens befinden. Ebenso bei der Titelsuche. Wird nach der Kategorie gesucht, so muss exakt diese vorhanden sein. Die ersten 50 Ergebnisstitel werden unsortiert zusammen mit dem Vor- und Nachnamen des Autors angezeigt und auf die jeweilige Detailseite verlinkt.

Die Administrationsseite eines Buches zeigt noch einmal dessen empfohlenen Verkaufs- preis, den eigentlichen Verkaufspreis, sowie das Titelbild und dessen Thumbnail. Der Be- nutzer kann nun einen neuen Verkaufspreis und neue Grafiken angeben. Der Button Submit Changes verweist auf die Änderungsbestätigung.

13

TPC Benchmark W

Die Änderungsbestätigung ändert die entsprechenden Daten, zeigt die Detailinfos an und führt eine neue Berechnung der verwandten Bücher wie folgt durch: Es werden die letzten

10.000 Bestellungen gesucht, die das zu ändernde Buch enthalten. Aus diesen Bestellun-

gen werden die fünf am häufigsten bestellten Bücher als verwandte Bücher eingetragen. Sind weniger als fünf Bücher vorhanden, so werden durch unterschiedliches Aufaddieren der letzten ID die entsprechenden Werte bestimmt 1 .

2.5. Zugriffsprotokollierung

Der TPC-W sieht in Abschnitt 2.2.13 das Protokollieren der einzelnen Zugriffe vor. Dabei muss für jeden Zugriff auf ein Web-Element die Client-Adresse, ein Zeitstempel, sowie die Request-Zeile des HTTP-Headers, der Statuscode und die Anzahl an gesendeten Bytes protokolliert werden. Das Format muss dem Common Log Format (CLF) des W3C- Konsortiums [CLFW3C] entsprechen. Das folgende Beispiel ist der Protokolldatei des Buchladens entnommen:

Der Benchmark sieht vor, dass mindestens alle 30 Sekunden die Protokolleinträge in ei- nen persistenten Zustand gebracht werden.

1 TPC-W Spezifikation, Abschnitt 2.16.3.3 [TPC-W]

14

Architektur

3. Architektur

Die Entwicklung moderner Softwaresysteme kann meist nicht mehr vollständig durch Ein- Mann-Projekte realisiert werden. Die einzelnen Teilaufgaben sind zu komplex und zu um- fangreich, um diese komplett erfassen und lösen zu können. Daher wurde in dieser Arbeit ein Schichtenmodell entwickelt und ein Großteil der zu erledigenden Aufgaben auf bereits existierende Softwarelösungen ausgelagert.

3.1. Schichtenmodell

Um eine möglichst performante und leicht verständliche Programmierlösung zu entwi- ckeln, ist die Entscheidung der zu verwendeten Technologien von höchster Bedeutung. Um eine möglichst transparente Entwicklung zu gewährleisten, die aktuellen Program- mierstandards entspricht, wurde wie in Abbildung 3-1 eine fünf-Schichtenarchitektur ein- geführt.

Abbildung 3-1: Schichtenmodell

Schicht fünf stellt den Benutzer dar. An dieser Stelle sieht der Benchmark den entspre- chenden Lastgenerator vor. Doch auch ein menschlicher Benutzer ist hier denkbar. Diese Schicht stellt eine eigenständige Einheit dar, die nach der Spezifikation auf externer Hardware läuft und mittels des TCP/IP-Protokolls mit der darunterliegenden Ebene kom- muniziert.

Die vierte Schicht stellt die eigentliche Kommunikation mit der Außenwelt auf Serverseite dar. Diese Aufgabe wird durch einen Webserver erledigt, der nur einen TCP-Port zur Verfügung hat und die jeweiligen Anfragen weiterleiten muss. Zusammen mit den darun-

15

Architektur

terliegenden Schichten wird ein neues System definiert, welches den zu testenden Buch- laden darstellt.

Die Darstellungsschicht ist verantwortlich für die Generierung der einzelnen Webseiten. Auf dieser Schicht sollen die im Benchmark vorgegebenen Seiten dynamisch mit Inhalt gefüllt werden. Hierzu wird auf die darunterliegende Schicht zurückgegriffen.

Aufgabe der zweiten Schicht ist die Verarbeitung der übergebenen Daten in den jeweili- gen vorgegebenen Geschäftsprozessen. In dieser Schicht ist die gesamte Logik der Web- anwendung untergebracht.

Die Datenschicht ist schließlich allein für die Speicherung der in der zweiten Schicht an- fallenden Daten verantwortlich. Die Persistenz auf dieser Ebene ist durch das ACID- Prinzip bestimmt: Atomarität von Transaktionen, Konsistenz der Daten, Isolation der Transaktionen und dauerhafte Speicherung.

Aufgabe des nächsten Entwicklungsschrittes muss die Festlegung verschiedener Tech- nologien für das erstellte Architekturmodell sein.

3.2. Schicht 5: Benutzer

Der Benutzer auf Schicht fünf stellt gemäß der TPC-W Spezifikation einen emulierten Browser dar. Dieser soll das Verhalten eines menschlichen Benutzers nachahmen, der mit einem Standard-Browser die Webseiten betrachtet. Der emulierte Browser ist angehalten, die Startseite des Buchladen als Eingangsseite zu verwenden und von dort aus der im HTML-Code vorgegeben Navigation zu folgen. Ein Abweichen ist nicht gestattet.

Da es sich bei den Webseiten um reine HTML-Seiten mit entsprechenden Grafiken han- delt, kann der Benutzer aber auch menschlich sein und einen Standard-Browser verwen- den. Dies ist vor allem zu Testzwecken sinnvoll, um die korrekte Abarbeitung der einzel- nen Transaktionen möglichst effizient zu gewährleisten. Da die Implementierung eines emulierten Browsers nicht zu den Aufgaben dieser Arbeit gehört, wird bei den folgenden Betrachtungen von einem menschlichen Benutzer ausgegangen.

3.3. Schicht 3 & 4: Darstellungs- und Kommunikationsschicht

Die Darstellungs- und Kommunikationsschicht kann in den meisten Fällen zusammenge- fasst werden. Softwareprodukte zur Generierung dynamischer Webseiten haben hier oft einen entsprechenden Connector integriert.

16

Architektur

3.3.1. Entscheidung: PHP oder JSP Die Verwendung von Linux als Betriebssystem und die Anforderung eine OpenSource- Lösung zu favorisieren ließ auf der dritten Schicht zwei Möglichkeiten zu: PHP und Java Server Pages. Beide Konzepte erlauben es, programmiersprachliche Elemente im HTML- Code einzubetten und somit dynamisch Webseiten zu generieren. Während es sich bei den Personal Homepage Tools (PHP) um eine eigene Sprache handelt, die um in C pro- grammierte Elemente erweitert werden kann, basiert Java Server Pages (JSP) auf Java. Dies bietet hier den Vorteil, mit einer wesentlich größeren Klassenbibliothek aufwarten zu können. Weitere Ausführungen und Vorteile von JSP finden sich in Abschnitt 4.1.

Ausschlaggebend für die Entscheidung für eine der beiden Konzepte war die Entwicklung der Applikationsschicht. An dieser Stelle sollen nicht nur die einzelnen Benutzertransakti- onen abgewickelt werden, sondern vor allem das Clustering organisiert werden. Eine PHP-Realisierung hätte an dieser Stelle eine komplette Eigenentwicklung erfordert, da es in diesem Bereich keine passende OpenSource-Lösung gibt.

Java Server Pages hingegen bieten zusammen mit Enterprise JavaBeans die Möglichkeit, einen OpenSource Applikationsserver zu verwenden, der um die benötigten Komponenten erweitert wird. Verwaltungsaufgaben wie das Clustering werden nach Spezifikation der Enterprise JavaBeans vom Applikationsserver durchgeführt, der entsprechend konfiguriert werden kann. Nähere Details zu Enterprise JavaBeans sind in Abschnitt 4.2 ausgeführt. Zudem lässt die in Java verwendete Objektorientierung eine zeitgemäße Entwicklung im Bereich größerer Projekte zu. Die aufgeführten Gründe führten nach gründlicher Abwä- gung zu einer Entscheidung für diese Architektur.

3.3.2. Tomcat und Coyote Das Jakarta-Projekt der Apache Software Foundation entwickelt serverseitige Open- Source Anwendungen auf Java-Basis. Eines der Subprojekte ist Tomcat, ein Java Servlet Container, welcher die von Sun Microsystems entwickelte Spezifikation für Java Servlets und Java Server Pages implementiert. Mit Version 4 wurde der Container unter dem Na- men Catalina neu implementiert und entspricht in der aktuellen, als stabil gekennzeichne- ten Version 4.1.18 der Servlet-Spezifikatikation 2.4 sowie JSP 1.2.

Java Server Pages dienen, wie bereits in Abschnitt 3.3.1 beschrieben, der Generierung dynamischer HTML-Dokumente mit Hilfe der Java-Plattform. Damit ist diese Technologie auf Schicht drei des Architekturmodells angesiedelt. Durch den Einsatz von Java lassen

17

Architektur

sich die von Schicht zwei zur Verfügung gestellten Enterprise JavaBeans verwenden, wel- che die eigentliche Geschäftslogik implementieren.

Als Teil des Tomcat-Projekts ist der Coyote-Connector implementiert. Dieser beherrscht unter anderem den HTTP/1.1-Standard, über welchen die einzelnen Webanfragen abge- wickelt werden. Als solches ist Coyote im vorgestellten Schichtenmodell als Schicht vier zu sehen, da an dieser Stelle die Kommunikation mit der Außenwelt abgewickelt wird.

3.4. Schicht 2: Verarbeitung

Durch die Festlegung der Technologie für Schicht drei der in Abbildung 3-1 vorgestellten Schichtenarchitektur ist auf dieser Schicht eine Enterprise JavaBeans (EJB) Lösung na- hezu festgelegt. Die Verwendung einer anderen Technologie als EJB ist denkbar, auf- grund der verwendeten Java Server Pages aber sicherlich nicht sinnvoll. Eine Eigenimp- lementierung würde zudem unnötigen Aufwand zur Erstellung verschiedenester Funktio- nalitäten hervorrufen.

3.4.1. Anforderungen und Softwarevergleich Zu den Anforderungen an die Verarbeitungsschicht gehört natürlich ein hoher Durchsatz. Hier werden alle Verarbeitungsschritte abgehandelt, wodurch sich gerade diese Schicht schnell zu einem Flaschenhals entwickeln kann, der die gesamte Antwortzeit des Systems negativ beinflusst.

Die einzelnen Geschäftsprozesse, welche mit Hilfe der Enterprise JavaBeans Technologie entwickelt werden, sollten zudem nahezu automatisch über den Cluster verteilt werden können. Damit wird der Programmierer an vielen Stellen entlastet und die Gesamtlösung wesentlich stabiler.

Weiterhin kommt der Gesichtspunkt einer OpenSource-Lösung vor allem hier zum Tragen. Der gesamte Buchladen soll zu einem späteren Zeitpunkt entsprechend instrumentiert werden. Da ein möglicher Meßpunkt innerhalb des EJB-Umgebung nicht auszuschließen ist, hat die Verfügbarkeit der Quellcodes eine hohe Bedeutung.

Für die Entwicklung von Enterprise JavaBeans wird ein sogenannter Container benötigt, welcher diese verwaltet. Der Markt für solche Container bietet zur Zeit der Erstellung die- ser Arbeit unterschiedliche Lösungen. Der Inprise Application Server sowie IBMs Websphere sind kommerzielle Produkte, welche als gute Server angesehen werden und reich an Funkionen, aber kostenpflichtig sind. Der ebenfalls kommerzielle, aber teilweise

18

Architektur

kostenlos verfügbare Weblogic Server von BEA zählt ebenfalls zu den erhältlichen Top- produkten. Allerdings ist hier der Quellcode nicht verfügbar, weshalb diese Lösung eben- falls nicht verwendet werden kann. Die vollständige OpenSource-Lösung JBoss von der gleichnamigen Entwicklergruppe erfüllt als einzige Softwarelösung alle genannten Anfor- derungen und wurde aus diesem Grund als EJB-Container gewählt.

3.4.2. JBoss Die JBoss-Group, eine der Hauptgruppen der OpenSource-Vereinigung, entwickelt JBoss seit März 1999 mit aktuellem Versionsstand 3.0.x. JBoss stellt eine Umgebung zur Verfü- gung, die eine vollständige Entwicklung einer J2EE-Anwendung (Java 2 Enterprise Editi- on) gemäß den Sun Microsystems Spezifikationen zulässt.

JBoss besteht dabei vor allem aus dem JBossServer, dem Basis-Container für Enterprise JavaBeans, und der Java Management Extension (JMX) Infrastruktur, mit der JMX kom- patible Komponenten angeschlossenen werden können. Beispiele für JMX-Module sind der eigentliche Container, Datenbanken und Datenquellen, aber auch Module für Web- komponeten wie Java Server Pages, welche im konkreten Fall durch Tomcat realisiert werden. Die Module können an den JMX-Bus angeschlossen werden und stehen ab die- sem Zeitpunkt dem Entwickler zur Verfügung. Diese hohe Modularität hat JBoss einen exzellenten Ruf und entsprechenden Erfolg mit bisher über 3,5 Millionen Downloads 1 ein- gebracht.

Eine weitere für die Implementierung des Projekts nötige Eigenschaft ist das Clustering. Durch entsprechende Konfiguration ist es mit JBoss möglich, auf verschiedenen Rechnern Instanzen zu betreiben und diese transparent nach außen als eine große Instanz erschei- nen zu lassen. 2

Die Entscheidung für JBoss lag aber hauptsächlich an der Marktpräsenz des Produkts. Durch die Verleihung des JavaWorld Editors' Choice Awards 2002 als bester Applikati- onsserver hat sich JBoss damit zu einer quasi Standardsoftware entwickelt und gewinnt einen immer höheren Stellenwert im industriellen Umfeld. Damit wird in dieser Arbeit nicht nur eine hohe Qualität des Gesamtprojekts sicher gestellt, sondern auch ein Fokus auf die Verwendung aktueller Technologien gesetzt.

1 Stand Juni 2003 [JBOSS]

2

19

Architektur

3.5. Schicht 1: Datenhaltung

Die unterste Schicht des Architekturmodells stellt die Datenbankebene dar. An dieser Stelle werden Daten aus Schicht zwei, deren persistente Speicherung für den Betrieb notwendig ist, entgegengenommen. Hier soll ebenfalls eine OpenSource-Lösung einer kommerziellen vorgezogen werden, um spätere Anpassungen vornehmen zu können.

3.5.1. Ideallösung Die Entscheidung für eine Datenbank musste mit den Anforderungen von JBoss abge- stimmt werden. Der Container unterstützt zwar Clustering, allerdings wird dies nicht auf Datenbankebene durchgeführt, was gerade im Umfeld der Lastverteilung dringend not- wendig ist. Aus diesem Grund muss bis zur Fertigstellung einer entsprechenden JBoss- Implementierung ein Datenbankclustering vorgenommen werden. Die ideale Lösung für dieses Probleme ist eine Datenbank, die synchrones Master-Master-Clustering unter- stützt, wie in Abbildung 3-2 zeigt.

Abbildung 3-2: Synchrones Update

In diesem Fall dürfen auf jeder Datenbankinstanz Änderungen durchgeführt werden. Die- se werden synchron auf den anderen Knoten geändert. Schreib- und Lesesperren bei Transaktionen werden hier ebenfalls global gesetzt. Entsprechende Datenbanken gibt es zur Zeit allerdings nur im kommerziellen Bereich. Die Datenbank der Firma Oracle besitzt als einzige die Möglichkeit, ein synchrones Master-Master-Clustering durchzuführen. Die hohen Lizenzkosten wären bei einer Nutzung im universitären Umfeld durch die Verwen- dung der Lizenzen des Datenbanklehrstuhls des Instituts entfallen. Bei dem Versuch, die Datenbank in das Projekt zu integrieren kam es allerdings zu Störungen im laufenden Be-

20

Architektur

trieb. Recherchen im JBoss-Entwicklerforum ergaben, dass der Javadatenbanktreiber JDBC im Clusteringumfeld zu diesen Problemen führt. Eine Lösung des Problems war bis zur Fertigstellung dieser Arbeit nicht in Sicht.

3.5.2. HypersonicDB Die mit JBoss ausgelieferte Datenbank HypersonicDB, ein OpenSource-Projekt, b e- herrscht in Ihrer Grundversion kein Clustering. Jedoch haben Entwickler, die unter ande- rem am JBoss-Projekt arbeiten, eine asynchrone Master-Master-Clustering-Funktionialität eingeführt. Eine asynchrone Lösung ist aber in einem hochbelasteten System nicht trag- bar, da damit Dateninkonsistenzen bereits nach einer kurzen Zeitspanne auftreten wür- den. Eine synchrone Lösung ist nach Aussage der Entwickler in Sicht, jedoch nicht vor Fertigstellung dieser Arbeit.

Abbildung 3-3 zeigt eine solche Inkonsistenz auf. Host 1 und 2 ändern gleichzeitig das selbe Tupel. Nach den Aktualisierungen entspricht der Wert des Tupels in Datenbank 1 der Update-Funktion von Host 2 und von Datenbank 2 der von Host 1. Welcher Wert in Datenbank 3 geschrieben wird, ist von der Geschwindigkeit der beiden anderen abhängig und damit nicht vorhersehbar.

Abbildung 3-3: Inkonsistenz bei asynchronen Änderungen

Da Hypersonic SQL als Standarddatenbank in JBoss integriert ist, wäre der Betrieb mit dieser Datenbank natürlich wünschenswert. Allerdings stößt man auch hier auf Grenzen. Bei der Entwicklung stellte sich heraus, dass sich die Bilddaten nicht in HypersonicDB

21

Architektur

speichern lassen, da das Datenvolumen zu groß ist. Aus diesem Grund ist für diese Lö- sung eine zweite Bilddatenbank unumgänglich. Ein mögliches Lösungsszenario für späte- re Arbeiten an diesem Projekt wird im Implementierungskapitel beschrieben.

3.5.3. MySQL Da eine Master-Master-Clustering Lösung im Datenbankbereich nicht in Aussicht stand, musste eine andere Lösung gefunden werden. Die im Vergleich zu anderen OpenSource- und kommerziellen Lösungen schnelle OpenSource Datenbank MySQL bietet eine Mas- ter-Slave-Lösung an. Dabei können Daten nur am Master-Knoten geändert werden. Die Änderungen werden dann auf die einzelnen Slave-Instanzen überspielt. Da die MySQL- Datenbank seit Version 4 die für Datenbanktransaktionen wichtigen ACID-Eigenschaften (Atomicy, Consistency, Isolation, Durability) in Form der InnoDB-Tabellentypen unter- stützt, können Änderungen am Master-Knoten unter Berücksichtigung der transaktionalen Forderungen durchgeführt werden, wie in Abbildung 3-4 gezeigt.

Abbildung 3-4: Aktualisierung nur auf der Master-Instanz

Für lesende Clients an einem der Slave-Instanzen spielen die Vorgänge am Masterknoten während einer Transaktion keine Rolle, da sie erst nach Beendigung eines vollständigen Transaktionsvorgang überspielt werden. Damit wird die Konsistenz der Datensätze ge- wahrt. Eine strikte Trennung zwischen lesenden und schreibenden Geschäftstransaktio- nen, wie im Implementierungskapitel beschrieben, ermöglicht somit eine Übergangslösung für das Projekt.

22

Architektur

3.6. Gesamtarchitektur

Die letzten Abschnitte haben die einzelnen Softwareprogramme für das Schichtenmodell

vorgestellt, welche in der Architektur verwendet werden. Damit ergibt sich die in Abbildung

3-5 aufgezeigte Lösung.

Abbildung 3-5: Schichtenmodell mit Softwareprodukten

23

Grundlagen

4. Grundlagen

In diesem Kapitel sollen die Grundlagen für Java Server Pages und Enterprise JavaBeans erläutert werden. Die Ausführungen sollen ein Verständnis für die Implementierung er- möglichen. Auf den folgenden Seiten kann aber lediglich ein Überblick über diese beiden Technologien gegeben werden. Für eine vollständige Erklärung aller Zusammenhänge kann an dieser Stelle nur auf die angegebene Literatur verwiesen werden.

4.1. Java Server Pages

Java Server Pages (JSP) ist eine Technologie für die Programmierung von Webseiten mit dynamischen Inhalten und stammt von Sun Microsystems. Ziel von JSP ist es, die Ent- wicklung von Web-Anwendungen zu beschleunigen, und wie bereits bei Java, portabel und sicher zu gestalten.

4.1.1. Historische Entwicklung Der folgende Abschnitt soll einen kurzen Überblick über die vier bekanntesten Technolo- gien zur Generierung von dynamischen Webseiten in chronologischer Entwicklung zeigen. Für jede der aufgeführten Technologien ist in Tabelle 4-1 ein kurzes Hello World!-Beispiel gezeigt.

Common Gateway Interface (CGI)

In der Anfangsphase des World Wide Web wurden lediglich statische Elemente zur Verfü- gung gestellt. Sehr früh kam der Wunsch nach dynamischen Inhalten. Das Common Gate- way Interface (CGI) generierte in dieser frühen Phase der Webentwicklung dynamische Seiten. Es entwickelte sich schnell zum Standard und wurde mit einer zahlreichen Anzahl von Tools und Scriptsprachen erweitert. Da für jede Anfrage ein neuer Prozess gestartet werden muss, ist diese Methode trotz späterer Nachbesserung sehr langsam. Ein weiterer Nachteil dieses Interfaces ist die Behandlung von Requests, Cookies, Sessions oder Templates. Für die Umsetzung dieser Techniken ist der Programmierer vollständig selbst verantwortlich.

Java Servlets

1994 schrieb James Gosling, einer der Java-Väter, einen vollständig Java-basierten Web- server. Innerhalb dieses Projekts entstand das Konzept der Servlets. Servlets stellen klei- ne Programmstücke dar, die wie auch CGI, als Ausgabe Webseiten generieren. Für die

24