Motivation und Zielsetzung der Diplomarbeit

Fachbereich Informatik
Internetanwendungen
auf
Javabasis
Diplomarbeit von
Andreas Billmann
Mannheim, Januar 2001
Betreuer der Diplomarbeit:
Prof. Dr. R. Gerten
Abstract
Die Diplomarbeit beschreibt den Aufbau verschiedener Internetanwendungen. Im
Speziellen werden hierbei die Internetportale betrachtet. Nach einer kurzen
Analyse zweier vorhandener Internetportale wird ein Rahmen für die Umsetzung
eines Portals für den Fachbereich Informatik der FH Mannheim entworfen. Der
Schwerpunkt liegt hierbei auf den Teilbereichen Inhalt, Struktur und Design.
Nach der Auswertung der Vor- und Nachteile verschiedener Architekturen wird
die 3-Tier-Architektur zur Umsetzung ausgewählt. Anschließend erfolgt eine
Betrachtung verschiedener Softwaretechniken für Internetanwendungen. Nach
einem Vergleich der Softwaretechniken bezüglich ihrer Verwendung für das
Internetportal werden die JavaServlets als zu verwendende Technik bestimmt. Im
weiteren Verlauf bilden die Entscheidungen, die aus der Auswertung der Architekturen und der Betrachtung der Softwaretechniken begründet sind, die Basis für
den Lösungsvorschlag für die Erstellung des Internetportals.
Da die JavaServlets in Java programmiert sind, wird im Folgenden die
Programmiersprache Java vorgestellt. Der Hauptaugenmerk liegt hierbei auf der
Unterstützung moderner (objektorientierter) Softwaretechniken durch Java.
Der Lösungsvorschlag für die Erstellung des Internetportals umfaßt die Anwendungsschichten Datenbanksystem, Geschäftslogik und Präsentation. Jede Anwendungsschicht wird im Hinblick auf ihre Teilbereiche erläutert. Zusätzlich zur
Erläuterung wird die Implementierung jeder Anwendungsschicht am Beispiel des
Internetportals des Fachbereichs Informatik aufgezeigt.
-2-
Kapitelverzeichnis
1.
Motivation und Zielsetzung der Diplomarbeit ...............7
2.
Portal des Fachbereichs ..............................................10
3.
Internetanwendungen ..................................................18
4.
Java...............................................................................27
5.
Anwendungsschichten .................................................36
6.
Implementierungshinweise..........................................50
7.
Schlußbetrachtung .......................................................52
-3-
Inhaltsverzeichnis
1.
1.1.
1.2.
1.3.
2.
2.1.
2.1.1.
2.1.2.
2.2.
2.2.1.
2.2.2.
2.2.3.
2.2.4.
3.
3.1.
3.1.1.
3.1.2.
3.1.3.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.3.
4.
4.1.
4.1.1.
4.1.2.
4.2.
4.2.1.
4.2.2.
4.2.3.
4.2.4.
Motivation und Zielsetzung der Diplomarbeit ...............7
Einführende Betrachtung des Themas.................................... 7
Ziel und Aufbau der Diplomarbeit............................................ 7
Grundlegende Begriffe ............................................................. 8
Portal des Fachbereichs ..............................................10
Betrachtung bestehender Portale.......................................... 10
Inhaltsanalyse ........................................................................... 10
Designanalyse........................................................................... 10
Entwurf des Portals................................................................. 11
Inhalte ....................................................................................... 11
Interaktive Elemente.................................................................. 12
Struktur...................................................................................... 14
Design ....................................................................................... 16
Internetanwendungen ..................................................18
N-Tier-Architekturen ............................................................... 18
2-Tier-Architektur....................................................................... 18
3-Tier-Architektur....................................................................... 19
4-Tier-Architektur....................................................................... 19
Serverseitige Programmiertechniken.................................... 20
Common Gateway Interface (CGI)............................................ 21
Webserver-APIs ........................................................................ 22
Servlets ..................................................................................... 23
Java Server Pages (JSP) .......................................................... 24
Vergleich der Techniken............................................................ 25
Begründung der Auswahl der Techniken zur
Portalimplementierung ........................................................... 26
Java...............................................................................27
Allgemeine Grundlagen von Java.......................................... 27
Grundlegende Anforderungen bei der Entwicklung von Java.... 27
Java Architektur ........................................................................ 29
Objektorientierte Konzepte von Java .................................... 30
Abstraktion ................................................................................ 31
Kapselung ................................................................................. 31
Wiederverwendung ................................................................... 31
Beziehungen ............................................................................. 32
-4-
4.2.5.
4.2.6.
4.2.7.
4.2.8.
4.2.9.
4.2.10.
5.
5.1.
5.1.1.
5.1.2.
5.1.3.
5.1.4.
5.1.5.
5.2.
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.3.
5.3.1.
5.3.2.
5.3.3.
6.
6.1.
6.1.1.
6.1.2.
6.1.3.
6.2.
6.2.1.
6.2.2.
7.
7.1.
7.2.
Vererbung ................................................................................. 32
Polymorphismus........................................................................ 33
Statische Elemente ................................................................... 33
Schnittstelle............................................................................... 34
Abstrakte Klassen ..................................................................... 34
Entwurfsmuster ......................................................................... 35
Anwendungsschichten .................................................36
Datenbanksystem.................................................................... 36
Leistungsmerkmale von relationalen
Datenbankmanagementsystemen ........................................ 36
Structured Query Language (SQL) ........................................... 37
Java Database Connectivity (JDBC) ......................................... 37
Zugriffsschicht ........................................................................... 38
Implementierung ....................................................................... 39
Geschäftslogik ........................................................................ 42
Geschäftsprozeß....................................................................... 42
Geschäftsobjekte ...................................................................... 42
JavaBeans ................................................................................ 43
Implementierung ....................................................................... 43
Präsentation ............................................................................ 45
Hypertext Markup Language (Html) .......................................... 45
Servlets ..................................................................................... 46
Implementierung ....................................................................... 47
Implementierungshinweise..........................................50
Programmierumgebung.......................................................... 50
JDK 1.2.2 .................................................................................. 50
Servlets 2.2 ............................................................................... 50
Dokumentation .......................................................................... 50
Systemumgebung ................................................................... 50
Webserver................................................................................. 50
Servlet Engine........................................................................... 51
Schlußbetrachtung .......................................................52
Resümee .................................................................................. 52
Ausblick auf aktuelle und zukünftige Entwicklungen .......... 53
-5-
Eidesstattliche Erklärung
Hiermit versichere ich an Eides statt, daß ich die vorliegende Arbeit selbständig
angefertigt und keine fremde Hilfe in Anspruch genommen habe. Alle Stellen, die
wörtlich aus veröffentlichten oder nicht veröffentlichten Schriften entnommen
sind, habe ich als solche einzeln kenntlich gemacht.
Ferner erkläre ich, daß die vorliegende Arbeit in keinem anderen Studiengang und
an keiner anderen Stelle als Prüfungsleistung verwendet wurde.
Mannheim, . Januar 2001
Andreas Billmann
-6-
1. Motivation und Zielsetzung der
Diplomarbeit
1.1. Einführende Betrachtung des Themas
Die Entwicklung von „Internetportalen“ nimmt immer mehr zu. Es reicht heutzutage nicht mehr aus, Information in statischer Form im World Wide Web bereitzustellen. Die Webseiten sollten themenorientiert und dynamisch dargestellt werden,
um eine leichtere Wartbarkeit des Systems zu gewährleisten. Zudem sollte eine
Interaktion zwischen dem „Websurfer“ und dem Portal möglich sein. Erst dadurch
kann man Dienste wie Diskussionsforen, Newsletter oder ähnliches anbieten, die
den Mehrwert für den Benutzer steigern.
Im Rahmen dieser Diplomarbeit soll ein Portal für den Fachbereich Informatik
erstellt werden, das zum einen Informationen bereitstellt, zum anderen aber auch
Möglichkeiten zur Kommunikation bietet. Thematisch orientiert sich das Portal
am Fachbereich Informatik der FH Mannheim. Die hier gezeigten Techniken sind
aber nicht nur für Portale gedacht und anwendbar, sondern eignen sich
grundsätzlich für fast alle Internetanwendungen.
1.2. Ziel und Aufbau der Diplomarbeit
Die Diplomarbeit soll der Aufbau von Internetanwendungen im Allgemeinen
aufzeigen und analysieren. Hierbei liegt der Schwerpunkt auf der Betrachtung von
Portalen. Die Basis bilden bereits bestehende Portale, die in Bezug auf
verschiedene Kriterien bewertet werden. Ausgehend von dieser Analyse erfolgt
der Entwurf des Portals für den Fachbereich Informatik der FH Mannheim.
Das Hauptziel dieser Diplomarbeit ist es, die für die Umsetzung einer Internetanwendung allgemein möglichen Techniken in Bezug auf ihre Eignung differenziert
zu betrachten und im Hinblick auf unterschiedliche Anforderungen zu bewerten.
Somit ergibt sich die Möglichkeit, die einzelnen zur Verfügung stehenden
Techniken miteinander zu vergleichen. Hierbei wird besonders Java als
ausgewählte Technik betrachtet. Anschließend wird die Aufteilung einer
Internetanwendung nach softwaretechnischen Gesichtspunkten vorgenommen und
die Art der Implementierung im Portal vorgestellt.
Abschließend werden die Ergebnisse und Schwerpunkte dieser Diplomarbeit in
einem Resümee zusammengefaßt. In diesem Rahmen erfolgt insbesondere ein
-7-
Ausblick auf aktuelle und zukünftige Entwicklungsrichtungen von Internetanwendungen.
1.3. Grundlegende Begriffe
Aufgrund der Begriffsvielfalt in der Informatik sollen hier einige der benutzten
Begriffe vorab kurz vorgestellt und erläutert werden.
Datenbank und Datenbankmanagementsystem
„Unter einer Datenbank versteht man den Speicherort für persistente
Datensätze und unter einem Datenbankmanagementsystem (DBMS) die
Software, die den Zugriff auf die Datenbank vornimmt. Das Datenbankmanagementsystem und die von ihm kontrollierten Datenbank(en) bilden
zusammen das Datenbanksystem.“1
Entwurfsmuster (Design Pattern)
„Eine objektorientierte Technik, die Aspekte einer nützlichen Designstruktur identifiziert, benennt und abstrahiert. Das Design Pattern identifiziert
Klassen und Instanzen, ihre Rollen, ihre Kollaborationen und Verantwortlichkeiten unter Berücksichtigung eines spezifischen objektorientierten Designproblems.“2
Geschäftsprozess
„Ein Geschäftsprozess besteht aus einer Reihe von Aktivitäten und erzeugt
ein Ergebnis, das für den Klienten von Wert ist.“3
Geschäftsobjekt
„Ein Geschäftsobjekt repräsentiert ein Objekt der echten Welt aus dem
geschäftlichen Bereich.“4
Internetanwendung
Eine Internetanwendung ist grundsätzlich jede Anwendung die über das
Internet arbeitet. Im Rahmen der Diplomarbeit werden nur
Internetanwendungen die über das World Wide Web realisiert werden,
betrachtet.
1
[ZB00, S. 127]
[DS00, S. 430]
3
[DS00, S. 432]
4
[DS00, S. 432]
2
-8-
Internet Portal
Unter einem Internet Portal versteht man eine Internetseite, die
Informationen und Dienste zu einem oder mehreren definierten Themen
bieten.
Java Beans
„Als Beans werden in Java eigenständige, wiederverwendbare Softwarekomponenten zum Aufbau von Applets und Applikationen bezeichnet.
Obwohl sie nicht zwangsläufig eine für den Anwender sichtbare Oberfläche haben müssen, werden Beans doch typischerweise als grafische
Komponenten zur Verfügung gestellt und können mit Hilfe eines GUIEditors (GUI= Graphical User Interface) interaktiv zu komplexen Anwendungen zusammengesetzt werden.“5
Komponente
„Eine Komponente ist ein unabhängiges Softwaremodul, das für die
‚plug&play’-Wiederverwendung bestimmt ist. Komponenten enthalten
eine oder mehrere Schnittstellenbeschreibungen (interface). Die meisten
Komponenten können entsprechend den Anforderungen der ContainerAnwendung konfiguriert werden. Beispiele für Komponentenmodelle sind
JavaBeans, Enterprise Java Beans, CORBA und ActiveX/COM/DCOM.“6
Statische und dynamische Webseite
Als statischen Webseite bezeichne ich eine Webseite, die nur aus Dateien
besteht. Die einzige Möglichkeit, die Webseite zu ändern, besteht in der
Änderung einer Datei. Im Gegensatz dazu wird eine dynamische Webseite
mit Hilfe von Programmen zur Laufzeit erzeugt. Das heißt, Html-Seiten
werden erst bei Anfrage generiert. Dies geschieht meist im Zusammenspiel
mit einem Datenbanksystem.
5
6
[K00, S. 1002]
[DS00, S. 436]
-9-
2. Portal des Fachbereichs
2.1. Betrachtung bestehender Portale
Eine kurze Analyse bestehender Portale bilden die Basis des Entwurfs für das
Portal der Fachbereichs Informatik der FHT Mannheim. Im Folgenden werden
exemplarisch die Portale „heise.de“7 und „Geeksworld“8 betrachtet.
2.1.1.
Inhaltsanalyse
Bei „heise.de“ ist das Thema des Portals alles rund um die IT Branche. Als
Dienste bietet „heise.de“ aktuelle Nachrichtenanzeige mit der Möglichkeit, diese
zu kommentieren, verschiedene Diskussionsforen, Tarifrechner und einen Chat.
„Geeksworld“ befasst sich mit dem Thema Webdesign und Webseitenprogrammierung. Als interaktive Elemente bietet „Geeksworld“ Diskussionsforen,
Newsletter, aktuelle Nachrichten und einen Downloadbereich.
Beide Portale zeigen, daß neben der reinen Informationsdarstellung besonders vor
allem die Dienste Diskussionsforum und aktuelle Nachrichten einen hohen
Stellenwert haben. Die aktuellen Nachrichten erscheinen bei beiden Portalen
direkt als Startseite, und die Diskussionsforen zeigen durch ihre hohe Anzahl an
Benutzereinträgen, daß der Dienst genutzt wird.
2.1.2.
Designanalyse
Das Portal „heise.de“ ist in drei Spalten aufgeteilt. In der linken Spalte findet man
das Menü, in der Mitte ist der Hauptteil, in dem sich der Inhalt befindet, und
rechts sind die wichtigsten Links aufgelistet. Diese Form der Darstellung wird im
Moment sehr häufig benutzt, um eine optimale Ausnutzung des Platzes zu
erreichen, da Bildschirme in der Regel mehr Pixel in der Breite als in der Höhe
bieten. Allerdings wird das Menü recht unübersichtlich, wenn man in die tieferen
Ebenen geht, denn zusätzlich zu dem Hauptmenüeintrag wird direkt darunter das
entsprechende Untermenü dargestellt.
7
8
http://www.heise.de
http://www.geeksworld.de/
- 10 -
„Geeksworld“ hat ein Hauptmenü oben quer, in dem sich sieben Einträge
befinden. Zu jedem der sieben Einträge wird auf der linken Seite ein Untermenü
dargestellt. Durch ein „flaches“ Hauptmenü ist eine optimale Platzaufteilung
gewährleistet und die Navigation ist auch in tieferen Ebenen noch übersichtlich.
2.2. Entwurf des Portals
Der Entwurf des Portals läßt sich in mehrere Teile gliedern. Als erstes muß der
Inhalt spezifiziert werden. Dieser Inhalt läßt sich dann in Bereiche aufteilen. Auch
die interaktiven Elemente werden diesen Bereichen untergeordnet. Somit gewinnt
man für die Webseite eine Struktur, die die Aufteilung der Inhalte und
interaktiven Elemente in Bereiche und Teilbereiche weiter fördert und den
Benutzer der Webseite in seiner Navigation unterstützt. Nach der Strukturbildung
muß dann ein geeignetes Design gewählt werden, das die Struktur unterstützt und
die Navigation vereinfacht.
2.2.1.
Inhalte
Die Inhalte des Portals werden in erster Linie aus den zur Verfügung stehenden
Informationen des Fachbereiches gewonnen. Die folgenden Punkte sollen eine
kurze Aufzählung der wichtigsten Inhalte darstellen.
•
Der Fachbereich stellt sich, das Dekanat und das dazugehörige Sekretariat
vor.
•
Eine Professorenliste mit den nötigsten Eckdaten zu den Professoren soll
abrufbar sein.
•
Eine Verlinkung bestehender Professorenseiten soll möglich sein.
•
Eine Auflistung der Institute, die den Fachbereich angegliedert sind, soll
abrufbar sein.
•
Die Daten zur Fachschaftsvertretung sollen angezeigt werden.
•
Der aktuelle Stundenplan soll abrufbar sein.
•
Das Herunterladen von Unterlagen, Vorlesungsskripten oder Tutorien soll
möglich sein.
- 11 -
2.2.2.
Interaktive Elemente
Um dem Portal einen zusätzlichen Mehrwert zu geben, werden verschiedene
Dienste angeboten. Die hier vorgestellten Dienste sollen eine Auswahl der am
weitesten verbreiteten Dienste sein.
•
Diskussionsforum
Angemeldete Benutzer haben die Möglichkeit, sich zu verschiedenen Diskussionsthemen auszutauschen. Der Ablauf innerhalb des Diskussionsforums wird in Abbildung 1 dargestellt.
•
Nachrichtendienst
Aktuelle Nachrichten, die den Fachbereich betreffen, werden auf der
Startseite mit den Überschriften aufgelistet und zum Lesen bereitgestellt.
So kann jeder Benutzer die neusten Nachrichten auf den ersten Blick
erfassen.
•
Linkkatalog
Der Benutzer findet hier ausgewählte Links, die nach Themen sortiert
sind. Er hat auch die Möglichkeit, ihm bekannte Links anzumelden.
- 12 -
Benutzer
meldet sich an
Existiert
Benutzer ?
NEIN
Fehlermeldung
JA
Bestätigung
Liste aller Foren
anzeigen
JA
Eingabe
ok ?
NEIN
Fehlermeldung
Bestätigung
der
Speicherung
Liste aller Fragen
und Anzahl der
Antworten
anzeigen,
Formular zur
Eingabe einer
eigenen Frage
anzeigen
JA
Eingabe
ok ?
NEIN
Fehlermeldung
Antwort
anzeigen,
Formular zur
Beantwortung der
Frage anzeigen
Abbildung 1: Ablauf innerhalb des Diskussionsforums
Die Abbildung zeigt den Ablauf des Dienstes „Diskussionsforum“. Es beschreibt
die Möglichkeiten die ein Benutzer von seinem Anmelden bis zu seinem
Abmelden hat.
- 13 -
2.2.3.
Struktur
Die Struktur einer Internetseite wird als Hierarchie angegeben. In folgenden
Schaubildern werden die zwei Extreme der Hierarchie dargestellt: die flache und
die tiefe Hierarchie. Abbildung 1 zeigt eine flache Hierarchie, in der alle Links in
der ersten Ebene sichtbar sind. Der Nachteil der flachen Hierarchie ist die
Unübersichtlichkeit, die bei einer größeren Anzahl von Menüpunkten auftritt.
Deswegen empfiehlt sich diese Struktur generell für vier bis acht Menüpunkte.
Abbildung 2: Flache Hierarchie einer Internetseite
In Abbildung 2 wird die tiefe Hierarchie dargestellt. Jeder Punkt ist einem
anderen untergliedert. Der Vorteil der tiefen Hierarchie ist die übersichtliche
Gliederung der Menüpunkte. Nachteilig ist allerdings, daß ein Benutzer, der auf
eine Information, die weit unten in der Hierarchie gespeichert ist, zugreifen will,
viele Menüpunkte passieren muß. Die Tiefe der Ebenen sollte somit nicht größer
als vier sein, da sonst die Gefahr besteht, daß der Benutzer lieber die Seite verläßt,
anstatt weiter nach der Information zu suchen.
Abbildung 3: Tiefe Hierarchie einer Internetseite
Idealerweise sollte eine Struktur entstehen, die die beiden oben gezeigten Extreme
kombiniert und somit Übersichtlichkeit und schnelle Informationsfindung vereint.
Eine solche Struktur wird üblicherweise in drei Schritten gebildet:
Erster Schritt:
Die Oberbegriffe werden aus dem vorgegebenen Inhalt
extrahiert. Aus diesen Oberbegriffen entsteht dann das
Hauptmenü. Hierbei ist muß man darauf achten, daß es
weder zu wenige, noch zu viele Begriffe sind. Üblicherweise verwendet man zwischen vier und acht Oberbegriffe.
- 14 -
Zweiter Schritt:
Die Unterbegriffe werden den Oberbegriffen zugeordnet.
Dritter Schritt:
Die Reihenfolge der Unterbegriffe wird durch deren
Gewichtung festgelegt.
Die in Abbildung 3 dargestellte Struktur ergibt sich aus den angegebenen Inhalten
und interaktiven Elementen.
Abbildung 4: Struktur des Portals
Aus den in Kapitel 2.2.1 gewonnen Inhalte und den interaktiven Elementen aus
Kapitel 2.2.2 kann eine Hauptmenü erzeugt werden. Eine Aufteilung in zwei
Ebenen ist hierbei sehr günstig, denn innerhalb des Fachbereiches gibt es
verschiedene Organisationseinheiten, die eigene Inhalte haben. Des weiteren
lassen sich die angebotenen Dienste in einer Ebene darstellen. Die genaue
Darstellung wird im folgenden Kapitel zum Thema Design gezeigt. Im
Hauptmenü sind die folgenden Punkte 1-4 in einer Ebene und die Punkte 5-8.
1.
2.
3.
4.
5.
6.
7.
8.
Fachbereich
Professoren
Fachschaft
Institute
Stundenplan
Unterlagen
Service
Links
- 15 -
2.2.4.
Design
Das Design hat das Ziel, die Struktur der Webseite zu unterstützen. Aus diesem
Grunde wird eine Dreiteilung der Internetseite vorgenommen. Die drei Hauptteile
werden im Folgenden erläutert und in Abbildung 5 dargestellt.
Teil 1:
Teil 1 ist der Kopf der Internetseite. In ihm werden die acht Hauptmenüpunkte und das Logo dargestellt.
Teil 2:
Teil 2 beinhaltet das dynamische Untermenü der Internetseite.
Teil 3:
Teil 3 umfaßt den eigentlichen Inhalt.
Teil 1
Teil 2
Teil 3
Abbildung 5: Dreiteilung der Internetseite zur Strukturunterstützung
Im ersten Teil erfolgt eine Zerlegung des Kopfes der Seite in das Logo und das
Hauptmenü. Das Hauptmenü wird wiederum in die organisatorische Ebene und
die Dienstebene untergliedert.
Logo
Fachbereich
Professoren
Fachschaft
Stundenplan
Unterlagen
Service
Institute
Links
Organisationseinheiten
Dienste
Abbildung 6: Struktur des Hauptmenüs
- 16 -
Das Untermenü wird im zweiten Teil dargestellt. Das Untermenü weist als
Überschrift die entsprechende Zuordnung der Kategorie auf. Unter der Überschrift
werden die jeweiligen einzelnen Unterpunkte in alphabetischer Reihenfolge
aufgelistet. Besonderes Merkmal dieses Untermenüs ist seine Dynamik, d.h. daß
neu hinzugefügte Seiten automatisch als neuer Unterpunkt in das Menü
aufgenommen und angezeigt werden.
Innerhalb des dritten Teils werden die eigentlichen Informationen Internetseite
abgebildet. Diese Informationen können sowohl in Form von Texten, als auch von
Grafiken, dargestellt werden. Das Design der Informationen hängt im
Wesentlichen von ihrem Inhalt ab.
- 17 -
3. Internetanwendungen
3.1. N-Tier-Architekturen
Eine N-Tier-Architektur9 (N-Ebenen-Architektur) ist eine Architektur, die in N
Ebenen aufgeteilt ist. Die Ebenenbildung geschieht durch die Trennung der
verschiedenen Aufgaben einer Anwendung, wobei dann im Idealfall jede Aufgabe
seine eigene Ebene bekommt. Eine Anwendung läßt sich im Regelfall in die
Aufgaben Präsentation, Anwendungslogik und Datenhaltung trennen.
Eine Internetanwendung ist immer eine Architektur mit mehreren Ebenen. Im einfachsten Fall handelt es sich um eine 2-Tier-Architektur. Im Folgenden wird nun
dargestellt, wie die derzeit eingesetzten Architekturen für Internetanwendungen
diese Aufgaben verteilen.
3.1.1.
2-Tier-Architektur
Die typische 2-Tier-Architektur stellt die Client-Server-Architektur dar. Der
Client übernimmt in dieser Architektur die Präsentation der Aufgaben und der
Server bietet die Anwendungslogik und die Datenhaltung.
Tier 1: Präsentationsebene
Tier 2: Anwendung und Daten
Abbildung 7: 2-Tier Architektur [EF00]
9
Das englische Wort Tier bedeutet übersetzt Ebene/ Stufe. Somit werden Architekturen, die in
mehrere Ebenen eingeteilt sind als n-Tier-Architekturen bezeichnet.
- 18 -
3.1.2.
3-Tier-Architektur
Die 3-Tier Architektur verteilt die Aufgaben der Präsentation, Anwendungslogik
und der Datenhaltung in jeweils eigene Ebenen. Auf dem Client sorgt ein Browser
für die Präsentation der Daten. Ein Web- oder Applikationsserver bietet die
Verarbeitung der Anwendungslogik und ein Datenbankserver übernimmt die
Datenhaltung. Dies ist die gängigste Form bei Internetanwendungen.
Tier 1: Präsentation
Tier 2: Anwendung
Tier 3: Datenbanken
Abbildung 8: 3-Tier-Architektur [EF00]
3.1.3.
4-Tier-Architektur
Bei der 4-Tier-Architektur teilt man die Anwendung weiter auf. Man
unterscheidet hierbei zwischen Serverschnittstelle (Web-Server) und Anwendungslogik. Da die Serverschnittstelle jetzt als zusätzliche Aufgabe zu verstehen
ist, wird die Schnittstelle in eine eigene Ebene eingegliedert.
Tier 1: Präsentation
Tier 2: Web-Server
Tier 3: Anwendung
Tier 4: Datenbanken
Abbildung 9: 4-Tier-Architektur [EF00]
- 19 -
3.2. Serverseitige Programmiertechniken
Um Internetanwendungen erstellen zu können, reicht die ursprüngliche Technik
zur Darstellung von Information, die Hypertext Markup Language (Html), nicht
aus. Denn Html selbst ist keine Programmiersprache, mit ihr sind lediglich
Layoutinformationen und Verknüpfungen von Informationen möglich. Die Informationsverarbeitung und Sicherung muß daher mit anderen Techniken vorgenommen werden. Diese Aufgaben werden wie im Kapitel 3.1 beschrieben auf Seiten des Servers ausgeführt. Aus diesem Grunde werden hier verschiedene
Programmiertechniken angesprochen, die eine serverseitige Anwendungsentwicklung unterstützen.
Die Präsentation auf dem Client wird mit Html beschrieben, denn Html hat sich
als Darstellungssprache bewährt und ist am weitesten verbreitet. Es unterstützt die
Verarbeitung von Daten nur indirekt, indem es die Darstellung von Formularen
erlaubt. In diese kann der Benutzer seine Daten eingeben und der Browser, das
Programm, das die Html-Seiten anzeigt, überträgt die Daten dann über das Internet an eine Internetanwendung. Die Daten werden als key-value-Paar übertragen.
Key-value –Paar bedeutet, daß jedes Eingabefeld im Formular einen Schlüssel
(key) und einen Wert (Value), der eingegeben wird, hat. Die Internetanwendung
erhält eine Zeichenkette, die sich nach dem folgenden Muster aufbaut:
key1=value1&key2=value2&key3=...
Name=Billmann
Vorname=Andreas
...
Client:
Ein Formular wird
in der Html-Seite
dargestellt.
Die Formulardaten
werden als key-valuePaar übertragen.
Internetanwendung:
Die Daten werden
verarbeitet
Abbildung 10: Formulardaten werden versandt und verarbeitet.
Die Internetanwendung verarbeitet die gesandten Daten, (Speicherung, Berechnung, etc.) und generiert eine neue Html-Seite, die an den Client zurückgesandt
wird. Die meisten Anwendungen bestehen nicht nur aus einem einzigen Schritt,
sondern aus einer Abfolge mehrerer Ein- und Ausgaben. Die Gliederung und Aufreihung der Abfolgen stellen einen Ablauf dar. Da die Internetanwendung nicht
nur Html zur Darstellung, sondern auch noch ein neues Formular erzeugt, kann
dieser Ablauf abgearbeitet werden.
- 20 -
<html>
<head>
</head>
<body>
…
Client:
Html-Seite wird
dargestellt.
Es wird nur eine
Html-Seite an den
Client zurückgesandt.
Internetanwendung
Eine neue HtmlSeite wird
generiert.
Abbildung 11: Neue Html-Seite wird generiert und zurückgesandt.
Nachfolgend werden einige Techniken vorgestellt, die genau diese Abläufe unterstützen und die sich für die Entwicklung von Internetanwendungen anbieten.
3.2.1.
Common Gateway Interface (CGI)
„Das Common Gateway Interface (CGI) ist eine Schnittstelle zu dem Web-Server,
die es ermöglicht, die Funktionalität des Servers zu erweitern.“10
Das Common Gateway Interface ist wohl die bekannteste Möglichkeit, Webseiten
Interaktivität zu verleihen. Jedes ausführbare Programm kann als CGI dienen,
somit gibt es hier keine Beschränkung auf eine bestimmte Programmiersprache.
Die Programmiersprache muß nur einigen Mindestanforderungen genügen.
Sie muß:
• in die Standardausgabe schreiben,
• von der Standardeingabe lesen,
• Umgebungsvariablen einlesen können.
Als CGI Programme eignen sich sowohl klassische, kompilierte Programmiersprachen, wie C, als auch interpretierbare Programmiersprechen wie Perl oder
TCL.
Zu den Vorteilen von CGI zählen die weite Verbreitung des Systems11, die
einfache Schnittstelle und die Programmiersprachenunabhängigkeit. Aus diesen
Gründen können CGI-Anwendungen leicht auf verschiedene Webserver portiert
werden.
10
11
[K97, S. 27]
Es gibt kaum einen Webserver, der nicht das CGI anbietet.
- 21 -
Bei den CGI-Programmen sind jedoch die Nachteile so gravierend, daß sie heute
nicht mehr zur Realisierung großer Anwendungen eingesetzt werden. Der entscheidendste Nachteil ist, daß ein CGI-Programm als eigenständiger Prozess ausgeführt wird. Der mit jeder Anfrage einhergehende Verbrauch von Betriebssystemressourcen kann sich zudem negativ auf die Serververfügbarkeit auswirken.
„Die Konsequenzen können erdrückend sein: Stellen Sie sich einen gutbesuchten
Server vor, dessen Hauptattraktion eine Anwendung ist, die über CGI gestartet
wird. Nehmen wir an, diese Anwendung ist aufwendig und benötigt zur
Ausführung fünf Sekunden auf einem unbelasteten System. Was passiert, wenn in
einer Minute tausend Anfragen auf diesen Rechner einprasseln, dürfte klar sein.“12
Einem CGI-Programm ist es auch nicht möglich, auf Interna des Webservers
zuzugreifen. Hier seien nur kurz die Zugangskontrolle und die Authentifizierung
erwähnt.
3.2.2.
Webserver-APIs
Aufgrund dieser Defizite der CGI-Programme wurden die Webserver-APIs entwickelt. Die Application Programming Interfaces (APIs) zeichnen sich dadurch
aus, daß sie dynamisch geladen werden. Es handelt sich hierbei um Bibliotheken,
die, ab dem Moment, an in dem sie geladen wurden, für weitere Anfragen im
Speicher bleiben.
Durch die Tatsache, daß die APIs im gleichen Adreßraum wie die Webserver
arbeiten, kann auf die Ressourcen des Webservers zugegriffen werden und die
Performance wird gesteigert. Aufgrund dieser Vorteile eignen sich die APIs
besonders zur Programmierung komplexer Anwendungen.
Die Vorteile, die das CGI bot, werden bei den APIs allerdings zu Nachteilen. Die
komplexen und unterschiedlichen Schnittstellen haben zur Folge, daß die Programmierung der Anwendung komplizierter und eine leichte Portierbarkeit auch
nicht gewährleistet wird. Es ist nun auch möglich, den Webserver durch
unsaubere Programmierung zum Absturz zu bringen. Die Programmiersprachenunabhängigkeit ist auch nicht mehr gewährleistet, sondern hängt von der
eingesetzten API ab.
12
[RS00, S. 6]
- 22 -
3.2.3.
Servlets
Die Servlet API von SUN Microsystems ist die Grundlage für Java Servlets.
Diese Schnittstelle ermöglicht es, serverseitige Java-Anwendungen zu entwickeln.
Es gibt sehr viele kommerzielle Programme, die entweder die Servlet API von
SUN implementiert haben, oder die eine eigene API zum Ausführen von Servlets
programmiert haben. Deshalb besteht eigentlich für jeden Webserver auf jedem
Betriebssystem die Möglichkeit, Servlets als Programmiertechnik anzubieten.
Java bietet sich an dieser Stelle aus mehreren Gründen zur Anwendungsentwicklung an. Durch die Betriebsystemunabhängigkeit ist eine einfache
Portierung der Anwendung auf verschiedene Webserver und auch Betriebssysteme gewährleistet. Ein weiterer Vorteil ist das Fehlen von Zeigern. Denn eine
unsaubere Programmierung mit Zeigern ist die Hauptursache für kritische
Abstürze der Anwendung und meist auch des Webservers.
Der Lebenszyklus eines Servlets wird in der Abbildung 12: Lebenszyklus eines
Servlet-Objektes dargestellt. Das Interessante an diesem Lebenszyklus ist, daß es
vorgesehen ist, ein Servlet erst einmal für weitere Anfragen am Leben zu erhalten.
Das Servlet besitzt eine Initialisierungsmethode, die nur einmal, nach dem Laden
der Servlet-Klasse und der Erzeugung eines Objektes, aufgerufen wird. In dieser
Methode werden Variablen initialisiert, die sich nicht mehr ändern, beispielsweise
Zuweisung einer Datenbankverbindung oder Werte die aus einer Property-Datei
ausgelesen werden soll. Weitere Variablen die in der Initialisierungsmethode
häufig gesetzt werden sind Counter. Nach der Initialisierung wird eine ServletInstanz ausgewählt, denn es können natürlich auch mehrere Instanzen existieren.
Von der ausgewählten Instanz wird die Servicemethode aufgerufen, welches die
Abarbeitung des Servletcodes zur Folge hat. Die vom Servlet generierte Antwort
wird an den Client gesandt. Nun wird das Objekt für eine in der Serverkonfiguration angegebene Dauer im Speicher gehalten. Sobald eine neue Anfrage
an dieses Servlet gestellt wird, überprüft der Server, ob noch eine Instanz der
Servlet-Klasse im Speicher ist. Ist dies der Fall, dann wird eine ausgewählt und
wieder die Servicemethode aufgerufen. Sollte keine Instanz im Speicher
existieren, dann wird die Servlet-Klasse wieder geladen und der oben vorgestellte
Ablauf beginnt von neuem.
Der Vorteil dieses Lebenszyklus ist eindeutig die Steigerung der Performance,
denn Servlets die häufig angefragt werden bleiben fast immer im Speicher und
stehen damit sofort zur Abarbeitung zur Verfügung. Deshalb wird versucht bei der
Programmierung von Servlets nur ein Servlet zu programmieren, das mit Hilfe
- 23 -
von Parametern den Workflow realisiert und intern verschiedene Objekte zur
Abarbeitung des Workflows erstellt. Diese Technik wird in Kapitel 4.3.4 näher
vorgestellt.
Anfrage an ein
Servlet
Existiert eine
Instanz ?
Laden der ServletKlasse
Erzeugen eines
Objektes und
Aufruf der
Methode init()
Auswahl einer
Servlet-Instanz
Aufruf der Methode
service()
Abarbeitung der
Methode und
versenden der
generierten Antwort
an den Client
Neue Anfrage
Innerhalb des
Timeouts?
Aufruf der
Methode
destroy()
Abbildung 12: Lebenszyklus eines Servlet-Objektes
Die Verarbeitung der Anfrage des Clients und die Generierung einer Antwort
wird im Kapitel 4.3.3 erläutert.
3.2.4.
Java Server Pages (JSP)
Eine neue Entwicklung im Bereich serverseitige Javaanwendungen hat SUN mit
den Java Server Pages geschaffen. Im Unterschied zu den Servlets wird hier der
Javacode in die Html-Seite eingebettet.
- 24 -
Dies ist vor allem dann ein Vorteil, wenn die Gestaltung der einzelnen Seiten von
einem Designer vorgenommen werden soll, und wenn viele unterschiedliche
Darstellungen auf den Seiten benötigt werden. Die Anwendungslogik wird im
idealen Fall in JavaBeans gekapselt und der Designer muß neben seinen HtmlKenntnissen nur wissen, wie er an die Daten der Beans kommt. Durch die
Tatsache, daß man in JSP eigene Tags definieren kann, kann man die
Anforderung und die Speicherung der Daten aus bzw. in einem Bean in einer dem
Designer vertrauten Technik anbieten. Der Designer benutzt diese Tags wie die
Html-Tags, die er kennt.
Dieses Konzept wird auch von anderen serverseitigen Skriptsprachen wie PHP
oder ASP verwendet. Ein Nachteil bei serverseitigen Skriptsprachen ist die
Performance, denn der Quellcode muß zur Laufzeit interpretiert werden. Die Java
Server Pages gehen da einen anderen Weg, sie werden beim ersten Aufruf in
Bytecode kompiliert und stehen dann als Servlet zur Verfügung. Und nur wenn
der Code geändert wird, wird wieder neu übersetzt. So machen sich die Java
Server Pages die Vorteil der höheren Performance kompilierter Programme zu
nutzen. In der neueren Entwicklung wird diese Technik auch in anderen
Programmiersprachen verwendet.
3.2.5.
Vergleich der Techniken
Die Tabelle stellt einen Vergleich der Techniken bezüglich Portierbarkeit,
Performance und Programmierung dar. Die Programmierung wird hierbei unterteilt in die Programmierung der Präsentationsschicht und der Anwendungsschicht.
Programmierung Programmierung
(Präsentation) (Anwendungslogik)
Portierbarkeit
Performance
Common
Gateway
Interface
hoch
niedrig
komplex
komplex
Server-APIs
niedrig
hoch
komplex
komplex
Servlets
hoch
hoch
komplex
komplex
Java Server
Pages
hoch
hoch
einfach
komplex
Abbildung 13: Vergleich der serverseitigen Programmiertechniken
Ein Vergleich der Techniken zeigt, daß der Einsatz von Servlets oder Java Server
Pages zu bevorzugen ist. Im folgenden Kapitel wird die Auswahl der im Portal
des Fachbereichs eingesetzten Technik begründet und festgelegt.
- 25 -
3.3. Begründung der Auswahl der Techniken zur Portalimplementierung
Die Implementierung des Portals stützt sich auf die 3-Tier-Architektur. Da die 3Tier-Architektur am weitesten verbreitet ist, sind die benötigten Komponenten,
(Browser, Web-Server und Datenbank) überall vorhanden. Im Gegensatz dazu
wird für die 4-Tier-Architektur noch zusätzlich ein Applikationsserver benötigt.
Obwohl derzeit sehr viele Applikationsserver entwickelt werden, konnte sich in
diesem Bereich noch keine konkrete Technik (Corba, EJB etc.) durchsetzen.
Somit ist eine spätere Neuprogrammierung des Portals nicht ausgeschlossen.
Um einen späteren Austausch der Komponenten (Browser, Web-Server und
Datenbank)zu ermöglichen, ist die Anwendung in sich durch ein Mehrschichtenmodell unterteilt. Dieses Mehrschichtenmodell separiert die Anwendung in Präsentationsschicht , Geschäftslogik und Zugriffsschicht. Dies entspricht der Einteilung der 3-Tier-Architektur dahingehend, daß die Präsentations- und die Zugriffsschicht die Schnittstellen zur Präsentations- und Datenhaltungsebene bilden. Auf
die einzelnen Schichten wird im Rahmen von Kapitel 4 näher eingegangen.
Das Portal ist in Java als Servlet programmiert, um eine einfache Portierung zu
ermöglichen. Diese einfache Portierung ist sehr wichtig, da der Web-Server und
das Betriebssystem, auf dem das Portal installiert werden soll, noch nicht bekannt
sind bzw. sich auch zu einem späteren Zeitpunkt noch ändern können.
Durch die JDBC-Schnittstelle bietet Java außerdem eine elegante Möglichkeit, die
Unabhängigkeit von Datenbankmanagementsystemen in der Zugriffsschicht zu
erreichen. Des weiteren bietet Java die Unterstützung moderner Programmier- und
Webtechniken (Komponentenmodell, Corba, EJB etc.). Die Implementierung des
Portals in Java Server Pages bietet sich in diesem Fall nicht an, da sie eine hohe
Disziplin des Entwicklers voraussetzt. Denn hier besteht die Gefahr, daß bei einer
Weiterentwicklung des Systems die Trennung der Präsentationsschicht und der
Anwendungsschicht aufgehoben wird.
- 26 -
4. Java
4.1. Allgemeine Grundlagen von Java
Die Servlets, deren Verwendung in Kapitel 3.2.5 begründet und beschlossen
wurde, werden in Java programmiert. Um die Grundlagen der Programmiersprache Java näher vorzustellen, werden die Anforderungen an Java und die Java
Architektur in den folgenden Kapiteln beschrieben.
4.1.1.
Grundlegende Anforderungen bei der Entwicklung von Java
SUN Microsystems hatte ursprünglich die Idee, JAVA als eine Programmiersprache zu konzipieren, die für die Entwicklung von Programmen für Kleingeräte
(Toaster, Videorecorder etc.) eingesetzt wird. Die Programme sollten folgenden
Anforderungen genügen:
• geringe Größe der Programme:
Es sollten kleine Programme entwickelt werden, da Kleingeräte wie Toaster
o.ä. nur über sehr begrenzte Speicherkapazitäten verfügen.
• Portabilität:
Die Programme sollten auch mit den verschiedenen Chips der Gerätehersteller
kompatibel sind, ohne daß sie neu übersetzt werden müssen.
• Robustheit:
Es soll ausgeschlossen werden, daß die Kleingeräte aufgrund von
Programmabstürzen ausfallen.
Wegen der rasanten Entwicklung des World Wide Webs und der geringeren
Nachfrage nach Java als Programmiersprache für Kleingeräte änderte SUN
Microsystems die Strategie für Java. Es stellte sich heraus, daß sich Java aufgrund
der ursprünglichen Anforderungen an die Sprache insbesondere für verteilte Anwendungen im Web (Applet) eignet. „Ein Applet kann damit als eine neue Art
von Binärprogramm angesehen werden, das über verschiedene Hardware- und
Betriebssystemplattformen hinweg portabel ist und auf einfache Weise im Internet
verteilt werden kann.“13
Aufgrund der geringen Größe von Javaprogrammen ist die Verteilung der Anwendung über das World Wide Web in einer für den Benutzer akzeptablen Zeit möglich. Da das World Wide Web von Betriebssystemen unabhängig ist, kann nicht
klar festgelegt werden, über welches Betriebssystem der einzelne Benutzer
verfügt. Um zu garantieren, daß verteilte Programme trotz dieser Problematik
13
[K00, S. 31]
- 27 -
funktionieren, ohne mehrere, auf die verschiedenen Betriebssysteme individuell
zugeschnittene Versionen eines Programms entwickeln zu müssen, müssen die
verteilten Programme portierbar sein. Da Java die Anforderung der Portierbarkeit
auch schon auf Chipebene unterstützt, wurde es um die Fähigkeit der Betriebssystemunabhängigkeit erweitert. Derzeit entwickelt SUN Microsystems ein reines
Javabetriebssystem, das in der Lage sein soll, die optimale Ressourcenverteilung
selbst vorzunehmen. Diese zusätzliche Fähigkeit würde die Performance weiter zu
erhöhen.
Das World Wide Web beinhaltet die Gefahr, daß Programme aus dem World
Wide Web, die in der Lage sind, sich selbst zu starten, private Daten der Benutzer
lesen oder gar bearbeiten. Diese Gefahr stellt eine Bedrohung für die Privatsphäre
und die Persönlichkeitsrechte der Benutzer dar. Sie würde somit den Datenschutz
außer Kraft setzen und alle Benutzer auf lange Sicht zu „gläsernen“ Menschen
machen. Um diese Gefahr auszuschalten, wurde die Programmiersprache Java
zusätzlich zur Robustheit um die Anforderung der Sicherheit erweitert. Die
Robustheit wurde mit dem Sicherheitskonzept kombiniert.
Beide Anforderungen wurden durch das Sandkastenprinzip abgedeckt. Unter dem
Sandkastenprinzip versteht man die Kapselung des Programms in einem eigenen
Prozeß, aus welchem es nicht auf andere Bereiche (Speicher, Festplatten u.v.m.)
zugreifen kann. Wenn nun ein Fehler im Programm auftauchen sollte, wird das
Betriebssystem davon nicht beeinträchtigt, es wird lediglich der Prozeß des
Programms gestoppt. Dies ist bei Programmen, die in anderen Programmiersprachen erstellt wurde, leider nicht der Fall. Das am häufigsten auftretende Problem ist eine fehlerhafte Programmierung der Zeiger auf Speicherbereiche. Wenn
die Zeiger nicht mit ausreichender Sorgfalt programmiert werden, besteht leicht
die Gefahr, daß Speicherbereiche, die für andere Programme gedacht waren,
überschrieben werden. Im schlimmsten Fall sind dies die Speicherbereiche für die
Betriebssystemfunktionen. Aus diesem Grund wird in Java nicht mit Zeigern
programmiert. Java ist selbst für die Verwaltung des Speicherplatzes verantwortlich und übernimmt alle Funktionen, die zuvor der Entwickler ausführen mußte.
Im Laufe der Zeit zeigte sich, daß Java nicht nur für die Applets geeignet ist,
sondern man mit Java auch „richtige“ Anwendungen programmieren kann. Um
die Entwicklung von Applikationen zu unterstützen, werden die Grundfunktionalitäten durch weitere dynamisch verfügbare Bibliotheken erweitert. Beispielsweise
wurde die Bibliothek zur Programmierung von grafischen Oberflächen recht früh
in die Standardbibliotheken von Java eingefügt. Mittlerweile hat man das Konzept
der Bibliothek zur Programmierung von grafischen Oberflächen um eine neue
Bibliothek (Swing Bibliothek) erweitert. Die Standardbibliotheken umfassen in
der Zwischenzeit alle Dienste, die bei der Programmierung von Applikationen
benötigt werden (Datenbankzugriff, Netzwerkzugriff, uvm.). Zusätzlich zu den
- 28 -
Standardbibliotheken sind spezialisierte Bibliotheken (Servlets, Mail, uvm.) von
SUN Microsystems oder einem Drittanbieter erhältlich.
4.1.2.
Java Architektur
Die Java Architektur wird prinzipiell in zwei Teile aufgeteilt: die Java Virtual
Machine und das Java Application Programming Interface (API). Die Basis der
Ausführung von Javaprogrammen bildet die Java Virtual Machine. Der Quellcode
von Java wird von einem Javacompiler in den sogenannten Bytecode übersetzt.
Bei der Ausführung des Programms interpretiert die Java Virtual Machine den
Bytecode. Der Unterschied, der dieses Konzept grundlegend von den anderen
Compilersprachen wie C oder C++ trennt, ist die Tatsache, daß der Javacompiler
den Quellcode nicht direkt in Maschinencode übersetzt. Dies hat den Vorteil, daß
das Programm portierbar ist. Die Anforderung der Portierbarkeit wurde bereits in
Kapitel 4.1.1. angesprochen. Während Maschinencode von dem Betriebssystem
und der Maschine abhängig ist, wird der Bytecode erst zur Laufzeit für ein
spezielles Betriebssystem umgesetzt. Somit ist die alleinige Prämisse, die an ein
System gestellt werden muß, das Vorhandensein einer Java Virtual Machine.
Da interpretierbare Sprachen wie Perl oder Basic schon länger existieren, stellt
sich die Frage, worin der Unterschied zwischen Java und diesen Sprachen liegt.
Ein allgemeiner Nachteil der interpretierbare Sprachen ist die Tatsache, daß sie
eine geringere Performance als Compilersprachen haben. Die Ursache dieses Problems ist, daß eine Syntaxüberprüfung des Quellcodes erst zur Laufzeit vorgenommen wird und dadurch die Ausführgeschwindigkeit des Programms erheblich
reduziert wird. Im Gegensatz dazu entfällt bei Java die Syntaxüberprüfung zur
Laufzeit, da diese schon bei der Übersetzung des Quellcodes in den Bytecode
durchgeführt wurde. Außerdem ist der Quellcode der interpretierbaren Sprachen
unkomprimiert, was zu einer erhöhten Komplexität bei der Findung von Tokens
führt.
Während die Java Virtual Machine die Abstraktion vom Betriebsystem
übernimmt, abstrahiert das API von verschiedenen Diensten des jeweiligen
Betriebsystems. Beispielsweise werden in der Bibliothek „java.awt“ 14Klassen zur
Programmierung von grafischen Oberflächen bereitgestellt. Die Klassen der
Bibliothek kümmern sich um die spezifische Umsetzung der Oberfläche auf dem
jeweiligen Betriebsystem. So findet sich für jeden Dienst, den ein Betriebsystem
bietet, eine entsprechende Bibliothek, die diesen Dienst abstrahiert. Ein
Entwickler muß sich daher auch nur mit den Programmierkonzepten von Java
auseinandersetzen und nicht mit den verschiedenen Konzepten der einzelnen
Betriebsysteme. Dies verkürzt die Entwicklungszeit von Programmen, die auf
verschiedenen Betriebsystemen laufen sollen, erheblich und schafft durch ein
größeres Detailwissen in einer Konzeption eine höhere Stabilität der Programme.
14
Der Begriff „Klasse“ wird in Kapitel 4.2.1 näher erläutert.
- 29 -
Ein weiterer Vorteil der Abstraktion ist, daß sich ein Entwickler auf das
Wesentliche, nämlich die Funktionalität seiner Anwendung, konzentrieren kann.
Applets und Applications
Java Base API
Java Standard Extension API
Java Base Classes
Java Standard Extension Classes
Java Virtual Machine
Porting Interface
Adapter
Adapter
Adapter
JavaOS
Browser
OS
OS
OS
Hardware
Hardware
Hardware
Java on a Browser
Java on a desktop OS
Java on a smaller OS
Hardware
Java on JavaOS
Network
Abbildung 14: Java Base Platform [DS00]
Die Abbildung stellt das zugrundeliegende System, auf dem eine Javaanwendung
ausgeführt werden soll, weiß dar. Die dunklen Bereiche zeigen das Basissystem,
das zum Ausführen der Anwendung benötigt wird. Die hellgrauen Adapter stellen
die Verbindung zwischen dem System und der Java Virtual Machine her.
Interessant ist hierbei, daß das Javabetriebsystem keinen Adapter benötigt.
4.2. Objektorientierte Konzepte von Java
Da es sich bei Java um eine objektorientierte Programmiersprache handelt,
werden hier die wichtigsten objektorientierten Konzepte von Java vorgestellt. Im
Regelfall besteht eine Internetanwendung aus vielen einzelnen Teilen, deshalb ist
besonders der Einsatz der Abstraktion als grundlegendes Konzept gegeben. In der
Implementierung spielen vor allem das Konzept der Beziehungen, der
Polymorphismus und der Einsatz abstrakter Klassen, eine wichtige Rolle. Der
Einsatz dieser Konzepte wird in den einzelnen Kapiteln zu dem Thema
Anwendungsschichten gezeigt.
- 30 -
4.2.1.
Abstraktion
Als Abstraktion bezeichnet man in der objektorientierten Programmierung die
Trennung zwischen dem Konzept und der Umsetzung einer Sache. In dem
Konzept wird der Aufbau und die Funktionsweise einer Sache festgelegt. Die
Umsetzung ist dann die reale Sache, die auf Basis des Konzepts erzeugt wird. In
der Softwareentwicklung nennt man das Konzept eine Klasse und die Umsetzung
ist ein Objekt von einer Klasse.
Das folgende Beispiel verdeutlicht die Abstraktion. Der Konstruktionsplan eines
Autos ist ein Konzept. Wenn nun ein Auto nach diesem Konzept gebaut wird,
dann ist der Aufbau und die Funktionsweise des Autos festgelegt. Nach dem
Konstruktionsplan kann man aber nicht nur ein Auto, sondern beliebig viele Autos
herstellen. Ein weiterer Vorteil ist, daß ein Autofahrer der ein Auto, das nach
diesem Konstruktionsplan gebaut wurde, fährt und sich nach einiger Zeit ein
neues Auto, das nach dem gleichen Konstruktionsplan gebaut wurde kauft, kann
er sich sicher sein, daß das Auto genau so zu fahren ist wie sein erstes .
4.2.2.
Kapselung
„In objektorientierten Programmiersprachen wird eine Klasse durch die Zusammenfassung einer Menge von Daten und darauf operierender Funktionen (die nun
Methoden genannt werden) definiert.“15
Die Daten werden im Folgenden Membervariablen genannt und repräsentieren
den Zustand eines Objekts. Der Zustand eines Objekts kann bei jeder Instanz einer
Klasse unterschiedlich sein. Beispielsweise ist die Farbe (Membervariable) des
Autos grün (Zustand des Objektes Auto). Die Methoden repräsentieren das
Verhalten des Objekts. Im Beispiel sind die verschiedenen Verhaltensformen des
Objekts Auto „fahren“, „bremsen“, „stehen“ etc.
4.2.3.
Wiederverwendung
Mit Hilfe der Bildung von Klassen soll eine Wiederverwendung bereits
bestehender Softwareelemente ermöglicht werden. Jede Klasse ist somit ein
kleiner Teil einer großen Gesamtheit. Beispielsweise kann eine Klasse Adresse,
die in der Programmierung einer Buchhaltungssoftware verwendet wird, somit
auch in der Programmierung einer Adreßverwaltung benutzt werden. Dies hat zur
Folge, daß ein Objekt, das auf der Klasse Adresse aus der Buchhaltungssoftware
basiert, ebenfalls in der Adreßverwaltung verwendet wird. Dies ist nur aufgrund
15
[K00, S. 127]
- 31 -
der Tatsache möglich, daß beide Anwendungen den Aufbau des Objekts kennen,
da sie die gleiche Klasse als „Konstruktionsplan“ verwenden.
4.2.4.
Beziehungen
Zwischen Klassen und Objekten bestehen in der Regel Beziehungen. Im Rahmen
der objektorientierten Softwareentwicklung unterscheidet man prinzipiell drei
Grundtypen von Beziehungen:
•
„is-a“-Beziehungen
„is-a“-Beziehungen umfassen sowohl eine Generalisierung, als auch eine
Spezialisierung. Die Beziehungsaussage „Ein Auto ist ein Kraftfahrzeug.“
stellt also einerseits eine Generalisierung dar, indem das Auto als Teil der
Kraftfahrzeuge (wie z.B. auch Motorräder) charakterisiert wird, andererseits
erfolgt auch eine Spezialisierung der Kraftfahrzeuge auf das Auto.
•
„part-of“- Beziehungen
Eine „part-of“-Beziehung bezeichnet entweder eine Aggregation, oder eine
Komposition. Unter einer Aggregation versteht man den Vorgang, daß ein
Objekt ein anderes Objekt in sich aufnimmt, aber auch ohne das andere Objekt
existieren kann. Beispielsweise kann ein Auto eine Person aufnehmen, die
komplette Funktionsfähigkeit des Auto ist aber auch ohne Insasse gegeben.
Die Komposition hingegen umfaßt die Tatsache, daß ein Objekt aus anderen
zusammengesetzt ist. Ein Auto besteht aus einer Karosserie, vier Rädern,
einem Motor usw. Wenn bei der Komposition ein Objekt fehlt, ist das Auto
nicht mehr voll funktionsfähig. Somit kann man die Komposition als strengere
Form der Aggregation sehen, da sie eine existenzielle Abhängigkeit des
umfassenden Objekts von seinen Objektelementen darstellt.
•
Verwendungs- oder Aufrufbeziehungen
Die Verwendungs- oder Aufrufbeziehung beschreibt ein Objekt, das ein
anderes Objekt zeitlich begrenzt benutzt. „Herr Müller benutzt das Auto.“ ist
ein Beispiel hierfür. Herr Müller beginnt beim Einstieg in das Auto mit der
Benutzung, die mit seinem Ausstieg beendet wird.
4.2.5.
Vererbung
„>>is-a<< -Beziehungen werden in objektorientierten Programmiersprachen
durch Vererbung ausgedrückt. Eine Klasse wird dabei nicht komplett neu
definiert, sondern von einer anderen Klasse abgeleitet. In diesem Fall erbt sie alle
Eigenschaften dieser Klasse und kann nach Belieben eigene hinzufügen.“16
16
[K00, S. 129]
- 32 -
Allerdings ist beim Prinzip der Vererbung eine Besonderheit zu beachten. Sowohl
die Variablen, als auch die Methoden werden mit einer Eigenschaft, die man
Sichtbarkeit nennt, belegt. Die Sichtbarkeit bestimmt, wer auf welche Variablen
und Methoden zugreifen darf.
Man unterscheidet in Bezug auf die Sichtbarkeit prinzipiell drei Möglichkeiten:
•
Eine Variable oder eine Methode ist als öffentlich (public) deklariert. Sie ist
dann in der Klasse selbst, in abgeleiteter Klassen und in externen Klassen
sichtbar.
•
Eine Variable oder Methode ist als geschützt (protected) deklariert. Sie ist
nur in der Klasse selbst, in den abgeleiteten Klasse und in Klassen, die zum
selben Paket gehört, sichtbar.
•
Eine Variable oder Methode ist als privat (private) deklariert. Sie ist nur für
die Klasse selbst sichtbar.
Standardmäßig wird eine Variable oder Methode ohne explizite Deklaration der
Sichtbarkeit als protected eingestuft.
4.2.6.
Polymorphismus
Unter Polymorphismus versteht man die Möglichkeit, daß eine Variable, die zum
Speichern von Objekten des Typs A deklariert wurde, sowohl ein Objekt vom Typ
A aufnehmen kann, als auch ein Objekt B, das von einer abgeleiteten Klasse von
A erstellt wurde. So kann die Variable KFZ, die vom Typ Kraftfahrzeug ist,
nicht nur ein allgemeines Objekt vom Typ Kraftfahrzeug aufnehmen, sondern
auch ein Objekt Auto, dessen Klasse aus Kraftfahrzeug abgeleitet wurde. Eine
konkrete Anwendung des Prinzips des Polymorphismus wird in Kapitel 5.3.5
näher beschrieben.
4.2.7.
Statische Elemente
Die bisherige Betrachtung beschränkte sich auf Instanzen von Klassen. Diese
Instanzen umfassen Membervariablen und Methoden. Allerdings existieren auch
Anwendungsfälle, bei denen es sinnvoll ist, Eigenschaften, die nicht zu der
Instanz einer Klasse gehören, zu verwenden. Diese Eigenschaften sind Variablen
oder Methoden und werden als Klassenvariablen oder Klassenmethoden
bezeichnet. Sie können unabhängig von der Instanz einer Klasse verwendet
werden.
- 33 -
Wenn die Instanzen einer Klasse auf eine Klassenvariable zugreifen, erfolgt dieser
Zugriff auf die gleiche Klassenvariable. Das bedeutet, daß eine Änderung des
Wertes der Klassenvariable durch eine Instanz für allen anderen Instanzen gilt.
Die Klassenmethoden werden häufig zur Erzeugung eines Objektes verwendet.
Die Entwurfsmuster Finder und Factory bauen auf den Klassenmethoden auf und
werden in Kapitel 5.2.4 näher beschrieben.
4.2.8.
Schnittstelle
„ Die Schnittstelle (interface) definiert die Merkmale eines Systems, wie sie von
einem anderen System aus gesehen werden. So definiert eine Komponentenschnittstelle die Methoden und Eigenschaften (Felder), die vom Klienten der
Komponente benutzt werden können.“17
In einer Schnittstelle wird festgelegt, welche Methoden ein Entwickler in eine
Klasse implementieren muß, wenn er erreichen will, daß die Klasse die Schnittstelle benutzt. Der daraus resultierende Vorteil ist, daß ein Entwickler die Methoden einer Klasse, die er benutzen will, kennt, wenn er die Struktur der Schnittstelle kennt.
Als Beispiel wird hier die Java Database Connectivity (JDBC) Schnittstelle18
erläutert. In einer Treiberklasse, die die JDBC-Schnittstelle implementiert, müssen alle in der Schnittstelle angegeben Methoden programmiert sein. Ein Entwickler, der nun über diese Treiberklasse auf eine Datenbank zugreifen will, kann
sicher sein, daß in der Klasse eine Methode getConnection( ) existiert, mit der
er den Datenbankzugriff erreichen kann, da die Methode in der Schnittstelle
definiert wurde.
4.2.9.
Abstrakte Klassen
Abstrakte Klassen umfassen mindestens eine abstrakte Methode, was bedeutet,
daß diese Methode nicht in der Klasse implementiert ist. Dies hat zur Folge, daß
keine Instanz von dieser Klasse erzeugt werden kann. Die Klassen, die von einer
abstrakten Klasse erben, müssen die abstrakten Methoden implementieren. Wenn
diese Implementierung nicht erfolgt, werden sie selbst auch als abstrakte Klassen
bezeichnet. Dieser Vorgang kann sich über mehrere Ebenen der Vererbungshierarchie fortsetzen, bis alle abstrakten Methoden implementiert wurden.
17
18
[DS00, S.441]
Die Funktionsweise der JDBC-Schnittstelle wird in Kapitel 5.1.3 näher erläutert.
- 34 -
Abstrakte Klassen werden verwendet, um die Gemeinsamkeiten ähnlicher Klassen
zusammenzufassen und teilweise zu implementieren. In Kapitel 5.3.5.wird die
abstrakte Klassen am Beispiel der Klasse Screen weiter verdeutlicht.
4.2.10. Entwurfsmuster
„Ein Entwurfsmuster benennt, abstrahiert und identifiziert die relevanten Aspekte
einer allgemeinen Entwurfsstruktur. Diese Aspekte beschreiben, warum das
Muster für die Entwicklung eines wiederverwendbaren objektorientierten
Entwurfs nützlich ist. Das Entwurfsmuster identifiziert die teilnehmenden Klassen
und Objekte, die Rollen, die sie spielen, die Interaktionen zwischen den Rollen
und die ihnen zugeteilten Aufgaben. Jedes Entwurfsmuster konzentriert sich auf
ein bestimmtes objektorientiertes Entwurfsproblem. Es beschreibt, wann es
einsetzbar ist, ob es angesichts einschränkender Randbedingungen eingesetzt
werden kann, und welche Konsequenzen sein Einsatz hat.“19
19
[GHJV96, S.4]
- 35 -
5. Anwendungsschichten
5.1. Datenbanksystem
Um auf Daten langfristig zugreifen zu können, müssen diese gespeichert werden.
Diese Speicherung kann entweder in Dateien, oder in Datenbankmanagementsystemen vorgenommen werden. Die Datenspeicherung in Dateien ist einfach zu
realisieren und hat allerdings den Nachteil, daß ein Auslesen von Teilinformationen recht kompliziert ist. Datenbankmanagementsysteme bieten dagegen einen
hohen Komfort bei der Datenhaltung, der im Folgenden noch näher beschrieben
wird. Die relationalen Datenbankmanagementsysteme haben sich als Datenspeicher durchgesetzt, so daß die wenig verbreiteten objektorientierten Datenbankmanagementsysteme hier nicht weiter betrachtet werden.
5.1.1. Leistungsmerkmale von relationalen Datenbankmanagementsystemen
Folgende Leistungsmerkmale begründen den Komfort der relationalen Datenbankmanagementsysteme:
•
•
•
•
Effizienter Datenzugriff und –speicherung
Die Datenbanken erlauben einen wesentlich schnelleren und zuverlässigeren
Zugriff auf Daten als Dateien.
Konsistenzprüfung der Daten
Aufgrund der Tatsache, daß Daten nur bestimmte Werte annehmen können,
erfolgt bei einer Speicherung falscher Werte eine Fehlermeldung.
Mehrbenutzerfähigkeit
Bei Internetanwendungen werden die Daten von mehreren Teilnehmern gelesen und geschrieben. Die Regelung des Zugriffs auf diese Daten wird von
dem Datenbankmanagementsystem übernommen. Es darf beispielsweise nicht
vorkommen, daß zwei Teilnehmer gleichzeitig auf den selben Dateninhalt
schreiben.
Transaktionen
Eine Transaktion enthält eine Gruppe von Anweisungen, die ausgeführt
werden. „Die Anforderungen an Datenbanktransaktionen werden mit dem
Begriff ACID abgekürzt (atomic, consistent, isolated, durable)“ [DS00]
Das heißt, daß eine Transaktion als eine atomare, untrennbare Einheit zu
betrachten ist. In Verbindung mit der Konsistenzprüfung bedeutet das, daß im
Falle einer fehlerhaften Anweisung alle anderen Anweisungen entweder nicht
mehr ausgeführt oder rückgängig gemacht werden. Die Isolation soll sicherstellen, daß keine weitere Transaktion die gerade ausgeführte Transaktion
beeinflussen kann. Nach der Beendigung einer Transaktion müssen alle zuvor
eingetragenen Daten dauerhaft gespeichert werden.
- 36 -
•
Ausfallsicherheit
Das Datenbankmanagementsystem hat Mechanismen, die nach einem
Systemabsturz eine Reparatur beschädigter Daten vornehmen können.
5.1.2.
Structured Query Language (SQL)
„SQL –structured query language– bedeutet strukturierte Abfragesprache.
Abfragesprachen dienen in Datenbanksystemen zur Datendefinition und
Informationsgewinnung.“20
SQL ist heute in Verbindung mit relationalen Datenbankmanagementsystemen
die Standardabfragesprache. Durch SQL wird eine Trennung zwischen der Datenbankabfrage und der Programmiersprache geschaffen. So bietet nahezu jede
Programmiersprache die Möglichkeit, eine Abfrage, die in SQL formuliert ist, an
das relationale Datenbankmanagementsystem zu senden und das Ergebnis auszuwerten. Dies bietet wiederum eine hohe Unabhängigkeit. So kann zu einem
späteren Zeitpunkt die Datenbank gewechselt werden und eine bestehende
Anwendung kann auf die Daten ohne Änderung zugreifen.
Leider gibt es keinen SQL-Standard, da die verschiedenen Hersteller von
relationalen Datenbankmanagementsystemen eigene SQL-Dialekte entwickelten.
Das American Standard Institute (ANSI) hat einen Standard für relationale
Sprachen entworfen, das ANSI-SQL. Jedoch bildet ANSI-SQL lediglich den
kleinsten gemeinsamen Nenner aller Dialekte.
5.1.3.
Java Database Connectivity (JDBC)
„Java Database Connectivity (JDBC) stellt eine Schnittstelle zu relationalen
Datenbankmanagementsystemen (RDBMS) dar.“21
JDBC stellt somit alle nötigen Funktionalitäten bereit, die man zum Zugriff auf
ein relationales Datenbankmanagementsystem benötigt. Da jedoch jedes relationales Datenbankmanagementsystem einen anderen Zugriffsmechanismus hat, muß
für jedes System ein eigener JDBC-Treiber existieren.
Man unterscheidet vier Typen von JDBC-Treibern:
Typ 1:
20
21
Eine JDBC-ODBC-Bridge22 ermöglicht den Zugriff auf ein
relationales Datenbankmanagementsystem mit Hilfe eines ODBC
[M95, S.7]
[DS00, S. 157]
- 37 -
Treibers.
Typ 2:
Der JDBC-Treiber setzt auf einen proprietären Treiber des
Herstellers des relationalen Datenbankmanagmentsystems auf.
Typ 3:
Der Treiber ist komplett in Java geschrieben, benötigt aber eine
Middleware zur Kommunikation.
Typ 4:
Der Treiber ist komplett in Java geschrieben und die JDBC-Calls
werden direkt in das erforderliche Protokoll des relationalen
Datenbankmanagementsystems umgesetzt.
Die eindeutige Spezifikation der Schnittstelle erlaubt es, auf jedes relationale
Datenbankmanagementsystem in der gleichen Weise zuzugreifen, unabhängig
vom Treibertyp. Das ermöglicht ein problemloses Austauschen der Datenbankmanagementsystemen. Im Quellcode muß nur der Verweis auf den alten Treiber
durch einen Verweis auf den Treiber ersetzt werden. Dies geschieht einfach durch
das Austauschen der Treibernamen. Aus diesem Grund bietet sich die Verwendung von JDBC in der Zugriffsschicht an. Man sollte aber bei der
Programmierung auf eine einheitliche Verwendung von ANSI-SQL achten, denn
sonst kann es, aufgrund der Verwendung herstellerspezifischer Dialekte, zu
Problemen bei einem Austausch der Datenbankmanagementsysteme kommen.
Die JDBC Schnittstelle bietet unter anderem folgende Funktionalitäten, die auch
für die Implementierung des Portals eingesetzt werden:
•
•
•
5.1.4.
Über JDBC kann man die Verbindung zur Datenbank herstellen. Man
erhält nach Anforderung ein Connection-Objekt, welches alle weiteren
benötigten Objekte liefert.
Für die Abrage der Datenbank stellt das Connection-Objekt ein StatementObjekt, welches die SQL-Abfrage und ihre Ausführung kapselt. Die SQLAbfrage wird als Zeichenkette dem Statement-Objekt übergeben.
Das Statement liefert als Ergebnis einer SELECT-Anweisung ein
ResultSet-Objekt zur Verfügung, in dem alle gefundenen Datensätze
gespeichert sind und durch Iteration abgefragt werden können.
Zugriffsschicht
Um der Anforderung, das Datenbanksystem von den Geschäftsobjekten zu
trennen, nachzukommen, muß eine Zugriffsschicht erstellt werden. Aus der
Implementierung einer Zugriffsschicht entstehen mehrere Vorteile:
22
Die JDBC-ODBC-Bridge ist bereits im Lieferumfang von Java enthalten.
- 38 -
Die Zugriffsschicht kapselt die spezifischen Eigenschaften des Datenbanksystems. Somit ist ein leichter Austausch des Datenbanksystems gewährleistet, denn die anfallenden Änderungen müssen nur in der Zugriffsschicht vorgenommen werden. Dadurch kann auch jede beliebige Art der
Speicherung der Daten vollzogen werden. Somit kann man das situationsspezifisch optimale Datenbankmanagementsystem auswählen und eine
Steigerung der Performance erreichen.
In der Zugriffsschicht kann man durch die Implementierung von
Mechanismen wie Caching oder Connection-Pooling die Performance
entscheidend verbessern. Ein späteres Einfügen von solchen Mechanismen
kann ohne den Eingriff in die komplette Anwendung vollzogen werden.
Die Verwaltung der Verbindungen zum Datenbanksystem bietet den
Vorteil, daß mit Hilfe von Kontrollmechanismen die Datenkonsistenz
gewahrt bleibt.
Für die Implementierung einer Zugriffsschicht existieren zur Zeit zwei Modelle:
1. Jedes Geschäftsobjekt ist für ihren Persistenzmechanismus selbst verantwortlich. Dadurch, daß man den Persistenzmechanismus in dem Objekt
selbst kapselt, muß man bei einer Änderung des Geschäftsobjekts nur die
entsprechende Klasse ändern.
2. Der Zugriffsschicht wird die Klassenstruktur der Anwendung, die Struktur
der Datenbank und die Abbildung zwischen beiden bekannt gemacht Das
geschieht durch eine Speicherung der Informationen selbst in einer
Datenbank oder in Dateien. Mit Hilfe dieser Informationen kann die
Abbildung zu Laufzeit vorgenommen werden. Der Vorteil ist hierbei, daß
(fast) kein Persistenzcode mehr in den Klassen befindet, der Nachteil ist,
daß eine Änderung der Klassenstruktur oder der Datenbank auch eine
Neuaufbereitung der Informationsquelle für die Zugriffsschicht nach sich
zieht.
5.1.5.
Implementierung
Die Implementierung der Zugriffsschicht für das Portal umfaßt das erste Modell.
Das Geschäftsobjekt ist für seinen Persistenzmechanismus selbst verantwortlich.
Die Zugriffsschicht bekommt vom Geschäftsobjekt eine Beschreibung, welche
Daten es wohin speichern soll, bzw. welche Daten es von wo holen soll. Diese
Beschreibung ist in dem vorliegenden Fall in SQL gehalten, sie könnte aber auch
in einer beliebigen Sprache sein. Die Zugriffsschicht selbst interpretiert die
Beschreibung und entscheidet dann, wie der Zugriff passieren soll.
- 39 -
In der vorliegenden Implementierung besteht die Zugriffsschicht aus zwei
Klassen. Die DataAccess-Klasse bekommt die Beschreibung vom Geschäftsobjekt
und fordert dann je nach Anweisung eine Verbindung zum Lesen aus der
Datenbank oder eine Verbindung zum Schreiben in die Datenbank an. Diese
Verbindungen werden von der Klasse ConnectionPool verwaltet.
Diese Verwaltung kann nur funktionieren, wenn es nur eine Instanz der Klasse
ConnectionPool gibt. Um dies sicherzustellen, wurde das Entwurfsmuster
„Singleton“ in der Klasse implementiert.
„Zweck: Sichere ab, daß eine Klasse genau ein Exemplar besitzt, und stelle einen
globalen Zugriffspunkt darauf bereit.“23
public class Singleton {
private static Singleton mySingleton = null;
private Singleton() {}
public static Singleton getInstance() {
if (mySingleton == null) {
mySingleton = new Singleton();
}
return mySingleton;
}
}
Listing 1: Entwurfsmuster Singleton
Der ConnectionPool hält zehn Verbindungen zur Datenbank offen und verwaltet
sie in einem Pool. Diese Verbindungen sind ausschließlich für den lesenden
Zugriff auf die Datenbank gedacht. Wenn nun mehr als zehn Anfragen an die
Datenbank bestehen, werden weitere Verbindungen bereitgestellt und der Pool
wird vergrößert. Wenn nun die Anfragen wieder sinken, wird der Pool wieder
verkleinert. So wächst der Pool dynamisch mit den Zugriffen. Dadurch erreicht
man eine deutlich höhere Performance.
Um Probleme beim Schreiben in die Datenbank zu verhindern, stellt der
ConnectionPool nur eine einzige Verbindung zum Schreiben in die Datenbank
zur Verfügung. Der ConnectionPool stellt bei der Anforderung dieser
Verbindung fest, ob sie bereits vergeben ist. Ist dies der Fall, so muß das
Geschäftsobjekt, das gerade die Verbindung angefordert hat, warten, bis die
Verbindung wieder freigegeben wird.
Auf der folgende Seite wird in der Abbildung 15 die Zugriffsschicht als
Diagramm dargestellt.
23
[GHJV96, S. 157]
- 40 -
LEGENDE:
Geschäftsobjekt
erzeugt
DataAccess
DataAccess
DBConnectionPool
SQL
WriteConnection
von
DBConnectionPool
anfordern
INSERT / UPDATE
Art der
Abfrage
Connection von
DBConnectionPool
anfordern
SELECT
Warten
Connection in
Benutzung?
NEIN
JA
Connection im
Pool?
NEIN
JA
Connection an
DataAccess
übergeben
Connection aus dem
Pool entfernen
neue Connection
erstellen
Connection an
DataAccess
übergeben
SQL ausführen
Connection zurück
an
DBConnectionPool
SQL ausführen
Kennzeichnung der
Connection als
unbenutzt
Connection zurück
an
DBConnectionPool
JA
Wartende Anfrage
benachrichtigen
Connection
schließen
Max.
Conncetions im
Pool?
NEIN
Connection
zurück in den
Pool
ResultSet an das
Geschäftobjekt
geben
Abbildung 15: Vereinfachte Darstellung der Funktionsweise der Zugriffsschicht
- 41 -
5.2. Geschäftslogik
In der kommerziellen Softwareentwicklung ist die Logik, die in einer Anwendung
implementiert werden soll, auf der Geschäftslogik aufgebaut. Unter der
Geschäftslogik versteht man den logischen Ablauf von Geschäftsprozessen. Die
im Folgenden erläuterten Begriffe werden anhand des Beispieles „Einkaufen im
Internet“ verdeutlicht. Die Geschäftslogik umfaßt in diesem Fall die realen
Geschäftsprozesse Warenauswahl, Warenkauf und Bezahlung. Diese bilden die
Grundlage für die Logik der Internetanwendung.
5.2.1.
Geschäftsprozeß
Ein Geschäftsprozeß umfaßt generell eine Reihe von Aktivitäten und führt zu
einem Ergebnis, das für den Kunden von Wert ist. Folglich besteht ein
Geschäftsprozeß aus mehreren Schritten. Die Logik, die festlegt, in welcher
Reihenfolge die Schritte durchzuführen sind, bezeichnet man als Workflow.
Dieser Workflow wird bei einer Anwendung in Programmcode umgesetzt.
Im Rahmen des Geschäftsprozesses „Warenauswahl“ gibt es beispielsweise die
Aktivitäten „Warenpreis vergleichen“ und „in den Warenkorb legen“.
5.2.2.
Geschäftsobjekte
Innerhalb eines Geschäftsprozesses werden ein oder mehrere Geschäftsobjekte
benutzt. Ein Objekt der „realen“ Welt, das in einem Geschäftsprozeß verwendet
wird, versteht man als Geschäftsobjekt. So werden die Geschäftsobjekte „Waren“
und „Warenkorb“ im Rahmen des Geschäftsprozesses „Warenauswahl“ benutzt.
Ein Geschäftsobjekt muß jedoch nicht notwendigerweise ein reales Objekt sein,
sondern es kann auch künstlicher Natur sein, wie beispielsweise der Preis einer
Ware.
„Wenn man Prozesse der echten Welt auf einem Computer simulieren will, so
macht es Sinn, die echte Welt so genau wie möglich auf dem Computer
abzubilden. Ein möglicher Weg ist, die Welt als eine Anzahl von Objekten zu
beschreiben, die sich aufeinander beziehen.“24
Diese Abbildung des „realen“ Objekts ist ein Softwarekonstrukt, das ebenfalls
Objekt genannt wird.
In der aktuellen Softwareentwicklung werden die Geschäftsobjekte als Komponenten abgebildet. Eine Komponente kapselt Daten und Methoden wie ein Objekt.
24
[DSOO, S. 78]
- 42 -
Allerdings ist eine Komponente aus dem objektorientierten Kontext herausgelöst
und kann auch in einer strukturierten Programmiersprache wie C programmiert
werden. Der Softwareentwickler benutzt eine Komponente wie eine Black Box,
d.h. er übergibt ihr Daten und erhält wiederum Daten, ohne zu wissen, wie die
Verarbeitung der Daten in der Komponente implementiert ist. Durch die Gemeinsamkeiten, daß Komponenten ähnlich wie Objekte einen Zustand, Eigenschaften
und Funktionen haben, bietet sich das Objekt als Grundlage der Komponente an.
5.2.3.
JavaBeans
JavaBeans ist ein Vorschlag von SUN Microsystems, wie Komponenten in Java
aussehen sollen. Ursprünglich waren sie als Komponenten für visuelle Softwareentwicklungssysteme, wie den JBuilder von Borland oder Forte von SUN Microsystems, gedacht.
„Die öffentliche Schnittstelle einer JavaBeans-Komponente enthält Definitionen
von Ereignissen, Eigenschaften sowie Methoden.“25
Damit die visuellen Softwareentwicklungssysteme die JavaBeans einfach einbinden können, unterliegen die JavaBeans vorgegebenen Entwurfsmustern26. Die
Konvention ist, daß den Eigenschaften mit einer Methode
set<Eigenschaftsname>(...) ein Wert zugewiesen wird und man diesen Wert
mit einer Methode get<Eigenschaftsname>() wieder auslesen kann.
Die JavaBeans müssen nach der Definition auch eine Persistenzmechanismus
integrieren, als Standardmechanismus wird hier Javas „Object Serialization“
benutzt. Es kann aber auch ein eigener Mechanismus implementiert werden.
5.2.4.
Implementierung
Die Geschäftsobjekte des Portals sind im Komponentemodell von Java, den
JavaBeans realisiert. Alle Geschäftsobjekte verfügen über die vorgegebenen setund get-Methoden. Dadurch wird der Aufruf und der Umgang mit einem
Geschäftsobjekt in der Präsentationsschicht vereinfacht und vereinheitlicht.
Um die Geschäftsobjekte in der Präsentationsschicht verwenden zu können, haben
diese Entwurfsmuster zur Erzeugung bestehender Geschäftsobjekte aus der Daten25
[GT00, S. 144]
SUN Microsystem nennt die Spezifikation zwar Entwurfsmuster, aber es sind keine nach
[GHJV96].
26
- 43 -
bank. Als erzeugende Entwurfsmuster sind die Muster „Finder“ und „Factory“
implementiert. Durch einen einfachen Aufruf einer statischen Methode erhält man
ein Objekt mit den gewünschten Werten. Sollte ein Geschäftsobjekt wiederum ein
oder mehrere Geschäftsobjekte beinhalten, so werden innerhalb des Objektes alle
anderen Objekte erzeugt. Hierfür wird das Muster „Chain of Responsibility“
benutzt. Durch Verkettung wird die Erzeugung von Objekten innerhalb eines
Geschäftsobjektes an die Objekte weiterdelegiert. Dadurch wird sichergestellt,
daß bei der Benutzung eines Objektes auch alle anhängende Objekte bis zur
untersten Ebene zur Verfügung stehen. Für einige Geschäftsobjekte ist es auch
nicht notwendig, daß sie über eine öffentliche Methode zum erstellen haben. Es
reicht bei Geschäftsobjekten, die nur innerhalb eines anderen Geschäftsobjektes
Sinn machen, aus, die Erzeugermethoden mit protected zu deklarieren. Ein
„leeres“ Objekt, das dann gefüllt werden soll, wird über den Standardkonstruktor
erzeugt.
public class GeschäftsobjektA
{
GeschäftsobjektB objektB;
public GeschäftsobjektA();
public GeschäftsobjektA findByID(int id);
public GeschäftsobjektA findByName(String name)
{
objektB = GeschäftsobjektB.findByID(1);
...
Listing 2: Entwurfsmuster Finder und Factory
findById
GeschäftsobjektA
findById
findById
GeschäftsobjektC
GeschäftsobjektB
findById
GeschäftsobjektD
Abbildung 16: Chain of Responsibility
Die Geschäftsobjekte sind aber auch für ihren Persistenzmechanismus verantwortlich. So hat jedes Objekt eine Methode, die zur Speicherung des O in der DB
dient. Wie bei den erzeugenden Methoden auch, sind sie nicht alle als public
deklariert, denn es gibt auch Geschäftsobjekte, bei denen es keinen Sinn macht,
sie außerhalb eines bestimmten Kontextes zu speichern. Auch hier wird mit dem
Muster „Chain of Responsibility“ sichergestellt, daß alle Objekte, die innerhalb
eines zu speichernden Objektes sind, mitgespeichert werden.
- 44 -
5.3. Präsentation
Die Präsentation hat die Aufgabe, Daten darzustellen und die Dateneingabe zu ermöglichen. Sie soll die Informationsaufbereitung sinnvoll unterstützen und der
leichteren Handhabung einer Anwendung dienen. Hierbei gibt es unterschiedliche
Varianten der Darstellung. Eine Variante ist die alphanummerische Ausgabe in
der Kommandozeile. Sie eignet sich weniger für komplexe Anwendungen. Eine
weitere Variante ist, daß eine speziell auf die Daten zugeschnittene Anwendung
die Darstellung übernimmt. Diese eignet sich besonders für fest installierte, nicht
verteilte Anwendungen. Wenn aber ein verteiltes System existiert, in dem
unterschiedliche Teilnehmer mit unterschiedlichen Betriebssystemen die gleichen
Informationen betrachten wollen, ist es am einfachsten, wenn man die Daten mit
Formatierungsbefehlen koppelt und die Interpretation der Formatierungsbefehle
von einer Software vornehmen läßt. Dies hat den Vorteil, daß man nicht an eine
Anwendung gebunden ist. Es kann eine zweite Anwendung geschrieben werden,
das diese Formatierungsbefehle auch umsetzen kann. Ein Beispiel hierfür sind die
Importfilter gängiger Textverarbeitungsprogramme.
5.3.1.
Hypertext Markup Language (Html)
Die Hypertext Markup Language wurde zur Darstellung und Verknüpfung von
Informationen entwickelt. Html hat sich als Standarddarstellung im World Wide
Web durchgesetzt. Dies ist vor allem auf die Einfachheit der Sprache zurückzuführen. Bei Html handelt es sich um eine Auszeichnungssprache. Mit einem sehr
kleinen Satz an Auszeichnungen (Tags) sind sehr komplexe Darstellungen
möglich.
Zur Betrachtung eines Html-Dokumentes benötigt man einen Browser. Der
Browser ist ein Programm, das die Auszeichnungen der Html-Seite interpretiert
und die Information entsprechend darstellt. Interessant ist dabei, daß Auszeichnungen, die dem Browser nicht bekannt sind, einfach „überlesen“ werden. Das
garantiert eine Abwärtskompatibilität der Html-Standards. So ist eine Seite auch
dann darstellbar, wenn man einen älteren Browser benutzt, der diese Auszeichnungen nicht interpretieren kann.
Ein Html-Dokument besteht aus einem Kopf (head) und einem Rumpf (body).
Der Kopf enthält Metainformationen und den Titel des Html-Dokumentes, während der Rumpf die eigentlichen Informationen und die Formatierungsbefehle zur
Darstellung umfaßt.
Die Verknüpfung mehrerer Dokumente wird in Html mit Hilfe sogenannter Links
realisiert. Ein Link ist ein sichtbares Objekt der Html-Seite, beispielsweise ein
- 45 -
Bild oder ein Text, das von einer speziellen Auszeichnung umschlossen ist. Innerhalb der Auszeichnung wird die Adresse des zu verknüpfenden Elements angegeben. Dieses Element muß nicht zwingend ein Html-Dokument sein. Sobald man
den Link mit der Maus anklickt, wird das Element in den Browser geladen.
5.3.2.
Servlets
Die Abbildung 12 zeigt, daß die Methode service( ) bei jeder Anfrage an ein
Servlet aufgerufen wird. Die Methode service( )beim Servlet entspricht der
Methode main( ) bei der Applikation. Die Methode service( ) erhält zum
einen ein ServletRequest-Objekt, in dem alle Daten zur Anfrage gekapselt
werden, und zum anderen ein ServletResponse-Objekt.
Im ServletRequest-Objekt exisitieren Methoden, die Werte der klassischen
CGI-Variablen liefern. Zusätzlich hat das Objekt Methoden, die den Zugriff auf
getParameter(String
die
Parameter
erleichtern.
Die
Methode
parametername) liefert den Wert zu einem Parameter parametername zurück.
Die Methode getParameterNames( ) bietet den Zugriff auf alle Parameternamen
in der Anfrage.
„Mit Vorsicht zu genießen ist dabei String getParameter(String name). Sind
nämlich mehrere Werte einem Schlüssel zugeordnet, erhält man mit
getParameter(String name) nur einem Wert. Daher sollte diese Methode auch
aus dem Servlet-API verschwinden. Der Protest einiger Entwickler hat jedoch
dazu geführt, daß Sun die Methode wieder eingeführt hat. Ist man sich nämlich
sicher, daß nur ein Wert übermittelt werden soll, ist es sehr viel komfortabler,
direkt mit einem String zu arbeiten, anstatt immer auf ein Array zuzugreifen.
Werden
mehrere Parameter gleichen Namens übermittelt, liefert
27
getParameter(String name) den ersten.“
Eine Besonderheit stellt die Methode getInputStream( ) dar. Mit dieser
Methode ist es möglich, Binärdaten zu lesen, so daß Dateien mit Hilfe eines HtmlFormulars an ein Servlet übertragen werden können.
Der zweite Parameter der Methode service( ) ist das ServletResponse-Objekt. Im ServletResponse-Objekt werden alle Daten gekapselt, die nach Beendigung des Servlets an den Client zurückgesandt werden. Die wichtigste Methode
bei der Antworterstellung für den Client ist die Methode getWriter( ). Diese
Methode erzeugt ein Objekt vom Typ Writer, das alle Methoden zur Erstellung
der Ausgabedaten zur Verfügung stellt.
27
[RS00, S. 45]
- 46 -
„Wer beim Programmieren von Servlets alle Fäden in der Hand behalten will,
muß sich darüber im klaren sein, daß die service( )-Methode seines Servlets
unter Umständen von mehreren Threads gleichzeitig aufgerufen wird.. Es existieren also gewöhnlich weniger Servlet-Instanzen als Threads, die dieses Servlet
gleichzeitig ausführen. Tatsächlich wird ein Servlet in der Regel nur einmal
instantiiert. Das bedeutet, daß ungeschützte Klassen- und Instanzvariablen
während der Ausführung durch Thread A von Thread B verändert werden können.
Dieses Verhalten kann leicht zu inkonsistenten Zuständen führen.“28
Die Klasse HttpServlet ist eine komfortable Ausgangsbasis für Servlets, die das
Hypertext Transfer Protocol (HTTP) verwenden. Das Hypertext Transfer Protocol
ist ein textbasiertes Transferprotokoll, in dem die Anforderung von Daten bzw. ihr
Versenden mit den Protokollkommandos GET und POST möglich ist. Die Klasse
HttpServlet bietet zusätzlich zur service( ) –Methode noch die Methoden
doGet( ) und doPost( ) an. In Abhängigkeit von dem Protokollkommando, mit
dem das HttpServlet aufgerufen wird, erfolgt eine Verzweigung in der entsprechenden Methode zur Verarbeitung des Aufrufs. Beide Methoden bekommen
ein HttpServletRequest-Objekt und ein HttpServletResponse-Objekt als
Parameter mitgeliefert. Beide Objekte stellen eine Spezialisierung der allgemeinen Objekte der service( )-Methode im Hinblick auf die HTTP-Unterstützung
dar.
Eine wichtige Unterstützung, stellt das Lesen und Schreiben von Cookies dar.
„Unter Cookies versteht man kleine Informationsstücke, die der Server auf dem
Rechner des Clients ablegt. Wenn der Client eine Web-Seite bzw. ein Servlet auf
dem entsprechenden Server aufruft, dann werden die für diesen Kontext
gespeicherten Cookies an den Server mit übertragen.“29
Diese Technik ermöglicht die Erzeugung von Sitzungen (Sessions).
„Unter einer Session versteht man eine Zusammenhängende Abfolge von
Anforderungen und Antworten zwischen Client und Server. Da HTTP ein
verbindungsloses Protokoll ist, muß bei jeder Frage und Antwort eine
Identifikation mitgeschickt werden, um mehrere Anforderungen als
zusammenhängend erkennen zu können.“30
5.3.3.
Implementierung
Für die Darstellung der einzelnen Seiten wird ein Modell benutzt, das im
Folgenden Screenmodell genannt wird. Das Screenmodell unterliegt, wie die
28
[RS00, S. 51]
[EF00, S.118]
30
[RS00, S. 66]
29
- 47 -
Geschäftsobjekte auch, dem Komponentenmodell. Für jede Html-Seite die sich
von einer anderen Html-Seite in ihrer Form oder in den verwendeten Geschäftsobjekten unterscheidet, wird als eigenständige Komponente gesehen, sie werden
im Folgenden Screenobjekte genannt.
Alle Screenobjekte erben von der abstrakten Klasse Screen. Die abstrakte Klasse
Screen definiert die Schnittstelle zwischen den Screenobjekten und dem Servlet,
das die Screenobjekte benutzt. Die Klasse Screen ist als abstrakt und nicht als
Interface entworfen, da sie Grundfunktionalitäten schon implementiert hat. Alle
Screens haben denselben Html-Rumpf, deshalb kann die Ausgabe dieses HtmlRumpfes schon in der Screen-Klasse ausprogrammiert werden. Und für den Fall,
daß doch etwas im Html-Rumpf eines Screenobjektes anders ist als bei den
anderen, können die Methoden die den Html-Rumpf erzeugen, überschrieben werden.
public abstract class Screen {
public void header(Response-Objekt) { ist implementiert }
public abstract void body(Response-Objekt);
public void footer(Response-Objekt) { ist implementiert }
}
Listing 3: Beispiel für die abstrakte Klasse Screen
Durch die vorgegebene Schnittstellen in der Klasse Screen ist die Entwicklung
eines eigenen Screenobjektes sehr einfach. Es muß lediglich die Methode body
implementiert werden. Diese bekommt wie im oberen Beispiel ein Objekt mit, in
das der Htmlcode geschrieben wird. Nach der Abarbeitung der Methode doGet()
oder doPost() generiert das Servlet daraus die Antwort für den Client und sendet
diese. Damit innerhalb eines Screenobjektes aber auch Parameter abgefragt
werden können, ist es sinnvoll auch ein Request-Objekt mit zu übergeben.
Innerhalb des Servlets wird das objektorientierte Prinzip des Polymorphismus
(Vielgestaltigkeit) angewandt. Das Servlet selbst arbeitet nur mit einem Objekt
vom Typ Screen. Zur Laufzeit wird dem Objekt ein konkretes Screenobjekt zugewiesen und das Servlet kann dann die in der Klasse Screen definierten Methoden
benutzen.
...
Screen screen = null;
if ( soll ScreenA erzeugen ) { screen = new ScreenA() }
…
screen.header(Response-Objekt);
screen.body(Response-Objekt);
screen.footer(Response-Objekt);
…
- 48 -
Listing 4: Anwendung des Polymorphismus
Das erleichtert die Programmierung des Workflows erheblich. Dem Servlet wird
ein Parameter mitgeliefert, der das zu erstellende Screenobjekt eindeutig identifiziert. So ist ein Workflow als eine Kette von if-Anweisungen programmierbar.
Und jedem Link der geschrieben wird, bekommt diesen Parameter mit.
- 49 -
6. Implementierungshinweise
6.1. Programmierumgebung
Die Programmierumgebung beschreibt kurz welche notwendigen Einstellungen an
einem Computer vorgenommen werden müssen, damit die Internetanwendung,
weiterentwickelt werden kann.
6.1.1.
JDK 1.2.2
Durch die Benutzung der neuen Collection Schnittstelle, zur dynamischen
Speicherung und Verwaltung von Objekten in Listen, muß mindestens ein
JDK1.2.2 installiert sein. Diese findet man unter http://www.javasoft.com.
6.1.2.
Servlets 2.2
Eine Bibliothek für Servlets muß in den CLASSPATH mit aufgenommen werden.
Die aktuelle Bibliothek für Servlets findet man unter http://java.apache.org.
6.1.3.
Dokumentation
Zur Dokumentation von Javaklassen hat sich das im JDK befindliche javadoc als
Standard durchgesetzt. Dies hat den Vorteil, daß ein Programmierer, der sich mit
Java befasst hat, innerhalb kürzester Zeit, auf Grundlage der von javadoc
erzeugten Dokumentation, fremde Klassen benutzen kann. Javadoc bildet aus
speziell definierten Kommentaren innerhalb des Quellcodes eine HTML-Datei,
die die Informationen über Methoden und Attribute darstellt. Ein Auszug der von
javadoc erzeugten Dateien zur Implementierung befindet sich im Anhang D.
6.2. Systemumgebung
6.2.1.
Webserver
Zur Installation der Internetanwendung muß ein Webserver auf dem rechner
vorhanden sein. Prinzipiell ist jeder Server dafür geeignet, vorausgesetzt man
kann eine Servlet Engine dafür installieren. Die Fachbereichsseiten benutzen den
Tomcat v3.2, zu finden unter: http://jakarta.apache.org/
- 50 -
Der Server beinhaltet schon die Referenzimplementierung der servlets2.2 und
somit wird keine separate Servlet Engine benötigt.
6.2.2.
Servlet Engine
Eine Servlet Engine wird benötigt, um Servlets auszuführen. Sollte der Webserver
keine Servlet Engine integriert haben, dann muß einen zusätzlich installiert
werden. Tomcat3.2 kann als Servlet Engine dienen, oder das Open Source Projekt
Caucho, unter http://www.caucho.com. Es gibt aber auch kommerzielle Produkte,
wie JRun, zu finden unter http://www.jrun.com, oder ServletExec, das man unter
http://www.newatlanta.com findet.
- 51 -
7. Schlußbetrachtung
7.1. Resümee
Die Diplomarbeit zeigt, daß sich 3-Tier-Architekturen sehr gut zur Programmierung von Internetanwendungen eignen, denn die Trennung der verschiedenen
Ebenen einer Anwendung bieten die Vorteile einer hohen Skalierbarkeit und
Sicherheit. Zudem ist der Austausch der einzelnen Komponenten (Client, Anwendungsserver, Datenbank) nahezu problemlos möglich. Die einzelnen
Komponenten sind auch
Um eine Anwendung für eine 3-Tier-Architektur zu programmieren eignet sich
Java besonders, denn der Einsatz von JavaServlets unterstützt das einfache Austauschen der Komponenten einer 3-Tier-Architektur. Desweiteren sind in Java,
dadurch daß es eine recht „junge“ Programmiersprache ist, die bewährten
Konzepte, aber auch die neuen Konzepte enthalten. Dies wird gerade bei den hier
eingesetzten Techniken JDBC und JavaBeans deutlich.
Die Aufteilung der Internetanwendung in ein Schichtenmodell, hier die
Aufteilung in Präsentationsschicht, Geschäftslogik und Zugriffsschicht, unterstützt nicht nur den oben genannten Vorteil des leichteren Austauschens von
Komponenten, sondern bietet gerade in einem großen Projekt den Vorteil, daß die
jeweilige Schicht von Spezialisten implementiert werden kann. Das Implementieren einer Schicht geschieht unabhängig von dem Implementieren der anderen
Schichten. Dem Entwickler einer Schicht muß nur die Schnittstelle der darunterliegenden Schicht bekannt sein. Ein Entwickler der die Präsentationsschicht
erstellt, muß sich deshalb nicht um die Datenhaltung in den Komponenten oder
gar die Speicherung der Daten in der Datenbank kümmern. Eine einfache
Weiterentwicklung der Anwendung ist damit gegeben, denn so kann beispielsweise eine Darstellung der Daten schnell und sicher geändert werden, ohne daß
die Geschäftslogik oder die Zugriffsschicht davon betroffen sind.
Auf Basis dieser Ergebnisse läßt sich im Rahmen dieser Diplomarbeit feststellen,
daß eine Kombination aus 3-Tier-Architektur, der Umsetzung mit Java und der
Aufteilen der Anwendung in Schichten sich ideal für die Programmierung
komplexer Internetanwendungen eignet. Eine Verbesserung dieses Systems wird
im folgenden Kapitel kurz erörtert.
- 52 -
7.2. Ausblick auf aktuelle und zukünftige Entwicklungen
Die aktuellen Entwicklungen zeigen, daß Internetanwendungen von 3-TierArchitekturen mehr und mehr zu den 4-Tier-Architekturen wechseln. Es wurde
festgestellt, daß n-Tier-Architekturen eine höhere Sicherheit und Skalierbarkeit
bieten, je mehr Ebenen sie haben. Deshalb bietet eine 4-Tier-Architektur eine
noch höhere Sicherheit und Skalierbarkeit als die 3-Tier-Architektur.
Die Umsetzung von Internetanwendungen innerhalb einer 4-Tier-Architektur wird
mit Hilfe von Komponentenmodellen wie JavaBeans, Enterprise Java Beans oder
DCOM in Verbindung mit Applikationsservern realisiert. Der Vorteil, den die
Industrie zusätzlich zur Sicherheit und Skalierbarkeit im Einsatz dieser Techniken
sieht, ist die höhere Wiederverwendbarkeit von Komponenten. Durch die Verwendung von Standardkomponenten hofft man natürlich, daß diese bei der Entwicklung von mehreren Anwendungen wieder verwendet werden können. Schon
jetzt gibt es Firmen die sich auf die Entwicklung von Standardkomponenten und
deren Verkauf spezialisiert haben. Das schafft ein erhebliches Einsparungspotential durch die Verkürzung von Enwicklungszeit.
Zur Zeit werden viele Applikationsserver entwickelt und in naher Zukunft werden
sie, ähnlich den Webservern, kostengünstig und vielfältig für jeden Bedarf zur
Verfügung stehen. Ein Übergang von den 3-Tier-Architekturen zu den 4-TierArchitekturen ist deshalb schon absehbar. Und zukünftige Internetanwendungen
werden nur noch als 4-Tier-Architekturen konzipiert und umgesetzt.
- 53 -
Anhang A
Literaturverzeichnis
[B00]
Bengel, G.: Verteilte Systeme, Viewig 2000.
[B99]
Boger, :Java in verteilten Systemen, dpunkt 1999.
[DS00]
Daum, B, Scheller, M.: Electronic Business, Addison-Wesley 2000.
[EF00]
Eberhart, A., Fischer S.: Java-Bausteine für E-Commerce-Anwendungen, Hanser 2000.
[GHJV96]
Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Enwurfsmuster,
Addison-Wesley 1996.
[GT00]
Gruhn, V., Thiel, A.: Komponentenmodelle, Addison-Wesley
2000.
[K00]
Krüger, G.: GoTo Java 2, Addison-Wesley 2000.
[K97]
Kim, E.: CGI, SAMS 1997.
[M95]
Misgeld, W.: SQL Einstieg und Anwendung, Hanser 1995.
[R98]
Röhrig, B.: Datenbanken mit Linux, C & L 1998.
[RS00]
Rossbach, P., Schreiber, H.: Java Server und Servlets,
Addison-Wesley 2000.
[T00]
Trau, V.: Java Server Pages, dpunkt 2000.
[ZB00]
Zimmermann, J., Beneken G.: Verteilte Komponenten und Datenbankanbindung, Addison-Wesley 2000.
- 54 -
Anhang B
Abbildungsverzeichnis
Abbildung 1: Ablauf innerhalb des Diskussionsforums........................................13
Abbildung 2: Flache Hierarchie einer Internetseite...............................................14
Abbildung 3: Tiefe Hierarchie einer Internetseite .................................................14
Abbildung 4: Struktur des Portals..........................................................................15
Abbildung 5: Dreiteilung der Internetseite zur Strukturunterstützung ..................16
Abbildung 6: Struktur des Hauptmenüs ................................................................16
Abbildung 7: 2-Tier Architektur [EF00] ...............................................................18
Abbildung 8: 3-Tier-Architektur [EF00] ...............................................................19
Abbildung 9: 4-Tier-Architektur [EF00] ...............................................................19
Abbildung 10: Formulardaten werden versandt und verarbeitet. ..........................20
Abbildung 11: Neue Html-Seite wird generiert und zurückgesandt. ....................21
Abbildung 12: Lebenszyklus eines Servlet-Objektes ............................................24
Abbildung 13: Vergleich der serverseitigen Programmiertechniken ....................25
Abbildung 14: Java Base Platform [DS00] ...........................................................30
Abbildung 15: Vereinfachte Darstellung der Funktionsweise der
Zugriffsschicht...............................................................................................41
Abbildung 16: Chain of Responsibility .................................................................44
Listingverzeichnis
Listing 1: Entwurfsmuster Singleton .....................................................................40
Listing 2: Entwurfsmuster Finder und Factory......................................................44
Listing 3: Beispiel für die abstrakte Klasse Screen ...............................................48
Listing 4: Anwendung des Polymorphismus .........................................................49
- 55 -
Anhang C
Package informatik
- 56 -
Package informatik.db
- 57 -
Package informatik.screens
- 58 -
Anhang D
Beispiel für eine von javadoc erzeugte Dokumentation.
Overview Package Class Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
informatik.db
Class DBConnectionPool
java.lang.Object
|
+--informatik.db.DBConnectionPool
public class DBConnectionPool
extends java.lang.Object
Die Klasse DBConnectionPool sorgt für den korrekten Zugriff auf die lesenden
Connections zur Datenbank.
Method Summary
void close(java.sql.Connection con)
Die Methode close schließt eine Connection und
legt sie in den Pool zurück, sofern nicht die Anzahl
von 10 Connections erreicht ist.
void destroy()
Schließt automatisch den Pool, wenn der
Garbage Collector aufräumt und die das Objekt
zerstören will
java.sql.Connection getConnection()
Diese Methode liefert eine Connection aus dem
Pool, wenn gerade eine frei ist, im anderen Fall wird
eine neue angelegt.
static DBConnectionPool getDBConnectionPool()
Singleton,
damit
es
nur
einen
DBConnectionPool gibt, auf den jeder zugreift. mit
default-Werten
static DBConnectionPool getDBConnectionPool(java.lang.String driver,
java.lang.String url, java.lang.String uid,
java.lang.String pwd)
Singleton,
damit
es
nur
einen
DBConnectionPool gibt, auf den jeder zugreift.
- 59 -
java.sql.Connection getWriteConnection()
Diese Methode liefert eine Connection aus dem
Pool, wenn gerade eine frei ist, im anderen Fall wird
eine neue angelegt.
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll,
toString, wait, wait, wait
Method Detail
getDBConnectionPool
public static DBConnectionPool
getDBConnectionPool(java.lang.String driver,
java.lang.String url,
java.lang.String uid,
java.lang.String pwd)
throws
java.lang.ClassNotFoundException
Singleton, damit es nur einen DBConnectionPool gibt, auf den jeder
zugreift.
getDBConnectionPool
public static DBConnectionPool getDBConnectionPool()
Singleton, damit es nur einen DBConnectionPool gibt, auf den jeder
zugreift. mit default-Werten
getConnection
public java.sql.Connection getConnection()
throws java.sql.SQLException
Diese Methode liefert eine Connection aus dem Pool, wenn gerade eine
frei ist, im anderen Fall wird eine neue angelegt.
getWriteConnection
public java.sql.Connection getWriteConnection()
throws
java.sql.SQLException
Diese Methode liefert eine Connection aus dem Pool, wenn gerade eine
frei ist, im anderen Fall wird eine neue angelegt.
close
- 60 -
public void close(java.sql.Connection con)
Die Methode close schließt eine Connection und legt sie in den Pool
zurück, sofern nicht die Anzahl von 10 Connections erreicht ist.
destroy
public void destroy()
Schließt automatisch den Pool, wenn der Garbage Collector aufräumt und
die das Objekt zerstören will
Overview Package Class Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
NO FRAMES
- 61 -