Liebe Leserin, lieber Leser, - bilder.buecher.de · Liebe Leserin, lieber Leser, ich freue mich,...

Liebe Leserin, lieber Leser,

ich freue mich, dass Sie sich für ein Galileo Computing-Buch entschieden haben. Unsere Einsteigertitel sind besonders für Leser geeignet, die sowohl inhaltlich als auch didaktisch professionell gemachte Fachliteratur schätzen und sich nicht mit »schnellen« Produkten zufrieden geben.

Dieses Buch befasst sich mit der aktuellen Version 2.0 der JavaServer Pages. Und es hat sich Einiges getan. Das Buch schafft den Spagat zwischen der Beschreibung bisher üblicher Verfahren und der Behandlung der vollständig neuen Möglichkei-ten von 2.0. Die Materie ist komplex; unser Einstieg hilft, JSP 2.0 zu verstehen und effektiv anzuwenden.

Das Buch wurde sorgfältig geprüft und die Beispiele getestet. Doch kein noch so gutes EDV-Buch ist ohne Fehler. Lassen Sie uns wissen, wenn etwas nicht so funk-tioniert, wie Sie es erwarten. Über Anregungen und Lob freuen wir uns natürlich auch!

Jetzt wünsche ich viel Freude beim Lesen!

Judith Stevens-LemoineLektorat Galileo Computing

[email protected]

Galileo Press • Gartenstraße 24 • 53229 Bonn

1 Java Server Pages im Überblick ............... 17

2 Einrichten einer Entwicklungsumgebung 61

3 Entwicklung dynamischer Webseiten mit JSP 2.0 .............................................. 85

4 Einrichten dynamischer Webanwendungen .................................. 389

5 Erweiterungen und fortgeschrittene Lösungen ................................................. 415

6 Kurzreferenz Java Server Pages 2.0 .......... 479

Auf einen Blick

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISBN 3-89842-360-3

© Galileo Press GmbH, Bonn 20041. Auflage 2004

Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbe-sondere das Recht der Übersetzung, des Vortrags, der Reproduktion, der Vervielfältigung auf fotomecha-nischem oder anderen Wegen und der Speicherung in elektronischen Medien.

Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor, Herausgeber oder Übersetzer für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen.

Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmun-gen unterliegen.

Lektorat Judith Stevens-LemoineKorrektorat Claudia Falk, Dr. Rainer Noske, BonnEinbandgestaltung Barbara Thoben, KölnHerstellung Iris WarkusTitelbild zefa visual mediaSatz Typographie & Computer, KrefeldDruck und Bindung Koninklijke Wöhrmann, Zutphen, Niederlande

Der Name Galileo Press geht auf den italienischen Mathematiker und Philosophen Galileo Galilei (1564–1642) zurück. Er gilt als Gründungs-figur der neuzeitlichen Wissenschaft und wurde berühmt als Verfechter des modernen, heliozentrischen Weltbilds. Legendär ist sein Ausspruch Eppur se muove (Und sie bewegt sich doch). Das Emblem von Galileo Press ist der Jupiter, umkreist von den vier Galileischen Monden. Galilei entdeckte die nach ihm benannten Monde 1610.

Inhalt 5

1.1 Von statischen zu dynamischen Webseiten .......................................... 19

1.2 Die Basis: das HTTP-Protokoll ............................................................... 201.2.1 Das Anfrage/Antwort-Modell ................................................... 201.2.2 Verbindungslos ........................................................................ 211.2.3 Ohne Zustand .......................................................................... 221.2.4 Aufbau von HTTP-Nachrichten ................................................. 221.2.5 Das Format der Anfrage ........................................................... 231.2.6 Das Format der Antwort .......................................................... 261.2.7 Beobachtung der HTTP-Kommunikation ................................... 29

1.3 JSP im Vergleich zu älteren Serveranwendungen .................................. 291.3.1 Common Gateway Interface ..................................................... 301.3.2 Servererweiterungen ................................................................ 311.3.3 Java-Servlets ............................................................................ 311.3.4 Active Server Pages .................................................................. 351.3.5 Von Servlets zu JavaServer Pages .............................................. 361.3.6 Arbeitsteilung zwischen Programmierung und Seitendesign ...... 371.3.7 Was spricht für JSP? ................................................................. 38

1.4 Anwendungsgebiete und -modelle ....................................................... 391.4.1 JSP oder DHTML? .................................................................... 391.4.2 Das Designmodell Model-View-Controller ............................... 39

1.5 Von JSP 1.2 nach JSP 2 ......................................................................... 411.5.1 Plattform und Servlet-API ......................................................... 421.5.2 JSTL und andere Tag-Bibliotheken ............................................ 421.5.3 Expression Language ................................................................ 421.5.4 Simple Tag-Handler .................................................................. 431.5.5 Tag-Dateien ............................................................................. 431.5.6 JSP als XML-Dokument und XML-Views ................................... 431.5.7 Neue Standardaktionen und dynamische Attribute ................... 44

1.6 Allgemeine Merkmale von JSP .............................................................. 441.6.1 Laufzeitumgebung für JSP ........................................................ 441.6.2 Einbindung in J2EE ................................................................... 451.6.3 Aufbau einer JSP ...................................................................... 481.6.4 Übersetzungsphase .................................................................. 491.6.5 Die JSP-Implementierungsklasse ............................................... 50

Inhalt

Vorwort 15

1 JavaServer Pages im Überblick 19

6 Inhalt

1.6.6 Ausführungsphase .................................................................... 511.6.7 Quellcode des Beispiels ........................................................... 55

2.1 Werkzeuge für Java ............................................................................... 63

2.2 Webserver und JSP-Container .............................................................. 642.2.1 Apache Tomcat 5.0 installieren ................................................ 652.2.2 Einrichten der Umgebung ........................................................ 662.2.3 Serverbetrieb ........................................................................... 682.2.4 Serverkonfigurierung: server.xml .............................................. 722.2.5 Webanwendungen .................................................................. 772.2.6 Gemeinsame Bibliotheken ....................................................... 82

2.3 Einrichten der Beispiele ........................................................................ 82

2.4 Entwicklungswerkzeuge für JSP ........................................................... 83

3.1 JSPs und JSP-Dokumente ..................................................................... 873.1.1 Standardsyntax und XML-Syntax .............................................. 87

3.2 Syntaktische Bestandteile einer JSP ..................................................... 883.2.1 JSP-Elemente und Template-Daten .......................................... 883.2.2 Elemente und Attribute ........................................................... 903.2.3 EL-Ausdrücke .......................................................................... 913.2.4 Kommentare ........................................................................... 913.2.5 Sonderzeichen und Escape-Sequenzen ..................................... 933.2.6 Relative URLs ........................................................................... 943.2.7 Hinweis zu den Dateinamen .................................................... 94

3.3 Direktiven an den JSP-Container .......................................................... 953.3.1 Die Direktive page ................................................................... 953.3.2 Die Direktive include ............................................................... 1053.3.3 Alternative Import-Mechanismen ............................................. 1093.3.4 Die Direktive taglib .................................................................. 1093.3.5 Hinweise zur Schreibweise bei Direktiven ................................ 114

3.4 Skriptelemente ..................................................................................... 1143.4.1 Java-Code in JSPs ..................................................................... 1153.4.2 Deklarationen .......................................................................... 1163.4.3 Skriptlets ................................................................................. 1203.4.4 Ausdrücke ............................................................................... 1303.4.5 Skriptlösung für ein Web-Tagebuch ......................................... 133

3.5 Zugriff auf serverseitige Objekte .......................................................... 1373.5.1 Objekte und Variablen ............................................................. 1383.5.2 Implizite Objekte ..................................................................... 139

2 Einrichten einer Entwicklungsumgebung 63

3 Entwicklung dynamischer Webseiten mit JSP 2.087

Inhalt 7

3.6 Arbeit mit impliziten Objekten ............................................................. 1413.6.1 Request .................................................................................... 1413.6.2 Response ................................................................................. 1423.6.3 PageContext ............................................................................ 1433.6.4 Session ..................................................................................... 1433.6.5 Application .............................................................................. 1443.6.6 Out .......................................................................................... 1463.6.7 Config ...................................................................................... 1483.6.8 Page ......................................................................................... 1483.6.9 Exception ................................................................................. 148

3.7 Expression Language ............................................................................. 1483.7.1 Einfacher als Skriptausdrücke ................................................... 1493.7.2 Die API-Erweiterung für EL ...................................................... 1503.7.3 Einsatz von EL-Ausdrücken ....................................................... 1513.7.4 Implizite Objekte in EL-Ausdrücken ......................................... 1523.7.5 Hinweise zur Syntax von EL ...................................................... 1543.7.6 Funktionen .............................................................................. 157

3.8 Einsatz von Standardaktionen ............................................................... 1603.8.1 Allgemeine Syntax von Aktionen .............................................. 1613.8.2 Attributwerte ........................................................................... 1623.8.3 Typumwandlungen .................................................................. 1623.8.4 Ressourcen einfügen – <jsp:include> ........................................ 1623.8.5 Weiterleiten einer Anfrage – <jsp:forward> .............................. 1693.8.6 Parameterübergabe – <jsp:param> ........................................... 1723.8.7 Komponenten einbetten – <jsp:plugin> .................................... 1733.8.8 Parametergruppen – <jsp:params> ........................................... 1783.8.9 Notausgang – <jsp:fallback> ..................................................... 1783.8.10 Elemente erzeugen – <jsp:element> ......................................... 1783.8.11 Attribute erzeugen – <jsp:attribute> ......................................... 1803.8.12 Rumpf einfügen – <jsp:body> ................................................... 1823.8.13 Fragmente aufrufen – <jsp:invoke> ........................................... 1833.8.14 Template-Text einfügen – <jsp:text> ......................................... 1853.8.15 Rumpf ausführen – <jsp:doBody> ............................................. 1853.8.16 Nutzen von JavaBean-Komponenten ........................................ 1863.8.17 JavaBeans deklarieren – <jsp:useBean> ..................................... 1903.8.18 Eigenschaften abfragen – <jsp:getProperty> .............................. 1963.8.19 Eigenschaften setzen – <jsp:setProperty> ................................. 1973.8.20 Weitere Standardaktionen ........................................................ 2003.8.21 Verwandschaftsbeziehungen und Attributkombinationen ......... 200

3.9 Einsatz der JSP Standard Tag Library – JSTL .......................................... 2013.9.1 Aktionen anstelle von Skriptelementen .................................... 2013.9.2 JSTL 1.0 und 1.1 ...................................................................... 2033.9.3 Abwärtskompatibilität .............................................................. 2043.9.4 Zusammensetzung der Bibliothek ............................................. 2043.9.5 Ablaufsteuerung mit JSTL ......................................................... 2063.9.6 Verarbeitung von XML-Dokumenten ........................................ 2143.9.7 Zugriff auf Datenbanken ........................................................... 2273.9.8 Formatierung von Zahlen, Zeit- und Datumsangaben ............... 2283.9.9 Lokalisierung und Internationalisierung .................................... 232

8 Inhalt

3.10 JSP als XML-Dokument ........................................................................ 2323.10.1 Allgemeine Merkmale von XML ............................................... 2363.10.2 Identifizierung von JSP-Dokumenten ....................................... 2413.10.3 Aufbau von JSP-Dokumenten .................................................. 2413.10.4 Verarbeitung eines JSP-Dokuments .......................................... 2483.10.5 Vorteile von JSP-Dokumenten ................................................. 2483.10.6 JSPs mit XML-Elementen ......................................................... 248

3.11 XML-Ansicht einer JSP .......................................................................... 249

3.12 Nebenläufigkeit und Thread-Sicherheit ................................................ 2513.12.1 Single-Thread-Modell .............................................................. 2513.12.2 Synchronisierung ..................................................................... 252

3.13 Verarbeitung der Ein- und Ausgabe ...................................................... 2533.13.1 Formulare und Anfrage-Parameter ........................................... 2543.13.2 Beispiel für ein Anmeldeformular ............................................. 2543.13.3 Steuerung der Formularverarbeitung ........................................ 2583.13.4 Formularauswertung ................................................................ 2643.13.5 Validierung von Benutzereingaben ........................................... 266

3.14 Einsatz von JavaBeans .......................................................................... 2713.14.1 JavaBeans als Komponenten in JSP .......................................... 2713.14.2 Allgemeine Merkmale von Beans ............................................. 2713.14.3 Eigenschaften und Zugriffsmethoden ....................................... 2733.14.4 Andere Methoden ................................................................... 2743.14.5 Zustände und Serialisierung ..................................................... 2753.14.6 JavaBean-Konstruktor .............................................................. 2753.14.7 JavaBean als Datenbehälter innerhalb eines Anmeldeverfahrens 2753.14.8 Kompilieren und Installieren von Beans ................................... 2843.14.9 Skriptvariable und JavaBean-Objekte ....................................... 284

3.15 Zugriff auf Servlet-Komponenten ......................................................... 2853.15.1 Servlets kompilieren und installieren ........................................ 286

3.16 Austausch zwischen Anwendungskomponenten .................................. 289

3.17 Cookies ................................................................................................. 2923.17.1 Cookies schreiben .................................................................... 2933.17.2 Cookies auslesen ..................................................................... 2953.17.3 Cookies ändern ........................................................................ 2973.17.4 Cookies löschen ....................................................................... 297

3.18 Sitzungsverfolgung ............................................................................... 2973.18.1 Das Session-Konzept in HTTP .................................................. 2983.18.2 Sitzungsverfolgung mit Cookies ................................................ 2993.18.3 Umschreiben von URLs ............................................................ 2993.18.4 Sitzungskennungen über versteckte Formularfelder .................. 3013.18.5 SSL-Sitzungen .......................................................................... 302

3.19 Handhabung einer Sitzung ................................................................... 3023.19.1 Start einer Sitzung .................................................................... 3033.19.2 Abfrage der Sitzungsinformationen .......................................... 3033.19.3 Daten an das Sitzungsobjekt anbinden ..................................... 3043.19.4 Einbau von Beobachtern .......................................................... 3053.19.5 Sitzungsende ........................................................................... 306

Inhalt 9

3.19.6 JSPs in Sitzung einfügen ........................................................... 3063.19.7 Test der Sitzungsverfolgung ...................................................... 307

3.20 Filter und Filterketten ........................................................................... 309

3.21 Internationale und lokale Websites ...................................................... 3133.21.1 Unicode und Zeichenkodierungen ............................................ 3133.21.2 Separate Webpräsenzen für mehrere Sprachen ......................... 3143.21.3 Automatische Sprachauswahl ................................................... 3153.21.4 I18N – Internationale Sites ....................................................... 3163.21.5 Java-Klassen für I18N ............................................................... 3173.21.6 Ressourcenbündel .................................................................... 3213.21.7 Zeichenkodierung für dynamische Inhalte ................................ 3223.21.8 Aktionen der Standardbibliothek für die Internationalisierung .. 3223.21.9 Stadt, Land, Fluss – international .............................................. 323

3.22 Zugriff auf Datenbanken mit JDBC ....................................................... 3283.22.1 Allgemeine Merkmale von SQL ................................................ 3283.22.2 Die JDBC-Architektur ............................................................... 3303.22.3 Der Zugriff auf Datenbanken in der Übersicht .......................... 3383.22.4 Erstes Beispiel mit MySQL ........................................................ 3423.22.5 Die Arbeit mit Datenquellen .................................................... 3473.22.6 Neue Daten in die Datenbank einfügen .................................... 3533.22.7 Datenbankoperationen mit Hilfe von JSTL ................................ 3573.22.8 Ausführen von SQL-Anweisungen ............................................ 3643.22.9 Parameter für die Ergebnismenge ............................................. 3703.22.10 Verarbeiten der Ergebnismenge ................................................ 3733.22.11 Das Interface RowSet ............................................................... 3783.22.12 Transaktionen .......................................................................... 3783.22.13 Zugriff auf Metadaten .............................................................. 3813.22.14 Ausnahmebehandlung und Warnungen .................................... 3833.22.15 Auslagern des Zugriffscodes in Komponenten ........................... 3833.22.16 Connection Pooling .................................................................. 384

3.23 Fehlersuche und Debugging ................................................................. 3853.23.1 Auswerten der Fehlermeldungen .............................................. 3853.23.2 Testverfahren ........................................................................... 3873.23.3 Erzeugen von Fehlerseiten ....................................................... 3873.23.4 Error-Handler ........................................................................... 387

4.1 Anwendungsdeskriptoren ..................................................................... 3914.1.1 Beschreibungselemente im Überblick ....................................... 3914.1.2 Übergreifende Einstellungen .................................................... 3944.1.3 Einstellungen für Servlets und JSPs ........................................... 3954.1.4 Listener und Filter .................................................................... 3974.1.5 MIME-Zuordnungen ................................................................ 3994.1.6 Startseiten ................................................................................ 4004.1.7 Fehlerseiten ............................................................................. 4004.1.8 Lokalisierung ............................................................................ 4014.1.9 Sicherheitsmaßnahmen und Berechtigungen ............................ 401

4 Einrichten dynamischer Webanwendungen 391

10 Inhalt

4.1.10 Benutzerauthentifizierung ........................................................ 4044.1.11 JSP-Konfiguration .................................................................... 4054.1.12 Bezug auf JNDI-Objekte .......................................................... 4084.1.13 Beispiel für eine Deskriptor-Datei ............................................ 409

4.2 Veröffentlichungsverfahren .................................................................. 4104.2.1 Schnüren eines WAR-Pakets .................................................... 4114.2.2 Installation einer WAR-Datei unter Tomcat .............................. 4124.2.3 Deployment ohne Archiv ......................................................... 4134.2.4 Anwendungsmanagement ........................................................ 413

5.1 Benutzerdefinierte Tags ........................................................................ 4175.1.1 Einsatz von Tag-Bibliotheken ................................................... 4185.1.2 Eine einfache Aktion ................................................................ 4185.1.3 Merkmale eigener Aktionen ..................................................... 4265.1.4 Das Interface IterationTag ........................................................ 4315.1.5 Ein Tag, das seinen Rumpf auswertet ....................................... 4325.1.6 Ausnahmebehandlung ............................................................. 437

