Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Exceptions
7 Generics<T>
8 Äußere.innere Klassen
9 Besondere Klassen der Java SE
10 Architektur, Design und angewandte Objektorientierung
11 Die Klassenbibliothek
12 Bits und Bytes und Mathematisches
13 Datenstrukturen und Algorithmen
14 Threads und nebenläufige Programmierung
15 Raum und Zeit
16 Dateien, Verzeichnisse und Dateizugriffe
17 Datenströme
18 Die eXtensible Markup Language (XML)
19 Grafische Oberflächen mit Swing
20 Grafikprogrammierung
21 Netzwerkprogrammierung
22 Verteilte Programmierung mit RMI
23 JavaServer Pages und Servlets
24 Datenbankmanagement mit JDBC
25 Reflection und Annotationen
26 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Ihre Meinung?

Spacer
 <<   zurück
Java ist auch eine Insel von Christian Ullenboom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
geb., mit DVD
1482 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1506-0
Pfeil 23 JavaServer Pages und Servlets
  Pfeil 23.1 Dynamisch generierte Webseiten
    Pfeil 23.1.1 Was sind Servlets?
    Pfeil 23.1.2 Was sind JavaServer Pages?
  Pfeil 23.2 Servlets und JSPs mit Tomcat entwickeln
    Pfeil 23.2.1 Servlet-Container
    Pfeil 23.2.2 Entwicklung der Servlet-/JSP-Spezifikationen
    Pfeil 23.2.3 Webserver mit Servlet-Funktionalität
    Pfeil 23.2.4 Tomcat installieren
    Pfeil 23.2.5 Ablageort für eigene JSPs
    Pfeil 23.2.6 Webapplikationen
    Pfeil 23.2.7 Zuordnung von Webapplikationen zu physikalischen Verzeichnissen
    Pfeil 23.2.8 Web-Projekt mit Eclipse IDE for Java EE Developers
  Pfeil 23.3 Statisches und Dynamisches
    Pfeil 23.3.1 Statischer Template-Code
    Pfeil 23.3.2 Dynamische Inhalte
    Pfeil 23.3.3 Kommentare
  Pfeil 23.4 Die Expression Language (EL)
    Pfeil 23.4.1 Operatoren der EL
    Pfeil 23.4.2 Literale
    Pfeil 23.4.3 Implizite EL-Objekte
  Pfeil 23.5 Formulardaten
    Pfeil 23.5.1 Einen Parameter auslesen
    Pfeil 23.5.2 HTML-Formulare
  Pfeil 23.6 Auf Beans zurückgreifen
    Pfeil 23.6.1 Beans in JSPs anlegen
    Pfeil 23.6.2 Properties einer Bean im EL-Ausdruck erfragen
    Pfeil 23.6.3 Properties mit <jsp:setProperty> setzen
    Pfeil 23.6.4 Bean-Klasse zum Testen von E-Mail-Adressen
    Pfeil 23.6.5 Parameterwerte in Bean übertragen
  Pfeil 23.7 JSP-Tag-Libraries
    Pfeil 23.7.1 Standard Tag Library (JSTL)
  Pfeil 23.8 Einbinden und Weiterleiten
    Pfeil 23.8.1 Einbinden von Inhalten
    Pfeil 23.8.2 Forward und Redirect
    Pfeil 23.8.3 Applets einbinden
  Pfeil 23.9 Skripting-Elemente in JSPs
    Pfeil 23.9.1 Scriptlets
    Pfeil 23.9.2 JSP-Ausdrücke
    Pfeil 23.9.3 JSP-Deklarationen
    Pfeil 23.9.4 Quoting
    Pfeil 23.9.5 Entsprechende XML-Tags
    Pfeil 23.9.6 Implizite Objekte für Scriptlets und JSP-Ausdrücke
  Pfeil 23.10 JSP-Direktiven
    Pfeil 23.10.1 page-Direktiven im Überblick
    Pfeil 23.10.2 Mit JSPs Bilder generieren
  Pfeil 23.11 Sitzungsverfolgung (Session Tracking)
    Pfeil 23.11.1 Lösungen für Sitzungsverfolgung
    Pfeil 23.11.2 Sitzungen in JSPs
    Pfeil 23.11.3 Auf Session-Dateien zurückgreifen
  Pfeil 23.12 Servlets
    Pfeil 23.12.1 Servlets compilieren
    Pfeil 23.12.2 Servlet-Mapping
    Pfeil 23.12.3 Der Lebenszyklus eines Servlets
    Pfeil 23.12.4 Mehrere Anfragen beim Servlet und die Thread-Sicherheit
    Pfeil 23.12.5 Servlets und Sessions
    Pfeil 23.12.6 Weiterleiten und Einbinden von Servlet-Inhalten
  Pfeil 23.13 Zum Weiterlesen

»Lebensfreude entsteht durch Frieden, der nicht statisch, sondern dynamisch ist.« – Henry Miller (1891–1980)

23 JavaServer Pages und Servlets


Rheinwerk Computing - Zum Seitenanfang

23.1 Dynamisch generierte Webseiten  Zur nächsten ÜberschriftZur vorigen Überschrift

In der ersten Generation von Internet-Seiten war jede Seite statisch auf dem Webserver abgelegt. Unterschiedliche Clients (im Allgemeinen Browser) erfragten die Seite und stellten sie dar. Dies reichte jedoch für viele Anwendungen nicht aus und schränkte die Interaktionsfähigkeit ein. Es gibt mehrere gute Gründe für dynamische Webseiten, bei denen HTML erst auf Anfrage generiert wird:

  • Die Seite ist von Benutzereingaben abhängig. Wenn ein Kunde sich beispielsweise für ein Produkt und dessen Preis interessiert hat, wäre es kaum möglich, für jedes Produkt eine aktuelle statische Webseite bereitzustellen. Zudem sieht ja jede Seite anders aus, und so gäbe es sehr viele Seiten. Wenn sich die Produktbeschreibung ändert, müsste der Benutzer immer eine aktuelle Seite sehen. In diesem Fall ist es günstig, die Webseiten bei Bedarf zu erzeugen. Für Einkaufssysteme kommt eine weitere Eigenschaft hinzu: Der Benutzer bewegt sich über mehrere Seiten und verwaltet einen Warenkorb, der anwachsen oder schrumpfen kann.
  • Web 2.0-Seiten zeichnen sich besonders durch Mitgliederbeteiligung aus, die Content hinzufügen und verändern. Beispiele sind Blogs, Wikis wie Wikipedia oder soziale Netzwerke. Nach jeder Sekunde kann der Inhalt einer Webseite nach dem Neuladen ganz anders aussehen.

Ist der Web-Inhalt dynamisch, kann bei einer Browser-Anfrage der Webserver keine statische Webseite zurückliefern, sondern muss irgendwie auf der Serverseite ein Programm laufen lassen, das dynamisch HTML generiert. Die Interaktion des Webservers, der ja alle Browser-Anfragen annimmt, mit dem Serverprogramm basiert auf speziellen Schnittstellen, wobei die älteste das Common Gateway Interface (kurz CGI) ist. Aufgrund von etwa Dateiendungen oder speziellen Pfaden weiß der Server, dass es sich um keine statische Webseite handelt, sondern gibt die Aufforderung zum Aufbau von HTML an ein externes Programm weiter, dass zum Beispiel aus Datenbanken Produktbeschreibungen holt, dann HTML generiert und es zum Webserver gibt, der das HTML wiederum zum Client schickt.

Serverseitig gibt es mittlerweile eine ganze Reihe von Programmiersprachen, wobei PHP zu den populärsten zählt. Vereinfacht ausgedrückt passiert Folgendes: Bekommt ein Webserver wie Apache oder IIS eine Anfrage an eine Datei, die auf .php endet, so wird die Verarbeitung an den PHP-Interpreter weitergeleitet. Der liest die PHP-Datei ein, interpretiert sie, was zum HTML führt, schickt sie zurück zum Browser, der die Webseite darstellt. Von Microsoft gibt es eine vergleichbare Technologie, die ASP (Active Server Pages) bzw. ASP.NET (Active Server Pages .NET) genannt wird. Während PHP eine eigene, an C angelehnte Programmiersprache ist, lassen sich bei ASP.NET die .NET-Sprachen wie VB.NET oder C# nutzen. Doch was ist mit Java?


Rheinwerk Computing - Zum Seitenanfang

23.1.1 Was sind Servlets?  Zur nächsten ÜberschriftZur vorigen Überschrift

Servlets sind Java-Programme, die in einem besonders präparierten Java-Webserver ausgeführt werden. Die Besonderheit daran ist zunächst, dass ein Webserver in Java realisiert werden muss, eine andere Besonderheit die, dass die Java-Programme als Kassen vom Java-Webserver geladen und dort auch verwaltet und mit einer besonderen Servlet-Schnittstelle angesprochen werden. Daher heißt ein Java-Webserver, der Servlets lädt und verwaltet, auch Servlet-Container. Servlets sind somit ein wenig mit Applets vergleichbar. Ein Applet ist ein Java-Programm auf der Clientseite (im Browser), während ein Servlet ein Programm auf der Serverseite (im Server) ist. Der Browser ist der Applet-Container, während der Java-Webserver mit Servlet-Schnittstelle einen Servlet-Container darstellt.


