Lade Inhalt...

Nutzung einer Datenbank mit Java-Servlets

©2001 Diplomarbeit 124 Seiten

Zusammenfassung

Inhaltsangabe:Einleitung:
In jeder Organisation gibt es ein so genanntes schwarzes Brett, auf dem aktuelle Informationen ausgehangen werden. Um zu prüfen, ob neue Informationen aushängen, muss oft viel Zeit und Aufwand betrieben werden. Es wäre schön, wenn es zusätzlich zu dem schwarzen Brett noch eine Informationsseite im Internet geben würde. Auf dieser Seite könnten dann kurze Informationen veröffentlicht werden, die darauf hinweisen, dass eine Änderung am schwarzen Brett durchgeführt wurde. Es könnten auch komplette Hinweise über z.B. Terminänderungen und Fristen auf dieser Informationsseite publiziert werden.
Dadurch ist die Möglichkeit gegeben, aktuelle Informationen über das Internet abzurufen. Somit ist der Informationsweg flexibler und effizienter gestaltet. Dieses Informationssystem kann und soll das schwarze Brett nicht ersetzen, aber sinnvoll erweitern.
Mit dieser Diplomarbeit wird solch ein Informationssystem speziell für den Fachbereich Elektrotechnik und Informationstechnik der Fachhochschule Aachen realisiert.
Die in der Studie erwähnte CD ist im Lieferumfang nicht enthalten, da sie für das Verständnis der Studie nicht notwendig ist.

Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Motivation1
2.Analyse2
2.1Definition der Aufgabenstellung2
2.2Der vorhandene Webserver3
2.2.1Netzstruktur4
2.2.2Eingesetzte Software5
2.3Anforderung an das Informationssystem6
2.3.1Allgemeine Anforderungen7
2.3.1.1Sicherheit7
2.3.1.2Flexibilität8
2.3.1.3Antwortzeit8
2.3.1.4Kosten9
2.3.2Zusätzliche Anforderung an die Datenbank9
2.3.3Zusätzliche Anforderung an den Applikation-Server9
2.3.4Zusätzliche Anforderung an die Webanwendung10
3.Lösungskonzepte13
3.1Auswahl der Softwarekomponenten13
3.1.1Applikation-Server – Servlet Engine14
3.1.2Datenbank Management System16
3.1.3Datenbanktreiber18
3.1.4Zusätzliche Softwarekomponenten20
3.1.5Zusammenfassung20
3.2Sicherheit21
3.2.1Verschlüsselung21
3.2.2Sicherheitsebenen25
3.2.3Sitzungsverfolgung26
3.2.4Logmechanismus28
3.2.5Abkapselung der Daten von der Webanwendung30
3.3Flexibilität31
3.3.1Nutzung von Dokumentenvorlagen31
3.3.2Konfiguration der Webanwendung32
3.3.3Hilfesystem33
3.4Antwortzeit34
3.4.1Datenbank Verbindungspool34
3.4.2Komprimierter Datenstrom36
3.5Entwurf der Datenbank36
3.6Definition der Hilfsklassen37
3.7Definition der […]

Leseprobe

Inhaltsverzeichnis


ID 5243
Wollenhaupt, Michael: Nutzung einer Datenbank mit Java-Servlets / Michael Wollenhaupt -
Hamburg: Diplomica GmbH, 2002
Zugl.: Aachen, Fachhochschule, Diplom, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany

Inhaltsverzeichnis
I
Inhaltsverzeichnis
1. Motivation... 1
2. Analyse ... 2
2.1 Definition der Aufgabenstellung ... 2
2.2 Der vorhandene Webserver ... 3
2.2.1 Netzstruktur ... 4
2.2.2 Eingesetzte Software ... 5
2.3 Anforderung an das Informationssystem ... 6
2.3.1 Allgemeine Anforderungen ... 7
2.3.1.1 Sicherheit... 7
2.3.1.2 Flexibilität ... 8
2.3.1.3 Antwortzeit ... 8
2.3.1.4 Kosten... 9
2.3.2 Zusätzliche Anforderung an die Datenbank ... 9
2.3.3 Zusätzliche Anforderung an den Applikation-Server... 9
2.3.4 Zusätzliche Anforderung an die Webanwendung... 10
3. Lösungskonzepte ... 13
3.1 Auswahl der Softwarekomponenten ... 13
3.1.1 Applikation-Server ­ Servlet Engine... 14
3.1.2 Datenbank Management System ... 16
3.1.3 Datenbanktreiber... 18
3.1.4 Zusätzliche Softwarekomponenten... 20
3.1.5 Zusammenfassung ... 20
3.2 Sicherheit ... 21
3.2.1 Verschlüsselung... 21
3.2.2 Sicherheitsebenen ... 25
3.2.3 Sitzungsverfolgung ... 26
3.2.4 Logmechanismus ... 28
3.2.5 Abkapselung der Daten von der Webanwendung ... 30

Inhaltsverzeichnis
II
3.3 Flexibilität ... 31
3.3.1 Nutzung von Dokumentenvorlagen... 31
3.3.2 Konfiguration der Webanwendung... 32
3.3.3 Hilfesystem ... 33
3.4 Antwortzeit ... 34
3.4.1 Datenbank Verbindungspool ... 34
3.4.2 Komprimierter Datenstrom... 36
3.5 Entwurf der Datenbank ... 36
3.6 Definition der Hilfsklassen... 37
3.7 Definition der Servletklassen... 39
3.7.1 About ... 39
3.7.2 AutoLöschen... 40
3.7.3 FächerVerwalten... 40
3.7.4 Hilfe ... 40
3.7.5 Logfile... 41
3.7.6 Login... 42
3.7.7 LoginCheck... 42
3.7.8 NamenÄndern... 42
3.7.9 StartUp... 42
3.7.10 Übersicht... 43
3.7.11 UserVerwalten ... 44
3.7.12 VorlagenVerwalten... 45
3.7.13 Zusammenfassung ... 45
4. Realisierung des Informationssystems ... 49
4.1 Kommunikationsschema... 49
4.2 Erweiterung des Webservers und der Firewall... 50
4.3 Umsetzung der Datenbank ... 50
4.3.1 Verwendete Datentypen... 51
4.3.2 Gegebene Einschränkungen durch MySQL ... 53
4.3.3 Erstellen einer Datenbank mit autorisiertem Zugriff... 54
4.4 Aufbau der Webanwendung... 55

Inhaltsverzeichnis
III
4.4.1 Benötigte Hilfsklassen ... 55
4.4.1.1 Link... 57
4.4.1.2 Log... 57
4.4.1.3 SchliesseVerbindungen... 59
4.4.1.4 Utils ... 59
4.4.1.5 VerbindungsPool... 61
4.4.2 Generelle Beschaffenheit einer Servletklasse... 64
4.4.3 Integration der vorgestellten Konzepte... 66
4.4.3.1 Das Sicherheitskonzept ... 66
4.4.3.2 Flexibilität ... 67
4.4.3.3 Antwortzeit ... 68
4.4.4 Interaktion der Servlets mit dem Benutzer ... 69
4.4.5 Spezialisierung der generellen Servletklassen... 70
4.4.6 Servletklassen ... 74
4.4.6.1 About ... 75
4.4.6.2 AutoLöschen ... 75
4.4.6.3 FächerVerwalten... 75
4.4.6.4 Hilfe... 77
4.4.6.5 Logfile... 77
4.4.6.6 Login... 77
4.4.6.7 LoginCheck... 78
4.4.6.8 NamenAendern ... 80
4.4.6.9 StartUp ... 80
4.4.6.10 Übersicht ... 84
4.4.6.11 UserVerwalten... 86
4.4.6.12 VorlagenVerwalten... 87
5. Erfahrung im Testbetrieb ... 89
5.1 Antwortzeit ... 89
5.2 Fehler in Tomcat ... 90
5.3 Die Java virtuelle Maschine (JVM)... 91
5.4 Komprimierter Datenstrom ... 92

Inhaltsverzeichnis
IV
6. Bewertung und Ausblick... 93
6.1 Bewertung... 93
6.1.1 Informationsflusserhöhung ... 93
6.1.2 Sicherheit ... 93
6.1.3 Antwortzeit ... 94
6.1.4 Entstandene Kosten ... 95
6.1.5 Flexibilität... 95
6.1.6 Administrations- und Wartungsaufwand... 97
6.1.7 Einfache Nutzbarkeit ... 98
6.1.8 Darstellung der generierten Webseiten... 98
6.1.9 Datenbankintegration... 98
6.2 Verbesserungs- und Erweiterungsvorschläge... 99
6.3 Ausblick ... 101
7. Anhang ... 102
7.1 Erweiterung des Apache Webservers... 102
7.2 Installation von Tomcat ... 104
7.3 Schnittstelle zwischen Apache und Tomcat ... 105
7.4 Installation des MySQL Datenbanksystems... 106
7.5 Installation der Webanwendung... 107
7.6 Integrationsverweise ... 109
7.7 Inhaltsstruktur der beigelegten CD... 110
7.8 Glossar ... 111
7.9 Abbildungsverzeichnis ... 116
7.10 Tabellenverzeichnis ... 117
7.11 Literaturverzeichnis... 117

Kapitel 1 ­ Motivation
1
1. Motivation
In jeder Organisation gibt es ein so genanntes schwarzes Brett, auf dem aktuelle In-
formationen ausgehangen werden. Um zu prüfen, ob neue Informationen aushängen,
muss oft viel Zeit und Aufwand betrieben werden. Es wäre schön, wenn es zusätzlich
zu dem schwarzen Brett noch eine Informationsseite im Internet geben würde. Auf
dieser Seite könnten dann kurze Informationen veröffentlicht werden, die darauf hin-
weisen, dass eine Änderung am schwarzen Brett durchgeführt wurde. Es könnten auch
komplette Hinweise über z.B. Terminänderungen und Fristen auf dieser Informations-
seite publiziert werden.
Dadurch ist die Möglichkeit gegeben, aktuelle Informationen über das Internet ab-
zurufen. Somit ist der Informationsweg flexibler und effizienter gestaltet. Dieses In-
formationssystem kann und soll das schwarze Brett nicht ersetzen, aber sinnvoll er-
weitern.
Mit dieser Diplomarbeit wird solch ein Informationssystem speziell für den Fach-
bereich Elektrotechnik und Informationstechnik der Fachhochschule Aachen realisiert.

Kapitel 2 ­ Analyse
2
2. Analyse
Dieses Kapitel beschreibt die zu Grunde liegende Aufgabenstellung, das vorhandene
Webserversystem und die Anforderung an die Erweiterung dieses Systems. Die An-
forderungen beziehen sich dabei auf die Softwarekomponenten von Drittherstellern,
aber auch auf die selbst zu entwickelnden Servlets mit ihren Hilfsklassen.
Im weiteren Verlauf werden die Servletklassen und ihre Hilfsklassen als Weban-
wendung bezeichnet.
2.1 Definition der Aufgabenstellung
Es soll ein Informationssystem
1
mit der zugehörigen Datenbank erstellt werden, das
den Professoren ermöglicht, kurze Informationen im Internet bereitzustellen. Die In-
formationen sollen sich dabei auf die wirklichen Aushänge am schwarzen Brett bezie-
hen, wie z.B. "Die Klausergebnisse vom Fach GFN1, Fachnummer 5271 hängen aus."
Aus Datenschutzgründen sollen diese Informationen nicht weiter aufgeschlüsselt wer-
den. D.h. es sollen keine Listen mit Matrikelnummern und Noten veröffentlicht wer-
den.
Dabei muss gewährleistet sein, dass sich jeder die Informationen mit einem Web-
browser anschauen, aber niemand anderes, außer ein Professor selber, veröffentlichen
und ändern kann. Ein Professor darf aber nur Einträge über seine eigenen Fächer ver-
öffentlichen dürfen. Im Gegensatz dazu soll es einen Administrator geben, der alle
Rechte hat und somit alle Fächer betreffenden Einträge sowie die Fächer selber ändern
kann. Er soll weiter noch die Möglichkeit haben, Benutzer des Informationssystems
verwalten zu können.
Damit das System leicht zu handhaben ist, sollen die auf dem Server vorhandenen
Benutzer zur Authentifizierung genutzt werden. Es sollen Vorlagetexte für oft wieder-
kehrende Einträge genutzt werden können. Diese sollten frei von den Professoren er-
weiterbar sein. Im übrigen sollen die Einträge automatisch nach einer voreingestellten
1
System, das Informationen aufnimmt, verarbeitet und aufbereitet, speichert und bei Bedarf wiedergibt.

Kapitel 2 ­ Analyse
3
Zeit gelöscht werden, was im weiteren Text als Autolöschintervall bezeichnet wird,
um die Pflege der Daten zu vereinfachen.
Darüber hinaus soll jede Änderung, die in der Datenbank durchgeführt wird, in ei-
ner Logdatei gespeichert werden, um nachzuvollziehen, welche Änderung wann und
von wem durchgeführt wurde.
In dieses Informationssystem soll ein Datenbanksystem integriert werden, welches
die Daten verwaltet und bereitstellt. Die Kommunikation zwischen Server und Klient
soll mit Hilfe der
Java
Servlet
2
Technik ermöglicht werden. Diese Technik ermög-
licht, dass bestimmte Javaklassen, die Servlets, Anfragen über das HTTP-Protokoll
entgegennehmen können. Als Antwort können die Servlets in einen Stream schreiben,
der an den anfragenden Klienten gesendet wird. Die Kommunikation soll wie folgt
aussehen:
Webserver
des
Fachbereiches
Servlets
Datenbank
Informationssystem
Abb. 2-1: Geforderte Webservererweiterung
Dabei sollen die Servlets als Schnittstelle zwischen dem Browser des Klienten und
den Daten aus der Datenbank tätig sein. Sie sollen die Daten der Datenbank präsentie-
ren können und den Professoren die Möglichkeit geben, mit der Datenbank zu
interagieren.
2.2 Der vorhandene Webserver
Die weiteren Ausführungen werden sich auf die FH-Aachen / Fachbereich Elektro-
technik und Informationstechnik beschränken, da das Informationssystem in diesem
Bereich eingesetzt werden soll, andere Fachbereiche bzw. (Fach)Hochschulen zeigen
aber keinen großen strukturellen Unterschied. Daraus lässt sich ableiten, dass das In-
2
Servlets: Das sind Javaprogramme, die auf einem Webserver ausgeführt werden. Sie können HTTP-
Anfragen von Webbrowsern auswerten und entsprechende Antworten zurücksenden.
Siehe dazu:
http://java.sun.com/products/servlet/

Kapitel 2 ­ Analyse
4
formationssystem ohne beachtliche Modifikation in andere Hochschulbereiche über-
tragbar ist.
2.2.1 Netzstruktur
Das LAN
3
des Fachbereichs ist weiter in VLAN
4
's unterteilt. Dadurch ist gewährleis-
tet, dass es verschiedene Sicherheitszonen gibt. Die VLAN's untereinander sind über
eine Firewall
5
miteinander verbunden. Dies ergibt dann das LAN, was wiederum über
die Firewall mit dem Internet verbunden ist. Die innere Unterteilung in VLAN's hat
hier den Vorteil, dass man internen Rechnergruppen aufgrund ihrer örtlichen Lage
bzw. Zugänglichkeit verschiedene Rechte im internen Netz geben kann. Genauso
können bedeutsame Rechner, die z.B. die Benutzer zentral verwalten oder wichtige
Dienste zur Verfügung stellen, besonders vor Zugriffen aus dem lokalen Netz bzw.
Internet geschützt werden.
Wie jede größere Organisation, verfügt auch unser Fachbereich über einen Web-
server, der den Fachbereich im Internet präsentiert. Der Webserver ist meist die ei-
gentliche Anlaufstelle aus dem Internet, deshalb ist er im Internet bekannt und muss
gegen Hackerangriffe besonders geschützt sein. Aus diesem Grund befindet er sich,
zusammen mit den restlichen Servern des Fachbereichs, in einer hochgradigen Sicher-
heitszone. Der Server ist über das Internet und über die anderen Sicherheitszonen nur
auf dem Standardport für das Hypertext Transfer Protokoll (http / Port 80) erreichbar,
obwohl auf diesem Server noch andere Dienste ausgeführt werden.
Bei der Darstellung des Fachbereichs und dessen Webserver wird mit Absicht auf
die volle Abbildung der unterschiedlichen VLAN's sowie andere zum Fachbereich
gehörende Rechner und Server verzichtet. Die nicht weiter aufgeführten oder ausge-
führten Strukturen sind für die eigentliche Erweiterung irrelevant. Die Darstellung soll
nur die Erreichbarkeit und die sichere Lage des Webservers verdeutlichen.
3
LAN: Local Area Network (Lokales Netz ­ limitiert auf z.B. ein Gebäude oder eine Organisation,
maximal 10 km)
4
VLAN: Virtual Local Area Network (virtuelles lokales Netzwerk)
5
Firewall: Sicherheitssystem, das die Rechner eines LAN's vor unberechtigten Netzzugriffen schützt.

Kapitel 2 ­ Analyse
5
hochgradige Sicherheitszone
Webserver des
Fachbereiches
Internet
Firewall
des
Fachbereiches
die anderen VLAN's
des Fachbereiches
Bertiebssystem:
SuSE Linux 7.0
Webserver:
Apache
Linux - Passwortdatei
nach außen nur Port 80
verfügbar
weitere Server
Abb. 2-2: Das vorhandene Webserversystem
2.2.2 Eingesetzte Software
Als Webserver wird die Software von der
Apache Foundation
6
eingesetzt. Der Apache
Webserver ist für seine Stabilität und Flexibilität im Bezug auf das Betriebssystem
und die Erweiterungsmöglichkeiten bekannt. Von allen genutzten Webservern liegt er
mit 60 %
7
deutlich auf Platz 1.
Auf den Serversystemen wird das Betriebssystem "
SuSE
8
Linux 7.0 Professional
"
eingesetzt. Dieses Betriebssystem arbeitet mit dem shadow Passwortsystem. Dabei
werden alle gültigen Benutzer des Servers mit ihrem verschlüsselten Passwort in einer
Datei in Namens "/etc/shadow" speichert. Die Passwörter sind mit dem älteren
crypt(3) Verfahren verschlüsselt, was auf dem DES
9
Standard basiert. Dieses Ver-
schlüsselungsverfahren ist nicht sehr sicher, weil nur die ersten 8 Buchstaben zur Ver-
schlüsselung benutzt werden. Deswegen kann es sein, dass das Verschlüsselungsver-
fahren bei kommenden Versionen von SuSE Linux gegen ein hochwertigeres Verfah-
ren ausgetauscht wird. Jeder Professor hat auf dem Webserver eine Zugangsberechti-
6
Apache: ein sehr verbreiteter Webserver, siehe dazu
http://httpd.apache.org
7
Analyse von
http://www.netcraft.com/survey/
8
SuSE: Software und Systementwicklung GmbH ­ Linux Distributor, siehe dazu:
http://www.suse.de
9
DES: Data Encryption Standard, von IBM entwickelt, normiert unter ANSI X3.92-1981

Kapitel 2 ­ Analyse
6
gung. Deshalb sind zu jedem Professor Zugangsdaten in der Server eigenen Passwort-
datei vorhanden.
Bei SuSE 7.0 wird unter Standardeinstellung das JDK1.1.8 installiert, was nicht
mehr ganz den Stand der Technik entspricht.
2.3 Anforderung an das Informationssystem
Das neue System sollte die in diesem Kapitel dargestellten Anforderungen erfüllen.
Dabei sind diese Forderungen aus der Aufgabenstellung abgeleitet, aber nicht selten
auch aus freien Gedankengängen, die das Konzept noch sicherer und konsequenter
gestalten sollen.
Aus Kapitel 2.1 geht hervor, dass sich das Informationssystem aus der Weban-
wendung und der Datenbank zusammensetzt. Die Webanwendung kann noch in die
eigentlichen Servlets mit ihren Hilfsklassen unterteilt werden. Sie wird wiederum von
dem Applikation-Server
10
umgeben. Die Datenbank wird von einem Datenbank Ma-
nagement System umgeben, was die Datenmanipulation und Datenintegrität der Da-
tenbank unterstützt.
Der Applikation-Server ermöglicht es, dass die Servlets in einem Behälter (Con-
tainer) ausgeführt werden. Damit der Applikation-Server mit dem Webserver kommu-
nizieren kann, muss er eine Schnittstelle zum Webserver beinhalten. Durch Verfeine-
rung der Abb. 2-1 wird diese Gegebenheit dargestellt:
Webserver
des
Fachbereiches
Datenbank
Applikation-Server
Webanwendung
(Servlets und
Hilfsklassen)
Informationssystem
DBMS
Abb. 2-3: Verfeinerung der Webservererweiterung
Es ergeben sich daraus die Komponenten, die für die Erweiterung des Systems benö-
tigt werden:
10
Applikation-Server:
http://webopedia.internet.com/TERM/a/application_server.html

