© Excellent backgrounds/Shutterstock.com
Java Magazin
Zwei Jahre nach dem Tod der Java Application Server

Leben Totgesagte länger?

Vor zwei Jahren habe ich den Tod der Java Application Server ausgerufen. Doch noch immer nutzen viele Anwendungen trotz so mancher Nachteile eben diese. Warum? Wo ist es vielleicht auch noch sinnvoll? Und welche Alternativen gibt es mittlerweile?

Eberhard Wolff


Der ursprüngliche Artikel [1] hat mehrere Gründe aufgeführt, warum Application Server keine zeitgemäße Plattform mehr sind. So ist Two-Phase Commit (2PC) zur Koordination mehrerer transaktionaler Ressourcen aus verschiedenen Gründen kaum sinnvoll. Dieser Punkt wäre einen eigenen Artikel wert, soll hier aber nicht weiter betrachtet werden. Mittlerweile ist es außerdem mit Technologien wie Spring Boot [2] möglich, Transaktionsmanager wie Atomikos oder Bitronix auch ohne Application Server zu nutzen. Das war zwar schon lange möglich, ist nun aber noch einmal wesentlich einfacher geworden. Selbst wenn also 2PC notwendig sein sollte, ist das noch lange kein Grund für den Einsatz eines Application Servers.

Der zweite Grund war, dass Application Server keine vollständige Plattform sind. Praktisch jede Anwendung benötigt neben dem Application Server zusätzliche eigene Bibliotheken. Also fehlen Features, die Anwendungen selbst mitbringen müssen.

Durch den Application Server legt man sich außerdem für alle Bestandteile der Plattform auf eine bestimmte Version fest. Es ist nicht möglich, nur ausgewählte Bestandteile zu aktualisieren, um beispielsweise Security oder Bug Fixes einzuspielen. Und der Application Server unterstützt nur spezielle Anwendungen – nämlich Webanwendungen. Unterstützung für Batchanwendungen oder Integrationsanwendungen fehlen. Also muss eine Anwendung einen Teil der Infrastruktur selbst mitbringen. Als vollständige Plattform ist der Application Server nicht ausreichend. Noch wichtiger ist die Kritik am Application Server als Plattform für mehrere Anwendungen.

Die Anwendungen auf einem Application Server sind nur unzureichend isoliert. Sie können zwar keinen Code anderer Anwendungen laden, aber bezüglich CPU und Speicher bedienen sie sich aus einem Pool. Eine Anwendung, die viel Speicher allokiert, bringt den Application Server und damit alle Anwendungen auf dem Application Server zum Absturz. Ebenso ist meistens kein isoliertes Deployment möglich. Denn meistens wird der Application Server auch beim Deployment einer einzigen Anwendung neu gestartet.

Während ursprünglich mehrere Anwendungen auf einem Application Server deployt werden sollten, ist das Verhältnis mittlerweile umgedreht: Eine Anwendung wird oft auf einem Cluster von Application Servern und damit auf mehreren Application Servern betrieben.

Application Server und Anwendungen hängen wechselseitig voneinander ab: Die Anwendung verwendet die Funktionen des Application Servers und hängt dah...

Java Magazin
Zwei Jahre nach dem Tod der Java Application Server

Leben Totgesagte länger?

Vor zwei Jahren habe ich den Tod der Java Application Server ausgerufen. Doch noch immer nutzen viele Anwendungen trotz so mancher Nachteile eben diese. Warum? Wo ist es vielleicht auch noch sinnvoll? Und welche Alternativen gibt es mittlerweile?

Eberhard Wolff


Der ursprüngliche Artikel [1] hat mehrere Gründe aufgeführt, warum Application Server keine zeitgemäße Plattform mehr sind. So ist Two-Phase Commit (2PC) zur Koordination mehrerer transaktionaler Ressourcen aus verschiedenen Gründen kaum sinnvoll. Dieser Punkt wäre einen eigenen Artikel wert, soll hier aber nicht weiter betrachtet werden. Mittlerweile ist es außerdem mit Technologien wie Spring Boot [2] möglich, Transaktionsmanager wie Atomikos oder Bitronix auch ohne Application Server zu nutzen. Das war zwar schon lange möglich, ist nun aber noch einmal wesentlich einfacher geworden. Selbst wenn also 2PC notwendig sein sollte, ist das noch lange kein Grund für den Einsatz eines Application Servers.

Der zweite Grund war, dass Application Server keine vollständige Plattform sind. Praktisch jede Anwendung benötigt neben dem Application Server zusätzliche eigene Bibliotheken. Also fehlen Features, die Anwendungen selbst mitbringen müssen.

Durch den Application Server legt man sich außerdem für alle Bestandteile der Plattform auf eine bestimmte Version fest. Es ist nicht möglich, nur ausgewählte Bestandteile zu aktualisieren, um beispielsweise Security oder Bug Fixes einzuspielen. Und der Application Server unterstützt nur spezielle Anwendungen – nämlich Webanwendungen. Unterstützung für Batchanwendungen oder Integrationsanwendungen fehlen. Also muss eine Anwendung einen Teil der Infrastruktur selbst mitbringen. Als vollständige Plattform ist der Application Server nicht ausreichend. Noch wichtiger ist die Kritik am Application Server als Plattform für mehrere Anwendungen.

Die Anwendungen auf einem Application Server sind nur unzureichend isoliert. Sie können zwar keinen Code anderer Anwendungen laden, aber bezüglich CPU und Speicher bedienen sie sich aus einem Pool. Eine Anwendung, die viel Speicher allokiert, bringt den Application Server und damit alle Anwendungen auf dem Application Server zum Absturz. Ebenso ist meistens kein isoliertes Deployment möglich. Denn meistens wird der Application Server auch beim Deployment einer einzigen Anwendung neu gestartet.

Während ursprünglich mehrere Anwendungen auf einem Application Server deployt werden sollten, ist das Verhältnis mittlerweile umgedreht: Eine Anwendung wird oft auf einem Cluster von Application Servern und damit auf mehreren Application Servern betrieben.

Application Server und Anwendungen hängen wechselseitig voneinander ab: Die Anwendung verwendet die Funktionen des Application Servers und hängt dah...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang