Grundbausteine einer Webapplikation mit Java EE 6

Transkript

1 Hochschule München Fakultät 07 Informatik und Mathematik Grundbausteine einer Webapplikation mit Java EE 6 Veranstaltung: Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Bearbeitet von: Thomas Haarbach (Matrikelnummer: ) Studiengruppe: Betreut von: IB6A Dipl. Inf. Michael Theis Vorgelegt am: Studienfach: Wirtschaftsinformatik

2 1 Inhaltsverzeichnis 2 Einleitung Allgemeine Grundlagen Das Word Wide Web Was ist eine Webapplikation? Identifizierung und Adressierung von Ressourcen im Internet URI, URL und URN HTTP-URLs Das Hypertext Transfer Protocol Ablauf einer HTTP-Kommunikation HTTP-Messages HTTP-Request HTTP-Methoden HTTP-Request Parameter HTTP-Header... 8 HTTP-Response HTTP-Statuscodes Cookies und Session Cookies Aufbau eines Cookies Session mit Cookies Mögliche Probleme Web-Techniken Grundbausteine einer Webapplikation mit dem Java Servlet API Einführung Unterschied zu anderen Technologien Beziehung zur Java EE Was ist ein Servlet? Was ist ein Servlet Container? Das Interface Servlet init()-methode service()-methode destroy()-methode I

3 4.2.4 Lebenszyklus eines Servlet Asynchronous Processing Basisklassen zur Erstellung von Servlets Die Basisklasse GenericServlet Die Basisklasse HttpServlet Datenaustausch und Datenhaltung Request und Response Der Request Das Interface ServletRequest Das Interface HttpServletRequest Die Response Das Interface ServletResponse Das Interface HttpServletResponse ServletConfig und ServletContext Das Interface ServletConfig Das Interface ServletContext Verhältnis zwischen ServletConfig und ServletContext Dispatching Requests Interface RequestDispatcher Servlet Filtering Das Interface Filter init()-methode dofilter()-methode dodestroy()-methode Lebenszyklus eines Filters Implementierung eines Filters Cookies und Sessions Das Interfaces HttpSession Die Klasse Cookie Erzeugen einer Session Deployment Descriptor und Annotations Die web.xml Annotations II

4 5 Fazit und Zusammenfassung Anhang... X 6.1 Abbildungsverzeichnis... X 6.2 Listingverzeichnis... X 6.3 Tabellenverzeichnis... XI 6.4 Literaturverzeichnis... XI 6.5 Ehrenwörtliche Erklärung... XIII III

5 2 Einleitung Als am 29. Oktober 1969 die ersten Datenpakete zwischen der University of California in Los Angeles und dem Stanford Research Institute ausgetauscht wurden, konnten die Entwickler des ARPANet damals noch nicht ahnen, welche Bedeutung dies für die Zukunft haben wird [1]. Knappe 20 Jahre später wurde durch Tim Berners-Lee die Grundlage für das World Wide Web (WWW) geschaffen. Noch heute basieren der Austausch und die Anzeige von Webinhalten auf dem von ihm entwickelten Hypertext Transfer Protocol (HTTP) sowie der Hypertext Markup Language (HTML) [2]. Weitere 20 Jahre, nachdem Berners-Lee das WWW konzipiert hatte und es seit 1993 der Öffentlichkeit zur Verfügung steht, können wir uns ein Leben ohne nur noch schwer vorstellen. Egal ob man Google Maps nach dem Weg fragt, eine Rechnung online bezahlt, eine Reise bucht oder unterwegs online ein Fußballspiel verfolgt, das WWW ist unser täglicher Begleiter geworden. Einer Studie aus dem Jahr 2010 zufolge waren bis zu diesem Zeitpunkt alleine in Deutschland mehr als 48 Mio. Bundesbürger online [3]. Dieser Trend wird sich weiter fortsetzen, da moderne Geräte, wie Smart TV s, Smartphone s und sogar Neuwagen, die Möglichkeit einer Verbindung zum WWW bieten oder sogar erfordern. Ein wesentlicher Grund für den Erfolg des WWW sind Webapplikationen, die es einem Endbenutzer ermöglichen, mit dem WWW zu interagieren und Webinhalte sich dynamisch, je nach getätigter Eingabe, ändern. Im weiteren Verlauf dieser Arbeit wird eine Technologie für Java-basierende Webapplikationen das Java Servlet Application Programming Interface 3.0 vorgestellt. Das Java Servlet API 3.0 (Servlet API) ist Bestandteil der Java Enterprise Edition 6 (Java EE6) Spezifikation und Grundbaustein für darauf aufbauende Technologien wie JavaServer Pages (JSP) oder JavaServer Faces (JSF) [4] [5]. Seite 1 von 41

6 3 Allgemeine Grundlagen Im folgenden Kapitel wird eine Einführung zu den Grundlagen des World Wide Web gegeben sowie Grundbausteine einer Webapplikation beschrieben. 3.1 Das Word Wide Web Eigentlich konzipierte Berners-Lee das WWW als Informationssystem für die European Organization for Nuclear Research (CERN). Man stand damals am CERN vor dem Problem, dass die Fülle an Informationen über Teilchenbeschleuniger und Experimente nicht mehr händelbar waren und damit eine große Gefahr von Informationsverlusten bestand. Deshalb machte Berners-Lee 1989/90 einen Vorschlag zur Verwaltung von Informationen in einem verteilten Hypertext System [6]. Computer conferenc ing IBM GroupT alk Hyper Card ENQUIRE VAX/ NOT ES uucp News for example Hierarc hical sys tems for example Linked information A Propos al "Mesh" unifies describes CERNDOC for example includes describes includes C.E.R.N "Hypertext" describes This document divis ion includes describes refers to wrote g roup g roup section Hypermedia etc Comms ACM Tim Berners-Lee Abbildung 1: Entwurf des Informationssystem als Netz [6] Laut Berners-Lee [6] musste ein solches System in der Lage sein, mit der Organisation bzw. den Projekten mitzuwachsen. Dabei durfte die Art der Speicherung nicht zu einer Beschränkung für die Größe der Information werden. Deshalb erschien es für Berners-Lee sinnvoller, ein System aus vernetzten Dokumenten zu etablieren, statt ein starres hierarchisches System zu entwickeln. Heute jedoch geht der Einsatz des WWW über eine reine Informationsverwaltung und -verteilung hinaus. Wie bereits in der Einleitung angedeutet, wollen Benutzer mit dem Web interagieren. Diese Interaktion kann die Nutzung einer Suchmaschine oder die Erstellung eigner Webinhalte innerhalb eines Content Management Systems sein. Für das Beispiel einer Suchmaschine gibt der Benutzer einen Suchbegriff in das Webinterface eines Suchmaschinenanbieters ein. Abhängig vom Suchbegriff wird eine Trefferliste erzeugt und dem Benutzer auf der Website angezeigt. In diesem Beispiel arbeitet im Hintergrund ein Programm auf Seite 2 von 41

7 einem Webserver, das eine Website mit der Trefferliste erzeugt. Diese Programme werden als Webapplikation bezeichnet [7, pp ]. 3.2 Was ist eine Webapplikation? Eine Webapplikation kann wie folgt definiert werden: Eine Webapplikation ist ein Computer- Programm, welches auf einem Webserver ausgeführt wird. Der Web-Browser dient dabei als Benutzerschnittstelle, mit dessen Hilfe der Benutzer mit dem Programm kommuniziert bzw. interagiert. Der Computer des Benutzers (Client) und der Dienstanbieter (Server) sind dabei über ein Netzwerk, wie beispielsweise dem Internet oder dem Intranet, verbunden und verwenden HTTP zur Kommunikation [7, p. 455]. HTTP Internet, Intranet, TCP/IP HTTP Port 80 Client mit Browser Server mit httpd Dokumente Abbildung 2: Web-Modell [8, p. 253] Webapplikationen können einen unterschiedlichen Grad der Komplexität erreichen. Die Bandbreite geht von einfachen Foren bis zu betriebswirtschaftlichen Anwendungen, wie beispielsweise Microsoft Dynamics CRM Online. An Webapplikationen werden, im Hinblick auf ihre Funktionalität, heutzutage die gleichen Anforderungen wie an Desktop- Anwendungen gestellt [7, p. 39]. 3.3 Identifizierung und Adressierung von Ressourcen im Internet Im Internet gibt es eine Vielzahl von verschiedenen Ressourcen. Um auf diese Ressourcen zugreifen zu können, müssen alle identifizierbar und zum größten Teil auch adressierbar sein. Die bekanntesten Ressourcen sind Webseiten oder FTP-Seiten, können aber auch logische Namen sein, wie z.b. Benutzernamen für -Konten. Damit eine Identifizierung bzw. Adressierung solcher Ressourcen möglich ist, wurden einheitliche Adressierungsmuster spezifiziert, welche kurz vorgestellt werden [7, p. 40] URI, URL und URN Ein Uniform Resource Identifier (URI) dient der Identifikation einer abstrakten oder physikalischen Ressource und hat den folgenden syntaktischen Aufbau [9, p. 16]: [ ][ ] In der Tabelle 1 sind verschiedene URIs aufgeführt. Wie man sieht, haben URIs, je nach angesprochen Dienst, ein anders Schema. Tatsächlich sind eine Vielzahl URI-Schemata definiert 1 [7, p. 41]. 1 Abrufbar unter Seite 3 von 41

8 SCHEMA AUTHORITY := HOST [:PORT] PFAD QUERY FRAGMENT ftp:// ftp.is.co.za /rfc/rfc1808.txt /rfc/rfc2396.txt ldap:// [2001:db8::7] /c=gb?objectclass?one mailto: news: comp.infosystems. tel: telnet:// :80 / urn: oasis:names:specification:docbook:dtd:xml:4.1.2 Tabelle 1: Übersicht verschiedener URI-Schemata [9, p. 7] Ein URI kann man, je nach ihrer Semantik, wie folgt unterscheiden: UNIFORM RESOURCE LOCATOR (URL): Die eindeutige Adresse einer physikalisch vorhandenen Ressource, wie z.b. eine Webseite. UNIFORM RESOURCE NAME (URN): Der weltweit eindeutige Name einer logisch vorhandenen Ressource, z.b. isbn: Abbildung 3: Zusammenhang URI,URL und URN HTTP-URLs HTTP-URLs sind durch das Schema http definiert und besitzen nachfolgende Syntax: [ ] [ ] HTTP-URLs sind in der HTTP-Spezifikation [10, p. 14] definiert und müssen bestimmte Eigenschaften erfüllen. So kann der Host-Teil ein DNS-Name oder eine IP-Adresse sein. Allerdings sollte der Einsatz einer IP-Adresse in HTTP-URLs, wenn möglich, vermieden werden. Auch wird festgelegt, dass bei einer fehlenden Portangabe der Standard-Port 80 verwendet wird. Ein Pfad besteht aus Segmenten, die getrennt durch "/" anzugeben sind. Seite 4 von 41