Kapitel 2 ­ Analyse
7
· Applikation-Server
· Webanwendung
· Datenbankschnittstelle
· Datenbank Managment System (DBMS)
· Datenbank
2.3.1 Allgemeine Anforderungen
Hier werden zuerst die allgemeinen Kriterien an die Systemerweiterung angeführt, die
für alle Komponenten gelten sollen. Da sich die Eigenschaften des gesamten Informa-
tionssystem aus den Eigenschaften der einzelnen Komponenten zusammensetzt, ist es
wichtig, dass alle Systemkomponenten mindestens die hier aufgestellten Anforderun-
gen erfüllen.
2.3.1.1 Sicherheit
Die ausgewählten Softwarekomponenten sollten aus bewährten und bekannten Pro-
dukten bestehen, damit, falls sich Sicherheitslücken auftun, diese in kürzester Zeit
geschlossen werden. Dabei ist auch von Vorteil, wenn Softwarekomponenten dem
Open Source
11
Modell entstammen, da diese Software von jedem einzusehen ist und
von vielen voneinander unabhängigen Entwicklern mit entwickelt wird. Dadurch wird
die Wahrscheinlichkeit auf Sicherheitslücken und versteckte Hintertüren vermindert.
Die unterschiedlichen Softwarekomponenten kommunizieren oft über netzwerk-
fähige Schnittstellen. Diese Schnittstellen sollen nicht öffentlich zugänglich sein, d.h.
die Firewall sollte die Ports der einzelnen Schnittstellen nach außen hin blockieren,
damit der Zugriff nur über den Webserver möglich ist.
Überdies soll das Serversystem in seiner vorherigen Funktionalität nicht gestört
oder eingeschränkt werden. Da die Servererweiterung auf dem gleichen Rechner in-
stalliert werden soll auf dem auch der Webserver ausgeführt wird, dürfen sich nicht
die Systemausfälle aufgrund neuer Software häufen.
Um das System später erweitern zu können, sollte schon bei der Entwicklung dar-
11
Open Source:
http://www.opensource.org

Kapitel 2 ­ Analyse
8
auf geachtet werden, dass die zum Einsatz kommenden Softwarekomponenten die
aktuellen Spezifikationen erfüllen, um sicherzustellen, dass sie nicht schon bei der
Entwicklung veraltet sind und so vielleicht später nicht mehr kompatibel zu den neue-
ren Entwicklungen sind. Dabei soll aber, um das Ziel einer neuen Spezifikation zu
erfüllen, keine Software im Beta- oder sogar Alphastadium eingesetzt werden.
2.3.1.2 Flexibilität
Da die eigentliche Webanwendung auf der Programmiersprache Java basiert und diese
sich auf einem plattformunabhängigen Modell aufbaut, wäre es konsequent, wenn bei
den übrigen Softwarekomponenten auch auf die Plattformunabhängigkeit geachtet
wird. Da diese Eigenschaft bei Programmen, die in anderen Programmiersprachen
entwickelt wurden meist nicht erreichbar ist, weil diese in native Kode kompiliert
werden, sollte mindestens auf die Verfügbarkeit verschiedener Versionen für ver-
schiedene Betriebssysteme geachtet werden.
Es sollte bei einzelnen Softwarekomponenten weiter darauf geachtet werden, dass
sie nicht auf einen Rechner beschränkt sind, sondern auf verschiedene Rechner verteilt
werden können. Dabei müssen sie die Möglichkeit haben, über das Netzwerk mitein-
ander zu kommunizieren. Dadurch kann das System je nach Auslastung verteilt wer-
den und ist so auch für hoch frequentierte Anfragen geeignet.
2.3.1.3 Antwortzeit
Als Antwortzeit (engl. Response Time) ist die Zeitspanne definiert, die zwischen der
gesendeten HTTP-Anfrage des Klienten und dem Empfang zugehörigen und vollstän-
digen HTTP-Antwort liegt.
Da es sich um eine Webanwendung handelt, spielt die Antwortzeit eine große
Rolle. Ein Internetanwender ist meist nicht gewillt, lange auf seine Anfrage zu warten.
Dabei liegt die gerade noch dem Anwender zumutbare Antwortzeit bei ca. 10 Sekun-
den
12
. Es muss ein Kompromiss zwischen Ressourcenverbrauch und Geschwindigkeit
eingegangen werden, da diese Parameter bis zu einem gewissen Maximum proportio-
nal zueinander sind.
12
Nilson. J., 1997; The Need for Speed;
http://www.useit.com/alertbox/9703a.html

Kapitel 2 ­ Analyse
9
Die Antwortzeit von statischen Webseiten soll nicht negativ beeinflusst werden,
d.h. die Entscheidung, ob eine statische oder dynamische Webseite gesendet werden
soll, muss sehr einfach und effektiv gestaltet sein.
2.3.1.4 Kosten
Es ist immer gut, wenig Geld auszugeben, was bei der Auswahl der Softwarekompo-
nenten dazu führt, dass selbstverständlich auf den Preis geachtet werden muss. Es soll
bei gleicher Funktionalität die günstigere Software gewählt werden. Man muss aber
nicht um jeden Preis das Günstigste wählen und dabei auf wichtige Funktionen ver-
zichten. Demzufolge ist die Software mit dem besten Preis-/Leistungsverhältnis die
beste Wahl.
Da die Servererweiterung auf einem Linuxsystem basieren soll, gibt es reichlich
Software, die auf dem Open Source Modell basiert und dadurch kostenfrei vertrieben
wird. Dabei kann es aber sein, dass die gleiche Software für andere Betriebssysteme
finanziell erworben werden muss.
2.3.2 Zusätzliche Anforderung an die Datenbank
Da die Webanwendung mit der Datenbank kommunizieren soll, muss eine Datenbank
gewählt werden, für die ein
JDBC
13
Treiber verfügbar ist. Da für den Aufbau einer
durch die Servlets generierten Webseite die Datenbankgeschwindigkeit erheblichen
Einfluss hat, sollte die Datenbank sehr schnell auf SQL Anweisungen reagieren. Dies
muss bei der Wahl des entsprechenden Datenbanktreibers berücksichtigt werden, weil
es meist für einzelne Datenbanken verschiedene Implementierungen von Datenbank-
treibern gibt, die allein wegen ihrer Kommunikationsstruktur unterschiedliche zeitli-
che Minimalgrenzen haben. Dieses Thema wird weiter in dem Kapitel 3.1.3 behan-
delt.
2.3.3 Zusätzliche Anforderung an den Applikation-Server
Der benötige Applikation-Server soll das eigentliche Ausführen der Java Servlets er-
13
JDBC: Datenbank API für Java,
http://java.sun.com/products/jdbc/
(ist kein Akronym)

