2 Grundlagen von Webanwendungen

Transkript

1 7 Verschiedene Technologien sind notwendig, damit leistungsfähige Webanwendungen entstehen können. In den letzten Jahren haben sich, teilweise unabhängig voneinander, in den einzelnen Bereichen ausgereifte Lösungen etabliert, von denen die wichtigsten in diesem Kapitel vorgestellt werden. Eine Einführung in das Hypertext Transfer Protocol (HTTP) und das Hypertext Transfer Protocol over SSL/TLS (HTTPS) macht den Anfang. Vermutlich löst heute ein durchschnittlicher Computeranwender mithilfe seines Webbrowsers etliche tausend HTTP-Requests pro Tag aus. Die Unterkapitel 2.1 (HTTP) und 2.2 (HTTPS) erläutern, was dabei im»hintergrund«passiert. HTTP wird überwiegend zur Übertragung von Dokumenten genutzt, die in einer Auszeichnungssprache wie der Hypertext Markup Language (HTML) oder der Extensible Markup Language (XML) formuliert sind. Daneben gibt es zahlreiche weitere Auszeichnungssprachen. Unterkapitel 2.3 gibt eine kurze Übersicht über die wichtigsten Vertreter. HTML-Dokumente können Applets enthalten Java-Programme, die clientseitig im Browser ablaufen. Unterkapitel 2.4 stellt die Applet-Technologie im Überblick dar und gibt Hinweise zur Programmierung eigener Applets. Die beiden nächsten Unterkapitel 2.5 und 2.6 beschreiben zwei serverseitige Java-Technologien zur dynamischen Generierung von Webinhalten: Servlets und JavaServer Pages (JSP). All diese Technologien fließen in die Java 2 Enterprise Edition (J2EE) ein, der ein weiteres Unterkapitel 2.7 gewidmet ist. Das Zusammenspiel der Bausteine zu definieren ist Gegenstand der Softwarearchitektur. Das abschließende Unterkapitel 2.8 geht auf verschiedene Architekturmodelle für Webapplikationen näher ein. Das vorliegende Kapitel bietet keine vollständige Spezifikation für alle diese Themengebiete. Sein Ziel ist es, die wichtigsten Konzepte, Schnittstellen und Zusammenhänge herauszuarbeiten, um so dem Leser das Rüstzeug für die weiteren Kapitel und das Basiswissen für die Entwicklung eigener Webanwendungen an die Hand zu geben. Technologien für Webanwendungen: - HTTP - HTTPS - Auszeichnungssprachen - Applets - Servlets - JSP - J2EE - Architekturen

2 8 2.1 Hypertext Transfer Protocol HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP wurde für den Einsatz in verteilten, Hypertext-basierten Informationssystemen konzipiert und ist damit eng mit der Entwicklung des World Wide Web verbunden. Als generisches und erweiterbares Protokoll eignet sich HTTP für zahlreiche weitere Anwendungsgebiete. Beispielsweise können andere Protokolle wie Java Remote Method Protocol (JRMP) das Übertragungsprotokoll von Remote Method Invocation (RMI) über HTTP»getunnelt«werden. Das kann nützlich sein, wenn zwischen Client und Server befindliche Firewalls das eigentlich benötigte Protokoll blockieren, aber für HTTP durchlässig sind. Allerdings ist dieser pragmatische Ansatz mitunter problematisch, weil er dazu benutzt werden kann, geltende Sicherheitsrichtlinien zu umgehen. Seit seiner Einführung im Jahr 1990 hat HTTP einen stetig wachsenden Anteil des Datenverkehrs im Internet übernommen. Heute werden größere Datenmengen mit HTTP übertragen als mit jedem anderen Protokoll der Anwendungsschicht, sei es das Simple Mail Transfer Protocol (SMTP) für s, das Network News Transfer Protocol (NNTP) für Nachrichten oder das File Transfer Protocol (FTP) für Dateitransfers. Aus dem zunehmenden Einsatz resultierten neue Anforderungen an Funktionsumfang und Leistungsfähigkeit von HTTP. Neben der ersten Fassung der Spezifikation gibt es zwei Nachfolgeversionen, welche die gestiegenen Anforderungen berücksichtigen. Die erste Version, HTTP/0.9, ist ein einfaches Protokoll zum Abrufen von HTML-Dokumenten. Es wird heute nicht mehr verwendet. Die nachfolgende Version, HTTP/1.0 [BFF96], unterstützt als wesentliche Erweiterung MIME-artige Nachrichten (Multi-Purpose Internet Mail Extensions), wodurch bereits protokollseitig Metainformation über die Art und Kodierung des Dokuments bereitgestellt werden kann. Die aktuelle Version, HTTP/1.1 [FG+99], die seit 1999 vorliegt, beinhaltet zahlreiche Verbesserungen, vor allem die Unterstützung von Proxy- Hierarchien, Caching, persistenten Verbindungen und virtuellen Hosts. Auch wenn die»interna«von HTTP im Webserver und Browser abgewickelt werden, ist für Entwickler von Webanwendungen ein gewisses Grundverständnis der Abläufe, der einzelnen Methoden und Statuscodes unerlässlich. Diese Informationen sind im vorliegenden Unterkapitel zusammengefasst. Die nachfolgenden Ausführungen beziehen sich, falls nicht explizit auf eine bestimmte Version hingewiesen wird, stets auf HTTP/1.1.

3 2.1 Hypertext Transfer Protocol Funktionsweise Das Hypertext Transfer Protocol definiert die Kommunikation zwischen einem (HTTP-)Client und einem (HTTP-)Server und folgt dabei einem einfachen Prinzip: 1. Der Client sendet einen Auftrag an den Server und wartet synchron auf eine Antwort. 2. Der Server empfängt den Auftrag und schickt eine Antwort zurück an den Client. HTTP unterscheidet zwei Arten von Nachrichten: Eine Request-Nachricht beschreibt einen Auftrag, eine Response-Nachricht eine Antwort. Zur Übertragung der Nachrichten setzt HTTP ein darunter liegendes Transportprotokoll voraus. Gemäß Spezifikation kann HTTP auf jedem beliebigen Transportprotokoll aufsetzen, das einen zuverlässigen Kommunikationskanal bereitstellt. Im praktischen Einsatz hat sich TCP/ als Transportprotokoll durchgesetzt. Nach [ReP94] ist 80 die»well-known TCP port number«, d.h. die allgemein gebräuchliche Portnummer für HTTP. Demgemäß erwarten HTTP-Server per Konvention Anfragen von Clients am TCP-Port 80. Es können aber auch andere Portnummern verwendet werden. Der Oracle HTTP Server in Oracle9iAS erwartet Requests standardmäßig am Port Abbildung 2 1 stellt den Ablauf bei der Verarbeitung eines Requests dar. Der Client initiiert eine Verbindung zum Server und sendet einen Request ab, mit dem er z.b. ein HTML-Dokument anfordert (1). TCP unterteilt die Daten in -Pakete (2). Üblicherweise laufen die Pakete über einen oder mehrere Router (3a, 3b), bevor sie den Server erreichen. Dort fügt die TCP-Schicht die -Pakete wieder zusammen (4) und reicht den Request an den HTTP-Server weiter (5). Der Server führt den Auftrag aus und sendet eine Response über TCP (6), (7), den Router (8a, 8b) und die TCP-Schicht des Clients (9) zum HTTP-Client (10). Request Response Portnummer 1 HTTP 10 HTTP-Request HTTP-Response 6 HTTP 5 Abb. 2 1 HTTP-Request und -Response TCP TCP 2 9 3a 8b 3b 8a 7 4 Client Router Server

4 10 Beide Arten von Nachrichten, Request und Response, bestehen jeweils aus: Einer Startzeile Einer Folge von Kopfzeilen Einer Leerzeile Einem optionalen Nachrichtenkörper Die Startzeile ist für Request und Response unterschiedlich definiert. In einem Request beschreibt sie den Auftrag, in einer Response enthält sie einen Statuscode, der über Erfolg oder Misserfolg Auskunft gibt. Jede Kopfzeile enthält einen Bezeichner und einen zugehörigen Wert. Die HTTP-Spezifikation definiert eine Reihe von Kopfzeilen wie zum Beispiel Date für Datum und Uhrzeit, wann ein Request oder eine Response gesendet wird. Darüber hinaus ist es möglich, anwendungsspezifische Kopfzeilen einzufügen. Eine Leerzeile trennt Kopfzeilen und Nachrichtenkörper. Letzterer dient zur Übermittlung der eigentlichen Nutzinformation (zum Beispiel HTML-Dokumente), ist aber nicht notwendigerweise in allen Arten von Aufträgen oder Antworten enthalten Request In einem Request enthält die Startzeile Angaben zur Auftragsart, Ressource, auf die sich der Auftrag bezieht, und Protokollversion (HTTP/1.0 oder HTTP/1.1). HTTP-Methoden: GET HEAD POST Die Auftragsart wird durch die so genannte (HTTP-)Methode beschrieben. Folgende Methoden sind vorgesehen: Ein GET-Request ist eine Aufforderung an den Server, die angegebene Ressource an den Client zu übertragen. Neben der Ressource liefert der Server auch dazugehörige Metainformation, wie zum Beispiel, wann die letzte Aktualisierung der Ressource erfolgte oder wie lange sie noch gültig ist. Der HEAD-Request unterscheidet sich vom GET-Request dadurch, dass der Server als Antwort lediglich Metainformation über die angefragte Ressource liefert, aber nicht die Ressource selbst überträgt. Entscheidet sich der Client nach Auswertung der Metainformation dafür, die Ressource zu laden, kann er in einem zweiten Schritt ein GET absetzen. Für Fälle, in denen der Client große Mengen an Daten an den Server übertragen möchte, eignet sich ein POST-Request. Mit POST können

5 2.1 Hypertext Transfer Protocol 11 ganze Dateiinhalte vom Client an den Server geschickt werden. Häufig werden auch Inhalte von Formularfeldern mittels POST zur Auswertung an den Server übergeben. In der Response sendet der Server ein entsprechendes Antwortdokument an den Client zurück. Ein PUT-Request ist ein Auftrag an den Server, den Nachrichtenkörper unter dem spezifizierten Namen abzuspeichern. Mit DELETE wird eine Ressource auf dem Server gelöscht. Ebenso wie die PUT-Methode ist DELETE auf frei zugänglichen Webservern im Internet sinnvollerweise deaktiviert beziehungsweise nur für den jeweiligen Webadministrator freigeschaltet. Mit dem OPTIONS-Request hat der Client die Möglichkeit, Optionen für die Kommunikation mit dem Server abzufragen. Beispielsweise kann der Server als Antwort auf einen OPTIONS-Request eine Liste der von ihm unterstützten HTTP-Methoden zurückgeben. Diese Methode wurde für Testzwecke vorgesehen. Der Server sendet als Antwort auf einen TRACE-Request einfach eine Kopie des Requests zurück. Die Methoden beziehen sich auf vom HTTP-Server bereitgestellte Ressourcen, zum Beispiel eine HTML-Seite, eine Grafik oder eine Audiodatei. Die Identifizierung der Ressource geschieht durch»uniform Resource Identifier«(URI) [BFM98]. URI sind eine Verallgemeinerung der allgemein gebräuchlichen Webadressen wie z.b.: PUT DELETE OPTIONS TRACE URI Diese Form einer URI wird als»uniform Resource Locator«(URL) bezeichnet, da sie den Ort der Ressource beschreibt. Eine URL spezifiziert das Protokoll, über das die Ressource erreichbar ist (http), auf welchem Server sie vorliegt ( und unter welchem Pfadnamen sie gespeichert ist (/Protocols/Spec.html). Eine zweite mögliche Form einer URI ist der»uniform Resource Name«(URN). Eine URN ist konzeptionell ein dauerhafter und ortsunabhängiger Name für eine Ressource. Beispielsweise wird das Dokument, welches die URN-Syntax festlegt, d.h. der RFC 2141 [Moa97], durch folgende URN eindeutig identifiziert: URL URN urn:ietf:rfc:2141 Die URN wird durch das einleitende»urn:«als solche ausgewiesen. Der nachfolgende Teil spezifiziert den Namensraum (ietf) und einen eindeutigen Namen der Ressource innerhalb des Namensraums (rfc:2141). In der praktischen Anwendung von HTTP spielen URNs allerdings derzeit nur eine untergeordnete Rolle. In der Regel werden Ressourcen durch URLs referenziert.