5.2 Einfache Tag-Handler ............................................................................ 438

5.3 Einbindung von Tags in eine Tag-Bibliothek ........................................ 4455.3.1 Aufbau eines Tag-Bibliothek-Deskriptors .................................. 4465.3.2 Beschreibung der einzelnen Aktionen ...................................... 4485.3.3 Erweiterungen der Taglib ......................................................... 4525.3.4 Installieren der Tag-Bibliothek .................................................. 4545.3.5 Einbinden einer Tag-Bibliothek in eine Anwendung ................. 4555.3.6 Tags oder Beans? ..................................................................... 4575.3.7 Validierung von Tag-Bibliotheken ............................................. 457

5.4 Tag-Dateien .......................................................................................... 4595.4.1 Platzierung der Tag-Dateien ..................................................... 4615.4.2 Inhalt von Tag-Dateien ............................................................ 4625.4.3 Die Direktive tag ...................................................................... 4635.4.4 Die Direktive attribute ............................................................. 4655.4.5 Die Direktive variable .............................................................. 4665.4.6 Zugriff auf implizite Objekte .................................................... 4675.4.7 Synchronisierung der Variablen ................................................ 4675.4.8 Ein Tag mit einem Attribut ....................................................... 4705.4.9 Tags zur dynamischen Präsentation von Daten ......................... 4715.4.10 Aufruf von Fragmenten ............................................................ 475

5.5 Struts-Framework ................................................................................. 476

5 Erweiterungen und fortgeschrittene Lösungen417

Inhalt 11

6.1 Allgemeine Regeln ................................................................................ 4816.1.1 Maskierungen .......................................................................... 4816.1.2 Typographische Konventionen ................................................. 482

6.2 Kommentare ......................................................................................... 482

6.3 Direktiven ............................................................................................. 4836.3.1 page ......................................................................................... 4836.3.2 Include ..................................................................................... 4856.3.3 Taglib ....................................................................................... 486

6.4 Skriptelemente ...................................................................................... 4876.4.1 Deklaration .............................................................................. 4876.4.2 Skriptausdruck ......................................................................... 4886.4.3 Skriptlets .................................................................................. 4896.4.4 Implizite Objekte für Skriptlets und Ausdrücke ......................... 490

6.5 EL-Ausdrücke ........................................................................................ 4916.5.1 Syntax ...................................................................................... 4926.5.2 Implizite Objekte in EL-Ausdrücken ......................................... 4926.5.3 Literale ..................................................................................... 4926.5.4 Operatoren .............................................................................. 4936.5.5 Funktionen .............................................................................. 495

6.6 Standardaktionen .................................................................................. 4956.6.1 <jsp:root> ................................................................................ 4966.6.2 <jsp:text> ................................................................................. 4976.6.3 <jsp:forward> ........................................................................... 4976.6.4 <jsp:include> ........................................................................... 4986.6.5 <jsp:param> ............................................................................. 4996.6.6 <jsp:plugin> ............................................................................. 5006.6.7 <jsp:params> ............................................................................ 5026.6.8 <jsp:fallback> ........................................................................... 5036.6.9 <jsp:useBean> .......................................................................... 5036.6.10 <jsp:getProperty> ..................................................................... 5046.6.11 <jsp:setProperty> ..................................................................... 5056.6.12 <jsp:element> .......................................................................... 5066.6.13 <jsp:attribute> ......................................................................... 5076.6.14 <jsp:body> ............................................................................... 5086.6.15 <jsp:invoke> ............................................................................ 5086.6.16 <jsp:doBody> ........................................................................... 5096.6.17 <jsp:output> ............................................................................ 510

6.7 Kurzreferenz der JSTL ............................................................................ 5106.7.1 Kern-Tag-Bibliothek ................................................................. 5116.7.2 Tags für allgemeine Aufgaben ................................................... 5116.7.3 <c:catch> ................................................................................. 5116.7.4 <c:out> .................................................................................... 5116.7.5 <c:set> ..................................................................................... 5126.7.6 <c:remove> .............................................................................. 5136.7.7 Verzweigungen ........................................................................ 514

6 Kurzreferenz JavaServer Pages 2.0 481

12 Inhalt

6.7.8 <c:if> ....................................................................................... 5146.7.9 <c:choose> .............................................................................. 5156.7.10 <c:when> ................................................................................ 5156.7.11 <c:otherwise> .......................................................................... 5166.7.12 Wiederholungen ...................................................................... 5166.7.13 <c:forEach> ............................................................................. 5166.7.14 <c:forTokens > ......................................................................... 5176.7.15 Import und URL-Behandlung ................................................... 5186.7.16 <c:import> .............................................................................. 5186.7.17 <c:url> ..................................................................................... 5196.7.18 <c:redirect> ............................................................................. 5206.7.19 <c:param> ............................................................................... 5216.7.20 Tags für die Verarbeitung von XML .......................................... 5216.7.21 <x:parse> ................................................................................. 5226.7.22 <x:out> .................................................................................... 5236.7.23 <x:set> .................................................................................... 5236.7.24 <x:if> ....................................................................................... 5246.7.25 <x:choose> .............................................................................. 5246.7.26 <x:when> ................................................................................ 5256.7.27 <x:otherwise> .......................................................................... 5256.7.28 <x:forEach> ............................................................................. 5256.7.29 <x:transform> .......................................................................... 5266.7.30 <x:param> ............................................................................... 5286.7.31 Tags für die Arbeit mit Datenbanken ........................................ 5296.7.32 <sql:setDataSource> ................................................................ 5296.7.33 <sql:query> ............................................................................. 5306.7.34 <sql:update> ........................................................................... 5326.7.35 <sql:param> ............................................................................. 5336.7.36 <sql:dateParam> ...................................................................... 5336.7.37 <sql:transaction> ..................................................................... 5346.7.38 Tags für die Formatierung von Werten ..................................... 5356.7.39 <fmt:formatNumber> .............................................................. 5356.7.40 <fmt:parseNumber> ................................................................ 5376.7.41 <fmt:formatDate> .................................................................... 5396.7.42 <fmt:parseDate> ...................................................................... 5406.7.43 <fmt:timeZone> ....................................................................... 5426.7.44 <fmt:setTimeZone> .................................................................. 5426.7.45 Internationalisierung von Anwendungen .................................. 5436.7.46 <fmt:bundle> .......................................................................... 5436.7.47 <fmt:setBundle> ...................................................................... 5446.7.48 <fmt:setLocale> ....................................................................... 5446.7.49 <fmt:message> ........................................................................ 5456.7.50 <fmt:param> ............................................................................ 5466.7.51 <fmt:requestEncoding> ............................................................ 5466.7.52 Standardfunktionen ................................................................. 5476.7.53 fn:contains ............................................................................... 5476.7.54 fn:containsIgnoreCase .............................................................. 5476.7.55 fn:endsWith ............................................................................. 5486.7.56 fn:escapeXml ........................................................................... 5486.7.57 fn:indexOf ............................................................................... 5496.7.58 fn:join ...................................................................................... 5496.7.59 fn:length .................................................................................. 550

Inhalt 13

6.7.60 fn:replace ................................................................................. 5506.7.61 fn:split ..................................................................................... 5516.7.62 fn:startsWith ............................................................................ 5516.7.63 fn:substring .............................................................................. 5526.7.64 fn:substringAfter ...................................................................... 5526.7.65 fn:substringBefore .................................................................... 5536.7.66 fn:toLowerCase ........................................................................ 5546.7.67 fn:toUpperCase ........................................................................ 5546.7.68 fn:trim ..................................................................................... 554

6.8 JSP-Ressourcen ..................................................................................... 555

Glossar 557

Index 569

15Vorwort

Vorwort

Auch der Siegeszug der Eisenbahn begann mit einem Börsencrash.Unbekannter Trostspender

Längst gehört es zu unseren Lebensgewohnheiten, den Fahrplan für eine Reise,das Kinoprogramm in der Stadt, das Angebot von offenen Stellen, vongebrauchten Autos, von Büchern, CDs und DVDs über das Internet einzusehen,online unsere Bankgeschäfte zu erledigen, Tickets zu buchen und Artikel zubestellen. Das Wissen der Welt, soweit es digital aufbereitet ist, lässt sich überSuchmaschinen anzapfen. Portale können auf die persönlichen Bedürfnissezugeschnittene Informationspakete mit einer erstaunlichen Aktualität zur Ver-fügung stellen.

All diese Angebote sind erst durch Verfahren möglich geworden, die über dieerste Phase der Internetnutzung hinausgeführt haben. Diese erste Phase wardurch die Möglichkeiten bestimmt, die auf der Basis von HTML realisiert wer-den konnten. Diese Technik arbeitet mit statischen Seiten, die durch Hyper-links miteinander verkettet sind. Der Webbesucher kann über den Link zwarvon Seite zu Seite springen, aber der Inhalt all dieser Seiten ist fixiert.

Der nächste Schritt war, die statischen Inhalte durch solche zu erweitern, dieerst auf Anfrage, also dynamisch zusammengestellt werden. In erster Liniewurde dazu eine Verzahnung von Webseiten mit Datenbanken benötigt, diedas Material liefern, um aktuelle Informationen in das Gerüst einer statischenSeite einzubinden.

Auf dem Terrain, das mit diesem zweiten Schritt erreicht wurde, konkurriereneine ganze Reihe von Verfahren, und dieser Wettbewerb hat sich durchausgünstig auf die Leistungsfähigkeit der inzwischen verfügbaren Lösungen ausge-wirkt.

Eine dieser Technologien sind die JavaServer Pages (JSP), die Sun seit 1998 fürdie Erzeugung dynamischer Webinhalte in den Markt eingeführt hat. WieHTML- oder XHTML-Seiten sind auch JSPs Textdokumente, die festlegen, wieeine Webseite in einem Browser ausgegeben werden soll. Viele JSPs enthaltenBestandteile, die denen von HTML- oder XHTML-Seiten entsprechen. (Eine JSPkann sogar ausschließlich aus HTML oder XHTML bestehen.) Andere Elementein einer JSP können aber mehr als nur gegebene Texte, Bilder und sonstigeMedien von einem Webserver auf den Bildschirm laden. Sie sind imstande, aufdem Server Verarbeitungsprozesse in Gang zu setzen, die die Antwort des Ser-

Vorwort16

vers durch den Inhalt der Anfrage bestimmen. Diese Antwort wird in der Regelin Form von HTML- oder XHTML-Seiten an den Client geschickt, was nebenbeiden Vorteil hat, dass Firewalls nicht im Wege stehen.

Aufgerufen werden können JSPs entweder direkt oder über Formulare, Linksoder spezielle Aktionen zum Inkludieren oder zur Weiterleitung von Anfragen.Dabei können Parameter in Form von Name/Wert-Paaren übergeben werden.JSPs können sich auch selbst aufrufen.

Der Zuspruch zu dieser Lösung ist in den letzten Jahren ständig gewachsen.Das hat sicher mit dem Erfolg von Java als plattformunabhängiger Program-miersprache zu tun, zum anderen auch damit, dass JSP ganz in eine Architektureingebettet ist, die die notwendigen Dienstleistungen für anspruchsvolleAnwendungen in Form entsprechender Bibliotheken wie JDBC, JNDI oder EJBschon mitbringt. Gemeint ist J2EE, die Edition der Java 2-Plattform für unter-nehmensweite Anwendungen.

In schneller Folge wurden mehrere Versionen der JSP-Spezifikation bereitge-stellt. Im Juni 1999 lag die Spezifizierung von JSP 1.0 vor, JSP 1.1 folgte schonim Dezember. JSP 1.2 wurde 2001 verabschiedet. Dieses Buch befasst sich ins-besondere mit der neuen JSP-Version 2.0. Diese Version baut auf der Servlet-API-Spezifikation 2.4 auf. JSP 2 erfordert die Java 2-Plattform in der StandardEdition Version 1.3 für Standalone-Container bzw. 1.4 für Container, die Teilder Umgebung Java 2 Enterprise Edition 1.4 sind. Diese Edition ist seit Novem-ber 2003 verfügbar. Als Referenzimplementierung für JSP 2.0 wird der OpenSource Tomcat-Container in der Version 5.0 verwendet.

Dieses Buch gibt Ihnen einen kompakten Einstieg in die aktuelle Version vonJSP, die vermutlich die Art und Weise, wie solche Projekte in Zukunft realisiertwerden, stark verändern wird. JSP 2.0 unterstützt zwar weiterhin eine Reihevon Verfahren, die in diesem Bereich bisher üblich waren, gemeint sind insbe-sondere die verschiedenen Formen von Skriptelementen. Es bietet aber zu-gleich deren weitgehenden oder sogar vollständigen Ersatz durch den Einsatzvon Elementen an, die klar an den inzwischen allgemein anerkannten XML-Standards orientiert sind. In gewissem Sinne befindet sich JSP also in einer ArtÜbergangsstadium, sodass gelegentlich konkurrierende Verfahren für den glei-chen Zweck beschrieben werden.

Die beiliegende CD enthält neben den im Buch beschriebenen Beispielen dieaktuellen Spezifikationen zu JSP 2, JSTL 1.1, Servlet 2.4 und die API-Dokumen-tation für J2EE 1.4, J2SE 1.4 und JSP 2.0. Auch das J2SE-SDK und die aktuellenTomcat 5.0-Binaries für Windows und UNIX liegen bei.

Helmut Vonhoegen Köln, im Januar 2004

17

1

2

3

4

5

6

7

8

9

10

11

12

13

14

1 JavaServer Pages im Überblick

1.1 Von statischen zu dynamischen Webseiten....... 19

1.2 Die Basis: das HTTP-Protokoll ........................... 20

1.3 JSP im Vergleich zu älteren Serveranwendungen 29

1.4 Anwendungsgebiete und -modelle.................... 39

1.5 Von JSP 1.2 nach JSP 2...................................... 41

1.6 Allgemeine Merkmale von JSP .......................... 44

1 Java Server Pages im Überblick

2 Einrichten einer Entwicklungsumgebung

3 Entwicklung dynamischer Webseiten mit JSP 2.0

4 Einrichten dynamischer Webanwendungen

5 Erweiterungen und fortgeschrittene Lösungen

6 Kurzreferenz Java Server Pages 2.0

19JavaServer Pages im Überblick

1

2

3

4

5

6

7

8

9

10

11

12

13

14

1 JavaServer Pages im Überblick

Online-Dienstleistungen taugen nur etwas, wenn sie den Bedürfnis-sen der Besucher entsprechen. Dazu reichen statische Angebote nicht aus.

Das Web wird gern als interaktives Medium betrachtet. Tatsächlich ist HTMLein wunderbares Mittel, um bunte Seiten vom Server zum Anwender zu schi-cken. Mittels Hyperlinks hangelt sich der Besucher mühelos von Seite zu Seite,und mit Hilfe von eingebauten Komponenten lassen sich Medien jeder Art aufdem Bildschirm wiedergeben.

Dennoch bleibt das Web mit den Mitteln von HTML allein eine Einbahnstraße,es gibt für den Besucher keine Möglichkeit – abgesehen von der Eingabe vonWebadressen –, selbst Informationen an das Web abzugeben und so seine Inte-ressen besser ins Spiel zu bringen.

1.1 Von statischen zu dynamischen Webseiten

Es gibt ganz unterschiedliche Gründe für mehr Interaktion. Häufig ist es bei-spielsweise für die Besucher der Sites großer Medien angenehm, wenn sie eineVorauswahl der Themen treffen können, zu denen Inhalte angeboten werden.Umgekehrt werden Informationsangebote oft nur dann freigegeben, wenn derBenutzer sich beim Anbieter anmeldet und seine Berechtigung nachweist, etwabei abonnierten Diensten wie MedLine. Online-Anbieter möchten die Kunden-bindung verstärken, indem sie den Besucher nicht nur mit seinem Namenansprechen, sondern ihm auch Spezialangebote vorschlagen, die zu dem pas-sen könnten, was er bisher schon gekauft hat. E-Commerce und Online-Ban-king sind nicht möglich, ohne den Zugriff auf Datenbanken auf der Seite desServers.

Die Technologien, die in diesem Buch vorgestellt werden, erlauben solcheLösungen oder sind zumindest ein bedeutender Teil davon. Die Besonderhei-ten dieser Verhahren ergeben sich zu einem großen Teil aus den Gegebenhei-ten, die durch die technische Strukur des Internets bedingt sind. Um den in denfolgenden Kapiteln beschriebenen Details ein Fundament zu geben, wirdzunächst das Kommunikationsmodell vorgestellt, das den JavaServer Pageszugrunde liegt.

JavaServer Pages im Überblick20

1.2 Die Basis: das HTTP-Protokoll

Die Webanwendungen, von denen in diesem Buch die Rede sein wird, könnenganz allgemein als Programme gekennzeichnet werden, die auf einem Webser-ver ablaufen und von Clients, in der Regel in Form von Webbrowsern, aufge-rufen werden. Während dies heute noch hauptsächlich von PCs aus stattfindet,sind schon die verschiedenartigsten Geräte auf dem Vormarsch, die den Zugriffauf Webserver-Anwendungen auch für unterwegs erlauben: PDAs, Handys,intelligente Armbanduhren, vielleicht demnächst auch Brillen von der Art, wiesie in der Werbung eines bekannten Kreditkartenanbieters auftauchten.

1.2.1 Das Anfrage/Antwort-Modell

Die Basis für all diese Erweiterungen der menschlichen und maschinellen Kom-munikation ist das HTTP-Protokoll, und jeder, der mit der Entwicklung vonAnwendungen zu tun hat, die dieses Protokoll als Fundament nutzen, sollte einpaar Hintergrundinformationen dazu nicht verschmähen. Die Besonderheitenvon HTTP bestimmen nämlich sehr ausdrücklich die Art und Weise, wie Web-anwendungen gestaltet werden können.

