© Enkel/Shutterstock.com
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 Modell für die Entwicklung von EJBs. Was den Entwickler freute, wirkte sich auf das Laufzeitverhalten der Server leider überhaupt nicht aus. Da das EJB-Komponentenmodell im Kern identisch geblieben war, waren die Server zur Laufzeit weiterhin gewohnt schwerfällig.

Das änderte sich mit dem Erscheinen von Java EE 6 und dem darin enthaltenen alternativen Komponentenmodell CDI. Es versprach (und hielt), dass es mit Enterprise Java nicht nur möglich sein sollte, einfach Komponenten zu entwickeln, sondern dass diese auch zur Laufzeit nicht mit dem Overhead, der von EJB bekannt war, verbunden sein sollten und damit deutlich leichtgewichtiger unterwegs waren. Dieses Komponentenmodell existierte zunächst neben EJBs.

Aber Java EE 6 brachte weitere Neuerungen: So wurde z. B. das Konzept der Profiles eingeführt. Die Idee war, dass ein Server nicht mehr den kompletten schwergewichtigen (und teils veralteten) Technologiestack implementieren musste und dennoch eine Java-EE-Zertifizierung bekommen konnte. Das Java EE Web Profile wurde geboren. Server, die den gesamten Stack implementierten, sollten weiterhin eine Zertifizierung für das Full Profile bekommen, und Server, die nur einen definierten Teil implementierten, bekamen eine Zertifizierung für das Web Profile. In diesem konnten z. B. Remote EJBs bewusst weggelassen werden.

Zudem wurde mit Java EE 6 das Pruning eingeführt, auf das ich später noch eingehen werde.

Zertifizierung gerät ins Stocken

Allerdings hatte der neue Standard eine weitere Folge, die zunächst nicht zu erwarten war: Es gab de facto keinen Server, der den Standard implementierte. Natürlich gab es die Referenzimplementierung, den Glassfish. Der war allerdings in den ersten Versionen so voller Fehler, dass er zwar den Beweis antreten konnte, dass Java EE 6 grundsätzlich funktionierte, jedoch keine echte Alternative für den Produktiveinsatz war.

Java EE 6 wurde im Dezember 2009 finalisiert. Alle großen Hersteller benötigten tatsächlich fast zwei Jahre, um ihre Server für Java EE 6 Full Profile zertifizieren zu lassen. IBM WebSphere erlangte die Zertifizierung im Sommer 2011, der JBoss Application Server folgte Anfang 2012 und von Oracle WebLogic gab es sogar erst im Sommer 2013 eine Version, die für Full Profile zertifiziert war.

Diese Lücke aus einer sehr guten Spezifikation und den fehlenden Implementierungen eröffnete eine Chance für neue Server am Markt. Schließlich war es wie gesagt seit Java EE 6 möglich, einen kompatiblen Server zu bauen, ohne den gesamten Stack zu implementieren.

Und tatsächlich erschienen in der Folge mehrere neue Server, die sich zertifizieren ließen, dabei aber lediglich das Web Profile implementierten. Dazu zählte Resign Candy, aber z. B. auch der heute immer noch recht bekannte und aktiv weiterentwickelte Apache TomEE. Auch JBoss brachte lange vor der Zertifizierung im Full Profile einen Server auf den Markt, der Java EE 6 Web Profile certified war.

Aufnehmen neuer Technologien

Java EE 6 war eine starke Spezifikation, die allerdings einiger Kraft bedurfte, um von den Anbietern realisiert zu werden. Dennoch bedeutete Java EE 6 eine Wende in der Qualität und vor allem in der Innovationskraft der Enterprise-Java-Spezifikationen. Alle sprechen heute von CDI, wenn es um ein Komponentenmodell in Java EE geht. EJBs sind nur noch in Bestandssoftware ein Thema.

In der Folge nahm Java EE wieder Fahrt auf und war mit seinen neuen Spezifikationen immer (relativ) nah am Zeitgeschehen. Neue Trends, die sich vor allem im Web auftaten, wurden von da an auch zeitnah in eine Java-EE-Spezifikation übernommen und konnten so standardisiert in Java-EE-Applikationen verwendet werden.

Während es bei den Themen JSON Processing (seit Java EE 7) und JSON Binding (erst seit Java EE 8) spät anmutet, sind mittlerweile zumindest alle gängigen Webstandards auch in Java-Enterprise-Standards überführt. Darunter befinden sich WebSockets (ein eigener EE-Standard seit Java EE 7), Server-sent Events (ein Teil von JAX-RS 2.1 in Java EE 8) und HTTP/2 (in Servlet 4.0 mit Java EE 8). Zusätzlich wurden in Java EE 7 Themen wie Asynchronität und Batch-Processing standardisiert.

Neue Architekturen und Deployment-Szenarien

Ursprünglich wurde der Application Server konzipiert, um als Deployment-Infrastruktur für Java-EE-(damals noch J2EE-)Anwendungen zu dienen. Die Idee war also: Der Betrieb stellt einen Application Server zur Verfügung, auf den dann alle Anwendungen deployt werden.

Dieses Vorgehen beinhaltet mehrere Probleme. Zum einen ist je Applikation eine individuelle Konfiguration des Servers erforderlich. Es müssen verschiedene Parameter angepasst und DataSources angelegt werden usw. Leider sieht es keiner der Server vor, diese Anwendungskonfigurationen zu isolieren. De facto wird dabei immer der gesamte Server konfiguriert. Eine DataSource, die ich für eine Anwendung anlege, ist für alle Anwendungen auf dem Server verfügbar, was vermutlich nicht gewünscht ist.

Ein ähnlich gelagertes Problem tritt beim Thema Clustering auf. Wenn ich der Meinung bin, dass ich für meine Anwendung aus Gründen der Performance oder Ausfallsicherheit einen Cluster benötige, kann ich immer nur alle Anwendungen des Ser...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang