© Excellent backgrounds/Shutterstock.com
Java Magazin
Sind sie noch zeitgemäß?

Der Tod der Java Application Server

Application Server und Enterprise Java werden oft gleichgesetzt. Aber das Konzept des Application Servers ist mehr als zehn Jahre alt - Zeit für eine kritische Bewertung. Passt die Idee eines Application Servers zu aktuellen Trends wie Micro Services und Embedded Containers?

Eberhard Wolff


Zunächst zum Begriff Application Server: Es geht hier nicht nur um vollständige Java-EE-Implementierungen, sondern auch um Servlet Container wie Tomcat oder Jetty. Diese Server versprechen Folgendes:

bieten einen Container für mehrere Anwendungenbieten die für die Anwendungen notwendige Infrastrukturunterstützen Betriebsprozesse wie Deployment und Monitoring

Container

Damit ein Application Server tatsächlich mehreren Anwendungen eine Heimat bieten kann, müssen die Anwendungen voneinander isoliert werden. Dazu werden Class Loader, die in Java-Umgebungen das Laden von Code umsetzen, benötigt. Jede Anwendung bekommt ihren eigenen Class Loader, sodass sie nur ihre eigenen Klassen nutzen kann. Das führt in der Praxis häufig zu Problemen – wohl jeder Nutzer eines Application Servers hat schon einmal ein Problem im Bereich des Classloadings untersucht, was oft eine sehr aufwändig Aufgabe ist.

Die Isolation auf Basis von Class Loadern ist leider nicht ausreichend. Computer haben Ressourcen wie CPU, Speicher oder Dateisysteme. Beim Zugriff auf diese Ressourcen sind die Anwendungen auf einem Application Server nicht voneinander isoliert. Das kann zu Problemen führen: Wenn beispielsweise Kunden eine Anwendung über eine Webschnittstelle interaktiv nutzen und gleichzeitig JMS große Datenmengen im Hintergrund bearbeitet, so sollte der Application Server natürlich der interaktiven Nutzung mehr Ressourcen zur Verfügung stellen. Wenn ein Kunde zu lange warten muss, sucht er sich ein anderes Angebot. Wenn die Bearbeitung einer asynchronen Anfrage etwas länger dauert, sollte das kein Problem sein. Die Ressourcen entsprechend zu verteilen, ist aber in einem Java-Prozess gar nicht möglich.

Genau diese Probleme lösen Betriebssysteme. Sie isolieren Prozesse und stellen jedem Prozess Ressourcen wie CPU oder Speicher zur Verfügung. Wenn also tatsächlich eine vollständige Isolation notwendig ist, müsste die JVM ein Betriebssystem werden – das kann aber kaum das Ziel sein.

Die Java-EE-Spezifikation spricht auch gar nicht davon, dass ein Application Server mehrere Anwendungen beheimaten muss – dort ist nur die Rede von Komponenten. Dazu gehören beispielsweise WARs für Web- oder JARs für EJB-Komponenten. Für ein solches Modell ist aber eine vollständige Class-Loader-Isolation nicht so sinnvoll – schließlich teilen sich diese Komponenten meistens Klassen. Eine Isolation von CPU oder Speicher ist immer noch notwendig, denn wenn ein Teil der Anwendung interaktiv genutzt wird, sollte er eine...

Java Magazin
Sind sie noch zeitgemäß?

Der Tod der Java Application Server

Application Server und Enterprise Java werden oft gleichgesetzt. Aber das Konzept des Application Servers ist mehr als zehn Jahre alt - Zeit für eine kritische Bewertung. Passt die Idee eines Application Servers zu aktuellen Trends wie Micro Services und Embedded Containers?

Eberhard Wolff


Zunächst zum Begriff Application Server: Es geht hier nicht nur um vollständige Java-EE-Implementierungen, sondern auch um Servlet Container wie Tomcat oder Jetty. Diese Server versprechen Folgendes:

bieten einen Container für mehrere Anwendungenbieten die für die Anwendungen notwendige Infrastrukturunterstützen Betriebsprozesse wie Deployment und Monitoring

Container

Damit ein Application Server tatsächlich mehreren Anwendungen eine Heimat bieten kann, müssen die Anwendungen voneinander isoliert werden. Dazu werden Class Loader, die in Java-Umgebungen das Laden von Code umsetzen, benötigt. Jede Anwendung bekommt ihren eigenen Class Loader, sodass sie nur ihre eigenen Klassen nutzen kann. Das führt in der Praxis häufig zu Problemen – wohl jeder Nutzer eines Application Servers hat schon einmal ein Problem im Bereich des Classloadings untersucht, was oft eine sehr aufwändig Aufgabe ist.

Die Isolation auf Basis von Class Loadern ist leider nicht ausreichend. Computer haben Ressourcen wie CPU, Speicher oder Dateisysteme. Beim Zugriff auf diese Ressourcen sind die Anwendungen auf einem Application Server nicht voneinander isoliert. Das kann zu Problemen führen: Wenn beispielsweise Kunden eine Anwendung über eine Webschnittstelle interaktiv nutzen und gleichzeitig JMS große Datenmengen im Hintergrund bearbeitet, so sollte der Application Server natürlich der interaktiven Nutzung mehr Ressourcen zur Verfügung stellen. Wenn ein Kunde zu lange warten muss, sucht er sich ein anderes Angebot. Wenn die Bearbeitung einer asynchronen Anfrage etwas länger dauert, sollte das kein Problem sein. Die Ressourcen entsprechend zu verteilen, ist aber in einem Java-Prozess gar nicht möglich.

Genau diese Probleme lösen Betriebssysteme. Sie isolieren Prozesse und stellen jedem Prozess Ressourcen wie CPU oder Speicher zur Verfügung. Wenn also tatsächlich eine vollständige Isolation notwendig ist, müsste die JVM ein Betriebssystem werden – das kann aber kaum das Ziel sein.

Die Java-EE-Spezifikation spricht auch gar nicht davon, dass ein Application Server mehrere Anwendungen beheimaten muss – dort ist nur die Rede von Komponenten. Dazu gehören beispielsweise WARs für Web- oder JARs für EJB-Komponenten. Für ein solches Modell ist aber eine vollständige Class-Loader-Isolation nicht so sinnvoll – schließlich teilen sich diese Komponenten meistens Klassen. Eine Isolation von CPU oder Speicher ist immer noch notwendig, denn wenn ein Teil der Anwendung interaktiv genutzt wird, sollte er eine...

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