Einleitung

Im Folgenden bekommen Sie einen kurzen Überblick über die speziellen Technologien, mit denen Sie sich im Rahmen des SE-Praktikums auseinandersetzen werden. Details und weiterführende Informationen finden Sie bei den angegebenen Links.

HTTP

HTTP steht für Hypertext Transfer Protocol und bezeichnet das Netzwerk-Protokoll, das dem WWW zu Grunde liegt. Es handelt sich um ein einfach aufgebautes Klartext-Protokoll. Im Normalfall erfolgt die Kommunikation zwischen Server und Client über TCP/IP Sockets. Über HTTP können beinahe beliebige Resourcen übertragen werden. Diese Ressourcen werden dabei über URLs identifiziert. Im Allgemeinen hat eine solche URL die Form

http://rechnername.domain.tld:Port/pfad/ressource-name

TLD steht dabei für Top-Level Domain (also de, com, org etc.) und Port für eine Zahl zwischen 1 und 32167. Ein Webserver erwartet Anfragen von Clients normalerweise auf Port 80, kann aber auf einen beliebigen anderen (freien) Port umkonfiguriert werden. Wichtig für die Entwicklung von Web-Anwendungen ist die Tatsache, dass es sich bei HTTP um ein verbindungsloses Protokoll handelt. Clients stellen Anfragen an den Server nach verschiedenen Ressourcen (HTML-Seite, darin enthaltene Bilder etc.) Diese Anfragen lassen sich für eine Web-Anwendung nicht ohne weiteres einem einzelnen Client eindeutig zuweisen. Es ist also zusätzlicher Aufwand nötig, um Informationen über Authentifizierung, Kontexte etc. zu erhalten. Weitere Informationen dazu im Abschnitt Session Tracking.

http://www.w3.org/Protocols/

Was sind Servlets?

Java Servlets stellen den Ansatz der Firma Oracle (vormals Sun) dar, Java als Ersatz für CGI-Skripte zu etablieren. Sun selbst definiert das so: "A servlet can almost be thought of as an applet that runs on the server side - without a face." Es handelt sich also um eine Technologie, mit der in Java geschriebene Programme Anfragen von Clients über HTTP empfangen, verarbeiten und beantworten können. Die Ausführung der Java-Programme und die Bereitstellung der Verbindung zum Client etc. erfolgt dabei durch einen sogenannten Servlet-Container, und weitgehend transparent für den Programmierer. Vorraussetzung dabei ist, dass selbst programmierte Servlets immer Unterklasse einer der von Sun bereitgestellten Servletklassen sein müssen, hier HttpServlet. Die Vorteile gegenüber anderen Ansätzen sind dabei klar: Zugriff auf das komplette Java API und viele Java-Bibliotheken von Drittherstellern, die weitgehende Plattformunabhängigkeit und die Existenz von ausgereiften Entwicklungsumgebungen. Ein einfaches Beispiel-Servlet finden Sie hier.

Java Servlets
Java ist auch nur eine Insel
Java Servlets Tutorial
Java Servlets 3.0 API Dokumentation

Was ist JSP?

JSP steht für Java Server Pages und war ursprünglich als Suns Antwort auf Microsofts ASP (Active Server Pages) und andere ähnliche Verfahren zur Entwicklung von dynamischen Webanwendungen wie z.B. Allaire Coldfusion gedacht. Kernüberlegung ist dabei eine Spezifikation die es erlaubt in HTML-Seiten einfach Programmcode einzubetten, der dannausgeführt wird. Anders als bei CGI-Skripten oder Servlets geht man das Problem der programmgesteuerten Erzeugung von HTML-Seiten also von der HTML-Seite aus, und nicht vom Programm aus an. Der eingebettete Programmcode wird dabei typischerweise von speziellen Tags umschlossen. Bei JSP wird natürlich in Java programmiert. Der eingebettete Programmcode wird nicht zur Laufzeit evaluiert, sondern in ein Servlet transformiert und vorkompiliert. Dieser Vorgang ist für Benutzer und Entwickler transparent.

Java ist auch nur eine Insel
JSP Tutorial

Session Tracking

Als Session Tracking bezeichnet man das Speichern von Kontext-Informationen über einen Client, beim Zugriff über mehrere Seiten einer Web-Applikation. Beispiele hierfür sind z.B. Informationen über den Authentifizierungsstatus eines Benutzers (angemeldet etc.).
Session Tracking wird in der aktuellen Servlet API direkt durch entsprechende Methoden unterstützt. Standardmässig werden die Session-Informationen dabei in Cookies abgelegt. Da Ihre Webanwendung jedoch auch lauffähig sein muss, wenn der Benutzer die Speicherung von Cookies unterbindet, müssen Sie auf einen alternativen Weg der Speicherung zurückgreifen:

URL-Rewriting
Hierfür gibt es eine entsprechende Methode, die eine URL so verändert, dass darin zusätzliche Parameter enthalten sind, die eine eindeutige Identifizierung des Clients erlauben. Aus http://beispielurl wird so z.B. http://beispielurl?jsessionid=12356123qwd1273a123.
Achtung: Sollte nur bei einem einzigen Link den der User anklickt diese Session-Information fehlen, dann gehen sämtliche Informationen über den Kontext verloren.

MVC-Modell mit Servlets + JSP

Im Zusammenhang mit dem SE-Praktikum ist beim Model-View-Controller-Modell vor allem die Trennung von Applikations-Logik und Präsentation von Interesse. Dies soll durch die Verwendung von Servlets und JSP-Seiten erreicht werden. In der Terminologie des MVC-Modells sind dabei die Servlets die Controller, sie übernehmen also die Steuerung des Ablaufs der Anwendung (Benutzerführung etc.). Die View-Schicht wird durch die JSP-Seiten repräsentiert. Sämtlicher HTML-Code sollte in den JSP-Seiten enthalten sein. Die JSP-Seiten sollten nicht mehr Programm- und Ablauf-Logik als unbedingt nötig enthalten. Durch diese Aufteilung sind insbesondere Layout-Änderungen wie Farbanpassungen oder das Austauschen von Logos etc. auch von Web-Designern ohne Java-Kenntnisse durchführbar. Die Modell-Schicht wird durch die sonstigen in Ihrer Anwendung enthaltenen Java-Klassen (z.B. für den DB-Zugriff, das XML-Parsen etc.) gebildet. Die Servlets greifen auf die Methoden dieser Klassen zurück.

Die im SE-Praktikum geforderte Umsetzung des MVC-Modell spiegelt durch die strikte Trennung von Programmcode und Präsentationsschicht die Anforderungen bei der Entwicklung von Web-Anwendungen in der Wirtschaft wieder. Projekte werden hier typischerweise von Teams aus Programmierern und Web- / Screen-Designern ohne ausgefeilte Programmierkenntnisse durchgeführt. Der Aufruf einer JSP-Seite von einem Servlet aus erfolgt über Methoden des Interface RequestDispatcher. Parameter (also Java-Objekte) lassen sich vom Servlet an die JSP-Seite z.B. durch einen Aufruf der setAttribute()-Methode der Klasse HttpServletRequest übergeben. Die oben angegebenen Tutorials sollten einen guten Überblick auch über das Zusammenspiel von Servlets und JSP-Seiten geben.

MVC-Modell im Web-Umfeld

Beispielinstallation Tomcat 7.0.x im CIP-Pool

Tomcat ist ein Servlet-API 3.0 und JSP 2.2 kompatibler Servlet-Container. Tomcat kann entweder in Verbindung mit einem bestehenden Webserver arbeiten, oder aber eigenständig. Für das SE-Praktikum sollten Sie Tomcat als eigenständigen Webserver+Servlet-Container installieren. Ihr habt dann völlige Kontrolle über den Server, können ihn beenden und neustarten.

Tomcat Binaries Core runterladen
Version 7.0.6: http://tomcat.apache.org/download-70.cgi#7.0.6
Archiv auspacken
tar xvzf apache-tomcat-7.0.6.tar.gz
Es entsteht ein neues Verzeichnis apache-tomcat-7.0.6. Das Verzeichnis können Sie nach belieben umbenennen oder an eine andere Stelle verschieben.
Environment-Variablen setzen / kontrollieren
export CATALINA_HOME=/home/cip/<login>/apache-tomcat-7.0.6 bzw. den Pfad und Verzeichnisnamen eures Tomcat-Verzeichnisses. Zusätzlich sollte natürlich auch der CLASSPATH für Java richtig gesetzt sein. Insbesondere muss -- zum kompilieren Ihrer Servlets, nicht zum Ausführen -- im CLASSPATH die Datei $CATALINA_HOME/lib/servlet-api.jar (also das Archiv mit den Servlet-Klassen) enthalten sein.
Tomcat konfigurieren
Im Verzeichnis <CATALINA_HOME>/conf finden Sie die Datei server.xml. Hier stellen Sie die globalen Konfigurations-Optionen von Tomcat ein. Im Bereich <Service name="Catalina"> sollten Sie den Port, auf dem der Webserver antwortet von 8080 auf einen neuen Wert setzen. Achtung: Die Portnummer muss > 1023 und noch nicht vergeben sein. Am besten Sie verwenden ein Schema der Form 80<Gruppennummer>. Auch den Port 8005 sollten Sie verändern. Solange alle Gruppen auf unterschiedlichen Workstations Ihre Tomcats starten, sollte es keine Probleme geben. Mit eindeutigen Portnummern sind Sie aber auf jeden Fall auf der sicheren Seite. Genauere Informationen zu den Konfigurations-Optionen etc. finden Sie im Tomcat-Handbuch Version 7.0.x.