Abbildung 1.1 Schema des Anfrage/Antwort-Modells in HTTP

Das Hypertext Transfer Protocol (HTTP) ist ein bewusst einfaches Protokoll aufder Basis des TCP/IP-Protokolls. Es wurde spezifiziert durch die Internet Engi-neering Task Force (IETF) in einem Request for Comments (RFC), und zwarzunächst in RFC 1945.

Jeder HTTP-Server muss die Version HTTP/1.0 unterstützen, die meisten erlau-ben aber auch die erweiterte Version HTTP/1.1 (RFC 2616), die insbesondereauch persistente Verbindungen erlaubt.

21Die Basis: das HTTP-Protokoll

1

2

3

4

5

6

7

8

9

10

11

12

13

14

Der Kern des Kommunikationsmodells, das durch HTTP geregelt wird, lässtsich vereinfacht als Schrittfolge beschreiben:

1. Ein Client öffnet eine Verbindung zum HTTP-Port eines Servers (Vorgabe istPort 80). Er benutzt dazu ein TCP/IP-Socket.

2. Er sendet über diese Verbindung eine Anfrage (Request). Ziel ist eine Res-source auf diesem Server.

3. Der Server lauscht auf eingehende Anfragen an dem dafür bestimmten Port.Geht eine Anfrage darüber ein, sendet er eine Antwort (Response) an denSocket des Clients: entweder die angeforderte Ressource oder eine Fehler-meldung, wenn die Adresse nicht stimmt.

4. Die Verbindung wird wieder geschlossen.

In der Regel ist der Client ein Programm, das in der Lage ist, Anfragen abzusen-den, meist ein Browser. Die Anfrage kann direkt durch die manuelle Eingabeeiner Webadresse gestartet werden oder durch Anklicken eines Links oder auchdurch das Abschicken eines Formulars. Es kann aber auch z.B. eine Suchma-schine sein, die automatisch Anfragen generiert.

In der Rolle des Servers kann im Prinzip jedes Programm agieren, das in derLage ist, solche Client-Anfragen zu verstehen und mit einer entsprechendenAntwort zu reagieren. Durch Zwischenschaltung von Proxies, Tunnels oderGateways kann der Ablauf der Kommunikation auch komplexere Formenannehmen, aber davon soll hier nicht die Rede sein.

Das HTTP-Protokoll legt dabei insbesondere fest, in welchem Format dieseNachrichten zwischen Client und Server ausgetauscht werden.

Bevor auf die Einzelheiten der beiden Seiten der Kommunikation eingegangenwird, sollen noch einige wesentliche Merkmale von HTTP betont werden, diegerade für die Webentwicklung von Bedeutung sind.

1.2.2 Verbindungslos

Aufgrund der Tatsache, dass für jedes Anfrage/Antwort-Paar eine eigene Ver-bindung auf- und wieder abgebaut wird, kann HTTP auch als ein verbindungs-loses Protokoll bezeichnet werden. Dieses Merkmal hat seine Vor- und Nach-teile. Zunächst spart der sofortige Abbau einer Verbindung, sobald der Serverseine Antwort losgeworden ist, viele Ressourcen auf der Serverseite, falls derServer von zahlreichen Clients adressiert wird. Andererseits erhöht sich durchdie zahlreichen Verbindungsaufnahmen der Netzverkehr.


1.2.3 Ohne Zustand

HTTP ist zugleich ein zustandsloses Protokoll. Der Server behält keinerlei Infor-mationen über den Client, sobald eine Verbindung nach dem Zusenden derAntwort abgeschlossen ist. Die Folge davon ist, dass das Protokoll nicht merkt,wenn ein Client A zum wiederholten Male eine Verbindung zu Server B auf-baut.

Auch über die Art des Zugangs gibt HTTP dem Server keinen Aufschluss, derServer kann also nicht unterscheiden, ob eine Anfrage durch Anklicken einesLinks, durch Abschicken eines Formulars oder durch Klick auf die SchaltflächeZurück erfolgt ist.

Für HTTP sind alle Verbindungen gleich, und nach ihrer Beendigung gibt eskeine »Erinnerung« an das, was früher geschehen ist. Hier unterscheidet sichHTTP deutlich von FTP, bei dem Verbindungen aufgebaut werden können, diefür mehrere Anfragen bestehen bleiben.

Dass HTTP ein zustandsloses Protokoll ist, hat den Vorteil, dass weniger Res-sourcen auf dem Server verbraucht werden und so mehr gleichzeitige Zugriffemöglich sind.

Wo es aber notwendig ist, HTTP-Verbindungen mit einer Art Erinnerungsver-mögen auszustatten, müssen besondere Maßnahmen ergriffen werden, wie siein Abschnitt 3.18 beschrieben werden.

1.2.4 Aufbau von HTTP-Nachrichten

Wie die Anfrage eines Clients und die Antwort eines Servers aussehen können,ist durch das HTTP-Protokoll genau beschrieben. Beide Nachrichtentypenhaben einen gemeinsamen Aufbau, der aber unterschiedlich ausgefüllt wird.

Jede Nachricht setzt sich aus folgenden Komponenten zusammen:

� Startzeile

� Nachrichten-Header*

� CRLF

� [Nachrichtenrumpf]

Die erste Zeile ist erforderlich, die Anzahl der Header-Zeilen kann ganz unter-schiedlich sein, je nachdem, welche Informationen an die jeweils andere Seiteübergeben werden sollen. Dabei wird zwischen allgemeinen Headern, Anfrage-bzw. Antwort-Headern und solchen unterschieden, die sich speziell auf dieNachrichten beziehen, die im Nachrichtenrumpf enthalten sind, falls ein sol-cher verwendet wird. Dieser Teil wird von den Headern jeweils durch eine


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Leerzeile abgetrennt. Die Header werden in Form von Name/Wert-Paarenangegeben.

1.2.5 Das Format der Anfrage

Bei jeder Anfrage eines Clients an einen Webserver wird ein URL verwendet,der zunächst das Protokoll und den gewünschten Server und dann die Res-source angibt, auf die auf diesem Server zugegriffen werden soll. Der Webser-ver lauscht auf eingehende Anfragen über einen bestimmten Port, Vorgabe istder Port 80. Diese Vorgabe kann geändert werden, indem die gewünschte Port-nummer hinter der Angabe des Servers, getrennt durch einen Doppelpunkt,angehängt wird:

http://www.helmut-vonhoegen.de:8080/index.html

Die erste Zeile bei einer Anfrage ist eine Anfragezeile (request-line), bei derAntwort eine Statuszeile (status-line).

Wird beispielsweise ein URL wie

http://www.helmut-vonhoegen.de/index.html

eingegeben, besteht die Anfragezeile aus:

GET /index.html HTTP/1.1

Die erste Zeile einer Anfrage gibt zunächst die Anfragemethode an undbenennt die Ressource, die angefordert wird. Dann folgt die vom Browser ver-wendete HTTP-Version.

Anfragemethoden

GET ist die vorgegebene Methode, die für normale Aufrufe von HTML-Seitenund JSPs verwendet wird. Sie fordert einfach vom Webserver die angegebeneRessource an. Ein Nachrichtenrumpf wird nicht verwendet.

Die POST-Methode, die ebenfalls im Zusammenhang mit JSP eingesetzt wird,erlaubt es, mit der Anfrage auch größere Datenmengen zu übertragen, diejeweils im Nachrichtenrumpf zusammengestellt werden.

Die anderen hier möglichen Methoden – HEAD, CONNECT, DELETE, OPTIONS, PUTund TRACE – spielen im Zusammenhang mit JSP normalerweise keine Rolle.

Header

Die Liste der möglichen Header ist ziemlich lang und kann unterwww.w3.org/Protocols/rfc2616/rfc2616-sec14.html nachgesehen werden.


Beschrieben werden hier nur einige der am häufigsten verwendeten Header inder Anfrage.

Host – Dieses Feld ist das einzige, das in jeder Anfrage enthalten sein muss.Angegeben wird der Name des Webservers und eventuell die Portnummer, wiesie aus dem verwendeten URL ausgelesen werden kann. Falls der IP-Adresseeines Servers mehrere Servernamen zugeordnet sind, kann so zwischen denverschiedenen virtuellen Hosts unterschieden werden.

Host: www.w3.org

Connection – Mit dem Wert close wird der Server angewiesen, die Verbin-dung zu schließen, sobald die Übertragung der Antwort abgeschlossen ist. DieAlternative ist keep-alive, wenn die Verbindung aufrechterhalten bleiben soll.

Connection: close

User-Agent – übergibt Informationen zu dem verwendeten Browser. DieAbfrage dieser Information erlaubt dem Server beispielsweise, unterschiedli-che Seiten zurückzugeben, je nachdem, welcher Browser im Einsatz ist. DieserHeader kann auch darauf hinweisen, dass ein Browser auf einem PDA oderHandy genutzt wird.

User-Agent: Mozilla/4.51 [en] (WinNT; I]

Eine Gruppe von Headern liefert dem Server Hinweise, wie die Antwort an denBrowser an dessen Möglichkeiten angepasst werden kann:

Accept – wird verwendet, um die Medientypen (also die MIME-Typen) aufzu-listen, die der Browser akzeptieren kann.