Kapitel 2 ­ Analyse
10
möglichen, er wird in diesem speziellen Fall auch als Servlet Engine bezeichnet.
Dieser sollte nicht als eigenständiger Webserver ausgeführt werden, sondern über
eine Schnittstelle mit dem Apache Server kommunizieren können und als eigenständi-
ger Prozess laufen. Damit bleibt die vorhandene Webserverstruktur erhalten und wird
nur entsprechend erweitert. Da die Servlets in dem eigentlichen Applikation-Server
ausgeführt werden, muss darauf geachtet werden, dass die benötigte JRE
14
installiert
ist.
Das folgende Bild soll verdeutlichen, dass die Klientenanfragen wie gehabt an
den Webserver geschickt werden. Wenn die Anfragen auf ein Servlet verweisen, sol-
len sie an den Applikation-Server weitergereicht werden.
vorhandener
Webserver
Informationssystem /
Applikation Server
Klient
HTTP-Anfrage
auf statische Seite
HTTP-Anfrage
an Servlet
Abb. 2-4: Einbindung des Informationssystems in den vorhandenen Webserver
2.3.4 Zusätzliche Anforderung an die Webanwendung
Bei der Webanwendung sollte besonders auf die Sicherheit geachtet werden, da ein
falsches oder zu schwaches Sicherheitskonzept der Servlets die Webanwendung un-
brauchbar macht. Die Servlets sollten bei einer Anfrage eines Klienten erst prüfen, ob
der Klient berechtigt ist, sie aufzurufen. Ist das nicht der Fall, sollte der anfragende
Klient zu einem Servlet umgeleitet werden, für das er die nötigen Rechte hat. Dabei
sollten die Servlets unterscheiden können zwischen anonymen, autorisiertem und ad-
ministrativem Benutzer. Folgende Rechte sollen die unterschiedlichen Benutzer ha-
ben:
· Anonymer Benutzer:
Ein anonymer Benutzer darf sich nur über Einträge informieren.
14
JRE: Java Runtime Enviroment, beinhaltet die Java Virtual Machine (JVM) und die Java Klassenbib-
liothek

Kapitel 2 ­ Analyse
11
· Autorisierter Benutzer:
Ein autorisierter Benutzer soll sich über Einträge informieren, seine Fächer
verwalten und neue Fächer hinzufügen dürfen. Er soll weiter die Möglichkeit
haben, Informationen über seine Fächer veröffentlichen, löschen oder ändern
zu können.
· Administrativer Benutzer (Administrator):
Der Administrator soll alle Rechte aller autorisierten Benutzer besitzen. Zu-
sätzlich soll er die Logdatei ansehen und löschen können. Er muss weiter Be-
nutzer und die Einstellung des Autolöschintervalls verwalten können.
Der Webanwendung muss, um die Authentifizierung zu ermöglichen, die Fähigkeit
gegeben werden, die Passwörter, die mit dem crypt(3) Verfahren erstellt wurden,
nachzubilden. Dafür ist keine Standardklasse in Java vorhanden. Es muss also folglich
noch eine Softwarekomponente ausgesucht werden, die dieses Verschlüsselungsver-
fahren nachbilden kann.
Weiter sollten bei einer Interaktion mit einem Benutzer die eingegebenen Daten
immer zur Sicherheit gefiltert werden, damit sie keine Probleme beim Einfügen in die
Datenbank oder bei der Darstellung auf der Webseite erzeugen. Das Verfahren des
Einbindens von HTML Befehlen in einem Formularfeld ist als so genannter
Cross Site
Skriptangriff
15
bekannt und deswegen keine untypische Attacke eines Angreifers.
Da die Webanwendung die eigentliche Benutzerschnittstelle zur Datenbank ist
und somit ein breites Spektrum von Anwendern hat, sollte die Anwendung sehr be-
nutzerfreundlich gestaltet werden. Zu der Benutzerfreundlichkeit gehören folgende
Kriterien:
· gleiches Darstellungsdesign für verschiedene Servlets
· übersichtliche Gestaltung der Darstellung
· Such-, Sortier- und Filterfunktionen für die Haupttabellen
· gute Lesbarkeit
· Unterteilung in Menüs, um die Darstellung nicht zu überladen
· Onlinehilfe
· selbsterklärende Funktionen und Bedienelemente
15
Cross Site Skriptangriff:
http://www.cert.org/advisories/CA-2000-02.html

Kapitel 2 ­ Analyse
12
· Sitzungsverfolgung (Session tracking), um Benutzerautorisierungen Servletü-
bergreifend zu speichern.
· lokales Speichern des Benutzernamens
· Information bei Fehleingabe oder bei einem allgemeinen Fehler
· Information, wenn Datenbank nicht erreichbar
· kleine Statistik im Hauptmenü über Einträge, Fächer und Vorlagen
Die Servlets müssen ihre Antworten für die anfragenden Klienten generieren. Da bei
der Entwicklung der Servlets nicht feststeht, welche Browser später genutzt werden,
sollte es gesichert sein, dass die Darstellung bei allen Browsern nahezu gleich ist. Es
sollte auf keinen Fall passieren, dass die generierten Webseiten nicht mehr lesbar sind.
Im übrigen sollte die Sitzungsverfolgung nicht nur mit Cookies funktionieren, da
diese von äußerster Wichtigkeit ist und bei jeder Klienteneinstellung funktionieren
sollte.
Im Gegensatz dazu könnte der Benutzername mit Cookies auf Wunsch des Be-
nutzers beim Klienten lokal gespeichert werden, damit bei der nächsten Anmeldung
nur noch das Passwort angeben werden muss.
Um später die Webanwendung leicht erweitern zu können, wäre es hilfreich,
wenn jeder Menüpunkt durch ein Servlet repräsentiert wird. Wird ein Servlet hinzuge-
fügt oder ausgetauscht, sind nur die Verweise in den vorhandenen Servlets anzupas-
sen.

