Hauptseminar Java 2 Thema Servlets und JavaServer-Pages

(1)

Hauptseminar Java 2 Thema

Servlets und JavaServer-Pages

Zusammenfassung

Die Einschrankungen von Anfrage/Antwort-basierten Web-Systemen wurden schon 1995 erkannt. Damals spezi zierte das National Center for Supercomputing Applications (NCSA) mit dem Common Gateway Interface (CGI) den ersten Ansatz, um uber Web- Server auch dynamische Inhalte vero entlichen zu konnen.

Seit jungstem geht Sun mit dem Servlet API, einer Standard Java-Erweiterung einen neuen Weg zur Erweiterung Anfrage/Antwort-basierter Server. Besonders im HTTP-Bereich dienen heute Servlets anstelle von CGI als eigenstandige Anwendung oder als Makler zwischen Nutzer auf der Clientseite und bestehenden Backend-Anwendungen auf der Serverseite, um im Internet steigende Informationsmengen und interaktive Inhalte anzubieten.

Dem Motto

"

Servlets are to servers what applets are to browsers\ ist dieses Seminar gewid- met.

Wintersemester 1999/2000 Universitat Ulm

Fakultat Informatik Abteilung Verteilte Systeme

Autor Peter Koller XXX

Betreuer

Prof. Dr. Michael Weber

Dipl.-Inf. Frank Kargl

Dipl.-Inf. Torsten Illmann

Dipl.-Inf. Markus Kieninger

(2)

Inhaltsverzeichnis

I Servlets 4

1 Einfuhrung in Servlets 4

2 Alternative Ansatze 4

2.1 Common Gateway Interface . . . 5

2.2 Proprietare Server-API . . . 6

2.3 Eingebaute Skript-Engines . . . 6

3 Der Servlet-Ansatz 6 4 Voraussetzungen 7 5 Programmierung 8 5.1 Grundlagen . . . 8

5.2 Beispiel 1: HelloWorld-Servlet . . . 9

5.3 Ubersetzen, installieren und testen . . . 9

6 Die Servlet-Umgebung 10 6.1 Zugri auf die Initialisierungsparameter mit ServletCon g . . . 10

6.2 Schnittstelle zur Servlet-Engine mit ServletContext . . . 10

6.3 Anfrageobjekt ServletRequest . . . 10

6.4 Antwortobjekt ServletResponse . . . 11

7 Features 11 7.1 Cookies . . . 11

7.2 Session-Management . . . 12

7.2.1 Grundlagen . . . 12

7.2.2 Beispiel 2: Foo-Bar Shop . . . 13

8 Server-Side Includes mit Servlets 16

9 Bewertung von Servlets 17

II JavaServer-Pages 18

10 Einfuhrung in JavaServer-Pages 18

Hauptseminar: Seite 2 von 22 Peter Koller

Servlets und JavaServer-Pages 14.02.2000

(3)

11 Wie funktioniert das? 18

12 Programmierung 19

12.1 Grundlagen . . . 19 12.2 Beispiel 3: HelloWorld JavaServer-Page . . . 19

13 Bewertung von JavaServer-Pages 20

Glossar 21

Referenzen 22

(4)

Teil I

Servlets

1 Einfuhrung in Servlets

Um das Interesse fur das Thema Servlets zu wecken, mochte ich hier auf die Einschrankungen von Web-Servern eingehen. Dies ist keine richtige Einschrankung in dem Sinne, dass bei der Entwicklung von Web-Servern wichtige Funktionen vergessen wurden. Es ist vielmehr das allgemeine Prinzip bei Client/Server-Systemen, dass ein Server eine bestimmte Menge an Aufgaben zu erfullen hat und fur diese entsprechende Dienste (Services) anbietet. Bei Web- Servern ist diese quasi Einschrankung, dass sie auf das Ausliefern von Dateien

beschrankt sind. Sie arbeiten nach dem Anfrage/Antwort-Prinzip (Request/Response).

Mittels verschie-dener Anfragemethoden, beispielsweise GET und POST bei HTTP kann ein Client, wie ein Web-Browser Dateien abrufen, die vom Web-Server angeboten werden.

Dies ist eine sehr statische Angelegenheit. Wunschenswert sind aber auch dynamische Web-Dokumente, wie

datenbankgenerierte Seiten wechselnde Werbebanner Auskunftssysteme Shopping-

Systeme etc.

Hier und auch bei noch vielen weiteren Aufgaben, wie bei der Verarbeitung von HTML- Formularen, der Weiterleitung von Anfragen und der Zusammenarbeit (Collaboration) meh- rerer Clients (z. B. Online-Konferenzsysteme) bieten Servlets eine Moglichkeit Anfrage/

Antwort-basierte Server zu erganzen, um daruber hinausgehende Anwendungen (Applica- tions) als das statische Ausliefern von Dateien zu ermoglichen.

Naturlich ist die Idee eine Schnittstelle zwischen den Anwendungen und dem Web-Server zu scha en nicht neu und es gibt bereits verschiedene Ansatze dazu auf die ich im nachsten Abschnitt eingehen werde.

2 Alternative Ansatze

Im wesentlichen gibt es, abgesehen von eingebauten Skript-Engines, drei Ansatze, um Ant- wort/Anfrage basierte Web-Server zu erweitern. Der alteste Ansatz wurde 1995 mit der Fest- legung des Common Gateway Interface (CGI) gescha en. Ein anderer Ansatz kommt von den Herstellern der Web-Server selbst und das sind Anwendungsprogrammierschnittstellen (API), die ihre hauseigenen Web-Server erweitern. Dies nennt man kurz proprietare Server-API.

Diese Ansatze mochte ich den folgenden Unterabschnitten kurz vorstellen, bevor ich im nachsten Abschnitt auf die jungste Entwicklung, den Servlet-Ansatz, eingehe.

(5)

2.1 Common Gateway Interface

Das Common Gateway Interface (CGI) wurde vom National Center for Supercomputing Applications (NCSA) entwickelt und spezi ziert den Datentransport vom Web-Server zum Anwendungsprogramm. Dieses Anwendungsprogramm kann dabei das CGI-Skript ¹ selbst sein oder aber eine Anwendung bei der das CGI-Skript als Makler zwischen Web- Server und Anwendung auftritt.

Die Wege von einem Web-Client uber den Web-Server an ein CGI-Skript verdeutlicht folgende Abbildung:

Abbildung 1: CGI-Kommunikation

Um ein CGI-Skript auf dem Web-Server auszufuhren stellt zuerst ein Web-Client, in diesem Falle ein Web-Browser, eine Anfrage an den Web-Server. Der Web-Server merkt dabei ², dass es sich um ein ausfuhrbares CGI-Skript handelt und setzt zuerst einige Umgebungsvariablen.

Diese dienen spater zum Austausch von Informationen zwischen dem Web-Server und dem CGI-Skript (z. B. Servername, Anfragemethode, etc.). Danach startet er das CGI-Skript, in- dem ein neuer Prozess erzeugt wird und ubermittelt je nach Anfragemethode auch Daten an die Standardeingabe des CGI-Skripts. Das CGI-Skript selbst wiederum liest die Umgebungs-variablen und die Standardeingabe und bearbeitet diese entsprechend der Programmlogik. Dabei kann es auf Ressourcen, wie Dateien, eine Datenbank oder andere Anwendungen zu-greifen. Nachdem es seine Informationen zusammengestellt hat, schickt es diese uber seine Standardausgabe an den Web-Server. Dieser nimmt die Daten an und transferiert sie an den Web-Client weiter.

In der Abbildung ist zu sehen, dass jede Anfrage an ein CGI-Skript einen eigenen Prozess erzeugt und bei mehreren Anfragen auch mehrere Prozesse ein- und desselben CGI- Skripts existieren konnen. Prozesswechsel sind aber im Sinne von Rechenzeit teuer und au ern sich in der Geschwindigkeit, wenn viele Anfragen im selben Zeitraum an ein CGI- Skript eintre en. Andererseits hat dieser Ansatz aber auch den Vorteil, dass das CGI- Skript den Web-Server nicht zum Absturz bringen kann.

1Man spricht an dieser Stelle hau g von Skripten anstatt von Programmen, da diese Programme oft mit Perl realisiert werden.

2Dies geschieht dadurch, dass sich ausfuhrbare CGI-Skripte in einem speziellen Verzeichnis, meist cgi-bin be nden mussen.

(6)

2.2 Proprietare Server-API

Proprietare Server-API sind Anwendungsprogrammierschnittstellen direkt von den Herstel-lern zu ihren eigenen Web-Servern. Beispiele sind NSAPI (Netscape Server Application Pro- gramming Interface) von Netscape und ISAPI (Internet Server Application Programming Interface) von Microsoft. Die Programme werden dabei direkt in den Web-Server eingebun- den. Dadurch wird ein Geschwindigkeitsvorteil erreicht, weil nicht laufend zwischen einzelnen Prozessen (vergleiche CGI) hin- und hergeschaltet werden muss. Andererseits konnen aber dadurch Programme den Web-Server zum Absturz bringen.

2.3 Eingebaute Skript-Engines

Eingebaute Skript-Engines wie beispielsweise Apache mod perl, mod php3 und Technologien wie Microsoft Active Server Pages sind im Vergleich zu CGI zwar e zienter, aber im Bezug auf die Skalierbarkeit, Portabilitat und Code Re-Use der JavaServer-Pages Technologie un- terlegen. Auf die Technologie von serverseitigen (serverside) Skript-Engines wird im zweiten Teil dieses Seminarhefts anhand von JavaServer-Pages eingegangen.

3 Der Servlet-Ansatz

Mit der Servlet API bietet Sun eine Anwendungsprogrammierschnittstelle fur serverseitige Java-Programme. Die Servlet API ist eine Standard Java-Erweiterung ³. Dabei gibt es ahnli- che Zugri smoglichkeiten wie bei CGI. So ist der Zugri auf Umgebungsvariable moglich und es existieren Datenstrome fur die Anfrage und die Antwort. Zusatzlich bietet das Servlet API Unterstutzung fur Cookies und ein Session-Management auf die hier in eigenen Abschnitten eingegangen wird.

Im Gegensatz zu CGI wird beim Servlet-Ansatz bei einer Anfrage fur ein Servlet nicht jedes Mal ein eigener Prozess erzeugt, sondern nur ein Thread. Daher sind bei konkurrierenden Anfragen keine Prozesswechsel des Betriebssystems notwendig und es tritt dadurch eine deut-liche Geschwindigkeitsverbesserung ein.

In der folgenden Abbildung wird der Weg vom Web-Client zum Servlet verdeutlicht.

Es wurden im Vergleich zur Abbildung der CGI-Kommunikation der Web-Server und Um- gebungsvariable zusammengefa t. Wie man sieht ist auf der Serverseite eine mit dem Web-Server korrespondierende Servlet-Engine notwendig.

3Das x in den Paketnamen die mit javax. beginnen, deutet auf eine Standard Java-Erweiterung.

(7)

Abbildung 2: Servlet-Kommunikation

Die Abbildung zeigt, dass selbst bei mehreren Anfragen an ein Servlet nur eine Servlet- Instanz erzeugt und initialisiert werden muss. Dabei spielt es keine Rolle, ob das Servlet in demselben oder einem anderen Prozess als der Server lauft.

4 Voraussetzungen

Um Servlets einsetzen zu konnen werden neben einem Web-Server und dem Java Serv- let Development Kit JSDK (http://java.sun.com/products/servlet/download.html)⁴ eine Servlet-Engine benotigt. Diese muss passend zum Web-Server sein. Auf der Web-Site von Sun ndet man eine ganze Reihe kommerzieller aber auch freier Servlet-Engines (http://java.sun.com/products/servlet/industry.html). Hier davon nur ein paar davon fur unterschiedliche Web-Server und Betriebssysteme:

JServ (http://java.apache.org/) fur den Apache-Web-Server (Apache Group) JRun (Allaire; ehemals von Live Software; http://www.jrun.com/products/jrun/) fur eine ganze Reihe von Web-Servern:

{ Apache-Web-Server (Windows NT und Unix) { Microsoft Personal Web-Server 4.x (PWS) { Microsoft Internet Information Server 3.x/4.x

{ Netscape FastTrack und Enterprise Server 3.x (Windows NT und Unix) { StarNine WebSTAR 3.x (Macintosh)

viele weitere Servlet-Engines bzw. kombinierte Web-Server mit Servlet-Engines: { Java Webserver (http://www.sun.com/software/jwebserver/index.html)

{ Jetty (http://www.mortbay.com/software/Jetty.html)

4Oder man verwendet das JavaServer Web Development Kit (JSWDK); dies beinhaltet dann auch eine Referenzimplementation fur JavaServer-Pages

Hauptseminar:

Servlets und JavaServer-Pages Seite 7 von 22 Peter Koller

14.02.2000

(8)

{ Jigsaw (http://www.w3.org/Jigsaw/) { jo! (http://www.tagtraum.com/)

{ ServletExec (http://www.servletexec.com/

{ Websphere (http://www.ibm.com/software/webservers/) { und viele weitere, ...

Die Programmbeispiele in den nachsten Abschnitten habe ich mit dem JSWDK WebServer getestet. Dies ist ein einfacher Web-Server mit Servlet-Engine. Zum Testen der Beispiele genugt dies vollkommen. In der aktuellen Version 1.0.1 des JSWDK werden das Java Servlet API 2.1 unterstutzt. Die aktuelle Servlet API ist zwar schon 2.2, aber von Sun gibt es noch keine Referenzimplementation einer Servlet-Engine fur diese Version. Daher sind alle meine Programmbeispiele API 2.1 konform. Mochte man Servlets fur die API 2.2 schreiben, dann kann man auf Tomcat (http://java.sun.com/products/jsp/tomcat/), die kombinierte Servlet 2.2 und JavaServer-Pages 1.1 Referenzimplementation ausweichen.

5 Programmierung

5.1 Grundlagen

Servlets werden durch die Schnittstelle javax.servlet.Servlet de niert. Es ist also keine Oberklasse notwendig, um Servlets zu erstellen, auch wenn dies wahrscheinlich die Regel sein wird.

Im folgenden stelle ich alle Methoden dieser Schnittstelle kurz dar:

void init(ServletConfig config)

Diese Methode dient zur Initialisierung eines Servlets. Sobald die Servlet-Engine eine Instanz des Servlets erstellt, z. B. weil das Servlet das erste Mal angefordert wurde, dann wird der Konstruktor ohne Argumente, sowie diese init(ServletConfig config)-Methode aufgerufen. Daher sollten in dieser Methode nur einmalige Setup- Routinen erledigt werden und das ServletConfig Objekt gefullt werden, damit es dann spater mit getServletConfig() ausgelesen werden kann.

ServletConfig getServletConfig()

Diese Methode dient nur dazu das ServletConfig-Objekt zu bekommen.

void service(ServletRequest req, ServletResponse, res)

Die service-Methode ist das Herz eines jeden Servlets. Sie wird jedesmal aufgerufen, wenn eine Anfrage fur das Servlet eintri t. Die service-Methode kann von mehrern Threads gleichzeitig aufgerufen werden. Daher ist eine Thread-sichere Implementierung notwendig oder es muss sichergestellt werden, dass diese Methode nicht gleichzeitig aufgerufen werden kann.

String getServletInfo()

Diese Methode soll Informationen uber das Servlet zuruckgeben (z. B. Servletnamen, Version, Autor, Copyright, etc.). Wenn die Methode implementiert wird, kann man mit Administrations-Tools diese Informationen uber das Servlet abfragen.

void destroy()

Hier ist der ideale Platz um Aufraumarbeiten durchzufuhren (z.B. Datenbankverbin- dungen schliessen). Die destroy-Methode wird wie auch die init-Methode im Leben eines Servlets nur einmal aufgerufen.

Hauptseminar:

Servlets und JavaServer-Pages Seite 8 von 22 Peter Koller

14.02.2000

(9)

5.2 Beispiel 1: HelloWorld-Servlet

HelloWorld.java 1: import java.io.*;

2: import java.util.Date;

3: import javax.servlet.*;

4: 5: public class HelloWorld extends javax.servlet.GenericServlet { 6: public void service(ServletRequest req, ServletResponse res) 7: throws ServletException, IOException {

8: res.setContentType("text/html");

9: PrintWriter out = res.getWriter();

10: Date d = new Date();

11: out.println("<html><head></head><body>" +

12: "Hello World am " + d.toString() + "</body></html>");

13: } 14: }

5.3 Ubersetzen, installieren und testen

Neben der Beachtung der Hinweise des JSDK ist es fur das Programmbeispiel notwendig, den Klassenpfad zu erweitern, damit die Klassen der Servlet API gefunden werden. Mit javac kann eine Servlet .java-Datei genau wie jedes andere Java-Programm auch in eine .class-Datei ubersetzt werden. Eventuell ist eine Kon gurationsdatei namens servlet.properties⁵ anzupassen. Diese Kon gurationsdatei enthalt zum einen die Initialisierungsargumente der Servlets (diese konnen vom Servlet mit der Methode getInitParameter(String) abgefragt werden). Und zum anderen kann hier ein eindeutiger Name fur das Servlet vergeben werden, der dann ein Teil der URL wird unter dem das Servlet aufrufbar ist.

Die Syntax fur die Eintrage in der Datei servlets.properties ist beim JSWDK Web-Server 1.0.1 wie folgt:

Servletname.code=Klassenname Servletname.initargs=arg1=wert1, ...

Nachdem die Kon gurationsdatei eventuell angepa t wurde, der Web-Server und die Servlet-Engine gestartet wurden, kann das Servlet unter der URL

http://ServerAddr:Port/ServletDir/HelloWorld ausgefuhrt werden. Das Mapping des Servletverzeichnisses kann man in den Kon gurationsdateien des JSWDK einsehen und andern. In der Datei servlet.properties war beim JSWDK keine Anderung notwendig, da das Servlet unter demselben Namen wie die Klassendatei aufgerufen wird. Die Servlet-Engine fand das Servlet dann auch ohne Eintragung in servlet.properties. Abhangig von der Servlet-Engine kann sich das auch anders verhalten.

5Diese Datei kann bei anderen Servlet-Engines auch anders hei en.

(10)

6 Die Servlet-Umgebung

6.1 Zugri auf die Initialisierungsparameter mit ServletCon g

Die Schnittstelle ServletConfig dient dem Zugri auf die Initialisierungsparameter aus der Kon gurationsdatei servlet.properties. Des Weiteren dient sie auch zum Zuruckliefern eines ServletContext-Objekts (siehe auch den nachsten Abschnitt). Die Schnittstelle dekla-riert dabei u. a. die folgenden Methoden:

String getInitParameter(String name)

liest einen Initialisierungsparameter aus der Datei servlet.properties Enumeration getInitParameterNames()

liefert eine Aufzahlung aller Parameternamen zuruck ServletContext getServletContext()

liefert ein ServletContext-Objekt

Alle Servlet-Engines mussen ein ServletConfig-Objekt zur Verfugung stellen. Zusatzlich sind alle Methoden der Schnittstelle ServletConfig in der Klasse GenericServlet implementiert, um den Zugri auf Initialisierungsparameter und die Umgebung des Servlets zu vereinfachen.

6.2 Schnittstelle zur Servlet-Engine mit ServletContext

Um auf die Umgebung, im weiteren als Kontext bezeichnet, in der ein Servlet ausgefuhrt wird zugreifen zu konnen, muss die Schnittstelle zur Servlet-Engine namens ServletContext, implementiert sein.

Der Kontext ist abhangig von den virtuellen Hosts und der URI eines Servlets. Fur jeden virtuellen Host gibt es mindestens einen Kontext. Abhangig von der URI eines Servlets kann es zusatzlich fur einen virtuellen Host unterschiedliche Kontexte geben.

SevletContext bietet Dienste an, um auf Server-Ressourcen, wie beispielsweise Dateien, Servlets, JavaServer-Pages und CGI-Skripte zuzugreifen. Ein zentraler Logdienst ist vorhan-den, um Meldungen eines Servlets in einer zentralen Logdatei zu protokollieren.

6.3 Anfrageobjekt ServletRequest

Das ServletRequest-Objekt bietet Methoden, um auf die Elemente einer Anfrage zuzugreifen.

Mit den Methoden

String[] getParameterValues(String name) Enumeration getParameterNames()

kann auf die per GET und POST ubermittelten Name-/Wert-Paare zugegri en werden.

Zum Lesen von zumeist binaren Daten wie z. B. beim Ubertragen mit FTP stehen mit ServletInputStream getInputStream() und Reader getReader() entsprechende Metho- den zur Verfugung, um auf diese Daten mittels eines Datenstroms oder einem Reader zuzu-greifen. Wobei ein Reader hierbei den Vorteil besitzt auch Zeichensatzkodierungen korrekt zu behandeln.

Hauptseminar:

Servlets und JavaServer-Pages Seite 10 von 22 Peter Koller 14.02.2000

(11)

6.4 Antwortobjekt ServletResponse

Mit dem ServletResponse-Objekt steht das Gegenstuck zum ServletRequest-Objekt be- reit. Hier werden Methoden angeboten, um eine Antwort zu erstellen.

Mit den Methoden

setContentLength(int length) setContentType(String type)

kann eine Antwort nach Lange und Inhaltstyp naher spezi ziert werden. Die

Nachrichtenlange ist hierbei optional. Der Nachrichtentyp muss aber gesetzt werden, wenn nicht der Standard-wert text/plain angenommen werden soll.

Um die Antwort selbst zu senden bedient man sich am besten eines Writers den man mit getWriter() anfordern kann. Naturlich steht auch hier als Alternative ein Datenstrom mit der Methode ServletOutputStream getOutputStream() zur Verfugung, wobei aber ersterer Moglichkeit der Vorzug zu geben ist.

7 Features

7.1 Cookies

Bei HTTP gibt es im Allgemeinen das Problem, dass es ein zustandsloses Protokoll ist. Es ist aber oftmals notwendig zwei oder mehr aufeinanderfolgende Anforderungen einem Benutzer eindeutig zuzuordnen. Hierunter fallen beispielsweise Web-Shop-Anwendungen, Auskunftssy- steme, etc. Die IP-Adresse des Clients hilft dabei auch nicht weiter, da sich mehrere Benutzer eine IP-Adresse teilen konnen (IP-Masquerading, dynamische IP-Adressen-Vergabe, Multi-User-Rechner).

Die Losung bieten Cookies, mit denen Daten auf der Seite des Benutzers (clientside) abge-legt werden konnen. Auf Anweisung eines Web-Servers speichert der Client (z. B. ein Web- Browser) Cookies und schickt sie bei jedem weiteren Aufruf einer Seite dieses Servers zuruck.

Im folgenden mochte ich keine vollstandige Au istung aller Methoden darlegen, die das Serv- let API zur Unterstutzung von Cookies bietet. Ich mochte vielmehr dem Programmierer die wichtigsten Methoden an die Hand geben, um einen schnellen Einstieg in dieses Thema zu nden.

void addCookie(Cookie aCookie) der Schnittstelle HttpServletResponse

Die Methode Cookie[] getCookies() der Schnittstelle HttpServletRequest liefert ein Array aller vom Client gesetzten Cookies.

Mit der Klasse javax.servlet.http.Cookie bietet die Servlet API eine Datenstruktur mit entsprechenden get- und set-Methoden und unter anderem die folgenden Moglich- keiten:

{ Mit Cookie(String name, String value) kann ein Cookie instanziert und mit einem Name-/Wert-Paar initialisiert werden.

{ Cookies konnen mit Kommentaren versehen werden.

{ Die Lebensdauer kann mit void setMaxAge(int expiry) beein u t werden. Man beachte, dass ohne Aufruf dieser Methode ein Cookie eine Browser-Sitzung nicht uberlebt.

Hauptseminar:

(12)

{ Ein Sicherheits-Flag kann gesetzt werden. Dann durfen diese Cookies nur uber eine sichere Verbindung an den Server zuruckgesendet werden.

7.2 Session-Management

7.2.1 Grundlagen

Eine Session ist durch eine zusammenhangende Abfolge von Anfragen und Antworten zwi-schen Client und Server gekennzeichnet. Dies geschieht durch das Mitschicken einer Identi ka-tion, im folgenden Session-ID genannt. Durch diese Session-ID kann man eine Anfrage einem Benutzer eindeutig zuordnen. Dieses allein konnten wird auch schon im vorigen Abschnitt mit Cookies. Doch das Session-Management besteht aus weit mehr als nur dem alleinigem Mitschicken einer Session-ID, wie wir spater noch sehen werden.

Grundsatzlich gibt es zwei Moglichkeiten eine Session-ID einem Benutzer zu schicken und sie wieder zuruckzuerhalten:

1. Cookies

2. Umschreiben von URLs (URL-Rewriting)

Beide Moglichkeiten werden von der Servlet API unterstutzt und haben ihre Vor- und Nach- teile. Bei Cookies muss gepruft werden, ob der Client Cookies unterstutzt. Da dies nicht immer der Fall sein muss und weil Cookies auch in Web-Browsern verboten werden konnen,

kann es sein, dass mit dieser Moglichkeit kein Session-Management betrieben werden kann.

Dann muss man auf die zweite Moglichkeit, die des URL-Rewriting ausweichen. Diese Me-thode ist zwar weniger elegant zu implementieren als erstere, bietet aber den Vorteil, dass sie mit allen Web-Browsern und selbst bei ausgeschalteten Cookies funktioniert.

Nachteilig wirkt sich aus, dass wie der Name schon sagt, jeder URL umgeschrieben werden muss und daher die HTML-Seiten dynamisch generiert werden mussen.

Auch hier mochte ich wieder nur die grundlegensten Methoden vorstellen, mit denen man ein Session-Management implementieren kann:

javax.servlet.http.HttpSession { boolean isNew()

Diese Methode liefert true, wenn ein neues Session-Objekt erzeugt werden mu te. { Eigenschaften, wie Erstellungsdatum, letzter Zugri , u. a.

HttpSession getSession()

Diese Methode von HttpServletRequest liefert die HttpSession einer Anfrage.

String encodeURL(String url)

Diese Methode von HttpServletResponse kodiert die Session-ID in der angegebenen URL.

Mit diesem Wissen kann man schon recht einfach eine Session-ID zwischen Client und Server hin- und herschicken. Doch was ein richtiges Session-Management ausmacht ist die Ver- knupfung von Sessions mit Objekten. Dabei wird eine Beziehung zwischen einer Session- ID, die der Client mit welcher Methode auch immer mitschickt und mit einem Objekt auf der Seite des Servers hergestellt.

HttpSession bietet dazu die folgenden Methoden:

Hauptseminar:

(13)

Object getValue(String name) String[] getValueNames()

putValue(String name, Object value) removeValue(String name)

7.2.2 Beispiel 2: Foo-Bar Shop

Anhand eines Mini-Shops, den ich Foo-Bar Shop ⁶ genannt habe, mochte ich das Session-Management demonstrieren. Der Mini-Shop hat dabei nur eine sehr begrenzte Anzahl von Funktionen, damit man sich mit den wichtigen Teilen fur diesen Abschnitt auseindersetzen kann und nicht von Funktionsvielfalt geblendet wird:

Hinzufugen von Waren in einen Warenkorb (jeder Benutzer hat davon genau einen).

Es gibt lediglich zwei Artikel, namlich Foo und Bar.

Die Seite, die den Warenkorb anzeigt ist identisch mit der Seite mit der Waren in den Warenkorb hinzugefugt werden konnen.

Eine Bestellen-Funktion ist vorhanden. Diese loscht aber lediglich den Warenkorb.

FooBarShop.java 1: import java.io.*;

2: import javax.servlet.*;

3: import javax.servlet.http.*;

4: 5: public class FooBarShop extends HttpServlet {

6: protected void doPost(HttpServletRequest req, HttpServletResponse res) 7: throws ServletException, IOException {

8: String msg;

9: Integer foo, bar;

10: 11: HttpSession session = req.getSession(true);

12: if (session.isNew()) { 13: foo = new Integer(0);

14: bar = new Integer(0);

15: } 16: else {

17: foo = (Integer)session.getValue("FooBarShop.foo");

18: bar = (Integer)session.getValue("FooBarShop.bar");

19: if (foo == null) foo = new Integer(0);

20: if (bar == null) bar = new Integer(0);

21: }

22: 23: if (req.getParameter("addFoo") != null) { 24: foo = new Integer(foo.intValue() + 1);

25: session.putValue("FooBarShop.foo", foo);

26: msg = "Artikel ’Foo’ hinzugefügt.";

6Die Namen Foo und Bar werden hau g als Name fur Variablen oder zu Testzwecken verwendet. Wer sich mehr dafur interessiert mochte bitte in den entsprechenden Referenzen [9] nachsehen.

Hauptseminar:

(14)

27: }

28: else if (req.getParameter("addBar") != null) { 29: bar = new Integer(bar.intValue() + 1);

30: session.putValue("FooBarShop.bar", bar);

31: msg = "Artikel ’Bar’ hinzugefügt.";

32: }

33: else if (req.getParameter("buy") != null) {

34: msg = foo.intValue() + " Foo und " + bar.intValue() + " Bar bestellt.";

35: foo = new Integer(0);

36: bar = new Integer(0);

37: session.invalidate();

38: } 39: else

40: msg = "Aufruf per GET";

41: printForm(msg, foo.intValue(), bar.intValue(), req, res);

42: }

43: 44: protected void doGet(HttpServletRequest req, HttpServletResponse res) 45: throws ServletException, IOException {

46: doPost(req, res);

47: }

48: 49: void printForm(String msg, int mengeFoo, int mengeBar,

50: HttpServletRequest req, HttpServletResponse res) 51: throws ServletException, IOException {

52: String encodedURL = res.encodeURL(req.getRequestURI());

53: res.setContentType("text/html");

54: res.setHeader("pragma", "no-cache");

55: PrintWriter out = res.getWriter();

56: 57: out.print("<html><head></head><body>");

58: out.print("Status: " + msg + "<p>\n");

59: out.print("Encoded URL: " + encodedURL);

60: 61: out.print("<form method=post action=" + encodedURL + ">");

62: out.print("<table border=1 cellpadding=5>\n");

63: out.print("<tr><td>Menge</td><td>Artikel</td><td> </td></tr>\n");

64: 65: out.print("<tr><td>" + mengeFoo + "</td><td>Foo</td><td>\n");

66: out.print("<input type=submit name=addFoo value= + >\n");

67: out.print("</td></tr>\n");

68: 69: out.print("<tr><td>" + mengeBar + "</td><td>Bar</td><td>");

70: out.print("<input type=submit name=addBar value= + >");

71: out.print("</td></tr>\n");

72: 73: out.print("</table><p>\n");

74: out.print("<input type=submit name=buy value=Bestellen>\n");

75: out.print("</form></body></html>");

76: } 77: }

Zeilen 1 bis 3 importieren einige Pakete, die Klassen beinhalten die von fast jedem

Hauptseminar:

(15)

Servlet benotigt werden.

Die Servlet-Klasse wird in Zeile 5 deklariert. Fur ein protokollabhangiges HTTP- Servlet wird am besten die Klasse HttpServlet verwendet.

In den Zeilen 6 bis 42 wird die HttpServlet doGet-Methode uberschrieben.

Die Zeilen 8 bis 9 deklarieren Variablen fur eine Statusnachricht und die Artikelmengen von Foo und Bar.

In Zeile 11 wird mit req.getSession(true) die Session geholt bzw. wegen dem Para- meter true eine neue Session erstellt, falls keine vorhanden war.

Die Zeilen 12 bis 15 prufen ob die Session neu war und initialisieren gegebenenfalls die Artikelmengen.

In den Zeilen 16 bis 21 wird versucht die Artikelmengen durch die an die Session gebundenen Objekte zu erhalten.

Die Zeilen 23 bis 40 verarbeiten die unterschiedlichen Ereignisse uber die das Shop- Formular aufgerufen werden kann.

Die Zeilen 23, 38 und 33 prufen ob das Formular mit einem der Formularbuttons ab- geschickt wurde.

Die Zeilen 23 bis 27 zeigen das Hinzufugen des Artikels Foo und speziell in Zeile 25 das Binden eines Objekts an eine Session.

Zeile 37 zeigt wie eine Session fur ungultigt erklart werden kann (im Beispiel ist hier der Shopping-Vorgang beendet).

Zeile 41 ruft die selbst de nierte Methode printForm(...), um die HTML-Seite auszu- geben. Damit auch bei einer GET-Anfrage (wie in den Zeilen 44 bis 47 gezeigt) dasselbe Formular ausgegeben wird, habe ich diese Routine in eine eigene Methode verpackt.

In den Zeilen 49 bis 76 wird die Methode printForm(...) implementiert.

Wichtig ist in Zeile 52 das Kodieren der Session-ID in der URL mittels encodeURL, damit der Shop auch funktioniert, falls keine Cookies verfugbar sind.

(16)

8 Server-Side Includes mit Servlets

Mit Server-Side Include (SSI) ist es moglich Dateien, Programme und Systemvariablen in HTML-Dokumente einzubinden. Abhangig von der Kon guration des Web-Servers werden HTML-Dokumente mit SSI zumeist an der Endung .shtml erkannt. Solche Dateien schickt ein Web-Server dann nicht einfach passiv an den Client, sondern parst sie erst und fugt dann den Inhalt der Datei, die Ausgabe eines Programms oder den Wert einer Systemvariablen ein.

Beispiele:

<!--

#echo var="HTTP_USER_AGENT"-->

SSI kann man auch in Verbindung mit Servlets verwenden. Abhangig vom Server kann man Servlets wie folgt in ein HTML-Dokument einbinden:

<servlet name=ServletName code=ServletCode.class initParam1=initArg1 initParam2=initArg2 ...> <param name=param1 value=val1> ...

</servlet>

(17)

9 Bewertung von Servlets

Wie man im Abschnitt Voraussetzungen gesehen hat, sind Servlet-Engines bereits jetzt schon fur eine Vielzahl von Web-Servern auf unterschiedlichsten Betriebssystemen verfugbar. Diese Server- und Plattformunabhangigkeit ist ein Verdienst der Sprache Java, der sich auch auf das Servlet-Konzept ubertragen hat.

Auch ist dank Java zur Programmierung von Servlets keine neue Programmiersprache zu erlernen, da das Servlet API eine Standard Java-Erweiterung ist. Zudem ist man gezwungen auf sichere Konzepte, wie Typsicherheit und Exception-Handlung zuruckzugreifen und die entwickelten Servlets haben naturlich auch genau diese Stabilitat inbegri en.

Die E zienz ist ein weiterer wichtiger Punkt. Im Gegensatz zu anderen Konzepten verwen-den Servlets Threads anstatt schwergewichtigen Prozessen. Prozesswechsel des Betriebssy- stems, die im Sinne von Rechenzeit teuer sind, entfallen. Dies au ert sich naturlich auch in der Geschwindigkeit mit der ein Nutzer eine Antwort auf seine Anfrage bekommt. Hin-zu kommt eine Geschwindigkeitssteigerung dadurch, dass Servlets zumeist im Prozess der Servlet-Engine ausgefuhrt werden. Sollte es einmal trotzdem nicht gewunscht sein Servlets im selben Prozessraum auszufuhren, dann ist jederzeit eine Prozesstrennung mit CORBA oder RMI moglich.

Da Servlets protokollunabhangig sind, sind sie auch fur den Einsatz in anderen Anfrage/

Antwort-basierten Systemen geeignet.

Mir personlich fehlte lediglich die Unterstutzung des URL-Rewriting in der Referenzimple- mentation von Sun zum Servlet API 2.1. Ein Ausweichen auf eine andere Servlet-Engine gleicht dieses Manko aber wieder aus.

(18)

Teil II

JavaServer-Pages

10 Einfuhrung in JavaServer-Pages

JavaServer-Pages bieten eine einfache und trotzdem sehr machtige Moglichkeit HTML-Seiten dynamisch zu erzeugen. Auch die Einbindung von Java-Beans ist moglich und man kann dadurch z. B. auf eine Datenbank oder einen Mail-Server zugreifen. Mit JavaServer-Pages kann auf das komplette Angebot des Java APIs zugegri en werden und damit steht der gesamte Java-Sprachumfang zur Verfugung.

11 Wie funktioniert das?

Alle JavaServer-Pages werden nicht direkt, sondern uber ein JspServlet angesprochen.

Des-halb muss in der Datei servlet.properties eine Zuordnung von Dateien mit der Endung .jsp zum JspServlet eingerichtet werden. Beim JSWDK Web-Server sieht das wie folgt aus:

jsp.code=com.sun.jsp.runtime.JspServlet jsp.initparams=keepgenerated=true

Die folgende Abbildung zeigt was passiert, wenn eine .jsp-Datei aufgerufen wird:

Abbildung 3: JavaServer-Pages-Kommunikation

Zuerst wird die HTTP-Anfrage vom Web-Browser zum JspServlet durchgereicht.

Das JspServlet pruft dann, ob zur .jsp-Seite schon ein entsprechendes Servlet existiert.

Ist dies nicht der Fall, wie es beim ersten Aufruf einer .jsp-Seite sein wird, dann erzeugt das JspServlet eine .java-Datei und ubersetzt diese in die entsprechende Klassendatei. Nun wird die Klasse instantiiert und initialisiert. Das Servlet fur die .jsp-Seite steht nun zur Verfugung und der HttpServletRequest wird an das Servlet weitergereicht. Dieses schickt

Hauptseminar:

(19)

dann seine HttpServletResponse zuruck zum JspServlet und die HTTP-Antwort wird weiter durchgereicht bis zum Web-Browser.

12 Programmierung

12.1 Grundlagen

JavaServer-Pages erstellt man dadurch, dass man in <% %>-Markierungen Java-Code in HTML einbindet und die Datei mit der Endung .jsp benennt. Diese Einbindung von Code bezeich-net man als Scriptlets. Dabei steht der gesamte Java-Sprachumfang zur Verfugung.

Alle Variablen sind fur alle Scriptlets derselben .jsp-Datei sichtbar.

Methoden werden in die ublichen HTML-Tags <script> und </script> eingebettet, wobei man aber angeben muss, dass das Script auf der Serverseite (serverside) lauft. Dies macht man mit dem Attribut/Werte-Paar runat=server. Ein Beispiel zur De nition einer Methode:

public Date currentDate() { return new Date();

</script> }

Obige Methode funktioniert aber nur, wenn zuvor mit einer Direktive das Paket java.util.Date importiert wurde:

<%@ page import="java.util.Date" %>

12.2 Beispiel 3: HelloWorld JavaServer-Page

Analog zum HelloWorld-Servlet gebe ich hier das Beispiel mit derselben Funktionalitat als JavaServer-Page:

HelloWorld.jsp

1: <%@ page import = "java.util.Date" %>

2: <html>

3: <head><title>Hello World</title></head>

4: <body>

5: Hello World mit JSP am 6: <% Date d = new Date(); %>

7: <%= d.toString() %>

8: </body>

9: </html>

(20)

13 Bewertung von JavaServer-Pages

Wie auch schon in der Bewertung von Servlets diskutiert sind JavaServer-Pages auch un- abhangig vom Betriebssystem und Server-Software.

Die Koexistenz von JavaServer-Pages mit Servlets sehe ich dadurch bedingt, dass kleine Systeme bei denen Scriptlets in HTML eingebettet sind, einfacher anzupassen sind, als Sy-steme zu bauen die HTML durch Programme generieren. Besonders durch die Kombination von JavaServer-Pages, Servlets und Beans steht ein umfangreicher Baukasten zur Verfugung, um die Inhalterstellung von der Inhaltdarstellung zu trennen.

Lediglich die momentan noch laufenden Syntaxanderungen an den verschiedenen JavaServer-Pages Spezi kationen sind mir negativ aufgefallen.

(21)

Glossar

API . . . Application Programming Interface CGI . . . . . . Common Gateway Interface CORBA . . . . . . Common Object Request Broker Architecture FTP . . . . . . File Transfer Protocol HTML . . . . . . Hypertext Markup Language HTTP . . . . . . Hypertext Transfer Protocol IP . . . .Internet Protocol ISAPI . . . Internet Server Application Programming Interface NCSA . . . National Center for Supercomputing Applications NSAPI . . . . . . Netscape Server Application Programming Interface RMI . . . . . . Remote Method Invocation SSI . . . . . . .Server-Side Include URI . . . . . . Uniform Resource Identi er URL . . . Uniform Resource Locator

(22)

Referenzen

[1] Sun microsystems: Java Servlet API; verfugbar uber http://java.sun.com/products/servlet/, 2000

[2] Sun microsystems: JavaServer-Pages Technology; verfugbar uber http://www.javasoft.com/products/jsp/, 2000

[3] P. Ro bach, H. Schreiber: Java Server und Servlets; Addison-Wesley, 1999 [4] S. Zeiger: Servlet Essentials 1.3.5; verfugbar uber

http://www.novocode.com/doc/servlet-essentials/, 2000

[5] R. Orfali, D. Harkey, J. Edwards: Abenteuer Client/Server; Addison-Wesley, 1997 [6] F. Hajji: Perl: Einfuhrung, Anwendung, Referenz; Addison-Wesley, 1998

[7] S. Oaks, H. Wong: Java Threads; O’Reilly, 1999 [8] SSI Tutorial; verfugbar uber

http://www.useforesite.com/tut ssi.shtml, 2000 [9] T. Irlbeck: Computer-Englisch; dtv, 1998

[10] Sun microsystems: Java Servlet API Industry Momentum; verfugbar uber http://java.sun.com/products/servlet/industry.html, 2000 [11] Sun microsystems: Servlets in the Real-World; verfugbar uber

http://java.sun.com/products/servlet/industry.html#servlets, 2000 [12] Sun microsystems: The Source For Java Technology; verfugbar

uber http://www.javasoft.com/, 2000

[13] D. Flanagan, J. Farley, W. Crawford, K. Magnusson: Java Enterprise in a Nutshell, O’Reilly, 1999