Accept: audio/*, text/html, image/gif, image/jpeg

Accept-Charset – gibt die Zeichensätze an, mit denen der Browser etwasanfangen kann.

Accept-Charset: iso-8859–5

Accept-Encoding – informiert über die möglichen Kodierungen, die für denInhalt der Antwort verwendet werden können.

Accept-Encoding: compress, gzip

Accept-Language – gibt die in der Antwort bevorzugten Sprachen an.

Accept-Language: de, en


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Anfrageparameter

Wenn bei einer Anfrage die GET-Methode verwendet wird, lassen sich an denURL Parameter anhängen, die der Server zur Generierung der Antwort verwen-den kann, etwa bei der Abfrage einer Datenbank. Soll beispielsweise eine Listemit Artikeln einer bestimmten Modellgruppe angefordert werden, kann derName der Modellgruppe als Parameter übergeben werden. Parameter werdennach einem trennenden Fragezeichen hinter den URL in Form von Name/Wert-Paaren angehängt, die selbst wieder durch &-Zeichen getrennt werden, wie indem folgenden Beispiel:

http://www.lichtlager.de/deckenlampen?modellgruppe=halogen&preis-gruppe=A

Dabei muss eine bestimmte Kodierung beachtet werden, die Zeichen maskiert,die innerhalb eines URL nicht in der Bedeutung verwendet werden sollen, wiesie nach der URL-Syntax vorgesehen sind. Die untenstehende Tabelle listet dieEscape-Codes für diese Zeichen auf.

Anfragerumpf

Bei der HTTP-Methode POST werden die Daten, die an den Server übergebenwerden sollen, etwa die Eingaben in einem Formular, nicht als Parameter anden URL, sondern hinter den Headern als Rumpf

Zeichen Escape-Code

Leerzeichen %20

» %22

~ %7E

. %2E

, %2C

< %3C

> %3E

# %23

% %25

{ %7B

} %7D

| %7C

\ %74


Diese Parameter lassen sich entweder manuell an den URL anfügen oder überein Formular, das die jeweiligen Werte abfragt. Sobald die Submit-Schaltflächebenutzt wird, werden die Parameter gesetzt.

Anfragerumpf

Bei der HTTP-Methode POST werden die Daten, die an den Server übergebenwerden sollen, etwa die Eingaben in einem Formular, nicht als Parameter anden URL, sondern hinter den Headern als Rumpf der Nachricht angehängt. Aufdiese Weise können bei einer Anfrage auch größere Datenmengen übertragenwerden. Mehr dazu im Abschnitt zu den HTML-Formularen.

1.2.6 Das Format der Antwort

Die Antwort des Servers folgt immer unmittelbar auf die Anfrage des Clients.Der Server versucht, die in der Anfrage angegebene Ressource zu finden, seidies nun eine einfache Webseite oder ein Programm wie etwa ein CGI-Skript.Die Antwort ergibt sich folglich aus dem, was dem Server durch die Abfrageabverlangt wird. Das Format der Antwort entspricht in der Grundstruktur demder Anfrage. Sie ist zusammengesetzt aus einer Reihe von Antwort-Headernund einem Antwort-Rumpf. Die Antwort-Header sind insbesondere dazu da,dem Browser Informationen zu liefern. Diese benötigt er, um mit dem Ant-wort-Rumpf etwas anfangen zu können, um Cookies zu setzen oder um zu

^ %5E

~ %7E

[ %5B

] %5D

' %60

; %3B

/ %2F

? %3F

: %3A

@ %40

= %3D

& %26

Zeichen Escape-Code


1

2

3

4

5

6

7

8

9

10

11

12

13

14

einer anderen Seite umzuleiten. Grundsätzlich werden immer erst die Headeran den Browser geschickt, bevor der Rumpf übermittelt wird.

Statuszeile

Die erste Zeile ist immer eine Statuszeile, die sofort erkennen lässt, ob dieAnfrage erfolgreich bearbeitet werden konnte oder nicht. Die Statuszeilebenennt das verwendete Protokoll, gibt dann einen Statuscode in Form einerdreistelligen Zahl und danach eine Kurzbeschreibung der durch den Statuscodeidentifizierten Situation an. Eine erfreuliche Statuszeile sieht deshalb so aus:

HTTP/1.1 200 OK

Die Anfrage wurde vom Server entgegengenommen, verstanden und akzep-tiert. Wird die Ressource nicht gefunden, gibt es den weniger erfreulichenCode 400 bad request. Wird der Zugriff auf eine Seite verweigert, weil derBenutzer sich nicht identifizieren kann, ist der Code 401 unauthorized.

Die Statuscodes sind nach der ersten Zahl in fünf Klassen eingeteilt, die in derTabelle beschrieben sind:

Die vollständige Liste der Codes ist unter www.w3.org/Protocols/rfc2616/rfc2616-sec10.html zu finden.

Antwort-Header

Hinter der Statuszeile folgen üblicherweise einige Header, wie in dem folgen-den Beispiel:

Code-Bereich Kategorie Bedeutung

1xx Information provisorischer Code für experiementelle Anwendungen, wird nur von HTTP/1.1 verwendet

2xx Erfolgreich gibt an, dass eine Anfrage erfolgreich bearbeitet wurde

3xx Umleitung Der Server fordert die Weiterleitung der Anfrage an eine andere Stelle an.

4xx Client-Fehler Codes für Fehler auf der Client-Seite, z.B. ein falsch ein-gegebener URL für eine Ressource, die deshalb nicht gefunden werden kann

5xx Server-Fehler Codes für Fehler auf der Serverseite. Der Server kann beispielsweise eine Anfrage nicht ausführen, obwohl der URL in Ordnung ist, etwa wegen Überlastung der Ver-bindungen.


HTTP/1.1 200 OKDate: Sat, 04 Mar 2003 13:39:02 GMTAccept-Ranges: bytesServer: Apache/1.3.1Content-Length: 1280Content-Type: text/htmlLast-Modified: Fri, 03 Mar 2003 06:54:40 GMT

<html> <head>...

Auch in der Antwort kommen unterschiedliche Typen von Headern vor. Einigeenthalten allgemeine Informationen im Zusammenhang mit der Antwort, z.B.:

� Date – gibt das Datum der Antwort an.

� Andere Header betreffen Informationen über die Antwort selbst:

� Server – gibt den Namen des verwendeten Servers bzw. des Serverpro-gramms und der verwendeten Version an.

� Accept-Ranges – zeigt an, dass auch Anfragen zu einzelnen Bereichen derRessource möglich sind, und gibt die Einheit an, die dabei verwendet wer-den kann.

Eine Reihe von Headern beziehen sich auf den Inhalt des Nachrichtenrump-fes in der Antwort:

� Content-Length – gibt die Länge des nach der Leerzeile angehängten Nach-richtenrumpfes an.

� Content-Type – gibt den Inhaltstyp des Nachrichtenrumpfes an, also ob essich z.B. um HTML- oder XML-Code oder um einfachen Text handelt. Hierwird der entsprechende MIME-Typ eingetragen, an dem der Browser erken-nen kann, ob er für die Darstellung der Daten möglicherweise auf ein Pluginzurückgreifen muss.

� Last-Modified – liefert das Datum der letzten Änderung an dem Nachrich-tenrumpf oder an der wiedergegebenen Ressource. Der Browser kann dieseInformation in einem lokalen Cache als Zeitstempel verwenden, sodass Res-sourcen nur dann neu angefordert werden müssen, wenn sie sich seit derletzten Anfrage geändert haben.

Antwortrumpf

Der Rumpf der Antwort kann einfache HTML-Seiten enthalten oder auchandere Inhaltstypen wie XML etc. Sind im Rumpf Tags enthalten, die selbst

29JSP im Vergleich zu älteren Serveranwendungen

1

2

3

4

5

6

7

8

9

10

11

12

13

14

wieder auf andere Ressourcen verweisen, etwa ein <img>-Tag für ein Bild,erzeugt der Browser bei der Entgegennahme der Antwort daraus automatischeine erneute, spezielle Anfrage an den Server, diese Ressource ebenfalls zu lie-fern. Das Laden einer großen Seite mit vielen Bildern und sonstigen einge-schlossenen Ressourcen – Videos, Audiostreams etc. – kann sich also zu einemmunteren Anfrage/Antwort-Spiel auffächern, bis eine Seite endlich vollständigzu sehen ist. Das führt bei langsamen Modemverbindungen zu den gefürchte-ten Wartezeiten.

1.2.7 Beobachtung der HTTP-Kommunikation

Wenn Sie die Client/Server-Kommunikation im Detail überprüfen wollen, kön-nen Sie eines der Tools verwenden, das die HTTP-Nachrichten sichtbar macht.Die Abbildung zeigt ein Dialogfenster des ProtocolExplorers, der auf der Seitewww.sourcestream.com von Dustin R. Callaway angeboten wird.

Abbildung 1.2 HTTP-Nachrichten bei einer Anfrage

1.3 JSP im Vergleich zu älteren Serveranwendungen

Der erste Lösungsansatz für dynamische Webseiten, der auch heute noch beivielen Formularseiten verwendet wird, benutzt das so genannte CommonGateway Interface (CGI). Diese »Allgemeine Übergangsschnittstelle« bot zum


ersten Mal die Möglichkeit, Daten vom Anwender zum Server zu schicken undauf diesem Weg an den Anbieter einer Website weiterzuleiten. Die Schnitt-stelle regelt, wie der Browser dabei mit Programmen auf der Serverseite kom-muniziert.

1.3.1 Common Gateway Interface

Der Ansatz des CGI ist relativ einfach. Bei normalen Webseiten wird von einemBrowser aus ein URL an den Webserver geschickt. Findet der Server die adres-sierte Seite, wird sie unverändert an den Browser geschickt und darin ange-zeigt. Bei einem CGI-Aufruf dagegen lokalisiert der aufrufende URL keineHTML-Seite, sondern ein Programm oder Skript auf dem Webserver. Wenn derServer die Anfrage empfängt, setzt er eine Reihe von Umgebungsvariablen, aufdie die CGI-Anwendung zugreifen kann. Dazu gehören etwa die Portnummer,der Skriptname, der Abfragestring, der Inhaltstyp und die Länge der Daten, diedem Skript übergeben werden, um nur einige zu nennen.

Der Server startet nach diesen Vorbereitungen die Anwendung. Vom Besuchereingegebene Daten werden entweder als Parameter, die an den URL angehängtsind, übergeben oder im Nachrichtenrumpf der Anfrage. Diese Daten werdenüber die Standardeingabe an das CGI weitergereicht.

Das Programm verwendet die übergebenen Daten, um damit etwas mehr oderweniger Sinnvolles zu tun, und schickt eine Antwortseite zurück. Das kanneine einfache Bestätigung sein, dass ein Formular empfangen wurde, oder auchdas Ergebnis einer Datenbankabfrage, die von dem CGI-Skript ausgeführt wird.Das Skript schreibt dazu diese Antwort einfach in die Standardausgabe, und derServer schickt sie an den Client.

Die weite Verbreitung von CGI-Lösungen hat sicher auch damit zu tun, dassCGI-Programme in zahlreichen Sprachen geschrieben werden können. Provi-der stellen häufig Bibliotheken mit verwendbaren CGI-Anwendungen zur Ver-fügung, um Standardfunktionen anzubieten.

Typische Aufgaben sind:

� Formmailer – Weiterleiten von ausgefüllten Formularen per E-Mail an denAnbieter

� Suchfunktionen – Auffinden von Informationen innerhalb umfangreicherWebsites

� Besucherzähler – Messung der Zugriffe auf einzelne Webseiten

Die CGI-Lösung bringt aber eine Reihe von Nachteilen, die sehr bald die Suchenach Alternativen angestoßen hat. Der gravierendste Nachteil ist, dass der


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Webserver für jede Anfrage einen eigenen Systemprozess starten und einenSprach-Interpreter laden muss, der dann das Skript ausführt. Kommen zahlrei-che Anfragen gleichzeitig an, geht die Performanz leicht in die Knie. Da jederCGI-Prozess separat ausgeführt wird, ist es auch schwierig, Daten zwischen ver-schiedenen CGI-Anwendungen auszutauschen, etwa um eine Sitzungsverfol-gung zu realisieren. Zwar hat hier die Erweiterung FastCGI, die von der FirmaOpen Market entwickelt wurde, insofern eine Verbesserung erlaubt, als dassmehrere Anfragen in einem permananten Prozess abgearbeitet werden kön-nen. Diese Lösung wird aber nur von einigen Servern unterstützt.

1.3.2 Servererweiterungen

Die Einschränkungen der CGI-Lösung führten zu einer Reihe von Alternativenin Form von speziellen Servererweiterungen. Webserver-APIs sorgen dafür,dass nicht für jede Anfrage ein neuer Prozess gestartet werden muss. DieAnwendungen werden nach der ersten Anfrage im Speicher gehalten und überFunktionsaufrufe für alle folgenden Anfragen genutzt. Dazu zählen das NSAPIauf dem Webserver von Netscape/iPlanet, das ISAPI auf dem Internet Informa-tion Server (IIS) von Microsoft und das Apache-API auf dem bekannten ApacheWebserver.

Webserver-APIs bringen insbesondere Geschwindigkeitsvorteile gegenüberden CGI-Lösungen. Zugleich werden aber auch die Funktionsmöglichkeitenerweitert, weil diese Interfaces Zugriff auf die internen Strukturen des jeweili-gen Servers haben. Der Nachteil ist allerdings, dass Anwendungen, die dieseAPIs nutzen, nicht ohne weiteres auf andere Server übertragen werden könnenund dass sie an bestimmte Sprachen gebunden sind.

1.3.3 Java-Servlets

In der Java-Welt – Start 1994 – führte Sun 1996 eine ähnliche Lösung ein: Serv-lets als Komponenten auf der Serverseite. Dazu wurde die Spezifikation für einServlet-API entwickelt, die inzwischen bis zu der Version 2.4 fortgeschrittenist. Sie beschreibt die Interfaces und Klassen, die Servlets nutzen, um Weban-wendungen mit dynamischen Inhalten generieren zu können.

Allerdings geschieht dies gewissermaßen im Hintergrund, denn Servlets habenanders als Java-Applets, die sich direkt in einem Browser zeigen und ihre Steu-erelemente anbieten, keine grafische Schnittstelle. Dafür haben sie den Vorteil,dass sie auf einer virtuellen Maschine in einer kontrollierten Serverumgebungablaufen und für die Kommunikation mit den Clients nur auf HTTP angewiesensind. Deshalb sind Servlets auch nicht von den Einschränkungen betroffen, dieeinem Applet durch die Umgebung, in der es innerhalb eines Browsers laufen


soll, gesetzt sind. Das Ergebnis eines Servlets wird auf dem Client einfach inHTML ausgegeben, was selbst für ältere Browser keine Probleme aufwirft. Aufdem Client muss also keine zusätzliche Software installiert sein.

Klassen für die HTTP-Kommunikation

Zunächst einmal sind Servlets reguläre Java-Klassen. Sie unterscheiden sichaber von anderen Java-Anwendungen dadurch, dass sie nur in einer bestimm-ten Umgebung ausgeführt werden können. Diese gibt vor, was ein Servlet kannund was nicht. Deshalb werden Servlets auch als Erweiterung von zwei spezi-ellen Klassen realisiert, die es erlauben, die durch das HTTP-Protokoll gegebe-nen Formen der Kommunikation zwischen Webbrowser und Webserver zunutzen. Dies sind die Klassen GenericServlet und HTTPServlet.

Diese Klassen bieten zahlreiche vordefinierte Methoden an, und die Aufgabeder Entwicklung besteht im Wesentlichen darin, entsprechende Unterklassendaraus zu bilden und die Methoden passend zu überschreiben, die für einebestimmte Anwendung benötigt werden.

Servlets erlauben es, auf eine Anfrage an den Webserver nicht einfach statischeInhalte, die in Form von Webseiten auf dem Server vorliegen, zurückzugege-ben, sondern Informationen, die das Servlet aktuell durch Verarbeitung dervorliegenden Daten generiert.

Ein Servlet stellt also auf der Basis von Daten, die im Zuge einer Anfrage über-geben werden, etwas Bestimmtes an, und erst die Ergebnisse dieser Aktivitätenwerden in Form einer Antwortseite im Browser wieder sichtbar.

Komponenten und Container

Webanwendungen, die mit Hilfe von Servlets realisiert werden, sind Software-komponenten, die zur Ausführung eine spezielle Laufzeitumgebung benötigen.Diese Umgebung wird in der Java-Welt durch Container hergestellt. Währendfür Applets auf der Client-Seite ein Applet-Container benötigt wird, benötigenServlets auf der Serverseite einen Servlet-Container.

Alle Servlet-Container müssen den Servlets bestimmte Dienste anbieten, diejedes Servlet braucht, wenn es eingesetzt werden soll. Und sie müssen dieseDienste in derselben Weise anbieten, damit Servlets, die auf einem bestimmtenContainer entwickelt wurden, auch auf jeden anderen Servlet-Container über-tragen werden können. Diese Einheitlichkeit wird dadurch gewährleistet, dassdie Container der Servlet-Spezifikation entsprechen müssen. Container stellenaußerdem bestimmte Werkzeuge – Deployment Tools – zur Verfügung, mitdenen Komponenten innerhalb des Containers eingerichtet und konfiguriert


1

2

3

4

5

6

7

8

9

10

11

12

13

14

werden können. Dabei werden Deskriptoren in Form von XML-Dokumentenverwendet.

Abbildung 1.3 Server, Servlet-Container und Servlets

Die Hauptaufgabe des Servlet-Containers ist, den so genannten Lebenszyklusder Servlets zu managen. Der Container lädt meist die Klasse eines Servlets,wenn die erste Anfrage danach von einem Browser eingeht, legt die Eingangs-werte fest und ermöglicht dann die Abarbeitung der Anfrage. Weitere Anfragenkönnen das bereits initialisierte Servlet erneut verwenden, bis der Serverschließlich heruntergefahren wird. Der Container gibt dem Servlet die Mög-lichkeit, genutzte Ressourcen wieder freizugeben und Zustandsinformationen,die während des Lebenszyklus erworben wurden, zu sichern.

Serverprozess und Threads

Dabei benutzen Servlets denselben Prozessraum wie der Webserver selbst, des-sen Wirkungsmöglichkeiten sie erweitern. Sie werden wie gesagt nur einmalgeladen, entweder bei der ersten Anfrage oder auch gleich beim Start des Ser-vers. Jede einzelne Anfrage kann dann als ein separater Ausführungspfad, alsThread, innerhalb dieses permanenten Prozesses behandelt werden. Das wie-derum eröffnet die Möglichkeit, in einem einzigen Prozess auch mehrereThreads parallel zu handhaben. Ist ein Servlet einmal geladen, können alleAnfragen an dieses Servlet, die gleichzeitig eingehen, auf mehrere Threads ver-teilt werden.


Servlets haben dabei Zugriff auf die Dienste, die der Webserver zur Verfügungstellt, z.B. Logbuchfunktionen, Benutzeridentifizierung etc. Außerdem kannauf Ressourcen zugegriffen werden, die zwischen verschiedenen Anfragen imSpeicher verbleiben, etwa geöffnete Datenbankverbindungen.

Automatische Kompilierung

Weitere Vorteile ergeben sich daraus, dass Servlets beim ersten Aufruf kompi-liert werden und nur bei einer Änderung erneut kompiliert werden müssen.Insofern sind diese Komponenten wesentlich schneller als Skriptlösungen, diejedes Mal neu interpretiert werden. Da es sich um Java-Klassen handelt, istauch die Überprüfung der verwendeten Datentypen immer streng, sodass Feh-ler in diesem Bereich schon bei der Kompilierung entdeckt werden und nichterst bei der Ausführung auffallen.

Java Virtual Machine – JVM

Wie bei den Java-Applets werden auch Java-Servlets von einer virtuellen Java-Maschine (JVM) ausgeführt. Auf diese Weise wird der direkte Zugriff auf denSpeicher vermieden und somit werden Möglichkeiten für einem Systemcrashminimiert. Bei Problemen werden Ausnahmen erzeugt, die von den Anwen-dungen behandelt oder abgefangen werden können.

Plattformunabhängigkeit

Da Servlets als Java-Klassen realisiert werden, gelten natürlich auch für Servletsdie allgemeinen Vorzüge der Sprache bezüglich der Übertragbarkeit auf ver-schiedene Plattformen und Serverumgebungen. Servlets können inzwischenauf fast allen marktgängigen Webservern eingesetzt werden. Entweder unter-stützen die Server den Einsatz von Servlets direkt oder mit Hilfe von entspre-chenden Add-Ons.

Seitengenerierung über Servlets

Was bisher zu Servlets gesagt wurde, zeigt diese Technik als mächtiges Instru-ment für die Generierung von dynamischen Webinhalten. Die Art und Weise,wie ein Servlet schließlich die sichtbare Antwort auf eine Anfrage erzeugt, kannaber nicht überzeugen.

Der HTML-Code, der schließlich für die Anzeige der Antwort auf dem Browserbenötigt wird, muss durch häufig unübersichtliche Folgen von Ausgabeanwei-sungen generiert werden, wie schon das folgende kleine Beispiel zeigt(Anrede.java):


1

2

3

4

5

6

7

8

9

10

11

12

13

14

import javax.servlet.*;import javax.servlet.http.*;public class anrede extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/html"); PrintWriter out = response.getWriter(); String name = request.getParameter("gast"); out.println("<HTML>"); out.println("<HEAD><TITLE>Gruss</TITLE></HEAD>"); out.println("<BODY>"); out.println("Guten Tag " + name); out.println("</BODY></HTML>"); }}

Der entscheidende Nachteil von Servlets ist offensichtlich: Eine klare Trennungvon Anwendungslogik und Präsentation bei der Entwicklung von Webanwen-dungen ist unmöglich. Selbst kleine Änderungen an der Darstellung einer Seiteerfordern, dass das Servlet neu kompiliert wird. Für die Entwicklung von Serv-lets werden zudem Programmierer benötigt, die mit Java umgehen können.Die Webdesigner können mit dieser Form der Seitengestaltung in der Regelaber nicht glücklich werden. Alternativen waren also gefragt.

1.3.4 Active Server Pages

Um die Entwicklung von dynamischen Webanwendungen zu vereinfachen,führte Microsoft auf der Basis seines Internet Information Servers (IIS) dieActive Server Pages (ASP) ein. Dabei handelt es sich um Webseiten, bei denender normale HTML-Code mit Einschüben aus Skriptelementen gemischt ist.

Anders als bei Lösungen mit Skriptelementen, die direkt im Browser aktiviertwerden, etwa mit JavaScript oder VBScript, geht es hier aber um Skripte, dieauf dem Server ausgeführt werden, um auf der Basis des HTTP-Protokolls dyna-mische Antwortseiten zu erzeugen, die an den Webbrowser zurückgegebenwerden.

Webentwickler bewegen sich dabei über weite Strecken in ihrer vertrautenHTML- oder auch DHTMLWelt. Nur an den Stellen, an denen dynamischeInhalte verlangt werden, sind spezielle Blöcke mit Skriptcode nötig. Sie werden


jeweils durch die Begrenzer <% und %> von den HTML-Elementen abgesondert.Das kleine Beispiel zeigt, wie dies aussehen kann:

<%@ LANGUAGE="VBSCRIPT" %><% Response.Expires=0 %><html> <head> <title>Zeitansage</title> </head> <body> <h2>Die aktuelle Zeit ist: <%= Now%></h2> </body></html>

Als Skriptsprache wird meistens VBScript oder JScript verwendet, obwohl dieLaufzeitumgebung im Prinzip auch von anderen Sprachen wie Perl oder Pythongenutzt werden kann. Der Webserver reicht die Aufrufe von ASP-Seiten an eineISAPI-Servererweiterung weiter, die dafür sorgt, dass das ASP-Dokument vonder ASP.DLL interpretiert wird. COM-Komponenten können über die Skript-elemente eingebunden werden, um komplexere Aufgaben zu erledigen.

Diese Technik führte zu einer spürbaren Vereinfachung, wenn es darum ging,Websites mit dynamischen Inhalten zu erzeugen. Wesentlichster Nachteil waraber die Einschränkung durch die Bindung an die Windows-Plattform, auchwenn es mit Produkten wie Chili!Soft ASP von Sun und InstantASP von Hal-cyon Software eine begrenzte Unterstützung für andere Plattformen gab.

1.3.5 Von Servlets zu JavaServer Pages

Auf der Basis des Java Servlet-APIs führte schließlich auch Sun 1998 eine Lösungein, die eine bessere Trennung von Webseitendesign und Programmierung vonAnwendungslogik erlaubt: die JavaServer Pages, abgekürzt JSP. Dabei werden dieVorteile der Servlet-Lösung insofern beibehalten, als JSPs auf dem Webserverautomatisch in Servlets übersetzt und als Servlets ausgeführt werden.

Zudem können Webanwendungen Servlets und JSPs auch mischen. Dies wirdin neuen Anwendungsarchitekturen wie Struts genutzt, die eine strenge Tren-nung zwischen der Anwendungslogik, der Steuerung der Aufgabenverteilungund der eigentlichen Datenpräsentation vornehmen, wobei Servlets für die bei-den ersten Bereiche und JSP für die Darstellung auf dem Client eingesetzt wer-den. Dies ist insbesondere bei großen Unternehmensanwendungen sinnvoll,die von Entwicklerteams realisiert und gepflegt werden. Mehr dazu inAbschnitt 1.4 und 5.6.


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Abbildung 1.4 Von der JSP über das Servlet zur HTML-Ausgabe

Der Schwerpunkt dieses Einstiegs liegt auf der JSP-Technologie. Das Servlet-API, das ja bei der Ausführung von JSPs direkt zum Einsatz kommt, wird alsohier im Wesentlichen nur im Zusammenhang mit JSP behandelt.

Es ist kein Geheimnis, dass die »aktiven Seiten auf dem Server« in vielen ihrerMerkmale auch für die JavaServer Pages Pate gestanden haben. Das voneinan-der Lernen ist schließlich die Basis jeden Fortschritts. Ähnlich wie bei einerASP-Seite wird der normale HTML- oder XHTML-Code, der für das Äußere derSeite sorgt, durch abgesonderte Inseln mit JSP-Elementen erweitert. Diese sor-gen dafür, dass auf der Seite des Servers eine bestimmte Verarbeitung ausge-führt wird, die in die statische HTML-Seite den Inhalt von dynamischen Ele-menten einfügt.

1.3.6 Arbeitsteilung zwischen Programmierung und Seitendesign

Während die HTML-Elemente in einer JSP so, wie sie sind, in der Ausgabe wie-dergegeben werden, stoßen die JSP-Elemente auf dem Webserver Verarbei-tungsprozesse an, von deren Ergebnis dann abhängt, was an der Stelleerscheint, an der die Elemente stehen. Wenn also beispielsweise ein JSP-Ele-ment eine Datenbank auf dem Server mit einem bestimmten Kriterium abfragt,erscheinen die bei dieser Abfrage gefundenen Datensätze an der entsprechen-den Stelle.

Um solche dynamischen Lösungen zu ermöglichen, stellt JSP zunächst eineReihe von Standardelementen zur Verfügung, Aktionen für typische Aufgaben,Direktiven oder Skriptelemente. Seit der JSP-Version 1.1 wird zusätzlich ein


Erweiterungsmechanismus angeboten, der mit Hilfe von benutzerdefiniertenAktionen und von JavaBeans oder Enterprise JavaBeans den Entwicklern einweites Feld öffnet. Durch solche Komponenten lassen sich auch komplexeAbläufe so kapseln, dass Designer, die diese in ihre Seite einbauen, über dieDetails nicht viel wissen müssen. All dies erleichtert die Arbeitsteilung, wenngroße Sites in Teams aus Designern und Programmierern zu realisieren sind.

Es soll aber nicht unerwähnt bleiben, dass die Mischung von HTML- und JSP-Elementen in umfangreichen JSP-Anwendungen auch leicht zu einer unüber-sichtlichen Situation führen kann. Die Anordnung der verschiedenen Elementeist in keiner Weise vorgeschrieben, kann also auch weniger gelungen sein. Insolchen Fällen wird vor allem die Fehlersuche zu einem harten Job. Auch diePflege solcher Sites kann Kopfschmerzen bereiten. Oft ist es deshalb ratsam,eine Anwendung modular aus kleineren Komponenten aufzubauen, die sicheinzeln testen lassen. Hier kann insbesondere das Model-View-Controller-Modell helfen, das im nächsten Abschnitt beschrieben wird.

1.3.7 Was spricht für JSP?

Zu den Vorteilen, die JSP gegenüber ASP vorweisen kann, gehört gewiss dieVerwendung von Java, wodurch die Implementierung von Webanwendungenauf unterschiedlichen Plattformen entscheidend vereinfacht wird. Die meistenpopulären Webserver sind in der Lage, entweder direkt oder indirekt durchentsprechende Add-Ons JSP-Lösungen zu beherbergen. Virtuelle Java-Maschi-nen stehen auf allen Plattformen zur Verfügung. Außerdem ist Java eine kom-plette Programmiersprache, unterliegt also nicht den Einschränkungen, die fürSkriptsprachen typisch sind.

Ein wesentliches Merkmal von JSP ist die Erweiterbarkeit. Die Erweiterungs-mechanismen sind gerade in der neuen JSP-Version noch einmal ausgebautund zugleich vereinfacht worden. Dabei werden insbesondere auch die Vor-teile der allgemein anerkannten XML-Standards genutzt.

Eine Besonderheit von JSP ist sicher auch, dass es sich um eine Spezifikationhandelt und nicht um ein fertiges Produkt. Es gibt zwar eine Referenzimple-mentierung für jede JSP-Version, deren Zweck es ist, am praktischen Beispiel zuklären, wie spezielle Merkmale der Spezifikation in der Praxis anzuwendensind. Unabhängig davon aber können Anbieter eigene Implementierungen derSpezifikation entwickeln und dem Sturm der Konkurrenz aussetzen.

Die Auseinandersetzung um die beste Lösung für die angesprochenen Pro-bleme ist natürlich überhaupt nicht abgeschlossen. In mancher Hinsicht istASP.NET – der Nachfolger von ASP – wiederum als Antwort auf die Merkmale

39Anwendungsgebiete und -modelle

1

2

3

4

5

6

7

8

9

10

11

12

13

14

zu verstehen, die JSP über ASP hinausgeführt haben. Beispielsweise werdenASP.NET-Seiten nun auch vor der Ausführung kompiliert, was deutlicheGeschwindigkeitsgewinne gegenüber interpretierten Skripten erlaubt. BeideTechnologien konkurrieren auf einem hohen Level miteinander, der Sachekann das nur gut tun.

1.4 Anwendungsgebiete und -modelle

Um in statische Webseiten dynamische Elemente einzubauen, stehen eineReihe von Verfahren auf der Client-Seite und auf der Serverseite zur Verfügung.Manche Aufgabe kann sowohl auf der einen als auch auf der anderen Seitegelöst werden.

1.4.1 JSP oder DHTML?

Anwendungen auf der Serverseite sind sicher immer dann zu bevorzugen,wenn es um Seiten geht, die auf umfangreiche Datenbestände zugreifen. SolcheJSP-Lösungen sind auch innerhalb von Intranets effektiv.

Natürlich könnte ein Versandhaus seinen digitalen Katalog im Prinzip auchzum Download anbieten, so wie es ja auch gedruckte Kataloge an den Kunden-stamm verschickt. Das hat aber, abgesehen von den Übertragungskosten, denNachteil, dass diese Kataloge nur durch ständige Updates aktuell gehalten wer-den. Wird dagegen ein Katalog auf dem Server gepflegt, greifen alle Clientsimmer auf den aktuellen Katalog zu.

Es gibt aber viele weniger umfangreiche Funktionen, die sich sowohl auf derClient-Seite als auch auf der Serverseite bereitstellen lassen. Auch bei Funktionen,die sich ohne jeden Nachteil etwa mit Skripten beim Client realisieren lassen,kann es trotzdem sinnvoll sein, sie über Webanwendungen auf dem Server zurealisieren. Dadurch wird beispielsweise vermieden, dass eine solche Funktionfür den Webbesucher nicht verfügbar ist, wenn er in seinem Browser die Ausfüh-rung etwa von JavaScripts aufgrund von Sicherheitsbedenken unterbindet.

1.4.2 Das Designmodell Model-View-Controller

Umfangreichere Webanwendungen enthalten fast immer eine Formularkom-ponente, in die der Besucher Eingaben macht, die anschließend auf der Server-seite geprüft werden, bestimmte Verarbeitungsschritte einleiten – wie dieAbfrage einer Datenbank – und schließlich in einer von diesen Schrittenbestimmten Antwort des Servers an den Client enden.

Solche typischen Abläufe lassen sich gut in einem Designmodell gruppieren,das mit der Abkürzung MVC für Model-View-Controller benannt wird. Das


Modell wurde schon in den spätern 80ern im Zusammenhang mit der Pro-grammiersprache Smalltalk vorgestellt. Die Grundidee ist eine saubere Tren-nung von drei Aufgabenbereichen, die sich bei jeder Anwendung, die mit einerBenutzerschnittstelle arbeitet, unterscheiden lassen. Jeder Bereich wird dabeiin einem Objekt zusammengefasst:

� Das Model-Objekt liefert das Datenmodell für die Vorgänge, um die es geht,und die Regeln dafür, wie diese Daten verwendet werden sollen. Dieses Objektvereint die logische Seite der Anwendung in sich, wobei von der Frage, wieDaten vom Benutzer eingegeben werden und wie die Ergebnisse der Daten-verarbeitung präsentiert werden sollen, zunächst ganz abgesehen wird.

� Das View-Objekt ist für die visuelle Präsentation der Daten zuständig. Dazumuss ihm bekannt sein, mit welchen Methoden die Daten des Model-Objekts ausgelesen werden und wie diese Daten durch das Controller-Objekt geändert werden können.

� Das Controller-Objekt ist für die Verarbeitung der vom Benutzer vorgenom-menen Eingaben zuständig. Es sitzt gewissermaßen zwischen dem View-und dem Model-Objekt. Wenn auf der Benutzerebene über ein Steuerele-ment z.B. ein angezeigter Wert verändert wird, sorgt das Controller-Objektdafür, dass diese Änderung an den Daten des Model-Objekts vorgenommenwird. Umgekehrt werden innerhalb des Model-Objekts neu berechneteDaten über das Controller-Objekt wieder an das View-Objekt zurückgege-ben, sodass sich die angezeigten Daten entsprechend ändern.

Bei unternehmensweiten Anwendungen ist es in der Regel sinnvoll, sie alsZusammenspiel von mehreren Komponenten zu realisieren, die sich demModell entsprechend auf eine der Aufgaben konzentrieren.

Abbildung 1.5 MVC in der Übersicht

41Von JSP 1.2 nach JSP 2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

Durch eine klare Trennung der verschiedenen Rollen wird es möglich, eine Ver-änderung an der Benutzeroberfläche vorzunehmen, ohne dass sich an demModel-Objekt etwas ändern muss. Einem Model-Objekt können mehrereView-Objekte zugeordnet werden, die beispielsweise die Dateneingabe überunterschiedliche Instrumente abwickeln.

Umgekehrt bleibt die Präsentation der Daten durch das View-Objekt von Ände-rungen in den Berechnungsverfahren des Model-Objekts unberührt. Dagegensind die View- und Controller-Objekte in der Regel enger verzahnt. Zu jedemView-Objekt muss es ein Controller-Objekt geben. Dieses Paar stellt die Benut-zeroberfläche der Anwendung dar, also das, was auch »look and feel« genanntwird.

Hilfreich ist zudem die Auslagerung von Funktionen, die in mehreren JSPsbenötigt werden, etwa Suchfunktionen oder Login-Verfahren, die in separatenKomponenten eingeschlossen werden können.

Welche Komponenten einer Webanwendung jeweils eine der drei Rolleninnerhalb dieses Modells übernehmen, kann je nach den Anforderungen ganzunterschiedlich sein. Der Entwicklung steht hier jedenfalls eine große Band-breite von Lösungen offen, weil JSP 2.0 mit der Unterstützung von JavaBeans,Tag-Bibliotheken und Tag-Dateien mehrere Methoden anbietet, Funktionen inKomponenten zu kapseln. Außerdem besteht immer die Möglichkeit, JSP-Lösungen und originäre Servlets miteinander zu verknüpfen.

In unternehmensweiten Anwendungen wird es häufig sinnvoll sein, JSP in ers-ter Linie für die View-Rolle, also für die Präsentation und Eingabe von Daten ander Benutzeroberfläche zu verwenden, für die Model-Rolle mit JavaBeans oderEnterprise JavaBeans zu arbeiten und als Controller Servlets zu nutzen. Dabeikann die View-Rolle beispielsweise auch durch eine bestimmte Abfolge vonJSPs realisiert werden.

Da es in vielen Webanwendungen eine ganze Reihe von immer wiederkehren-den Aufgabenstellungen gibt, entwickelt sich hier ein Markt für Komponenten,der nicht nur Sammlungen von benutzerdefinierten Aktionen anbietet, son-dern Frameworks wie Struts, die gleich ein Grundgerüst liefern, das für denkonkreten Bedarf aufgefüllt werden kann. Wenigstens einen Blick darauf fin-den Sie in Abschnitt 5.6.

1.5 Von JSP 1.2 nach JSP 2

Ursprünglich sollte auf JSP 1.2 eine Spezifikation mit der Nummer 1.3 folgen,doch im Laufe des Verfahrens entschied sich die verantwortliche JSR 152-Expertengruppe, Teil von JCP (die Abkürzung steht für Java Community Pro-


cess), für die Nummer 2.0, um deutlich zu machen, dass die neue Version ganzmaßgebliche Veränderungen gegenüber den bisherigen Verfahren der Erstel-lung von dynamischen Webinhalten erlaubt. Wen die Arbeit der Gruppe inter-essiert, der findet über www.jcp.org Näheres.

Wie schon so oft in der Software-Industrie steht die neue Version unter derHauptforderung, es den Anwendern leichter machen zu sollen als bisher. Indiesem Fall insbesondere den Webdesignern, die die Java-Programmierungnicht als ihre Sache betrachten. Inwieweit dies allerdings gelungen ist, musssich erst noch in der Praxis erweisen.

1.5.1 Plattform und Servlet-API

JSP 2.0 erweitert die bisherige Spezifikation, um die Funktionalität der Java 2-Plattform in der Standard Edition 1.4 und in der Enterprise Edition 1.4 voll aus-nutzen zu können. Außerdem wird das Servlet-API genutzt, das der Servlet-Spezifikation 2.4 entspricht. Diese Version ist eine konservative Erweiterungder Version 2.3. Sie erlaubt die Verwendung von Filtern nun auch in Zusam-menhang mit Request-Dispatchern. Die Unterstützung von HTTP/1.1 ist jetztvorgeschrieben. Für Deployment-Deskriptoren wurde ein XML-Schema defi-niert.

1.5.2 JSTL und andere Tag-Bibliotheken

Das Hauptmotiv für den Entwurf der JSP 2.0-Spezifikation war der Wunsch,die Entwicklung von dynamischen Webseiten zu vereinfachen. Die Notwendig-keit für Webdesigner, sich mit dem Schreiben von Skripten in Java-Code zuquälen, sollte weitgehend entfallen, auch wenn die Möglichkeit dazu weiterunterstützt wird. Die entsprechende Funktionalität wird dazu in Tags verpackt,die ihm von der Arbeit mit HTML oder XHTML vertraut sind. Die Innereienvon Java können dem Designer auf diese Weise verborgen bleiben.

Eine wesentliche Rolle spielt hier die im Rahmen des Jakarta-Projekts entstan-dene JavaServer Pages Standard Tag Library (JSTL), die inzwischen vom JCPspezifiziert und als verbindliche Lösung für viele typische Standardaufgaben indynamischen Webseiten eingesetzt werden kann.

Gleichzeitig ist die Erweiterbarkeit von JSP durch eigene oder auf dem Marktverfügbare zusätzliche Tag-Sammlungen weiter ausgebaut worden.

1.5.3 Expression Language

Die zunächst im Rahmen des JSTL-Projekts entwickelte Expression Language(EL) wurde aus der neuen Version 1.1 der JSTL-Spezifikation ausgekoppelt, um

43Von JSP 1.2 nach JSP 2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

sie auch unabhängig von der Tag-Bibliothek verwenden zu können. EL wurdenun direkt in die JSP 2.0-Spezifikation integriert, ein entsprechendes EL-APIwurde dem JSP-API hinzugefügt.

Die Sprache wurde für JSP 2.0 um die Unterstützung von Funktionen erwei-tert. EL ist in Anlehnung an JavaScript und XPath entstanden und dazu gedacht,die bisher in Form von Skriptelementen verwendeten Ausdrücke zu ersetzen.EL-Ausdrücke in der Form ${ausdruck} können jetzt auch direkt innerhalb desTemplate-Textes einer JSP vorkommen. Besonders komfortabel ist, dass sichAttributwerte in Aktionen – seien es Standardaktionen oder Aktionen auszusätzlichen Bibliotheken –, die erst bei der Ausführung der Seite bestimmtwerden, über solche Ausdrücke definieren lassen. Die Sprache erlaubt insbe-sondere auch einen einfachen Zugriff auf die Eigenschaften von JavaBeans.

1.5.4 Simple Tag-Handler

Zusätzlich zu dem bisher verwendeten Aufrufprotokoll für Tag-Handler, das aufdie Verwendung von Java-Code zugeschnitten ist, führt JSP 2.0 ein vereinfach-tes Protokoll für Tag-Erweiterungen ein, das Simple Tag Extension genanntwird.

Dieses Protokoll ist in der Erwartung entwickelt, dass in Zukunft bei der Gestal-tung von dynamischen Webinhalten ganz auf Skriptelemente in JSPs verzichtetwerden kann. Dabei wird es den Autoren solcher Erweiterungen freigestellt,diese auf der Basis von Java-Klassen oder auch direkt in JSP zu definieren.Dafür wird das Konzept der JSP-Fragmente verwendet, die Teilfunktionen ineiner Form kapseln, die sie wiederverwendbar macht.

1.5.5 Tag-Dateien

Neben dem schon bekannten Erweiterungsmodell auf der Basis von Tag-Bibli-otheken wird in JSP 2.0 deshalb parallel eine vereinfachte Form, eigene Tags indie JSP einzubringen, eröffnet, die spezielle Tag-Dateien verwendet. Diesebestehen ausschließlich aus JSP-Elementen, enthalten also keinen Java-Code,sodass auch Designer, die keine Java-Kenntnisse mitbringen, eigene Tags fürwiederholt benötigte Funktionen definieren können.

1.5.6 JSP als XML-Dokument und XML-Views

Ein allgemeiner Zug der neuen Version ist die deutliche Ausrichtung an XML alsBasistechnologie. Die Autoren von JSP-Anwendungen werden dazu ermuntert,JSPs direkt als vollwertige XML-Dokumente zu editieren, um die Vorteile vonWerkzeugen nutzen zu können, die XML unterstützen. Gleichzeitig wird intern


bei der Verarbeitung von JSPs mit einer automatisch generierten XML-Sichtauch der JSPs gearbeitet, die in der älteren Standardsyntax geschrieben sind,wenn Validatoren für die verwendeten Tag-Bibliotheken eingesetzt werden.

1.5.7 Neue Standardaktionen und dynamische Attribute

JSP 2.0 erweitert auch die Liste der Standardaktionen, insbesondere um dieElemente <jsp:attribute> und <jsp:body>. Mit Hilfe dieser Elemente lassensich Werte im Rumpf einer Aktion definieren, anstatt sie im Start-Tag derAktion unterzubringen. Das ist besonders in Zusammenhang mit Attributenvon Bedeutung, deren Name erst während der Ausführung der Seite dynamischzugewiesen wird. Dynamische Attribute sind ebenfalls eine wichtige Erweite-rung von JSP. Dafür wurde in dem Paket javax.servlet.jsp.tagext ein spe-zielles DynamicAttributes-Interface eingeführt.

1.6 Allgemeine Merkmale von JSP

JSP-Anwendungen sind Webanwendungen auf der Basis des HTTP-Protokolls.Um eine solche Webanwendung auszuführen, ist eine wesentlich komplexereUmgebung notwendig als bei einem Programm, das für einen lokalen Rechnergeschrieben ist. Bevor die syntaktischen Details der JSP-Programmierung zumThema werden, soll deshalb ein kurzer Überblick darüber gegeben werden,was überhaupt beim Aufruf von JSP-Anwendungen geschieht.

1.6.1 Laufzeitumgebung für JSP

Wenn Autoren eine einfache Webseite in HTML oder XHTML veröffentlichen,legen sie diese Seite auf einem Webserver ab. Wird von irgendeinem Browserdie Adresse dieser Seite eingegeben, liefert der Server als Antwort auf dieAnfrage die gewünschte Seite genau so an den Client aus, wie die Autoren sieauf den Server gelegt haben.

Bei den JavaServer Pages ist auf der Seite des Servers mehr zu tun, als nur dieangeforderte Seite abzuliefern. Zunächst wird auch die JSP von den Autorenauf dem Webserver abgelegt. Damit eine JSP ausgeführt werden kann, reichendie Funktionen, die ein Webserver beim Aufruf von statischen HTML-Seitenanbietet, aber nicht aus.

Es wird eine Laufzeitumgebung benötigt, die mit JSPs etwas anfangen kann.Auf dem Server wird dazu ein JSP-Container benötigt, eine Servererweiterungfür den Umgang mit JSP. Dieser Container sorgt dafür, dass eine JSP in ein Serv-let übersetzt wird, das dann wie ein originäres Servlet ausgeführt werden kann.Der JSP-Container wird häufig selbst als ein spezielles Servlet implementiert,

45Allgemeine Merkmale von JSP

1

2

3

4

5

6

7

8

9

10

11

12

13

14

das für die Ausführung von JSPs konfiguriert ist und innerhalb eines Servlet-Containers ausgeführt wird. In anderen Fällen werden ein Servlet-Containerund ein JSP-Container auch zu einem Paket kombiniert, das dann insgesamt alsWeb-Container bezeichnet wird, so wie es auch die JSP 2.0-Spezifikation tut.

Die JSP-Technologie ist in diesem Sinne also als eine Erweiterung der Servlet-Technologie zu verstehen, weshalb es zwischen Servlets und JSP-Lösungenauch grundlegende Gemeinsamkeiten gibt, auch wenn der Quellcode einesServlets und der Text einer JSP ziemlich verschieden aussehen.

Ein solcher Servlet-Container kann in verschiedenen Formen realisiert werden. Erkann Teil eines Webservers oder Teil eines Applikationsservers sein. Im ersten Fallist er entweder direkt in den Webserver integriert oder er wird durch eine Add-on-Komponente eingebunden, wenn der Webserver selbst keine genuine Unterstüt-zung für Servlets zur Verfügung stellt. Das ist z.B. bei Apache und bei IIS der Fall.

Ein Container kann aber auch, wie es beispielsweise für Tomcat gilt, als Standa-lone-Server betrieben werden, der neben normalen HTTP-Funktionen eineLaufzeitumgebung für Servlets und JSPs zur Verfügung stellt. Der Server kannohne Probleme parallel zu anderen Webservern betrieben werden, solange mitunterschiedlichen Parts gearbeitet wird.

In jedem Fall muss ein JSP-Container das HTTP-Protokoll unterstützen, wobeidie Versionen HTTP/1.0 und 1.1 verlangt werden. HTTPS kann hinzukommen.

1.6.2 Einbindung in J2EE

Wie die schon kurz angesprochene Servlet-Technologie sind auch die JavaSer-ver Pages Teil der Software-Architektur Java 2 Enterprise Edition. Sun Micro-systems hat die Java-Welt 1999 neu geordnet, und die gesamte Masse der dazu-gehörenden Klassenbibliotheken und Pakete in drei Editionen gruppiert:

� J2SE ist die Standard-Edition mit den Standard-APIs, die in erster Linie fürlokale Desktop-Anwendungen und für Applets, also Komponenten auf derClient-Seite benötigt werden.

� J2EE fügt auf der Basis von J2SE zahlreiche Erweiterungen für die Serverseitehinzu, um webbasierte, mehrschichtige unternehmensweite Anwendungenauf der Basis des HTTP-Protokolls zu ermöglichen. Dazu gehört in erster Liniedie Einführung von Enterprise JavaBeans (EJB), einer Architekturspezifika-tion für Serverkomponenten, die mehrschichtige Anwendungen in Java ver-einfachen, indem grundlegende technische Aspekte wie Transaktions- undZustandsverwaltung, Persistenz, Sicherheit, Nebenläufigkeit und Ressourcen-verwaltung bereits durch den EJB-Container gewährleistet werden.


� J2ME, die Micro-Edition ist eine für den Einsatz auf mobilen Geräten wiePDAs, Handys und Pager und in Embedded Systems wie Navigationssyste-men abgespeckte Version, deren Kern ein spezielle Variante der Java VirtualMachine, die Kilobyte Virtual Machine (KVM) ist.

Die J2EE-Spezifikation, die hier vor allem interessiert, definiert einen Stan-dard, der sich aus einer Anzahl notwendiger APIs und allgemeiner Richtlinienergibt, die durch einen Applikationsserver unterstützt werden müssen, wenner die Einstufung »J2EE-kompatibel« erhalten will.

J2EE ist kein abgeschlossenes Produkt, sondern die Definition eines Rahmensfür Anwendungen auf der Basis eines Komponentenmodells im Sprachraumvon Java.

Wesentliches Merkmal von J2EE ist, dass die für konkrete Lösungen benötig-ten Komponenten durch beschreibende Konfigurationsdateien in vielfältigerWeise angepasst werden können, ohne eine Zeile des Quellcodes ändern zumüssen. Diese so genannten Deployment-Deskriptoren werden in Form vonXML-Dokumenten gepflegt, für die verbindliche XML-Schemas definiert sind.Auch die Übertragung von Lösungen auf einen anderen J2EE-Server kann imPrinzip ohne Anfassen des Quellcodes allein durch Anpassungen der Deskrip-toren vorgenommen werden.

Als Laufzeitumgebung für J2EE-Anwendungen werden Container verwendet –Servlet- und JSP-Container beispielsweise –, die den Lebenszyklus der darinangesiedelten Webkomponenten steuern und ihnen standardisierte Dienstezur Verfügung stellen. Die Arbeitsaufteilung zwischen Container und Kompo-nente, die auch Kontrakt genannt wird, ist durch entsprechende Interfaces spe-zifiziert, etwa das Interface Servlet, das festlegt, in welcher Abfolge der Serverin eigener Regie und nicht durch den Anwendungscode die benötigten Metho-den aufruft. Jede J2EE-Implementierung muss also den einzelnen Webanwen-dungen die gleichen Dienste zur Verfügung stellen. Dabei werden die in denKonfigurationsdateien abgelegten Informationen automatisch umgesetzt.

Ergänzt wird die J2EE-Spezifikation durch die J2EE-Blueprints (Rezepte undDesignmuster für J2EE-Anwendungen), siehe java.sun.com/blueprints/enterprise, ein J2EE-Server als Referenzimplementierung, der für nichtkom-merzielle Tests genutzt werden kann (java.sun.com/j2ee/download.html)und eine J2EE-Testsuite, mit der die Kompatibilität von neuen Anwendungenüberprüft werden kann. Unter java.sun.com/j2ee/compatibility.html wer-den alle Produkte gelistet, die diesen Test bestanden haben.

Da JSP vollständig in J2EE eingebunden ist, stehen zahlreiche Dienste der Platt-form und die dazugehörigen APIs den Webanwendungen zur Verfügung. Die


1

2

3

4

5

6

7

8

9

10

11

12

13

14

folgende Tabelle gibt einen kurzen Überblick über wichtige Programmier-schnittstellen, die zu J2EE 1.4 gehören bzw. bereits durch J2SE 1.4 zur Verfü-gung stehen:

API Beschreibung

JDBC 3.0 Standardschnittstelle für den Zugriff auf Datenbanken mit Hilfe von Datenbanktreibern

Servlet-API 2.4 Schnittstelle, die von allen Servlets implementiert und die auch für die Ausführung von JavaServer Pages verwendet wird

JSP 2.0 Schnittstelle, um JSP-Elemente in eine Webseite zu integrie-ren, die dynamische Inhalte ermöglicht

Enterprise JavaBeans (EJB) 2.1

Erweiterung der JavaBean-Komponententechnik für unter-nehmensweite, mehrschichtige Anwendungen

Java Naming and Directory Interface (JNDI) 1.2

Gemeinsame Schnittstelle, über die Java-Programme J2EE-Namens- und Verzeichnisdienste nutzen können oder auch LDAP oder NDS. Dadurch kann auf Objekte und Ressourcen jeder Art mit Hilfe von logischen Namen zugegriffen wer-den.

Java Message Service (JMS) 1.1

Ein offener Standard, der den Zugriff auf Message Oriented Middleware (MOM) in Java-Anwendungen erlaubt

Java Transaction API (JTA) 1.0

Schnittstelle zur Interaktion mit einem Transaktionsmana-ger

Java Connector Architecture (JCA) 1.5

Schnittstelle für die Anbindung von Enterprise Information Systems (EIS) an J2EE-Anwendungen

Java API for XML Processing (JAXP) 1.2

Integriert XML-Parser in J2EE-Anwendungen und imple-mentiert den XSLT-Standard

JavaMail 1.3 Schnittstelle für den E-Mail-Versand und Empfang

JavaBeans Activation Frame-work (JAF)

Bestimmt den Typ von Daten aufgrund der MIME-Spezifika-tion und kann entsprechende Viewer starten. Wird für Java-Mail benötigt.

Java Authentication & Authorization Service (JAAS)

Stellt Verfahren zur Authentifizierung und zur Zugriffskont-rolle zur Verfügung. Basiert auf dem unter UNIX verwende-ten Pluggable Authentication Modules.

JAX-RPC 1.1 Schnittstelle für die Nutzung von Webdiensten auf der Basis von WSDL und SOAP

JAXP 1.2 Das Java API for XML Parsing macht J2EE unabhängig von konkreten Parsern und XSLT-Prozessoren.

JAXR 1.0 Das Java API for XML Registries erlaubt den Zugriff auf UDDI und andere Repositorien.


Es soll allerdings nicht verschwiegen werden, dass der Umgang mit den oft tiefgestaffelten Kompontenhierarchien in der Java-Welt nicht zu unterschätzendeAnforderungen an die Entwicklung von Anwendungen stellt. Wettbewerbe mitGedächtniskünstlern sind nicht die erste Aufgabe von Website-Entwicklern.Dokumentationen mit einfachen Navigationselementen, »intelligente« Edito-ren und Entwicklungsumgebungen sind deshalb dringende Erfordernisse füreine effektive Arbeitsweise.

1.6.3 Aufbau einer JSP

Ohne hier schon auf Details der Standardsyntax einzugehen, lässt sich der Aufbaueiner JSP in den meisten Fällen als eine Mischung aus speziellen JSP-Elementenund Nicht-JSP-Elementen beschreiben, wobei es sich meist um HTML-Code odereinfachen Text handelt. Der Zweck einer JSP ist dabei immer, exakt zu beschrei-ben, wie eine Anfrage verarbeitet und eine Antwort erzeugt werden soll.

In der folgenden Abbildung wird an einem kleinen JSP-Beispiel die Anordnungder unterschiedlichen Elemente durch Markierungen verdeutlicht. Es ist gleichsichtbar, dass die verschiedenartigen Bestandteile der Seite nicht etwa in zweiabgesonderte Bereiche eingeordnet werden müssen, sondern über die Seiteverstreut werden können. Der dynamische Inhalt einer Seite wird genau an derStelle in der Abfolge der Seitenelemente beschrieben, an der er in der Antwort,die der Server generiert, erscheinen soll. Die Reihenfolge von statischen unddynamischen Inhalten wird also durch das Layout der Seite bestimmt.

Abbildung 1.6 JSP mit Template-Daten und JSP-Elementen (grau markiert)

SAAJ 1.2 Das SOAP with Attachments API for Java erlaubt die Bil-dung und Verarbeitung von Meldungen, die dem SOAP 1.1-Standard entsprechen.

JSEE Connector Architec-ture 1.5

Erlaubt die Bildung von Ressourcen-Adaptern, um auf belie-bige betriebliche Informationssysteme zugreifen zu können

API Beschreibung


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Diese JSP erzeugt folgende Ausgabe, wenn sie über den Browser aufgerufenwird:

Abbildung 1.7 Ausgabe der Seite mit statischen und dynamischen Bestandteilen

In dem Beispiel werden neben dem HTML-Code eine page-Direktive und eineStandardaktion verwendet, die auf eine JavaBean zugreift, also auf eine Kom-ponente, die außerhalb der JSP definiert ist. Schließlich ist noch ein Ausdruckder neuen Expression Language (EL) enthalten, der für die Ausgabe der Zeitan-gaben sorgt.

1.6.4 Übersetzungsphase

Was geschieht nun, wenn diese Seite, vorausgesetzt, sie ist auf einem Serververöffentlicht, von einem Browser angefordert wird? Wird eine Anfrage füreine JSP von einem Browser abgeschickt, nimmt der auf der Seite des Serversaktive JSP- oder Web-Container – die JSP-Spezifikation verwendet diese beidenBegriffe synonym – die Anfrage entgegen.

Wird die JSP zum ersten Mal aufgerufen, übersetzt der Container aus dem Textder JSP zunächst den Java-Quellcode für ein entsprechendes Servlet und legtihn in einer .java-Datei ab. Anschließend kompiliert er daraus eine Servlet-Klasse und legt sie in einer .class-Datei ab. Dies geschieht automatisch. Über-setzung und Kompilierung zusammen werden als Übersetzungsphasebezeichnet. In dieser Phase können Fehler entdeckt werden, die aber erst ange-zeigt werden, wenn versucht wird, die JSP auszuführen.

Dabei wird für alle JSP-Elemente der entsprechende Java-Code übernommen,um durch die Verarbeitung dieses Codes die dynamischen Bestandteile derSeite zu erzeugen. Dagegen werden die Bestandteile, die keine JSP-Elementesind, in die schon angesprochenen Java-Ausgabeanweisungen übersetzt, mitdenen die entsprechenden statischen Elemente in der Antwort des Servers aufdie eingegangene Anfrage fixiert werden.


Abbildung 1.8 Übersicht über die Verarbeitung einer JSP-Anfrage

1.6.5 Die JSP-Implementierungsklasse

Die aus der JSP generierte Servlet-Klasse wird JSP page implementation classgenannt. Der genaue Name der erzeugten Klasse ist von der Implementierungabhängig. Das JSP-Implementierungsobjekt ist dabei Teil eines Pakets, dessenName ebenfalls von der gewählten Implementierung abhängig ist. (Stattdessenkann für eine Seite auch eine Oberklasse angegeben werden, von der die Klasseabzuleiten ist, und zwar durch ein spezielles extends-Attribut der page-Direk-tive, was in Abschnitt 3.3 beschrieben wird. Allerdings schränkt dieses Verfah-ren die Entscheidungsmöglichkeiten des JSP-Containers ein und sollte norma-lerweise gemieden werden. JSP 2.0 erlaubt es übrigens nicht, mit unbenanntenPaketen zu arbeiten, was bei der Übernahme von älteren Anwendungen, indenen so verfahren wurde, zu Fehlern führen kann.

Die JSP-Klasse implementiert im Kern das Interface javax.servlet.Servlet,das die grundlegenden Methoden enthält, die von Servlets beherrscht werdenmüssen. Anfragen werden deshalb genau so an diese Klasse zur Ausführungübergeben, wie es die Servlet 2.4-Spezifikation festlegt.


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Eine JSP-Implementierungsklasse kann von bestimmten Support-Klassenabhängig sein. Ist die Klasse in eine WAR-Datei verpackt, darauf wird inAbschnitt 4.2 noch im Detail eingegangen, muss jede dieser Klassen eingefügtwerden, damit das Paket zwischen allen JSP-Containern portabel bleibt.

Da die Frage/Antwort-Kommunikation zwischen Client und Server nur überein von beiden Seiten eingehaltenes Protokoll möglich ist, muss der JSP-Con-tainer außerdem sicherstellen, dass ein solches Protokoll verwendet wird. Inder Regel ist das HTTP, und deshalb muss die Implementierungsklasse dafürauch das Interface HttpJspPage implementieren, welches eine Erweiterungdes Interfaces JspPage ist.

Wird eine Seite, die schon kompiliert ist, später verändert, ist es Aufgabe desContainers, die Seite beim nächsten Aufruf neu zu kompilieren. Verwendeteine Seite Komponenten wie JavaBeans oder inkludierte Seiten, findet aller-dings nicht unter allen Umständen eine Neukompilierung statt. Mehr dazu inAbschnitt 3.14.

Die Übersetzungsphase kann auch vom Aufruf der JSP getrennt werden. Dazukann ein spezieller jsp_precompile-Parameter beim Aufruf der Seite verwen-det werden, der den Container veranlasst, die Seite zu übersetzen und zu kom-pilieren, ohne die darin enthaltene Anfrage auszuführen.

http://localhost:8080/einstiegjsp/Kapitel1/zeitAnsage.jsp?jsp_precompile=true

Diese Vorkompilierung hat den Vorteil, dass die durch die notwendige Überset-zung bedingte Verzögerung der Serverantwort beim ersten Aufruf einer JSPvermieden werden kann. Mehr dazu in Abschnitt 4.5.

1.6.6 Ausführungsphase

Ist durch die Übersetzung und Kompilierung ein Servlet erzeugt, das die JSPrepräsentiert, kann der JSP-Container alle Anfragen an das Implementierungs-objekt richten, das er als Instanz der JSP-Implementierungsklasse bildet. Dazuruft der Container das Servlet auf. Es mag so lange im Speicher bleiben, bis derServer heruntergefahren wird, sodass eine Serie von Anfragen verarbeitet wer-den kann, ohne einen neuen Prozess starten zu müssen.

Die Ausführung des Servers erzeugt schließlich auf der Basis der Daten undAnweisungen, die in der Anfrage enthalten sind, die Ausgabe, die als Antwortan den anfragenden Client zurückgeschickt wird. In diesem Prozess werdenhäufig noch andere Objekte erzeugt oder benutzt. Die JSP kann außerdemnoch festlegen, wie auf bestimmte Ereignisse reagiert werden soll. JSP 2.0


kennt allerdings nur die Ereignisse init und destroy, also den Moment, indem ein Servlet initialisiert wird, und den Moment, in dem das Implementie-rungsobjekt wieder zerstört wird.

Für jede eingehende Anfrage findet der JSP-Container jeweils die passendeInstanz der JSP-Implementierungsklasse und übergibt auf der Basis des Servlet-Protokolls die zugehörigen Anfragen. Die Servlet-Klasse definiert eine Art Kon-trakt zwischen dem JSP-Container und der JSP-Implementierungsklasse.

Da JSPs in der Regel das HTTP-Protokoll verwenden, wird dieser Kontraktdurch die HttpServlet-Klasse beschrieben. Der JSP-Container macht dabeiautomatisch eine Reihe von serverseitigen Objekten verfügbar, die impliziteObjekte genannt werden. Auf solche Objekte kann während der Ausführungder Seite über Skriptlets und Skriptausdrücke zugegriffen werden, etwa umDaten aus den Anfrage-Headern auszulesen oder um Statusinformationen abzu-fragen. Auch Ausdrücke der Expression Language haben Zugriff auf impliziteObjekte. Die JSP-Spezifikation ist im Prinzip auch für andere Protokolle offen.

Verarbeitung einer JSP durch den JSP-Container

Das Interface javax.servlet.Servlet stellt die Mittel bereit, damit ein Serv-let ausgeführt werden kann. Es stellt die Methoden zur Verfügung, um Ein-gangswerte für ein Servlet zu setzen, sorgt für die Bedienung der Anfragen undermöglicht es, das Servlet aus dem Speicher zu entfernen, wenn es seineDienstleistung abgeschlossen hat.

Wie dies genau geschieht, ist normalerweise Sache der jeweiligen JSP-Contai-ner-Implementierung, es sei denn, JSP-Autoren legen über das extends-Attri-but der page-Direktive eine andere Oberklasse fest. Diese muss dann gewähr-leisten, dass das Nötige geschieht.

Die Methodenabfolge regelt den Lebenszyklus

Stellt der Container eine Anfrage durch einen Client fest, wird das entspre-chende Servlet, wenn es noch nicht geladen ist, durch einen speziellen Klassen-lader in den Speicher geholt. Für jede Anfrage wird normalerweise ein eigenerThread verwendet, sodass auch mehrere Anfragen von einer einzigen Instanzder Implementierungsklasse parallel bearbeitet werden können.

Der Container ruft dabei die benötigten Methoden des Servlet-Objekts in einerbestimmten Reihenfolge automatisch auf. Diese Abfolge wird gern Lebenszyk-lus genannt. Für Servlets, die JSP-Implementierungsklassen sind, werden dabeivon Servlet abgeleitete Interfaces verwendet.


1

2

3

4

5

6

7

8

9

10

11

12

13

14

Über das Interface JspPage stehen die Methoden jspInit() und jspDestroy()zur Verfügung, die der Autor einer JSP überschreiben kann. Über das InterfaceHttpJspPage, die JspPage erweitert, kommt die jspService()-Methode hinzu,um die Kommunikation zwischen Client und Server zu steuern. Diese Methodewird durch den JSP-Container automatisch definiert, und zwar aufgrund desInhalts der JSP. Der JSP-Autor kann diese Methode nicht überschreiben.

Abbildung 1.9 Abfolge der Methodenaufrufe

Da bei jeder Anfrage an eine bestimmte Instanz innerhalb des dafür verwende-ten Threads dieselben Methoden verwendet werden, muss bei der Entwick-lung einer JSP folglich darauf geachtet werden, dass sich der auszuführendeCode immer in derselben Weise verhält, egal ob nur eine Anfrage stattfindetoder gleich mehrere. Der Code muss also Thread-sicher sein. Welche konkretenAnforderung sich daraus ergeben, wird in Abschnitt 3.12 erläutert.

Initialisierung

Die erste Methode jspInit() wird beim Laden des Servlets genau einmal auf-gerufen, und zwar noch vor der Bearbeitung der ersten Anfrage. Bei weiterenAnfragen wird sie also nicht mehr aufgerufen. Sie tut in der Vorgabe zunächstgar nichts. Durch Überschreiben dieser Methode hat der JSP-Autor aber dieMöglichkeit, bestimmte Initialisierungen vorzunehmen, etwa das Laden undErzeugen von Objekten, die für jede Anfrage benötigt werden. Auch lassen sichhier Datenbankverbindungen aufbauen, die von mehreren Anfragen gemein-sam genutzt werden sollen. Dazu können entsprechende Parameter in den Des-kriptor-Dateien der jeweiligen Webanwendung abgelegt werden. Die Parame-


ter lassen sich an dieser Stelle einlesen und wenn nötig in Instanzvariablenspeichern, die während der gesamten Ausführungszeit zur Verfügung stehen.

Ist die jspInit()-Methode einmal aufgerufen, sollte die JSP-Implementierungsicherstellen, dass anschließend mit der Methode getServletConfig()auf dieInitialisierungs- und Startparameter des Servlets zugegriffen werden kann.

Seitenverarbeitung

Die eigentliche Arbeit, nämlich aus der JSP-Anfrage eine entsprechende Ant-wortseite zu erzeugen, wird über die _jspService()-Methode erledigt. DieseMethode wird für jede Anfrage aufgerufen und auf der Basis der Inhalte der JSPautomatisch generiert. Die Methode kann, wie schon gesagt, nicht durchSkriptelemente in der JSP überschrieben werden.

Um die Kommunikation nach dem Muster Anfrage/Antwort zu steuern, wer-den entsprechende Parameter verwendet. Der formale Typ der Anfrageparame-ter – in der JSP 2.0-Spezifikation als <ServletRequestSubtype> bezeichnet –ist durch ein Interface bestimmt, das javax.servlet.ServletRequest erwei-tert. Entsprechend gilt für die Antwortparameter – <ServletResponseSub-type> - ein Interface, das javax.servlet.ServletResponse erweitert.

Diese Interfaces werden durch die Interfaces javax.servlet.http.Http-ServletRequest und javax.servlet.http.HttpServletResponse noch umMethoden bereichert, die für das HTTP-Protokoll spezifisch sind. Sie könnenvor allem protokollspezifische Daten liefern. Das betrifft z.B. das Abfragen derRequest-Header mit getHeader() oder von Cookies mit getCookies(). Wäh-rend HttpServletRequest der Anwendung das Parsen und Dekodieren derHTTP-Anfrage abnimmt, erlaubt HttpServletResponse einen einfachenZusammenbau der HTTP-Antwort, das Puffern der Ausgabe und das Setzen vonHeadern und Cookies. Für die Ausgabe werden Stream-Klassen für Textdatenund für binäre Daten zur Verfügung gestellt.

Freigabe der Ressourcen

Das Servlet kann so lange Anfragen verarbeiten, bis es explizit vom Containeraus dem Speicher entfernt wird. Dies geschieht, wenn dieser ein shutdown-Sig-nal erhält. Vor dem Entladen ruft der Container aber noch die Methode jsp-Destroy() auf. Die Methode jspDestroy() kann überschrieben werden, umDinge zu veranlassen, die geschehen sollen, bevor die Servlet-Instanz dem Gar-bage Collector überlassen wird, etwa Einträge in Log-Dateien. Häufig geht esauch um die Freigabe von Ressourcen oder das Schließen von offenen Verbin-dungen zu Datenbanken. Außerdem können Statusinformationen aus dem


1

2

3

4

5

6

7

8

9

10

11

12

13

14

ServletContext gespeichert werden, die bis zum nächsten Aufruf des Servletserhalten bleiben sollen.

Die Methode wird in jedem Fall erst ausgeführt, wenn alle Threads, die _jsp-service()-Methoden ausführen, beendet sind, also spätestens, wenn der Ser-ver heruntergefahren wird.

Während die jspInit()-Methode, falls der JSP-Autor sie überschreibt, injedem Fall zum Zuge kommt, ist das bei der jspDestroy()-Methode nicht sosicher. Es kann vorkommen, dass der Server crashed und es nicht mehr zurAusführung der Methode kommt.

1.6.7 Quellcode des Beispiels

Der Quellcode des Servlets, das der JSP-Container aus der kleinen JSP erzeugt,zeigt die Umsetzung des Inhalts der JSP in den Java-Code einer Servlet-Klasse.Die Datei wird unter Tomcat zusammen mit der kompilierten Klasse in einemUnterverzeichnis von $CATILINA/work abgelegt.

Der Name der Java-Datei übernimmt dabei den Dateinamen der JSP-Datei underweitert ihn um das Suffix _jsp, aus zeitAnsage.jsp wird also zeitAnsage_jsp.java und zeitAnsage_jsp.class.

package org.apache.jsp.Kapitel1;import javax.servlet.*;import javax.servlet.http.*;import javax.servlet.jsp.*;public final class zeitAnsage_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent { private static java.util.Vector _jspx_dependants; public java.util.List getDependants() { return _jspx_dependants; }public void _jspService(HttpServletRequest request,

HttpServletResponse response) throws java.io.IOException, ServletException { JspFactory _jspxFactory = null; PageContext pageContext = null; HttpSession session = null; ServletContext application = null; ServletConfig config = null; JspWriter out = null;


Object page = this; JspWriter _jspx_out = null; try { _jspxFactory = JspFactory.getDefaultFactory(); response.setContentType("text/html"); pageContext = _jspxFactory.getPageContext(this, request, response, null, true, 8192, true); application = pageContext.getServletContext(); config = pageContext.getServletConfig(); session = pageContext.getSession(); out = pageContext.getOut(); _jspx_out = out;

out.write('\r'); out.write('\n'); out.write("<html>\r\n\t"); out.write("<head>\r\n\t\t"); out.write("<title>Say the time"); out.write("</title>\r\n\t"); out.write("</head>\r\n\t"); out.write("<body>\r\n\t\t"); java.util.GregorianCalendar now = null; synchronized (pageContext) { now = (java.util.GregorianCalendar) pageContext.getAttribute("now", PageContext.PAGE_SCOPE); if (now == null){ try { now = (java.util.GregorianCalendar)java.beans.Beans.instantiate(this.getClass().getClassLoader(), "java.util.GregorianCalendar"); } catch (ClassNotFoundException exc) { throw new InstantiationException(exc.getMessage()); } catch (Exception exc) { throw new ServletException("Cannot create bean of class " + "java.util.GregorianCalendar", exc);


1

2

3

4

5

6

7

8

9

10

11

12

13

14

} pageContext.setAttribute("now", now, PageContext.PAGE_SCOPE); } } out.write("\r\n\t\t"); out.write("<p>The time is: "); out.write("</p>\r\n\t\t"); out.write((java.lang.String) org.apache.jasper.run-time.PageContextImpl.proprietaryEvaluate("${now.time}", java.lang.String.class, (PageContext)pageContext, null, false)); out.write('\r'); out.write('\n'); out.write(' '); out.write("</body>\r\n"); out.write("</html> \t\r\n \t\r\n \r\n "); } catch (Throwable t) { if (!(t instanceof SkipPageException)){ out = _jspx_out; if (out != null && out.getBufferSize() != 0) out.clearBuffer(); if (pageContext != null) pageContext.handlePageException(t); } } finally { if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext); } }}

Die Implementierungsklasse des Beispiels wird in der Tomcat-Umgebung alsErweiterung der Klasse HttpJspBase erzeugt, die zu dem Paket org.apa-che.jasper.runtime gehört. Diese Klasse wird für alle Servlets verwendet, dieaus einer JSP generiert werden. Sie implementiert die schon angesprochenenInterfaces javax.servlet.jsp.HttpJspPage, javax.servlet.jsp.JspPage,javax.servlet. Servlet, javax.servlet.ServletConfig und zusätzlichjava.io.Serializable.


Da in der JSP keine Überschreibungen für die Methoden jspinit() und jsp-destroy() vorhanden sind, wird nur die Methode _jspService() verwendet,um die Antwort auf die Anfrage zu erzeugen.

Zunächst werden eine Reihe von Objekten initialisiert, die die JSP als impliziteObjekte für Skriptelemente anbietet. Dann wird die getDefaultFactory()-Methode verwendet, um Instanzen für die Interfaces und Klassen zu erzeugen,die für die Implementierung des JSP-Objekts benötigt werden. Die in der ers-ten Zeile der JSP enthaltene page-Direktive, die hier den MIME-Typ der Seitebestimmt, legt in diesem Fall das Argument der setContenType()-Methodedes response-Objekts fest.

Ist das Objekt pageContext gebildet, werden Methoden dieses Objektsbenutzt, um andere Objekte zu erzeugen:

application = pageContext.getServletContext();config = pageContext.getServletConfig();session = pageContext.getSession();out = pageContext.getOut();

Die Bedeutung dieser Objekte wird in Abschnitt 3.6 näher erläutert.

Anschließend werden die in der JSP vorkommenden Template-Elemente unddie verschiedenen JSP-Elemente in der dort gegebenen Reihenfolge verwertet,um den Datenstrom zusammenzufügen, der die Antwort des Servers auf dieAnfrage erzeugt. Mit Hilfe der getOut()-Methode des PageContext-Objektswird der aktuelle Wert des impliziten out-Objekts festgestellt, das eine Instanzder JspWriter-Klasse ist, mit der die Ausgaben an den Browser erzeugt wer-den. Der Jspwriter arbeitet ähnlich wie ein PrintWriter, kann aber Datenauch zwischenspeichern.

Um aus den vorhandenen Anfrageobjekten die entsprechenden Antwortob-jekte zu gewinnen, werden bestimmte Umwandlungen vorgenommen.

Für jedes Template-Element wird eine Java-Anweisung, wie z.B.

out.write("<html>\r\n\t");

verwendet, um es in die Antwortseite einzubauen.

Die in der Seite vorkommenden Standardaktionen, die hier die Verwendungeiner JavaBean betreffen, werden durch den entsprechenden Java-Code ersetzt.Aus dem EL-Ausdruck

${now.time}

wird beispielsweise der Java-Code:


1

2

3

4

5

6

7

8

9

10

11

12

13

14

out.write((java.lang.String) org.apache.jasper.runtime.PageCon-textImpl.proprietaryEvaluate("${now.time}", java.lang.String.class, (PageContext)pageContext, null, false));

Der Vergleich zwischen dem Code der JSP und dem Code des daraus generier-ten Servlets dürfte die Einschätzung bestätigen, dass es für die Entwicklung vonWebanwendungen durchaus vorteilhaft ist, wo möglich von der Kodierung vonServlets zum Editieren von JSPs überzuwechseln.

Da die Übersetzung der JSP in den Java-Code des entsprechenden Servletsautomatisch abläuft, muss sich der JSP-Autor um das Ergebnis in der Regelauch nicht unbedingt kümmern. Zum Lernen oder bei der Suche nach Fehlern,die bei der Ausführung der Seite gemeldet werden, ist es aber häufig sinnvoll,sich den generierten Code anzusehen, um dort Hinweise auf die Ursachen desFehlers zu finden.

Werden andere JSP-Implementierungen verwendet, kann es zu leichten Abwei-chungen in der Übersetzung kommen. Bei anderen Containern muss eventuelldie Option zum Speichern des Quellcodes erst eingeschaltet werden.

Index 569

Index

A<auth-constraint> 404<auth-method> 404Accept 24Accept-Charset 24Accept-Charset-Header 320Accept-Encoding 24Accept-Language 24Accept-Language-Header 316, 320Accept-Ranges 28Achsenbezeichner 218Active Server Pages 35addCookie() 293Aktion 557

benutzerdefiniert 557Standard 557

Aktionen 90<jsp:attribute> 180<jsp:body> 182<jsp:doBody> 185<jsp:element> 178<jsp:fallback> 178<jsp:forward> 169<jsp:getProperty> 196<jsp:include> 162<jsp:invoke> 183<jsp:param> 172<jsp:params> 178<jsp:plugin> 173<jsp:setProperty> 197<jsp:text> 185<jsp:useBean> 190

ancestor 219Anfrage 21, 557

Parameter 25Antwort 21Antwort-Header 26Apache 557Apache Jakarta Project 64API 557Applet 176application 140, 144, 290, 491applicationScope 152, 492Applikationsserver 557at-end scoped variables 202Attribut 557Attribute 91attribute-Direktive 465Attributwerte 162Ausdruck 131, 557Ausdrücke 115Authentifizierung 401autoFlush 147Autorisierung 401

B<body-content> 420<button> 263BodyTag 432BodyTag-Interface 427BodyTagSupport 433BodyTagSupport-Klasse 428Browser. 21Bytecode 557

C<c:catch> 209, 511<c:choose> 210, 515<c:forEach> 211, 358, 516<c:forTokens> 212, 517<c:if> 210, 514<c:import> 109, 213, 518<c:otherwise> 210, 516<c:out> 206, 358, 511<c:param> 213, 521<c:redirect> 213, 520<c:remove> 206, 513<c:set> 207, 291, 512<c:url> 301, 519<c:when> 210, 515<Connector> 73<Context> 75, 76<context-param> 144, 394CallableStatement 368Cascading Stylesheets 558CATALINA_HOME 68CGI 29, 30, 558CGI-Skript 558child 219Class.forName() 349CLASSPATH 424Client 21Common Gateway Interface 29config 140, 148, 491conf-Verzeichnis 350Connection 24Connection Pooling 384Container-Element 558Content-Length 28Content-Type 28contentType 314, 485Controller 40Cookie 558

getCookies() 295setMaxAge() 295

cookie 152, 492Cookie-Header 293Cookies 292CREATE TABLE 329

570 Index

createStatement() 341, 364CSS 558

D<DefaultContext> 352<distributable> 394DatabaseMetaData 380, 381DataSource 347Datenquellen 347DDL 328defaultHost 73Deklaration 487, 558Deklarationen 115, 116deleteRow() 373Deployment Descriptor 352descendant 219DHTML 35, 559Direktive 483, 558

include 105, 108page 95, 483page autoFlush 98page buffer 98page charset 105page contentType 103page errorPage 100page extends 96page import 97page info 99page isELIgnored 105page isErrorPage 100page isThreadSafe 99page pageEncoding 105page session 97taglib 110taglib prefix 112taglib tagdir 110taglib uri 110

Direktiven 90, 95dirty read 379distributed container 558DML 328doAfterBody() 431, 433doEndTag() 428, 430doInitBody() 432Dokumenttyp-Definition 559doStartTag() 423, 429doTag() 428, 438, 439Dynamic HTML 559Dynamisches Attribut 559

E<el-ignored> 407<embed> 178<Engine> 73<env-entry> 408<error-page> 101, 400ECMA 560ECMAScript 149, 493

einfache Tag-Handler 438EJB 47, 559EL 42, 149, 491

API 150deaktivieren 159Delimiter 151Empty Operator 494empty-Operator 155fn:contains 158, 547fn:containsIgnoreCase 158, 547fn:endsWith 158, 548fn:escapeXml 158, 548fn:indexOf 158, 549fn:join 158, 549fn:length 158, 550fn:replace 158, 550fn:split 158, 551fn:startsWith 158, 551fn:substring 158, 552fn:substringAfter 158, 552fn:substringBefore 159, 553fn:toLowerCase 159, 554fn:toUpperCase 159, 554fn:trim 159, 554Funktionen 157, 453, 495Implizite Objekte 152, 492in Attributen 151JSTL-Funktionen 158Literale 492Operatoren 155, 493Syntax 154, 492Template-Text 149Typumwandlung 160Zugriff auf JavaBeans 149

EL-API 43EL-Ausdruck 91, 149, 559Element 559Elemente 91ELExection 160ELParseException 160encodeRedirectURL() 300encodeURL() 300End-Tag 90Enterprise JavaBeans 559Entität 560Entitätsreferenz 560Entity 560errorPage 387exception 101, 140, 148, 491execute() 364executeBatch() 364Expression 150Expression Language 42, 491ExpressionEvaluator 150

F<filter> 312, 397<filter-mapping> 310, 398

Index 571

<fmt:bundle> 232, 322, 543<fmt:formatDate> 228, 539<fmt:formatNumber> 228, 535<fmt:message> 232, 323, 545<fmt:param> 232, 323, 546<fmt:parseDate> 228, 540<fmt:parseNumber> 228, 537<fmt:requestEncoding> 232, 546<fmt:setBundle> 232, 323, 544<fmt:setLocale> 232, 322, 544<fmt:setTimeZone> 228, 542<fmt:timeZone> 228, 542<form> 254

action 259method 259

<form-login-config> 404Fehlermeldungen 386Fehlerseite 101, 400Filter 309, 397FilterChain 310FilterConfig 310Filter-Kette 309Filterkette 398findAncestorWithClass() 438findAttribute() 143findColumn() 374flush() 147following 219Formular 560Formularauswertung 264Formulare 254, 266

versteckte Felder 301Fragmentbezeichner 560Framework 560FunctionMapper 150

GGeltungsbereich 138, 289

application 139page 138request 138session 139

GenericServlet 32, 286getAttribute() 143, 290getAttributeNames() 144, 290getBeanInfo() 273getContext() 94getEnclosingWriter() 435getErrorData() 102getInitParameter() 148getJspBody() 438getLocales() 320getOut() 58getPageContext() 143getParameter() 264getRequest() 143getResponse() 143getResultSet() 365

getServletConfig() 54getServletContext() 148, 310getSession() 304getString() 347getUpdateCount() 365getVariableResolver() 151getWriter() 146

H<Host> 73header 152, 492headerValues 152, 492Host 24HTML 35, 561

Formulare 133htmlf 108HTTP 20, 560

GET-Methode 23Header 22, 23POST-Methode 23request-line 23Ressourcen 23Statuscodes 27status-line 23verbindungsloses Protokoll 21zustandsloses Protokoll 22

HTTP/1.0 20HTTP/1.1 20, 315HTTP-Authentifizierung 404HTTP-Port 21HTTP-Protokoll 20, 297HTTPServlet 32HttpServlet 286HttpServletRequest 293HttpServletResponse 293HttpSession 302

Objekte anbinden 304HttpSessionBindingListener 305HTTP-Statuscode 102

II18N 316<include-prelude> 109<include-coda> 109, 408<include-prelude> 408<init-param> 394<input> 262<is-xml> 407IANA 314IETF 561IETF) 20IIS) 31Implizites Objekt 139, 490, 561Include-Direktive 485Inhaltsmodell 561initParam 152, 492insertRow(), 373Instanzvariable 117

572 Index

Interface 561Introspektion 272invalidate() 306invoke() 184, 439ISAPI 31isELIgnored 464, 485isErrorPage 387ISO/IEC 10646 313ISO-639 317ISO-8859 105, 313, 314isUserInRole() 403IterationTag 431IterationTag-Interface 427

JJ2EE 45, 561J2EE 1.4 47j2ee_1_4.xsd 392J2EE-Blueprints 46J2EE-Spezifikation 46J2ME 46, 561J2SE 45, 63_jspService() 119<jsp:attribute> 44, 245, 507<jsp:body> 44, 508<jsp:declaration> 116, 247<jsp:directive.attribute> 247<jsp:directive.tag> 247<jsp:directive.variable> 247<jsp:doBody> 462, 509<jsp:element> 245, 506<jsp:expression> 131<jsp:fallback> 176, 503<jsp:forward> 398, 497<jsp:getProperty> 504<jsp:include> 498<jsp:invoke> 462<jsp:output> 245, 510<jsp:param> 499<jsp:params> 502<jsp:plugin> 500<jsp:root> 241, 460, 496<jsp:setProperty> 505<jsp:text> 244, 497<jsp:useBean> 138, 503<jsp-config> 109, 405<jsp-file> 395<jsp-property-group> 405, 407JAAS 47, 562JAF 47Jakarta-Projekt 562jar 412JAR-Archiv 562Java 562Java Community Process 42, 562Java RMI 562Java Server Faces, 417Java Server Pages 36, 562

java.lang.reflect 273java.sql 333java.util.locale 317JAVA_HOME 63JavaBean 186JavaBeans 91, 271, 562

Designmuster 274kompilieren 284Konstruktor 275package 284Plazierung 284Serialisierung 275Zugriffsmethoden 273

javac 63Java-Code 115Javadoc 422JavaMail 47, 562JavaScript 562JavaServer Pages Standard Tag Library 42javax.servlet.Filter 309javax.servlet.jsp.tagext 427javax.servlet.Servlet 50, 286javax.sql 333, 335JAX 563JAXP 47JAXR 47JAX-RPC 47JCA 47, 563JCP 41, 203, 562JDBC 47, 328, 330, 563

close() 377commit() 378DataSource 338Datenübernahme 374DriverManager 338executeQuery() 341executeUpdate() 341getConnection() 339Isolierungsgrade 379rollback() 378setAutoCommit() 379statement 341Typkonvertierung 376URL-Syntax 340

JDBC 3.0 337JDBC 3.0 Spezifikation 335JDBC-API 330JDBC-ODBC-Brücke 332JDBC-Treiber 330JDNI-Pfad 409JMS 47JNDI 47, 348, 408, 563

java:comp/env 408Ressourcenfabrik 350

JNDI API 350JSP 36, 38, 562

Aktionen 161Anwendungsgebiete 39

Index 573

Ausführungsphase 51Implementierungsklasse 50, 57Initialisierung 53Komponenten 105Laufzeitumgebung 44Lebenszyklus 52relative Pfade, 94Servlet-Klasse 55Standardsyntax 87Syntax 48Tools 83Übersetzungsphase 49Verzeichnisstruktur 78XML-Ansicht 249XML-Syntax 87

JSP 1.2 41JSP 2.0 42, 392JSP 2.0-Spezifikation 45JSP Implementierungsklasse 563jsp_2_0.xsd. 392JSP-API 43jsp-api.jar 424JSP-Container 44, 183, 563JspContext 151, 431JSP-Datei 563jspDestroy() 53, 54, 119JSP-Dokument 232, 314, 563

Template-Text 243Wurzelelement 241xmlns-Attribut 242

JSP-Dokumente 43, 241JSP-Element 138JSP-Elemente 88jspf 108JSP-Fragment 183, 439, 563JSP-Fragmente 183jspInit() 53, 119JSP-Konfiguration 405JspPage 53JSP-Segment 563jspService() 53JSP-Spezifikation 417JspWriter 58JSR 563JSR 152 41JSTL 42, 201, 357, 510, 566

Format-Tags 228SQL-Tags 227

JSTL 1.0 203JSTL 1.1 203JTA 47JVM 34, 564

KKlasse 564Klassenvariable 117Knotenmenge 216, 218Kommentare 91, 482

Konstruktor 564Kontextknoten 218, 220Kontextpfad 77

L<listener> 397<load-on-startup> 396<locale-encoding-mapping> 401<Logger> 74<login-config> 404Ländercodes 318Last-Modified 28Listener 397, 564Locale 317localhost 71log() 146Log-Dateien 71, 120Lokalisierungsstufe 218

M<mime-mapping> 399<mime-type> 399Markup 564Maskierungen 481Metadaten 564META-INF 111MIME-Typ 104, 399, 564Model 40Model-View-Controller 39, 276, 564Multithreading oder 251MySQL 342

CREATE DATABASE 342CREATE TABLE 342Treiber 343, 352

Nname-from-attribute 466name-given 466Namensraum 565Nebenläufigkeit genannt 251nested scoped variables 202node() 220node-set 216NSAPI 31NullPointerException 160

O<object> 178Objekt 565Objekte 138ODBC 331, 565out 140, 146, 491out.print() 122

P<page-encoding> 407page 140, 148, 491PageContext 58, 138, 290, 429

574 Index

pageContext 140, 143, 152, 490, 492page-Direktive

errorPage 485import 484isErrorPage 485session 484

pageEncoding 314, 464, 485pageScope 152, 492param 152, 492ParameterMetaData 381, 382paramValues 152, 492parent 219Parser 565PATH 63PCDATA 565Perl 565phantom reads 379PHP 565PL/SQL 368Plug-In 565PooledConnection 384Pooling 336Port-Nummer 565preceding 219PreparedStatement 366prepareStatement() 366Principal 565Property-Datei 323PropertyEditor 162

R<resource-ref> 352<Realm> 74<res-auth> 409<Resource> 352<ResourceParams> 352<resource-ref> 409<res-type> 409<role-link> 403<role-name> 403<rtexprvalue> 420Referenzimplementierung 565removeAttribute() 144, 277, 305Renderer 566request 21, 139, 141, 289, 490, 557request.getHeaderNames() 141request.getParameter() 141request.getRequestURI() 141RequestDispatchern 398requestScope 152, 492ResourceBundle 321response 21, 140, 142, 490response.getOutputStream() 142response.getWriter() 142Ressourcenbündel 321ResultSet 334, 347, 364, 370, 373resultSetConcurrency 371ResultSetMetaData 381, 382

resultSetType 370RFC 2109 294RowSet 336, 378

S<scripting-invalid> 407<security-constraint> 402<security-role> 402<security-role-ref> 403<Server> 73<Service> 73<servlet> 394, 395<servlet-class> 395<servlet-mapping> 396<servlet-name> 396<session-config> 394<session-timeout> 306, 394<sql:dateParam> 227, 533<sql:param> 227, 362, 533<sql:query> 227, 358, 530<sql:setDataSource> 228, 358, 529<sql:transaction> 227, 534<sql:update> 227, 532SAAJ 48scope 138, 184, 194scoped variables 202scriptless 464self 219sendRedirect() 300Serializable 275Server 28server.xml 71, 350, 405Servererweiterung 31Servlet 31, 286, 566

CLASSPATH 287destroy()-Methode 286init()-Methode 286kompilieren 286Lebenszyklus 286plazieren 287service()-Methode 286

Servlet-API 31, 47, 286, 290servlet-api.jar 286, 424Servlet-Container 32ServletContext 55, 94, 304Servlet-Spezifikation 32, 393Servlet-Spezifikation 2.4 42Session 298

JSESSIONID 299session 140, 143, 289, 490

getID() 304invalidate() 303, 308isNew() 303

Session-ID 300sessionScope 152, 492setAttribute() 143, 290setBodyContent() 428, 432setContentType() 103, 322

Index 575

Set-Cookie-Header 293setJspBody() 439setLocale() 322setPageContext() 429setParent() 429SGML 566Simple Tag-Handler 43SimpleTag-Interface 427, 438SimpleTagSupport 438SimpleTagSupport-Klasse 428SingleThreadModel 117, 251Sitzung

eröffnen 303Sitzungs-ID 302Sitzungsverfolgung 298Skriptausdruck 488Skriptelement 90, 114, 487, 566Skriptlet 120, 489, 566

Schleifen 126Template-Text 122Variable 121Verzweigung 125

Skriptlets 115SOAP 566Sprachcodes 317SQL 328

Batch-Updates 365INSERT 353

SQL-Anweisung 329SQLException 366, 383SQL-Operator 362sql-Skript 343SQL-Typen 334SSL 302Standardaktionen 161Start-Tag 90stored procedures, 367Struts 476Synchronisierung 252

T<tag> 110<tag-class> 111, 420<taglib> 110, 405, 420<taglib-uri> 406<textarea> 263Tag 566Tag Library Descriptor 110, 417, 445, 566Tag-Bibliothek 418, 566Tag-Datei 43, 418, 459

Direktiven 463installieren 461JSP-Fragmente 475Syntax 462tag-Direktive 463Variablensynchronisierung 467

tagdir 487TagExtraInfo 446

Tag-Handler 418, 421, 426, 566Tag-Interface 427taglib-Direktive 446, 455, 486TagLibraryValidator 249, 446, 458Tags

benutzerdefinierte 417TagSupport-Klasse 428TCP/IP 20TCP/IP-Socket 21Template-Daten 88, 566Template-Element 58Template-Text 91text() 220Thread 33, 566Throwable 387Throwable-Objekt 102TLD 110, 417, 442, 445, 446, 566

<attribute> 451<body-content> 450<dynamic-attributes> 452<fragment> 452<function> 495<rtexprvalue> 451<tag-class> 449<tag-file> 461<taglib> 447<tlib-version> 448<uri> 448<variable> 450impliziter Deskriptor 461installieren 454

TLD-Datei 419Token 567Tomcat 64

installieren 65konfigurieren 66Manager-Anwendung 413Verzeichnisse. 67webapps-Verzeichnis 411

tomcat-users.xml 405toString() 229Transaktionsverarbeitung 378try/catch-Blöcke 124T-SQL 368

U<url-pattern> 396, 407<user-data-constraint> 403Unicode 313, 567Uniform Resource Identifier 567Uniform Resource Locator 567updateRow() 373URI 567uri 487URL 23, 567

Escape-Codes 25URL-Kodierung 261URL-Rewriting 304

576 Index

URL-Syntax 25URL-Umschreibung 299User-Agent 24UTF-16 313UTF-32 313UTF-8 105, 313

VValidierung 248, 567valueBound() 305valueUnbound() 305var 184Variable 138variable-Direktive 466VariableResolver 150varReader 184Vererbung 567verteilte Webanwendung 567Verzeichnis 336View 40Vorbereitetes SQL 365

W<web-app> 393<web-resource-collection> 402<welcome-file-list> 400WAR 74, 568

archivieren 412installieren 413

WAR-Archiv 391, 411wasNull() 377Web Application Archive 74, 568Web services 568web.xml 75, 76, 111, 204, 306, 352, 391,

409Webanwendung 44, 567web-app_2_4.xsd 392webapps 77Web-Dienste 568WEB-INF 111, 421WEB-INF/tags 461Webseite 568Webserver 568Website 568Wohlgeformtes XML 568work-Verzeichnis 386Wrapper-Klasse 291Wurzelverzeichnis 78

XX/Open SQL CLI, 331<x:choose> 225, 524<x:forEach> 224, 225, 525<x:if> 225, 524<x:otherwise> 225, 525<x:out> 224, 523<x:param> 226, 528<x:parse> 223, 522<x:set> 225, 523

<x:transform> 223, 225, 526<x:when> 225, 525XHTML 560XML 214, 560

Datentypen 558Document Object Model 559Dokumentelement 558Dokumentinstanz 558Dokumentmodell 559Dokumenttyp-Deklaration 559DOM 559DOM-Schnittstelle 240DTD 239, 559Infoset 561Knoten 564Komplexer Datentyp 564Markup 234Namensräume 237Namensraum-URI 237Parser 240QName 565QNames 237Syntax 236, 557Tags- 236Transformationen 225Wohlgeformtheit 239Wurzelelement 393, 568Wurzelknoten 568

XML Schema 568XML-Deklaration 569XML-Dokument 232, 569XML-Dokumente 215XML-Elemente 246xmlns 113xmlns-Attribute 393XML-Prozessor 569XML-Schema 42, 239, 392XPath 43, 91, 149, 215, 569

Achsen 219Attributknoten 216DOM 216Elementknoten 216Funktionen 220Knotenmengenfunktionen 221Knotentest 219Kommentarknoten 217Logische Functionen 222Lokalisierungspfad 217Namensraumknoten 217Numerische Funktionen 222Prädikate 220Prozessoren 220Schreibweise 218String-Funktionen 221Textknoten 216Verarbeitungs-anweisungsknoten 217Wurzelknoten 216

XSL 569XSLT 240, 569

Liebe Leserin, lieber Leser, - bilder.buecher.de · Liebe Leserin, lieber Leser, ich freue mich,...

Documents

Transcript of Liebe Leserin, lieber Leser, - bilder.buecher.de · Liebe Leserin, lieber Leser, ich freue mich,...