Kapitel 3 ­ Lösungskonzepte
13
3. Lösungskonzepte
In diesem Kapitel sollen Konzepte entwickelt werden, die es ermöglichen, die aus Ka-
pitel 2 geforderten Anforderungen umzusetzen. Da die eigentlichen Softwarekompo-
nenten in ihrem Konzept feststehen und nur jeweils die Konfiguration geändert wer-
den kann, muss bei der Auswahl der Softwarekomponenten darauf geachtet werden,
dass diejenige Komponente gewählt wird, die am besten den geforderten Anforderun-
gen entspricht. Dabei gelten die hier vorgestellten Konzepte vornehmlich für die zu
entwickelnde Webanwendung. Das Kriterium Kosten ist wiederum nur für die Aus-
wahl von Softwarekomponenten relevant, da die eigentliche Webanwendung und die
Datenbank selbst zu entwickeln sind.
Da es sich um eine Webanwendung handelt, ist die Sicherheit sehr wichtig. Aus
diesem Grund sollen Konzepte erstellt werden, die eine Identifikation eines Benutzers
fordern, wenn er Informationen im System ändern möchte. Damit jede Änderung
nachvollziehbar bleibt, soll es einen Administrator geben, der sich alle Informations-
änderungen anschauen und alle anderen Benutzer verwalten kann.
Um die Webanwendung flexible aber einheitlich zu gestalten sollen ein oder meh-
rere Konzepte erstellt werden, die das einheitliche Design ermöglichen und auch eine
flexible Konfiguration, um das Informationssystem auch auf andere Bereiche übertra-
gen zu können.
Ein weiteres Kriterium ist die Ausführungsgeschwindigkeit und die davon abhän-
genden Wartezeiten des Benutzers. Da der Kommunikationsweg über mehrere Soft-
warekomponenten geht, sollen die einzelnen Komponenten wie auch ihre Kommuni-
kation zwischen ihnen optimiert werden.
3.1 Auswahl der Softwarekomponenten
Es werden im Folgenden, um eine Auswahl zu treffen, mehrere Möglichkeiten vorge-
stellt, aus denen dann mit Hilfe der in Kapitel 2.3 definierten Kriterien die beste Soft-
warekomponente ausgewählt wird. Die benötigten Komponenten sind:
· Applikation-Server

Kapitel 3 ­ Lösungskonzepte
14
· Datenbank Management System
· Datenbanktreiber
· Software, um ein crypt(3) Passwort zu bilden.
3.1.1 Applikation-Server ­ Servlet Engine
Eine komplette Liste von Servern, die die Servlettechnik unterstützen, kann bei
Sun
16
heruntergeladen werden. Dabei gibt es zwei Arten von Servern. Die eine Art der Ser-
ver erweitert den bestehenden Webserver und die andere Art fungiert als eigenständi-
ger Webserver.
Die zur Auswahl stehenden Applikation-Server wurden auf diejenigen beschränkt, die
als Erweiterung an den vorhandenen Webserver anknüpfen.
Die zur Auswahl stehenden Applikation-Server sind:
·
Allaire JRun 3.0
·
Jakrata Tomcat 3.2
·
Apache Web Server Jserv
·
Caucho Technology Resin 1.2
·
Gefion Software WAICoolRunner
·
New Atlanta ServletExec 3.1
Um aus den angegebenen Applikation-Servern eine Auswahl treffen zu können, wer-
den die in Kapitel 2 gewählten Kriterien angewendet.
Es wird eine Tabelle mit den oben angegebenen Servern erstellt, in der die Infor-
mationen über Preis und unterstützte Servlet-Spezifikation enthalten sind.
16
Unterstützung für Servlets:
http://java.sun.com/products/servlet/industry.html

Kapitel 3 ­ Lösungskonzepte
15
Produkt
Unterstütze Servlet-
Spezifikation
Preis
Allaire JRun 3.0
2.2
Ab 700 DM
Jakarta Tomcat 3.2
2.2
-
Apache Web Server Jserv
2.0
-
Caucho Technology Resin 1.2
2.2
Ab 1100 DM
Gefion Software WAICoolRunner
2.2
Ab 330 DM
New Atlanta ServletExec 3.1
2.2
Ab 1550 DM
Tabelle 1: Applikation-Server
Da in der
Servlet-Spezifikation 2.1
17
die Sitzungsverfolgung verbessert und in diesem
Rahmen nützliche Methoden ausgetauscht wurden, ist es zweckmäßig, einen Server zu
wählen, der mindestens die Spezifikation 2.1 erfüllt. Durch diese Bedingung disquali-
fiziert sich der Apache Web Server Jserv, der auch nicht weiter entwickelt wird.
Als kostenloser Applikation-Server steht nur noch der Jakarta Tomcat 3.2 zur
Auswahl. Der Preis soll dabei nicht das Hauptkriterium sein, sondern den Jakarta
Tomcat 3.2 nur als nächsten Kandidat qualifizieren.
Tomcat 3.2 ist die Referenzimplementierung der Java
Servlet 2.2
und Java Server
Pages 1.1 Technik. Dazu ist Tomcat 3.2 selbst in Java programmiert und von
JavaWorld
als ,,Most Innovative Java Product 2001" vorgeschlagen
18
. Tomcat 3.2 un-
terstützt mehrere Webserver, darunter:
· Apache ab Version 1.3
· Microsoft Internet Information Server, ab Version 4.0
· Microsoft Personal Web Server, ab Version 4.0
· Netscape Enterprise Server, ab Version 3.0
Es ist sogar möglich, Tomcat auf ein anderes Rechnersystem zu installieren, um z.B.
eine Lastverteilung zu realisieren. Dabei kommuniziert Tomcat mit dem Webserver
17
Neuerung in der Servlet API Spezifikation 2.1
http://java.sun.com/products/servlet/2.1/changes.html
18
Most Innovative Java Product 2001:
http://www.javaworld.com/jw-05-2001/jw-0504-finalists.html