Anlegen einer Web-Applikation
Als Web-Applikation bezeichnet man eine Servlet-Anwendung. Diese kann dabei auch aus mehreren Servlets, sowie statischen HTML-Seiten und auch JSP-Seiten bestehen. Um eine Web-Applikation einfach portabel und installierbar zu halten, werden alle Daten zu einer Web-Applikation nach einem einheitlichen Schema unterhalb eines eigenen Hauptverzeichnisses abgelegt. Im Einzelnen verläuft das so:

Erstellen eines Verzeichnisses unter <CATALINA_HOME>/webapps/ z.B. demo
Erstellen der folgenden Hierarchie unterhalb dieses Verzeichnisses:
...demo/pictures ...demo/WEB-INF ...demo/WEB-INF/classes ...demo/WEB-INF/lib ...demo/WEB-INF/jsp Die (kompilierten) Servlet-Klassen kommen später ins Verzeichnis classes, die JSP-Seiten nach jsp und ins Verzeichnis lib sollten zusätzliche von Ihnen verwendete Java-Bibliotheken in Form von JAR-Files kommen.

Erstellen der Datei ...WEB-INF/web.xml mit mindestens folgendem Inhalt:
Rote Kommentare bitte weglassen.

<?xml version="1.0" encoding="utf-8"?>
<web-app id="demo" version="3.0"
         xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
   <display-name>Demo</display-name>

   <servlet>                   
     <servlet-name>            <!-- Tomcat interne ID des Servlets
      servlet1                      Muss pro Web-Application eindeutig
     </servlet-name>                sein -->
     <servlet-class>           <!-- Name der Servlet-Klasse -->
      DemoServlet1
     </servlet-class>
   </servlet>
   <servlet-mapping>           <!-- Verknüpfung Servlet - URL -->
     <servlet-name>
      servlet1                 <!-- Servlet ID -->
     </servlet-name>
     <url-pattern>             <!-- URL Pattern unter dem das Servlet
      /demo-servlet                 erreichbar sein soll
     </url-pattern>                 Wildcards sind möglich (*) -->
   </servlet-mapping>

   <welcome-file-list>
     <welcome-file>
      demo-servlet             <!-- Servlet, das bei Aufruf der Webapp
     </welcome-file>                als erstes aufgerugen wird -->
   </welcome-file-list>
 </web-app>

Das Servlet ist dann unter http://<rechnername>:<Port>/<Web-App Name>/<url-pattern> erreichbar.
Genauere Informationen zu den Konfigurations-Optionen etc. finden Sie im Tomcat-Handbuch, u.A. können Sie hier bestimmte Servlets durch den Servlet-Container mit Passwörtern schützen lassen und andere Sicherheitseinstellungen treffen. Für jedes vom Benutzer aufzurufende Servlet muss es entsprechende Einträge in der web.xml geben. Als Vorlage können Ihnen auch die Konfigurationsdateien der mitgelieferten Beispiele dienen.

Entpacken + Installieren des Demo-Servlets
Der Servlet-Source + JSP-Seite müssen nur in die entsprechenden Verzeichnisse kopiert werden. (Eine war-Datei ist nichts anderes als eine zip-Datei mit anderer Endung.) Dann müssen Sie ggf. noch das Servlet kompilieren und Tomcat stoppen + neustarten. Danach sollten Sie über http://<rechnername>:<Port>/demo/demo-servlet auf das Servlet zugreifen können.

Tomcat starten / stoppen
Im Verzeichnis <CATALINA_HOME>/bin einfach startup.sh aufrufen. Tomcat gibt ein paar Meldungen aus, und wenn alles richtig war können Sie unter http://<rechnername>:<Port> auf die Tomcat-Startseite zugreifen.
Beendet wird Tomcat mit <CATALINA_HOME>/bin/shutdown.sh.

Eine etwas umfangreichere Webapplikation finden Sie hier.