© Excellent backgrounds/Shutterstock.com
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?

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 wir...

Neugierig geworden?

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