Aspekte moderner Web-Applikationen - Das IICM

Transcription

Technische Universität Graz
Institut für Informationsverarbeitung und
Computergestützte neue Medien
Diplomarbeit
aus Telematik
Aspekte moderner
Web-Applikationen
Gegenwärtige Technologien und Server im
Überblick, sowie in der Praxis
Georg Wurzenberger
[email protected]
Graz, März 2000
Betreuer: Dipl.-Ing. Harald Krottmaier
Begutachter: O. Univ.-Prof. Dr .phil. Dr. h.c. Hermann Maurer
Meinen Eltern, Roswitha und Johann Wurzenberger, meinem Bruder Johann,
meiner Schwester Maria und meiner Freundin Claudia.
Kurzfassung
Die derzeit stark steigende Verbreitung von Web-basierenden Applikationen – kurz WebApplikationen – im Bereich des Inter- und Intranet bringt zwei Entwicklungen zum Ausdruck: Einerseits die Abkehr vom herkömmlichen Client/Server-Modell und andererseits
einen Wechsel im Benutzungsverhalten von Software. Der Web-Browser als Thin-Client
verdrängt zunehmend spezialisierte Client-Software und etabliert sich nebenbei als bevorzugtes User-Interface des Anwenders. Der momentane Hype um E-Commerce und
E-Business unterstützt diese Entwicklung noch zusätzlich.
Mit vergleichbarer Geschwindigkeit verändert sich das Angebot vorhandener ServerSoftware, die als Plattform für Web-Applikationen in Frage kommt. Gleiches gilt für die
Vielzahl unterstützter Web-Technologien, die sehr stark in ihrer gebotenen Leistungsfähigkeit zu differenzieren sind. Eine One-size-fits-all“ Lösung bleibt daher auch Web”
Applikationen a priori verwehrt.
In der vorliegenden Arbeit wird die Bandbreite erhältlicher Server-Software gesichtet,
nach definierten Sparten geordnet und auf ihre Funktionalität hin untersucht. In der
Folge werden die Anwendungsmöglichkeiten der zur Zeit populärsten Web-Technologien
mit praktischen Beispielen schwerpunktmäßig diskutiert. Dabei werden vor allem die
Kommunikationsschnittstellen zu externen Datenbanken bewertet. Anschließend werden
der Hyperwave Information Server und der Apache HTTP Server, aus der Perspektive
des Applikationsentwicklers auf ihre programmtechnischen Möglichkeiten durchleuchtet.
Details einer für den kommerziellen Bereich implementierten Web-Applikation illustrieren im Folgenden die Programmierschnittstellen des Hyperwave Information Servers.
Schlußfolgerungen aus der theoretischen Untersuchung und der praktischen Umsetzung
beschließen diese Arbeit.
3
Abstract
We live in the age of the internet, which influences to an increasing extent our daily lives
and society as a whole. We need not go shopping to the grocery any longer, we just
do a mouse click and buy everything via the internet. This is what we understand by
e-commerce. But what is this hype all about? Which technologies and standards are
needed to set up things like e-shops? This thesis will discuss all these topics.
At the centre of these considerations are general issues in web-applications, which are the
technical basis for all e“-related matters at present. Starting from a general overview
”
of the existing server market and its segmentation in special types some selected webtechnologies are examined and tested for their database connectivity. The Hyperwave
Information Server and the Apache HTTP Server, two conceptionally completely different servers, are discussed in greater detail in terms of their programming techniques. In
addition, implementation aspects of the Hyperwave-based web application CO2, which
is used as an online content and helping system are described. The section of conclusions
from the theoretical and practical work performed for this thesis, closes with a general
outlook on future developments.
4
Danksagung
Ich danke den Mitarbeitern des IICM um Professor Hermann Maurer für ihre stets
sehr freundliche und tatkräftige Unterstützung in der Zeit meiner aktiven Projektmitarbeit am Institut. Besonderer Dank gebührt dabei Harald Krottmaier und Helmut
Leitner, mit denen ich bei zwei Projekten zusammenarbeiten durfte und von deren
Wissen ich sehr profitieren konnte. Dank gilt auch dem Institut für AMFT, das mir für
die Zeitdauer meiner Diplomarbeit einen Arbeitsplatz zur Verfügung gestellt hat und
mit Christian Meisl für den LATEX-Support sorgte.
Meinen Eltern, Roswitha und Johann Wurzenberger, möchte ich an dieser Stelle
für ihre Liebe und finanzielle Unterstützung während des gesamten Studiums meinen
innigsten Dank aussprechen. Derselbe Dank gilt auch meinem Zwillingsbruder Johann,
von dessen Erfahrungen im wissenschaftlichen Publizieren ich sehr profitieren konnte.
Leider habe ich unseren internen Wettkampf um die schnellere Studienzeit verloren. Das
nehme ich aber mit Würde und Gelassenheit, denn ich weiß ja, wer der bessere von uns
beiden ist . Bei meiner interaktiven Rechtschreibkorrektur namens Birgit Färber bedanke ich mich herzlich für ihre sorgfältige Arbeit. Schließlich und endlich bedanke ich
mich bei meiner Freundin Claudia Holzer, die mich im Laufe dieser Arbeit sehr oft
entbehren musste.
5
Ich versichere hiermit, diese Arbeit selbstständig verfaßt, andere als die angegebenen
Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel
bedient zu haben.
Unterschrift des Autors: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aspekte moderner Web-Applikationen
Gegenwärtige Technologien und Server im Überblick,
sowie in der Praxis
© Georg Wurzenberger , Graz im März 2000.
a
Diese Arbeit wurde unter Linux mit dem Schriftsatzsystem LATEX erstellt, das sich dabei als sehr ausgereiftes Werkzeug zur Erzeugung qualitativ hochwertiger PDF-Dokumente erwiesen hat. Sämtliche nicht
referenzierte Abbildungen wurden mit GIMP oder xfig erstellt. Abbildung 2.8 und 4.3 wurden mit dem
Einverständnis von Stefano Mazzocchi eingebunden. Verschiedene Formate dieser Arbeit sind unter der
Adresse ftp://www.amft.tu-graz.ac.at/pub/documents/gwurze/da zu finden.
a
[email protected]
6
Inhaltsverzeichnis
1 Einleitung
10
1.1
Vorausgehende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2
Kapitelübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Web-Applikationen
2.1
2.2
2.3
15
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2
Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3
Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.4
Anwendungsbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1
Server Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2
Web-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3
Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4
Information Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Web-Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1
SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2
CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.3
FastCGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.4
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.5
Server-Side JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.6
Java Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.7
JavaServer Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7
Inhaltsverzeichnis
Inhaltsverzeichnis
3 Hyperwave Information Server
3.1
3.2
60
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.1.1
Entstehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.1.2
Design Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.3
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1.4
Server Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.1.5
Unterstützte Plattformen . . . . . . . . . . . . . . . . . . . . . . . 70
3.1.6
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.1.7
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.1
PLACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.2
JavaScript Object Model . . . . . . . . . . . . . . . . . . . . . . . 75
3.2.3
Document Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4 Apache HTTP Server
4.1
4.2
81
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.1
Ziele des Apache Server Project . . . . . . . . . . . . . . . . . . . . 82
4.1.2
Entstehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.3
Unterstützte Plattformen . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.4
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1.5
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.1
mod include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2
mod perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2.3
mod php3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.4
mod jserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5 Projekt CO2
5.1
5.2
95
Allgemeiner Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.1
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.2
Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.3
Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.4
Programmieraufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 98
hwlib - Eine Objektbibliothek . . . . . . . . . . . . . . . . . . . . . . . . . 99
8
Inhaltsverzeichnis
5.3
5.4
Inhaltsverzeichnis
5.2.1
Objektorientierte Programmierung mit JavaScript . . . . . . . . . 99
5.2.2
Funktionalität im Überblick . . . . . . . . . . . . . . . . . . . . . . 101
5.2.3
Objekt-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Struktur und Requestabarbeitung . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.1
File-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3.2
CO2-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3.3
Requestabarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Anmerkungen zum Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.4.1
Probleme während des Projektverlaufes . . . . . . . . . . . . . . . 110
5.4.2
Derzeitiger Projektstatus . . . . . . . . . . . . . . . . . . . . . . . 111
6 Schlußfolgerungen
112
6.1
Schlußfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Abkürzungen
118
Listings
122
Literaturverzeichnis
123
A Attribute der perfekten Web-Applikation
129
B e-Manie
130
9
1 Einleitung
Web applications arent’t for me.
What about you? a .
Jim Seymour
a
Ready for Web Apps? [Seymour, 1999a].
Wir leben im Zeitalter des Internet, das gegenwärtig mit größter Vehemenz die etablierten Regeln der Gesellschaft und Marktwirtschaft neu definiert. Freunde ruft man
beispielsweise nicht mehr an, sondern trifft sie im Chat. Parkplatzsuche und Warteschlangenfrust beim Einkaufen sind passé, seit Einkaufskörbe nicht nur wie gewohnt aus
Metall, sondern auch virtuell sind. Das Internet macht es möglich: Einfach und schnell.
Das World Wide Web – kurz Web –, als populärster Teil des Internet, unterstützt
wesentlich mit dem momentanen Hype um e-Commerce und e-Business diesen Veränderungsprozess. Die web-zentrierte Ansicht von Problemen drängt sich in diesem Kontext
verstärkt in den Mittelpunkt der Software-Entwicklung. Web-basierende Anwendungen –
kurz Web-Applikationen – liegen voll im Trend und kämpfen offensiv um den Markt gewohnter Desktop-Anwendungen, die dadurch völlig verschwinden könnten [Berst, 1998].
Das Konzept des Webtop als Ersatz des langgedienten Desktop nimmt immer realere Formen an [BusinessWire, 2000] und verlagert dabei die Applikationslogik wieder in
Richtung eines leistungsstarken Server (Fat-Server). In nostalgischer Verwandtschaft zur
Zeit vor dem Durchbruch des Client/Server-Modells werden Thin-Clients aufgrund der
zu erwartenden niedrigeren Kosten und des niedrigeren Wartungsaufwandes [Rice, 1999]
als Lösung auf der Client-Seite propagiert.
Kostenlose Internet Services sind der erste Schritt in diese Richtung und sie erfahren
bereits sehr großen Zuspruch von der Anwendergemeinde. Technisch gesehen handelt es
sich dabei um spezielle Web-Applikationen, die bereits jetzt teilweise dasselbe Leistungs-
10
1 EINLEITUNG
spektrum besitzen, wie ihre Vorbilder am Desktop. In diesem Zusammenhang gehört
die breite Masse web-basierender E-Mail Dienste zur bekanntesten Gruppe unentgeltlicher Internet Services. Einen groben Überblick, inwieweit Desktop-Anwendungen schon
durch äquivalente Web-Applikation realisiert wurden, vermittelt die folgende Auflistung
bekannter Internet Services mit jeweils einer Beispielsreferenz:
• E-Mail: www.hotmail.com
• Terminplaner: www.when.com
• Landkarten: www.mapquest.com
• Virtueller Desktop: www.desktop.com
• Speicherung von Daten: www.docspace.com
• Office Anwendungen: www.thinkfree.com
Bei den angeführten Internet Services handelt es sich ausschließlich um freie über das
Web angebotene Dienste, die oft sehr große Anforderungen an die Server-Software stellen und als Web-Applikation dieselbe Komplexität erreichen, wie die entsprechenden
Desktop-Anwendungen.
Neben dem Internet bildet das Intranet den zweiten großen Anwendungsbereich
für Web-Applikationen. Im einen Fall versuchen Unternehmungen immer häufiger ihre
Schwierigkeiten, die durch historisch gewachsene Applikationslandschaften im Intranet
auftreten, mit Web-Applikationen in den Griff zu bekommen. Im anderen Fall wollen
Unternehmen ihre erfolgreich im Intranet laufenden Applikationen schlicht web-fähig“
”
machen und den dabei entstehenden Vorteil der einfacheren Wartung genießen. In der
Tat ist die momentan verfügbare Server-Software gerade für die Verbindung heterogener
Applikationsstrukturen gerüstet, was durch die breite Unterstützung vorhandener WebTechnologien, verteilter Objektsysteme, Datenübertragungsprotokolle und verschiedenster Datenbanken bewiesen wird. Abschließend soll noch bemerkt werden, dass WebApplikationen den Vorteil genießen, momentan einfach in Mode zu sein.
Ziel der Arbeit:
Motiviert durch die beschriebene gegenwärtige Situation, versucht die vorliegende Arbeit
einen möglichst breiten, praxisorientierten und verständlichen Überblick des technischen
11
1 EINLEITUNG
1.1 VORAUSGEHENDE BEMERKUNGEN
Umfeldes moderner web-basierender Applikationen zu geben. Der Überblick soll dabei
folgende Punkte umfassen:
• Analyse des Spektrums verfügbarer Server-Software.
• Bewertung einiger ausgesuchter Web-Technologien.
• Untersuchung zweier konzeptionell unterschiedlicher Server.
• Detail-Aspekte einer realisierten Web-Applikation.
Im Schwerpunkt soll in den angeführten Punkten auf praxisbezogene Problemstellungen
Bezug genommen werden. Auftretende Schwierigkeiten, sowie Stärken und Schwächen
der jeweils untersuchten Technologie sollen dokumentiert werden und als Grundlage für
eine Bewertung dienen. Ein Resumee, der aus der Untersuchung und praktischen Arbeit
gewonnenen Erkenntnisse soll zusammen mit einem Ausblick zu erwartender Entwicklungen diese Arbeit beschließen.
Persönliche Faszination der Thematik:
Dadurch, dass in Web-Applikation die verschiedensten Programmiersprachen, Übertragungsprotokolle, Sicherheitstechniken und Web-Technologien kooperieren, bedarf es an
fundiertem Wissen der einzelnen Komponenten und an viel praktischer Erfahrung, um
an der möglichen Komplexität dieser Applikationsform nicht zu scheitern. Die Herausforderung, die sich einem dabei stellt, ist der Punkt, der mich persönlich am meisten
fasziniert.
1.1
Vorausgehende Bemerkungen
Begriffswelt:
Die deutschsprachige Begriffswelt der Telekommunikation (TK) und Informationstechnologie (IT) orientiert sich sehr stark an den äquivalenten englischen Begriffen. Aufgrund
der rasanten Entwicklung im Bereich der TK und IT ist die Rechtschreibung vieler neuer
Begriffe im Deutschen noch nicht geklärt. Soweit der DUDEN bereits eine genaue Rechtschreibung für ein verwendetes Wort vorsieht, wird sie in dieser Arbeit berücksichtigt. Im
Zweifelsfall wird auf die englischsprachige Form des Wortes eins-zu-eins zurückgegriffen,
wie etwa beim Begriff Application Server. Persönlich vertrete ich die Meinung, dass die
12
1 EINLEITUNG
1.2 KAPITELÜBERSICHT
englischsprachigen Begriffe ohne langwierige Diskussion und ohne spezielle Anpassung
an die deutsche Sprache übernommen werden sollten, da sie die Sache naturgemäß vom
Ursprung her besser beschreiben.
Pragmatischer Ansatz:
Diese Arbeit versucht sehr sachbezogen an die diskutierten Themen heranzugehen und
persönlich gemachte Erfahrungen aus der praktischen Umsetzung einzubringen. Die
zahlreichen Listings mit Programmbeispielen sollen dabei den praxisbezogenen Zugang
zur Thematik verstärken. Im Falle der theoretischen Untersuchung werden, wo es möglich war, die Dokument-Adressen zitierter Autoren und Verweise auf allgemeine Informationsquellen angegeben. Die Leser der PDF1 -Version dieser Arbeit kommen in den
zusätzlichen Genuß, gewohnter Hyperlinks und eines mit PDF-Bookmarks realisierten
Inhaltsverzeichnisses.
Voraussetzungen:
Der Kommentar zu den abgedruckten Listings behandelt immer die wesentlichen Punkte
der diskutierten Problemstellung und nimmt keinen Bezug auf allgemeine Eigenschaften
der eingesetzten Programmiersprache. Somit setzt diese Arbeit ein grundsätzliches Verständnis der Programmentwicklung und Kenntnisse in zahlreichen Programmiersprachen
voraus. Zu den Sprachen zählen etwa Java, Perl, JavaScript und HTML.
1.2
Kapitelübersicht
• Kapitel 2, Web-Applikationen: Ausgehend von den generellen Anforderungen an
Web-Applikationen werden die Vor- und Nachteile dieser speziellen Applikationsform erläutert. Die breite Masse vorhandener Server-Software, die als Fundament
von Web-Applikationen zu sehen ist, wird nach Server-Segmenten – Web-Server,
Application Server, Information Server – getrennt, auf allgemeine Leistungsparameter und unterstützte Web-Technologien untersucht. Anschließend werden die
derzeit verbreitetsten Web-Technologien im Einzelnen beschrieben. Die Bewertung vorhandener Werkzeuge zur Kooperation mit Datenbanken bildet dabei den
Schwerpunkt der Diskussion.
• Kapitel 3, Hyperwave Information Server : Im Eingang beschreibt dieses Kapitel
1
Portable Document Format entwickelt von Adobe Systems http://www.adobe.com.
13
1 EINLEITUNG
1.2 KAPITELÜBERSICHT
den allgemeinen Funktionsumfang des Hyperwave Information Servers und seine
schon beinahe historische Entstehungsgeschichte. In der Folge werden die vorhandenen Programmierschnittstellen des Servers detailliert erklärt und nach für WebApplikationen relevanten Kriterien wie Performance und praktischer Verwendbarkeit bewertet.
• Kapitel 4, Apache HTTP Server : Analog zu Kapitel 2 wird eingangs der Apache
HTTP Server im Überblick dem Leser vorgestellt. Aspekte der Installation und
Konfiguration des Servers aus praktischer Sicht werden ebenso beschrieben, wie die
Ziele des Apache Server Projekts. Die Untersuchung und Diskussion der für WebApplikationen interessanten Module des Apache Servers schließen dieses Kapitel.
• Kapitel 5, CO2: Details einer Web-Applikation auf Basis des HWIS : Dieses Kapitel befasst sich mit konkreten Implementationsdetails einer im Rahmen eines
IICM-Projekts entstandenen Web-Applikation auf Basis des Hyperwave Information Servers. Ausgehend von der allgemeinen Applikationsstruktur wird der technische Ablauf vom Request zur HTML-Seite im Schwerpunkt beschrieben.
• Kapitel 6, Schlußfolgerungen und Ausblick: Das letzte Kapitel, versucht aus den
gewonnenen Ergebnissen der theoretischen Untersuchung und der praktischen Arbeit für die Entwicklung von Web-Applikationen relevante Schlußfolgerungen zu
ziehen. Mögliche zukünftige Entwicklungstendenzen von Web-Applikation bilden
den Abschluss dieser Arbeit.
• Anhang A, Attribute der perfekten Web-Applikation: Hersteller von Server-Software versehen gerne ihre Produkte und die darauf aufbauenden Web-Applikationen
mit speziellen Attributen. Dabei treten gewisse typische Begriffe (erweiterbar,
robust, etc.) recht häufig in den White Papers unterschiedlicher Hersteller auf.
Dieser Anhang listet die in der Untersuchungsphase gefundenen Attribute für WebApplikationen gesammelt auf.
• Anhang B, e-Manie: Ähnlich wie in Anhang A wurde im Zuge der InternetRecherche zu dieser Arbeit eine Unmenge von e“-Begriffen (zum Beispiel: e-Com”
merce, e-Business, etc.) gefunden. Dieser Anhang beinhaltet eine Auflistung der
gefundenen Begriffe mit teilweiser Beschreibung ihrer Bedeutung.
14
2 Web-Applikationen
So we hear desperate cries for a silver bullet – something to make software costs drop
as rapidly as computer hardware costs doa .
Frederick P. Brooks
a
No Silver Bullet [Brooks, 1986].
Die Applikation betrat die Bühne des World Wide Web und der Terminus Web-Applikation war geboren. So oder ähnlich dramaturgisch könnte man es sehen. Faktum ist,
dass Web-Applikationen beinahe in alle Bereiche herkömmlicher Software vorgedrungen
sind und immer häufiger in Unternehmen Schlüsselpositionen einnehmen – man denke
nur an den derzeit herrschenden Hype um E-Business und E-Commerce. Dem zum
Trotz können keine wirklichen Aussagen gefunden werden, was eigentlich Web-Applikationen sind und welche Vor- und Nachteile sie mitbringen. Dieses Kapitel versucht
in Abschnitt 2.1 diese grundlegenden Fragen auf Basis fundierter Recherche zu klären. Abschnitt 2.2 widmet sich der vorhandenen Server-Software und untersucht die
verschiedenen Segmente im Detail. Abschließend werden in Abschnitt 2.3 verschiedene Web-Technologien – Bausteine jeder Web-Applikation – auf ihre Leistungsfähigkeit
hinsichtlich einer Datenbank-Anbindung geprüft.
2.1
Grundlagen
Nichts gestaltet sich schwieriger als die genaue Definiton des Begriffes Web-Applikation, obwohl dieser zur Zeit in aller Munde ist. Kein einzelnes Phänomen der InternetGesellschaft, in der man nichts lieber tut, als sich mit Abkürzungen zu verständigen, die
15
2 WEB-APPLIKATIONEN
2.1 GRUNDLAGEN
man dabei selbst tagtäglich neu erfindet. Hätten wir nun ein Dutzend Web-Experten zur
Verfügung, könnten wir sie mit der Definition des Begriffes beauftragen. Die erhaltenen
Definitionen untersuchen wir dann auf Gemeinsamkeiten, um eine allgemeine Definition
daraus abzuleiten. Leider haben wir diese Resourcen nicht und probieren den modernen
Weg der Internet-Recherche, doch auch in den diversen Wörterbüchern [Networds, 2000;
Wĕbopēdia, 2000] für Internet-Begriffe fehlt jeweils ein Eintrag für Web-Applikation“.
”
Ein Leiden, das allen Newcomer-Begriffen“ des Internets gemein ist.
”
Der einfachere und einzig zielführende Weg ist die wörtliche Übersetzung aus dem
Englischen. Eine Web-Applikation ist demnach nichts anderes als eine auf das Internet
– im engeren Sinne auf das World Wide Web – basierende1 Anwendungs-Software. Damit ist eigentlich das Wesentliche gesagt. Welche konkreten Web-Technologien nun die
Web-Applikation in ihrer Implementation verwendet, ist aus diesem Blickwinkel völlig
belanglos.
Dennoch wollen wir um das allgemeine Verständnis zu erhöhen, den Versuch unternehmen, Web-Applikationen anhand von typischen Merkmalen näher zu charakterisieren. In Abschnitt 2.1.1 werden wir diese Merkmale als Anforderungen bezeichnen. Aus
diesen Anforderungen lassen sich ganz spezifische Vor- und Nachteile einer Web-Applikation ableiten, die in den Abschnitten 2.1.2 und 2.1.3 Erwähnung finden. Abschließend
werden in Abschnitt 2.1.4 die derzeit wichtigsten Anwendungsbeispiele für Web-Applikationen angeführt.
2.1.1
Anforderungen
Welche Eigenschaften machen eine herkömmliche Applikation zur Web-Applikation? Die
Beantwortung dieser Frage erweist sich nach genauerer Überlegung als nicht ganz trivial,
da einige Eigenschaften auch einer gewöhnlichen Applikation zugesprochen werden können. Aus diesem Grund versuchen wir die Antwort mit einem pragmatischerem Ansatz
zu bekommen. Das geschieht durch Festlegung der Anforderungen einer Web-Applikation rein vom allgemein technischen Standpunkt gesehen, also ohne spezielle Vorgaben
an die Funktionalität. Die dabei gefundenen Anforderungen bilden die Basis jeder WebApplikation und sind demnach implizit typische Eigenschaften dafür. Anforderungen
(Requirements) an Software – eine Web-Applikation ist zweifellos ein Stück Software –
werden immer in zwingende und optionale Anforderungen gegliedert. Zwingende Anfor1
Im Englischen ist Web Application eine Kurzform für Web-based Application, beides meint dasselbe.
16
2 WEB-APPLIKATIONEN
2.1 GRUNDLAGEN
derungen müssen in jedem Fall von einer Applikation erfüllt werden, um als Web-Applikation zu gelten. Die aufgelisteten optionalen Anforderungen werden in Summe von den
meisten Web-Applikationen zusätzlich erfüllt, sind aber nicht verbindlich.
Zwingende Anforderungen:
• Das Web, Kurzform von World Wide Web 2 dient als primäre Plattform der WebApplikation.
• Eine Web-Applikation ist im Inter- oder Intranet situiert.
• Der Web-Browser dient als alleiniges User-Interface.
• Eine Web-Applikation erzeugt Web-Seiten, die von einem Web-Broswer dargestellt
werden.
• Abhängig von Benutzereingaben oder überhaupt generell werden die Web-Seiten
dynamisch erzeugt.
• Die Sprache der Web-Seiten ist HTML3 oder XML4 .
• Eine Web-Applikation besitzt immer eine interaktive Komponente, die durch Formulare oder Applets5 erreicht wird.
• Die Web-Applikation überprüft die Eingaben des Users auf Korrektheit und verarbeitet sie. Zum Beispiel können Daten in einer Datenbank gespeichert werden.
• Die eigentliche Web-Applikation nutzt die Programmiermöglichkeiten eines WebServers oder Application Servers und wird auch von diesen beherbergt.
Optionale Anforderungen:
• Session-Management wird von der Web-Applikation realisiert.
• Die Web-Applikation interagiert mit einer Datenbank.
2
Das WWW ist der auf dem Hypertext Transfer Protocol (HTTP) basierende Teil des Internet.
HyperText Markup Language, siehe [W3C, 1999].
4
eXtensible Markup Language, siehe http://www.w3.org/XML.
5
Ein kleines Programm, dass innerhalb einer anderen Applikation ausgeführt wird, zum Beispiel ein
Java-Applet innerhalb eines Web-Browsers.
3
17
2 WEB-APPLIKATIONEN
2.1 GRUNDLAGEN
• Ein Sicherheitskonzept (Identifizierungsmechanismus, sichere Verbindungen) wird
von der Web-Applikation implementiert.
• Für die Web-Seiten Erstellung werden Templates verwendet, dessen Platzhalter
individuell gefüllt werden.
• Web-Applikationen arbeiten häufig mit Mail-Systemen zusammen.
• Die Web-Applikation fügt sich in vorhandene Infrastruktur6 ein.
• Web-Applikationen können Workflows anstossen.
Die Liste der optionalen Anforderungen kann fast beliebig erweitert werden, sieht man
etwa nur auf die Vielzahl vorhandener offener und proprietärer Web-Technologien (Abschnitt 2.3 behandelt einige ausgewählte Beispiele). Auch der Katalog der zwingenden
Anforderungen kann nicht als vollständig angesehen werden, soll aber verdeutlichen,
dass manche Leute gar nicht wissen, welche typische Eigenschaften Web-Applikationen
eigentlich ausmachen.
2.1.2
Vorteile
Aus den Anforderungen des letzten Abschnittes lassen sich zahlreiche Vorteile von WebApplikationen gegenüber herkömmlichen Client-Server-Applikationen ableiten. Gerade
diese Vorteile motivieren derzeit Unternehmen, auch ihre internen Applikationen zunehmend auf Web-Basis zu stellen, um à la longue vom verminderten Wartungsaufwand und
damit geringeren Kosten zu profitieren. Konkret zu den Vorteilen:
1. Web-Applikationen sind plattform-unabhängig. Das Vorhandensein eines WebBrowsers ist die einzige Voraussetzung auf der Client-Seite.
2. Die Web-Applikation läuft zentral auf einem oder mehreren Servern. Upgrades
finden rein hier statt, der Client bleibt dabei unbetroffen. Es entfällt das mühselige
Upgrade oft unzähliger Clients.
3. Die Web-Applikation übernimmt die ganze Applikations-Logik. Der Client kümmert sich rein um die Darstellung und findet daher auch mit weniger performanter
Hardware das Auslangen (Thin-Client).
6
File-Server, Web-Server, Verzeichnis-Dienste oder Datenbanken.
18
2 WEB-APPLIKATIONEN
2.1 GRUNDLAGEN
4. Bei entsprechenden Authorisierungs-Mechanismen und sicheren Verbindungen (Verschlüsselung der Daten-Pakete) kann die Web-Applikation weltweit eingesetzt werden.
5. Die vertraute Web-Browser-Oberfläche erleichtert dem Anwender das Erlernen der
Benutzerführung.
6. Die für Web-Applikationen benötigten Server-Produkte werden zunehmend leistungsfähiger und ausgereifter.
7. Web-Applikationen verwenden oft globale und weitverbreitete Internet-Standards,
die den meisten Entwicklern bereits vertraut sind. Damit verkürzt sich in vielen
Fällen die Entwicklungszeit.
8. Bei gezieltem und durchdachtem Einsatz ergeben sich in Summe geringere Kosten.
2.1.3
Nachteile
Kein Vorteil ohne Nachteil. Diese alte Weisheit bewahrheitet sich auch nach der Betrachtung der Vorteile von Web-Applikationen:
1. Web-Applikationen brauchen akzeptable Antwortzeiten (Response Times). Da jeder Page View“ dynamisch erzeugt wird und beim Aufbau der Seite oft Daten
”
von anderen Systemen benötigt werden, kann das zu vehementen Verzögerungen
führen. Bei 10 Sekunden liegt die Obergrenze, um die Aufmerksamkeit des Users
nicht zu verlieren [Nielsen, 2000a]. Die Architektur der Web-Applikation ist dabei
häufig entscheidender, als die Performance des Servers. Die Antwortzeit ist das
wichtigste Kriterium der Web-Applikation!
2. Web-Applikationen sind kein Allheilmittel“. Nicht jeder Anwendungsbereich ist
”
für Web-Applikationen geeignet.
3. Die im Internet verwendeten Standards sind teilweise noch extrem kurzlebig. Es ist
eine sprichwörtliche Gradwanderung, einerseits web-technologisch am Laufenden
”
zu bleiben“ und andererseits nicht Zeit und Geld mit unausgereiften Technologien
zu vergeuden.
4. Bei nachlässiger Programmierung können gravierende Sicherheitslöcher entstehen,
die potentielle Ziele für Angreifer sind.
19
2 WEB-APPLIKATIONEN
2.1.4
2.2 SERVER SOFTWARE
Anwendungsbereiche
Die unten angeführte Liste gibt die derzeit bekanntesten Anwendungsbereiche von WebApplikationen wieder. Die dabei verwendeten Begriffe assoziieren häufig sehr große Systeme, die zum Teil mit herkömmlichen Client-Server-Applikationen bereits realisiert
wurden, wie Help Systems“, und zum Teil nur als Web-Applikation überhaupt realiser”
bar sind, wie E-Commerce“ Systeme. Da sich diese Begriffe ausschließlich im englisch”
sprachigem Raum entwickelt haben, sind sie hier auch nur im Englischen angeführt:
• Document Management
• Frontend for Corporate Databases
• Knowledge Management
• Managing Inventory
• Business and News Portals
• Web-based Training
• E-Commerce, E-Business
• Help Systems
• Customer Support Systems
• Supply Chain Management
• Large Web Sites
• Groupware
2.2
Server Software
Nach den in Abschnitt 2.1.1 definierten Anforderungen an eine Web-Applikation, wird
für deren Realisierung eine entsprechende Plattform benötigt, die naturgemäß von einem
Server7 zur Verfügung gestellt wird. Plattform bedeutet in diesem Fall ein passendes
API8 oder dazu alternative Programmierschnittstellen des Servers. Diese Schnittstellen
werden in Abschnitt 2.3 als Web-Technologien bezeichnet und dort genauer untersucht.
Das stetig reicher werdende Angebot an erhältlicher Server-Software, verkompliziert
die Auswahl eines für die Web-Applikation am geeignetsten Servers noch zusätzlich. Die
primäre Entscheidungsgrundlage bildet der Anforderungs-Katalog an die Web-Applikation. Dieser enthält indirekt sehr viele Punkte, die vorrangig die Funktionalität des
Servers betreffen, wie zum Beispiel Sicherheit oder Last-Verteilung. Dennoch kann man
7
8
Hier ist die Server-Applikation im informatischen Sinn gemeint, nicht ein Rechner.
Application Program Interface
20
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
auch konkrete Anforderungen an den Server selbst stellen, dabei können die folgenden
Punkte ausgemacht werden:
• Web-Basisfunktionalität
• Erweiterbarkeit/Skalierbarkeit
1. HTTP 1.0/1.19
• Performance (Throughput, Response
Times)
2. Konfigurationsmöglichkeit
• Programmier-Schnittstellen,
• Sicherheit/Zuverlässigkeit
siehe dazu die in Abschnitt 2.3 ange• Management Tools
gebenen Technologien.
• Entwicklungsumgebung
• Dokumentation
• Modularität
• Kosten
Im Punkt Web-Basisfunktionalität wird festgelegt, dass ab diesem Zeitpunkt jeder Ser”
ver“ in dieser Arbeit indirekt ein HTTP-Server ist. Immer wichtiger werden auch
Erweiter- und Skalierbarkeit als Anforderung in der heutigen Zeit, da sich vorhandene Auslastungs-Muster“ über Nacht sprunghaft – und leider unvorhersehbar – ändern
”
können [Baum, 1999]. Um das Design oder die Architektur einer Web-Applikation skalierbar zu machen, muss vor allem der Server skalierbar sein und die entsprechenden
Mechanismen dafür bereitstellen.
Zu den von der Software zu erfüllenden technischen Anforderungen, kommen auch
wirtschaftliche Belange, nämlich die Kosten, die ein bestimmtes Budget nicht überschreiten sollten. Das kann bei gewissen Enterprise-Servern, zum Beispiel einem iPlanet (Netscape) Application Server mit 35.000$, eine durchaus strategische Entscheidung werden,
die eher von der Management- als der Technischen-Ebene getroffen wird.
Um in die Server-Landschaft“ etwas mehr Ordnung zu bringen, versuchen Hersteller
”
ihre Server einer gewissen Kategorie zuzuordnen, mit der man gleichzeitig eine bestimmte
Funktionalität verbinden soll. Der Nachteil liegt dabei in der verschiedenen Interpretation, bzw. Definition dieser vergebenen Labels und führt manchmal zu echter Verwirrung.
Die am häufigsten zu findenden Prädikate sind:
1. Web-Server
9
HyperText Markup Language [Berners-Lee et al., 1996; Fielding et al., 1999]
21
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
2. Application Server
3. Information Server
In den Abschnitten 2.2.2–2.2.4 wird versucht, diese Kategorien anhand ihrer typischen
Funktionalität im Einzelnen zu spezifizieren und dabei untereinander – sofern überhaupt
möglich – Grenzen zu ziehen. Unterscheidungskriterien sind primär implementierte Technologien und Standards der jeweiligen Server-Segmente. Das Hauptaugenmerk liegt
dabei im allgemeinen Überblick der vorhandenen Produkte und im Speziellen in der Leistungsfähigkeit dieser, in Hinblick auf darauf aufbauende Web-Applikationen.
Abschnitt 2.2.1 geht ganz allgemein den Fragen nach: Wieviele Server gibt es derzeit
überhaupt im World Wide Web? Welche Server-Software wird von diesen benutzt? Und
was kann man aus diesen Betrachtungen schließen?
2.2.1
Server Überblick
Die wohl bekannteste Adresse im WWW, die Server Statistiken betreibt, ist Net”
craft.com“ (http://www.netcraft.co.uk). Netcraft erstellt seit fast 5 Jahren eine monatlich aktualisierte Web Server Survey und gibt dadurch Aufschluß über den Verwendungsgrad bestimmter Server Software (siehe dazu Abbildung 2.1). Netcraft verwendet
zum Auffinden der Server ein Discovery Script, dass die gefundenen Server entsprechend ihrer Server-Signature10 identifiziert. Die so gesammelten Server-Informationen
werden von Netcraft in einer Datenbank verwaltet. Zur Zeit sind es über 13 Millionen
Web Sites – Anzahl stark steigend – die als Grundlage für die Statistiken von Netcraft
herangezogen werden. Tabelle 2.1 zeigt die Top 5“ und zusätzlich die Plazierung des
”
Hyperwave Information Servers. Deutlich ist die Dominanz des Apache Web Servers,
der mehr als die Hälfte des Marktes beherrscht, gefolgt vom Microsoft Internet Information Server mit knapp einem Viertel Anteil und dem schon eher abgeschlagenen iPlanet
Enterprise Server (früher Netscape) mit ,nur mehr‘ 6.94 Prozent. Der Hyperwave Information Server rangiert in der eigentlichen Tabelle – siehe [Netcraft, 2000] – im oberen
Drittel, ist aber mit 719 gezählten Sites innerhalb dieses Vergleichs unter ferner liefen.
10
Server response-header field der HTTP-Message, z.B: Server: Apache/1.3.4 (Unix) SuSE/6.0
22
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
Abbildung 2.1: Marktanteile der Top 5 Server über alle Domänen. Betrachtet in einem Zeitraum von August 1995 bis März 2000. Quelle: [Netcraft, 2000].
Tabelle 2.1: Netcraft Server Statistik vom März 2000 mit Platzierungen einzelner Server, Anzahl
der Web Sites und dem Prozentanteil des Marktes.
Rang
1
2
3
4
5
..
75
Server Name
Apache
Microsoft IIS
iPlanet (Netscape) Enterprise
Zeus
Rapidsite
..
Hyperwave Information Server
23
Anzahl der Sites
7.870.864
2.739.901
909.645
245.255
234.985
..
719
Prozentanteil
60.05%
20.91%
6.94%
1.87%
1.79%
..
0.01%
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
Vorsichtige Interpretation
Der Netcraft ,Web Server Überblick‘ ist mit einiger Vorsicht zu genießen. Die erfassten
Server wie Apache, Apache-1.3.4, mod_perl, ApacheSSL gehören zur gleichen Familie,
scheinen aber getrennt auf. Das Modul mod_perl des Apache ist ohnehin kein eigenständiger Web Server, es kann nur bei der Übersetzung der Apache-Distribution als Modul
installiert, oder als DSO11 dynamisch gelinkt werden. Über die Hälfte der erfassten Server – es sind über 600 – hat weniger als 100 gezählte Web Sites vorzuweisen. Alle Server
unter der Kategorie Web-Server zu sehen verzerrt die Ergebnisse zusätzlich, zwar nicht
im ersten Viertel der Statistik, aber sicher dannach. Daher ist auch die Plazierung des
HWIS sehr relativiert zu betrachten.
Der Netcraft ,Web Server Survey‘ ist vorrangig geeignet, einen schnellen qualitativen
Eindruck der derzeit herrschenden Marktverhältnisse zu bekommen. Für die genauere
Analyse oder gar als Entscheidungshilfe für die Anschaffung eines Servers, ist er sicher
weniger geeignet.
2.2.2
Web-Server
Selbst ein Internet-Service wie Netcraft, das seit dem Jahr 1995 das Wachstum der
Web-Server im Internet verfolgt, kann nicht klar definieren, welche Funktionalität ein
Web-Server zumindest haben muss und wo die Grenze zu einem Application Server liegt.
Daher wird hier versucht, ausgehend von den Leistungsprofilen der gesichteten Produkte,
die wichtigsten Merkmale eines Web-Servers in einer Defintion zusammen zu fassen:
Definition:
Ein Web-Server erlaubt mittels der Hypertext Markup Language (HTML) im Internet
Inhalte bereit zu stellen. Dazu nimmt der Web-Server Anfragen (Requests) von Web
Browsern entgegen und liefert ein entsprechendes Dokument. Dokumente sind eindeutig
über einen Uniform Resource Locator (URL12 ) im Internet bestimmt. Web-Server und
Web-Browser kommunizieren mittels Hypertext Transfer Protocol (HTTP). Server-seitige
Technologien können die Leistungsfähigkeit des Web-Servers steigern. Zu diesen Technologien zählen CGI, Server-Side Includes oder proprietäre Techniken wie Active Server
11
12
Dynamic Shared Object, siehe [Engelschall, 1998]
URL ist als Request For Comments definiert. [Berners-Lee et al., 1994, RFC 1738]
24
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
Pages (ASP). Vergleiche [Wĕbopēdia, 2000].
Sieht man von den angeführten server-seitigen Technologien völlig ab, würde das der
Anforderung Web-Basisfunktionalität“ – siehe Abschnitt 2.2 auf Seite 20 – eines Web”
Servers entsprechen. Ein derartig spartanischer Server wäre als Plattform für WebApplikationen natürlich ungeeignet. In der Praxis bieten aber alle Web-Server sogar
mehrere Möglichkeiten, Web-Applikationen zu realisieren, indem sie verschiedene WebTechnologien und Standards, wie CGI oder ASP, implementieren.
Das online Informations-Service internet.com [Icom, 2000] führt in einer sogenannten ServerWatch“ Listen von verschiedenen Server-Typen. Von Web-Server bis
”
Proxy-Server können hier Rubriken gefunden werden. Nach Auskunft der ServerWatch“
”
werden alle Server-Rubriken manuell verwaltet und die Aufnahme eines neuen ServerProduktes erfolgt nach eigenem aber unabhängigem Ermessen.
Die Liste der verzeichneten Web-Server der ServerWatch“ beschränkt sich auf 32
”
Einträge, sichtlich eine deutliche Reduktion zu den über 600, die im Netcraft Survey“
”
unter Web Server zu finden sind. In Tabelle 2.2 sind diese mit Name, URL und einigen
zusätzlichen Anmerkungen alphabetisch aufgelistet. Diese 32 sind zur Zeit die sicher
wichtigsten und meist eingesetzten Server am Markt. Bei der näheren Untersuchung der
Server bezüglich der gebotenen Leistung, Funktionalität und zusätzlicher Features fallen
folgende Punkte auf:
1. Freeware, GPL13
Viele Server sind kostenlos, laufen unter einer freien Lizenz wie der GPL oder
sind Open Source“ (siehe http://www.opensource.org für weitere Informatio”
nen). Bei einigen ist es eine grundsätzliche Anforderung ans eigene Produkt (siehe
Apache, Jigsaw), bei anderen eher ein ,Köder‘, um andere meistens sehr benötigte Tools, wie Such-Möglichkeit oder Administrations-Werkzeuge, für den Server
schmackhaft zu machen (siehe Roxen Challenger, Nr.20 in Tabelle 2.2). Es gibt
auch abgespeckte Versionen von feature-reichen kommerziellen Versionen, die nur
für den privaten Gebrauch bestimmt sind (siehe Microsoft Private Web Server).
2. Klein und Groß
Die Microsoft Server sind zusammen mit Lotus Domino die Spitzenreiter in der
Download-Größe. Im Allgemeinen sind die für Unix bestimmten Server um einiges
13
General Public License, siehe [GPL, 1999]
25
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Legende:
U .. Unix
L .. Linux
M .. MacOS
OS2 .. OS/2
W .. Windows 95/98/NT
NT .. Windows NT
Java .. Java Platformen
NetWare .. Netware
26
W
U,L
U, W
Java
W,U,OS2
NetWare
NT,M
W,U
Java
Java
NT
NT
W
NT
U,NT
U,NT
U,NT
W
U
U,W
W
U
U,W,M
W
Java
W
NT
W
M
U, W
W
U
4.1 MB
3.3 MB
2.9 MB
941 kB
11.6 MB
42.7 MB
3.7 MB
338 kB
583 kB
3.9 MB
74.6 MB
74.6 MB
74.6 mB
80 MB
1 MB
70 MB
18.7 MB
1.4 MB
3.5 MB
3.3 MB
6 MB
369 kB
2.1 MB
294 kB
4.1 MB
15.1 MB
779 kB
703 kB
3 MB
✌
✌
✌
150$
1295$
395$
✌
50$
✌
97$
99$
✌
1239$
✌
1295$
295$
✌
✌
✌
995$
✌
✌
✌
99$
799$
249$
599$
✌
70$
1699$
✌ .. Freeware
✝ .. Keine Weiterentwicklung
✿ .. In Java implementiert
➳ .. Baut auf Apache auf.
✔
✔
✔
✔
Anmerkung
Java Servlets
SSL
Preis
Adresse
www.csm.co.at/alibaba/index.htm
www.aolserver.com/server
www.apache.org
www.avenida.co.uk/products/aws
www-4.ibm.com/software/webservers/dgw
www.novell.com/products/netscape_servers
www.softarc.com
www.goahead.com/webserver/webserver.htm
www.servertec.com/products/iws/iws.html
www.w3.org/Jigsaw
www.notes.net/r5
www.microsoft.com/ntserver/web
www.microsoft.com/ntserver/web
www.microsoft.com/siteserver
hoohoo.ncsa.uiuc.edu
www.iplanet.com/products
www.iplanet.com/products
www.omnicron.ab.ca/httpd
www.rapidsite.com
www.roxen.com/products/challenger
www.sambar.com
www.c2.net/products/sh2
www.scriptics.com/products/tclhttpd
www.urllive.com
www.vqsoft.com/vq/server
www.luckman.com
website.oreilly.com
website.oreilly.com
www.starnine.com/webstar/webstar.html
www.imatix.com/html/xitami
www.zbserver.com
www.zeus.co.uk
Download
Größe
Web-Server
Alibaba
AOLserver
Apache
Avenida
Domino Go Webserver
Enterprise for Netware
First Class
GoAhead
iServer
Jigsaw
Lotus Domino
Microsoft IIS
Microsoft PWS
Microsoft Site Server
NCSA HTTPd
Netscape Enterprise
Netscape FastTrack
OmniHTTPd Pro
RapidSite
Roxen Challenger
Sambar Server
Stronghold
Tcl Web Server
URL Live!
vqServer
Web Commander
Website Pro
WebSite Standard
WebSTAR
Xitami
ZBServer
Zeus Web Server
BS
Nummer
Tabelle 2.2: Web-Server der ServerWatch“ [Icom, 2000] mit Name, Adresse, unterstütztem
”
Betriebssystem, Download Größe, Preis, SSL, Java Servlets und zusätzlichen Anmerkungen zum
Entwicklungsstatus.
✝
✔
✔
✿
✝
✔
✔
✿
✔
✔
✔
✝
✔
✔
✔
✔
✔
➳
✔
✔
➳
✔
✿
✔
✔
✔
✔
✔
✔
✔
✔
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
Platz sparender als die für Windows, da diese nicht bereits vorhandene StandardDienste wie ftp oder sendmail implementieren müssen. Viele Windows-Server
sind mit diesen zusätzlichen Diensten ausgestattet.
3. SSL14
Wird bereits von der Mehrzahl – in Tabelle 2.2 sind es die Hälfte – der Server
standardmäßig angeboten und stellt zur Zeit den Status quo im Bereich sichere
Kommunikation via Internet (HTTP, LDAP15 , IMAP16 ) dar.
4. Unix vor Windows
Unix ist noch immer das vorrangige Betriebssystem für Web-Server, dennoch bieten
immer mehr Hersteller Versionen auch für Windows 9x, aber zumindest Windows
NT an.
5. Java Servlets
In Tabelle 2.2 sind es 11 von 32 Servern die Java Servlets unterstützen. Java
Servlets sind eine immer populärer werdende Alternative zu CGI-Programmen auf
der Server-Seite.
6. In Java
Avenida, Jigsaw, und vqServer sind in Java implementiert. Sie haben damit den
Vorteil, automatisch auf sehr vielen Plattformen verfügbar zu sein. Zudem brauchen sie keine zusätzliche Servlet-Engine, um Java Servlets ausführen zu können,
sie verwenden dazu die vorhandene Virtual Machine.
7. Apache basierend
RapidSite und Stronghold erweitern die Grundfunktionalität des Apache WebServer mit zusätzlichen Features und bieten damit ein für bestimmte Zwecke vorgefertigtes Server-Paket kommerziel an. Stronghold ist die Nummer eins im Bereich
der kommerziellen SSL-Server für Unix-Platformen.
Abschließend läßt sich feststellen, dass alle Web-Server der ServerWatch“ die an
”
die Server-Software gestellten Anforderungen – zwar in unterschiedlicher Weise, aber
doch – erfüllen. Bei der Untersuchung zeigte sich auch, dass manche Produkte aufgrund
14
Secure Socket Layer, siehe [Alan O. Freier et al., 1996; SSL-Intro, 1998; Crypto, 1998].
Lightweight Directory Access Protocol
16
Internet Message Access Protocol
15
27
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
der ständigen Inkorporation neuer Technologien, einfach überladen“ sind und dadurch
”
schwerfällig werden im Handling und der Wartung. Die Geschwindigkeit, in der neue
Standards von Herstellern implementiert werden, bestimmt aber nachhaltig die Konkurrenzfähhigkeit ihres Produkts. Das geht jedoch – wie gesehen – vermehrt auf Kosten des
Kunden und der Qualität.
Eine Vielfalt von implementierten Web-Technologien erlaubt natürlich die Selektion der
für die Anforderungen der Applikation am geeignetsten. Diese Auswahl-Möglichkeit
sollte aber keinesfalls auf Kosten der Performance gehen, überhaupt wenn sich die sogennanten Usage Patterns über Nacht schlagartig ändern können17 .
2.2.3
Application Server
Gautam Desal in [Desal et al., 1999]:
Application servers are the infrastructure component in vogue this season.“
”
Application Server sind nicht nur en vogue“, sondern in der Zwischenzeit sehr gewachsen
”
und gereift. Das liegt an der Tatsache, dass viele Unternehmungen in einem Application
Server das effektivste Werkzeug sehen, in kurzer Zeit Web-Applikationen zu realisieren, die sich leicht in bestehende – oft heterogene – Systeme wie Kunden-Datenbanken,
Geschäfts-Applikationen oder sogenannte Legacy Applications18 integrieren lassen. Gerade in diese Richtung zielt auch das Werbekonzept der Hersteller, das mit dem Kauf
eines Application Servers die beinahe fertige Web-Applikation verspricht, was natürlich
nur ansatzweise stimmt. Der Markt wächst trotzdem rapide und bereits alle größeren
Software-Produzenten können mit entsprechenden Produkten aufwarten.
In Abschnitt 2.2.2 hat sich bereits die Definition eines Web-Servers als nicht sehr
leicht erwiesen, hingegen wirkliche Schwierigkeiten stellt die Aufgabe, einen Application
Server zu definieren. Eine Ursache liegt darin, dass Application Server meist auf der
Basis von vorhandenen Produkten eines Software-Hauses aufbauen und damit schon mit
bestimmten Grund-Features ausgestattet sind, für die das Haus bekannt ist. In dem Artikel What is an Application Server“ [Wright, 1999] unterteilt Guy Wright Application
”
Server nach ihrer Abstammung“ in 3 Kategorien:
”
17
18
Heute 100, Morgen 1000 zugreifende Benutzer
Das sind bestehende Applikationen eines Unternehmens, die sehr viel Zeit und Geld gekostet haben.
28
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
1. Web-Server mit zusätzlicher Funktionalität
2. Datenbank-Server mit zusätzlicher Web-Funktionalität
3. Völlig neues Produkt
Weitere Ursachen für diese Begriffs-Verwirrung“ beschreibt Mike Ricciuti in seinem
”
Artikel Application Server eludes Definition“ [Ricciuti, 1998]. Die Sichtung der White
”
Papers verschiedener Application Server ergibt dennoch eine große Menge an immer
wieder vorkommenden Features, die man als Kern-Merkmale von Application Servern
bezeichnen kann. Die nachstehende Definition fasst diese zusammen.
Definition:
Ein Application Server ist Software, die in der sogenannten Mittelschicht (engl. middle tier ) läuft, zwischen Web-Browser basierenden Thin Clients 19 und ,back-end‘ Datenbanken oder anderen Applikationen. Der Application Server behandelt die gesamte
Applikations-Logik, die für das Verhalten eines bestimmten Systems zuständig ist. Er
stellt Java- oder Browser-basierende Anwendungen dem Benutzer zur Verfügung, deren
Implementierung über eine integrierte Web-Entwicklungs-Umgebung erleichtert wird.
Zusätzlich kann ein Application Server in großen Systemen als Traffic Cop fungieren
und die auftretende Last entsprechend verteilen. Quelle: [Wĕbopēdia, 2000; Ricciuti,
1998].
Mit dem Einfügen eines Application Server in ein vorhandenes Client/Server-System,
Abbildung 2.2: 3-tier Architecture. Quelle: [Netscape, 2000].
19
Ein Computer der keine Applikation installiert haben muss, da er sie über den Web-Browser optional
laden kann. Siehe [Wĕbopēdia, 2000].
29
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
wird aus der 2-schichtigen Architektur (2-tier Architecture) eine 3-schichtige (3-tier
Architecture). Da wie in Abbildung 2.2 dargestellt der Application Server sich genau
zwischen Client und Server einordnet, spricht man von Middleware. Diese Architektur
begünstigt auch die Aufspaltung der Applikation in 3 Teile, nämlich in:
1. Presentation Logic (Präsentations-Logik):
HTML, XML, JavaScript.
2. Application Logic (Applikations-Logik):
Java, C/C++, Enterprise JavaBeans (EJB), Servlets, JavaServer Pages.
3. Data Logic (Daten-Logik):
SQL, EJB.
Diese Teilung erweist sich besonders bei der Entwicklung von large-scale Applications 20
als sehr vorteilhaft und wird zum Beispiel von Oracle [Oracle, 1999] in der Praxis verfolgt.
Die bereits oben zitierte ServerWatch“ [Icom, 2000] rezensiert auch die wichtigsten
”
Application Server in einer eigenen Rubrik. Tabelle 2.3 listet diese mit Namen, URL
und interessanten Anmerkungen alphabetisch auf. Zope wurde als Beispiel eines OpenSource Application Servers noch zusätzlich in der Tabelle ergänzt. Aus dem Studium
einiger White Papers und der Leistungsprofile der aufgelisteten Application Server können folgende Punkte festgehalten werden:
1. Größe
Die gepackten Demo-Versionen sind im Schnitt bereits an die 50 MB groß. Spitzenreiter ist Oracle mit 181 MB, Schlußlicht ist Galileo mit 229 kB. Die Größe
korreliert dabei zunehmend mit der Komplexität der Software.
2. Plattformen
Alle Server sind für Windows NT und Solaris erhältlich. Versionen für HP-UX,
AIX, MAC OS, Irix und Linux sind je nach Hersteller verfügbar.
3. Web-Server
Apache, MS Internet Information Server und Netscape sind die gängisten unterstützten Server. Die Kommunikation zwischen Web-Server und Application Server kann auch bei vielen Produkten über CGI stattfinden. Einige Server wie Galileo
oder Zope übernehmen selbst die Aufgabe eines Web-Servers.
20
Anwendungen für den Bereich Midrange bis Superenterprise, siehe [Krause & Hecht, 2000].
30
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
1
2
3
4
5
6
8
9
10
11
12
13
14
15
16
Legende:
Adresse
http://www.bluestone.com/products/sapphire
http://www1.allaire.com/products/coldfusion
http://www.delanotech.com/products
http://www.esemplare.com/galileo.html
http://www.haht.co.uk
http://www.intertop.com/isuite/iserver.html
http://www.netdynamics.com
http://www.iplanet.com/products
http://www.oracle.com
http://www.silverstream.com
http://www.sybase.com/products/easerver
http://www.vision-soft.com
http://www.apple.com/webobjects
http://www-4.ibm.com/software/webservers
http://www.zope.org
U .. Unix
W .. Windows 95/98/NT
NT .. Windows NT
W,U
W,U
NT
NT,U
NT,U
NT,U
NT,U
NT, U
NT, U
NT, U
NT,U
NT,U
NT,U
NT,U
NT,U
Preis
25.000$
3.495$
50.000$
✌
7.500$
3.995$
25.000$
35.000$
648$
8.500$
1.995$
25.00$
7.500$
6.000$
✌
Anm.
Application Server
Bluestone Sapphire/Web
ColdFusion
Delano e-Business Suite
Galileo
HAHTSite
Intertop
NetDynamics SUN
Netscape Appl. Server
Oracle Appl. Server
SilverStream
Sybase Appl. Server
Visiom B. Server
WebObjects Apple
WebSphere IBM
Zope
BS
Nr.
Tabelle 2.3: Application Server der ServerWatch“ [Icom, 2000] mit Name, Adresse, unterstütz”
tem Betriebssystem, Preis und zusätzlichen Anmerkungen.
✿
✿
✿
✌ .. Freeware
✿ .. In Java implementiert
4. Summe von Komponenten
Das Produkt Application Server besteht in fast allen Fällen aus einem Bündel
verschiedener Server und Tools, typischerweise aus Application Builder, Application
Server und Application Administration Tool. Das Admin-Tool ist zumeist via WebBrowser zugänglich.
5. Wizards, IDE21
Die Entwicklung von Applikationen soll durch Wizards und visuelle Werkzeuge
innerhalb der integrierten Entwicklungs-Umgebung beschleunigt werden. Im Speziellen wird das visuelle Applikations-Design von vielen Herstellern forciert.
6. Java, C/C++
Der Slogan write once, run anywhere“ hat Java zur Sprache des Network Compu”
ting gemacht [OAS, 1998]. Sämtliche Server unterstützen Java, fast alle C/C++.
Perl und Cobol sind nur ganz vereinzelt vertreten.
7. DB Unterstützung
21
Integrated Development Environment
31
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
Der Zugriff auf Datenbanken kann primär über ODBC22 oder JDBC23 erfolgen.
Informix, Oracle, DB2, SQL Server werden weniger aber dann direkt unterstützt.
8. CORBA24
Die Mehrzahl der Server – 10 von 16 – erlaubt die Erzeugung von CORBA Objekten und verfügt meistens über eigene Object Request Broker (ORB), die sich
untereinander über Internet Inter-ORB Protocol (IIOP) verständigen.
9. COM/DCOM25
Für verteilte Objekte auf Windows Ebene unterstützen 7 der 16 Server DCOM von
Microsoft. DCOM konkurriert mit CORBA, bei ungefähr gleicher Funktionalität.
10. EJB
Enterprise JavaBeans wurden im Vergleich zu CORBA sehr schnell von den Herstellern als Standard akzeptiert. Ungefähr die Hälfte der Server unterstützt bereits
diese Technologie.
11. Failover
Fast alle Server bieten Failover-Strategien auf Server-Level. Je nach Produkt – aber
eher vereinzelt – gibt es Failover auf Application-Level oder sogar auf Session-Level.
12. Clustering, Load-Balancing
Voraussetzung für Failover-Mechanismen ist die Möglichkeit einen anderen gleich”
wertigen“ Server bei Bedarf zu verwenden. Dazu werden sogenannte Server Cluster
eingesetzt, die auch das Aufteilen der auftretenden Last erlauben. Load-Balancing
kann entweder rule-based oder event-based stattfinden.
13. Hoher Preis
Application Server sind High-End-Software und die hat ihren Preis. Nach oben
hin ist es schwer, eine Grenze zu ziehen, da der Preis von der Anzahl der concurrent User abhängig sein kann. Dem stehen nur Galileo und Zope als freie Server
gegenüber, die aber auch mit weniger Funktionalität ausgestattet sind.
22
Open DataBase Connectivity, eine von Microsoft entwickelte DB-Zugriffsmethode.
Java DataBase Connectivity, ein von JavaSoft/SUN entwickeltes Java API zum DB-Zugriff.
24
Common Object Request Broker Architecture, siehe [Schmaranz, 2000, Kap. 7].
25
Das Distributed Component Object Model ist eine Erweiterung des Component Object Model und
ein von Microsoft entwickelter Standard für verteilte Objekte.
23
32
2 WEB-APPLIKATIONEN
2.2 SERVER SOFTWARE
Aus dieser Fülle aufgezählter Punkte könnte man glauben, in einem Application Serverwirklich das lang gesuchte Silver Bullet für den Werewolf Web-Applikation gefunden
zu haben, leiht man sich die berühmte Metapher von Frederick Brooks [Brooks, 1986].
Dem ist leider nicht so. Natürlich versucht man mittels visueller Tools die Entwicklung
so leicht wie möglich zu gestalten, aber den Aufwand eines durchdachten ApplikationsDesigns und den gewissen – meist größeren – Teil dazu notwendiger Low-Level Programmierung, können sie einem nicht abnehmen.
Bei der Auswahl des richtigen Servers26 ist zuerst immer den Anforderungen der
Web-Applikation Rechnung zu tragen. Das heißt man sucht die Antworten zu den beiden
folgenden Fragen:
1. Welche Anforderungen muß und soll die Web-Applikation erfüllen?
2. Welcher Server kann die Erfüllung dieser Anforderungen am ehesten unterstützen?
Bezieht man noch Aspekte wie Skalierbarkeit, Erweiterbarkeit, Sicherheit und Wartbarkeit in den Entscheidungsprozess mit ein, hat man von rein technischer Seite gesehen,
kaum eine Chance ein falsches Produkt als Plattform für die Web-Applikation zu wählen.
2.2.4
Information Server
Als letztes in Abschnitt 2.2 erwähntes Server-Segment, bleibt der Information Server.
Wie sich aus der Untersuchung der letzten beiden Kategorien herausstellt, ist das Label
Information Server“, einerseits sehr selten an Server vergeben und andererseits auch
”
noch nicht als eigenständige Kategorie – wie Web-Server“ oder Application Server“ –
”
”
am Markt etabliert. Das zeigt ebenfalls das Fehlen einer Rubrik Information Server“
”
in der bereits bekannten ServerWatch“, die Server der anderen Kategorien sehr wohl
”
rezensiert. Der Hauptgrund liegt in der Tatsache, dass sich die am Markt befindlichen
Information Server leicht in eine der beiden anderen Kategorien subsumieren lassen.
Somit entfällt ein eigenes Segment für Information Server. Derzeit gibt es nur zwei
Server, die von ihren Herstellern als Information Server bezeichnet werden:
1. Microsoft Internet Information Server
2. Hyperwave Information Server
26
Siehe Abschnitt 2.2 auf Seite 20 für Anforderungen an den Server.
33
2 WEB-APPLIKATIONEN
2.3 WEB-TECHNOLOGIEN
Wie aus Tabelle 2.2 ersichtlich zählt der Microsoft Internet Information Server – kurz
MSIIS – ohnehin zur Kategorie Web-Server. Der Hyperwave Information Server – kurz
HWIS – kann als Application Server betrachtet werden, was sich aus der genaueren Studie in Abschnitt 3 erweist.
Faktum ist allerdings, dass ein Information Server vom Blickwinkel Funktionalität aus gesehen, wesentlich mehr bieten muss, als bloß einen statischen Dokument-Baum zu verwalten. Der Name allein assoziiert gewisse Features, wie inherentes Dokument-Management,
Inhaltsmanagement und natürlich Informationsmanagement. Gerade große Datenbestände, wie in Intranet-Umgebungen oft vorzufinden, benötigen diese im Server integrierten Tools zur effizienten Verwaltung, Wartung und Suche. Demnach sollte Microsoft
seinen Server gemäß seines Leistungsgrades wirklich nur als Internet Server“ bezeichnen.
”
2.3
Web-Technologien
Web-Applikationen leben von der Möglichkeit, in irgendeiner Weise dynamisch – im Englischen auch ,on the fly‘ – Web-Seiten zu generieren. Sie nehmen in den meisten Fällen
session-abhängig Informationen aus einer Datenbank und verpacken diese in schön anzuschauendes HTML. Diese Grundanforderung an die Server Software hat nun eine Reihe
von sogenannten Web-Technologien enstehen lassen, die einerseits bereits als Standard
definiert wurden (zum Beispiel JavaScript, Java Servlets oder JSP) oder zum De-factoStandard geworden sind (zum Beispiel Server Side Includes). Die hier besprochenen
Technologien sind alle für die Server-Seite bestimmmt, Technologien der Client-Seite, wie
DHTML27 , XML oder CSJS28 können natürlich in den erzeugten Web-Seiten Anwendung finden. Die Unterscheidung in verschiedene Kategorien unter den in den nächsten
Abschnitten betrachteten Web-Technologien fällt ungleich schwerer wie diese zwischen
den verschiedenen Server-Typen. Ein mögliches Kriterium wäre aber die Leistungsfähigkeit oder der Einsatzbereich der Technolgie: PHP29 und Java Servlets erlauben den
Zugriff auf verschiedene Datenbanken und sind auch sonst mit sehr mächtigen APIs
ausgestattet, dagegen ist mit SSI30 hinsichtlich Database Connectivity überhaupt nichts
27
Dynamic HTML, siehe [Niederst, 1999, Kap. 24].
Client-Side JavaScript, siehe [csjsGuide, 1999; Flanagan, 1997].
29
PHP: Hypertext Preprocessor, ein Hypertext Preprocessor, siehe Abschnitt 2.3.4.
30
Server Side Includes, siehe Abschnitt 2.3.1
28
34
2 WEB-APPLIKATIONEN
möglich.
In der Praxis stellt oft der Server selbst diese Technologien zur Verfügung, wie das
parsen eines HTML-Dokuments nach SSI oder PHP Anweisungen, die entsprechend
interpretiert werden müssen. Sonst ist dazu aber ein zusätzlicher Server oder ein zusätzliches Modul notwenig, wie etwa beim Servlets-Konzept des Apache. Zu den Standards
und De-facto-Standards gesellen sich schließlich noch eine Unmenge von proprietären
server-seitigen Skriptsprachen. Alle erlauben die Einbettung von bestimmten Tags 31
in Standard HTML, die der Server vor dem Schicken des Dokuments entsprechend der
Anweisung ersetzt. Viele dieser Skriptsprachen sind als Meta-HTML zu bezeichnen.
Beispiele sind RXML (Roxen Macro Language), oder PLACE [HwisPlace, 1999] des Hyperwave Information Servers.
Die Abschnitte 2.3.1–2.3.7 untersuchen die derzeit wichtigsten Web-Technologien der
Server-Seite genauer und erklären anhand von Beispielen deren Funktionalität. Der
Schwerpunkt der Beispiele liegt in der Datenbank-Anbindung. Im Speziellen wird versucht mit den bereitgestellten Mitteln – Kommandos und Funktionen – der untersuchten Technologie, Daten aus einer MySQL32 Datenbank auszulesen und in einer HTMLTabelle zu formatieren. Das ist direkt entweder überhaupt nicht möglich (SSI) oder
gestaltet sich jeweils als mehr oder weniger schwieriges Unterfangen.
2.3.1
SSI
Server Side Includes (SSI) bieten die wohl einfachste Möglichkeit, HTML-Seiten etwas
dynamischer zu gestalten. In ein normales HTML-Dokument werden SSI-Anweisungen
eingebettet, die vor dem eigentlichen ,Senden‘ via HTTP vom Server interpretiert werden. SSI wird von zahlreichen Web-Servern als Feature angeboten, dennoch wurde
nie ein richtiger Standard definiert. Gewisse Anweisungen haben sich aber als DeFacto-Standard durchsetzen können, da die meisten Server sie in der gleichen Syntax
implementieren. SSI-Unterstützung alleine reicht noch nicht, der Server selbst muss
passend konfiguriert werden, um schließlich SSI-Anweisungen interpretieren zu können.
Abschnitt 4.2.1 beschreibt die Aktivierung von SSI beim Apache Web-Server.
HTML-Dokumente mit SSI-Anweisungen werden oft durch die Extension .shtml“
”
gesondert gekennzeichnet, damit der Server nur diese Files nach Anweisungen parst.
31
32
Ein Befehl der vom Server verstanden und interpretiert wird, z. B.: <attr> ... </attr>.
http://www.mysql.com
35
2 WEB-APPLIKATIONEN
Die SSI-Anweisungen werden in der Form von HTML Kommentaren in das Dokument
eingebunden:

Ein Leerzeichen vor dem abschließenden -->“ ist in der Regel für die richtige Ausführung
”
notwendig. Folgende Anwendungsbereiche bieten sich für SSI an:
• Einbinden von Dateien, zum Beispiel Header und Footer.
• Ausgabe der Größe oder des Datums der letzten Änderung eines Dokuments.
• Ausführen von CGI-Skripts oder Shell-Kommandos33 .
• Ausgabe von Umgebungsvariablen des Servers.
Eine bescheidene Liste, aber für das Einbinden kleiner ,Gimmicks‘ in Web-Seiten, wie
einen CGI-Counter, vollkommen ausreichend. Tabelle 2.4 listet einige interessante SSIBeispiele mit Beschreibung auf. Zusätzlich existieren noch Anweisungen für eine rudiTabelle 2.4: Einige SSI-Beispiele mit Beschreibung

Einbinden einer Datei aus dem Verzeichnis /include.
"
Ausführen eines CGI-Skripts.

Ausführen eines Shell-Kommandos.

Datums der letzten Änderung der Datei meisl.html.

Größe der Datei meisl.html.
mentäre Flußkontrolle, eine IF-Anweisung innerhalb eines SSI-Files kann zum Beispiel
so aussehen:

Hallo lisa.tu-graz.ac.at!

33
Bei der Ausführung von CGI’s und Shell-Kommandos ist Vorsicht geboten, unsicher implementierte
Skripte können großen Schaden anrichten.
36
2 WEB-APPLIKATIONEN
Sollte die Anfrage vom Host lisa.tu-graz.ac.at“ kommen, wird der Block bis zum
”
“ ins HTML-Dokument übernommen. Für eine komplette Liste der
”
verfügbaren Anweisungen siehe [Eilebrecht, 1999, Kap. 8] oder [Laurie & Laurie, 1999].
SSI sind für kleinere Aufgaben, wie Einbinden von oft verwendeten HTML-Stücken oder
Aufrufen von kleinen CGI-Skripts sehr geeignet. Aufgrund des kleinen Vorrats an Anweisungen ist diese Technik auch äußerst schnell erlernbar. SSI können aber bestenfalls
als primitive Unterstützung in Web-Applikationen angesehen werden.
Weitere Informationen:
http://www.sonic.net/~nbs/unix/www/ssi
http://www.apache.org/docs/mod/mod_include.html
2.3.2
CGI
Die wohl bewährteste Methode, dynamisch Web-Seiten zu erzeugen, stellt das Common
Gateway Interface – kurz CGI – zur Verfügung. Wie bereits dem Namen zu entnehmen,
handelt es sich dabei lediglich um eine Schnittstelle, die die Ausführung von Programmen
am Server erlaubt. Die Programme können dabei in jeder beliebigen Programmieroder Skriptsprache ausgeführt werden. Die bekanntesten Sprachen sind: Unix Shell,
Python, Tcl, Perl, C, C++, Java, Fortran, Visual Basic. Da hauptsächlich Skriptoder Interpretersprachen wegen ihrer höheren Flexibilität und leichteren Erlernbarkeit
eingesetzt werden, hat sich auch die Bezeichnung CGI-Skript“ eingebürgert. Den De”
facto-Standard unter den CGI-Sprachen stellt dabei Perl dar. CGI/1.1 wurde 1993 vom
NCSA httpd Team definiert und im gleichnamigen Web-Server implementiert. Derzeit
wird versucht CGI/1.1 und das neuere CGI/1.2 als Internet-Draft (RFC) zu etablieren.
CGI-Skripte befinden sich entweder in speziellen Verzeichnissen (z.B.: cgi-bin) am
Server oder können sich überall im Dokument-Baum befinden und werden anhand der
File-Extension (z.B.: .cgi oder .pl) als solche deklariert. Der Aufruf eines CGI-Skripts
kann über eine der beiden HTTP-Methoden34 GET oder POST erfolgen.
In HTML-
Formularen sind beide Methoden möglich, beim Aufruf des Skripts über eine URL kommt
GET zum Einsatz:
34
Siehe RFC 2616 [Fielding et al., 1999, Sec. 9] für eine genaue Beschreibung aller HTTP-Methoden.
37
2 WEB-APPLIKATIONEN
GET /cgi-bin/my.pl HTTP/1.0
Abbildung 2.3: Kommunikationsabläufe zwischen Client, Server und einem CGI-Skript in Perl.
Abbildung 2.3 stellt den Kommunikationsablauf zwischen Client, Server und CGI-Skript
schematisch dar. Wird ein CGI-Skript über die POST-Methode aufgerufen, so kommuniziert der Server direkt mit dem Standard Input (STDIN) des Skripts. Wird ein
CGI-Skript über die GET-Methode aufgerufen, erhält es über die Umgebungsvariblen des
Servers seinen Input.
Im einfachsten Fall werden gar keine Daten an das Skript übergeben. Listing 2.1
erzeugt beispielsweise ein simples HTML-Dokument, das lediglich das aktuelle Datum
und die aktuelle Uhrzeit ausgibt.
Listing 2.1: hello.pl
1
2
3
4
5
6
7
8
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "<HTML><HEAD><TITLE>Hello World CGI</TITLE></HEAD>\n";
print "<BODY><CENTER>\n";
print "<H1>Hello World CGI</H1>\n";
$time = localtime;
print "The date is:$time\n";
print "</CENTER></BODY></HTML>\n";
Zeile 1 des Skripts definiert den Namen des Programms, das den restlichen Inhalt interpretieren soll, in unserem Fall übernimmt ein Perl-Interpreter diese Aufgabe. Wichtig
für jedes CGI-Skript ist die Erzeugung eines primitiven HTTP-Headers, der im minimalen Fall nur den Content-type angibt. Der Client kann daraus auf die Art der
übermittelten Daten schließen und stellt diese entsprechend dar. In Listing 2.1, Zeile
38
2 WEB-APPLIKATIONEN
2 wird der Content-type mit text/html angegeben, die anschließend durch \n\n“ er”
zeugte Leerzeile dient zum Abschluß des HTTP-Headers. Das restliche Skript generiert
entsprechend des angegebenen Content-type ein einfaches HTML-Dokument.
Auch bei komplizierteren Aufgabenstellungen, wie dem Zugriff auf eine Datenbank,
erweist sich das Duo“ CGI und Perl als sehr dynamisch. Perl stellt dafür ein Database
”
Interface (DBI) Modul zur Verfügung, das unter Verwendung spezieller Treiber (Database Driver, DBD), mit verschiedenen Datenbanken zusammenarbeiten kann. Diese
speziellen Treiber führen auch die eigentlichen Operationen mit der Datenbank durch.
Abbildung 2.4 zeigt den Datenfluß, von einem Perl-Skript über DBI und verschiedenen DBD zu drei relationalen Datenbank-Systemen (RDBMS35 ). Die Implementierung
Abbildung 2.4: Datenfluß über das DBI Modul und speziellen DBD zu verschiedenen RDBMS.
neuer Treiber gestaltet sich aufgrund der in Abbildung 2.4 dargestellten Architektur als
unbeschwerlich und sehr effizient. Die Interaktion mit der Datenbank erfolgt im Detail
über drei Perl-Objekte, die als Handles bezeichnet werden:
1. Driver Handle: Repräsentiert einen geladenen DB-Treiber. Die Instanziierung
erfolgt indirekt über DBI->connect.
2. Database Handle: Kapselt eine einzelne Verbindung zu einer bestimmten DB. Der
eigentliche Verbindungsaufbau erfolgt über:
$dbh = DBI->connect($data_source,... );
35
Relational DataBase Management System
39
2 WEB-APPLIKATIONEN
3. Statement Handle: Kapselt ein einzelnes SQL-Statement, das innerhalb der DB
exekutiert wird. Die Instanziierung erfolgt über:
$sth = $dbh->prepare(’<SQL-Statement>’);
Wie die drei Handles zusammenhängen und durch welche Perl-Variable sie typischerweise
angesprochen werden, ist in Abbildung 2.5 dargestellt.
Die abgebildete Struktur der
Abbildung 2.5: DBI Handles mit zugehörigen Perl-Variablen
Handles ist auch im Code-Beispiel (Listing 2.2) zu finden und definiert jeweils nur EinKind-Beziehungen. In der Praxis sind Mehr-Kind-Beziehungen die Regel, das heißt
ein Driver Handle hat eventuell mehrere Database Handles und jeder Database Handle
eventuell mehrere Statement Handles.
Listing 2.2 verwendet nebem dem DBI Modul auch das CGI Modul (Zeile 3), das
den Aufbau und die Manipulation von HTML-Dokumenten mit zahlreichen Methoden
vereinfacht. In Zeile 11 und 12 generiert die Methode header() einen HTTP-Message
Header, in Zeile 13 und 14 erzeugt start_html einen HTML Header und end_html()
in Zeile 22 schließt das HTML-Dokument mit den entsprechenden Tags. Dazwischen
werden Daten mit Hilfe der erwähnten Handles aus einer MySQL-DB gelesen und in
einer HTML-Tabelle formatiert.
Listing 2.2: Products.pl erzeugt über DBI eine Verbindung mit einer MySQL-DB und füllt
eine HTML-Tabelle mit Daten.
1 #!/usr/bin/perl -w
2 use DBI;
# DBI Module
3 use CGI;
# CGI Module
4 my $cgi_obj = new CGI;
5 my $data_source = ’dbi:mysql:test;www.amft.tu-graz.ac.at;3306’;
6 my $dbh = DBI->connect($data_source,’test’,’test’) ||
7
die "Can’t connect to Server: $DBI::errstr\n";
8 my $sth = $dbh->prepare( ’SELECT * FROM Products’ ) ||
40
2 WEB-APPLIKATIONEN
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
die "Can’t prepare Statement: $DBI::errstr\n";
$sth->execute || die "Can’t execute Query: $DBI::errstr\n";
print $cgi_obj->header( -type=>’text/html’,
-expires=>’+1h’);
print $cgi_obj->start_html(-title=>’CGI - Perl - MySQL’,
-DTD=>’-//W3C//DTD HTML 3.2//EN’ );
print $cgi_obj->h1(’Products:’);
print "<TABLE BORDER=1>\n";
while ( my @ergebnis = $sth->fetchrow_array ){
print "<TR><TD>".$ergebnis[0]."</TD><TD>";
print $ergebnis[1]."</TD></TR>\n";
}
print "</TABLE>\n";
print $cgi_obj->end_html;
$sth->finish;
$dbh->disconnect;
Die Variable $data_source in Zeile 5 definiert im ersten Teil den DBI-Treiber und die
Datenbank (dbi:mysql:test), im zweiten Teil den Namen des DB-Servers (www.amft.tugraz.ac.at) und im dritten Teil das Port des DB-Servers (3306). Mit dieser Information, Benutzer und Passwort, gelingt die Verbindung mit der MySQL-DB bei entsprechenden Rechten über DBI->connect() reibungslos. Die eigentliche Ausführung eines SQLKommandos erfolgt mit den Anweisungen in Zeile 8-10. Die Methode fetchrow_array()
(Zeile 17) liest eine einzelne Zeile des Ergebnisses in ein Array (@ergebnis). Die Einträge
des Ergebnis-Feldes @ergebnis werden mit HTML-Tags in Zeile 18 und 19 kombiniert
und liefern zusammen eine formatierte HTML-Tabelle. Somit bleibt am Ende nur mehr
der Abbruch der DB-Verbindung mittels $dbh->disconnect in Zeile 24.
CGI ist als Web-Technologie nicht mehr weg zu denken. Vom einfachen Gästebuch bis
zum ausgefeilten Warenkorb-System reichen die CGI-Web-Applikationen, die sich im
tagtäglichen Einsatz bewähren. Perl hat sich dabei als zuverlässiger Partner“ erwiesen
”
und stellt hilfreiche Bibliotheken (Module), wie CGI, DBI, LWP36 dem Programmierer zur Verfügung. Vorsicht sollte aber stets bei der Programmierung gegeben sein,
denn Sicherheitslöcher in CGI-Skripts sind beliebte Ziele von Angreifern. Der große
Schwachpunkt von CGI liegt im Faktum, dass bei jedem CGI-Aufruf ein eigener Pro36
Library for Web Programming.
41
2 WEB-APPLIKATIONEN
zess abgespaltet wird. Dies kann zu vehementen Leistungseinbußen führen und hat
auch zur Entwicklung von Alternativen wie FastCGI (Abschnitt 2.3.3), embedded CGI,
Emulatoren wie mod_perl (Abschnitt 4.2.2) oder Server APIs, wie NSAPI37 oder ISAPI38 beigetragen. Dennoch scheint die Popularität von CGI noch ungebrochen und
die Bestrebungen nach einer verbesserten CGI-Spezifikation (CGI/1.2) sind auch Beweis
dafür, dass CGI noch immer konkurrenzfähig ist und bleiben möchte. Diese Situation
beschreibt Lincoln Stein [Stein, 1999] sehr prägnant und treffend so:
CGI is dead. Long live CGI!“
”
http://www.w3.org/CGI
http://Web.Golux.Com/coar/cgi
http://www.oreilly.com/catalog/perldbi/chapter/ch04.html
http://stein.cshl.org/WWW/software/CGI/cgi_docs.html
2.3.3
FastCGI
Eine Technologie, die einerseits die Schwächen von CGI ausmerzen und andererseits dessen Stärken übernehmen möchte, ist das von Open Market 39 im Jahre 1996 entwickelte
FastCGI Web-Server-Interface. Die Hauptschwächen von CGI sind:
• Geringe Performance. Jeder Request erzeugt einen eigenen Prozess, wie in Abschnitt 2.3.2 bereits angesprochen.
• Fehlende Persistenz. Bei jedem Request muss eine Applikation erneut initialisiert
werden. Persistenz würde zum Beispiel auch das Cachen“ von Daten erlauben.
”
• Nicht skalierbar. Das Auslagern einer resource-intensiven Applikation auf einen
anderen Server – Load Distribution – ist nicht möglich.
Dem gegenüber definiert sich FastCGI [Saccoccio, 1999] wie folgt als:
37
Netscape Server API, http://developer.netscape.com/docs/manuals/enterprise/nsapi.
Internet Server API, http://www.genusa.com/isapi.
39
http://www.openmarket.com.
38
42
2 WEB-APPLIKATIONEN
• Eine sprach- und server-unabhängige, skalierbare offene Erweiterung von CGI, die
hohe Performance und Persistenz garantiert.
• Ein Protokoll zum Datenaustausch zwischen Web-Server und einer FastCGI-Appliktion.
• Ein Paket von Libraries, die das Protokoll implementieren.
Konzeptionell ist FastCGI sehr ähnlich zu CGI mit zwei Hauptunterschieden [OpenMarket, 1996]:
1. FastCGI-Prozesse sind persistent: Nach der Beendigung eines Aufrufs, wartet der
Prozess auf einen erneuten Aufruf anstatt sich zu beenden.
2. Anstelle von Umgebungsvariablen und Pipes verwendet FastCGI ein eigenes Protokoll, dass über eine full-duplex Verbindung die Informationen von Standard-Input,
-Output und -Error multiplext. Abbildung 2.6 veranschaulicht diese Relation zwischen Web-Server und FastCGI.
Abbildung 2.6: Beziehung zwischen Web-Server und FastCGI
Mit diesem Ansatz kann eine FastCGI-Applikation lokal oder auf einem entfernten Rechner laufen, womit der Anforderung nach Skalierbarkeit nachgekommen wird. Bei entfernten Applikationen verwendet der Server eine TCP-Verbindumg. Zusätzlich erlaubt
FastCGI single-threaded oder multi-threaded Applikationen. Multi-threaded Applikationen können gleichzeitig mehrere Verbindungen vom Web-Server annehmen und diese
innerhalb eines einzelnen Prozesses verarbeiten. Thread-Sicherheit ist für derartige Applikationen primäre Voraussetzung.
Die eingschränkte Funktionalität von CGI, nämlich nur auf einfache Anfragen reagieren zu können, erweitert FastCGI mit der Einführung sogenannter Rollen (roles). Eine
Applikation kann nun eine von drei verschiedenen Rollen übernehmen:
43
2 WEB-APPLIKATIONEN
1. Responder. Entspricht der einfachen Funktionalität, die von CGI bereitgestellt
wird.
2. Filter. Erlaubt die Verarbeitung eines Files bevor es an den Client gesendet wird,
zum Beispiel bei On-the-fly Format-Konversionen.
3. Authorizer. Überprüft vor Ausführung der Anfrage, ob eine entsprechende Berechtigung dazu vorhanden ist, zum Beispiel über eine Password-Authentifizierung.
Open Market stellt für die rasche Entwicklung von FastCGI-Applikationen sogenannte
Application Libraries für die Sprachen C/C++, Java, Perl, Python und Tcl zur Verfügung. Wie aus Listing 2.3 ersichtlich gibt es zum Beispiel für Perl ein eigenes Modul
FCGI, dass Methoden für FastCGI-Skripts bereitstellt.
Listing 2.3: HelloWorld.pl mit FastCGI
1
2
3
4
5
6
7
8
9
#!/usr/bin/perl -w
use FCGI;
$count=0;
while (FCGI::accept() == 0) {
print("Content-type: text/html \n\n",
"<H1> Hello World with FastCGI </H1>\n",
"Request ", ++$count,
" from Server ", $ENV{’SERVER_NAME’});
}
In dem einfachen Fall von Listing 2.3 wird bei jeder Anfrage ein Zähler inkrementiert,
der die Anzahl der Zugriffe speichert. Die Methode FCGI::accept() akzeptiert dabei
eine neue Anfrage und beendet implizit die letzte. Vorhandene Perl-CGI-Skripts müssen
einfach in die in Listing 2.3 gezeigte While-Schleife gepackt werden, um als FastCGI
ebenso ihren Dienst zu verrichten.
Derzeit unterstützen zahlreiche Server FastCGI als server-seitige Technologie. Dazu
zählen Apache (mod_fastcgi), Microsoft Server, Netscape Server und Zeus.
http://www.fastcgi.com
44
2 WEB-APPLIKATIONEN
2.3.4
PHP
PHP steht offiziell für PHP: Hypertext Preprocessor und ist eine server-seitige, in HTML
eingebettete Skriptsprache. Ausgangspunkt waren die von Rasmus Lerdorf im Jahre
1995 entwickelten Personal Home Page Tools, die bald danach unter dem Akronym
PHP2 bekannt wurden. Die aktuellste Version (zur Zeit PHP 3.014) kann unter der
Adresse http://www.php.net frei bezogen werden. Derzeit soll PHP auf über 150.000
Web Sites in der ganzen Welt Verwendung finden, Tendenz stark steigend.
Vergleichbar mit SSI werden als PHP gekennzeichnete Files – üblicherweise Files mit
der Extension .php“ oder .php3“ – vor dem Versenden vom PHP-Interpreter (meistens
”
”
im Web-Server integriert) nach PHP-Anweisungen geparst. Listing 2.4 zeigt ein Beispiel,
wie über PHP-Anweisungen das aktuelle Datum ausgegeben werden kann.
Listing 2.4: HelloWorld.php3
1
2
3
4
5
6
7
8
9
10
<HTML><HEAD>
<TITLE>Hello World with PHP3<TITLE>
</HEAD><BODY>
<H1>Hello World with PHP3 !!<H1>
<?
//
$today=date("Y-m-d");
//
PRINT "Today is:";
PRINT "<B> $today </B>";
//
?>
//
</BODY></HTML>
starts the PHP script
use of the ’date’ function
e.g.: ’2000-01-15’
closes the PHP script
Die Syntax ist sehr von C, aber auch Java und Perl beeinflußt und erlaubt dem Anfänger
ein rasches Einarbeiten in die Sprache. Alle Anweisungen zwischen <?“ und ?>“ Tags
”
”
werden vom Server als PHP interpretiert. PHP kann prinzipiell alles was mit CGI möglich ist, versteht mit regulären Ausdrücken umzugehen, unterstützt Objekte und spricht
zahlreiche Protokolle wie IMAP40 , SNMP41 , NNTP42 , POP343 oder auch HTTP, was die
Kommunikation mit anderen Diensten erleichtert. Die wesentliche Stärke von PHP liegt
aber in der Unterstützung einer breiten Masse von Datenbanken. Zur Veranschaulichung
sollen hier nur einige aufgezählt werden:
40
Internet Message Access Protocol.
Simple Network Management Protocol.
42
Network News Transfer Protocol, RFC 977.
43
Post Office Protocol 3.
41
45
2 WEB-APPLIKATIONEN
• Oracle
• Informix
• Unix dbm
• dBase
• MySQL
• Sybase
Ein Beispiel wie man über PHP-Anweisungen Daten aus einer MySQL-Datenbank auslesen und damit ein HTML-File erstellen kann, wird in Listing 2.5 dargestellt:
Listing 2.5: telefon.php3: Auslesen von Tel.Nr. aus einer MySQL-Datenbank mittels PHP.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<HTML><HEAD>
<TITLE>telefon.php3</TITLE>
</HEAD><BODY>
<H2>Telefonnumern aus einer DB:</H2>
<?
mysql_connect("localhost","gwurze","gwurze")
OR die("Kann SQL-Server nicht erreichen");
mysql_select_db("gwurze") OR die("DB nicht erreichbar");
?>
<table border=1>
<tr><th>Name</th><th>Telefon</th></tr>
<?
$pers = mysql_query("SELECT NachN,VorN,Tel1,Tel2 FROM Personen");
while ($row=mysql_fetch_row($pers)) {
print"<tr><td>".$row[0]." ".$row[1]."</td>";
print"<td>".$row[2]." ".$row[3]."</td></tr>\n";
}
?>
</table>
</body></html>
Im gegebenen Fall wurde ein Apache Web-Server unter Linux mit PHP3 Unterstützung
verwendet, man spricht dann abgekürzt von einem LAMP-System: Linux, Apache, MySQL und PHP, siehe [Reeg, 1999; Zhang, 1999]. Den Vorteil, den man beim Einsatz
von PHP genießt, sind die einfach zu handhabenden Funktionen für die DatenbankManipulation:
• mysql_connect verbindet zum MySQL-Server mittels Benutzername und Passwort.
46
2 WEB-APPLIKATIONEN
• mysql_select_db wählt die zu benutzende Datenbank aus. Das gelingt nur, wenn
die entsprechenden Rechte am MySQL-Server für den Benutzer gesetzt sind.
• mysql_query sendet eine SQL-Query an den MySQL-Server. Im Beispielsfall werden aus der Tabelle Personen Daten selektiert. Die Funktion liefert bei Erfolg
einen positiven ,Result Identifier‘.
• mysql_fetch_row liest eine Zeile aus dem mittels ,Result Identifier‘ assoziierten
Ergebnis der SQL-Query und erzeugt damit ein Array. Die Einträge dieses Arrays
werden dann in eine HTML-Tabelle verpackt.
Mit diesem Rüstzeug eröffnet sich eine sehr komfortable Möglichkeit für Web-Applikation. Durch die rasche Weiterentwicklung von PHP wachsen auch die Marktanteile
gegenüber ASP und CF44 , die mit PHP schon jetzt einen ernstzunehmenden Gegner
haben. Jim White bezeichnet in [White, 1999] nicht umsonst PHP als Silent Killer“.
”
http://www.php.net
http://www.php.de
http://www.phpbuilder.com
http://phpwizard.net
2.3.5
Server-Side JavaScript
JavaScript ist Netscape’s Plattform-übergreifende und Objektorientierte Skriptsprache
[ssjsGuide, 1999]. Damit ist nach dem ersten Satz bereits offensichtlich, dass es sich
dabei um eine proprietäre Skript-Sprache handelt, die später aus marktwirtschaftlichen
Überlegungen zum offenen Standard wurde. Mit dem Namen JavaScript“ – ursprünglich
”
LiveScript – wollte man auf die syntaktische Verwandtschaft mit Java hinweisen, aber
primär vom damals einsetzenden Java-Hype“ profitieren.
”
Wird allgemein von JavaScript“ gesprochen, ist in den meisten Fällen die Version
”
der Client-Seite gemeint. Zusätzlich hat Netscape auch eine Version für die Server-Seite
44
Cold Fusion, ein kommerzielles Entwicklungs-Tool für Web-Applikationen.
47
2 WEB-APPLIKATIONEN
entwickelt, die für die typischen Anforderungen an eine Web-Applikation – RDBS- und
File-Handling – angepasst ist. Sowohl Client-Side (CS) und Server-Side (SS) JavaScript besitzen den selben Sprachkern, der als Core JavaScript bezeichnet wird. Abbildung 2.7 zeigt, dass durch Erweiterung der Funktionalität von Core JavaScript – sprich
zusätzlichen Objekten – SS oder CS JavaScript abgeleitet wird. Die wichtigsten Sprach-
Abbildung 2.7: Komponenten von JavaScript
Merkmale von JavaScript sind gleichzeitig die wichtigsten Unterscheidungsmerkmale zu
einer rein objekt-orientierten Sprache wie Java:
• JavaScript ist eine interpretierte Sprache im Gegensatz zu C/C++ oder Java.
• JavaScript ist untypisiert, d.h. der Typ einer Variable muss bei der Definition oder
beim Auftreten nicht festgelegt werden.
• Ein JavaScript Objekt ist ähnlich einem assoziativen Array (Hash).
• JavaScript ist prototype-based im Gegensatz zu class-based, d.h. es gibt keine
Unterscheidung zwischen Klasse und Instanz im Sinne des OO-Paradigmas.
• JavaScript realisiert über eine sogenannte prototype chain Vererbung. In [jsOOP,
1997] ist dieser nachgeahmte Vererbungs-Mechanismus genauer erklärt.
Da ein Web-Server mit SSJS Unterstützung als Client einer Datenbank agieren kann,
48
2 WEB-APPLIKATIONEN
drängte sich“ auch Netscape [ssjsGuide, 1999] die moderne 3-schichtige-Architektur na”
hezu auf“. Folgende Schichten lassen sich dabei identifizieren.
”
1. Web-Client: HTML-Parser und JavaScript Interpreter.
2. Web-Server: JavaScript Applikation mit JavaScript Runtime Engine.
3. Datenbank Server.
Das Pendant der SCRIPT-Tags45 auf der Client-Seite sind die Server-Tags auf der ServerSeite. Für die weitere Betrachtung soll Listing 2.6 als Beispiel dienen:
Listing 2.6: hello.html mit Server-Side JavaScript.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<HTML><HEAD>
<TITLE>Hello World with Server-Side JavaScript</TITLE>
</HEAD><BODY>
<H1>Hello World</H1>
Your IP address is
<SERVER>
write(request.ip);
writeln("<P>Last time you were "+client.oldname+".");
writeln("<P>This time you are "+request.newname+".");
client.oldname=request.newname;
if client.number == null
client.number = 0;
else
client.number = 1+parseInt(client.number,10);
</SERVER>
<FORM method="post" action="hello.html">
<INPUT type="text" name="newname" size=20>
<INPUT type="submit"><INPUT type="reset">
</FORM>
<P>You have been here <SERVER>write(client.number);<SERVER> times.
</BODY></HTML>
Das erste auffallende Merkmal ist die Mischung aus HTML und JavaScript-Anweisungen
innerhalb des Files. Beide JS-Blöcke – 1. Block: Zeile 6–15 und 2. Block: Zeile 20 – werden durch ein <SERVER>“-Tag eigeleitet und durch </SERVER>“ abgeschlossen. Die erste
”
”
45
CSJS-Anweisungen stehen innerhalb des HTML-Codes zwischen <SCRIPT> und </SCRIPT> Tags
49
2 WEB-APPLIKATIONEN
Aufgabe von hello.html“ ist die Ausgabe der IP-Adresse des Clients. Dazu stellt die
”
JavaScript Runtime Engine das Objekt request zur Verfügung, das diverse Informationen des Aufrufers in Properties des Objekts speichert. Wie aus Zeile 7 ersichtlich, kann
man über write(request.ip)“ bequem die entsprechende Adresse ausgeben.
”
Als zweite Aufgabe wird die Anzahl der Zugriffe vom gleichen Client gezählt. In Zeile
11-14 wird dem client Objekt, das Session-Informationen eines bestimmten Clients
speichert, die Property number“ beim ersten Aufruf hinzugefügt, die bei jeden weiteren
”
Request inkrementiert wird. In Zeile 20 erfolgt die Ausgabe der Zugriffe.
In der dritten Aufgabe wird in einem Formular nach dem Namen des Benutzers
gefragt, der beim nächsten Aufruf ausgegeben wird. Dazu wird ein Eingabe-Feld des
Formulars – in diesem Fall das Feld newname“ – automatisch zu einer Property des
”
request Objekts des in der Aktion des Formulars definierten Dokuments.
Um hello.html“ am Server zum Laufen zu bringen, muss es zuvor in eine binäre
”
Form kompiliert werden. Beim Netscape Enterprise Server übernimmt diese Aufgabe
ein Commandline-Tool mit dem Namen jsac46 . Der Aufruf
jsac -v -o hello.web hello.html
erzeugt aus hello.html“ ein Applikationsfile hello.web“, das abschließend nur mehr
”
”
am Server installiert werden muss. Durch Eingabe der Applikations-URL kann die Anwendung gestartet werden. Alternativ kann der Start auch über den Application Manager des Servers erfolgen, wie es beim Netscape Enterprise Server exerziert wird.
Neben Objekten des Session Management Service – request, client, session, server –
benötigt eine Web-Applikation in zweiter Linie Zugriffsmöglichkeiten auf verschiedene
Datenbanksysteme. Netscape stellt für diese Anforderung das LiveWire Database Service zur Verfügung, das Objekte für die Datenbank-Manipulation enthält. Mit folgenden
Datenbanksystemen können Transaktionen stattfinden:
• Informix
• DB2
• Oracle
• DB-Server, die den ODBC-Standard
• Sybase
verwenden.
Da LiveWire“ eine sehr proprietäre Lösung für diese Aufgabe ist, sollen hier nur im
”
46
JavaScript Application Compiler
50
2 WEB-APPLIKATIONEN
Überblick die Objekte und deren Funktionalität beschrieben werden. Um mit einer DB
Verbindung aufzunehmen, gibt es zwei Möglichkeiten: Mit dem vordefinierten Objekt
database, das eine einzelne Verbindung kapselt oder mit dem flexibleren Objekt DbPool,
das mehrere Verbindungen zu verschiedenen Datenbanken erlaubt. Ein neuer DB-Pool
wird mit dem folgenden Statement erzeugt:
pool = new DbPool("ORACLE","myserver","name","secret","test");
Der erste Parameter gibt den Typ des DB-Servers als vordefinierten String an, der zweite Parameter den Namen des DB-Servers und die restlichen Parameter Benutzername,
Passwort und Name der Datenbank. Daten können danach wie folgt ausgelesen werden:
conn = pool.connection("A Test Connection");
conn.SQLTable("select * from personen");
conn.release();
Über pool.connection() holt man sich ein Connection Objekt aus dem Pool. Die Methode SQLTable des Connection-Objekts generiert aus dem Ergebnis des SQl-Statements
automatisch eine HTML-Tabelle für die Ausgabe. Das abschließende conn.release()
entläßt“ die verwendete Verbindung wieder an den Pool. Mit nur vier Statements er”
reicht man bequem das gleiche Ergebnis, wozu andere Technologien 25 und mehr Anweisungen benötigen.
Ein wirklicher Brückenschlag zu Java gelingt Netscape mit dem Konzept von LiveConnect. Damit können JavaScript-Objekte direkt auf Java-Klassen oder CORBAObjekte zugreifen.
Server-Side JavaScript bietet zusammen mit den Erweiterungen LiveWire und LiveConnect einen vollständigen Baukasten“ für Web-Applikationen der verschiedensten
”
Art. Vorausgesetzt man nennt einen Netscape (seit kurzem iPlanet) Server sein Eigen.
Der Hyperwave Information Server stellt sein API ebenfalls in Form von JavaScript
Objekten zur Verfügung.
http://developer.netscape.com/docs
51
2 WEB-APPLIKATIONEN
2.3.6
Java Servlets
Java Servlets bieten eine sehr mächtige Möglichkeit, Web-Applikationen zu bauen, die
leicht auf bereits vorhandene Systeme (z.B.: Datenbanken) zugreifen können. Was ist
nun ein Servlet? Die Java Servlet Specification Version 2.2 [JServSpec2.2, 1999] definiert
Servlets wie folgt:
Ein Servlet ist eine Web-Komponente (im Engl.: web component), die über einen
Kontainer (Servlet Engine 47 ) gemanagt, dynamische Inhalte generiert. Servlets sind
,kleine‘ plattform-unabhängige Java Klassen, die nachdem sie in neutralen Bytecode kompiliert wurden, von einem Web-Server dynamisch geladen und zum Laufen
gebracht werden können. Servlets interagieren mit Web-Clients über ein RequestResponse-Schema (basierend auf das Hypertext Transfer Protocol), das vom Servlet
Kontainer implementiert wird.“
”
Vereinfachend kann ein Servlet auch mit einem Applet48 verglichen werden, das auf der
Server-Seite läuft und daher keine grafische Oberfläche besitzt. Folgende Vorteile bietet
der Einsatz von Java Servlets:
1. Plattform-Unabhängigkeit
2. Zugang zu allen Java API’s
3. Schneller als CGI Scripts49
4. Session-Management
Zur Ausführung des Servlets ist eine sogenannte Servlet Engine notwendig, die Anfragen
an bestimmte Servlets weiterleitet. Die Servlet Engine ist entweder direkt im Web-Server
integriert (JavaSoft Java Web Server) oder eine eigene Server-Applikation (Apache, siehe Abschnitt 4.2.4). Abbildung 2.8 zeigt, welche Methoden von der Servlet Engine
während des Servlet’s Life Cycle aufgerufen werden.
Die init() Methode dient zur
Initialisierung des Servlets, das geschieht entweder bei der ersten Verwendung des Servlets oder schon vorher. Die service() Methode kann mit der main() Methode einer
47
Eine Servlet Engine ist eine Server-Applikation, die Servlets ausführt.
Eine kleine in Java [Campione & Wallrath, 1999] geschriebene Applikation.
49
Gewöhnliche CGI’s spalten beim Request jeweils einen neuen Prozess ab, Servlets hingegen sind nur
einfache Threads.
48
52
2 WEB-APPLIKATIONEN
Abbildung 2.8: Die verschiedenen Stufen bei der Ausführung eines Servlets innerhalb der Servlet Engine. Quelle: [Mazzocchi & Fumagalli, 1998].
Java Applikation verglichen werden. Für das abschließende Aufräumen der besetzten
Resourcen wird die destroy() Methode verwendet.
Bei der Programmierung eines Servlets müssen diese Methoden entsprechend angepaßt werden, weiters muss das Servlet direkt oder indirekt das javax.servlet.Servlet
Interface implementieren. Der einfachere Weg ist das Überschreiben von Methoden einer
vorhandenen Servlet-Klasse, wie zum Beispiel der javax.servlet.http.HttpServlet
Klasse. Listing 2.7 zeigt ein vom HttpServlet abgeleites Servlet, das nur die doGet()
Methode überschreibt, die dem HTTP Get entspricht.
Listing 2.7: Hello, ein vom HttpServlet abgeleitetes Java Servlet
1
2
3
4
5
6
7
8
9
10
11
12
13
import javax.servlet.http.*;
import javax.servlet.*;
import java.io.*;
public class Hello extends HttpServlet {
public void doGet (HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
// get an PrintWriter from the response object
PrintWriter out = response.getWriter();
// prepare the response’s content type
response.setContentType("text/html");
// get the IP address of the client
String remoteAddress = request.getRemoteAddr();
53
2 WEB-APPLIKATIONEN
14
// print to the output stream!
out.println("Hi Man from <b>" + remoteAddress + "</b>");
15
16
17
}
}
Vorausgesetzt der Server unterstützt Java Servlets, kann nun das Servlet via WebBrowser50 aufgerufen werden, dass im Gegenzug ein simples – in unserem Fall sogar unvollständiges – HTML-Dokument an den Client sendet. Akzeptiert das Servlet den Aufruf, werden der doGet Methode zwei Objekte übergeben, eines der Klasse
HttpServletRequest und eines der Klasse HttpServletResponse. Das erste Objekt
(request) kapselt die ,eingehende‘ , das andere Objekt (response) die ,ausgehende‘
Kommunikation und vereinfacht das Handling mit dem Hypertext Transfer Protokoll.
Zum Beispiel wird in Listing 2.7, Zeile 11 der MIME51 -Type der HTTP-Antwort festgelegt.
Ein etwas sinnvollerer Anwendungsbereich von Servlets ist deren Einsatz zur Kommunikation mit Datenbanken. Die benötigte Schnittstelle zu Datenbanken wird durch
das JDBC52 API realisiert, dass für alle bekannten Datenbanken Treiber zur Verfügung
stellt. Ein Verbindungsaufbau mit einer MySQL Datenbank zeigt das folgende Java
Code-Stück aus der init() Methode eines Datenbank Servlets:
Class.forName("org.gjt.mm.mysql.Driver").newInstance();
dbc = DriverManager.getConnection("jdbc:mysql://localhost:3306/myDB?"
+"user=name&password=paswd");
Das erste Statement erzeugt ein Connection-Objekt, das die Verbindung zur Datenbank
kapselt. Dazu wird ein passender JDBC-Driver für die Datenbank benötigt, in unserem
Fall heißt dieser org.gjt.mm.mysql.Driver“. Das zweite Statement stellt nun eine
”
konkrete Verbindung zur Datenbank her und diese bleibt während der Lebenszeit des
Servlets aufrecht. Das Auslesen aller Datensätze einer Tabelle Produkte“ kann zum
”
Beispiel so geschehen:
1
Statement stmt = dbc.createStatement();
2
stmt.execute("select * from Produkte");
50
Aufruf über URL, zum Beispiel http://localhost/servlets/Hello.
Multipurpose Internet Mail Extensions, siehe [Freed & Borenstein, 1996].
52
Java DataBase Connectivity. Ein Java API zum Ausführen von SQL-Statements, stellt eine Reihe
von Klassen und Interfaces zur Manipulation von Datenbanken zur Verfügung.
51
54
2 WEB-APPLIKATIONEN
3
ResultSet rs = stmt.getResultSet();
Mit der Möglichkeit, SQL-Statements zu exekutieren (siehe Zeile 2), steht nun die gesamte Funktionalität der Datenbank zur Verfügung. Der Einsatz von RMI53 würde den Code
des Servlets noch zusätzlich vereinfachen und die Komplexität des Datenbank-Handlings
auf eine zusätzliche Schicht verlagern.
Die Servlets-Technologie wird von einer immer größer werdenden Anzahl von Servern
unterstützt und bietet eine gute Alternative zu CGI basierenden zeitkritischen Applikationen. Zusätzliches Session-Management erlaubt nun endgültig die Interaktivität zu
erhöhen. Mit Java hat man zudem den Vorteil, auf einer großen Menge von Plattformen
ohne Probleme lauffähige Applikationen erzeugen zu können und von der Mächtigkeit
der vorhandenen APIs zu profitieren. Zur Zeit ist die Java Servlet API Specification
Version 2.2 unter http://java.sun.com/products/servlet/2.2 verfügbar.
http://java.sun.com/products/servlet/index.html
http://java.sun.com/docs/books/tutorial/servlets/TOC.html
http://java.sun.com/products/jdbc
2.3.7
JavaServer Pages
Eine weitere Möglichkeit, der Anforderung nach dynamisch generierten Inhalten im
WWW nachzukommen, ist der Einsatz von JavaServer Pages, kurz JSP. Mit JSP soll es
per definitionem noch leichter möglich sein, die Präsentations-Logik von der ApplikationsLogik zu trennen. Die JSP Technologie ist in enger Verbindung mit Java Servlets des
letzten Abschnittes zu sehen, da jeder JSP Request ein Java Servlet erzeugt, das die
eigentliche Ausgabe erledigt. Die Verarbeitung von JSP Files (.jsp) erfolgt ebenfalls
durch einen Satz von Java Servlets am Server.
Die JavaServer Pages Spezifikation 1.1 [JSPSpec1.1, 1999] definiert nun JSP wie folgt:
A JSP page is a text-based document that describes how to process a request
”
53
Remote Method Invocation, siehe http://java.sun.com/docs/books/tutorial/rmi.
55
2 WEB-APPLIKATIONEN
to create a response. The description intermixes template data with some
dynamic actions and leverages on the Java Platform.“
Dazu kombiniert ein JSP Dokument Standard-HTML mit speziellen JSP Elementen,
die von der sogenannten JSP Engine 54 vor dem Senden des Dokuments verarbeitet und
durch entsprechendes HTML ersetzt werden. Wie bei der Servlet-Technologie des letzten
Abschnittes hat man sämtliche Java APIs zur Applikations-Entwicklung zur Verfügung.
Listing 2.8 zeigt ein simples JSP Beispiel, das die java.util.Date Klasse verwendet,
um das aktuelle Datum und die aktuelle Uhrzeit auszugeben.
Listing 2.8: HelloWorld.jsp
1
2
3
4
5
6
7
<HTML><HEAD>
<TITLE>Hello World with Java Server Pages (JSP)</TABLE>
<%@ page import="java.util.Date" %>
</HEAD><BODY>
<H1>Hello World !!</H1>
The current date is <%= new Date() %>.
</BODY></HTML>
Ein JSP-Block startet in den meisten Fällen mit der Zeichenfolge ,<%‘ und endet mit
der Zeichenfolge ,%>‘. Die page import Anweisung in Zeile 3 von Listing 2.8 importiert
die Klasse java.lang.Date, die in Zeile 6 über ein new Date() instanziiert wird. Beim
Parsen des JSP Dokuments ersetzt die JSP Engine diese Anweisungen mit den enstprechenden Ausgaben: Zeile 3 erzeugt keine Ausgabe und in Zeile 6 erscheint Datum und
Uhrzeit in textueller Form.
Wie bei den bereits beschriebenen Web-Technologien, gelingt es auch mit JSP relativ
leicht, mit einer Datenbank zu interagieren. Bevorzugt übernehmen sogenannte JavaBeans 55 diese Aufgabe, die über spezielle JSP-Anweisungen aufgerufen werden. In Listing 2.9 Zeile 5 wird das Bean JSPMySqlBean von Listing 2.10 instanziiert und erhält
den speziellen Namen bean_test.
Listing 2.9: Bean.jsp zeigt wie eine Bean-Komponente innerhalb einer JSP aufgerufen wird.
1
2
54
55
<HTML><HEAD>
<TITLE>JSP and Java Beans</TITLE>
Wird auch als JSP container bezeichnet.
Eine wiederverwendbare Software-Komponente, die über ein Builder-Tool visuell manipuliert werden
kann, siehe http://java.sun.com/beans.
56
2 WEB-APPLIKATIONEN
3
4
5
6
7
8
</HEAD><BODY>
<H1>Use a Java Bean to connect to a MySql DB</H1>
<jsp:useBean id="bean_test" class="JSPMySqlBean" />
<%= bean_test.generateHtmlTable() %>
</BODY>
</HTML>
Die Methode generateHtmlTable() des Beispiel-Beans (Listing 2.10), die in Zeile 6
(Listing 2.9) aufgerufen wird, baut mit den bereits bekannten Einstellungen über JDBC
eine Verbindung mit einer MySQL-DB auf. Die Anweisungen zum Verbindungsaufbau
und Ausführen einer Query am DB-Server sind ident mit den Beispielen des letzten
Abschnittes, lediglich die Ausgabe hat sich dahingehend geändert, dass explizit HTMLCode beim Aufruf erzeugt und retourniert wird.
Listing 2.10: Die Methode generateHtmlTable() der JSPMySqlBean Klasse liest Beispieldaten
aus einer MySQL-DB aus und formatiert diese als HTML-Tabelle.
1
2
3
import java.sql.*;
import java.net.URL;
import java.io.Serializable;
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class JSPMySqlBean implements Serializable {
public static String generateHtmlTable() throws Exception {
String url;
Connection dbc;
String html_string = new String("No Connection");
try {
Class.forName ("org.gjt.mm.mysql.Driver");
url = "jdbc:mysql://www.amft.tu-graz.ac.at:3306/test";
dbc = DriverManager.getConnection(url, "test", "test");
String query = "select * from Products ";
Statement statement = dbc.createStatement();
ResultSet resultSet = statement.executeQuery (query);
html_string = "<TABLE BORDER=1>";
while (resultSet.next()) {
html_string += "<TR><TD>"+resultSet.getString(1)+"</TD>";
html_string += "<TD>"+resultSet.getString(2)+"</TD></TR>\n";
}
html_string += "</TABLE>";
57
2 WEB-APPLIKATIONEN
23
}
catch (Exception e) {
System.out.println(e.toString());
}
return html_string;
24
25
26
27
28
29
}
}
Ausgehend von diesen und den bereits erwähnten Java-bezogenen Technologien, definiert
SUN in [JServSpec2.2, 1999] eine Web-Applikation als ein Zusammenspiel folgender
Elemente:
• Java Servlets
• Utility Classes
• JavaServer Pages
• HTML, DHTML, Images, Sound.
• Java Applets
• Beschreibende Meta-Information, die
alle angeführten Elemente verknüpft.
• JavaBeans
Die Meta-Information der gesamten Web-Applikation wird in einem sogenannten Web
Application Deployment Descriptor File (web.xml) gehalten, das entsprechend den XMLKonventionen mit dem folgenden DOCTYPE versehen ist:
<!DOCTYPE webapp
SYSTEM "http://java.sun.com/j2ee/dtds/web-app_1_2_.dtd"
Nach Abschluß der Entwicklung werden alle Elemente – sprich Files – der Web-Applikation, mit dem Java Archive Tool (JAR) in ein WAR 56 File gepackt. Damit kann die
gesamte Web-Applikation als ein einziges File auf einen anderen Server, der auch JSP
und Java Servlets unterstützt, übertragen und zur Anwendung gebracht werden. In
diesem Zusammenhang bezeichnet SUN den Server als Web Container, die JSP engine
als JSP Container und die Servlet engine als Servlet Container.
SUN bietet mit diesem Konzept eine sehr durchdachte Gesamtlösung für Web-Applikationen auf Java Basis. Es scheint, dass die teilweise sehr jungen“ Spezifikationen
”
einzelner Java-Technologien auch langsam Reife erlangen. Eine ausgereifte Spezifikation
ist Grundvoraussetzung neben Robustheit, Stabilität und Geschwindigkeit, möchte man
56
Web Archive
58
2 WEB-APPLIKATIONEN
das Vertrauen der Web-Programmierer gewinnen. Diese greifen aber auch gerne auf
alternative, sich im Trend befindliche offene Lösungen wie derzeit PHP zurück, das in
punkto Datenbank-Handling der JSP-Technologie leicht Paroli bieten kann.
http://java.sun.com/products/jsp
http://java.sun.com/products/jsp/whitepaper.html
http://www.klomp.org/gnujsp
http://jakarta.apache.org
59
3 Hyperwave Information Server
The system should allow access to all kinds of
information one can think of.
(Multimedia Axiom)a .
Req. G.1
a
Hyper-G Specification of Requirements [Kappe, 1991].
Die Geschichte des Hyperwave Information Server – kurz HWIS – ist ein Beispiel, wie
aus einem vielleicht visionär anmutenden wissenschaftlichen Kleinstprojekt eine eigenständige und gewinnbringende Unternehmung entstehen kann. Glaubt man jedoch den
Angaben des Netcraft Server Surveys (siehe Tabelle 2.1) so leisten“ sich gerade einmal
”
719 Web-Sites einen HWIS. Leicht übersehen wird dabei, dass Netcraft nur die von außen sichtbaren HWIS in Betracht ziehen kann, die zahlreich hinter Firewalls verborgenen
HWIS namhafter Firmen – Siemens, Porsche, Motorola, um nur einige zu nennen – fehlen natürlich im Server Survey. Hyperwave sieht aber gerade den verdeckten“ Bereich
”
des Intranets als Kerngeschäft ihres Servers.
Dieses Kapitel untersucht im Schwerpunkt den HWIS bezüglich seiner Tauglichkeit
als Plattform für Web-Applikationen. Abschnitt 3.1 konzentriert sich auf die allgemeinen Eigenschaften des Servers, von den Leistungsmerkmalen beginnend über die
Software-Architektur bis zu den Konfigurationsmöglichkeiten. Anschließend werden im
Abschnitt 3.2 die Programmiermöglichkeiten des Servers näher betrachtet und auf ihre
Leistungsfähigkeit hin untersucht.
60
3 HYPERWAVE INFORMATION SERVER
3.1
Grundlagen
3.1.1
Entstehung
3.1 GRUNDLAGEN
Im Jahre 1989 begann ein kleines Team um Herman Maurer, Ivan Tomek und Fritz
Huber des IICM (Institute for Information Processing and Computer Supported New
Media) an der TU-Graz, Anforderungen an ein optimal large-scale Hypermedia System“
”
zu sammeln. Die konzeptionellen Schwächen der um diese Zeit vorherrschenden Informationssysteme wie WAIS 1 , Gopher 2 und das World Wide Web 3 sollten dabei beseitigt
werden. Demgegenüber versuchte man, zukunftsweisende Ansätze wie aus Ted Nelson‘s
Xanadu 4 zu übernehmen und auf eigene Weise umzusetzen. Unter dem Namen HyperG – das G“ steht für Graz – begann 1990 mit Unterstützung des österreichischen Mini”
steriums für Wissenschaft und Kunst, die Entwicklung eines Prototypen. 1991 erstellte
Frank Kappe ein erstes Architectural Design“ [Kappe, 1991] aus den gesammelten Re”
quirements [Kappe et al., 1991] und implementierte bald darauf zusammen mit Gerald
Pani den ersten Hyper-G Server und Client. Zum erstmaligen Einsatz in der Praxis
kam der Hyper-G Server 1992 als Informationssystem der TU-Graz, besser bekannt als
TUGinfo. Im gleichen Jahr adaptierte die European Space Agency (ESA) den Server für
ein Guide and Directory“ System. Damit wurde der Hyper-G Server zur Produktreife
”
herangeführt. 1993 wurde der Hyper-G Client für Windows (Amadeus) und 1994 der
Hyper-G Client für Unix-Systeme (Harmony) entwickelt. Zum wissenschaftlichen gesellte sich zusehends auch der kommerzielle Erfolg von Hyper-G, der durch die Gründung
einer AG und der damit verbundenen Namensänderung auf Hyperwave, Anfang 1997
sprichwörtlich gekrönt wurde. Zur Zeit ist die Version 5.1 des HWIS aktuell.
Hyperwave beschäftigt derzeit über 100 Mitarbeiter5 , verfügt über Niederlassungen in
Graz (Entwicklung), München, Genf, sowie Boston und zählt zu den Start-up“ Unter”
nehmungen im IT-Bereich. Knowledge-Management und sogennante Informationsportale im Intranet werden zunehmend zum Kerngeschäft von Hyperwave.
1
Wide Area Information Server war eine reine Suchmaschine. Startete um 1989.
Ein Campus-Informationssystem der University of Minnesota. Startete um 1991.
3
1989 war nicht sicher, ob sich das WWW-Konzept durchsetzen würde.
4
Siehe [Xanadu, 2000]: Project Xanadu was an explicit inspiration for Hyperwave.“
”
5
Tendenz stark steigend.
2
61
3.1.2
3.1 GRUNDLAGEN
Design Ziele
Aus den erwähnten Requirements für ein second generation Hypermedia System“ [Mau”
rer, 1996] des letzten Abschnittes, wurden in abgekürzter Form die folgenden Design
Ziele [Andrews et al., 1994] festgelegt:
1. Provide orientational and navigational aids.
2. Provide automatic structuring and maintenance.
3. Reduce fragmentation across servers.
4. Support user identification and access control.
5. Support multilinguality.
6. Maintain interoperability with existing systems.
Unter der im letzten Punkt angeführten Interoperabilität ist die Möglichkeit gemeint,
mit verschiedenen Protokollinstanzen kommunizieren zu können. Eine zurückblickend
richtungsweisende Entscheidung, da man sich dadurch – um es bildlich zu formulieren –
automatisch immer ins richtige Boot setzt, sprich das zur Zeit gängigste Protokoll leicht
unterstützen kann6 . Zur damaligen Zeit sollten Gopher, WWW und Hyper-G Clients
auf den Server zugreifen können.
Das viel zitierte Lost in Hyperspace“ Syndrom, damit verbunden der berühmte Ser”
ver Error-Code 404 und Begriffe wie Dangling Links“ und Orphans“, motivierte die
”
”
Forderung nach automatischer Strukturierung eingefügter Dokumente. Nicht der User
muss sich um die Validierung von Links in Dokumenten kümmern, sondern der Server hat diese Aufgabe automatisch zu erledigen. Bei der Anforderung eines Dokuments
sollen dynamisch ergänzte Navigationshilfen die Orientierung im Informationsraum erleichtern.
Diese aus den Requirements [Kappe et al., 1991] hervorgegangenen Design Ziele für
ein Informationssystem korrelieren in immer stärkeren Maße mit den Anforderungen
derzeitiger Web-Applikationen. User-Management, Multilingualität und Interoperabilität zählen oft zu den Kernaufgaben moderner Web-Applikationen. Ein Server, der
für derartige Aufgaben bereits konzeptionell gerüstet ist, eignet sich daher bestens als
Applikationsplattform.
6
Das sich HTTP als Standard durchsetzen würde, konnte Anfang der 90-Jahre noch niemand wissen.
62
3.1.3
3.1 GRUNDLAGEN
Features
Die Design Ziele der frühen Anfänge des HWIS – siehe Abschnitt 3.1.2 – haben sich
trotz des rasanten Siegeszuges“ des WWW nicht gravierend geändert. Einzig der Web”
Browser (früher WWW-Browser) hat sich als Client7 für den HWIS durchgesetzt.
Einer der Erfolgsfaktoren des HWIS ist die Flexibilität und Dynamik, mit der die
Dokument-Struktur des Servers umgesetzt, sprich für das Ziel Interface Web-Browser
adaptiert wird (Erstellung einens dynamischen HTML-Dokuments). Dazu werden die
eingefügten Dokumente nicht auf herkömmliche Art statisch in einem File-Baum verwaltet – vergleiche Abschnitt 4, Apache HTTP Server – sondern dynamisch in einem sogenannten Object Repository, einer objekt-orientierten Datenbank. Das Struktur-Element
Collection wird bei diesem Ansatz zur zentralen Verwaltungseinheit. Eine Collection
ist vergleichbar mit einem Verzeichnis eines hierarchischen File-Systems, das weitere
Files und Verzeichnisse enthalten kann. Analog kann eine Collection wieder weitere
Dokumente und Collections beinhalten. Mit der vorgegebenen Root-Collection (Hyperwave Root Collection) wird eine Collection-Hierarchie erzeugt, die formal mathematisch
gesprochen, einem gerichteten azyklischen Graph entspricht. Die vordefinierte Informationsarchitektur des HWIS zwingt auch indirekt den User, mit Disziplin und Ordnung
seine Dokumente am Server zu verwalten.
Der HWIS erzeugt dynamisch entsprechende HTML-Dokumente, um in der CollectionHierarchie via Web-Browser navigieren zu können (siehe Abbildung 3.1). Damit werden
alle Objekte am Server – im übertragenen Sinn – automatisch verlinkt und bleiben stets
in einem konsistenten Zustand. Orphane sind daher ausgeschlossen.
In der folgenden Aufzählung werden die wichtigsten Features des Hyperwave Information Servers kurz erläutert. Für genauere Informationen über die Leistungsmerkmale
des Servers sei auf [HwisUser, 1999] oder [Maurer, 1996] verwiesen.
1. Collection: Ist die zentrale“ Container-Klasse des HWIS. Diese Klasse leitet
”
zusätzlich verschiedene Unterklassen mit spezialisierten Eigenschaften ab. Das
Attribut CollectionType eines Container-Objekts entscheidet über den genauen
Typ. In der Grundkonfiguration des HWIS sind vier Unterklassen vordefiniert:
• Cluster: Kombiniert mehrere Objekte in einem Container. Diese Klasse
findet sehr gerne in Web-Applikationen Anwendung.
7
Das W3C verwendet den allgemeineren Begriff User Agent.
63
3.1 GRUNDLAGEN
Abbildung 3.1: Hyperwave Collection-Hierarchie.
• Sequence: Die Objekte einer Sequence werden automatisch sequentiell verlinkt. Die Reihenfolge ist abhängig vom Attribut Sequence des Objekts.
• MultiCluster: Alle Elemente des MultiClusters werden zusammengestzt in
einem Dokument dargestellt.
• AlternativeCluster: Enthält zum Beispiel mehrere Dokumente mit gleichem Inhalt, aber verschiedenem Format (HTML, PDF, PS). Beim Request
wird entsprechend den Benutzereinstellungen entschieden welches Dokument
an den Client geschickt wird.
2. Attribute: Zu jedem Objekt am HWIS (Dokument, Collection, etc.) werden
zusätzliche Metadaten (Attribute) in Form eines getrennten Objekts im Repository
gespeichert. Man unterscheidet grundsätzlich vom System und vom User definierte
Attribute.
3. Zugriffskontrolle: Jedes Objekt am HWIS besitzt definierte Zugriffsrechte, was
das Lesen, Schreiben und Löschen betrifft. Ein hilfreiches Tool für die Verwaltung
der Benutzungsrechte wird durch den integrierten Rights Wizard zur Verfügung
64
3.1 GRUNDLAGEN
gestellt.
4. Link Management: Die Konsistenz der Links wird automatisch vom Server gewährleistet. Links werden als eigene Objekte, getrennt von den Dokumenten im
Repository gespeichert. Beim Einfügen eines Dokuments werden alle vorkommenden Links extrahiert und im Gegenzug – das Dokument wird angefordert – auch
wieder dynamisch ins Dokument eingefügt. Source und Destination Anchor Objekte realisieren die geforderte Bidirektionalität.
5. User-Management: User und User-Gruppen werden in einem hierarchischem
Schema verwaltet. Zum Beispiel können die Zugriffsrechte einer Gruppe auf einen
bestimmten Bereich des Servers restringiert werden.
6. Session-Management: Jeder User kann individuell Einstellungen für das UserInterface treffen, etwa ob dieses in deutscher oder englischer Sprache gehalten sein
soll.
7. Suche: Der HWIS ist mit einer integrierten Such-Funktionalität ausgestattet. Die
Suche im Volltext oder den Metadaten der Objekte ist möglich, zudem kann sogar
nach Links gesucht werden. Der Such-Bereich (Search Scope) kann individuell
angepasst werden.
8. Online Publizieren: Kleine Dokumente können direkt über HTML-Formulare
oder über die Publish“ Funktion des Web-Browsers (Netscape Navigator, Inter”
net Explorer) eingefügt werden. Auf gleiche Art können Collections erzeugt und
gelöscht, oder Attribute verändert werden.
9. Online Administration: Die Administration des HWIS kann ebenso über den
Web-Browser erfolgen. Nach erfolgreicher Authentifizierung erlaubt das Tool WaveSetup die Konfiguration des Servers. Abbildung 3.2 zeigt einen Ausschnitt der
vielfältig vorhandenen Konfigurationsmöglichkeiten.
10. Trennung von Inhalt und Darstellung: Layout und Navigation können zentral
geändert und angepasst werden. Der User braucht sich um diese Belange nicht
mehr zu kümmern. Ein Corporate Design ist wesentlich einfacher realisierbar.
11. Release Flow: Wird auch als Document-Staging bezeichnet. Ein Dokument
durchläuft vor der endgültigen Publikation mehrere definierte Schritte und wird
65
3.1 GRUNDLAGEN
Abbildung 3.2: Online Administration des HWIS mittels WaveSetup.
erst released“, wenn zum Beispiel ein Review von verschiedenen Personen durch”
geführt wurde. Für weitere Informationen, siehe [HwisUser, 1999, Abs. 2.3.5.10]
12. Versionskontrolle: Der HWIS erlaubt die Versionierung von Dokumenten. Dazu müssen die Dokumente explizit eingecheckt werden. Zusätzliche Features wie
Version History erleichtern die Verwaltung. Über sogenannte Configurations können ganze Collection-Hierarchien versioniert werden. Für weitere Informationen,
siehe [HwisUser, 1999, Abs. 2.3.5.11].
13. Diskussionsforum: Der HWIS erlaubt die Verwaltung von Newsgroups – meist
thematisch verwandt – in einem sogenannten Diskussionsforum. Die Funktionalität
ist vergleichbar mit Usenet Newsgroups. Für weitere Informationen, siehe [HwisUser, 1999, Abs. 2.5].
14. Document Classes: Der HWIS bildet das objekt-orientierte Paradigma auf Dokumente am Server ab. Damit können Dokumente mit einem bestimmten Aussehen
und erweiterter Funktionalität ausgestattet werden. Document Classes werden in
Abschnitt 3.2.3 ausführlich behandelt.
66
3.1 GRUNDLAGEN
15. Sicherheit: Der HWIS verfügt über ein ausgefeiltes Sicherheitsmodell. Einerseits
kann die Zugriffsberechtigung jedes Dokuments explizit festgelegt werden (siehe
Punkt 2), andererseits unterstützt der HWIS auch die moderne und verbreitete
SSL-Verschlüsselungstechnik.
Diese 15 Punkte lassen erkennen, dass der HWIS besonders für die effiziente Verwaltung
von großen Informationsmengen konzipiert und getrimmt wurde. Eine Aufgabe, die in
vielen Unternehmungen steigende Bedeutung findet.
3.1.4
Server Architektur
Wie viele moderne Server-Systeme ist der Hyperwave Information Server kein monolithischer Block, der durch einen einzelnen Prozess realisiert wird. Schon 1994 (siehe Abbildung 3.3) setzten die Entwickler auf die Vorteile eines verteilten Systems und sahen
für die verschiedenen Aufgaben unabhängige Module (eigene Prozesse) vor. Diese kommunizieren über Internet Sockets miteinander und werden von einem Kontrollprozess
(hwservercontrol) gestartet und überwacht. Das erhöht die Flexibilität, Skalierbarkeit
und Performance des Systems und verspricht auch erhebliche Wartungsvorteile.
Abbildung 3.3: Server Architektur anno 1994. Quelle: [Andrews et al., 1994].
Die verschiedenen Module können jeweils einer bestimmten Schicht (Layer) des HWIS
67
3.1 GRUNDLAGEN
zugeordnet werden. Prinzipiell wird der Server in 3 Schichten unterteilt (vergleiche dazu Abbildung 3.4):
1. Protocol Conversion Layer: Diese Schicht macht aus dem HWIS einen multiprotokoll Server. Sogennante Gateways transformieren verschiedene Protokolle8
in das serverspezifische HG-CSP9 . Als WaveMaster wird das WWW-Gateway bezeichnet.
2. Session Layer: In dieser Schicht werden die Anfragen der einzelnen Gateways
koordiniert und auf die Sever-Prozesse der Database Layer aufgeteilt. Für jede
Client-Verbindung wird ein eigener leichtgewichtiger Prozess erzeugt, der erst beim
Abbruch der Verbindung beendet wird.
3. Database Layer: Hier erfolgt die eigentliche Verwaltung der gespeicherten Objekte. In dieser Schicht befinden sich die drei folgenden Server: Object Server, Full
Text Server und Document Cache Server.
Bezugnehmend auf Abbildung 3.4 können diesen Schichten konkrete Prozesse zugeordnet
werden. Im Folgenden werden die Aufgaben dieser Prozesse einzeln kurz bschrieben:
1. Protocol Conversion Layer:
• wavemaster: Ist das Front-End“ des ganzen Systems. Generiert dynamisch
”
HTML-Seiten, die an den Web-Browser geschickt werden. Enthält in Form
von Templates und Dokument-Klassen die Logik der Applikation. Zusätzlich sind die benötigten PLACE und JavaScript Interpreter in diesem Modul
integriert.
• waveslave: Bildet zusammen mit dem wavemaster einen Application Server.
Die Instanzen des Application Servers können auf verschiedenen Rechnern disloziiert sein. Eine angenehme Eigenschaft für die Applikations-Entwicklung.
2. Session Layer:
8
9
Früher HTTP, Gopher und SNMP jetzt nur mehr HTTP.
Hyper-G Client Server Protocol ist ein verbindungsorientiertes (connection-oriented ) Protokoll mit
der well-known“ Port-Nummer 418 (RFC 1700 [Reynolds & Postel, 1994]).
”
68
3.1 GRUNDLAGEN
Abbildung 3.4: Server Architektur anno 1999. Quelle: [Kappe, 1999].
• hgserver: Ein leichtgewichtiger“ Koordinator-Prozess, der für jede Verbin”
dung extra erzeugt wird. Bei Beginn werden Paramater für die Kommunikation ausgehandelt, wie zum Beispiel Identifizierungsdaten. Dieser Prozess
verhält sich als Client zu den Prozessen der Database Layer.
3. Database Layer:
• wavestore: Ist der eigentliche Object Server. Die Objekte werden in einer multi-user, read-write Datenbank verwaltet. Die native“ Datenbank des
”
HWIS kann auch durch eine Oracle-DB ersetzt werden.
• dcserver: Steht für Document Cache Server “. Hier werden die eigentlichen
”
Dokumente des HWIS gehalten. Entweder liefert dieser Server dem Client
angeforderte Dokumente oder akzeptiert das Speichern übertragener Dokumente.
• ftserver: Steht für Full Text Server“. Dieser Server verwaltet Indizes von
”
Wort-Listen. Beim Einfügen eines neuen Dokuments werden automatisch
indizierte Attribute in diese Datenstruktur aufgenommen. Bei einer Suche
liefert dieser Server bereits eine gereihte Liste von Treffern.
69
3.1 GRUNDLAGEN
Für eine ausführlichere Beschreibung der Architektur und Prozess-Struktur sei auf [HwisProg, 1999] verwiesen.
3.1.5
Unterstützte Plattformen
Derzeit ist der Hyperwave Information Server für Windows NT 4.0 und zahlreiche UnixPlattformen verfügbar. Folgende Unix-Derivate werden unterstützt:
• DEC UNIX 4.0
• Linux 2.x
• HP-UX 10.20
• SNI Reliant UNIX 5.43
• IBM AIX 4.3
• SUN Solaris 2.5.1
3.1.6
Installation
Unter Windows NT führt ein grafisches Setup-Programm durch die Installation des
HWIS und der mitgelieferten Add-Ons“. Die Installatiosprozedur gestaltet sich dabei
”
in der für Windows gewohnten Art und Weise. Zu den Add-Ons“ zählen:
”
1. Hyperwave Publishing Wizard
2. ODMA10 Support
3. Hyperwave Virtual Folders
4. Hyperwave Office Extensions
Für die Installation unter UNIX muss ein eigener User-Account mit dem empfohlenen
Namen hwsystem und einer C-Shell eingerichtet werden. Darauf startet man einfach
unter dem User hwsystem das Perl-Skript install von der Installations-CD, das durch
die einzelnen Schritte der Installation führt.
Sowohl für Windows NT und UNIX ist das Installationsprozedere in eigenen Guides
detailliert erklärt. Siehe dazu [HwisNtInstall, 1999] und [HwisUnInstall, 1999].
10
Open Document Management API.
70
3.1.7
3.1 GRUNDLAGEN
Konfiguration
Die Konfiguration wesentlicher Parameter des HWIS kann wie in Abbildung 3.2 dargestellt, über das Programm WaveSetup direkt im Web-Browser erfolgen.
Größere
Kontrolle über den Server erhält man dennoch nur durch direktes Editieren des HauptKonfigurationsfiles .db.contr.rc, das mit seinen Grundeinstellungen wie folgt aussieht:
Listing 3.1: .db.contr.rc Grundkonfiguration
1
2
3
4
5
6
7
8
9
10
11
12
# @(#)[HyperWave] [HGC-T] db.contr.rc
2.02 [server configuration file] [Gerald Pani]
MAIN::DATABASE = NATIVE
MAIN::PROCESS = WAVEMASTER
WAVEMASTER::PORT = 81
WAVEMASTER::ERRORS = log/wave-err.log
WAVEMASTER::LOG = log/wave.log
WAVEMASTER::COMMAND = wavemaster -scope WAVEMASTER
WAVEMASTER::USER_PLACE_TEMPLATES = true
MAIN::PROCESS = WAVENOTIFY
WAVENOTIFY::COMMAND = wavenotify
WAVENOTIFY::LOG = log/notify.log
13
14
15
16
17
18
# database nice factors
WAVESTORE::NICE_FACTOR = 3.0
WAVEORACLE::NICE_FACTOR = 3.0
ENVIRONMENT::DIRdbs = $HOME/wavestore
WAVESETUP::PORT = 9999
Die Bedeutung der meisten Einstellungen geht bereits aus den Namen hervor, wie etwa
das Port des Wavemasters, das in der Beispielkonfiguration in Listing 3.1 auf 81 gesetzt
wurde, um nicht mit einem parallel laufenden Apache HTTP Server zu kollidieren. In
der Entwicklungsphase startet man fast immer einen Wavemaster-Prozess lokal auf seinem Rechner oder unter seinem eigenen Account und entwickelt an diesen Templates.
Dazu müssen die Wavemaster-Einstellungen im .db.contr.rc entsprechend angepasst
werden, etwa zu:
WAVEMASTER::HOSTNAME = lisa.tu-graz.ac.at
WAVEMASTER::DIR = $HOME/wavemaster
WAVEMASTER::LOG_COMMON = $HOME/log/wave.log
71
3.2 PROGRAMMIERUNG
Für eine vollständige Liste der möglichen Konfigurationsparameter siehe Hyperwave Administrators Guide [HwisAdmin, 1999, Abs. 2].
3.2
Programmierung
Wie in Abschnitt 3.1.3 bereits erwähnt, trennt der HWIS strikt die Darstellung eines
Dokuments von seinem Inhalt. Die äußere Erscheinung – oder besser das Layout – eines
Dokuments kann dadurch individuell den gewünschten Anforderungen (typisches Beispiel
wäre eine Corporate Design) angepasst werden. Der HWIS realisiert diese Trennung von
Inhalt und Darstellung über sogenannte Templates. Ein Template ist ein File, das aus
PLACE (siehe Abschnitt 3.2.1) und JavaScript (siehe Abschnitt 3.2.2) Anweisungen,
sowie aus HTML-Tags besteht und bei einem Client-Request vom HWIS abgearbei”
tet“ wird. Als Resultat wird ein dynamisch erzeugtes HTML-Dokument an den Client
gesendet. Die beschriebene Funktionalität steckt im wavemaster Modul des HWIS, etwas exakter in den Files des wavemaster Verzeichnisses der HWIS-Installation. Das
Haupt-Template des HWIS wird als master.html bezeichnet und ist der Startpunkt aller Client-Requests. Für eine genaue Beschreibung des HWIS Template-Mechanismus
sei auf Abschnitt 1 des PLACE Workshops [HwisPlaceWS, 1999] verwiesen.
Web-Applikationen auf Basis des HWIS adaptieren primär die vorgefertigten Templates
nach ihren Bedürfnissen und greifen dabei indirekt über PLACE und JavaScript auf
das API des HWIS zurück. Abschnitt 3.2.1 stellt kurz die ältere Variante der TemplateProgrammierung über die proprietäre Meta-Sprache PLACE vor. Abschnitt 3.2.2 erklärt
die modernere Form der Programmierung mittels server-seitigem JavaScript (SSJS). Abschnitt 3.2.3 beschäftigt sich abschließend mit dem völlig neuartigem Konzept sogenannter Document Classes, die mit der Version 5.0 des HWIS eingeführt wurden.
3.2.1
PLACE
Der Name PLACE leitet sich von den in der Sprache vorkommenden Platzhaltern (engl.
Placeholders) ab. PLACE besteht in der Tat aus einer Unmenge von Platzhaltern, die
ihrerseits bestimmte Teilinformationen von Server-Objekten repräsentieren. Sobald man
auf ein bestimmtes Objekt am Server zugreift, verarbeitet der Wavemaster ein definiertes
PLACE Template und liefert als Ergebnis ein HTML-Dokument. PLACE Templates
bestehen aus HTML und PLACE Anweisungen, dabei beginnt und endet jedes PLACE
72
3.2 PROGRAMMIERUNG
Statement mit zwei Prozentzeichen (%%), zum Beispiel:
%%# So sieht ein Kommentar in PLACE aus %%
PLACE unterstützt dabei zahlreiche gewohnte Konstrukte einer Programmiersprache.
Dennoch muss an dieser Stelle betont werden, dass PLACE in einigen Bereichen deutliche
Einschränkungen gegenüber einer herkömmlichen Programmiersprache besitzt:
1. PLACE ist keineswegs objekt-orientiert, obwohl die Notation sehr häufig den Anschein erweckt (zum Beispiel: %%object.title%%).
2. Der fundamentale Zuweisungsoperator fehlt gänzlich. Es ist also nicht möglich
eigene Variablen zu definieren.
3. Arithmetische Operationen können nicht ausgeführt werden.
Die damit limitierte Funktionalität von PLACE entspricht aber dem eigentlichen Zweck
der Sprache, nämlich schnell und mit einfachen Mitteln11 das standardmäßige UserInterface zu verändern. Dementsprechend sind nun die Sprachkonstrukte und Features
von PLACE gestaltet:
• Programmflusskontrolle: Der Programmfluss kann über if“ oder while“ An”
”
weisungen kontrolliert werden. PLACE unterstützt die gewohnten Vergleichsoperatoren für Ausdrücke, die über UND (&&), ODER(||) und NICHT (!) verknüpft
werden können. Beispiel eines einfachen if“-Blocks:
”
%%if object.title == "Test"%%
Das ist EIN Test Objekt!
%%else%%
Das ist KEIN Test Objekt!
%%endif%%
Beispiel eines einfachen while“-Blocks:
”
%%while coll.next_entry%%
%%# Ausfuehrungsblock %%
%%endwhile%%
11
Sofern die Anzahl von über 600 Placeholders nicht schon wieder gegenteiliges bewirkt.
73
3.2 PROGRAMMIERUNG
• Strukturierung: Üblicherweise erreichen Template Files sehr schnell eine unübersichtliche Größe, die eine Aufsplittung auf mehrere Files unabdingbar macht.
Dazu kann man in PLACE einerseits relativ zum wavemaster Verzeichnis ein File
über
%%include "file_name"%%
einbinden, oder direkt ein Objekt vom Server über
%%hyperinclude "GOID_or_name"%%
an die Stelle der Inlcude-Anweisung substituieren. Dennoch sollte man den Einsatz
eines Inlcudes immer sorgfältig abwägen, da bei Includes über mehrere Ebenen12
sehr schnell der Überblick verloren gehen kann.
• Makros: Neben der Aufteilung der Templates auf mehrere Files, erlaubt PLACE
die Deklaration von Makros, die über ihren Namen aufgerufen werden können. Ein
Beispiel eines einfachen Footer-Makros für eine HTML-Seite:
%%macro my_footer%%
<hr noshade>
Georg Wurzenberger |
<a href="mailto:[email protected]">[email protected]</a>
%%endmacro%%
Über %%my_footer%% kann dieses Makro aufgerufen werden.
• Placeholder: PLACE definiert sich über die Fülle vorhandener Placeholder,
die für die verschiedensten Aufgabenbereiche ausgelegt sind. Zum Beispiel werden logisch zusammengehörige Teile eines HTML-Dokuments gewissen Placeholders zugeteilt, wie etwa der Doctype des HTML-Dokuments dem Placeholder object.html.doctype oder der Teil zwischen den BODY-Tags dem Placeholder object.content. Für die Manipulation der Collection-Ausgabe gibt es ein Set von
Placeholders die mit dem Präfix coll.“ beginnen, wie für den Titel eines Objekts
”
der Collection (coll.entry.title). Für Sequence- und Cluster-Objekte gibt es
bezüglich der Semantik ganz ähnliche Placehoder.
12
Ein inkludiertes File enthält wieder Include-Anweisungen und so weiter.
74
3.2 PROGRAMMIERUNG
Ein Objekt am Server wird immer mit zusätzlichen Attributen gespeichert, die
über eine While-Schleife in PLACE ausgelesen werden können. Der Placeholder
object.attributes.entry.key repräsentiert dabei den Namen eines bestimmten
Attributes, object.attributes.entry.value den korrespondierenden Wert.
Die für das Session-Management relevanten Placeholders beginnen mit dem Präfix
session.“, wie zum Beispiel session.username oder session.language. In”
formationen über den Client werden in Placeholders mit dem Präfix client.“
”
gehalten, wie etwa die IP-Adresse in client.ipadr.
Schließlich gibt es noch Placeholder um Attribute zu verändern, Objekte zu kopieren, zu bewegen oder zu löschen und auch für die Versionskontrolle und Annotation.
Die über 600 vorhandenen Placeholder werden in dem alleine 360 Seiten starken
Hyperwave PLACE Workshop [HwisPlaceWS, 1999] mit den dazugehörigen Makros beschrieben.
• Actions: Eine besondere Form der Placeholder bilden sogenannte Actions. Über
Actions wird der HWIS aufgefordert, Aktionen auszuführen und im gegengesetzten
Fall kann eruiert werden, welche Aktionen vom Server durchgeführt wurden.
Wie bei vielen anderen proprietären Meta-Sprachen bedarf es einiger Zeit, um sich mit
der Programmierung von PLACE Templates vertraut zu machen. Der Umstand, dass
dabei ein einziges Template aus einer Mischung verschiedener Elemente wie etwa PLACE,
HTML oder SSJS Anweisungen bestehen kann, scheint sehr gewöhnungsbedürftig.
3.2.2
JavaScript Object Model
Seit der Version 4.0 des HWIS findet JavaScript vermehrt Anwendung in den Templates
des Wavemasters. JavaScript soll dabei primär als Ergänzung und Erweiterung von
PLACE verstanden werden und nicht als Alternative. Die Funktionalität von JavaScript
auf der Server-Seite wurde bereits in Verbindung mit dem Netscape (iPlanet) Server
in Abschnitt 2.3.5 erörtert.
Der Hyperwave JavaScript-Interpreter und die dazugehörige Runtime Engine unterstützen ebenfalls Core JavaScript“ und zusätzliche Objekte, die sich vom sprach”
unabhängigen Hyperwave API ableiten. Zusammen bilden die JavaScript Objekte des
HWIS, das Hyperwave JavaScript Object Model. Das Objekt-Modell erweist sich dabei
als sehr mächtig, da die gesamte Funktionalität, die über das User-Interface verfügbar
75
3.2 PROGRAMMIERUNG
ist, auch in einzelnen Methoden der JavaScript Objekte zu finden ist. Tabelle 3.1 listet
die JavaScript Objekte des HWIS mit kurzer Beschreibung auf.
Die Programmierung der Templates und damit indirekt die Verwirklichung von WebApplikationen, gestaltet sich über das JavaScript Objekt-Modell des HWIS wesentlich
komfortabler und angenehmer als über eine adäquate Litanei“ von Placeholders. Zu”
dem ist JavaScript in enger syntaktischer Verwandtschaft mit Java und C++, was den
damit vertrauten Programmierer schnell in JavaScript Fuß fassen läßt. Eine Web-Applikation auf Basis des HWIS und seines JavaScript API ist in Abschnitt 5 detailliert
beschrieben. Die genaue Referenz aller JavaScript Klassen des HWIS kann im Hyperwave
Programmer’s Guide [HwisProg, 1999, Abs. 2] gefunden werden.
3.2.3
Document Classes
Mit der Einführung sogenannter Document Classes versucht Hyperwave die Entwicklung
von Applikationen am Server zu erleichtern. Dieser Abschnitt möchte das Konzept von
Dokument-Klassen in den wesentlichen Zügen erklären und vertieft sich dabei weniger in
technische Details, die ohnehin in [HwisProg, 1999, Abs. 4] nachgelesen werden können.
Dokument-Klassen sind eine spezielle Erweiterung der existierenden Dokument-Typen des HWIS, wie Document, Collection, Sequence oder Cluster. Nicht immer findet
man mit den vorgegebenen Typen das Auslangen, vor allem wenn es um speziellere Anforderungen geht, wie sie gewöhnlich in Web-Applikationen auftreten. In einem Support
Tracking System genügt es zum Beispiel nicht, ein Trouble Ticket 13 durch einen einfachen
Cluster darzustellen, da bereits beim Einfügen eines neuen Tickets eigens angepasste Formulare benötigt werden. An diesem Punkt beginnt das Konzept der Dokument-Klassen
zu greifen. Durch die Erzeugung einer neuen Dokument-Klasse am HWIS wird gleichzeitig ein neuer Dokument-Typ generiert, der den vorgegebenen Anforderungen auf Punkt
entsprechen kann.
Die neu definierten Dokument-Klassen werden ebenfalls in einer Collection-Hierarchie
am Server gespeichert, wobei die Collection mit dem Namen hw_documentclasses als
Wurzel fungiert. Abbildung 3.5 zeigt die Hierarchie von Dokument-Klassen eines TestServers. Über speziell festgelegte Attribute – alle mit dem Präfix HW_DC_“ – wird ei”
13
Beinhaltet verschiedenste Informationen zu einem Problem, wie E-Mails, diverse Files, Status des
Tickets, Bearbeiter und einiges mehr.
76
3.2 PROGRAMMIERUNG
Tabelle 3.1: JavaScript Klassen oder Objekte des HWIS mit kurzer Beschreibung der Funktionalität.
Klasse/Objekt
HW_API_Attribute
HW_API_Object
HW_API_ObjectArray
HW_API_Reason
HW_API_Error
HW_API_Content
HW_API_Server
KeyValue
KeyValueField
OptionParser
SendMail
File
Directory
server
request
response
wavemaster
client
a
Beschreibung
Ein Key-Value(s)“ Paar eines HW_API_Object.
”
Enthält mehrere HW_API_Attribut Objekte.
Enthält ein Feld (evt. sortiert) von HW_API_Object Instanzen.
Repräsentiert eine Warnung oder eine Fehlermeldung.
Kann mehrere HW_API_Reason Objekte enthalten.
Kapselt eine Menge unbestimmter Daten, die in einem
Zusammenhang stehen. Zum Beispiel ein Stück Text.
Die mächtigste Klasse. Besitzt etwa 45 Methoden für die
Manipulation von Objekten am Server.
Hält ein Key-Value(s)“ Paar.
”
Besteht aus KeyValue Objekten.
Kann in hwjsa Programmen verwendet werden, um
Kommandozeilen-Optionen zu parsen.
Mit dieser Klasse können Mails verschickt werden.
Dient zur Manipulation von Files.
Dient zur Manipulation ganzer Verzeichnissse.
Eine Instanz der HW_API_Server Klasse.
Ein globales Objekt, das bei jedem Aufruf generiert wird
und Informationen über den Client enthält, wie dessen IP
Adresse.
Dieses Objekt hält den HTTP-Header, der als Antwort
zurück geschickt wird.
Ein globales Objekt, das einige allgemeine Informationen
über den Server kapselt.
Enthält Informationen, die in Form eines Cooky beim Client gespeichert werden und beim nächsten Request wieder
zum Server gelangen.
Ein Tool des HWIS, mit dem JavaScript-Programme in der Kommandozeile getestet werden können.
77
3.2 PROGRAMMIERUNG
Abbildung 3.5: Hierarchie der Document Classes am HWIS.
ne gewöhnliche Collection als Dokument-Klasse am Server deklariert. Das Attribut
HW_DC_ClassName legt zum Beispiel den genauen Namen der Klasse fest.
Vergleichbar mit Klassen in der objektorientierten Programmierung können Dokument-Klassen aus den folgenden Elementen bestehen:
• Members: Sind Eigenschaften der Objekte einer Klasse. Der HWIS unterscheidet
dabei zwei Arten von Members:
– Attribute Members: Entsprechen den bekannten Attributen von Objekten
des HWIS und werden über den Attributnamen HW_DC_Member festgelegt.
Zum Beispiel wird in einem Adressbucheintrag der Vorname benötigt, der als
Attribut der Klasse in der folgenden Weise festgelegt wird:
HW_DC_Member:(Type:string)(Name:firstname)(Access:public)
(Caption:(en:"First Name")(ge:"Vorname"))
– Pointer Members: Vom Namen abgeleitet handelt es sich dabei um Referenzen
auf andere Objekte des Servers. Zum Beispiel kann ein Adressbucheintrag
mit zusätzlicher Information versehen werden, die in einem eigenen Objekt
gewartet wird:
HW_DC_Member:(Type:HW_DC_API_Pointer)(Name:additionalinfo)
78
3.2 PROGRAMMIERUNG
• Methods: Sind Funktionen, die das Verhalten der Dokument-Klasse bestimmen,
wie etwa deren Darstellung. Sie können dabei auf die Daten aller Members ungehindert zugreifen. Eine Methode wird ebenfalls als Objekt mit speziellen Attributen in der Collection“ der Dokument-Klasse angelegt. Abbildung 3.6 zeigt
”
Abbildung 3.6: Die Methoden der Dokument-Klasse email“.
”
die Methoden der Dokument-Klasse email“ in der Darstellung des Web-Browsers.
”
Die Methode send“ der Klasse email“ wurde dabei mit den folgenden Attributen
”
”
versehen:
DocumentType:Generic
MimeType: application/vnd.hyperwave-method[-js]
HW_DC_MethodName:send
HW_DC_Access:public
HW_DC_Caption:(en:"Send an email")(ge:"Schicke ein E-Mail")
HW_ExecutionContext:core
HW_ExecutionLanguage:JavaSCript
HW_ExecutionLanguageVersion: 1.4
HW_ExecutionParameter:(Type:string)(Name:subject)(inOut:in)
HW_ExecutionParameter:(Type:string)(Name:text)(inOut:in)
Das Attribut MimeType“ bezeichnet die Sprache der Methode, in diesem Fall Ja”
vaScript. In der weiteren Entwicklung des Servers sollen Methoden auch in anderen
79
3.2 PROGRAMMIERUNG
Programmiersprachen ausführbar sein. Über das Attribut HW_ExecutionContext“
”
wird der Ausführungskontext der Methode festgelegt, der wm“ für WaveMaster,
”
vf“ für Virtual Folders oder core“ für WaveMaster und Virtual Folders sein
”
”
kann. Damit können Methoden für ein spezielles User-Interface ausgelegt werden.
Über HW_ExecutionParameter“ können einzelne Parameter der Methode festge”
legt werden. Über die Variable inOut“ wird der konkrete Typ des Parameters
”
definiert.
Der eigentliche Unterschied zu Klassen in der objektorientierten Welt liegt in der Persistenz. Instanzen von Dokument-Klassen sind nach der Erzeugung physikalisch am
Server gespeichert, hingegen sind Instanzen von objektorientierten Programmen meist14
nur währen der Laufzeit im Speicher. Daher beherrschen Dokument-Klassen noch weitere typische Eigenschaften objektorientierter Sprachen:
• Kapselung von Daten
• Destruktoren
• Vererbung
• Statische Methoden
• Konstruktoren
• Überladen von Methoden
Da sich die deklarierten Dokument-Klassen automatisch in das bekannte User-Interface
integrieren – im Punkt Publish“ der Menüleiste scheinen auch die Namen der Dokument”
Klassen auf – lassen sich daraus sehr bequem neue Instanzen am Server anlegen.
Hyperwave erfüllt mit der Einführung von Dokument-Klassen einen lange gehegten
Wunsch der Programmierer, nämlich mit einem neuen Programmierkonzept flexibler
und schneller Web-Applikationen auf Basis des HWIS realisieren zu können. Zweifelhaft
ist nur, ob der Programmierer auch entsprechend schnell die notwendige Fingerfertigkeit
mit dieser neuen Technik erlangen kann, zumal das für Dokument-Klassen von Hyperwave vorausgesetzte Wissen15 nicht gerade klein ist.
14
15
In Java können Objekte serialisiert gespeichert und wieder hergestellt werden.
Objektorientiertes Programmieren, C++ oder Java, JavaScript und das Hyperwave API. Siehe [HwisProg, 1999, Abs. 4].
80
4 Apache HTTP Server
Good programmers know what to write. Great
ones know what to rewrite (and reuse)a .
Eric S. Raymond
a
The Cathedral and the Bazaar [Raymond, 1999,
Kap. 2].
Der Apache HTTP Server – kurz Apache – ist eines der Aushängeschilder der OpenSource Community. Sein Marktanteil von bald 60 Prozent (siehe Abbildung 2.1 auf
Seite 23) macht ihn zum unangefochtenen Leader unter den Web-Servern. Nach grundlegenden Betrachtungen in Abschnitt 4.1, konzentriert sich dieses Kapitel in Abschnitt 4.2
schwerpunktmäßig auf die für Web-Applikationen interessanten Module des Apache. Dabei werden Aspekte der Konfiguration und des praktischen Einsatzes der jeweiligen Module ausführlich beschrieben und fallweise durch theoretische Hintergrundinformation
ergänzt.
4.1
Grundlagen
Das Apache Server Project, das sich um die Entwicklung des Apache HTTP Servers
kümmert, ist eines von mehreren Projekten der Apache Software Foundation, kurz ASF1 .
Die erst im Juni 1999 in Delaware (USA) gegründete Institution, die sich selbst als not”
for-profit corporation“ bezeichnet, ist aus der im Jahr 1995 entstandenen und weitaus
bakannteren Apache Group hervorgegangen. Alle Projekte des ASF – zur Zeit acht an
der Zahl – gründen auf den Prinzipien der freien, kollaborativen Software-Entwicklung,
1
http://www.apache.org
81
4 APACHE HTTP SERVER
4.1 GRUNDLAGEN
verwenden das Internet zur Kommunikation und leben vom Geist des open-source“ Pa”
radigmas. Das bekannteste mit dem Apache Brand“ versehene Produkt ist der Apache
”
HTTP Server, der üblicherweise vereinfachend nur Apache“ oder Apache Server“ ge”
”
nannt wird. Die folgenden Abschnitte beschäftigen sich mit einigen allgemeinen, aber
hauptsächlich technischen Details des Apache Servers.
4.1.1
Ziele des Apache Server Project
Das Ziel des Projekts ist die Realisierung eines sicheren, effizienten und erweiterbaren
HTTP Servers, der die aktuellen und gültigen HTTP – derzeit HTTP/1.12 – Standards
implementiert.
4.1.2
Entstehung
Der im Jahre 1995 meistgenutzte Web-Server im Internet war der durch Rob McCool
entwickelte NCSA3 Server. Nachdem McCool bereits Mitte 1994 NCSA verlassen hatte
kam die weitere Entwicklung zum Erliegen und viele Webmaster, die bis dato die Version
1.3 des NCSA Servers benutzten, begannen den Server in eigener Regie zu patchen“.
”
Zur Kommunikation unter diesen Webmastern wurde von Brian Behlendorf and Cliff
Skolnick eine Mailing Liste und ein Rechner zur gemeinsamen Entwicklung eingerichtet.
Die Apache Group mit acht Core Contributors war geboren. Aus dem gepatchten“
”
Server – im Englischen a patchy server“ – entstand auch die Bezeichnung Apache.
”
Nun erfolgte die Entwicklung Schlag auf Schlag. Im April 1995 erfolgte die erste
öffentliche Release (Version O.62) und bereits im Dezember 1995 war Apache 1.0 mit
neuem Modul-Konzept, API, verbesserter Dokumentation und weiteren Erneuerungen
verfügbar. Im selben Zeitraum löste Apache den NCSA Web-Server von der Spitze der
benutzten Server Software ab [Siehe Abschnitt 2.2.1]. Apache 2.0a2 Alpha ist die derzeit
letzte Version des Servers.
4.1.3
Unterstützte Plattformen
Der Apache Server läuft auf nahezu allen Unix-Derivaten4 . Zu den bekanntesten kommerziellen Unix Betriebssystemen zählen Digital Unix, Solaris 2 und Irix. Linux, als
2
RFC 2616 [Fielding et al., 1999]
National Center of Super Computing. http://www.ncsa.uiuc.edu.
4
siehe [Eilebrecht, 1999, Kap. 3.2] für eine genauere Liste.
3
82
4.1 GRUNDLAGEN
frei erhältliche Alternative, wird ebenso unterstützt. Im Windows Bereich wird primär
Windows NT 4.0 (Service Pack 3) unterstützt, die Versionen für Windows 95/98 werden
weniger gepflegt. Versionen für OS/2 und sogar AmigaOS sind erhältlich.
4.1.4
Installation
Unter der Adresse http://www.apache.org/dist kann immer die aktuellste Version des
Apache HTTP Servers, entweder als Source-Tarball oder als Binary-Distribution, unter
der Apache License 5 frei bezogen werden. Rein für das experimentelle“ Kennlernen des
”
Servers reicht die Installation der entsprechenden Binary-Version für seine Plattform.
Will man jedoch den Server besser an seine Bedürfnisse anpassen so kommt man an der
Übersetzung des Quellcodes nicht vorbei, vorausgestzt ein C-Compiler ist vorhanden.
Das Entpacken des Apache-Archives erzeugt eine Reihe von Unterverzeichnissen. Das
wichtigste davon ist das src Verzeichnis, das alle Source-Dateien des Apache und seiner
Module, sowie Konfigurations-Files enthält. Welche Module nun wie in den Apache integriert werden sollen, kann in der Datei Configuration festgelegt werden. Die folgende
Anweisung binded das Modul mod_env“ – ermöglicht die Verwendung von Umgebungs”
variable des Servers in CGI-Skripte oder SSI-Dokumente – in den Apache Server ein.
AddModule modules/standard/mod_env.o
Grundsätzlich ist es ratsam, sich vorher genau zu überlegen, welche Module wirklich
benötigt werden. Einige Module brauchen auch ohne direkte Verwendung Resourcen
und können somit den ganzen Server verlangsamen. Das in Abschnitt 4.2 erklärte Konzept von Dynamic Shared Objects, stellt eine Alternative zum statischen Einbinden von
Modulen dar und findet aufgrund der Einfachheit immer mehr Anklang.
Der Aufruf des Shell-Skripts Configure erstellt entsprechend der im Configuaration
File getätigten Angaben ein Makefile, das via make den gewünschten HTTP-Daemon6
(httpd) erzeugt. Abschließend kopiert man httpd an die entsprechende Stelle des Verzeichnisbaumes (zum Beispiel /usr/sbin) und erstellt ein Boot-Skript, damit der WebServer beim Hochfahren automatisch gestartet wird.
5
6
http://www.apache.org/LICENSE.txt
Ein Prozeß der im Hintergrund läuft und gewisse Aufgaben periodisch oder auf Anfrage erledigt.
83
4.1.5
4.1 GRUNDLAGEN
Konfiguration
Alle Konfigurationsanweisungen – diese werden auch als Direktiven bezeichnet – befinden
sich in der Datei httpd.conf, die beim Start des Servers automatisch gelesen wird. Die
Anhänger von grafischen Benutzer-Oberflächen schrecken vor dem Editieren einer reinen
Text-Datei in den meisten Fällen zurück, in der Unix-Welt ist dieser Zugang aber der
üblichere und effizientere.
Listing 4.1 zeigt Ausschnitte aus der Konfiguration eines im Betrieb befindlichen
Web-Servers (www.amft.tu-graz.ac.at) und kommentiert die Funktion einiger Anweisungen.
Listing 4.1: Ausschnitte aus einem httpd.conf File
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ServerRoot "/usr/local/httpd"
MinSpareServers 5 #min. number of idle child server processes.
MaxSpareServers 10 #max. number of idle child server processes.
StartServers 5
#number of child server processes created on startup.
MaxClients 150
#max. number of simultaneous requests
LoadModule mime_module /usr/lib/apache/mod_mime.so
AddModule mod_mime.c
Port 80
ServerAdmin [email protected]
ServerName www.amft.tu-graz.ac.at
DocumentRoot "/usr/local/httpd/htdocs"
ErrorLog /var/log/httpd.error_log
ServerSignature On
## Accesss to ’intra’ only from the AMFT-Intranet
<Directory "/usr/local/httpd/htdocs/intra">
Options FollowSymLinks Includes
Order allow,deny
Allow from 129.27.114
</Directory>
## enable perl for cgi-bin
<Location /cgi-bin>
AddHandler perl-script .pl
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
</Location>
84
27
28
29
30
31
32
4.2 MODULE
## To use server-parsed HTML files
AddType text/html .shtml
## To use PHP files
AddType application/x-httpd-php3 .php3
## Customizable error response (AMFT)
ErrorDocument 401 /resources/error_docs/error401.html
Die meisten Direktiven lassen schon vom Namen her auf ihre Bedeutung schließen, wie
das Setzen des TCP-Ports, auf dem der Server auf Client-Requests lauscht“. Die Kon”
figuration von ganzen Verzeichnissen oder Dateien kann über eine der folgenden Anweisungen geschehen:
• <Directory Verzeichnis> Anweisungen </Directory>
• <Files Dateiname> Anweisungen </Files>
• <Location URL-Pfad > Anweisungen </Location>
Als Beispiel sollen die Anweisungen in Zeile 15-19 von Listing 4.1 dienen. Sie beschränken den Zugriff des Verzeichnisses intra auf die Domain 129.27.114 (Zeilen 17 und
18), erlauben die Interpretation von SSI-Files und das Folgen“ von symbolischen Links
”
(Zeile 16).
Für eine vollständige Liste der möglichen Direktiven der Apache-Distribution sei auf die
Server Dokumentation [ApacheDoc, 1999] und [Eilebrecht, 1999] verwiesen.
4.2
Module
Das Modulkonzept des Apache war ein wesentlicher Faktor, der zur raschen Verbreitung
und Akzeptanz des Servers beitrug. Einerseits können wie in Abschnitt 4.1.4 beschrieben, Module je nach gewünschter Funktionalität eingebunden oder weggelassen werden,
andererseits können Module bei Bedarf auch selbst erstellt werden. Der Kern (Core)
kann dabei je nach Anforderung immer klein gehalten werden und garantiert dadurch
gute Performance. Ben und Peter Laurie [Laurie & Laurie, 1999] formulieren diesen
Aspekt wie folgt:
One of the great things about Apache is that if you don’t like what it does,
”
you can change it.“
85
4.2 MODULE
Apache stellt dazu ein API und ein funktionierendes Beispiel-Modul (mod_example) zur
Verfügung. Das File mod_example.c illustriert die vorhandenen Callback-Mechanismen
des Servers sowie die Verwendung von Apache API-Funktionen.
Bevor man aber den direkten“ Weg geht und gleich selbst gewünschte zusätzliche
”
Funktionalität implementiert, lohnt sich der Blick zu den in großer Anzahl vorhandenenen Apache Module7 . Für diesen Zweck gibt es die Apache Module Registry im Web
(http://modules.apache.org), die es erlaubt innerhalb der dort registrierten Module,
stichwortartig zu suchen.
Nicht innerhalb der ASF entwickelte Module werden auch als Third-Party Module
bezeichnet und sind aufgrund ihrer großen Anzahl ein Beweis für den Erfolg des Apache
Open-Source Projekts. Nachfolgend einige wichtige Add-On Module8 , die derzeit häufig
Verwendung finden.
• mod_php
• mod_ssl
• mod_perl
• mod_fastcgi
• mod_cgi
• mod_jserv
Gerne zur Anwendung kommen auch die zahlreich vorhandenen AuthentifizierungsModule, wie zum Beispiel mod_auth_dbm oder mod_auth_mysql, die eine Authentifizierung über eine bestimmte Datenbank erlauben. Abbildung 4.1 zeigt abschließend
den prozentuellen Verwendungsgrad der populärsten Add-On Module im Vergleich zur
Gesamtheit der untersuchten Apache Web-Server. In diesem Fall untersuchte E-Soft [ESoft, 2000] mehr als 1.06 Millionen Apache Server nach deren Modul-Installation.
Dynamic Shared Objects (DSO)
Seit der Version 1.3 des Apache ist das dynamische Laden von Modulen in den Adressraum
des HTTP-Daemon während des Starts entsprechend dem dlopen-Standard [Engelschall,
1998] möglich. Damit erspart man sich ein Neukompilieren des Servers beim Hinzufügen
oder Entfernen eines Moduls und gewinnt zusätzlichen Komfort und Flexibiltät bei der
Konfiguration. Um über die LoadModule-Direktive dynamisch Module laden zu können
muss das Modul mod_so.c statisch in den Apache-Kern kompiliert werden. Alle Module
7
8
Nicht betrachtet werden hier die Standard Module der Apache-Distribution.
Module, die nicht Bestandteil der Apache-Distribution sind.
86
mod frontpage
Ben-SSL
6.62
6.70
23.85
PHP
2.37
19.59
Frontpage
2.16
mod perl
1.96
mod ssl
1.52
mod fastcgi
%
ApacheJServ
30
20
10
0
4.2 MODULE
Abbildung 4.1: Prozentueller Verwendungsgrad der verschiedenen Add-On Module zur Gesamtheit von etwa 1.06 Millionen Apache Server. Quelle: [E-Soft, 2000].
der Apache-Distribution – außer http_core.c – können nun als DSO gelinkt werden.
Die Standard-Konfiguration des Apache geht bereits diesen Weg, was ein Aufruf des
httpd mit der Option -l verdeutlicht:
Compiled-in modules:
http_core.c
mod_so.c
Alle restlichen Module werden über LoadModule-Anweisungen im httpd.conf beim Start
des Servers gelinkt, zum Beispiel:
LoadModule mime_module
/usr/lib/apache/mod_mime.so
LoadModule perl_module
/usr/lib/apache/libperl.so
Die Erzeugung von DSO-Files, vor allem für Third-Party Module, wird durch ein, während der Übersetzung der Apache-Distribution an die Plattform angepasstes Perl-Skript
(apxs9 ), noch zusätzlich erleichtert.
Die Abschnitte 4.2.1–4.2.4 beschäftigen sich etwas genauer mit Module, die für Web-Applikationen aufgrund ihrer Funktionalität interessant sind.
4.2.1
mod include
Mit dem Modul mod_include ist es möglich, SSI-Anweisungen (siehe Abschnitt 2.3.1) in
HTML-Dokumenten zu verwenden. Wie in Abschnitt 4.2 beschrieben kann auch dieses
9
APache eXtenSion Tool.
87
4.2 MODULE
Modul statisch in den httpd gelinkt oder als DSO während der Laufzeit geladen werden.
Letzteres ist die Regel.
Standardmäßig sucht der Apache Server nicht nach SSI-Anweisumngen in HTMLFiles10 , dazu muss im httpd.conf konkret festgelegt werden, welche Dokumente SSIAnweisungen enthalten können. Files mit einer bestimmten Extension als SSI-Files
zu kennzeichnen erweist sich dabei als vorteilhaft. Folgende Direktiven werden dazu
benötigt:
AddHandler server-parsed .shtml
AddType
text/html
shtml
Zusätzlich müssen auch die Verzeichnisse für SSI-Anweisungen frei geschaltet werden:
<Directory /shtml>
Options +Includes
</Directory>
Somit wird ein File test.shtml aus dem Verzeichnis /shtml vom Server auf IncludeAnweisungen untersucht. Um die Ausführung von CGI-Skripts zu unterbinden kann
die Option Includes, durch IncludesNOEXEC ersetzt werden. Damit ist es mit den
Anweisungen #exec und #file nicht mehr möglich CGI’s aufzurufen, die ein eventuelles
Sicherheitsrisiko darstellen könnten.
4.2.2
mod perl
Das Apache/Perl Projekt der ASF versucht, den sehr mächtigen Perl Interpreter in
den Apache HTTP Server zu integrieren. Dabei werden die Perl Runtime Libraries in
den Server gelinkt und ein Perl-Interface dem Server API zur Verfügung gestellt. Das
Server Plug-In mod_perl ist das Resultat der Integration. Wie aus Abbildung 4.1 auf
Seite 87 hervorgeht, ist mod_perl ein sehr beliebtes Apache Add-On Modul, das nun
konkret für zweierlei Zwecke dienlich ist:
1. Apache Module können damit völlig in Perl programmiert werden.
2. Der persistente im Server eingebettete Interpreter vermeidet den Overhead, bei
Perl CGI-Skripts einen externen Interpreter starten zu müssen.
10
Alle HTML-Files nach Include-Anweisungen per Voreinstellung zu parsen, würde die Leistung des
Servers sichtlich drosseln.
88
4.2 MODULE
Für die Funktion in Punkt 2 wird die CGI-Umgebung des Servers emuliert, sodass bestehende CGI-Skripts auch unter mod_perl ohne Änderung lauffähig sind. Das Perl Modul
Apache::Registry ist für diese Emulation verantwortlich und cacht“ einmal aufgeru”
fene und somit kompilierte CGI-Skripts für die weitere Verwendung. Dieses Vorgehen
begründet die beschleunigte Ausführung von CGI’s unter mod_perl, verlangt aber zusätzliche Vorsicht bei der Programmierung der Skripts, zum Beispiel in der Festlegung
der Sichtbarkeit von Variablen. Da Skripts unter mod_perl eine Lebenszeit“ über meh”
rere HTTP-Requests hinaus besitzen, können Variable, die fälschlicherweise als global
definiert wurden, Grund von Fehlern in der Applikation werden. Daher sollte man den
Perl Interpreter immer mit der Option -w ( turn warnings on for compilation“) starten
”
und die Compile-Direktive strict verwenden:
#!/usr/bin/perl -w
use strict;
Gezwungenermaßen programmiert man dadurch wesentlich sauberer“. Um mod_perl
”
als CGI Replacement zu verwenden, sind nach der Installation als DSO (empfohlen),
folgende Einstellungen in der Server Konfiguration (httpd.conf) vorzunehmen:
Listing 4.2: Konfiguration von mod_perl
1
2
3
4
5
6
Alias /perl/ /usr/local/httpd/perl-scripts/
<Location /perl>
SetHandler perl-script
Options +ExecCGI
</Location>
In Listing 4.2 wird für Perl-Skripts ein eigenes Verzeichnis verwendet, dem der PerlHandler Apache::Registry (Zeile 4) zugewiesen wird. Unabhängig von der Extension
werden alle exekutierbaren Files in diesem Verzeichnis von Apache::Registry behandelt, sofern wie in Zeile 5 die Ausführung von CGI’s gestattet ist. Will man alle Files
mit der Extension .pl“ von Apache::Registry gehandelt wissen, trifft man folgende
”
Einstellungen:
<Files *.pl>
SetHandler perl-script
89
4.2 MODULE
Options ExecCGI
</Files>
Abschließend kann festgestellt werden, dass CGI Web-Applikationen mit mod_perl den
großen Vorteil haben, wesentlich schneller zu sein als vergleichbare Lösungen mit JavaTechnologien (Jserv, JSP) oder ASP. Der einzige Nachteil liegt in der beschränkten
client-seitigen Anwendungsmöglichkeit.
4.2.3
mod php3
Auf beinahe einem Viertel aller Apache Server (siehe Abbildung 4.1 auf Seite 87) ist
mod_php3 als Zusatz installiert. Damit ist mod_php3 das derzeit populärste Apache AddOn Modul am Markt. Die Version 3.0.15 (stabil) und die Version 4 Release Candidate
1 sind zur Zeit unter http://www.php.net verfügbar.
In 2.3.4 auf Seite 45 wurde PHP bereits näher untersucht und als sehr effektive und
dabei frei erhältliche Web-Technologie identifiziert. Was dabei weniger Erwähnung fand,
war der Umstand, dass PHP ein reines Apache Produkt ist und nur auf Basis dieses einen
Servers zur Zeit läuft. Aufgrund der Marktführung des Apache im Web-Server-Bereich
ein vertretbarer Nachteil.
Zeitgemäß installiert man mod_php3 am bequemsten als DSO via apxs zu einer vorhandenen Apache Distribution. Das entspricht auch dem empfohlenen Weg. Anschließend überläßt man apxs die Einträge ins httpd.conf oder nimmt diese selbst vor. In
Listing 4.3 wird zum Beispiel PHP nur dann als Modul geladen, wenn httpd mit dem
Schalter -D PHP gestartet wird:
Listing 4.3: Konfiguration von mod_php3
1
2
3
4
5
<IfDefine PHP>
LoadModule php3_module /usr/lib/apache/libphp3.so
AddModule mod_php3.c
AddType application/x-httpd-php3 .php3
</IfDefine>
Die Direktiven innerhalb der IfDefine Sektion werden nur dann ausgeführt, wenn PHP
als Parameter definiert wurde. Nach dem Laden und Aktivieren des Moduls in Zeile
2 und 3 weist die AddType Direktive in Zeile 4 dem festgelegten PHP-MIME-Typ Dateien mit der Endung .php3“ zu. Wird eine solche Datei mit einem HTTP-Request
”
90
4.2 MODULE
angefordert, leitet Apache diesen Request an mod_php3 weiter, das die Datei nach PHPAnweisungen parst und dabei ein entsprechendes HTML-Dokument erstellt. Dieser Ablauf ist in Abbildung 4.2 in vereinfachter Form dargestellt.
Abbildung 4.2: Apache Server mit PHP Modul
Die eigentliche Konfiguration des PHP-Parsers erfolgt in dem File php3.ini für
PHP 3.0.x oder php.ini für PHP 4. Diese Datei wird beim Start des Apache Servers
geladen und kontrolliert wesentliche Aspekte der PHP-Scripting-Umgebung. Listing 4.4
fasst die wichtigsten Optionen auszugsweise zusammen:
Listing 4.4: Auszug aus php3.ini
1
2
3
4
5
6
7
8
9
10
11
[PHP_3]
engine
= On
short_open_tag
= On
max_execution_time = 30
memory_limit = 8388608
display_error
= On
[MySQL]
mysql.allow_persistent =
mysql.default_host
=
mysql.default_user
=
mysql.default_password =
;
;
;
;
;
enable PHP 3.0 parser
allow the <? tag.
Max. execution time of each script, in sec.
Max. amount of memory a script may consume
Print out errors (part of the HTML script)
On
localhost
user
secret
;
;
;
;
allow or prevent persistent link
default host for mysql_connect()
default user for mysql_connect()
default pwd for mysql_connect()
Die Sektion [PHP_3] setzt verschiedene Optionen, die das allgemeine Verhalten der PHPUmgebung betreffen, wie das Festlegen eines oberen Speicher-Limits für Skripts oder
eines Logging-Schemas. Die restlichen Sektionen konfigurieren über Direktiven verschiedene Datenbank-Einstellungen (siehe Listing 4.4 Sektion [MySQL]), die je nach Daten-
91
4.2 MODULE
bank in ihrem Umfang sehr stark variieren.
Midgard 11 , eine frei erhältliche Web-Applikation Entwicklungs-Plattform basiert, völlig
auf Apache und der PHP-Scripting-Umgebung.
4.2.4
mod jserv
Um Java Servlets ausführen zu können, bedarf es einerseits der entsprechenden ServletKlassen12 und andererseits einer Java Virtual Machine, kurz JVM. Wie in Abschnitt 2.3.6
bereits angedeutet, kann bei in Java implementierten Web-Servern dafür die bereits für
den Server selbst laufende JVM verwendet werden. Bei einem von Grund auf in C
geschriebenen Web-Server, wie dem Apache, benötigt man jedoch einen alternativen
Lösungsansatz. Bei jedem Servlet-Request eine eigene JVM zu starten, verwehrt sich
aufgrund der benötigten Zeit zum Start eines neuen JVM-Prozesses13 . Daher hat sich
das Entwicklungs-Team des Apache JServ Project für eine three-tier“ Architektur ent”
schieden, das heißt, die Servlet Engine ist nicht Teil des Servers sondern eine standalone“
”
Applikation. Folgende Schichten lassen sich identifizieren:
1. HTTP-Client: Web-Browser.
2. HTTP-Server und AJP-Client: Apache mit mod_jserv.
3. AJP-Server: Apache JServ.
Client und Web-Server kommunizieren mittels HTTP. Das Web-Server Modul mod_jserv
und die Servlet Engine kommunizieren über das Apache JServ Protocol, kurz AJP.
Wie sehen nun die einzelnen Schritte eines Servlet-Requests aus? Abbildung 4.3 stellt
den Ablauf eines Requests vom Client zur Servlet Engine schematisch dar. Es ergibt sich
der folgende Ablauf:
• Der Client sendet einen HTTP-Request an den Apache Web-Server.
• Im Apache Web-Server wird der HTTP-Request vom mod_jserv Modul in einen
AJP-Request umgeformt und an die Servlet Engine Apache JServ geschickt.
11
Application Server Suite, http://www.midgard-project.org.
Grundpakete javax.servlet und javax.servlet.http werden über das Java Servlet Development
Kit (JSDK) installiert.
13
Eine Standard Sun JVM benötigt etwa 5 Sekunden um zu starten.
12
92
4.2 MODULE
Abbildung 4.3: Apache JServ three-tier“ Operation. Quelle: [Mazzocchi & Fumagalli, 1998].
”
• Apache JServ erzeugt aus dem AJP-Request ein ServletRequest Objekt. Zusätzlich wird ein ServletResponse Objekt generiert, das die Rückgabe-Daten des
Servlets kapselt.
• Das ServletResponse Objekt wird nach Ausführung des Servlets in eine AJPResponse umgewandelt und an mod_jserv zurückgeschickt.
• mod_jserv erzeugt aus der AJP-Response eine HTTP-Response, die an den WebBrowser gesendet wird.
Für genauere Informationen über Apache JServ sei auf [Mazzocchi & Fumagalli, 1998]
verwiesen.
Installation:
Als Voraussetzung neben dem eigentlichen Apache Web-Server müssen JDK14 und JSDK
2.015 auf dem System verfügbar sein. Sind diese Anforderungen erfüllt, stellt die Apache
JServ Distribution die Servlet Engine (Apache JServ ) und das Modul mod_jserv für den
Web-Server bereit. Für letzteres empfielt sich wieder die Installation als DSO. Genauere
Beschreibungen der Installation sind in [Haberstadt, 1998; Yumul, 1998] zu finden.
14
15
Java Development Kit, http://java.sun.com/products/jdk.
Java Servlets Development Kit, http://java.sun.com/products/servlet.
93
4.2 MODULE
Konfiguration:
Ausgehend von oben angegebener Installation ist die Servlet Konfiguration des Apache
auf verschiedene Files – siehe Abbildung 4.4 – aufgeteilt:
httpd.conf
Include
jserv/jserv.conf
ApJServProperties
jserv/jserv.properties
root.properties
jserv/zone.properties
LoadModule jserv_module /usr/lib/apache/mod_jserv.so
ApJServDefaultProtocol ajpv12
ApJServDefaultPort 8007
ApJServMount /servlets /root
wrapper.bin=/usr/lib/java/bin/java
wrapper.classpath=/usr/lib/apache/ApacheJServ.jar
wrapper.classpath=/usr/local/jsdk/lib/jsdk.jar
wrapper.classpath=/usr/lib/java/mysql.jdbc/mysql_comp.jar
port=8007
zones=root
repositories=/usr/local/httpd/servlets
autoreload.classes=true
Abbildung 4.4: Die Servlet Konfigurationsfiles im Verzeichnis /etc/httpd und
/etc/httpd/jserv. Reihenfolge des Aufrufs und die wichtigesten Anweisungen innerhalb
der Files.
1. jserv.conf: Ladet das mod_jserv Modul und beinhaltet verschiedene Direktiven
für die Servlet Engine, zum Beispiel Festlegen des Protokolls und des Ports.
2. jserv.properties: Apache JServ parst dieses File beim Start und findet Informationen über den Platz“ der JVM, den Klassen-Pfad16 und den verschiedenen
”
Servlet Zonen (eine Menge von zusammengehörigen Servlets). In unserem Fall ist
die Servlet Zone root definiert.
3. zone.properties: Setzt den Pfad zu den sogenannten Servlet Repositries, die
zu dieser Zone gehören. Im gegebenen Beispielsfall: Alle Servlets im Verzeichnis
/usr/local/httpd/servlets gehören zur Servlet Zone root. Die Servlets unterliegen damit denselben Sicherheits-Einschränkungen.
16
Wichtig: Hier muss der Pfad zu den JDBC Treiber-Klassen angegeben werden, sonst werden diese
über die Methode Class.forName(...) nicht gefunden.
94
5 Projekt CO2
The Need for Speed a .
a
Jakob Nielsen
Gleichnamiger Artikel [Nielsen, 1997].
Content Organisation 2, kurz CO2, ist eine auf dem Hyperwave Information Server
basierende Web-Applikation, die die Strukturierung von Organisationsinformationen innerhalb der Creditanstalt und Bank Austria, kurz CA/BA, zur Aufgabe hat. CO2 wurde
nach den Vorgaben der CA durch ein Projekt-Team des IICM im Zeitraum Jänner bis
Oktober 1999 entwickelt. Aufgrund der Größe und Komplexität des Systems liegt der
Schwerpunkt dieses Kapitels auf der Applikationsstruktur und in der ausführlichen Erklärung der Requestabarbeitung. Mit Requestabarbeitung ist die Art und Weise gemeint,
mit der CO2 ausgehend von einem Client-Request eine HTML-Seite generiert. Im Rahmen des CO2-Gesamtprojektes wurde ich neben kleineren Aufgaben mit der gesamten
Umsetzung der Dialogdesign-Vorgaben betraut.
Abschnitt 5.1 beschreibt in allgemeiner Form das CO2-Projekt und sein Umfeld. Anschließend erörtert Abschnitt 5.2 die grundsätzlichen Konzepte der Objekt-Bibliothek
hwlib, die als Basis für die gesamte Applikationsentwicklung eingesetzt wurde. Abschnitt 5.3 diskutiert die grundsätzliche Struktur der Applikation und Aspekte der implementierten CO2-Objekte. Des weiteren beschreibt dieser Abschnitt die einzelnen Schritte
der Requestverarbeitung im Detail. Abschnitt 5.4 kommentiert einige im Projektverlauf
aufgetretene Probleme und beschließt mit dem derzeitigen Projektstatus dieses Kapitel.
95
5 PROJEKT CO2
5.1
5.1 ALLGEMEINER ÜBERBLICK
Allgemeiner Überblick
Das CA Pflichtenheft bezeichnet CO2 als ein Contentprojekt, das sich mit Inhalten und
deren Strukturierung auf dem Konzern1 -Intranet beschäftigt. Der Begriff Inhalt“ steht
”
dabei für konzernweite Organisationsinformationen und dem internen Richtlinienwesen,
das folgende Punkte umfasst:
• Arbeitsanweisungen
• Hilfetexte
• Arbeitshandbücher
• Schulungsunterlagen
• Systembeschreibungen
• Lexika
Als Plattform für dieses System entschied man sich für den Hyperwave Information
Server, der auch gut in die bestehende Systemlandschaft – durchwegs Windows – passte.
Mit der Implementierung der Applikation beauftragte die CA ein Entwickler-Team des
IICM, das bereits auf Erfahrungen vorangegangener Projekte2 mit dem HWIS und der
Objekt-Bibliothek hwlib zurückgreifen konnte.
5.1.1
Zielsetzung
Als ein web-basierendes Intranet-Informations- und Hilfesystem soll CO2 den folgenden
Anforderungen entsprechen:
1. CO2 soll sich in den konzernweiten Informationsraum einbetten und mit den vorhandenen Systemen (ARIS, RUBI, MORIZ, NEWS, etc.)3 kooperieren.
2. Die Redundanzen der heterogenen, gewachsenen Struktur konzernweiter Informationen sollen minimiert werden. Ein bestimmter Inhalt ist genau einmal im Informationsraum physikalisch gespeichert und kann über Referenzen von anderen
Objekten angesprochen werden.
3. Inhalte sollen strukturiert, einheitlich gegliedert und aktuell sein. Die Gliederung
der Information soll abwicklungsorientiert erfolgen, das heißt auf Basis der bewährten Struktur von Prozessmodellen.
1
Creditanstalt und Bank Austria.
Kurz zuvor implementierte das gleiche Team einen Prototypen eines Support-Tracking-Systems.
3
Intranet-Applikationen für verschiedene Aufgabenbereiche im CA/BA-Intranet.
2
96
5 PROJEKT CO2
4. Der Zugang zur Information soll rasch, einfach und an die Aufgabenstellung angepaßt erfolgen. Der Mitarbeiter soll die Information dann konsumieren können,
wenn er sie situationsbedingt braucht, etwa bei der Anlage eines neuen Kontos.
5. Die Wartung soll über ein Autorensystem einfach und effizient ausführbar sein.
Das CO2-Pflichtenheft bezeichnet die prozesshaften Regelungen“ als Kernstück der Ap”
plikation. Durch Einbeziehung des logischen Umfeldes gelingt es den globalen Kontext
der Regelung leichter zu erkennen.
5.1.2
Entities
Die bis dato in Arbeitshandbüchern und Arbeitsanweisungen der CA/BA vorhandene
Information kann aus prozessorientierter Sicht in die folgenden System-Entities unterteilt
werden:
• Prozessmodelle
– Listen
– Formulare
• Vorgänge
– Bildschirmmasken
• Tätigkeiten
– Fragestellungen
• Arbeitsschritte
– Varianten
• Medien
• Felder
• Lexikon
– Transaktionen
Diese Aufzählung entspricht auch der zugrunde liegenden Informationshierarchie: Ein
Prozessmodell besteht aus einem oder mehreren Vorgängen. Ein Vorgang besteht aus
einem oder mehreren Tätigkeiten, usw. Nur die angeführte Entity Lexikon“ fügt sich
”
nicht in diese Schema.
Abbildung 5.1 zeigt die Darstellung eines Vorganges im Web-Browser. Der Balken
links beherbergt die Navigation, die jeweils den Kontext des aktuellen Objekts wiedergibt, das im rechten Teil des Browser-Fensters dargestellt wird. Das gezeigte Objekt in
Abbildung 5.1 verdeutlicht auch den modularen Aufbau eines Objekts aus Unterobjekten. Im Testfall besteht der dargestellte Vorgang aus verschiedenen Fragestellungen, die
wiederum verschiedene Varianten als Antwort beinhalten.
97
5 PROJEKT CO2
Abbildung 5.1: CO2-Benutzeroberfläche im Web-Browser.
5.1.3
Kontext
CO2 kooperiert in erster Linie mit auf VIP4 -Basis erstellten Produkten, die über einen
Produktschlüssel einem Prozessmodell des Informationsbereiches zugeordnet werden.
Somit werden zum Beispiel Hilfestellungen für die Erzeugung oder Anlage gewisser Produkte dem Benutzer ad hoc zugänglich.
5.1.4
Programmieraufgaben
Aus den allgemeinen Rahmenbedingungen und dem Pflichtenheft des Projekts wurden
folgende Teilaufgaben für die Programmierung der Web-Applikation abgeleitet:
1. Integration der hwlib in den vorhandenen Prototypen.
2. Teilweises Redesign der Prototyp-Anwendung.
3. Übertragung der Systementitäten auf JavaScript Objekte.
4
VIP wurde parallel zu CO2 als Produktverwaltungssystem der CA/BA am IICM entwickelt.
98
5 PROJEKT CO2
5.2 HWLIB - EINE OBJEKTBIBLIOTHEK
4. Entwicklung des Requestablaufes.
5. Implementation der Eingabemasken.
6. Umsetzung des Dialogdesigns.
7. Feinschliff und Optimierung.
Die aufgezählten Punkte müssen dabei in chronologischer Reihenfolge betrachtet werden, das heißt Teilaufgabe 2 setzt die Implementierung von Teilaufgabe 1 voraus. Die
Erklärung des entwickelten Requestablaufes bildet den Schwerpunkt der Diskussion.
5.2
hwlib - Eine Objektbibliothek
Als Basis für die Implementierung des CO2-Projektes diente die am IICM entwickelte Hyperwave Library – kurz hwlib. Die Erfahrung vorhergegangener Projekte zeigte,
dass gewisse Funktionalität oft benötigt wird oder sich nur nach äußerlichen Kriterien
von Applikation zu Applikation unterscheiden ließ. Um nicht jedesmal Entwicklungszeit
an den gleichen Problemen zu vergeuden, verwirklichte man die Idee5 einer ObjektBibliothek für den HWIS, die fertige Bausteine für individuelle Projekte bereitstellt.
Die hwlib implementiert dabei objektorientierte Prinzipien, die teilweise auch mit JavaScript verwirklicht werden können.
Abschnitt 5.2.1 erklärt wie man mit JavaScript ansatzweise objektorientiert programmieren kann. Anschließend gibt Abschnitt 5.2.2 einen allgemeinen Überblick über den
hwlib-Funktionsumfang. Abschnitt 5.2.3 verdeutlicht den objektorientierten Ansatz
durch die Beschreibung der Objekt-Hierarchie. Die allgemeine Thematik der hwlib erweist sich als sehr umfangreich, daher werden in diesem Abschnitt nur die für das weitere
Verständnis dieser Arbeit benötigten Grundlagen erörtert. Für das interessierte Publikum sei auf den hwlib Reference Guide [Wurzenberger, 1999] verwiesen.
5.2.1
Objektorientierte Programmierung mit JavaScript
JavaScript ist eine objektorientierte Sprache basierend auf Prototypen, im Gegensatz zu
Klassen-basierenden Sprachen wie Java und C++ [jsOOP, 1997]. Das macht einen wesentlichen Unterschied, da JavaScript zwischen den Begriffen Klasse und Instanz nicht
5
Harald Krottmaier ([email protected]) ersann im September 1998 dieses Konzept.
99
5 PROJEKT CO2
wie gewohnt formal unterscheidet. Es gilt nur, dass alle Objekte, die von ein und demselben Konstruktor6 erzeugt wurden, Instanzen einer bestimmten Klasse7“ sind. Dieses
”
Prinzip soll nun anhand einer konkreten Klassendefinition veranschaulicht werden, als
Beispiel diene die nachfolgende Definition der Klasse Drawing:
Listing 5.1: Basisklasse Drawing
1
2
3
4
5
6
function Drawing(xpos,ypos){
this.x = xpos || 0;
this.y = ypos || 0;
this.move = Drawing_move;
}
Drawing.prototype.move = Drawing_move;
7
8
9
10
11
function Drawing_move(x,y){
this.x += x;
this.y += y;
}
Die Klasse Drawing besteht aus zwei Membervariablen und einer Memberfunktion, wobei
letztere schon außerhalb des Funktionsrumpfes über die prototype Eigenschaft deklariert wurde. Die eigentliche Definition der Memberfunktion move – in Listing 5.1 von
Zeile 9 bis 11 – ist an keinen speziellen Platz gebunden. Über die Anweisung
var drawing = new Drawing(1,2);
kann nun ein neues Drawing-Objekt erzeugt werden. Im nächsten Schritt wird eine Klasse Rectangle von der Klasse Drawing abgeleitet. Einfache Vererbung ist mit JavaScript
sehr wohl möglich und wird über eine sogenannte Prototyp-Kette mit der speziellen
Eigenschaft __proto__ realisiert. Die Klasse Rectangle leitet sich wie folgt ab:
Listing 5.2: Abgeleitete Klasse Rectangle
1
2
3
4
6
7
function Rectangle(x,y,radius){
this.base = Drawing;
this.base(x,y);
this.r = radius || 1;
In JavaScript eine simple Funktion.
Der Begriff Klasse wird in der weiteren Diskussion stv. für eine bestimmte Konstruktorfunktion
verwendet.
100
5 PROJEKT CO2
5
6
}
Rectangle.prototype.__proto__ = Drawing.prototype;
In Zeile 2 und 3 in Listing 5.2 wird explizit der Konstruktor der Superklasse aufgerufen.
Zeile 6 verdeutlicht die Vererbung mittels Prototyp-Kette, wobei im Beispiel bereits die
optimierte Form der Syntax gewählt wurde, wie sie auch in der hwlib zur Anwendung
kommt.
Dieser kurze Ausflug in die objektorientierte Welt beweist, dass mit relativ einfachen
Mitteln in JavaScript das objektorientierte Paradigma imitiert wird. Dadurch kann man
sich teilweise die Vorteile der OOP8 zu Nutze machen solange man sich nur konsequent
genug an die definierten Regeln hält, wie es beispielsweise die hwlib vorexerziert.
5.2.2
Funktionalität im Überblick
Alles was auf irgendeine Weise zur hwlib gehört befindet sich per definitionem im Verzeichnis hwlib/ des Wavemaster-Verzeichnisses, zum Beispiel:
~/wavemaster-5.1/hwlib/
Die Kernobjekte der hwlib besitzen das Präfix hw_“ in ihrem Namen und werden in
”
gleichnamigen Files mit der Extension .js“ gespeichert. Zum Beispiel ist der Source”
code des hw_TextObject im File hw_TextObject.js zu finden. Alle Files der Kernobjekte befinden sich im Verzeichnis hwlib/objects/. Neben den Kernobjekten stellt
die hwlib auch eine große Menge zusätzlicher Objekte zur Verfügung, die im Verzeichnis hwlib/utils organisiert sind und von dort auf Bedarf eingebunden werden können.
Helfer-Objekte sind für die Server- und die Client-Seite der Applikation für die verschiedensten Aufgaben vorhanden, zum Beispiel das Objekt hwlib_url zur Manipulation
von URLs. Objectbrowser, Sequencer, Rightswizard sind kleine, oft benötigte Minianwendungen, die ebenso fixer Bestandteil der Library geworden sind. Für die Erzeugung
von Formularen werden hw_FormEntry-Objekte verwendet, die es erlauben ohne direkte
HTML-Kenntnisse Formulare zu bauen, die dem derzeitigen Template-Design des HWIS
entsprechen. Dieses Verfahren hat sich als sehr komfortabel und zeitsparend erwiesen.
Die Superklasse aller Objekte der Library bildet das hw_object. Von Seiten der
Funktionalität ist das hw_Object das mächtigste Objekt der hwlib. Die in großer Anzahl
8
Object-Oriented Programming.
101
5 PROJEKT CO2
vorhandenen Methoden erlauben die verschiedensten Manipulationen mit Objekten am
HWIS: Verschieben, Kopieren, Löschen und Erzeugen von Objekten erfolgt mit einfachen
Methodenaufrufen und muss nicht immer zeitintensiv über Methoden des JavaScript API
implementiert werden. Fast alle restlichen Kernobjekte der Library entsprechen den
spezialisierten Objekttypen des HWIS. Als Beispiel kapselt das hw_CollectionObject
Fähigkeiten einer Collection des HWIS und besitzt zusätzliche Methoden für die Manipulation der Kinder-Objekte. Die Objekt-Hierarchie der Library in Abschnitt 5.2.3
verdeutlicht diese Verbindung. Aus diesen Gründen fungiert die hwlib als Schnittstelle
zwischen Programmierer, Hyperwave API und Objekten am HWIS.
Erzeugung eines Objekts:
Ein reales Server-Objekt kann in sehr einfacher Weise durch ein äquivalentes, viel mächtigeres hwlib-Objekt repräsentiert werden. Angenommen das Objekt am Server hat den
Namen "test/test.txt", dann kann mit der JavaScript-Anweisung
var testObject = new hw_Object("test/test.txt");
ein spezielles hw_Object generiert werden, mit dem etwa die Änderung von Attributen
viel leichter zu bewerkstelligen ist. Im unserem Falle handelt es sich offensichtlich um ein
Text-Objekt, das wesentlich besser durch ein hw_TextObject repräsentiert werden kann.
Um nicht jedesmal die adäquaten hwlib-Objekte aus den Server-Objekten in eigener
Regie erzeugen zu müssen, übernimmt diese Aufgabe in der hwlib ein Object Generator .
Dieser Generator erzeugt aus der übergebenen GOID eines Objektes automatisch das
passende Library-Objekt:
testObj = hw_ObjectGenerator(testObj.obj());
Als Kriterium für die Auswahl des richtigen hwlib-Objekts dienen spezielle Attribute
des Server-Objekts wie DocumentType, CollectionType oder DocumentClass.
Integration in den Wavemaster:
Die hwlib greift sehr stark in das ursprüngliche Template-Konzept des Wavemasters
ein. Das passiert durch Einbinden hwlib-spezifischer JavaScript-Files und PLACETemplates im Master-Template des Wavemasters, sprich im master.html. Ein hwlibUser-Template eines Objekts sieht wie folgt aus:
%%include "hwlib/default.usertemplate.amster.hwt"%%
%%hwlib_defaultusertemplate_master_hwt%%
102
5 PROJEKT CO2
Abbildung ?? stellt beide Varianten der hwlib-Integration grafisch dar und verdeutlicht
das zeitliche Zusammenspiel der involvierten Files. Auch CO2 verwendet spezielle User-
body macro
footer macro
request
hwlib_defaultusertemplate_master_hwt
default.body.hwt
macro
process standard actions
Web-Browser
header macro
response
default.include.hwt
default.action.suffix.hwt
default.global.hwt
default.action.hwt
default.master.html
Templates zum Einbinden der hwlib und der applikationsspezifischen Files.
default.include.hwt
default.global.hwt
default.action.hwt
hwlib HTML Header
default.body.hwt
hwlib HTML Footer
Abbildung 5.2: Request/Response-Schema über default.master.html oder PLACE-Makro
hwlib_defaultusertemplate_master_hwt
5.2.3
Objekt-Hierarchie
Alle Kernobjekte der hwlib sind in eigenen Files im Verzeichnis hwlib/objects zu
finden. Aufgrund des objektorientierten Ansatzes – von der hwlib von Grund auf verfolgt – bilden diese Objekte einen Klassenbaum, der die Ableitungsbeziehungen der einzelnen Objekte visualisiert. Abbildung 5.3 stellt die Klassenhierarchie grafisch in UML9 Notation dar und zeigt die ursprüngliche Beziehung aller Objekte zum hw_Object. Die
sehr mächtige und breit gefächerte Funktionalität des hw_Object wird dabei an alle Kernobjekte der Library vererbt.
Die hwlib ermöglicht dem Programmierer sich auf die wesentlichen Punkte der Applikationsentwicklung zu konzentrieren, nämlich auf die Modellierung der Datenstrukturen und dem Architectural Design“. Für die anfallenden Standardaufgaben stellt die
”
9
Uniform Modelling Language
103
5 PROJEKT CO2
5.3 STRUKTUR UND REQUESTABARBEITUNG
hw_Object
hw_DocumentObject
hw_TextObject
hw_TextObjectHTML
hw_ImageObject
hw_GenericObject
hw_CollectionObject
hw_SequenceObject
hw_ClusterObject
hw_MultiClusterObject
hw_AlternativeClusterObject
hw_QueryObject
Abbildung 5.3: hwlib Objekt-Hierarchie in UML Darstellung.
hwlib leicht konfigurierbare Objekte oder sogar ganze Module bereit, ein großer Vorteil
auch für die Fertigung von Prototypen, da in sehr kurzer Zeit bereits ansehnliche Ergebnisse geliefert werden können. Deshalb entschied sich auch das Entwickler-Team des
CO2-Projekts für den Einsatz der hwlib.
5.3
Struktur und Requestabarbeitung
Wie bereits in Abschnitt 5.2 erwähnt werden in der CO2-Applikation spezielle UserTemplates eingesetzt, um die notwendigen PLACE und JavaScript-Files einzubinden.
Wie fügen sich nun diese in den Verzeichnisbaum der Applikation? Abschnitt 5.3.1
zeigt wie die File- und Verzeichnisstruktur der Applikation aussieht. Einige spezielle
CO2-Objekte werden daraufhin in Abschnitt 5.3.2 beschrieben. Anschließend führt die
Diskussion direkt in das Konzept der CO2-Requestbearbeitung in Abschnitt 5.3.3. Dort
wird Schritt für Schritt erklärt, wie ausgehend von einem Client-Request eine entsprechende HTML-Seite generiert wird.
104
5 PROJEKT CO2
5.3.1
File-Hierarchie
Alle Files und Templates der Applikation befinden sich im Verzeichnis
wavemaster-ca/ca/fk/co2
der HWIS-Installation oder im Wavemaster-Verzeichnis eines Users, was generell während der Entwicklungsphase praktiziert wird. Abbildung 5.4 veranschaulicht im linken
Teil den Kontext des Applikationsverzeichnisses und listet im rechten Teil sämtliche
CO2-Objektfiles auf. Insgesamt umfasst die Applikation 32 spezialisierte CO2-Objekte,
Abbildung 5.4: CO2 File-Hierarchie und Objektfiles.
die durch das Präfix co2_“ gekennzeichnet sind. Im Verzeichnis objects/ werden die
”
entsprechenden JavaScript Source-Files organisiert. Mit der aus Abbildung 5.4 ersichtlichen Filestruktur verfolgt CO2 die gleiche Linie wie in der hwlib.
5.3.2
CO2-Objekte
Abgeleitet von den organisatorischen Prozesseinheiten des Pflichtenhefts wurden JavaScript Objekte für die Applikation entworfen. Dabei fanden die meisten Entities – siehe
105
5 PROJEKT CO2
Abschnitt 5.1.2 – eine gleichnamige Objektrepräsentation. Einige werden nachfolgend
zum besseren Verständnis aufgelistet:
Prozessmodell
−→
co2_Prozessmodell
Vorgang
−→
co2_Vorgang
Tätigkeit
−→
co2_Taetigkeit
Arbeitsschritt
−→
co2_Arbeitsschritt
Medium
−→
co2_Medium
Die vollständige Liste der CO2-Objekte kann im rechten Teil von Abbildung 5.4 gefunden werden. Superklasse fast aller CO2-Objekte ist ein Cluster mit dem Namen
co2_Cluster, der vom hw_CollectionObject abgeleitet und spezialisiert wurde. Das
führt gleich zu einem Kernpunkt der CO2-Applikation und hwlib-basierenden Applikationen im Generellen: Eine modellierte Entity wird fast immer durch ein ContainerObjekt am Hyperwave Server repräsentiert. Das heißt, ein JavaScript-Objekt besteht
aus mehreren Server-Objekten und besitzt nur als Ganzes eine sinnvolle Bedeutung für
die Applikation, ein Ansatz den Hyperwave mit der Einführung der Dokument-Klassen –
siehe Abschnitt 3.2.3 – seit kurzem auch verfolgt.
Als Beispiel soll das Objekt co2_Fragestellung dienen, das aus einer Reihe von
Unterobjekten modelliert wurde. Die Relationen der einzelnen Klassen oder Objekte sind
co2_Fragestellung
1 co2_Tip
1 co2_Kurzbeschreibung
1 co2_Beschreibung
* co2_Variante
1
*
+
co2_Kurzbeschreibung
co2_WrapperObjectTaetigkeit
co2_Fragestellung
Abbildung 5.5: Klassendiagramm der co2_Fragestellung
in Abbildung 5.5 dargestellt. Im Falle der Fragestellung zeigt sich ein optional rekursiver
Aufbau eines Objekts, da eine Variante wieder eine Fragestellung beinhalten kann. Dieser
Umstand kann fallweise zu sehr komplexen, verschachtelten Strukturen am Server führen,
die bei der Darstellung des Objektes durchschritten“ werden müssen. Das kann bei
”
106
5 PROJEKT CO2
der dynamischen Erzeugung der HTML-Repräsentation des angeforderten Objektes zu
sehr langen Verarbeitungszeiten“ führen. Siehe Abbildung 5.1 für ein Beispiel einer
”
Fragestellung.
5.3.3
Requestabarbeitung
Das Herz der Applikation liegt im Aufrufkonzept der Makros und Funktionen und in
der Art und Weise, wie diese über Includes eingebunden werden. Ausgehend von einem
Beispiel-Request soll der Ablauf der Verarbeitung am Server Schritt für Schritt erklärt
werden. Da es sich dabei um relativ komplexe Verarbeitungszusammenhänge handelt,
wird die Erklärung durch die schematische Darstellung des Ablaufes in Abbildung 5.6
unterstützt. Die in Abbildung 5.6 eingezeichneten Punkte (❶ – ❽) definieren dabei die
beschriebenen Verarbeitungschritte der Reihe nach.
Ausgangssituation:
Ein Benutzer der CO2-Applikation möchte sich gerne über einen speziellen Vorgang –
nennen wir ihn ‘Vorgang A’ – näher informieren. Dazu wählt er aus der im Web-Browser
dargestellten Vorgangsliste ‘Vorgang A’ per Mausklick. Im gleichen Moment schickt der
Web-Browser einen Request mit der kodierten URL des aufzurufenden Vorganges an den
Server. Dort beginnt ausgehend von der URL und dem festgelegten Place-Template des
Vorgangsobjekts die Abarbeitung des Requests.
❶ Über den ersten Teilstring der URL – die Zeichenfolge vor dem Fragezeichen ( ?“)
”
am Anfang des URL-Strings – wird ein spezielles Objekt am Server referenziert, im
Beispiel ‘Vorgang A’. Der Server erkennt, dass im Fall von ‘Vorgang A’ das PLA”
CETemplate“ Attribut gesetzt ist und verarbeitet anstelle des standardmäßigen
Templatesatzes, das über das Attribut referenzierte Template. Dieses Template
liegt ebenfalls am Server und besteht für die CO2-Applikation aus zwei Zeilen:
%%include ca/fk/co2/master.hwt%%
%%ca_fk_co2_master%%
Die erste Zeile inkludiert das Master-Template der CO2-Applikation und in der
zweiten Zeile wird das darin definierte Makro ca_fk_co2_master aufgerufen.
❷ Durch das Einbinden des Files master.hwt im ersten Schritt der Requestverarbeitung wird das Makro ca_fk_co2_master definiert. Dieses Makro bindet weitere
107
5 PROJEKT CO2
ca/fk/co2/master.hwt
%%macro ca_fk_co2_master%%
5
include
include
hwlib/default.include.hwt
createWrapperAndLink.action
assignToOrganisations.action
objects/co2_WrapperObjectVorgang.js
objects/co2_WrapperObjectVorgang.js
navi/co2_Navigation.js
copyStellenRollen.action
6
ca/actions.hwt
include
include
ca/fk/co2/actions.hwt
objects/co2_Global.js
objects/co2_Ansprechpartner.js
ca/global.hwt
4
call
ca/fk/co2/action.hwt
%%htmlBuilder%%
ca/fk/co2/include.hwt
3
1
Objekterzeugung:
currentUrlObject
currentHWObject
layout
BACA_identify.action
poolIdentify.action
passwdChange.action
hwlib/default.actions.hwt
insert.Action
modify.action
Requestparameter
Debuglevels CO2, VIP, HWLIB
displayForm.action
ca/fk/co2/applicationBody.hwt
browser/component.hwt
%%macro applicationBody
<SERVER>
currentHWObj.displayContent();
</SERVER>
sequencer/component.hwt
%%macro htmlBuilderHead%%
<HEAD>
Meta-Tags
Client-Side JS
</HEAD>
%%endmacro%%
ca/fk/co2/htmlBuilder.hwt
ca/navi/include.html
ca/htmlBuilderHeader.hwt
ca/htmlBuilderBody.hwt
%%macro htmlBuilder%%
%%htmlBuilderHead%%
%%htmlBuilderBody
%%endmacro%%
7
%%macro htmlBuilderBody%%
<BODY>
<SERVER>writeln(layout.navi_left());</SERVER>
%%applicationBody%%
</BODY>
%%endmacro%%
8
Abbildung 5.6: Feinkonzept der Requestabarbeitung.
108
HTML-Page
2
URL initiated Request
5 PROJEKT CO2
Files ein und beginnt gleich mit dem wichtigsten: ca/fk/co2/include.hwt. Dieses
File umfasst alle für die Applikation wichtigen Include-Anweisungen.
❸ Neben dem Default-Include“ der hwlib werden alle JavaScript Source-Files der
”
CO2-Objekte eingebunden und dadurch vom Interpreter geparst.
❹ Durch das Einbinden des Files ca/global.hwt werden explizit Objekte ausgehend
von den URL-kodierten Variablen erzeugt. Zu diesen Objekten gehören:
• currentUrlObject: Kapselt die aktuelle URL des Requests.
• currentHWObject: Das aktuell angeforderte Objekt wird über den ObjektGenerator erzeugt. Im Falle von ‘Vorgang A’ wird eine Instanz von der Klasse
co2_Vorgang generiert.
• layout: Ein für die Darstellung wichtiges Objekt, das festlegt welche Style
Sheets zur Verwendung kommen, ausgehend von der Unterscheidung zwischen
VIP und CO2.
Das File ca/fk/co2/applicationBody.hwt definiert das Makro applicationBody
und das File ca/fk/co2/htmlBuilder.hwt definiert das Makro htmlBuilder, die
beide in weiterer Folge aufgerufen werden.
❺ Neben den allgemeinen Includes werden noch zusätzliche Files für das ActionHandling benötigt. Das Template ca/fk/co2/action.hwt bindet alle dazu benötigten Action-Templates ein. Beginnend mit speziellen CO2-Actions über allgemeine CA-Actions bis zu den Actions der hwlib. Im Beispiel von ‘Vorgang A’ wird
hier abhängig vom Wert der URL-kodierten Variable action eine Aktion abgearbeitet. Wurde keine spezielle Aktion angegeben, wird das angeforderte Objekt
(‘Vorgang A’) nur dargestellt.
❻ Nach dem Einbinden von include.hwt und action.hwt wird abschließend das Makro htmlBuilder aufgerufen. Dieses Makro baut aus den Vorgaben des Requests
eine vollständige HTML-Seite zusammen. Der HTML-Head wird dabei durch das
Makro htmlBuilderHead und der BODY durch das Makro htmlBuilderBody dynamisch erzeugt.
❼ Im Makro htmlBuilderBody erfolgt der Aufruf der Methode navi_left() des
layout Objekte, die den HTML-Sourcecode für die Navigationsleiste der linken Sei-
109
5 PROJEKT CO2
5.4 ANMERKUNGEN ZUM PROJEKT
te liefert. Das Kernstück der Darstellung wird anschließend durch den Aufruf des
Makros applicationBody erzeugt. Dieses kleine Makro fordert das currentHWObj
auf, sich einfach selbst darzustellen, das heißt die dafür notwendigen HTMLAnweisungen als String zu retournieren. Fast alle Kernobjekte der CO2-Applikation
sind mit der Methode displayContent ausgestattet, die für diese Aufgabe zuständig ist.
❽ Nach Aufruf aller Makros und Funktionen wird als Ergebnis eine vollkommen dynamisch und auf Basis von Benutzeraktionen generierte HTML-Seite mittels HTTP
an den Web-Browser zurückgeschickt, wo ‘Vorgang A’ wie gewünscht dargestellt
werden kann.
Die über acht Schritte durchgeführte Erklärung zeigt, dass recht aufwendige und komplizierte Mechanismen in Gang gesetzt werden müssen, um eine einzelne HTML-Seite zu
generieren. Der große Vorteil in der dynamischen Technik ist im wesentlich geringeren
Wartungsaufwand zu finden, den man durch statische HTML-Seiten nie erzielen kann.
5.4
Anmerkungen zum Projekt
Die im Zuge der Projektarbeit gemachten Erfahrungen erweisen sich bereits jetzt als sehr
wertvoll. Abschnitt 5.4.1 soll aber dennoch einige Probleme, die während des Projektverlaufes aufgetreten sind, diskutieren. Abschnitt 5.4.2 beschließt mit dem derzeitigen
Status des CO2-Projektes dieses Kapitel.
5.4.1
Probleme während des Projektverlaufes
In jedem Projekt treten unvermeidlich Probleme an den Tag, so auch im Zuge der Entwicklung der CO2-Applikation. Einige lösen sich von selbst und von anderen lernt man.
Die wichtigsten Problempunkte sollen hier ganz kurz beschrieben werden:
• Falsche Vorgaben: Die CA unterschätzte sehr grob das zu erwartende Zugriffsverhalten der Benutzer und die mit dem dynamischen Seitenaufbau verbundenen
Verarbeitungszeiten des Servers. Das führte im Extremfall zu Seitenaufbauzeiten
von über 2 Minuten! Die langen Aufbauzeiten sind dabei teilweise durch die Architektur der Applikation begründet, weil bei der Darstellung oft sehr komplexe
Objektstrukturen dynamisch durchschritten werden müssen.
110
5 PROJEKT CO2
5.4 ANMERKUNGEN ZUM PROJEKT
• Change Requests: Die von der CA deponierten Change Requests (CRs) wurden
in den meisten Fällen mündlich durchgeführt. Das war insofern problematisch,
da es fast unmöglich ist während eines Telefonats alle Details des CRs zu protokollieren. Für die Nachvollziehbarkeit des Projekts ist aber eine standardisierte
Form der CR-Aufnahme unumgänglich und fordert eine schriftliche Formulierung
des CRs von Seiten des Auftraggebers.
• Zeitdruck: Da die Verantwortlichen der CA selbst unter Termindruck standen,
übten sie diesen naturgemäß weiter auf uns aus. Das erforderte oft gesonderte Programmiereinheiten der Entwickler, um den Zeitplan halten zu können. Implementieren wird dabei zusehends zu einer Routineangelegenheit und die Fehlerhäufigkeit
steigt wieder, ein Handicap mit der die Software-Entwicklung aber tagtäglich leben
muss.
• Unzureichendes Projektmanagement: Aufgrund des engen Zeitplans und
vielleicht auch des unterbesetzten Entwicklerteams wurde Projektmanagement nur
sehr am Rande betrieben. Die Koordination der Teilaufgaben funktionierte dennoch gut und die Integration der einzelnen Teile zu einem Ganzen ebenso10 . Nur
der eigentliche Projektaufwand in Mannstunden bleibt einer groben Schätzung
vorbehalten.
5.4.2
Derzeitiger Projektstatus
Aufgrund massiver Performance-Probleme der Applikation, einerseits in den falschen
quantitativen Vorgaben der CA und andererseits in Schwächen der Appliaktionsarchitektur begründet, ist eine Aufstockung der Prozessorleistung der einzige Weg, die teilweise
horrenden Antwortzeiten auf ein erträgliches Maß zu verkürzen. Aus diesem Grund wird
zur Zeit ein Ausbau der Server-Hardware erwogen, der natürlich mit intensiven Kosten
verbunden ist. Das IICM hat im Herbst die Applikationsentwicklung des CO2-Projekts
völlig abgeschlossen und den Sourcecode-Baum der CA übergeben. Kleine Korrekturen
und Ausbauarbeiten werden aber am Institut noch immer durchgeführt.
10
Für die Integration wurde CVS erfolgreich eingesetzt.
111
6 Schlußfolgerungen und Ausblick
So no client to install, no server to install, and
access from anywhere. Smells like nirvanaa .
Jim Seymour
a
Send Out for Software [Seymour, 1999b].
Das letzte Kapitel dieser Arbeit zieht ein Resumee aus den Erkenntnissen der theoretischen Untersuchung auf Basis einer fundierten Internet-Recherche und den Erfahrungen
der praktischen Arbeit. Die praktischen Erfahrungen wurden einerseits durch die reale
Erprobung der besprochenen Web-Technologien sowie ausgewählter Server und andererseits durch die erledigte Arbeit im Rahmen des CO2-Projekts gewonnen. Ein Ausblick
auf zu erwartende Entwicklungen auf Grundlage momentaner Trends bei Web-Applikationen beschließt diese Arbeit.
6.1
Schlußfolgerungen
Wachstum des Internet:
Im Zeitraum November 1999 bis März 2000 wuchs die Anzahl der vom Netcraft Server Survey [Netcraft, 2000] berücksichtigten Web-Sites von 9.5 auf 13.1 Millionen. Mit
dem Wissen, dass die Server des Intranet-Bereiches in diesen Zahlen gar nicht aufscheinen, kann auf die derzeit fast exponentielle Ausbreitungsgeschwindigkeit des Internet
geschlossen werden. Die Auswirkungen dieses Booms, Hypes oder wie auch immer man
es nennen mag, werden tagtäglich an immer stärker veränderten Gesellschafts- und Geschäftsregeln sichtbar. Als Randbemerkung soll hier noch angeführt werden, dass sich
seit Jänner 2000 bereits mehr als eine Milliarde [Inktomi, 2000] Seiten im Web befinden.
112
6 SCHLUSSFOLGERUNGEN
6.1 SCHLUSSFOLGERUNGEN
Qualitätskriterien einer Web-Applikation:
Die Qualitäts- sind gleichzeitig die Erfolgskriterien der Web-Applikation. Das spiegelt
sich inbesondere bei e-Commerce Unternehmen wieder, bei denen das Geschäftspotential
oft ausschließlich in der Web-Site steckt1 . Im Verlauf des CO2-Projekts haben sich die
drei folgenden Kriterien als besonders entscheidend erwiesen:
• Response Time: Wie bereits in Abschnitt 2.1.3 beschrieben, ist die Antwortzeit
das wichtigste Kriterium für den Benutzer und damit für die Akzeptanz und den
Erfolg einer web-basierenden Applikation. 10 Sekunden ist das oberste Zeitlimit,
um nicht die Aufmerksamkeit des Benutzers zu verlieren [Nielsen, 2000a]. Die
aus dem CO2-Projekt (Abschnitt 5) gewonnenen Erfahrungen verstärken auch aus
praktischer Sicht die Bedeutung dieses Kriteriums.
In diesem Zusammenhang fordert Jakob Nielsen auch vorhersagbare Antwortzeiten,
die von Session zu Session nicht sehr stark variieren. Damit fällt es dem Benutzer
leichter, seine Arbeitsweise an die Applikation anzupassen [Nielsen, 2000a].
• Skalierbarkeit: Die Entwicklung von auftretenden Benutzungsmustern einer WebApplikation kann nur sehr schwer vorausgesagt werden. Sicher ist allerdings, dass
sich die Belastung der Applikation schlagartig ändern kann [Baum, 1999]. Ist
man für diese Eventualität nicht entsprechend gerüstet, kann ein erhöht auftretender Zugriff die ganze Web-Applikation in die Knie zwingen, wie es beispielsweise
Toys‘R‘us2 im November 1999 passiert ist [Carr, 2000]. Skalierbarkeit erweist sich
vor allem für den Bereich des e-Business als sehr kritisch, da ein unerwarteter
Ausfall eines Servers oder einer Applikation zu erheblichen finanziellen Verlusten
führen kann. Die Untersuchung der Server-Software in dieser Arbeit zeigte aber
deutlich, dass die Hersteller ein erhöhtes Augenmerk auf die Skalierungsmöglichkeiten ihrer Server legen. Dennoch muss die Architektur der Web-Applikation vordringlich skalierbar sein, um die bereitgestellten Möglichkeiten des Servers nutzen
zu können. Diese Eigenschaft wurde auch in Abschnitt 2.2 angesprochen und ist
ein Problempunkt des CO2-Projekts.
Werkzeuge für automatisiertes Load oder Stress-Testing können bereits sehr realistische Szenarien der Benutzungsbelastung simulieren und dadurch die Belastungs1
2
Indeed, for e-commerce companies the site is the company“ [Nielsen, 2000a].
”
http://www.toysrus.com
113
obergrenze3 einer Anwendung feststellen. Web-Applikation entwickeln sich zunehmend zu geschäfts-kritischen Systemen – und für geschäfts-kritische Systeme ist ein
Test durch derartige Tools – WebLoad 4 als Beispiel – ein absolutes Muss, bevor
sie online gehen. Damit können von Vornherein entsprechende Server-Kapazitäten
für die Eventualität einer Überlastung eingeplant oder einfach die geforderte Lasttauglichkeit der Applikation überprüft werden.
• Usability: Nach wie vor helfen Performance und Skalierbarkeit einer Web-Applikation nicht viel, wenn der Benutzer nur sehr mühsam mit der Bedienung zu
Rande kommt. Allein klare und einfache Strukturen in puncto Seitenaufbau und
Navigation versprechen den gewünschten Erfolg. Jacob Nielson bringt es auf den
Punkt: Usability rules the web.“ [Nielsen, 2000a].
”
Eng mit dieser Thematik verwandt ist die Diskussion um die verwendete Informationsarchitektur [Rosenfeld & Morville, 1998], die bestimmt in welcher Form
und Struktur dem Benutzer die angebotene Information präsentiert und wie vom
Benutzer erhaltene Information wieder am Server abgelegt wird. Der HWIS – in
Abschnitt 3 beschrieben – folgt einer streng hierarchischen Architektur, die dem
Server inherent gegeben ist. Eine gute Lösung, da sich der User intuitiv an Hierarchien orientiert und diese als vertraut empfindet. Klare Strukturen, wie sie der
HWIS vorgibt, helfen dem Benutzer [Nielsen, 2000b], sich im Informationsraum
zurecht zu finden, beim Apache hingegen – in Abschnitt 4 beschrieben – liegt es
am Appliaktionsentwickler, eine entsprechende Architektur am Server zu verwirklichen.
Auswahl der Server-Software und Web-Technologie:
Die Auswahl der Server-Software ist auch immer indirekt eine Auswahl der Web-Technologie und das gilt ebenso für den umgekehrten Fall. Tatsache ist, dass es derzeit
ein sehr breites und vielfältiges Spektrum an Server-Software am Markt gibt (siehe Abschnitt 2.2.1). Eine one-size-fits-all“-Lösung [Desal et al., 1999] für das Anforderungs”
profil einer Web-Applikation verwehrt sich aufgrund der inherenten heterogenen Struktur
dieser Applikationsform a priori. Die Strategie der Auswahl besteht nun im Wesentlichen
darin, die Requirements der Applikation mit den Leistungsprofilen der Server zu verglei3
4
Im Englischen: The volume at which the system breaks down.“
”
http://www.radview.com/products/wl
114
chen und sich auf die Unterstützung weit verbreiteter, offener und starker Technologien
zu konzentrieren. Damit fällt die Wahl auf ein Produkt, das am besten den geforderten
Ansprüchen gerecht werden kann. Aus der Untersuchung des Server-Spektrums ergaben
sich weitere für die Auswahl relevante Punkte:
1. Java-zentriert: Das Gros der untersuchten Application Server unterstützt Java
als Programmiersprache. Darüber hinaus hat SUN eine Java-basierende Gesamtlösung für Web-Applikationen entwickelt, die aus ihrer Sicht aus einem Zusammenspiel von JavaServer Pages, HTML (später XML), Applets, Servlets und BeanKomponenten aufgebaut sind. In Abschnitt 2.3.7 wird ab Seite 58 das zugrunde
liegende Konzept derartiger Web-Applikation dem Leser vorgestellt.
2. Thin-Client: Der Begriff Thin-Client“ wird von einigen Server-Herstellern wie
”
etwa Oracle [OAS, 1998] als Synonym für eine Client-Maschine mit Web-Browser
und Java Virtual Machine verwendet. Das kann Verwirrung stiften, da Thin”
Client“ einerseits für eine speziell klein gehaltene Client-Applikation und andererseits für einen Network Computer, kurz NC5 , als Ganzes stehen kann. Gemeinsam
ist ihnen nur, dass die Applikationslogik zum größten Teil am Server zu finden ist.
Siehe [Wĕbopēdia, 2000].
3. Hyperwave Information Server: Der HWIS bietet aufgrund der inherenten
hierarchischen Server-Struktur klare Vorteile im Umgang mit großen Datenbestände. Es ist festzuhalten, dass der HWIS verstärkt für die Applikationsentwicklung
im Bereich des Intranet konzipiert wird und sich besonders mit Windowssystemen
kooperativ zeigt. Für den Entwickler erweist sich vor allem das mit der Version
5 eingeführte Konzept der Dokument-Klassen als sehr angenehme Entwicklungshilfe für Applikationen. Die in Abschnitt 5.2 beschriebene hwlib erfüllte im CO2Projekt einen sehr ähnlichen Zweck und kann als Vorstufe von Dokument-Klassen
gesehen werden. JavaScript wird in der Applikationsentwicklung voraussichtlich
PLACE à la longue in den Hintergrund drängen.
4. Apache HTTP Server: Als konzeptionell konträres Beispiel zum HWIS, wurde
der Apache HTTP Server aufgrund seiner enormen Popularität und Verbreitung
näher untersucht. Allein im Zeitraum dieser Arbeit (November 1999 bis März 2000)
5
Besitzt keine Harddisk im Unterschied zu einem Fat-Client.
115
6.2 AUSBLICK
stieg der relative Marktanteil des Apache von 54.81 auf 60.05 Prozent, das entspricht einem Zuwachs von etwa 3 Millionen Web-Sites zufolge des Netcraft Server
Survey [Netcraft, 2000]. Das Aushängeschild der Open-Source-Gemeinde hat sich
auch im Einsatz als Testplattform für die praktische Erprobung der untersuchten
Web-Technologien als sehr zuverlässig und stabil erwiesen.
Die Apache Software Foundation6 versucht neue und erfolgversprechende Technologien so früh wie möglich in ihrer Arbeit zu unterstützen, das beweisen eigene Projekte für XML (Apache XML Project bestehend aus: Xerces, Xalan,
Cocoon, FOP ) oder für JSP und Servlets (Jakarta). Ein wesentliches Erfolgskriterium für den Apache bilden populäre ASF-unabhängige Projekte und Entwicklungen wie PHP (www.php3.net), Zend (www.zend.org) und Midgard (www.
midgard-project.org). Die Entwicklergemeinde arbeitet derzeit zügig Richtung
Version 2.0 des Apache HTTP Server.
Persönliche Schlußfolgerungen:
Diese Arbeit hat besonders gezeigt, dass es nur schwer möglich ist, in der Thematik Web”
Applikation“ einen Gesamtüberblick zu bekommen. Das begründet sich hauptsächlich
durch die enorme Angebotspalette an Software und Technologien, deren gewissenhafter
Einzeltest Jahre dauern würde. Durch die praktische Arbeit mit zwei Servern vollkommen unterschiedlicher Konzeption und Marktposition wurde ein Leitsatz deutlich: Berücksichtige immer alternative, zuweilen freie Server oder Technologien, versichere Dich
aber, ob sie für den speziellen Fall auch wirklich geeignet sind.
6.2
Ausblick
CO2:
Die Entwicklungsarbeit des CO2-Projektes ist für das IICM abgeschlossen. Die einzige Möglichkeit die Performance des Systems im jetztigen Zustand zu verbessern, ist in
leistungsstärkere Hardware zu investieren. Für diese Option untersuchten die Projektverantwortlichen der CA bereits die Applikation auf einem performanten Test-System
der Firma SUN in Deutschland. Doch trotz Aufrüstung des Servers und der damit ver6
http://www.apache.org
116
6.2 AUSBLICK
bundenen annehmbaren Applikationsgeschwindigkeit kann nur der Praxiseinsatz zeigen,
ob letztendlich CO2 im Stande ist, die geforderten Ziele zu erreichen.
Allgemein:
In Zukunft werden Web-Applikationen noch stärker mit Funktionalität ausgestattet sein,
die bis dato Desktop-Applikationen vorbehalten war. Besonders bereits zu bestaunende
web-basierende Office-Anwendungen7 [BusinessWire, 2000] verdeutlichen eine weitere
Entwicklungstendenz: Webtop statt Desktop. Web-Applikationen der zweiten Generation sollen Textverarbeitung und Tabellenkalkulation beherrschen. Als Nebeneffekt
werden sogenannte Application Service Providers (kurz ASP) diese Dienste oder Applikationen netzwerk-basierend an Unternehmungen auf Vertragsbasis bereitstellen. Der
Trend geht bereits jetzt in diese Richtung mit der Motivation sich die Installation und
Integration der Sofware/Hardware zu ersparen, sowie die Anzahl der Lizenzen8 .
Sofern nicht spezialisierte Thin-Clints, wie sie etwa von Citrix9 seit einiger Zeit angeboten werden, als Systembasis dienen, ist der Web-Browser das unumstrittene Nummer eins User-Interface der Web-Applikation. Doch durch den zu erwartenden Trend
erfordern Web-Applikationen immer größere Funktionalität vom Web-Browser – Funktionalität, die schon teilweise im Betriebssystem zu finden ist. Als Konsequenz müßte
der Web-Browser allmählich selbst zum Betriebssystem werden, um die gestellten Anforderungen erfüllen zu können [Elrick, 1998].
In puncto Web-Technologien tendiert XML, leise die Rolle eines kommenden Schlüsselspielers (im Engl.: Key Player ) einzunehmen. Namhafte Software-Firmen, darunter
Microsoft und SUN, unterstützen die Bestrebungen des W3C10 , XML als mächtigen
freien Web-Standard zu etablieren. Es wir bereits spekuliert, ob nicht durch XML und
XSLT11 ein neues Programmierparadigma geschaffen wird [Rath, 1999].
Anwendbar können diese vielversprechenden Trends aber nur dann werden, wenn der Flaschenhals Verbindungsbandbreite einmal bis ins Wohnzimmer des Normalverbrauchers
geöffnet wird. Erst dann kann sich Sun’s alter Slogan The Network is the computer“
”
allmählich bewahrheiten. Seien wir dennoch gespannt, was alles auf uns zukommt.
7
ThinkFree Office (www.thinkfree.com) ist sogar vollkommen kompatibel zu Microsoft Office.
Nicht jeder arbeitet jederzeit mit seiner Textverarbeitung.
9
Applikationen über Citrix-Clients (http://www.citrix.com) sind noch sehr langsam [Herel, 1999].
10
http://www.w3.org/XML
11
eXtensible Style Language Transformations. http://www.w3.org/TR/1999/REC-xslt-19991116
8
117
Abkürzungen
AJP . . . . . . . . . . Apache JServ Protocol
API . . . . . . . . . . . Application Programming Interface
APXS . . . . . . . . APache eXtenSion Tool
ASF . . . . . . . . . . Apache Software Foundation
ASP . . . . . . . . . . Active Server Pages
ASP . . . . . . . . . . Application Service Provider
CF . . . . . . . . . . . . Cold Fusion
CGI . . . . . . . . . . Common Gatway Interface
COM . . . . . . . . . Component Object Model
CORBA . . . . . . Common Object Request Broker Architecture
CSJS . . . . . . . . . Client-Side JavaScript
DBD. . . . . . . . . . DataBase Driver
DBI. . . . . . . . . . . DataBase Interface
DCOM . . . . . . . Distributed Component Object Model
DHTML . . . . . Dynamic HTML
DSO . . . . . . . . . . Dynamic Shared Object
EJB . . . . . . . . . . Enterprise JavaBean
118
6.2 AUSBLICK
GPL . . . . . . . . . . General Public License
HG-CSP . . . . . Hyper-G Client Server Protocol
HTML. . . . . . . . HyperText Markup Language
HTTP . . . . . . . . HyperText Transfer Protocol
IDE . . . . . . . . . . . Integrated Development Environment
IIOP . . . . . . . . . . Internet Inter-ORB Protocol
IMAP . . . . . . . . Internet Message Access Protocol
ISAPI . . . . . . . . Internet Server API
JAR . . . . . . . . . . Java Archive
JDBC . . . . . . . . Java DataBase Connectivity
JDK . . . . . . . . . . Java Development Kit
JSDK. . . . . . . . . Java Servlet Development Kit
JSP . . . . . . . . . . . JavaServer Pages
JVM . . . . . . . . . . Java Virtual Machine
LAMP . . . . . . . . Linux Apache MySQL PHP
LDAP . . . . . . . . Lightweight Directory Access Protocol
LWP . . . . . . . . . . Library for Web Programming
MIME . . . . . . . . Multipurpose Internet Mail Extensions
NCSA . . . . . . . . National Center of Super Computing
NNTP . . . . . . . . Network News Transfer Protocol
NSAPI . . . . . . . Netscape Server API
ODBC . . . . . . . . Open DataBase Connectivity
119
6.2 AUSBLICK
ODMA . . . . . . . Open Document Management API
OOP . . . . . . . . . . Object-Oriented Programming
ORB . . . . . . . . . . Object Request Broker
PDF . . . . . . . . . . Portable Document Format
PHP . . . . . . . . . . PHP: Hypertext Preprocessor
POP . . . . . . . . . . Post Office Protocol
RDBMS . . . . . . Relational DataBase Management System
RFC . . . . . . . . . . Request For Comments
RMI . . . . . . . . . . Remote Method Invocation
RXML . . . . . . . RoXen Macro Language
SNMP . . . . . . . . Simple Network Management Protocol
SQL . . . . . . . . . . Structured Query Language
SSI. . . . . . . . . . . . Server-Side Includes
SSJS . . . . . . . . . . Server-Side JavaScript
SSL . . . . . . . . . . . Secure Socket Layer
Tcl . . . . . . . . . . . . Tool Command Language
TCP . . . . . . . . . . Transmission Control Protcol
UML . . . . . . . . . Uniform Modelling Language
URL . . . . . . . . . . Uniform Resource Locator
WAIS. . . . . . . . . Wide Area Information Servers
WAR . . . . . . . . . Web Archive
WWW . . . . . . . World Wide Web
120
6.2 AUSBLICK
XML . . . . . . . . . eXtensible Markup Language
XSLT . . . . . . . . . eXtensible Style Language Transformations
121
Listings
2.1
hello.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2
Products.pl DBI und MySQL . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3
HelloWorld.pl mit FastCGI . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4
HelloWorld.php3
2.5
telefon.php3 PHP und MySQL . . . . . . . . . . . . . . . . . . . . . . . 46
2.6
hello.html mit Server-Side JavaScript. . . . . . . . . . . . . . . . . . . . 49
2.7
Hello, ein vom HttpServlet abgeleitetes Java Servlet . . . . . . . . . . . 53
2.8
HelloWorld.jsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.9
Bean.jsp JavaBeans und JSP . . . . . . . . . . . . . . . . . . . . . . . . . 56
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.10 JSPMySqlBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.1
.db.contr.rc Grundkonfiguration . . . . . . . . . . . . . . . . . . . . . 71
4.1
Ausschnitt aus httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2
Konfiguration von mod_perl . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3
Konfiguration von mod_php3 . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4
Auszug aus php3.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1
Basisklasse Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2
Abgeleitete Klasse Rectangle . . . . . . . . . . . . . . . . . . . . . . . . . 100
122
Alan O. Freier, A. O.; P. Karlton & P. C. Kocher (1996): The SSL Protocol,
Version 3.0, Internet Draft. http://www.netscape.com/eng/ssl3.
Andrews, K.; F. Kappe & H. Maurer (1994): The Hyper-G Network Information
System. ftp://ftp.iicm.edu/pub/papers/dms94.pdf.
ApacheDoc (1999): Apache 1.3 User’s Guide. http://www.apache.org/docs.
Baum, D. (1999):
Scalable Web Apps, Informationweek Online.
http://www.
informationweek.com/722/22iuweb.htm.
Berners-Lee; Fielding & Frystyk (1996): RFC 1945 Hypertext Transfer Protocol
– HTTP/1.0. http://sunsite.auc.dk/RFC/rfc/rfc1945.html.
Berners-Lee; Masinter & McCahill (1994): RFC 1738 Uniform Resource Locators
(URL). http://sunsite.auc.dk/RFC/rfc/rfc1738.html.
Berst, J. (1998): Why Your Desktop Applications Will Soon Disappear. http://www.
zdnet.com/anchordesk/story/story_2881.html.
Brooks, F. P. (1986):
ware Engineering.
No Silver Bullet – Essence and Accidents of Soft-
http://www.virtualschool.edu/mon/SoftwareEngineering/
BrooksNoSilverBull\%et.html.
BusinessWire (2000): Thinkfree.Com Paves The Way from The Desktop to The
Webtop with Free, Web-Based Office Solutions. http://industry.java.sun.com/
javanews/stories/print/0,1797,22670,00.htm\%l.
Campione, M. & c. Wallrath (1999): The Java Tutorial, Second Edition.
123
Carr, N. (2000): The Myth of Scalability. http://www.thestandard.com/article/
display/0,1151,8532,00.html.
Crypto (1998):
Introduction to Public-Key Cryptography.
http://developer.
netscape.com/docs/manuals/security/pkin/contents.htm.
csjsGuide (1999): Client-Side JavaScript Guide Version 1.3.
http://developer.
netscape.com/docs/manuals/js/client/jsguide.
Desal, G.; J. Fenner; J. Patel & M. Schenecker (1999): Web Application Servers
are Here To Stay, Informationweek Online. http://www.informationweek.com/726/
prapp.htm.
E-Soft (2000): Web Survey. http://www.e-softinc.com/survey.
Eilebrecht, L. (1999): Apache Web-Server. mitp, 2. Aufl.
Elrick, J. (1998): But isn’t a browser a desktop application? http://www.zdnet.
com/anchordesk/talkback/talkback_142116.html.
Engelschall, R. S. (1998): Apache 1.3 Dynamic Shared Object (DSO) Support.
http://www.apache.org/docs/dso.html.
Fielding; Mogul; Frystyk; Masinter; Leach & Berners-Lee (1999): RFC
2616 Hypertext Transfer Protocol – HTTP/1.1. http://sunsite.auc.dk/RFC/rfc/
rfc2616.html.
Flanagan, D. (1997): JavaScript: The Definitive Guide. O’Reilly, 2. Aufl.
Freed & Borenstein (1996): RFC 2045 Multipurpose Internet Mail Extensions (MIME). http://sunsite.auc.dk/RFC/rfc/rfc2045.html.
GPL (1999): GNU General Public License. http://www.gnu.org/copyleft/gpl.html.
Haberstadt, A. (1998): Using Apache JServ 1.0b1. http://www.servletcentral.
com/1999-01/jserv.dchtml.
Herel, H. (1999):
Productivity Applications.
stories/reviews/0,6755,2344659,00.html.
124
http://www.zdnet.com/pcmag/
HwisAdmin (1999): Hyperwave Administrator’s Guide - Hyperwave Information Server
Version 5.1, Bd. 3.
HwisNtInstall (1999): Hyperwave Installation Guide for Windows NT, Bd. 4.
HwisPlace (1999): Hyperwave PLACE and Server API - Hyperwave Information Server Version 5.1, Bd. 4.
HwisPlaceWS (1999): Hyperwave PLACE Workshop- Hyperwave Information Server
Version 5.1, Bd. 4.
HwisProg (1999): Hyperwave Programmer’s Guide - Hyperwave Information Server
Version 5.1, Bd. 4.
HwisUnInstall (1999): Hyperwave Installation Guide for UNIX, Bd. 4.
HwisUser (1999): Hyperwave User’s Guide - Hyperwave Information Server Version
5.1, Bd. 2.
Icom (2000): http://www.internet.com.
Inktomi (2000): WebMap. http://www.inktomi.com/webmap.
JServSpec2.2 (1999):
Java Servlet Specification v2.2.
http://java.sun.com/
products/servlet/2.2/.
jsOOP (1997): Object Hierarchy and Inheritance in JavaScript. http://developer.
netscape.com/docs/manuals/communicator/jsobj/contents.\%htm.
JSPSpec1.1 (1999):
JavaServer Pages 1.1 Specification.
http://java.sun.com/
products/jsp/download.html.
Kappe, F. (1991): Aspects of a Modern Multi-Media Information System. ftp://ftp.
iicm.edu/pub/papers/report308.pdf.
Kappe, F. (1999): Hyperwave Information Server - Technical White Paper. http:
//www.hyperwave.at/publish/downloads/twp5.pdf.
Kappe, F.; H. Maurer & I. Tomek (1991): Hyper-G Specification of Requirements.
ftp://ftp.iicm.edu/pub/papers/report284.pdf.
125
Krause, R. & B. L. Hecht (2000): Six Server Segments: Guidelines for Categorizing
Servers. http://serverwatch.internet.com/articles/serve_cat/server_cat_a.
html.
Laurie, B. & P. Laurie (1999): Apache: The Definitive Guide. O’Reilly, 2. Aufl.
Maurer, H. (1996): HYPERWAVE - The next Generation Web Solution. Addison
Wesley Longman Limited.
Mazzocchi, S. & P. Fumagalli (1998): Advanced Apache JServ Techniques. http:
//java.apache.org/jserv/papers/techniques.pdf.
Netcraft (2000): Server Survey. http://www.netcraft.com.
Netscape (2000): Netscape Application Server - White Paper. http://www.iplanet.
com/products/whitepaper/whitepaper_3.html.
Networds (2000): Das Internet-Wörterbuch. http://www.networds.de.
Niederst, J. (1999): Web Design in a Nutshell. O’Reilly.
Nielsen, J. (1997): The need for Speed. http://www.useit.com/alertbox/9703a.
html.
Nielsen, J. (2000a): Designing Web Usability: The Practice of Simplicity. New Riders
Publishing.
Nielsen, J. (2000b): Is Navigation Useful?
http://www.useit.com/alertbox/
20000109.html.
OAS (1998): Oracle Application Server 4.0 White Paper. http://technet.oracle.
com/products/oas/pdf/oas40wp.pdf.
OpenMarket (1996): FastCGI: A High-Performance Web Server Interface. http:
//www.fastcgi.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.h\%tm.
Oracle (1999):
Understanding the Benefits of Oracle Application Server in 3-
Tier Computing. http://technet.oracle.com/products/oas/pdf/benefits_of_
3_tier.pdf.
126
Rath, H. H. (1999): Klein, aber fein. iX .
Raymond, E. S. (1999): The Cathedral and the Bazaar. http://www.tuxedo.org/
~esr/writings/cathedral-bazaar.
Reeg, C. (1999): Datenbank, mySQL und PHP. http://www.jugendnetz-ffm.de/
privat/reeg.
Reynolds & Postel (1994): RFC 1700 Assigned Numbers. http://sunsite.auc.dk/
RFC/rfc/rfc1700.html.
Ricciuti, M. (1998): Application server eludes definiton, CNET News.com. http:
//www.informationweek.com/726/prapp.htm.
Rice, V. (1999): Why it pays to think thin. http://www.zdnet.co.uk/itweek/brief/
1999/44/client/01.html.
Rosenfeld, L. & P. Morville (1998): Information Architecture for the World Wide
Web. O’Reilly.
Saccoccio, R. (1999): FastCGI - Presentation Slides for O’reilly’s Open Source ’99
Conference. http://www.fastcgi.com/docs/OpenSource99/FastCGI.pdf.
Schmaranz, K. (2000): Softwareentwicklung in Inter- und Intranet Umgebungen. ftp:
//ftp2.iicm.edu/pub/kschmar/Internet_Programming_WS_1999_2000.pdf.
Seymour, J. (1999a): Ready for Web Apps? http://www.zdnet.com/pcmag/stories/
reviews/0,6755,2344642,00.html.
Seymour, J. (1999b):
Send Out for Software.
http://www.zdnet.com/pcmag/
stories/reviews/1,6755,2348942,00.html.
ssjsGuide (1999): Server-Side JavaScript Guide Version 4.0.
http://developer.
netscape.com/docs/manuals/ssjs/1_4/ssjspdf.zip.
SSL-Intro (1998): Introduction to SSL. http://developer.netscape.com/docs/
manuals/security/sslin/contents.htm.
Stein, L. D. (1999): Is CGI Dead? http://www.webtechniques.com/archives/1999/
04/webm.
127
W3C (1999): HyperText Markup Language. http://www.w3.org/MarkUp.
White, J. (1999): PHP: A silent killer. http://www.devshed.com/Talk/BrainDump/
PHP.
Wright, G. (1999): What is an Application Server? http://webreview.com/pub/
sections/appserver/index2.html.
Wĕbopēdia (2000): http://webopedia.internet.com.
Wurzenberger, G. (1999): hwlib Reference Guide 1.0.
Xanadu (2000): Project Xanadu - The Original Hypertext Project. http://www.
xanadu.net.
Yumul, R. M. (1998): Getting Started with Java Servlets using Apache JServ. http:
//www.devshed.com/Server_Side/JServ/Started.
Zhang, Y. (1999): Setting Up Database Driven Websites. http://www.devshed.com/
Server_Side/Administration/Database.
128
A Attribute der perfekten Web-Applikation
Bei der Studie verschiedenster White Papers, technischer Spezifikationen und Referenzen im Bereich Web-Technologien und Server-Software während dieser Arbeit, wurde
eine große Anzahl an Attributen von Web-Applikationen gefunden. Fallweise kennt der
Einfallsreichtum diverser Dokumente keine Grenzen und läßt den Einfluß einer offensiven Marketing-Strategie erkennen. Würde eine Web-Applikation alle unten angeführten
Attribute besitzen, könnte man sie zu Recht als perfekt bezeichnen. :-)
Die perfekte Web-Applikation ist:
The perfect Web Application is:
sicher,
skalierbar,
secure,
scalable,
schnell,
anwenderfreundlich,
fast,
user-friendly,
intuitiv,
wiederverwendbar,
intuitive,
reusable,
flexibel,
transparent,
flexible,
transparent,
umfassend,
plattformübergreifend,
comprehensive,
cross-platform,
dynamisch,
zuverlässig,
dynamic,
reliable,
einfach,
modular,
simple,
modular,
effizient,
stabil,
efficient,
stable,
handhabbar,
verteilt,
manageable,
distributed,
robust,
persistent,
robust,
persistent,
kollaborativ,
mächtig,
collaborative,
powerful,
intelligent,
leicht verwendbar,
intelligent,
easy to use,
portierbar,
erweiterbar,
portable,
extendable,
fehlerfrei,
konsistent
error-free,
consistent
und zu guter Letzt billig.
and last but not least cheap.
129
B e-Manie
Bei der Recherche nach typischen Anwendungsbereichen für Web-Applikationen ließen
sich aus ähnlichen Gründen wie in Anhang A vermehrt Begriffe mit einem e“1 als
”
Anfangsbuchstaben, gefolgt von einem Bindestrich, finden. Einerseits überrascht vom
massiven Auftreten und andererseits fasziniert vom Einfallsreichtum und der teilweisen
Bedeutungslosigkeit dieser Wörter, sollen hier die gefundenen e“-Begriffe ihren Platz
”
finden. Anmerkungen sollen dabei zum besseren Verständnis dienen. ;-)
e-business
Geschäfte zwischen Kunden und Lieferanten werden rein über das
Web/Internet abgewickelt.
e-biz
Kurzform für e-business.
e-consultant
Ein Berater für e-commerce.
e-conomy
e-commerce
Steht für Economy“, und indirekt für e-business.
”
Verkauf von Waren über das Web.
e-journal
Ein elektronisches Journal.
e-loan
Kreditgeschäfte über das Web, z.B.: www.e-loan.com.
e-law
Rechtliche Belange im Web/Internet.
e-money
e-services
Elektronische Geld, auch Digital Cash“.
”
Umfasst e-business u. e-commerce, www.hp.com/e-services.
e-solutions
Lösungen für e-commerce.
e-stamp
Postgebühren übers Web bezahlen, z.B: www.e-stamp.com
Und vieles mehr:
e-power, e-answers, e-notes, e-print, e-conference, e-math, ebomb, e-rails, e-zine, e-toys, e-soccer, e-trader, e-rate, e-mail, esports, e-card, e-pc, e-news, e-education, e-tutor, e-industry, esignatures, e-marketing, e-speak, e-show and e-form.
1
Steht in den meisten Begriffen und Akronymen für electronic“.
”
130

Aspekte moderner Web-Applikationen - Das IICM

Transcription

Similar documents

PDF-Download

Einstieg in VBA und die Office Programmier Beispiel von Excel

MVC Architektur in Java Web Anwendungen