Jakarta Servlet

Als Jakarta Servlet (früher Java Servlet) bezeichnet man Java-Klassen, deren Instanzen innerhalb eines Webservers Anfragen von Clients entgegennehmen und beantworten. Der Inhalt der Antworten kann dabei dynamisch, also im Moment der Anfrage, erstellt werden und muss nicht bereits statisch (etwa in Form einer HTML-Seite) für den Webserver verfügbar sein. Servlets stellen eine Weiterentwicklung der ursprünglich im Web-Bereich verwendeten Schnittstelle CGI oder anderer Konzeptionen dar. Java-Webanwendungen nutzen hauptsächlich Servlets, während die klassische Erzeugung dynamischer Web-Inhalte über CGI zum Beispiel mittels PHP, Ruby on Rails, Active Server Pages oder Perl erfolgt.

Die Servlet-Spezifikation ist Teil der Jakarta-EE-Technologie. Servlet-Container sind damit fester Bestandteil aller Jakarta-EE-Anwendungsserver. Jedoch ist ein Servlet-Container nicht immer eine vollständige Jakarta-EE-Implementierung. Es gibt unabhängig davon Webserver, die einen Servlet-Container enthalten (z. B. Apache Tomcat, Jetty).

Ein Servlet wird implementiert, indem eine Klasse erstellt wird, die die Schnittstelle jakarta.servlet.Servlet implementiert. Es gibt die Klasse jakarta.servlet.http.HttpServlet, die diesen Vorgang vereinfacht. Anschließend wird eine oder beide Methoden doGet und doPost überschrieben, um die beiden wichtigsten HTTP-Methoden GET und POST verarbeiten zu können. Häufig wird auch nur die Methode service überschrieben, welche unabhängig vom HTTP-Befehl aufgerufen wird. Um das Servlet auf dem Web-Server registrieren zu können, müssen Metainformationen bereitgestellt werden. Diese Metainformationen werden hinterlegt in einer XML-Datei namens web.xml, dem sogenannten Deployment Descriptor. Der Deployment Descriptor wird zusammen mit der kompilierten Servlet-Klasse (sowie ggf. weiteren benötigten Klassen) in einer Archiv-Datei, dem Web-Archiv, zusammengeführt. Dieses Web-Archiv wird dem Servlet-Container über eine von ihm bereitgestellte Funktionalität übergeben (deployment).

Zur Laufzeit greift der Webserver auf den Servlet-Container zu, der wiederum möglicherweise eine Instanz des Servlets erzeugt und die entsprechende Methode startet. Einige Container wickeln mehrere Requests und damit Threads gleichzeitig über einen Pool von Servlets ab. Deswegen sollte bei Attributen innerhalb eines Servlet immer der gleichzeitige Zugriff von mehreren Threads im Hinterkopf behalten werden.

Häufig werden in einem Servlet sowohl Parameter der Anfrage als auch Sitzungsdaten verwendet, um zum Beispiel eine personalisierte Antwort zu erzeugen oder Daten auf dem Server zu speichern oder zu verändern. Die Antworten können neben Text (zum Beispiel HTML oder XML) auch Bilder oder andere Binärdateien sein.

Servlets werden oft nach dem Entwurfsmuster Model View Controller (MVC) in Form von Jakarta Server Pages (JSP) verwendet. Hierbei repräsentieren meist die JSP oder JSF die View. Interessanterweise werden auch die JSP-Seiten zur Laufzeit zu Servlets kompiliert. Die selbst geschriebenen Servlets bilden Controller sowie Model ab. Frameworks wie z. B. Spring MVC oder Struts bilden eine weitere Ebene der Abstraktion und bieten ein schärfer getrenntes MVC-Muster.

Das englische Wort „Servlet“ ist ein Kofferwort, das sich aus den Begriffen „Server“ und „Applet“ zusammensetzt, also serverseitiges Applet und somit Servlet.

Sun hat mit Einführung der Sprache Java zwei Arten von Anwendungen definiert: Applications (also Desktop-Anwendungen) und Applets (wörtlich Anwendung-chen, also Mini-Anwendungen, die nur innerhalb eines Containers – in der Regel in einem Webbrowser – ablaufen). Als die Java-Technologie auch auf die Serverseite kam, suchte man dort einen Namen für die kleinen Codestückchen, die jetzt nicht mehr im Kontext des Browsers, sondern in dem des Webservers laufen, der an Applet erinnert. Schließlich ist es ein im weitesten Sinne ähnliches Konzept: kleine Serveranwendung-chen, die einen Container (hier: ein um ein Servlet-Container erweiterter Web-Server) um sich herum brauchen, um laufen zu können. Dabei kam man auf Servlet.

Die Handhabung, das Verhalten und das Verwalten von Jakarta-Servlets folgt einem Standard, der über den Java Community Process (JCP) definiert wird. An diesem Standard wird aktiv gearbeitet und es gibt verschiedene Versionen. Die letzte veröffentlichte Version ist 5.0, welche Bestandteil der Jakarta EE 9 Spezifikation ist. Sie wurde im September 2020 veröffentlicht.^[1]

Um die Funktionalität eines Servers zu erweitern, können separate, ausführbare Module geschrieben werden. Diese Server Extensions gibt es für zahlreiche Plattformen, z. B. existiert für die Microsoft Internet Information Services (IIS) das sogenannte Internet Server API (ISAPI). In Java werden Server-Erweiterungen mit Hilfe der Servlet API geschrieben. Die Server-Extension-Module heißen Servlets.

1. Der Benutzer sendet ein ausgefülltes Formular im Browser ab.
2. Der Browser löst die damit verbundene Aktion aus, indem er die Formulardaten an den Webserver sendet.
3. Der Webserver übersetzt den Aktionsnamen des Formulars in den Namen einer Servletklasse. Er verwendet dazu Informationen aus dem Deployment-Deskriptor, einer Datei namens „web.xml“.
4. Der Webserver ruft je nach HTTP-Methode des Formulars (GET oder POST) die Methode doGet bzw. doPost-Methode des Servlets auf und übergibt dabei die Anfragedaten („request“) als Parameter zusammen mit einem response-Objekt, mit dem Ausgaben getätigt werden können. Die Ausgaben werden nach Abschluss der Methode vom Webserver an den Browser gesendet.
5. Der Browser nimmt die Antwort entgegen und stellt sie dar.
6. Der Benutzer liest die Antwort im Browser.

Das folgende Ablaufdiagramm zeigt einen typischen Ablauf beim Aufruf eines Servlets.

• jcp.org
• Jakarta Servlet 5.0 (englisch)
  • Java Servlet 4.0 Spezifikation (englisch)
  • Java Servlet 3.1 Spezifikation (englisch)
  • Java Servlet 3.0 Spezifikation (englisch)
• Java Servlet Technology Overview bei Oracle (englisch)
• Tomcat apache.org (englisch) – die Referenzimplementation der Servlet- und JSP-Spezifikation

1. ↑ Jakarta Servlet 5.0