Aspekte moderner Web-Applikationen - Das IICM

Technische Universit¨ at Graz Institut f¨ ur Informationsverarbeitung und Computergest¨ utzte neue Medien

Diplomarbeit aus Telematik

Aspekte moderner Web-Applikationen Gegenw¨ artige Technologien und Server im ¨ Uberblick, sowie in der Praxis

Georg Wurzenberger [email protected]

Graz, M¨ arz 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 herk¨ ommlichen Client/Server-Modell und andererseits einen Wechsel im Benutzungsverhalten von Software. Der Web-Browser als Thin-Client verdr¨ angt zunehmend spezialisierte Client-Software und etabliert sich nebenbei als bevorzugtes User-Interface des Anwenders. Der momentane Hype um E-Commerce und E-Business unterst¨ utzt diese Entwicklung noch zus¨ atzlich. Mit vergleichbarer Geschwindigkeit ver¨ andert sich das Angebot vorhandener ServerSoftware, die als Plattform f¨ ur Web-Applikationen in Frage kommt. Gleiches gilt f¨ ur die Vielzahl unterst¨ utzter Web-Technologien, die sehr stark in ihrer gebotenen Leistungsf¨ ahigkeit zu differenzieren sind. Eine One-size-fits-all“ L¨osung bleibt daher auch Web” Applikationen a priori verwehrt. In der vorliegenden Arbeit wird die Bandbreite erh¨ altlicher Server-Software gesichtet, nach definierten Sparten geordnet und auf ihre Funktionalit¨ at hin untersucht. In der Folge werden die Anwendungsm¨ oglichkeiten der zur Zeit popul¨ arsten Web-Technologien mit praktischen Beispielen schwerpunktm¨ aß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 M¨ oglichkeiten durchleuchtet. Details einer f¨ ur 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 f¨ ur ihre stets sehr freundliche und tatkr¨ aftige Unterst¨ utzung in der Zeit meiner aktiven Projektmitarbeit am Institut. Besonderer Dank geb¨ uhrt 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 f¨ ur AMFT, das mir f¨ ur die Zeitdauer meiner Diplomarbeit einen Arbeitsplatz zur Verf¨ ugung gestellt hat und mit Christian Meisl f¨ ur den LATEX-Support sorgte. Meinen Eltern, Roswitha und Johann Wurzenberger, m¨ochte ich an dieser Stelle f¨ ur ihre Liebe und finanzielle Unterst¨ utzung w¨ahrend 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 W¨ urde und Gelassenheit, denn ich weiß ja, wer der bessere von uns ¨ rber bebeiden ist . Bei meiner interaktiven Rechtschreibkorrektur namens Birgit Fa danke ich mich herzlich f¨ ur ihre sorgf¨ altige 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 selbstst¨ andig 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 ¨ Gegenw¨ artige Technologien und Server im Uberblick, sowie in der Praxis

© Georg Wurzenberger , Graz im M¨arz 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. S¨ amtliche nicht referenzierte Abbildungen wurden mit GIMP oder xfig erstellt. Abbildung 2.8 und 4.3 wurden mit dem Einverst¨ andnis 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

Kapitel¨ ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Unterst¨ utzte 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

Unterst¨ utzte 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 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.2.1

5.3

5.4

Inhaltsverzeichnis

5.2.2

Objektorientierte Programmierung mit JavaScript . . . . . . . . . 99 ¨ Funktionalit¨ at im Uberblick . . . . . . . . . . . . . . . . . . . . . . 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 w¨ahrend des Projektverlaufes . . . . . . . . . . . . . . . 110

5.4.2

Derzeitiger Projektstatus . . . . . . . . . . . . . . . . . . . . . . . 111

6 Schlußfolgerungen

112

6.1

Schlußfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.2

Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Abk¨ urzungen

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 gegenw¨artig mit gr¨ oß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 pass´e, seit Einkaufsk¨ orbe nicht nur wie gewohnt aus Metall, sondern auch virtuell sind. Das Internet macht es m¨oglich: Einfach und schnell. Das World Wide Web – kurz Web –, als popul¨ arster Teil des Internet, unterst¨ utzt wesentlich mit dem momentanen Hype um e-Commerce und e-Business diesen Ver¨ anderungsprozess. Die web-zentrierte Ansicht von Problemen dr¨ angt sich in diesem Kontext verst¨ arkt in den Mittelpunkt der Software-Entwicklung. Web-basierende Anwendungen – kurz Web-Applikationen – liegen voll im Trend und k¨ ampfen offensiv um den Markt gewohnter Desktop-Anwendungen, die dadurch v¨ ollig verschwinden k¨ onnten [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 L¨osung 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 geh¨ ort die breite Masse web-basierender E-Mail Dienste zur bekanntesten Gruppe unentgeltli¨ cher Internet Services. Einen groben Uberblick, inwieweit Desktop-Anwendungen schon durch ¨aquivalente 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 angef¨ uhrten 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 Komplexit¨ at erreichen, wie die entsprechenden Desktop-Anwendungen. Neben dem Internet bildet das Intranet den zweiten großen Anwendungsbereich f¨ ur Web-Applikationen. Im einen Fall versuchen Unternehmungen immer h¨ aufiger 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-f¨ ahig“ ” machen und den dabei entstehenden Vorteil der einfacheren Wartung genießen. In der Tat ist die momentan verf¨ ugbare Server-Software gerade f¨ ur die Verbindung heterogener Applikationsstrukturen ger¨ ustet, was durch die breite Unterst¨ utzung vorhandener WebTechnologien, verteilter Objektsysteme, Daten¨ ubertragungsprotokolle 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 gegenw¨artige Situation, versucht die vorliegende Arbeit ¨ einen m¨ oglichst breiten, praxisorientierten und verst¨ andlichen Uberblick des technischen

11

1 EINLEITUNG

1.1 VORAUSGEHENDE BEMERKUNGEN

¨ Umfeldes moderner web-basierender Applikationen zu geben. Der Uberblick soll dabei folgende Punkte umfassen: • Analyse des Spektrums verf¨ ugbarer Server-Software. • Bewertung einiger ausgesuchter Web-Technologien. • Untersuchung zweier konzeptionell unterschiedlicher Server. • Detail-Aspekte einer realisierten Web-Applikation. Im Schwerpunkt soll in den angef¨ uhrten Punkten auf praxisbezogene Problemstellungen Bezug genommen werden. Auftretende Schwierigkeiten, sowie St¨ arken und Schw¨achen der jeweils untersuchten Technologie sollen dokumentiert werden und als Grundlage f¨ ur 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. Pers¨ onliche Faszination der Thematik: ¨ Dadurch, dass in Web-Applikation die verschiedensten Programmiersprachen, Ubertragungsprotokolle, Sicherheitstechniken und Web-Technologien kooperieren, bedarf es an fundiertem Wissen der einzelnen Komponenten und an viel praktischer Erfahrung, um an der m¨oglichen Komplexit¨ at dieser Applikationsform nicht zu scheitern. Die Herausforderung, die sich einem dabei stellt, ist der Punkt, der mich pers¨ onlich am meisten fasziniert.

1.1

Vorausgehende Bemerkungen

Begriffswelt: Die deutschsprachige Begriffswelt der Telekommunikation (TK) und Informationstechnologie (IT) orientiert sich sehr stark an den ¨aquivalenten englischen Begriffen. Aufgrund der rasanten Entwicklung im Bereich der TK und IT ist die Rechtschreibung vieler neuer Begriffe im Deutschen noch nicht gekl¨ art. Soweit der DUDEN bereits eine genaue Rechtschreibung f¨ ur ein verwendetes Wort vorsieht, wird sie in dieser Arbeit ber¨ ucksichtigt. Im Zweifelsfall wird auf die englischsprachige Form des Wortes eins-zu-eins zur¨ uckgegriffen, wie etwa beim Begriff Application Server. Pers¨ onlich vertrete ich die Meinung, dass die

12

¨ 1.2 KAPITELUBERSICHT

1 EINLEITUNG

englischsprachigen Begriffe ohne langwierige Diskussion und ohne spezielle Anpassung an die deutsche Sprache u ¨bernommen werden sollten, da sie die Sache naturgem¨ aß vom Ursprung her besser beschreiben. Pragmatischer Ansatz: Diese Arbeit versucht sehr sachbezogen an die diskutierten Themen heranzugehen und pers¨ onlich gemachte Erfahrungen aus der praktischen Umsetzung einzubringen. Die zahlreichen Listings mit Programmbeispielen sollen dabei den praxisbezogenen Zugang zur Thematik verst¨ arken. Im Falle der theoretischen Untersuchung werden, wo es m¨oglich war, die Dokument-Adressen zitierter Autoren und Verweise auf allgemeine Informationsquellen angegeben. Die Leser der PDF1 -Version dieser Arbeit kommen in den zus¨ atzlichen 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 grunds¨ atzliches Verst¨ andnis der Programmentwicklung und Kenntnisse in zahlreichen Programmiersprachen voraus. Zu den Sprachen z¨ahlen etwa Java, Perl, JavaScript und HTML.

1.2

Kapitel¨ ubersicht

• Kapitel 2, Web-Applikationen: Ausgehend von den generellen Anforderungen an Web-Applikationen werden die Vor- und Nachteile dieser speziellen Applikationsform erl¨ autert. 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 unterst¨ utzte 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.2 KAPITELUBERSICHT

1 EINLEITUNG

den allgemeinen Funktionsumfang des Hyperwave Information Servers und seine schon beinahe historische Entstehungsgeschichte. In der Folge werden die vorhandenen Programmierschnittstellen des Servers detailliert erkl¨ art und nach f¨ ur 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 Uberblick 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 f¨ ur 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 f¨ ur die Entwicklung von Web-Applikationen relevante Schlußfolgerungen zu ziehen. M¨ ogliche zuk¨ unftige 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 h¨ aufig in den White Papers unterschiedlicher Hersteller auf. Dieser Anhang listet die in der Untersuchungsphase gefundenen Attribute f¨ ur WebApplikationen gesammelt auf. ¨ • Anhang B, e-Manie: Ahnlich 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 B¨ uhne des World Wide Web und der Terminus Web-Applikation war geboren. So oder ¨ahnlich dramaturgisch k¨ onnte man es sehen. Faktum ist, dass Web-Applikationen beinahe in alle Bereiche herk¨ ommlicher Software vorgedrungen sind und immer h¨ aufiger in Unternehmen Schl¨ usselpositionen einnehmen – man denke nur an den derzeit herrschenden Hype um E-Business und E-Commerce. Dem zum Trotz k¨ onnen 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 kl¨ aren. 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 Leistungsf¨ ahigkeit hinsichtlich einer Datenbank-Anbindung gepr¨ uft.

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 Ph¨ anomen der InternetGesellschaft, in der man nichts lieber tut, als sich mit Abk¨ urzungen zu verst¨ andigen, die

15

2 WEB-APPLIKATIONEN

2.1 GRUNDLAGEN

man dabei selbst tagt¨ aglich neu erfindet. H¨atten wir nun ein Dutzend Web-Experten zur Verf¨ ugung, k¨ onnten 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 W¨ orterb¨ uchern [Networds, 2000; W˘ebop¯edia, 2000] f¨ ur Internet-Begriffe fehlt jeweils ein Eintrag f¨ ur Web-Applikation“. ” Ein Leiden, das allen Newcomer-Begriffen“ des Internets gemein ist. ” ¨ Der einfachere und einzig zielf¨ uhrende Weg ist die w¨ortliche Ubersetzung 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 v¨ ollig belanglos. Dennoch wollen wir um das allgemeine Verst¨ andnis zu erh¨ ohen, den Versuch unternehmen, Web-Applikationen anhand von typischen Merkmalen n¨ aher 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 Erw¨ ahnung finden. Abschließend werden in Abschnitt 2.1.4 die derzeit wichtigsten Anwendungsbeispiele f¨ ur Web-Applikationen angef¨ uhrt.

2.1.1

Anforderungen

Welche Eigenschaften machen eine herk¨ ommliche Applikation zur Web-Applikation? Die ¨ Beantwortung dieser Frage erweist sich nach genauerer Uberlegung als nicht ganz trivial, da einige Eigenschaften auch einer gew¨ohnlichen Applikation zugesprochen werden k¨ onnen. 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 Funktionalit¨ at. Die dabei gefundenen Anforderungen bilden die Basis jeder WebApplikation und sind demnach implizit typische Eigenschaften daf¨ ur. Anforderungen (Requirements) an Software – eine Web-Applikation ist zweifellos ein St¨ uck Software – werden immer in zwingende und optionale Anforderungen gegliedert. Zwingende Anfor1

Im Englischen ist Web Application eine Kurzform f¨ ur Web-based Application, beides meint dasselbe.

16

2 WEB-APPLIKATIONEN

2.1 GRUNDLAGEN

derungen m¨ ussen in jedem Fall von einer Applikation erf¨ ullt werden, um als Web-Applikation zu gelten. Die aufgelisteten optionalen Anforderungen werden in Summe von den meisten Web-Applikationen zus¨ atzlich erf¨ ullt, sind aber nicht verbindlich. Zwingende Anforderungen: • Das Web, Kurzform von World Wide Web 2 dient als prim¨ are 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. • Abh¨ angig 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 ¨berpr¨ uft die Eingaben des Users auf Korrektheit und verarbeitet sie. Zum Beispiel k¨ onnen Daten in einer Datenbank gespeichert werden. • Die eigentliche Web-Applikation nutzt die Programmierm¨ oglichkeiten 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 ausgef¨ uhrt 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. • F¨ ur die Web-Seiten Erstellung werden Templates verwendet, dessen Platzhalter individuell gef¨ ullt werden. • Web-Applikationen arbeiten h¨ aufig mit Mail-Systemen zusammen. • Die Web-Applikation f¨ ugt sich in vorhandene Infrastruktur6 ein. • Web-Applikationen k¨ onnen Workflows anstossen. Die Liste der optionalen Anforderungen kann fast beliebig erweitert werden, sieht man etwa nur auf die Vielzahl vorhandener offener und propriet¨ arer Web-Technologien (Abschnitt 2.3 behandelt einige ausgew¨ ahlte Beispiele). Auch der Katalog der zwingenden Anforderungen kann nicht als vollst¨ andig 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 gegen¨ uber herk¨ ommlichen 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-unabh¨angig. Das Vorhandensein eines WebBrowsers ist die einzige Voraussetzung auf der Client-Seite. 2. Die Web-Applikation l¨ auft zentral auf einem oder mehreren Servern. Upgrades finden rein hier statt, der Client bleibt dabei unbetroffen. Es entf¨ allt das m¨ uhselige Upgrade oft unz¨ ahliger Clients. 3. Die Web-Applikation u ¨bernimmt die ganze Applikations-Logik. Der Client k¨ ummert 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 (Verschl¨ usselung der Daten-Pakete) kann die Web-Applikation weltweit eingesetzt werden. 5. Die vertraute Web-Browser-Oberfl¨ ache erleichtert dem Anwender das Erlernen der Benutzerf¨ uhrung. 6. Die f¨ ur Web-Applikationen ben¨ otigten Server-Produkte werden zunehmend leistungsf¨ ahiger und ausgereifter. 7. Web-Applikationen verwenden oft globale und weitverbreitete Internet-Standards, die den meisten Entwicklern bereits vertraut sind. Damit verk¨ urzt sich in vielen F¨ allen 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 ben¨ otigt werden, kann das zu vehementen Verz¨ ogerungen f¨ uhren. Bei 10 Sekunden liegt die Obergrenze, um die Aufmerksamkeit des Users nicht zu verlieren [Nielsen, 2000a]. Die Architektur der Web-Applikation ist dabei h¨ aufig 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 ” f¨ ur Web-Applikationen geeignet. 3. Die im Internet verwendeten Standards sind teilweise noch extrem kurzlebig. Es ist eine sprichw¨ortliche Gradwanderung, einerseits web-technologisch am Laufenden ” zu bleiben“ und andererseits nicht Zeit und Geld mit unausgereiften Technologien zu vergeuden. 4. Bei nachl¨ assiger Programmierung k¨ onnen gravierende Sicherheitsl¨ ocher entstehen, die potentielle Ziele f¨ ur Angreifer sind.

19

2 WEB-APPLIKATIONEN

2.1.4

2.2 SERVER SOFTWARE

Anwendungsbereiche

Die unten angef¨ uhrte Liste gibt die derzeit bekanntesten Anwendungsbereiche von WebApplikationen wieder. Die dabei verwendeten Begriffe assoziieren h¨ aufig sehr große Systeme, die zum Teil mit herk¨ ommlichen 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 angef¨ uhrt: • 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 f¨ ur deren Realisierung eine entsprechende Plattform ben¨ otigt, die naturgem¨ aß von einem Server7 zur Verf¨ ugung 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 erh¨ altlicher Server-Software, verkompliziert die Auswahl eines f¨ ur die Web-Applikation am geeignetsten Servers noch zus¨ atzlich. Die prim¨ are Entscheidungsgrundlage bildet der Anforderungs-Katalog an die Web-Applikation. Dieser enth¨ alt indirekt sehr viele Punkte, die vorrangig die Funktionalit¨ at 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 k¨ onnen die folgenden Punkte ausgemacht werden: • Web-Basisfunktionalit¨ at

• Erweiterbarkeit/Skalierbarkeit

1. HTTP 1.0/1.19

• Performance (Throughput, Response Times)

2. Konfigurationsm¨ oglichkeit • Programmier-Schnittstellen,

• Sicherheit/Zuverl¨ assigkeit

siehe dazu die in Abschnitt 2.3 ange• Management Tools

gebenen Technologien. • Entwicklungsumgebung

• Dokumentation

• Modularit¨ at

• Kosten

Im Punkt Web-Basisfunktionalit¨ at 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 – ¨andern ” k¨ onnen [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 daf¨ ur bereitstellen. Zu den von der Software zu erf¨ ullenden technischen Anforderungen, kommen auch wirtschaftliche Belange, n¨ amlich 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 Funktionalit¨ at verbinden soll. Der Nachteil liegt dabei in der verschiedenen Interpretation, bzw. Definition dieser vergebenen Labels und f¨ uhrt manchmal zu echter Verwirrung. Die am h¨ aufigsten zu findenden Pr¨ adikate 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 Funktionalit¨ at im Einzelnen zu spezifizieren und dabei untereinander – sofern u ¨berhaupt m¨oglich – Grenzen zu ziehen. Unterscheidungskriterien sind prim¨ ar implementierte Technologien und Standards der jeweiligen Server-Segmente. Das Hauptaugenmerk liegt ¨ dabei im allgemeinen Uberblick der vorhandenen Produkte und im Speziellen in der Leistungsf¨ ahigkeit 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 Uberblick

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 f¨ ur die Statistiken von Netcraft herangezogen werden. Tabelle 2.1 zeigt die Top 5“ und zus¨ atzlich die Plazierung des ” Hyperwave Information Servers. Deutlich ist die Dominanz des Apache Web Servers, der mehr als die H¨alfte des Marktes beherrscht, gefolgt vom Microsoft Internet Information Server mit knapp einem Viertel Anteil und dem schon eher abgeschlagenen iPlanet Enterprise Server (fr¨ uher 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 gez¨ahlten 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 Dom¨ anen. Betrachtet in einem Zeitraum von August 1995 bis M¨ arz 2000. Quelle: [Netcraft, 2000].

Tabelle 2.1: Netcraft Server Statistik vom M¨ arz 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 Uberblick‘ ist mit einiger Vorsicht zu genießen. Die erfassten Server wie Apache, Apache-1.3.4, mod_perl, ApacheSSL geh¨ oren zur gleichen Familie, scheinen aber getrennt auf. Das Modul mod_perl des Apache ist ohnehin kein eigenst¨ an¨ diger Web Server, es kann nur bei der Ubersetzung der Apache-Distribution als Modul ¨ installiert, oder als DSO11 dynamisch gelinkt werden. Uber die H¨alfte der erfassten Server – es sind u ¨ber 600 – hat weniger als 100 gez¨ahlte Web Sites vorzuweisen. Alle Server unter der Kategorie Web-Server zu sehen verzerrt die Ergebnisse zus¨ atzlich, 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 Marktverh¨ altnisse zu bekommen. F¨ ur die genauere Analyse oder gar als Entscheidungshilfe f¨ ur 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 Funktionalit¨ at 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 k¨ onnen die Leistungsf¨ ahigkeit des Web-Servers steigern. Zu diesen Technologien z¨ahlen CGI, Server-Side Includes oder propriet¨ are 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 [W˘ebop¯edia, 2000]. Sieht man von den angef¨ uhrten server-seitigen Technologien v¨ ollig ab, w¨ urde das der Anforderung Web-Basisfunktionalit¨ at“ – siehe Abschnitt 2.2 auf Seite 20 – eines Web” Servers entsprechen. Ein derartig spartanischer Server w¨are als Plattform f¨ ur WebApplikationen nat¨ urlich ungeeignet. In der Praxis bieten aber alle Web-Server sogar mehrere M¨ oglichkeiten, Web-Applikationen zu realisieren, indem sie verschiedene WebTechnologien und Standards, wie CGI oder ASP, implementieren. Das online Informations-Service internet.com [Icom, 2000] f¨ uhrt in einer sogenannten ServerWatch“ Listen von verschiedenen Server-Typen. Von Web-Server bis ” Proxy-Server k¨ onnen hier Rubriken gefunden werden. Nach Auskunft der ServerWatch“ ” werden alle Server-Rubriken manuell verwaltet und die Aufnahme eines neuen ServerProduktes erfolgt nach eigenem aber unabh¨ angigem Ermessen. Die Liste der verzeichneten Web-Server der ServerWatch“ beschr¨ ankt sich auf 32 ” Eintr¨ age, 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 zus¨ atzlichen Anmerkungen alphabetisch aufgelistet. Diese 32 sind zur Zeit die sicher wichtigsten und meist eingesetzten Server am Markt. Bei der n¨ aheren Untersuchung der Server bez¨ uglich der gebotenen Leistung, Funktionalit¨ at und zus¨ atzlicher 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 f¨ ur weitere Informatio” nen). Bei einigen ist es eine grunds¨ atzliche Anforderung ans eigene Produkt (siehe Apache, Jigsaw), bei anderen eher ein ,K¨ oder‘, um andere meistens sehr ben¨ otigte Tools, wie Such-M¨ oglichkeit oder Administrations-Werkzeuge, f¨ ur 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 f¨ ur 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-Gr¨ oße. Im Allgemeinen sind die f¨ ur 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 Gr¨ oß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, unterst¨ utztem ” Betriebssystem, Download Gr¨ oße, Preis, SSL, Java Servlets und zus¨ atzlichen Anmerkungen zum Entwicklungsstatus.

✝ ✔ ✔

✿ ✝

✔ ✔

✿

✔ ✔ ✔ ✝ ✔ ✔

✔

✔ ✔

➳

✔

✔

➳

✔

✿

✔ ✔ ✔

✔

✔

✔ ✔ ✔

2 WEB-APPLIKATIONEN

2.2 SERVER SOFTWARE

Platz sparender als die f¨ ur Windows, da diese nicht bereits vorhandene StandardDienste wie ftp oder sendmail implementieren m¨ ussen. Viele Windows-Server sind mit diesen zus¨ atzlichen Diensten ausgestattet. 3. SSL14 Wird bereits von der Mehrzahl – in Tabelle 2.2 sind es die H¨alfte – der Server standardm¨ aß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 f¨ ur Web-Server, dennoch bieten immer mehr Hersteller Versionen auch f¨ ur Windows 9x, aber zumindest Windows NT an. 5. Java Servlets In Tabelle 2.2 sind es 11 von 32 Servern die Java Servlets unterst¨ utzen. Java Servlets sind eine immer popul¨ arer 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 verf¨ ugbar zu sein. Zudem brauchen sie keine zus¨ atzliche Servlet-Engine, um Java Servlets ausf¨ uhren zu k¨ onnen, sie verwenden dazu die vorhandene Virtual Machine. 7. Apache basierend RapidSite und Stronghold erweitern die Grundfunktionalit¨ at des Apache WebServer mit zus¨ atzlichen Features und bieten damit ein f¨ ur bestimmte Zwecke vorgefertigtes Server-Paket kommerziel an. Stronghold ist die Nummer eins im Bereich der kommerziellen SSL-Server f¨ ur Unix-Platformen. Abschließend l¨ aßt sich feststellen, dass alle Web-Server der ServerWatch“ die an ” die Server-Software gestellten Anforderungen – zwar in unterschiedlicher Weise, aber doch – erf¨ ullen. 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 st¨ andigen Inkorporation neuer Technologien, einfach u ¨berladen“ sind und dadurch ” schwerf¨ allig werden im Handling und der Wartung. Die Geschwindigkeit, in der neue Standards von Herstellern implementiert werden, bestimmt aber nachhaltig die Konkurrenzf¨ ahhigkeit ihres Produkts. Das geht jedoch – wie gesehen – vermehrt auf Kosten des Kunden und der Qualit¨ at. Eine Vielfalt von implementierten Web-Technologien erlaubt nat¨ urlich die Selektion der f¨ ur die Anforderungen der Applikation am geeignetsten. Diese Auswahl-M¨ oglichkeit sollte aber keinesfalls auf Kosten der Performance gehen, u ¨berhaupt wenn sich die sogennanten Usage Patterns u ¨ber Nacht schlagartig ¨andern k¨ onnen17 .

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, Gesch¨ afts-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 nat¨ urlich nur ansatzweise stimmt. Der Markt w¨achst trotzdem rapide und bereits alle gr¨ oßeren Software-Produzenten k¨ onnen 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, f¨ ur 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 zus¨ atzlicher Funktionalit¨ at 2. Datenbank-Server mit zus¨ atzlicher Web-Funktionalit¨ at 3. V¨ollig neues Produkt Weitere Ursachen f¨ ur 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 ) l¨ auft, zwischen Web-Browser basierenden Thin Clients 19 und ,back-end‘ Datenbanken oder anderen Applikationen. Der Application Server behandelt die gesamte Applikations-Logik, die f¨ ur das Verhalten eines bestimmten Systems zust¨ andig ist. Er stellt Java- oder Browser-basierende Anwendungen dem Benutzer zur Verf¨ ugung, deren Implementierung u ¨ber eine integrierte Web-Entwicklungs-Umgebung erleichtert wird. Zus¨ atzlich kann ein Application Server in großen Systemen als Traffic Cop fungieren und die auftretende Last entsprechend verteilen. Quelle: [W˘ebop¯edia, 2000; Ricciuti, 1998]. Mit dem Einf¨ ugen 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 [W˘ebop¯edia, 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 beg¨ unstigt auch die Aufspaltung der Applikation in 3 Teile, n¨ amlich in: 1. Presentation Logic (Pr¨ asentations-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 zus¨ atzlich in der Tabelle erg¨ anzt. Aus dem Studium einiger White Papers und der Leistungsprofile der aufgelisteten Application Server k¨ onnen folgende Punkte festgehalten werden: 1. Gr¨ oß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 Gr¨ oße korreliert dabei zunehmend mit der Komplexit¨ at der Software. 2. Plattformen Alle Server sind f¨ ur Windows NT und Solaris erh¨ altlich. Versionen f¨ ur HP-UX, AIX, MAC OS, Irix und Linux sind je nach Hersteller verf¨ ugbar. 3. Web-Server Apache, MS Internet Information Server und Netscape sind die g¨angisten unterst¨ utzten 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 f¨ ur 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, unterst¨ utz” tem Betriebssystem, Preis und zus¨ atzlichen Anmerkungen.

✿

✿ ✿

✌ .. Freeware ✿ .. In Java implementiert

4. Summe von Komponenten Das Produkt Application Server besteht in fast allen F¨ allen aus einem B¨ undel verschiedener Server und Tools, typischerweise aus Application Builder, Application Server und Application Administration Tool. Das Admin-Tool ist zumeist via WebBrowser zug¨ anglich. 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]. S¨ amtliche Server unterst¨ utzen Java, fast alle C/C++. Perl und Cobol sind nur ganz vereinzelt vertreten. 7. DB Unterst¨ utzung 21

Integrated Development Environment

31

2 WEB-APPLIKATIONEN

2.2 SERVER SOFTWARE

Der Zugriff auf Datenbanken kann prim¨ ar u ¨ber ODBC22 oder JDBC23 erfolgen. Informix, Oracle, DB2, SQL Server werden weniger aber dann direkt unterst¨ utzt. 8. CORBA24 Die Mehrzahl der Server – 10 von 16 – erlaubt die Erzeugung von CORBA Objekten und verf¨ ugt meistens u ¨ber eigene Object Request Broker (ORB), die sich untereinander u ¨ber Internet Inter-ORB Protocol (IIOP) verst¨ andigen. 9. COM/DCOM25 F¨ ur verteilte Objekte auf Windows Ebene unterst¨ utzen 7 der 16 Server DCOM von Microsoft. DCOM konkurriert mit CORBA, bei ungef¨ ahr gleicher Funktionalit¨ at.

10. EJB Enterprise JavaBeans wurden im Vergleich zu CORBA sehr schnell von den Herstellern als Standard akzeptiert. Ungef¨ ahr die H¨alfte der Server unterst¨ utzt 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 f¨ ur Failover-Mechanismen ist die M¨ oglichkeit 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 abh¨ angig sein kann. Dem stehen nur Galileo und Zope als freie Server gegen¨ uber, die aber auch mit weniger Funktionalit¨ at 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 f¨ ur verteilte Objekte. 23

32

2 WEB-APPLIKATIONEN

2.2 SERVER SOFTWARE

Aus dieser F¨ ulle aufgez¨ ahlter Punkte k¨ onnte man glauben, in einem Application Serverwirklich das lang gesuchte Silver Bullet f¨ ur den Werewolf Web-Applikation gefunden zu haben, leiht man sich die ber¨ uhmte Metapher von Frederick Brooks [Brooks, 1986]. Dem ist leider nicht so. Nat¨ urlich versucht man mittels visueller Tools die Entwicklung so leicht wie m¨oglich zu gestalten, aber den Aufwand eines durchdachten ApplikationsDesigns und den gewissen – meist gr¨ oßeren – Teil dazu notwendiger Low-Level Programmierung, k¨ onnen 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 erf¨ ullen? 2. Welcher Server kann die Erf¨ ullung dieser Anforderungen am ehesten unterst¨ utzen? 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 f¨ ur die Web-Applikation zu w¨ahlen.

2.2.4

Information Server

Als letztes in Abschnitt 2.2 erw¨ ahntes 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 eigenst¨ andige 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 entf¨ allt ein eigenes Segment f¨ ur 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 f¨ ur Anforderungen an den Server.

33

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

Wie aus Tabelle 2.2 ersichtlich z¨ahlt 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 Funktionalit¨ at 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 nat¨ urlich Informationsmanagement. Gerade große Datenbest¨ ande, wie in Intranet-Umgebungen oft vorzufinden, ben¨ otigen diese im Server integrierten Tools zur effizienten Verwaltung, Wartung und Suche. Demnach sollte Microsoft seinen Server gem¨aß seines Leistungsgrades wirklich nur als Internet Server“ bezeichnen. ”

2.3

Web-Technologien

Web-Applikationen leben von der M¨ oglichkeit, in irgendeiner Weise dynamisch – im Englischen auch ,on the fly‘ – Web-Seiten zu generieren. Sie nehmen in den meisten F¨ allen session-abh¨ angig Informationen aus einer Datenbank und verpacken diese in sch¨ on 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 f¨ ur die Server-Seite bestimmmt, Technologien der Client-Seite, wie DHTML27 , XML oder CSJS28 k¨ onnen nat¨ urlich in den erzeugten Web-Seiten Anwendung finden. Die Unterscheidung in verschiedene Kategorien unter den in den n¨ achsten Abschnitten betrachteten Web-Technologien f¨ allt ungleich schwerer wie diese zwischen den verschiedenen Server-Typen. Ein m¨ogliches Kriterium w¨are aber die Leistungsf¨ ahigkeit oder der Einsatzbereich der Technolgie: PHP29 und Java Servlets erlauben den Zugriff auf verschiedene Datenbanken und sind auch sonst mit sehr m¨achtigen 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

2.3 WEB-TECHNOLOGIEN

m¨oglich. In der Praxis stellt oft der Server selbst diese Technologien zur Verf¨ ugung, wie das parsen eines HTML-Dokuments nach SSI oder PHP Anweisungen, die entsprechend interpretiert werden m¨ ussen. Sonst ist dazu aber ein zus¨ atzlicher Server oder ein zus¨ atzliches Modul notwenig, wie etwa beim Servlets-Konzept des Apache. Zu den Standards und De-facto-Standards gesellen sich schließlich noch eine Unmenge von propriet¨ aren 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 erkl¨ aren anhand von Beispielen deren Funktionalit¨ at. 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 m¨oglich (SSI) oder gestaltet sich jeweils als mehr oder weniger schwieriges Unterfangen.

2.3.1

SSI

Server Side Includes (SSI) bieten die wohl einfachste M¨ oglichkeit, 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 k¨ onnen, da die meisten Server sie in der gleichen Syntax implementieren. SSI-Unterst¨ utzung alleine reicht noch nicht, der Server selbst muss passend konfiguriert werden, um schließlich SSI-Anweisungen interpretieren zu k¨ onnen. 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.: ... . http://www.mysql.com

35

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

Die SSI-Anweisungen werden in der Form von HTML Kommentaren in das Dokument eingebunden: Ein Leerzeichen vor dem abschließenden -->“ ist in der Regel f¨ ur die richtige Ausf¨ uhrung ” notwendig. Folgende Anwendungsbereiche bieten sich f¨ ur SSI an: • Einbinden von Dateien, zum Beispiel Header und Footer. ¨ • Ausgabe der Gr¨ oße oder des Datums der letzten Anderung eines Dokuments. • Ausf¨ uhren von CGI-Skripts oder Shell-Kommandos33 . • Ausgabe von Umgebungsvariablen des Servers. Eine bescheidene Liste, aber f¨ ur das Einbinden kleiner ,Gimmicks‘ in Web-Seiten, wie einen CGI-Counter, vollkommen ausreichend. Tabelle 2.4 listet einige interessante SSIBeispiele mit Beschreibung auf. Zus¨ atzlich existieren noch Anweisungen f¨ ur eine rudiTabelle 2.4: Einige SSI-Beispiele mit Beschreibung

Einbinden einer Datei aus dem Verzeichnis /include. " Ausf¨ uhren eines CGI-Skripts. Ausf¨ uhren eines Shell-Kommandos. ¨ Datums der letzten Anderung der Datei meisl.html. Gr¨ oße der Datei meisl.html. ment¨ are Flußkontrolle, eine IF-Anweisung innerhalb eines SSI-Files kann zum Beispiel so aussehen: Hallo lisa.tu-graz.ac.at! 33

Bei der Ausf¨ uhrung von CGI’s und Shell-Kommandos ist Vorsicht geboten, unsicher implementierte Skripte k¨ onnen großen Schaden anrichten.

36

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

Sollte die Anfrage vom Host lisa.tu-graz.ac.at“ kommen, wird der Block bis zum ” “ ins HTML-Dokument u ¨bernommen. F¨ ur eine komplette Liste der ” verf¨ ugbaren Anweisungen siehe [Eilebrecht, 1999, Kap. 8] oder [Laurie & Laurie, 1999]. SSI sind f¨ ur kleinere Aufgaben, wie Einbinden von oft verwendeten HTML-St¨ ucken oder Aufrufen von kleinen CGI-Skripts sehr geeignet. Aufgrund des kleinen Vorrats an Anweisungen ist diese Technik auch ¨außerst schnell erlernbar. SSI k¨ onnen aber bestenfalls als primitive Unterst¨ utzung 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 bew¨ahrteste Methode, dynamisch Web-Seiten zu erzeugen, stellt das Common Gateway Interface – kurz CGI – zur Verf¨ ugung. Wie bereits dem Namen zu entnehmen, handelt es sich dabei lediglich um eine Schnittstelle, die die Ausf¨ uhrung von Programmen am Server erlaubt. Die Programme k¨ onnen dabei in jeder beliebigen Programmieroder Skriptsprache ausgef¨ uhrt werden. Die bekanntesten Sprachen sind: Unix Shell, Python, Tcl, Perl, C, C++, Java, Fortran, Visual Basic. Da haupts¨ achlich Skriptoder Interpretersprachen wegen ihrer h¨ oheren Flexibilit¨ at und leichteren Erlernbarkeit eingesetzt werden, hat sich auch die Bezeichnung CGI-Skript“ eingeb¨ urgert. 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 k¨ onnen 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 m¨oglich, beim Aufruf des Skripts u ¨ber eine URL kommt GET zum Einsatz: 34

Siehe RFC 2616 [Fielding et al., 1999, Sec. 9] f¨ ur eine genaue Beschreibung aller HTTP-Methoden.

37

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

GET /cgi-bin/my.pl HTTP/1.0

Abbildung 2.3: Kommunikationsabl¨ aufe 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, erh¨ alt 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 "Hello World CGI\n"; print "\n"; print "Hello World CGI\n"; $time = localtime; print "The date is:$time\n"; print "\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 f¨ ur 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.3 WEB-TECHNOLOGIEN

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 daf¨ ur ein Database ” Interface (DBI) Modul zur Verf¨ ugung, das unter Verwendung spezieller Treiber (Database Driver, DBD), mit verschiedenen Datenbanken zusammenarbeiten kann. Diese speziellen Treiber f¨ uhren 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: Repr¨ asentiert 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

2.3 WEB-TECHNOLOGIEN

3. Statement Handle: Kapselt ein einzelnes SQL-Statement, das innerhalb der DB exekutiert wird. Die Instanziierung erfolgt u ¨ber: $sth = $dbh->prepare(’’); Wie die drei Handles zusammenh¨ angen 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 zugeh¨ origen 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 erw¨ ahnten 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 f¨ ullt 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

2.3 WEB-TECHNOLOGIEN

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 "\n"; while ( my @ergebnis = $sth->fetchrow_array ){ print "".$ergebnis[0].""; print $ergebnis[1]."\n"; } print "\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 Ausf¨ uhrung 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 Eintr¨ age 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 G¨ astebuch bis zum ausgefeilten Warenkorb-System reichen die CGI-Web-Applikationen, die sich im tagt¨ aglichen Einsatz bew¨ahren. Perl hat sich dabei als zuverl¨ assiger Partner“ erwiesen ” und stellt hilfreiche Bibliotheken (Module), wie CGI, DBI, LWP36 dem Programmierer zur Verf¨ ugung. Vorsicht sollte aber stets bei der Programmierung gegeben sein, denn Sicherheitsl¨ ocher 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

2.3 WEB-TECHNOLOGIEN

zess abgespaltet wird. Dies kann zu vehementen Leistungseinbußen f¨ uhren 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 Popularit¨ at von CGI noch ungebrochen und die Bestrebungen nach einer verbesserten CGI-Spezifikation (CGI/1.2) sind auch Beweis daf¨ ur, dass CGI noch immer konkurrenzf¨ ahig ist und bleiben m¨ochte. Diese Situation beschreibt Lincoln Stein [Stein, 1999] sehr pr¨ agnant und treffend so: CGI is dead. Long live CGI!“ ” Weitere Informationen: 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 Schw¨achen von CGI ausmerzen und andererseits dessen St¨ arken u ¨bernehmen m¨ochte, ist das von Open Market 39 im Jahre 1996 entwickelte FastCGI Web-Server-Interface. Die Hauptschw¨achen 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 w¨ urde zum Beispiel auch das Cachen“ von Daten erlauben. ” • Nicht skalierbar. Das Auslagern einer resource-intensiven Applikation auf einen anderen Server – Load Distribution – ist nicht m¨oglich. Dem gegen¨ uber 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

2.3 WEB-TECHNOLOGIEN

• Eine sprach- und server-unabh¨ angige, 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 ¨ahnlich 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. Zus¨ atzlich erlaubt FastCGI single-threaded oder multi-threaded Applikationen. Multi-threaded Applikationen k¨ onnen gleichzeitig mehrere Verbindungen vom Web-Server annehmen und diese innerhalb eines einzelnen Prozesses verarbeiten. Thread-Sicherheit ist f¨ ur derartige Applikationen prim¨ are Voraussetzung. Die eingschr¨ ankte Funktionalit¨ at von CGI, n¨ amlich nur auf einfache Anfragen reagieren zu k¨ onnen, erweitert FastCGI mit der Einf¨ uhrung sogenannter Rollen (roles). Eine Applikation kann nun eine von drei verschiedenen Rollen u ¨bernehmen:

43

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

1. Responder. Entspricht der einfachen Funktionalit¨ at, 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. Uberpr¨ uft vor Ausf¨ uhrung der Anfrage, ob eine entsprechende Berechtigung dazu vorhanden ist, zum Beispiel u ¨ber eine Password-Authentifizierung. Open Market stellt f¨ ur die rasche Entwicklung von FastCGI-Applikationen sogenannte Application Libraries f¨ ur die Sprachen C/C++, Java, Perl, Python und Tcl zur Verf¨ ugung. Wie aus Listing 2.3 ersichtlich gibt es zum Beispiel f¨ ur Perl ein eigenes Modul FCGI, dass Methoden f¨ ur 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", " Hello World with FastCGI \n", "Request ", ++$count, " from Server ", $ENV{’SERVER_NAME’}); }

In dem einfachen Fall von Listing 2.3 wird bei jeder Anfrage ein Z¨ahler 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 m¨ ussen einfach in die in Listing 2.3 gezeigte While-Schleife gepackt werden, um als FastCGI ebenso ihren Dienst zu verrichten. Derzeit unterst¨ utzen zahlreiche Server FastCGI als server-seitige Technologie. Dazu z¨ahlen Apache (mod_fastcgi), Microsoft Server, Netscape Server und Zeus. Weitere Informationen: http://www.fastcgi.com

44

2 WEB-APPLIKATIONEN

2.3.4

2.3 WEB-TECHNOLOGIEN

PHP

PHP steht offiziell f¨ ur 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

Hello World with PHP3 Hello World with PHP3 !! //

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 Anf¨ anger ein rasches Einarbeiten in die Sprache. Alle Anweisungen zwischen “ Tags ” ” werden vom Server als PHP interpretiert. PHP kann prinzipiell alles was mit CGI m¨oglich ist, versteht mit regul¨ aren Ausdr¨ ucken umzugehen, unterst¨ utzt Objekte und spricht zahlreiche Protokolle wie IMAP40 , SNMP41 , NNTP42 , POP343 oder auch HTTP, was die Kommunikation mit anderen Diensten erleichtert. Die wesentliche St¨ arke von PHP liegt aber in der Unterst¨ utzung einer breiten Masse von Datenbanken. Zur Veranschaulichung sollen hier nur einige aufgez¨ ahlt 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

2.3 WEB-TECHNOLOGIEN

• 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

telefon.php3 Telefonnumern aus einer DB: NameTelefon

Im gegebenen Fall wurde ein Apache Web-Server unter Linux mit PHP3 Unterst¨ utzung verwendet, man spricht dann abgek¨ urzt 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 f¨ ur die DatenbankManipulation: • mysql_connect verbindet zum MySQL-Server mittels Benutzername und Passwort.

46

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

• mysql_select_db w¨ahlt die zu benutzende Datenbank aus. Das gelingt nur, wenn die entsprechenden Rechte am MySQL-Server f¨ ur 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 Eintr¨ age dieses Arrays werden dann in eine HTML-Tabelle verpackt. Mit diesem R¨ ustzeug er¨ offnet sich eine sehr komfortable M¨ oglichkeit f¨ ur Web-Applikation. Durch die rasche Weiterentwicklung von PHP wachsen auch die Marktanteile gegen¨ uber ASP und CF44 , die mit PHP schon jetzt einen ernstzunehmenden Gegner haben. Jim White bezeichnet in [White, 1999] nicht umsonst PHP als Silent Killer“. ” Weitere Informationen: 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-¨ ubergreifende und Objektorientierte Skriptsprache [ssjsGuide, 1999]. Damit ist nach dem ersten Satz bereits offensichtlich, dass es sich dabei um eine propriet¨ are Skript-Sprache handelt, die sp¨ ater aus marktwirtschaftlichen ¨ Uberlegungen zum offenen Standard wurde. Mit dem Namen JavaScript“ – urspr¨ unglich ” LiveScript – wollte man auf die syntaktische Verwandtschaft mit Java hinweisen, aber prim¨ ar vom damals einsetzenden Java-Hype“ profitieren. ” Wird allgemein von JavaScript“ gesprochen, ist in den meisten F¨ allen die Version ” der Client-Seite gemeint. Zus¨ atzlich hat Netscape auch eine Version f¨ ur die Server-Seite 44

Cold Fusion, ein kommerzielles Entwicklungs-Tool f¨ ur Web-Applikationen.

47

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

entwickelt, die f¨ ur 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 Funktionalit¨ at von Core JavaScript – sprich zus¨ atzlichen 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 ¨ahnlich 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 erkl¨ art. Da ein Web-Server mit SSJS Unterst¨ utzung als Client einer Datenbank agieren kann,

48

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

dr¨ angte 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. F¨ ur 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

Hello World with Server-Side JavaScript Hello World Your IP address is write(request.ip); writeln("Last time you were "+client.oldname+"."); writeln("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); You have been here write(client.number); times.

Das erste auffallende Merkmal ist die Mischung aus HTML und JavaScript-Anweisungen innerhalb des Files. Beide JS-Bl¨ ocke – 1. Block: Zeile 6–15 und 2. Block: Zeile 20 – werden durch ein “-Tag eigeleitet und durch “ abgeschlossen. Die erste ” ” 45

CSJS-Anweisungen stehen innerhalb des HTML-Codes zwischen und Tags

49

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

Aufgabe von hello.html“ ist die Ausgabe der IP-Adresse des Clients. Dazu stellt die ” JavaScript Runtime Engine das Objekt request zur Verf¨ ugung, 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 gez¨ahlt. In Zeile 11-14 wird dem client Objekt, das Session-Informationen eines bestimmten Clients speichert, die Property number“ beim ersten Aufruf hinzugef¨ ugt, 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 n¨ achsten 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 bin¨ are ” 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 – ben¨ otigt eine Web-Applikation in zweiter Linie Zugriffsm¨ oglichkeiten auf verschiedene Datenbanksysteme. Netscape stellt f¨ ur diese Anforderung das LiveWire Database Service zur Verf¨ ugung, das Objekte f¨ ur die Datenbank-Manipulation enth¨ alt. Mit folgenden Datenbanksystemen k¨ onnen Transaktionen stattfinden: • Informix

• DB2

• Oracle

• DB-Server, die den ODBC-Standard

• Sybase

verwenden.

Da LiveWire“ eine sehr propriet¨ are L¨osung f¨ ur diese Aufgabe ist, sollen hier nur im ” 46

JavaScript Application Compiler

50

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

¨ Uberblick die Objekte und deren Funktionalit¨ at beschrieben werden. Um mit einer DB Verbindung aufzunehmen, gibt es zwei M¨ oglichkeiten: 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 k¨ onnen danach wie folgt ausgelesen werden: conn = pool.connection("A Test Connection"); conn.SQLTable("select * from personen"); conn.release(); ¨ Uber 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 f¨ ur die Ausgabe. Das abschließende conn.release() entl¨ aß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 ben¨ otigen. Ein wirklicher Br¨ uckenschlag zu Java gelingt Netscape mit dem Konzept von LiveConnect. Damit k¨ onnen JavaScript-Objekte direkt auf Java-Klassen oder CORBAObjekte zugreifen. Server-Side JavaScript bietet zusammen mit den Erweiterungen LiveWire und LiveConnect einen vollst¨ andigen Baukasten“ f¨ ur 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 Verf¨ ugung. Weitere Informationen: http://developer.netscape.com/docs

51

2 WEB-APPLIKATIONEN

2.3.6

2.3 WEB-TECHNOLOGIEN

Java Servlets

Java Servlets bieten eine sehr m¨achtige M¨ oglichkeit, Web-Applikationen zu bauen, die leicht auf bereits vorhandene Systeme (z.B.: Datenbanken) zugreifen k¨ onnen. 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 47 Kontainer (Servlet Engine ) gemanagt, dynamische Inhalte generiert. Servlets sind ,kleine‘ plattform-unabh¨ angige Java Klassen, die nachdem sie in neutralen Bytecode kompiliert wurden, von einem Web-Server dynamisch geladen und zum Laufen gebracht werden k¨ onnen. 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 l¨ auft und daher keine grafische Oberfl¨ ache besitzt. Folgende Vorteile bietet der Einsatz von Java Servlets: 1. Plattform-Unabh¨ angigkeit 2. Zugang zu allen Java API’s 3. Schneller als CGI Scripts49 4. Session-Management Zur Ausf¨ uhrung 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 w¨ahrend 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 ausf¨ uhrt. Eine kleine in Java [Campione & Wallrath, 1999] geschriebene Applikation. 49 Gew¨ ohnliche CGI’s spalten beim Request jeweils einen neuen Prozess ab, Servlets hingegen sind nur einfache Threads. 48

52

2 WEB-APPLIKATIONEN

2.3 WEB-TECHNOLOGIEN

Abbildung 2.8: Die verschiedenen Stufen bei der Ausf¨ uhrung eines Servlets innerhalb der Servlet Engine. Quelle: [Mazzocchi & Fumagalli, 1998].

Java Applikation verglichen werden. F¨ ur das abschließende Aufr¨ aumen der besetzten Resourcen wird die destroy() Methode verwendet. Bei der Programmierung eines Servlets m¨ ussen diese Methoden entsprechend angepaßt werden, weiters muss das Servlet direkt oder indirekt das javax.servlet.Servlet ¨ Interface implementieren. Der einfachere Weg ist das Uberschreiben 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 " + remoteAddress + "");

15 16 17

2.3 WEB-TECHNOLOGIEN

} }

Vorausgesetzt der Server unterst¨ utzt Java Servlets, kann nun das Servlet via WebBrowser50 aufgerufen werden, dass im Gegenzug ein simples – in unserem Fall sogar unvollst¨ andiges – 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 ben¨ otigte Schnittstelle zu Datenbanken wird durch das JDBC52 API realisiert, dass f¨ ur alle bekannten Datenbanken Treiber zur Verf¨ ugung stellt. Ein Verbindungsaufbau mit einer MySQL Datenbank zeigt das folgende Java Code-St¨ uck 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 f¨ ur die Datenbank ben¨ otigt, 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 w¨ahrend der Lebenszeit des Servlets aufrecht. Das Auslesen aller Datens¨ atze 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 Ausf¨ uhren von SQL-Statements, stellt eine Reihe von Klassen und Interfaces zur Manipulation von Datenbanken zur Verf¨ ugung.

51

54

2 WEB-APPLIKATIONEN

3

2.3 WEB-TECHNOLOGIEN

ResultSet rs = stmt.getResultSet();

Mit der M¨ oglichkeit, SQL-Statements zu exekutieren (siehe Zeile 2), steht nun die gesamte Funktionalit¨ at der Datenbank zur Verf¨ ugung. Der Einsatz von RMI53 w¨ urde den Code des Servlets noch zus¨ atzlich vereinfachen und die Komplexit¨ at des Datenbank-Handlings auf eine zus¨ atzliche Schicht verlagern. Die Servlets-Technologie wird von einer immer gr¨ oßer werdenden Anzahl von Servern unterst¨ utzt und bietet eine gute Alternative zu CGI basierenden zeitkritischen Applikationen. Zus¨ atzliches Session-Management erlaubt nun endg¨ ultig die Interaktivit¨ at zu erh¨ ohen. Mit Java hat man zudem den Vorteil, auf einer großen Menge von Plattformen ohne Probleme lauff¨ ahige Applikationen erzeugen zu k¨ onnen und von der M¨ achtigkeit 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 verf¨ ugbar. Weitere Informationen: 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 M¨ oglichkeit, 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 m¨oglich sein, die Pr¨ asentations-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

2.3 WEB-TECHNOLOGIEN

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 s¨amtliche Java APIs zur Applikations-Entwicklung zur Verf¨ ugung. 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

Hello World with Java Server Pages (JSP) Hello World !! The current date is .

Ein JSP-Block startet in den meisten F¨ allen 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 erh¨ alt den speziellen Namen bean_test. Listing 2.9: Bean.jsp zeigt wie eine Bean-Komponente innerhalb einer JSP aufgerufen wird. 1 2 54 55

JSP and Java Beans

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

2.3 WEB-TECHNOLOGIEN

Use a Java Bean to connect to a MySql DB

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 Ausf¨ uhren einer Query am DB-Server sind ident mit den Beispielen des letzten Abschnittes, lediglich die Ausgabe hat sich dahingehend ge¨andert, 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 = ""; while (resultSet.next()) { html_string += ""+resultSet.getString(1)+""; html_string += ""+resultSet.getString(2)+"\n"; } html_string += "";

57

2 WEB-APPLIKATIONEN 23

} catch (Exception e) { System.out.println(e.toString()); } return html_string;

24 25 26 27 28 29

2.3 WEB-TECHNOLOGIEN

} }

Ausgehend von diesen und den bereits erw¨ ahnten 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 angef¨ uhrten Elemente verkn¨ upft.

• 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: