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 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.
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 4.0 API Dokumentation
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 dann ausgeführt wird. Anders als bei CGI-Skripten oder Servlets geht man das Problem der programmgesteuerten Erzeugung von HTML-Seiten also von der HTML-Seite 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. JSP ist eine Abstraktionsstufe tiefer als JSF angesiedelt und heutzutage hauptsächlich nur noch für Entwickler von Libraries u.ä., aber nicht mehr für die Erstellung von Anwendungen attraktiv.
Java 7 - Mehr als eine Insel
JSP Tutorial
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.
Bernd Müller, Java Server
Faces 2.0, 2. Auflage, Hanser, 2010, 80/ST 253 J35 M9(2)
Michael Kurz, Martin Marinschek, JavaServer Faces 2.2, 3. Auflage,
Dpunkt, 2014, 80/ST 253 J35 K9(3)
Irian JSF @ Work
Oracle JSF Tutorial
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 JSF 2 gibt es Bestrebungen, das parallel entwickelte Context and Dependency Injection CDI zu integrieren. De Facto werden dadurch Annotationen wie z.B. @ManagedBean oder @ManagedProperty durch die entsprechenden von CDI (hier @Named und @Inject) ersetzt. Ab JSF 2.2 werden die nicht-CDI Annotationen als deprecated betrachtet und ab JSF 2.3 auch als solche markiert, d.h. der Compiler gibt damit Warnmeldungen bei deren Verwendung an. Leider betrachtet obige/gängige Literatur hautpsächlich noch die alte Notation. Hier finden Sie die CDI-Version der Demo Applikation und (nur zur Illustrationswecken) das deprecated Pendant. Ersteres benutzt die CDI-Referenzimplementierung Weld , welche sich in Form der (all-in-one) Library weld-servlet-shaded.jar im Ordner WebContent\WEB-INF\lib der Applikation befindet. Da da die Implementierung im Praktikum auf CDI basieren muss, empfehlen wir dringend CDI auch in der Einführungsaufgabe zu verwenden.
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:
http://beispielurl
wird so z.B.
http://beispielurl?jsessionid=12356123qwd1273a123
.
Solange die JSF-Welt nicht verlassen wird, kümmert sich JSF bei Bedarf automatisch um das URL-Rewriting.
Tomcat ist ein Servlet-API 4.0 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.
tar xvzf
apache-tomcat-9.0.x.tar.gz
apache-tomcat-9.0.x
. Das Verzeichnis können Sie nach
belieben umbenennen oder an eine andere Stelle verschieben.export
CATALINA_HOME=/home/cip/<login>/apache-tomcat-9.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.<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 verwenden Sie ein Schema der Form
80<Gruppennummer>
. Beachten Sie, auf diese Ports kann
man nur lokal im CIP-Pool zugreifen. Nur ein aktiver
VPN-Tunnel hilft dabei nicht. Sie können sich aber eine Portweiterleitung per SSH einrichten. 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 9.0.x.<CATALINA_HOME>/webapps/
z.B.
jsfdemo
...jsfdemo/ressources
...jsfdemo/view
...jsfdemo/META-INF
...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
und Weld Libraries. Ins Verzeichnis view
kommen die
Facelet-Dateien mit der Endung .xhtml
, wie z.B.
login.xhtml
...WEB-INF/web.xml
mit mindestens folgendem Inhalt:
|
http://<rechnername>:<Port>/<Web-App
Name>/
(default) bzw.
http://<rechnername>:<Port>/<Web-App
Name>/faces/view/<faclet-name.xhtml>
erreichbar.war
-Datei ist nichts
anderes als ein zip
-Archiv mit anderer Endung. Dateien
mit Endung .war
packt Tomcat in der Grundeinstellung
beim Start auch automatisch aus, wenn man sie in
<CATALINA_HOME>/webapps/
legt.) Vergessen Sie
nicht die für Weld/CDI wichtigen dateien
...META-INF/context.xml
, bean.xml
und
faces-config.xml
zu übernehmen. Dann müssen Sie
ggf./bei Änderungen noch den Java-Code kompilieren und Tomcat
stoppen + neustarten. Danach sollten Sie über
http://<rechnername>:<Port>/jsfdemo
auf die
Applikation zugreifen können.<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.<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.