9 Nach einem "?" können Queries angegeben werden. Die Abbildung 4 zeigt eine, nach der HTTP-Spezifikation gültige, HTTP-URL. Abbildung 4: Beispiel einer gültigen HTTP-URL 3.4 Das Hypertext Transfer Protocol Als Kommunikationsprotokoll, zwischen HTTP-Client (Client) und HTTP-Server (Server), ist HTTP die Grundlage der Übertragung von Daten im WWW. Die Übertragung der Daten findet in Form eines Austausches von HTTP-Messages (Request/Response) statt. HTTP ist ein verbindungsorientiertes und zustandsloses Protokoll. Das bedeutet, dass keine der an der Verbindung beteiligten Parteien (Client/Server) irgendeine Information über den Zustand der Verbindung speichert. Zur Kommunikation nutzt HTTP ein zuverlässiges Transportprotokoll, welches in den meisten Fällen TCP 2 sein dürfte. Die Abbildung 5 zeigt, dass vor der HTTP-Kommunikation eine TCP-Verbindung aufgebaut wird, welche nach dem Nachrichtenaustausch vom Client wieder abgebaut wird. Ab der HTTP Version 1.1 (HTTP/1.1) kann durch Setzen eines Steuersignals (keep-alive) der Abbau der TCP-Verbindung verhindert werden. Dadurch ist es möglich, mehrere Abfrage-Antwort-Zyklen innerhalb einer TCP-Verbindung abzuarbeiten [8, pp ]. Clientseite Serverseite TCP-Verbindungsaufbau HTTP-Request HTTP-Response TCP-Verbindungsabbau Abbildung 5: HTTP-Kommunikation [8, p. 260] Ablauf einer HTTP-Kommunikation Der Client stellt eine Anfrage (HTTP-Request) an den Server. Der Server empfängt und bearbeitet den Request und sendet eine Antwort (HTTP-Response) an den Client zurück. Mit Absenden der Response ist der Request abgearbeitet und die Kommunikation beendet [8, p. 258]. Beide, der Request und die Response, treten stets paarweise auf und werden als HTTP-Messages bezeichnet. Die Kommunikation kann nur durch den Client eröffnet werden. Per Definition kann ein Server selbstständig keine Kommunikation beginnen, mit der Konsequenz, dass ein Server 2 TCP Transmission Control Protocol Transportprotokoll in der Schicht 4 im TCP/IP- Referenzmodell [8, p. 10] Seite 5 von 41

10 nicht selbstständig über Änderung benachrichtigen kann. Der Client muss, sofern Änderungen zu erwarten sind, den Server regelmäßig nach Änderungen fragen. Dieses regelmäßige, wiederholende (zyklische) Abfragen des Servers wird als Polling bezeichnet [7, p. 43] HTTP-Messages HTTP-Messages sind textbasierende und zeilenorientierte Nachrichten. Zur Darstellung der Zeichen wird US-ASCII verwendet und somit eine Plattformunabhängigkeit garantiert [7, p. 45]. Die beiden unterschiedlichen Ausprägungen werden in den nächsten beiden Abschnitten kurz erklärt HTTP-Request Ein HTTP-Request hat der Reihe nach folgenden Aufbau: REQUEST-LINE: Enthält Request-Methode, die Request-URI, die HTTP-Version sowie Eingabeparameter aus HTML-Formularen. REQUEST-HEADER: Eine Liste mit keinem oder mehreren HTTP-Headern mit Metainformation zur Behandlung eines Requests. Beispiel: Accept: text/html Browser unterstützt nur HTML-Dateien. LEERZEILE: Markiert das Ende der Request-Header Liste, dargestellt durch US-ASCII- Steuerzeichen <CR><LF> (carriage return + line feed). MESSAGE-BODY: Bereich für die Nutzdaten, der bei der Methode GET leer ist. Bei der Methode POST werden hier die Eingabeparameter aus HTML-Formularen übertragen. Die Abbildung 6 zeigt einen HTTP-Request mit Verwendung der Methode GET. Sie folgt genau dem zuvor skizzierten Aufbau. Die erste Zeile erhält die Request-Line, danach folgen verschiedene HTTP-Header [8, p. 259] [10, pp ]. GET /index.de.html HTTP/1.1<cr><lf> Host: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/ Firefox/11.0<cr><lf> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<cr><lf> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3<cr><lf> Accept-Encoding: gzip, deflate<cr><lf> DNT: 1<cr><lf> Connection: keep-alive<cr><lf> If-Modified-Since: Sat, 14 Apr :14:14 GMT<cr><lf> If-None-Match: "38eeb1-5d34-4bdabbf563d80"<cr><lf> Cache-Control: max-age=0<cr><lf> <cr><lf> Abbildung 6: HTTP-Request mit GET Wird statt der Methode GET die Methode POST verwendet, folgt nach der Liste von HTTP-Headern zunächst eine Leerzeile, repräsentiert durch <CR><LF>, dann der Message- Body mit Daten zur Verarbeitung im Server. Die Abbildung 7 zeigt, dass im Message-Body Daten enthalten sind. Seite 6 von 41

11 POST /fs4search/firstseek.search HTTP/1.1<cr><lf> Host: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/ Firefox/11.0<cr><lf> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<cr><lf> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3<cr><lf> Accept-Encoding: gzip, deflate<cr><lf> DNT: 1<cr><lf> Connection: keep-alive<cr><lf> Referer: Cookie: JSESSIONID=EF489DA3A9A94B01539F13DF9C55F18A<cr><lf> <cr><lf> Keyword=Mandl<cr><lf> Abbildung 7: HTTP-Request mit POST HTTP-Methoden Neben den bereits erwähnten Methoden GET und POST gibt es noch weitere Request- Methoden, die der Tabelle 2 zu entnehmen sind. Methode 3 GET Bedeutung Fordert die in dem Request-URI angegebene Ressource an. Hier bleibt der Message-Body leer. Übergabe von Parametern als Teil der URI möglich. Die Ressource wird im Message-Body der Response erwartet. POST Fordert die in dem Request-URI angegebene Ressource unter Berücksichtigung der im Message-Body enthaltenen Daten an. Die Ressource wird im Message-Body der Response erwartet. HEAD PUT DELETE Dient zum separaten Abrufen der Request-Header. Verhält sich wie GET, nur dass im Message-Body der Antwort keine Ressource enthalten ist und daher leer bleibt. Ermöglicht das Abrufen von Information einer Ressource, ohne diese komplett abrufen zu müssen. Ermöglicht das Hochladen einer Ressource unter Angabe eines Ziel-URI auf einen Webserver. Ermöglich das Löschen einer durch den Request-URI spezifizierte Ressource. TRACE OPTIONS CONNECT Sendet die Request so zurück, wie sie vom Server empfangen wurde. Nützlich, um Verbindungen zu debuggen. Ermöglicht das Abfragen der vom Server unterstützen Methoden und Eigenschaften. Wird von Proxyservern implementiert, die z.b. SSL-Tunnel unterstützen. Tabelle 2: HTTP-Methoden [10, pp ] Anmerkung: Ein Webserver muss mindestens die Methoden GET, POST und HEAD unterstützen HTTP-Request Parameter HTTP-Request Parameter dienen dazu, zusätzliche Informationen an die Webapplikation zu übermitteln. Meist handelt es sich um Daten aus HTML-Formularen. Http-Request Parameter unterscheidet man in Params-Parameter und Query-Parameter. Erstere sind Teil des Pfads und werden getrennt durch ein Semikolon oder Komma der URL angehängt. In der Praxis haben diese jedoch kaum eine Bedeutung. Der Standardfall ist der Einsatz von 3 Die HTTP-Methoden PUT, DELETE, TRACE, OPTIONS und CONNECT werden erst ab HTTP/1.1 unterstützt Seite 7 von 41

12 Query-Parametern, die bei der GET Methode getrennt durch ein "?" als Teil der URL oder bei der POST Methode im Message-Body angegeben werden [7, p. 49] (siehe auch 3.3.2). GET /search/sc.jsp?q=java HTTP/1.1<cr><lf> Request-Header Abbildung 8: HTTP-Request mit GET und Query-Parameter HTTP-Header Die HTTP-Spezifikation [10] definiert eine Reihe an möglichen HTTP-Headern. HTTP-Header enthalten Metainformation zur Steuerung einer HTTP-Message. Man unterscheidet: GENERAL-HEADER: Allgemeine Information zur Steuerung einer HTTP-Message, z.b. Connection: keep-alive bedeutet, dass die TCP-Verbindung bestehen bleiben soll. REQUEST-HEADER: Information zur Steuerung eines HTTP-Request und dürfen nur dort enthalten sein, z.b. Accept-Language: de-de,de gibt Auskunft über die vom Client unterstützten Sprachen. RESPONSE-HEADER: Information zur Steuerung eines HTTP-Response und dürfen nur dort enthalten sein, z.b. Server: Apache Information über den verwendeten Webserver. ENTITY-HEADER: Zusätzliche Information über den Inhalt des Message-Bodys, z.b. Content-Length: gibt die Länge der übertragenen Daten in Bytes an. Auf eine weiterführende Erklärung der einzelnen HTTP-Header wird an dieser Stelle verzichtet und auf die HTTP-Spezifikation verwiesen HTTP-Response Eine Antwort besteht aus den folgenden Teilen in der Reihenfolge: STATUS-LINE: Angabe der HTTP-Version, Statuscode des Requests und Reason Phrase. RESPONSE-HEADER: Wie bei einem Request sind hier die HTTP-Header aufgeführt. LEERZEILE: Markiert das Ende der HTTP-Header Liste. MESSAGE-BODY: Bereich für die Daten des Ergebnisses, in der Regel der HTML-Code. In der Abbildung 9 ist exemplarisch ein HTTP-Response zu sehen. In der ersten Zeile ist die Status-Line mit der HTTP-Version HTTP/1.1, dem Statuscode 200 sowie die Reason-Phrase OK eingetragen. Der Statuscode 200 bedeutet, dass der Request erfolgreich abgearbeitet wurde, was durch die Reason-Phrase OK unterstrichen wird. Danach folgen die bereits erwähnten HTTP-Header. Nach einem <CR><LF>, wodurch, wie bei einem Request auch, das Ende der Seite 8 von 41

13 HTTP-Header Liste anzeigt wird, folgt im Message-Body die angeforderte Ressource. In diesem Beispiel ein HTML-Code. HTTP/ OK<cr><lf> Date: Sun, 15 Apr :48:41 GMT<cr><lf> Server: Apache<cr><lf> Last-Modified: Sat, 14 Apr :10:22 GMT<cr><lf> Etag: " dd-4bdabb "<cr><lf> Accept-Ranges: bytes<cr><lf> Content-Length: 18653<cr><lf> Keep-Alive: timeout=5, max=100<cr><lf> Connection: Keep-Alive<cr><lf> Content-Type: text/html<cr><lf> <cr><lf> <html> </html> Abbildung 9: HTTP-Response mit Ergebnis HTTP-Statuscodes Statuscodes sind zum Teil in der HTTP-Spezifikation festgelegt, können aber je nach Server- Implementierungen auch individuell geregelt sein. Die Tabelle 3 zeigt einen Auszug in der HTTP-Spezifikation [10] festgelegten Statuscodes. Klasse Beispiel Bedeutung Informational 1xx 100 Continue Der Einleitungsteil des Requests ist beim Server angekommen und die Übertragung kann fortgesetzt werden. Successful 2xx 200 OK Der Request wurde erfolgreich abgearbeitet. Redirection 3xx 202 Accepted Der Request wurde akzeptiert, konnte aber noch nicht vollständig abgearbeitet werden. 301 Moved Permanently Die angeforderte Ressource hat einen neuen URI und kann über die zurückgesendeten URIs abgerufen werden. Client Error 4xx 404 Not Found Die angeforderte Ressource ist auf dem Server nicht vorhanden. Server Error 5xx 501 Not Implemented Der Server unterstützt die erforderliche Methode zu Bearbeitung des Requests nicht. Tabelle 3: HTTP-Statuscodes [10, pp ] 3.5 Cookies und Session Cookies Wie bereits im Abschnitt 3.4 erwähnt, ist HTTP zustandslos und speichert keine Zustandsdaten über die HTTP-Verbindung. Damit das Halten von Zustandsdaten über mehrere Anfrage-Abfrage-Zyklen möglich ist, wurden HTTP-Cookies (Cookies) eingeführt und zunächst in der RFC 2109 HTTP State Management Mechanism [11] spezifiziert. Mittlerweile ist die RFC 6265 [12] aus dem Jahr 2011 aktuell. Cookies sind kleine Textdateien mit clientspezifischen Informationen über den Zustand. Diese werden während einer HTTP-Kommunikation zwischen Webbrowser (HTTP-Client) und Webserver (HTTP-Server) ausgetauscht. Verwaltet wird ein Cookie vom Webbrowser, der sie persistent speichert und nach vorgegebenen Regeln wieder löscht [7, pp ]. Seite 9 von 41

14 Erzeugt wird ein Cookie in der Regel von einer Webapplikation, die auf einem Webserver ausgeführt wird. Dazu leitet der Webserver den Request an die Webapplikation weiter, um die Anfrage zu bedienen. Zunächst wird durch die Webapplikation geprüft, ob bereits ein Cookie vorhanden ist. Sollte kein Cookie existieren oder es sollen die Informationen eines Cookies geändert werden, wird ein neues Cookie erzeugt und in einem Header-Feld der Response zurück an den Client gesendet. Dieser speichert das Cookie zugeordnet zur aufgerufenen URL ab und sendet es von nun an mit jedem Request an diese URL mit. Die Abbildung 10 zeigt grob den Ablauf einer HTTP-Kommunikation mit Cookie. Web-Client Web-Server TCP-Verbindungsaufbau Web-App HTTP-Request an URL x Prüfen auf Cookie HTTP-Response Set-Cookie: URL x Kein Cookie Cookie erzeugen Cookie vorhanden Cookie Daten ändern Cookie speichern HTTP-Request an URL x Cookie: URL x Keine Änderung nötig Response senden Abbildung 10: HTTP-Kommunikation mit Austausch von Cookies Cookies können auch über clientseitige Skripte erzeugt werden. Dies könnte beispielsweise eine JavaScript Funktion sein, die Spracheinstellungen des Benutzers in einem Cookie speichert. Der Ersteller eines Cookies kann angeben, wie lange ein Cookie existieren soll, das heißt, wie lange es gespeichert bleibt. Wird keine Lebensdauer angegeben, wird das Cookie mit dem Schließen des Webbrowsers gelöscht. Der Browserbenutzer bemerkt in der Regel nichts von diesen Vorgängen. Weder das Speichern, noch das Zurücksenden eines Cookies an den Server, wird angezeigt. Heute gängige Browser bieten meist die Möglichkeit, die Behandlung von Cookies explizit einzustellen [7, p. 187] Aufbau eines Cookies Ein Cookie hat einen Namen, der aus einem Namen-Wert-Paar 4 aus alphanumerischen US- ASCII Zeichen besteht. Darüber hinaus können Cookies weitere Werte aus US-ASCII Zeichen enthalten, wie z.b. eine SessionID oder Angaben zur Lebensdauer [13, p. 73] Session mit Cookies Neben der Möglichkeit, benutzerdefinierte Einstellungen einer Webseite zu speichern, können mittels Cookies Sitzungen (Sessions) realisiert werden. Dazu wird in einem Cookie eine, von einer Webapplikation erzeugte, SessionID eingetragen und dem Client über die 4 Wird auch als Token bezeichnet. Seite 10 von 41

15 Response gesendet. Der Client sendet nun mit jedem Request, der an diese URL gerichtet ist, dieses Cookie zur Identifikation mit. Solche Cookies werden auch als Session-Cookies bezeichnet und existieren nur so lange, wie die Session besteht, und sind daher temporär [7, p. 202]. Unter einer Session versteht man logisch zusammenhängende Aktionen, die über einen definierten Zeitraum im selben Kontext getätigt werden. Die SessionID ist eine generierte eindeutige Nummer, die zur Identifikation einer Session dient. In Webapplikationen ist dies von elementarer Bedeutung, da mehrere Clients gleichzeitig Aktionen ausführen können. Diese Aktionen werden über HTTP-Requests an die Webapplikation übermittelt. Deshalb ist es wichtig, dass jeder Request, der dazugehörigen Session zugeordnet wird [7, p. 203]. In einer Session könnte z.b. die Warenkorbfunktionalität eines Online-Shops verwaltet werden. Sollten nun Aktionen, wie das Hinzufügen eines neuen Artikels, nicht der richtigen Session zugeordnet werden, wäre es möglich, dass ein Benutzer einen Artikel bestellt, den er eigentlich nicht wollte. HTTP-Client HTTP-Server Login POST username=thomas password=a_passwd Response Set-Cookie: SESSIONID=623AC7642 Login successful? 1. create sessionid 2. return sessionid in cookie 3. store sessionid in database SESSION ID sessionid username createdate expiredate lastaccessdate Datenbank GET Cookie: SESSIONID=623AC7642 Response Content für Thomas Lookup SessionID 1. session match a username? 2. session still valid Abbildung 11: Erstellen einer Sitzung zur Identifikation eines Benutzers [14] Eine Session beginnt in der Regel mit dem Aufruf der Webapplikation 5 durch einen Client und endet nach Abarbeitung der letzten Aktion. Sollte ein Client über einen längeren Zeitraum keine Aktionen mehr durchführen, sollte sichergestellt sein, dass die Session nach einem definierten Zeitraum selbstständig beendet wird. Dies wird als Timeout bezeichnet. Ein Timeout wird aus Performanz- sowie Sicherheitsgründen festgelegt. Eine Webapplikation würde nicht bemerken, dass z.b. ein angemeldeter Benutzer die Webapplikation nicht mehr 5 Diese Web-App könnte z.b. ein Online-Shop oder eine Online-Banking Anwendung sein. Seite 11 von 41

16 nutzt und die Session bliebe bestehen. Die Gründe bezüglich der Sicherheit liegen dabei auf der Hand. Durch eine nicht geschlossene Session könnten sich Unbefugte, Zugriff zu dieser Webapplikation verschaffen. So wird z.b. im Online-Banking eine Session in der Regel nach min beendet [7, p. 206]. Die Gründe der Performanz sind nicht so deutlich. Zunächst muss man Sessions als Objekte verstehen, welche im Kontext einer Webapplikation existieren. Neben dem Halten der Benutzerdaten, dienen Sessions oftmals auch als Zwischenspeicher für Anwendungsdaten, z.b. Daten eines Warenkorbs. Diese Session-Objekte wachsen mit der Dauer der Session und der Menge der gespeicherten Anwendungsdaten. Bei einem Benutzer macht dies noch nicht viel aus. Bei einer großen Anzahl von angemeldeten Benutzern kann dies zu einem großen Speicherbedarf führen, worunter zwangsläufig die Performanz leidet [7, pp ] [15, pp ] Mögliche Probleme Wie bereits im Abschnitt beschrieben, können Benutzer ihren Webbrowser so einstellen, dass Cookies prinzipiell abgelehnt werden. Das muss ein Entwickler bei der Erstellung einer Webapplikation berücksichtigen. Eine Session-Verwaltung, die ausschließlich mittels Cookie realisiert wird, würde bei Ablehnung des Cookies die Session verlieren [13, pp ]. Konzepte, die dennoch das Halten von Session-Informationen ohne Cookie ermöglichen sind: HIDDEN-FIELDS Die SessionID wird in einem nicht sichtbaren Feld innerhalb des HTML-Codes eingebunden. URL-REWRITING Dem URL wird die SessionID als HTTP-Request Parameter angefügt. SECURE SOCKET LAYER (SSL) Während dem Aufbau der TCP-Verbindung wird automatisch ein eindeutiger Identifikator erzeugt, der auch für die Session-Verwaltung verwendet werden kann. In der Praxis hat sich eine Kombination aus Session-Cookie und URL-Rewriting etabliert. Allerdings gibt es hier ein Problem. Die Webapplikation erhält keine Informationen darüber, ob der Web-Browser Cookies akzeptiert. Deswegen wird bei der Erstellung der Session zunächst beides angewandt. Zum einen wird die SessionID in einem Cookie, zum anderen als URL-Parameter übermittelt. Ist beim darauffolgenden Request das Session-Cookie im HTTP-Request-Header enthalten, werden für den weiteren Verlauf nur noch Session-Cookies verwendet. Im anderen Fall wird URL-Rewriting eingesetzt [13, p. 78] [16, p. 238]. Seite 12 von 41

17 3.6 Web-Techniken Web-Techniken können in clientseitige und serverseitige Web-Techniken unterschieden werden. Clientseitige Web-Techniken werden im Webbrowser verarbeitet oder ausgeführt. Darunter fallen Sprachen, wie HTML, XHTML, XML, CSS, HTML5 und JavaScript. Aber auch Java selbst ist als Java-Applet denkbar. Für Java-Applets muss allerdings eine Java Virtual Machine (JVM) auf dem Client vorhanden sein [7, pp. 5-6]. Client mit Web-Browser Web-App HTTP-Request Cleintseitige Techniken: HTML, XHTML, XML, HTML5, JavaScript etc. HTTP-Response Webserver Serverseitige Techniken: Servlets, JSP, JSF Abbildung 12:Abgrenzung clientseitige und serverseitige Web-Techniken [7, p. 6] Serverseitige Web-Techniken bezeichnen Komponenten, die auf einem Webserver verarbeitet oder ausgeführt werden. Für serverseitige Web-Techniken gibt es eine Vielzahl von Techniken. Im Java-Umfeld sind es Technologien wie Java Servlets, JavaServer Pages oder JavaServer Faces, welche es ermöglichen, umfangreiche und leistungsfähige Webapplikationen zu entwickeln. Seite 13 von 41

18 4 Grundbausteine einer Webapplikation mit dem Java Servlet API Nachdem im Kapitel 3 Grundlagen einer Webapplikation erläutert wurden, behandelt dieses Kapitel die Grundbausteine, die das Servlet API 6 zur Erstellung von Webapplikationen bietet. 4.1 Einführung Die Geschichte der Java Servlets (Servlet) reicht zurück bis in das Jahr James Gosling experimentierte damals an einem Java-basierten Webserver, womit er auch die Grundlagen für Servlets legte. Die erste Version das Java Servlet API 2.1 wurde allerdings erst 1999 zur Verfügung gestellt [17, p. 173]. Seit Dezember 2009 ist diese in der Version 3.0 verfügbar. Die Abbildung 13 zeigt die Kernkomponenten der API. <<interface>> ServletConfig <<interface>> ServletContext <<interface>> RequestDispatcher <<abstract>> GenericServlet <<interface>> Servlet <<abstract>> HTTPServlet <<interface>> ServletRequest <<interface>> ServletResponse <<interface>> HTTPServletRequest <<interface>> HTTPServletResponse <<interface>> HTTPSession n Cookie Abbildung 13: Kernkomponenten des Java Servlet API [18] Unterschied zu anderen Technologien In der Funktionsweise kann man ein Servlet mit Common Gateway Interface (CGI) Programmen (CGI-Scripte) vergleichen. CGI-Scripte sind aber im Gegensatz zu Servlets eigenständige Programme. Bei CGI wird für jeden eingehenden HTTP-Request ein eigener Prozess gestartet. Das hat den Vorteil, dass der Anwendungsprozess von Serverprozess getrennt ist und CGI-Skripte so in fast jeder beliebigen Sprache geschrieben sein können. Ebenfalls ist dadurch eine gewisse Absturzsicherheit des Webservers gewährleistet, da ein Fehler im CGI-Skript nicht zu einem Absturz des Webservers führt [2, p. 6]. Allerdings hat das Erstellen neuer Prozesse einen hohen Ressourcenverbrauch zur Folge und belasteten das Betriebssystem durch die notwendigen Prozesswechsel. Hier haben Servlets den Vorteil, dass sie als leichtgewichtige Threads innerhalb eines Prozesses ablaufen und dadurch weniger Overhead beim Prozesswechsel erzeugt wird. Bei Servlets läuft auf dem Webserver nur der Prozess für den Webcontainer [13, p. 81]. Dieser unterschiedliche Ansatz beim Prozessmodel macht Servlets wesentlich performanter bei niedrigerem Ressourcenverbrauch. Das von vielen Webservern unterstützte Servlet API sowie die Plattformunabhängigkeit sind weitere Vorteile von Servlets. [4, p. 3]. 6 Application Programming Interface - Programmierschnittstelle Seite 14 von 41

19 Client 1 HTTP-Request HTTP-Response Webserver Client 1 HTTP-Request HTTP-Response Webserver Prozess 1 Client 2 HTTP-Request HTTP-Response HTTP-Request HTTP-Response Servlet-Instanz Client 2 HTTP-Request HTTP-Response HTTP-Request HTTP-Response Prozess 2 Prozess n Client n Verarbeitung nebenläufiger Anfragen bei Servlets Client n Verarbeitung nebenläufiger Anfragen bei CGI Abbildung 14: Vergleich von Servlet und CGI bei der Verarbeitung von HTTP-Requests [13, pp ] Beziehung zur Java EE 6 Das Servlet API ist ein Bestandteil der Java EE 6 Spezifikation und Teil des dazu gehörigen Java Development Kits (JDK). Die Tabelle 4 zeigt die Pakete des Servlet API. Packages javax.servlet javax.servlet.annotation javax.servlet.descriptor javax.servlet.http Tabelle 4: Pakete des Servlet API [19] Das javax.servlet Package beinhaltet Klassen und Interfaces, die als Zusicherungen zwischen Servlet und Ablaufumgebung zu verstehen sind. Mit diesen Klassen und Interfaces können allgemeine Servlets erstellt werden Annotationen erlauben es, Servlets, Filter und Listener zu deklarieren und können auch als Metadaten verstanden werden. Erlaubt einen programmatischen Zugriff auf Informationen aus der web.xml und web-fragment.xml. Das javax.servlet.http beinhaltet Klassen und Interfaces, die als Zusicherungen zwischen Servlet und Ablaufumgebung verstanden werden und HTTP nutzen. Mit diesen Interfaces können HTTP spezifische Servlets erstellt werden Was ist ein Servlet? Ein Servlet ist eine Java-basierende Web-Komponente, die durch eine spezielle Ablaufumgebung verwaltet und ausgeführt wird. Diese Ablaufumgebung wird als Servlet- Container oder Webcontainer bezeichnet. Servlets dienen dazu, Anfragen eines Clients zu verarbeiten und dynamisch Antworten zu generieren. Wie alle Java-basierenden Technologien wird aus Servlet-Klassen plattformunabhängiger Bytecode erzeugt, welcher dynamisch zur Laufzeit in einen Webserver geladen und ausgeführt werden kann. Dabei werden an den Webserver nur zwei Anforderungen gestellt: Er muss auf Java basieren und Servlets unterstützen, das heißt, einen Servlet-Container zur Verfügung stellen [4, p. 1]. Eine Webapplikation besteht normalerweise aus einer Reihe an Servlets, JavaBean und sonstigen Ressourcen, z.b. Bilder, HTML-Dokumente, und werden in der Regel in einem Web- Application-Archive (war) zusammengefasst [13, p. 85] Was ist ein Servlet Container? Der Servlet-Container ist die Ablaufumgebung für Servlets und hat die Aufgabe, den Lebenszyklus eines Servlets zu steuern und zu überwachen. Ebenso leitet er die eingehenden Anfragen an das betreffende Servlet weiter und sendet die, durch das Servlet generierte, Antwort an den Client zurück [16, pp ]. Seite 15 von 41

20 Ein Servlet-Container kann Teil eines Application-Servers sein, der, wie ein Servlet-Container auch, eine spezielle Ablaufumgebung für Java Anwendungen ist, jedoch ein größeres Einsatzspektrum besitzt [13, p. 85]. Neben einer Java Virtual Maschine (JVM), stellt der Web-Container APIs der Java Standard Edition (Java SE) sowie weitere APIs, z.b. das Java Transaction API (JTA) oder das Java Naming and Directory Interface (JNDI), zur Verfügung [13, p. 85]. 4.2 Das Interface Servlet Das Interface javax.servlet.servlet ist die zentrale Schnittstelle des Servlet API. In diesem Interface sind Methoden 7 zur Steuerung des Lebenszyklus eines Servlets deklariert. Die Tabelle 5 gibt eine Übersicht aller Methoden des Interfaces. Method Summary ServletConfig String Tabelle 5: Methoden des Interface Servlet [19] destroy() Wird durch den Servlet Container aufgerufen, um ein Servlet zu beenden. getservletconfig() Gibt ein ServletConfig Objekt zurück, welches die Initialisierungs- und Startparameter enthält. getservletinfo() Liefert Information über das Servlet, wie Autor, Version und Copyright init(servletconfig config) Wird zum Initialisieren eines Servlets durch den ServletContainer aufgerufen. service(servletrequest req, ServletResponse res) Wird bei einem eingehenden Request durch den ServletContainer aufgerufen init()-methode Nachdem eine Instanz des Servlets erzeugt wurde, wird durch den Servlet-Container die Methode init(servletconfig config) aufgerufen, um notwendige Initialisierungsschritte auszuführen. Hierbei enthält das übergebene Objekt javax.servlet.servletconfig config die Konfiguration- und Initialisierungsparameter des Servlets. Nur wenn diese Methode erfolgreich ausgeführt wurde, kann ein Servlet eingehende Requests verarbeiten [4, p. 8] [13, p. 91] service()-methode An die Methode service(servletrequest req, ServletResponse res) leitet der Servlet- Container, nach der erfolgreichen Initialisierung, alle Requests eines Clients als ServletRequest Objekte weiter, um diese dort zu verarbeiten. Darüber hinaus übergibt der Servlet-Container ein ServletResponse Objekt, welches die Antwort aufnimmt. Zu beachten ist, dass diese Methode durch mehrere Threads ausgeführt werden kann und Vorkehrungen getroffen werden müssen, die konkurrierenden Zugriffe abzusichern. Um sicher konkurrierende Zugriffe zu gewährleisten, schlägt die Servlet API Spezifikation zwei Möglichkeiten vor. Zum einen können mittels syncronized Methoden oder Blöcke threadsicher ausgeführt werden. Zum anderen kann das Interface javax.servlet.singlethreadmodel verwendet werden. Dieses Interface stellt sicher, dass 7 In dem Servlet API auch als life-cycle-methods bezeichnet Seite 16 von 41