Kapitel 3 ­ Lösungskonzepte
16
über eine TCP
19
Verbindung. Die genannten Kriterien qualifizieren Tomcat 3.2 als
hinreichenden Applikation-Server. Um Tomcat auszuführen, ist auf dem System JRE
1.1 oder höher erforderlich.
Es gibt zwei Protokollversionen, die ermöglichen, dass Tomcat mit dem Webser-
ver kommuniziert
20
. Das ältere AJP12 und das neuere AJP13 Protokoll. Dabei ermög-
licht nur das AJP13 Protokoll eine sichere Erkennung von verschlüsselten Anfragen
und ist demzufolge für die Webanwendung notwendig. AJP13 wird bei der Installati-
on von Tomcat nicht als Standardprotokoll genutzt und muss extra konfiguriert wer-
den. (Kapitel 7.3)
Ergänzend sei noch erwähnt, dass es von Tomcat zusätzlich die Versionen 3.3
und 4.0 gibt, diese sind aber beide noch im Entwicklungsstadium und stützen sich auf
die
Servlet API Spezifiktion 2.3
, die ebenfalls noch nicht offizielle Gültigkeit hat.
Die weiter in Tabelle 1 aufgeführten Applikation-Server sollen nicht untersucht
werden, da sie alle für den kommerziellen Einsatz kostenpflichtig sind. Eine weitere
Begründung des Abbruches der Applikation-Server Analyse ist, dass Tomcat 3.2 sich
als Referenzimplementierung und flexible Webservererweiterung qualifiziert hat. Es
soll folglich Tomcat 3.2 für das zu entwickelnde Informationssystem eingesetzt wer-
den.
3.1.2 Datenbank Management System
Es gibt unter SuSE Linux zwei standard DBMS die beide dem Open Source Modell
entsprechen. Das ist einmal das relationale
MySQL
21
DBMS und das objektrelationale
PostgreSQL
22
DBMS.
Dabei sprechen für MySQL die sehr weite Verbreitung und der dementsprechend
gute Support. MySQL ist für über 10 Betriebssysteme vorhanden und ist somit auf
vielen Plattformen einsetzbar. Weiter gilt es als sehr robust und stabil im Betrieb. Im
Punkt Geschwindigkeit liegt das MySQL DBMS gegenüber vielen anderen DBMS,
19
TCP: Transmission Control Protocol:
RFC793
20
Protokollwahl:
http://jakarta.apache.org/tomcat/tomcat-3.2-doc/mod_jk-howto.html - s3
21
MySQL:
http://www.mysql.com
22
PostgreSQL:
http://www.postgresql.org/

Kapitel 3 ­ Lösungskonzepte
17
darunter auch PostgreSQL, oft an der Spitze
23,24
. Dabei kann man nicht ein DBMS
angeben, was generell das schnellste System ist. Es ist vielmehr abhängig von der zu
verwaltenden Datenbank und die verwendeten Datenbankoperationen. MySQL ist da-
bei auf den Einsatz einfachen Datenbank und einfachen Datenbankoperationen opti-
miert, was auf die hier zu verwendende Datenbank zutrifft.
Für die Geschwindigkeitsoptimierung des MySQL DBMS sind einige Konzepte
weggefallen, so ist z.B. das in
SQL 89 Level 2
25
definierte Fremdschlüsselkonzept in
MySQL nicht realisiert. Das Transaktionskonzept ist geplant und wird bis jetzt nur
von instabilen Beta Versionen unterstützt. Als vorübergehende Lösung stellt MySQL
ein "lock" Statement bereit, womit Relationen für schreibend und lesend oder nur
schreibenden Zugriff gesperrt werden können. Um Deadlocks zu vermeiden müssen
alle benötigten Ressourcen auf einmal gesperrt werden.
Für die PostgreSQL Datenbank sprechen die fast vollständig Implementierung
des SQL92 Standards, dazu gehören z.B. vollständige Transaktionssicherung oder
Subselects, was beides von MySQL nicht unterstützt wird. PostreSQL ist aber leider
nur für Linux verfügbar und bietet eine schlechtere Anwenderunterstützung, wie sie
z.B. bei MySQL durch Foren und Mailinglisten gegeben ist, an. Dies hängt mit der
weiten Verbreitung von MySQL zusammen.
Da die zu entwickelnde Datenbank aus keiner komplexen Struktur besteht, wer-
den größtenteils nur einfache Einfüge- und Abfrageaktionen genutzt. Daraus folgt,
dass die fehlende SQL92 Kompatibilität von MySQL nicht so stark in die Gewichtung
eingeht. Für beide Datenbanken gibt es einen JDBC API 2.x Treiber des Types 4, was
in Kapitel 3.1.3 weiter analysiert wird.
Es wurde für das Informationssystem das MySQL Datenbank Management Sys-
tem gewählt, da die Plattformunabhängigkeit sowie die Performance und der gute
Support für dieses System sprechen. Die aktuelle Version von MySQL ist 3.23.
23
Vergleichergebnisse von Datenbanken:
http://www.mysql.com/information/crash-me.php
24
Vergleich von PostgreSQL und MySQL:
http://www.phpbuilder.com/columns/tim20000705.php3
25
SQL89 Definition:
http://www.cs.nccu.edu.tw/~lien/DBslide/SQL89/

Kapitel 3 ­ Lösungskonzepte
18
3.1.3 Datenbanktreiber
Es soll die JDBC Schnittstelle von Java zum Verbindungsaufbau zur Datenbank ge-
nutzt werden. Um dies zu ermöglichen, wird ein JDBC Treiber benötigt, der in Java
als externe Klasse einzubinden ist. Diese Klasse wird dann über den JDBC Treiber
Manager von Java verwaltet.
Es gibt vier Arten von Datenbanktreiber, die unterschiedlichen Architekturen
werden jetzt erläutert und bildlich veranschaulicht.
· Typ 1:
Es handelt sich hierbei um die so genannte "JDBC - ODBC
26
- Brigde". Dabei
wird der JDBC Kode in ODBC Kode umgewandelt. Um den ODBC Kode
ausführen zu können, muss noch zusätzlich ein ODBC Treiber installiert sein,
der meist in nativen Kode implementiert ist. D.h. es wird eine zweifache Um-
setzung der Datenbankbefehle ausgeführt und es werden zwei Treiber benö-
tigt. Oft wird der ODBC Kode noch einmal in den speziellen Datenbank
Klienten Kode umgesetzt.
· Typ 2:
Der Treiber basiert auf dem Schema von Typ 1. Hier wird der ODBC Treiber
durch einen herstellerabhängigen Treiber ersetzt. Dieser kann teilweise in Ja-
va realisiert sein.
· Typ 3:
Purer und universeller Java Datenbanktreiber, der über einen Middleware
27
Server mit einer Datenbank kommuniziert. Der Middleware Server unterstützt
dabei eine Vielzahl von unterschiedlichen Datenbanken.
· Typ 4:
Ein in reinem Java realisierter direkter Datenbanktreiber. Dabei konvertiert
der Treiber die JDBC Befehle in direkte Datenbankbefehle für das Datenbank
Managment System. Aus dieser Struktur ergibt sich, dass dieser Treiber am
effizientesten mit einer Datenbank kommuniziert.
26
Open Database Connectivity:
http://iroi.seu.edu.cn/books/whatis/odbc.htm
27
Middleware:
http://iroi.seu.edu.cn/books/whatis/middlewa.htm