Performant? Einem modernen Webserver kommt die Aufgabe zu, statischen Content (CSS-, JavaScript-, Grafik-Dateien) zu servieren und auch dynamische Webseiten zu generieren. Die Java-Webserver der aktuellen Generation sind schnell genug, für mittelgroße Seiten auch die traditionellen Webserver wie Apache oder IIS zu ersetzen. Sollte es eine sehr hoch frequentierte Seite sein, so bleiben die etablierten Webserver bestehen und werden so konfiguriert, sodass sie die dynamisch ausführbaren Serverprogramme etwa an einen Servlet-Container weiterreichen.


Die Servlet-API

Das Paket java.net deklariert Klassen für die Clientseite, also für die Seite, die eine Anfrage an den Webserver stellt. Für Servlets der Serverseite ist das Paket javax.servlet reserviert, was jedoch kein Teil der Java SE ist, doch dazu später mehr.

Um eine Vorstellung davon zu bekommen, wie ein Servlet programmiert ist, werfen wir einen Blick auf ein einfaches Servlet:

Listing 23.1  com/tutego/web/servlet/SchnarchServlet.java

package com.tutego.web.servlet;

import java.io.IOException;
import javax.servlet.http.*;

public class SchnarchServlet extends HttpServlet
{
  @Override
  protected void doGet( HttpServletRequest req, HttpServletResponse res )
      throws IOException
  {
    res.getWriter().println( "'Chr! Schnarch! Razong! Chr! Chr! Rapüh!'" );
    res.getWriter().println( "(Disneys beste Comics, Band 5, S.  218)" );
  }
}

Ein Servlet erweitert eine besondere Oberklasse und realisiert eine doGet()-Methode. Die Methode ruft der Servlet-Container immer dann auf, wenn der Client eine Standard-Anfrage über HTTP stellt. Die Implementierung der doGet()-Methode schreibt in einen besonderen Ausgabestrom, der für die Daten bestimmt ist, die zum Client gelangen.


Rheinwerk Computing - Zum Seitenanfang

23.1.2 Was sind JavaServer Pages?  topZur vorigen Überschrift

Servlets sind Server-Programme, die Webseiten erstellen, indem sie mit println() oder Ähnlichem HTML-Code in den Ausgabestrom schreiben. Ändert sich das Erscheinungsbild, dann muss das Java-Programm umgebaut werden, was aufwändig und fehlerträchtig ist. In der Regel ist der Programmierer auch nicht der Designer, und dieser möchte mit Webseiten-Erstellungsprogrammen wie DreamWeaver oder Microsoft FrontPage arbeiten. In vielen dynamischen Programmen stecken oft nur ein oder zwei Zeilen Dynamik, der Rest ist statischer HTML-Code.

Eine JSP (JavaServer Page) geht das Problem genau umgekehrt an. Wo ein Servlet eine Java-Klasse ist, die sich um die Ausgabe des HTML-Codes kümmert, ist eine JSP eine HTML-Seite mit eingebettetem Java-Code:

Listing 23.2  datum.jsp

<html><body>
Hallo Nutzer. Wir haben heute
<%= new java.util.Date() %>.
</body></html>

Selbst eine normale Webseite ohne eingebettete JSP-Kommandos ist eine JSP.

Nun kann der Designer die Visualisierung der Informationen noch nachträglich anpassen, denn Visualisierung und Logik sind getrennt. Wie wäre es, wenn wir einem HTML-Designer einen Quellcode eines Servlets geben und ihn bitten, eine neue Spalte einzufügen?

Der JSP-Compiler

JSP-Skripte werden vom Server automatisch in Servlets übersetzt. Der Server weiß JSP von normalen HTML-Seiten zu unterscheiden, transformiert mithilfe eines JSP-Übersetzers aus der JSP ein Servlet und ruft die bekannten Servlet-Methoden auf, um die Ausgabe zu erzeugen. Der Übersetzungsvorgang von JSP in ein Servlet muss nur einmal getätigt werden – danach benutzt der Servlet-Container direkt die übersetzte Klasse.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
 <<   zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Java SE Bibliotheken






 Java SE Bibliotheken


Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Einstieg in Eclipse






 Einstieg in
 Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in
 Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de