© Excellent backgrounds/Shutterstock.com
Java Magazin
Die Rolle des EE-Servers in Zeiten von Docker und Co.

Enterprise Java beyond the Application Server


Java EE war jahrelang von den Application Servern geprägt, die den Standard implementierten. Sprach man von JEE (bzw. damals noch J2EE) war das gleichbedeutend mit WebLogic, WebSphere und Co. Wie hat sich diese Sichtweise gewandelt? Welche Bedeutung hat ein Standardisierungsprozess wie JEE heute und was wird eigentlich aus den Application Servern?

Historisch war J2EE (der Vorgänger von Java EE) nicht ohne einen klassischen Application Server denkbar. Neben einer Java Runtime benötigt eine EE-Applikation nämlich noch einige weitere Funktionalität, um gemäß der Spezifikation zu funktionieren. Diese Funktionalität stellt der Application Server zur Verfügung. Insbesondere der J2EE-Standard basierte größtenteils auf dem Komponentenmodell der EJBs. Diese waren zu der damaligen Zeit nicht nur für die Entwickler schwer zu implementieren [1], sondern erforderten auch eine Laufzeitumgebung, die viele Aufgaben hatte: XML-Deskriptoren mussten ausgewertet, Transaktionsbehandlung musste realisiert, RMI für die Remote Interfaces zur Verfügung gestellt werden, Aufrufe auf den Remote Interfaces mussten mit den lokalen EJB-Instanzen gekoppelt werden.

Realisiert wurde diese Funktionalität durch die Application Server, in denen für jede EJB ein oder mehrere Proxies generiert und allerlei Funktionalität unter der Haube realisiert wurde. Das alles sorgte dafür, dass EJBs schwergewichtige Komponenten waren, d. h. es war teuer, sie zu instanziieren, und auch zur Laufzeit war ein Aufruf einer EJB-Methode nicht sehr performant. Um das festzustellen, musste man nicht erst zwei EJBs wechselseitig in einer Rekursion aufrufen. Um das Problem der teuren Instanziierung zu umgehen, war im Standard ein Instance Pooling vorgesehen. Hier war die Idee, dass der Application Server bereits vorkonfigurierte Instances in einem Pool lagern und sie entnehmen konnte, wenn eine benötigt wurde. Dadurch sollte das teure Instanziieren umgangen werden. Auch dieser Pool wurde natürlich vom Application Server verwaltet.

J2EE war also nicht nur in der Entwicklung schwergewichtig, sondern auch zur Laufzeit, was vor allem an den beschriebenen Anforderungen an die Server lag. Die damals gängigen Application Server wie IBM WebSphere und Bea (später Oracle) WebLogic handelten sich daher nicht zu Unrecht den Ruf ein, schwergewichtige Monster zu sein.

Leichtgewichtiges Komponentenmodell und WebProfile

Java EE 5 brachte mit der Umstellung von XML-Deployment-Deskriptoren auf Annotations ein leichtgewichtigeres Mo...

Java Magazin
Die Rolle des EE-Servers in Zeiten von Docker und Co.

Enterprise Java beyond the Application Server

Java EE war jahrelang von den Application Servern geprägt, die den Standard implementierten. Sprach man von JEE (bzw. damals noch J2EE) war das gleichbedeutend mit WebLogic, WebSphere und Co. Wie hat sich diese Sichtweise gewandelt? Welche Bedeutung hat ein Standardisierungsprozess wie JEE heute und was wird eigentlich aus den Application Servern?

Arne Limburg


Java EE war jahrelang von den Application Servern geprägt, die den Standard implementierten. Sprach man von JEE (bzw. damals noch J2EE) war das gleichbedeutend mit WebLogic, WebSphere und Co. Wie hat sich diese Sichtweise gewandelt? Welche Bedeutung hat ein Standardisierungsprozess wie JEE heute und was wird eigentlich aus den Application Servern?

Historisch war J2EE (der Vorgänger von Java EE) nicht ohne einen klassischen Application Server denkbar. Neben einer Java Runtime benötigt eine EE-Applikation nämlich noch einige weitere Funktionalität, um gemäß der Spezifikation zu funktionieren. Diese Funktionalität stellt der Application Server zur Verfügung. Insbesondere der J2EE-Standard basierte größtenteils auf dem Komponentenmodell der EJBs. Diese waren zu der damaligen Zeit nicht nur für die Entwickler schwer zu implementieren [1], sondern erforderten auch eine Laufzeitumgebung, die viele Aufgaben hatte: XML-Deskriptoren mussten ausgewertet, Transaktionsbehandlung musste realisiert, RMI für die Remote Interfaces zur Verfügung gestellt werden, Aufrufe auf den Remote Interfaces mussten mit den lokalen EJB-Instanzen gekoppelt werden.

Realisiert wurde diese Funktionalität durch die Application Server, in denen für jede EJB ein oder mehrere Proxies generiert und allerlei Funktionalität unter der Haube realisiert wurde. Das alles sorgte dafür, dass EJBs schwergewichtige Komponenten waren, d. h. es war teuer, sie zu instanziieren, und auch zur Laufzeit war ein Aufruf einer EJB-Methode nicht sehr performant. Um das festzustellen, musste man nicht erst zwei EJBs wechselseitig in einer Rekursion aufrufen. Um das Problem der teuren Instanziierung zu umgehen, war im Standard ein Instance Pooling vorgesehen. Hier war die Idee, dass der Application Server bereits vorkonfigurierte Instances in einem Pool lagern und sie entnehmen konnte, wenn eine benötigt wurde. Dadurch sollte das teure Instanziieren umgangen werden. Auch dieser Pool wurde natürlich vom Application Server verwaltet.

J2EE war also nicht nur in der Entwicklung schwergewichtig, sondern auch zur Laufzeit, was vor allem an den beschriebenen Anforderungen an die Server lag. Die damals gängigen Application Server wie IBM WebSphere und Bea (später Oracle) WebLogic handelten sich daher nicht zu Unrecht den Ruf ein, schwergewichtige Monster zu sein.

Leichtgewichtiges Komponentenmodell und WebProfile

Java EE 5 brachte mit der Umstellung von XML-Deployment-Deskriptoren auf Annotations ein leichtgewichtigeres Mo...

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