Kapitel 3 ­ Lösungskonzepte
19
Typ 1
Typ 2
Typ 3
Typ 4
Abb. 3-1: Die vier verschiedenen Datenbanktreibertypen
(grau : in Java zu realisieren)
Es gibt zwei JDBC-API Versionen. Die neuere API Version
28
(2.0) bietet unter ande-
rem mehr Flexibilität in Bezug auf das Objekt, was die gelieferte Tupel einer Daten-
bankabfrage zur Verfügung stellt. Die Neuerungen sind zwar nicht zwingend erforder-
lich, es sollte aber im Zuge der Aktualität die JDBC-API Version 2.0 gewählt werden.
Da bei einem Webseitenaufbau durchaus mehrere Datenbankabfragen durchge-
führt werden und jeweils einer der in Abb. 3-1 angegebenen Kommunikationspfade
bidirektional durchlaufen werden muss, soll ein Datenbanktreiber des Typs 4 gewählt
werden. Dadurch ist gewährleistet, dass die Kommunikation mit der Datenbank so
direkt wie nur möglich ist, was implizit einen Zeitvorteil gegenüber den anderen Trei-
bertypen bedeutet. Ein schöner Seiteneffekt ist die Plattformunabhängigkeit des Trei-
bers.
Im Zuge der geforderten Anforderungen qualifiziert sich nur der
MM.MySQL
29
Treiber. Dieser fällt unter die
LGP Lizenz
30
und ist somit frei einsetzbar. Um diesen
Treiber nutzen zu können, muss mindestens JDK 1.2 installiert sein.
28
Änderungen in JDBC API 2.0
http://java.sun.com/products/jdbc/features.html
29
MM.MySQL Datenbanktreiber Typ 4,
http://mmmysql.sourceforge.net/
30
Lesser General Public License: Bedingungen unter
http://www.gnu.org/copyleft/lesser.html

Kapitel 3 ­ Lösungskonzepte
20
3.1.4 Zusätzliche Softwarekomponenten
Es soll möglich sein, Linux Passwörter, die mit dem Crypt(3) Verfahren verschlüsselt
wurden, nachzubilden. Dazu gibt es drei Ansätze:
1) Das Passwort mit dem MySQL Befehl ENCRYPT(str[,salt]) zu generieren.
2) Erstellen eines Passwortes mit einem Systemaufruf System.execute(...).
3) Das Einbinden einer Javaklasse, die diese Funktionalität zur Verfügung stellt.
Die ersten beiden Ansätze sind wegen der geforderten Plattformunabhängigkeit keine
gute Lösung, da sie beide systemabhängige Funktionen ausführen. Es bietet sich an,
eine vollständige Java Lösung zu implementieren. Die Firma "
The Cryptix Foundation
Limited
"
31
bietet eine Werkzeugsammlung mit gängigen Sicherheits- und Verschlüs-
selungsalgorithmen basierend auf Sun's Java Cryptography Extensions (JCE) 1.1 an.
Das Programm heißt Cryptix V3.2 und ist kompatibel zum JDK1.3. In der Werkzeug-
sammlung ist eine Klasse Namens UnixCrypt vorhanden, die es ermöglicht, das
Crypt(3) Verfahren auf einen bestimmten String mit einem bestimmten Salt String
durchzuführen.
Da JDK1.3.0_02 auch für Linux angeboten wird und in der Webanwendung Me-
thoden verwendet werden sollen, die erst ab Java 1.2 vorhanden sind (z.B. creatNew-
File()
von Klasse File), sollte dies ebenfalls installiert werden.
3.1.5 Zusammenfassung
Um das gewünschte Informationssystem zu realisieren, werden zusätzlich zu dem be-
stehenden System folgende Softwarekomponenten benötigt:
· Applikation-Server: Tomcat 3.2.1
· Datenbank Management System: MySQL 3.23
· Datenbanktreiber: MM.MySQL, Typ 4 Treiber
· Verschlüsselungskomponente: Cryptix 3
· Java: JDK 1.3.0_02
Alle Komponenten entstammen dem Open Source Modell und sind dadurch auch
beim kommerziell Einsatz kostenfrei. Des weiteren sind alle Komponenten, bis auf
31
Werkzeugsammlung für Verschlüsselungsalgorithmen:
http://www.cryptix.org/

Kapitel 3 ­ Lösungskonzepte
21
MySQL, in Java realisiert. Dies garantiert maximale Plattformunabhängigkeit und
Flexibilität des kompletten Systems, da auch das MySQL DBMS für die gängisten
Betriebssysteme vorhanden ist.
3.2 Sicherheit
Da das Informationssystem auch aus dem Internet erreichbar sein soll, muss es, wie
eigentlich jede öffentlich zugängliche Anwendung, besondere Sicherheitsvorkehrun-
gen beinhalten. Dabei ist darauf zu achten, dass sich zwar jeder mit diesem System
über Neuigkeiten informieren kann, aber für jede Änderung oder Aktualisierung der
Benutzer authentifiziert sein muss, damit die Änderung nachvollziehbar und zuorden-
bar ist. Wäre das nicht gegeben, würden die Informationen an Glaubwürdigkeit und
somit ihren Informationsgehalt verlieren, da jeder alles veröffentlichen könnte.
3.2.1 Verschlüsselung
Die Benutzer müssen sich gegenüber der Webanwendung authentifizieren, es muss
dabei gewährleistet sein, dass bei der Autorisierung kein dritter an die Autorisierungs-
daten kommen kann. Da es sich um eine Webanwendung handelt, die über das Inter-
net aufgerufen werden kann, gibt es eine Vielzahl von Möglichkeiten die Authentifi-
zierungsdaten mitzuschneiden. Da die Daten über verschiedene Server (Router, Pro-
xy) gesendet werden, kann ein Angreifer, wenn er Zugriff zu solchen Knotenpunkten
erlangt hat, den ganzen Netzverkehr, der über diesen Knoten läuft, mitschneiden. Es
könnte auch der Internetverkehr zu einem Server des Angreifers umgelenkt werden,
was bei geschicktem Nachbau der Webseite für den Benutzer kaum erkennbar ist. Der
Benutzer schickt dann seine Authentifizierungsdaten an den Angreifer, der die Daten
dann wiederum für das eigentliche Informationssystem benutzen kann. Die folgende
Abbildung zeigt die als Beispiel genannten Möglichkeiten.

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2001
ISBN (eBook)
9783832452438
ISBN (Paperback)
9783838652436
DOI
10.3239/9783832452438
Dateigröße
1.9 MB
Sprache
Deutsch
Institution / Hochschule
Fachhochschule Aachen – Elektrotechnik und Informationstechnik
Erscheinungsdatum
2002 (März)
Note
1,0
Schlagworte
jarkata tomcat apache verschlüsselung informationssystem
Zurück

Titel: Nutzung einer Datenbank mit Java-Servlets
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
book preview page numper 20
book preview page numper 21
book preview page numper 22
book preview page numper 23
book preview page numper 24
book preview page numper 25
book preview page numper 26
124 Seiten
Cookie-Einstellungen