SEP WS 2014/2015
Tutorial

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. Oracle 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 Oracle 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 7 - Mehr als eine Insel
Java Servlets Tutorial
Java Servlets 3.1 API Dokumentation

Was ist JSP?

Dieser Abschnitt ist nur der Vollständigkeit und Übersicht halber enthalten. Sämtliche Anwendungsentwicklung im Praktikum soll stattdessen in JSF stattfinden.

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 7 - Mehr als eine Insel
JSP Tutorial

Was ist JSF?

JSF steht für Java Server Faces. Die Technologie erlaubt die eine ähnlich strukturierte Programmierung von Webanwendungen wie Java Swing für normale graphische Oberflächen. Mit Facelets gibt es eine zu XHTML sehr ähnliche Sprache, die das erstellen einer Oberfläche in XML erlaubt. Wie bei Swing gibt es Listener (Java Methoden), die bei den verschiedenen JSF-Komponenten (z.B. einem Knopf) registriert werden können und dann bei einem Ereignis (Drücken des Knopfs) Aktionen ausführen. Genauso wie bei Swing wird so die Verwendung von MVC automatisch erzwungen, im Gegensatz zu der Verwendung von Servlets und JSP. In der Regel wird pro Dialog- (= Web-) Seite oder pro Formular ein sog. Backing Bean bereitgestellt, das alle Listener und Datenproperties (z.B. für Eingabefelder) für die Seite enthält.
Bei der Verwendung von JSF arbeitet man eine Abstraktionsebene höher als mit Serlvets und JSP, kommt also in der Regel mit diesen Technologien nicht direkt in Berührung. Oracle empfiehlt zur Anwendungsentwicklung JSF anstatt Servlets und JSP zu verwenden.

JSF Tutorial
Bernd Müller, Java Server Faces 2.0, Hanser, 2010 80/ST 253 J35 M9(2)
Java Server Faces 2.2 API Dokumentation
Java Server Faces 2.2 Faclets Tag Documentation

Bitte beachten Sie, dass die obigen JSF Tutorials meistens davon ausgehen, dass die JSF-Library (Mojarra) bereits im Applikationserver enthalten ist. Bei Tomcat ist dies jedoch nicht der Fall. Man kann sie aber leicht pro Applikation nachrüsten, indem man die entsprechende(n) jar-Dateien in das Verzeichnis WebContent\WEB-INF\lib kopiert. Sie brauchen die JSF-Referenzimplementierung von Oracle (Mojarra). Links dazu finden sie hier. Da sie die Demo Applikation bereits enthält, läuft sie ohne weiteres Zutun unter Tomcat.

Seit JFS 2 gibt es Bestrebungen, das parallel entwickelte Context and Dependency Injection CDI zu integrieren. De Facto werden dadurch Annotationen wie @ManagedBean oder @ManagedProperty durch die entsprechenden von CDI (hier @Named und @Inject ersetzt. Hier finden Sie eine CDI-Version obiger Demo Applikation. Letztere benutzt die Referenzimplementierung Weld, welche sich in Form der Libraries cdi-api.jar und weld-servlet.jar im Ordner WebContent\WEB-INF\lib der Applikation befindet.

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:

Solange die JSF-Welt nicht verlassen wird, kümmert sich JSF bei Bedarf automatisch um das URL-Rewriting.

Beispielinstallation Tomcat 8.0.x im CIP-Pool

Tomcat ist ein Servlet-API 3.1 und JSP 2.3 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.

  1. Tomcat Binaries Core runterladen
    Neuste Version 8.0.x: http://tomcat.apache.org/download-80.cgi
  2. Archiv auspacken
    tar xvzf apache-tomcat-8.0.x.tar.gz
    Es entsteht ein neues Verzeichnis apache-tomcat-8.0.x. Das Verzeichnis können Sie nach belieben umbenennen oder an eine andere Stelle verschieben.
  3. Environment-Variablen setzen / kontrollieren
    export CATALINA_HOME=/home/cip/<login>/apache-tomcat-8.0.x bzw. den Pfad und Verzeichnisnamen Ihres Tomcat-Verzeichnisses. Zusätzlich sollte natürlich auch der CLASSPATH für Java richtig gesetzt sein. Insbesondere muss -- zum manuellen 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.
  4. 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 8.0.x.
  5. Anlegen einer Web-Applikation
    Als Web-Applikation bezeichnet man eine Servlet-Anwendung. Diese kann dabei auch aus mehreren Servlets, Facelets, 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:
    1. Erstellen eines Verzeichnisses unter <CATALINA_HOME>/webapps/ z.B. jsfdemo
    2. Erstellen der folgenden Hierarchie unterhalb dieses Verzeichnisses:
      ...jsfdemo/ressources
      ...jsfdemo/view
      ...jsfdemo/WEB-INF
      ...jsfdemo/WEB-INF/classes
      ...jsfdemo/WEB-INF/lib
       Die (kompilierten) Java-Klassen kommen später ins Verzeichnis classes, z.B. Managed Beans, und ins Verzeichnis lib sollten zusätzliche von Ihnen verwendete Java-Bibliotheken in Form von JAR-Files kommen, wie z.B. die JSF Libraries. Ins Verzeichnis view kommen die Facelet-Dateien mit der Endung .xhtml, wie z.B. login.xhtml
    3. 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="jsfdemo" version="3.1"
         xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">

  <display-name>JSF Demo</display-name>

  <servlet>                                     <!-- JSF Controller-Servlet -->
    <servlet-name>Faces Servlet</servlet-name>  <!-- Interne ID des Servlets -->

   <servlet-class>                              <!-- Name der Servlet-Klasse -->
      javax.faces.webapp.FacesServlet
    </servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>                             <!-- Verknüpfung Servlet - URL -->
    <servlet-name>Faces Servlet</servlet-name>  <!-- Servlet ID -->
    <url-pattern>/faces/*</url-pattern>         <!-- URL Pattern unter der das Servlet erreichbar sein soll -->
  </servlet-mapping>

  <context-param>                               <!-- JSF Debug Ausgaben auf Webseiten sichtbar -->
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
  </context-param>

  <welcome-file-list>
    <welcome-file>faces/view/login.xhtml</welcome-file>  <!-- Facelet, das bei Aufruf der Webapp
                                                                  als erstes aufgerufen wird -->
  </welcome-file-list>
    
</web-app>

      Ein Faclet ist dann unter http://<rechnername>:<Port>/<Web-App Name>/ (default) bzw. http://<rechnername>:<Port>/<Web-App Name>/<faces/view/faclet-name.xhtml> erreichbar.
      Genauere Informationen zu den Konfigurations-Optionen etc. finden Sie im Tomcat-Handbuch, u.A. können Sie hier bestimmte URLs durch den Container (Tomcat) mit Passwörtern schützen lassen und andere Sicherheitseinstellungen treffen. Als Vorlage für Ihr Programm kann Ihnen auch die Konfigurationsdatei des unten genannten Beispiels dienen.
    4. Entpacken + Installieren des JSF Demos
      Die Dateien müssen nur in die entsprechenden Verzeichnisse kopiert werden. Eine war-Datei ist nichts anderes als eine zip-Datei mit anderer Endung. Dateien mit Endung .war packt Tomcat in der Grundeinstellung beim Start auch automatisch aus, wenn man es in <CATALINA_HOME>/webapps/ legt.) Dann müssen Sie ggf. noch den Java-Code kompilieren und Tomcat stoppen + neustarten. Danach sollten Sie über http://<rechnername>:<Port>/jsfdemo auf die Applikation zugreifen können.
  6. 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.

Hier wurde der manuelle Weg eine Web-Applikation zu erstellen im Detail gezeigt. Unter Eclipse können Sie war-Dateien direkt importieren und per GUI-Klick auf dem Server laufen lassen.