Java EE 8: Ein erster Blick

Servlet-Spezifikation 4.0

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Die Servlet-Spezifikation 4.0 legt den Fokus sehr stark auf die Unterstützung des neuen HTTP/2-Protokolls. Daneben fand man aber auch noch die Zeit, eine neue Mapping-API für Servlets zu integrieren. Was das bringt und wie man damit arbeitet, klärt dieses Video.

Transkript

Die Servlet-Spezifikation innerhalb der Java EE Version 8 liegt in einer neuen Hauptversion vor, 4.0. In diesem Video werden wir uns damit auseinandersetzen, was diese Version an Neuerungen bietet. Die neue Version der Servlet-Spezifikation legt ihren ganz besonderen Fokus auf die Unterstützung des HTTP/2-Protokolls. Dieses Protokoll ist schon sehr revolutionär für den Umgang mit Webseiten, es verändert nämlich auch die Vorgehensweisen, wie Daten geladen und bereitgestellt werden. Deswegen war es den Entwicklern extrem wichtig, eine Unterstützung bereitzustellen, die abwärtskompatibel zur bisherigen Implementierung in Version 3.1 war. Und gleichzeitig sollte auch die Unterstützung für das alte HTTP-Protokoll in Version 1.1 beibehalten werden. Darüber hinaus hat man noch die Zeit gefunden eine neue Mapping API für Servlets bereitzustellen. Um zu verstehen, warum HTTP/2 so wichtig für die Zukunft auch der Servlet API ist, sollte man sich zunächst einmal fragen, was falsch ist an der bisherigen HTTP-Spezifikation/1.1. Grundsätzlich ist daran nicht so viel falsch, denn diese Spezifikation funktioniert schon seit gut 20 Jahren. Sie ist aber langsam, denn Requests werden sequenziell abgearbeitet, einer nach dem anderen. Darüber hinaus gibt es keine serverseitige Push-Funktionalität und die Umsetzung in sich ist ineffizient, denn es gibt keine gute Unterstützung des TCP-Protokolls. Und zu guter Letzt sei auch erwähnt, diese Spezifikation ist schon fast 20 Jahre alt und in 20 Jahren ändern sich die Herausforderungen und Ansätze sowie die Ideen und Grundsätze, nach denen gearbeitet wird, schon fundamental. Vorhang auf für den neuen Standard HTTP/2. Dieser möchte mit den Nachteilen des alten Standards aufräumen, ohne komplett alles neu erfinden zu müssen. Aus diesem Grund gibt es jetzt Dinge wie Request/Response Multiplexing, bei dem auf einem Request mehrere Antworten gesendet werden können, oder in einer Anfrage mehrere Pushes stattfinden können. Streams, also die Datenströme die fließen, können priorisiert werden, das heißt, die werden zwar zur selben Zeit losgeschickt oder abgerufen, kommen aber unterschiedlich schnell an. Server Push erlaubt es Dinge gleich mitzusenden, ohne dass sie vom Client aus direkt aufgerufen werden müssen, und die Header lassen sich komprimieren. Darüber hinaus gibt es dutzende weitere Änderungen, die aber extrem tief technisch sind und die vor allen Dingen auch damit zu tun haben, wie mit dem TCP-Protokoll, was unten drunter liegt, interagiert wird. Diese neuen Funktionalitäten, die die HTTP/2-Spezifikation bereitstellt, finden sich nun auch, zumindest zum Teil für uns sichtbar, in der Servlet-Spezifikation 4.0. So gibt es bei den HttpServletRequest und HttpServletResponse Klassen eine neue Methode, getStreamId. Mit deren Hilfe können wir auf den aktuellen Stream zugreifen und diesen identifizieren. Darüber hinaus gibt es eine neue Klasse Priority. Damit können wir festlegen, dass bestimmte Streams mit einer höheren Priorität zum Client übertragen werden. Und dieses Setzen der Priorität findet sich dann eben auch in den HttpServletRequest und HttpServletResponse Klassen. Die Unterstützung für serverseitige Pushes ist ein weiteres Highlight innerhalb der Servlet-Spezifikation 4.0. Zu diesem Zweck gibt es ein Interface namens PushBuilder. Und dieses Interface kann genutzt werden, um Web-Ressourcen zum Client zu senden und zwar findet dieses Senden schon statt, während die eigentliche Abarbeitung der Anforderungen passiert. Das erlaubt es dann, dass Bilder beispielsweise zeitgleich mit der Seite oder sogar schon vor der Seite beim Client ankommen, obwohl dieser diese Bilder noch gar nicht explizit angefordert hat. Sehen wir uns an, wie das funktioniert. Ich habe hier einmal den Google Chrome Browser offen und lösche seinen Browser-Cache um sicherzustellen, dass auch wirklich nichts im Cache ist. Nun rufe ich einmal die Developer-Tools auf und wechsle in den Bereich Network. Ich rufe nun eine Adresse auf, die lokal liegt an dieser Stelle. Und nun kann ich erkennen, dass der eigentliche Anforderungszeitraum der gesamten Webseite 31 ms beträgt, ein Bild allerdings bereits nach 1 ms vorlag. Dieses Bild wurde per serverseitigem Push an den Client geschickt, während der Rest der Seite serverseitig noch verarbeitet worden ist. Somit konnte der Client dann an dieser Stelle das Bild bereits in Empfang nehmen, ohne dass er einen expliziten, zweiten Anlauf nehmen musste, um das Bild nachzuladen wie er das bei klassischem HTTP/1.1 machen müsste. Sie sehen das auch hier in diesem Initiator-Bereich, dort können Sie sehen, es war hier ein PushRequest von diesem HTTP/2 End-Point. Die Servlet API 4.0 bietet mithilfe der neu hinzugekommen Mapping API eine ganz kleine, aber sehr willkommene Erleichterung des Arbeitsalltags, gerade dann, wenn Sie Frameworks implementieren, die stark und intensiv mit Servlets interagieren. Generell ist es ja so, dass Servlets auf verschiedenen Pfaden gemappt sein können, das heißt hier können auf verschiedene Adressen untergeordnet innerhalb der Seite lauschen. Das können Adressen sein, die wie ein Dateiname aussehen, das können Pfade sein, das können implizite oder explizite Mappings sein. Bisher war es schwierig, nicht unmöglich aber schwierig den tatsächlich aufgerufenen Pfad herauszufinden. Da musste man schon relativ tief ins Request-Objekt hineingehen, und dort dann die entsprechenden Dinge abfragen. Das Ganze ist nun mit der Mapping API deutlich vereinfacht worden. Es gibt nämlich bei der HttpServletRequest Klasse eine neue Methode getMapping, und diese Methode gibt uns eine Mapping-Instanz zurück. Und mithilfe dieser Mapping-Instanz bekommen wir dann verschiedene Informationen raus, zum Beispiel den ermittelten Pfad, das Pattern, was auf diesem Pfad angewendet worden ist, also Dateiname oder ähnliche Sachen, und die Art des Machings, also beispielsweise ist es in Form einer Dateierweiterung passiert, ist es ein Pfad gewesen, ist es implizit gewesen und so weiter und so fort. Das macht das Leben nicht von Otto Normalverbraucher einfacher, aber von Leuten, die sehr, sehr tief mit der Servlet API interagieren müssen, gibt es dann hier an der Stelle schon Beifall. In diesem Video haben wir uns damit auseinandergesetzt, welche Änderungen und Erweiterungen es in der Servlet-Spezifikation 4.0 gibt. Wir haben kurz besprochen, was das Interessante an HTTP/2 ist. Wir haben gesehen, wie wir Servlet-Push implementieren können, wie sich das auswirkt und wir haben über die kleine, feine Servlet 4.0 Mapping API gesprochen.

Java EE 8: Ein erster Blick

Lernen Sie die wichtigsten Neuerungen und Verbesserungen der akutellen Java-EE-Spezifikation kennen.

43 min (6 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:13.09.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!