JBoss Undertow został wprowadzony jako nowy serwer WWW w projekcie WildFly 8. W poprzednich wersjach JBoss EAP, JBoss AS oraz JBoss Web Server używany był projekt Tomcat jako podstawowy podsystem serwera WWW.

Problem jednak w tym, że Tomcat został zaprojektowany jako serwer autonomiczny, o dość statycznej architekturze i wysokich wymaganiach na zasoby systemu. Projekt WildFly jako najbardziej nowatorski idzie jeszcze dalej w kierunku modularności. Dzięki temu zbudowany w oparciu o niego JBoss EAP7 pozwala dostarczać tylko to czego w danej chwili potrzebujemy. Mający sztywną i mało elastycznie zaprojektowaną architekturę serwer WWW nie będzie dobrze funkcjonował w obrębie nowych wymagań JBoss EAP7.

Przyjrzyjmy się zatem serwerowi UNDERTOW, który jest osadzony jako jeden z podsystemów nowego JBoss EAP7, a nie jako osobny serwer.

Undertow osadzony jako podsystem w Red Hat JBoss Enterprise Application Platform 7

Każde możliwe działanie jakie podejmuje serwer WWW np. obsługa sesji, uwierzytelnianie, obsługa błędów, obsługa trwałych połączeń, zarządzanie serwletami – można zatomizować i podzielić na podserwisy lub handler’y. Handler’y są następnie powiązane razem w taki sposób, aby stworzyć dokładny workflow, który jest wymagany dla danego przypadku użycia. Ponieważ Undertow jest napisany w Java’ie, można zatem używać serwletów, a wszelkie serwlety można mieszać z hander’ami.

Prosty workflow. Diagramem Francesco Marchioni, Geeks kod Java, 2014.

Co to znaczy w sensie funkcjonalnym? Otóż by użyć Undertow wymagany jest jedynie handler, który aktywuje cały workflow. A to potencjalnie znacznie usprawni działanie serwera i poprawi stosunek osiągów do zużycia zasobów. Dla porównania: pakiet Undertow jest mniejszy niż 1 MB, a w czasie wykonywania (gdy jest załadowany do pamięci), jego wielkość sterty (HEAP) to około 4 MB. Z kolei typowy rozmiar sterty (HEAP) dla Tomcat mieści się w przedziale od 64 do 128 MB. To ponad trzydziestokrotnie więcej!

Undertow to nie tylko zmiana architektury. Istnieje kilka innych nowatorskich cech, które opisujemy poniżej:

1. Wspiera HTTP upgrade – usługa, która pozwala na przełączanie pomiędzy różnymi protokołami HTTP (w tym HTTP2), a nawet innymi przyjaznymi Java’ie protokołami np. EJB przez HTTP. Zmniejsza to liczbę portów, którymi można dysponować – co doskonale nadaje się do zastosowań chmurowych, w których ilość otwartych portów jest ograniczona.
2. Może pracować jako reverse proxy dla klastra serwerów internetowych. W Undertow topologia klastra może być tworzona i aktualizowana dynamicznie, bez konieczności ręcznej interwencji lub wsparcia serwerów takich jak Apache.
3. Obsługuje zarówno blocking i nonblocking I/O. Blocking oznacza, że jeden request musi zostać zakończony zanim serwer zacznie przetwarzać kolejne żądanie. Nonblocking oznacza, że serwer będzie przetwarzać wiele jednoczesnych żądań, o ile nie są one zależne od siebie.
4. Undertow wykorzystuje pamięć buforową. Oznacza to, że przechowuje dane w pamięci RAM, a nie pisze danych do pamięci fizycznej (dysk). Dzięki temu informacje są znacznie szybciej przetwarzane/odzyskiwane.

Ta lekkość i wszechstronność Undertow ma swój cel. Jako wbudowany świadczy te same usługi co dotychczasowy (osobny) projekt. Został tak zaprojektowany by natywnie działać w środowiskach chmurowych. Szczególnym przypadkiem użycia jest Internet Rzeczy (IoT), w którym mały i lekki Undertow może wiele zwojować 😉 Ta lekkość pozwala np. wbudować go w aplikacje, którą później sam kontroluje.

Odejście od projektu Tomcat to bardzo dobry pomysł. Wreszcie w JBoss mamy w pełni modularną usługę serwera WWW, która znacznie poprawia wydajność i oszczędzi nam zasoby w naszych Data Center.