JEE 6 ist eine ausgereifte, jedoch sehr komplexe Technologie. Vor allem der Betrieb eines Applikationsservers bringt eine erhebliche Komplexität mit sich. Was bedeutet der Einsatz eines JEE 6-Applikationsservers, vor allem im Zusammspiel von Architekten und Administratoren?
In einem früheren Beitrag habe ich argumentiert, dass ein Applikationsserver wie z.B. Glassfish zwar hilft, ein Projekt schnell zu starten. Langfristig jedoch erschweren JEE-Applikationsserver die Wartung und Weiterentwicklung eines Systems, vor allem, wenn sie aktualisiert werden – und mit ihnen die ganze technologische Basis eines Systems.
Meine Argumente möchte ich nun etwas vertiefen und einen weiteren Blickwinkel hinzufügen.
Zuerst wieder kurz zu meinem Hintergrund: Ich arbeite seit vielen Jahren sehr gerne mit dem Spring-Framework und betreibe die entstandenen Anwendungen am liebsten in Web-Containern wie Tomcat. Zuletzt habe ich jedoch ein komplexes Projekt auf Basis einer JEE 6-Architektur aufgesetzt und dafür die aktuellsten Standards verwendet, also EJB 3.1 mit JPA 2 und JMS. Die daraus entstandenen Systeme laufen teils seit über einem Jahr stabil im Produktivbetrieb.
Unsere Erfahrung im Projekt war: Die in JEE 6 enthaltenen Technologien sind inzwischen ausgereift. Wir konnten ein hohes Arbeitstempo konstant halten und hatten nur wenige Probleme mit der Verwendung der JEE-APIs (von Bugs in EclipseLink einmal abgesehen).
Die Sichtweise des Architekten
Trotz dieser guten Erfahrungen mit JEE 6 würde ich mich bei einem neuen Projekt gegen diesen Technologie-Stack entscheiden.
Dies liegt weniger an den JEE-APIs selbst. Auch in einem Spring-Projekt verwende ich JPA, Bean-Validatoren, Dependency Injection per @Inject und schätze JSF2 als Web-Framework. Viele der von JEE definierten Schnittstellen und APIs sind sehr gut zu verwenden, und es erscheint mir z.B. wenig sinnvoll, noch gegen die Hibernate-API direkt zu programmieren. Hier setze ich lieber auf die Standards.
Bauchschmerzen bereitet mir hingegen die Laufzeitumgebung, also der Applikationsserver, in dem die Anwendung läuft.
In einem JEE-Projekt hat der Architekt keine Entscheidungsfreiheit, welche Implementierung der einzelnen Standards er verwenden kann, er erhält ein vorgegebenes Gesamtpaket. Manche der integrierten Komponenten weisen eine hohe Qualität auf, während andere eher die Stabilität beeinträchtigen. Zudem ist eine Aktualisierung einzelner Komponenten kaum möglich – Updates betreffen immer den vollständigen Server, also alle Basis-Technologien auf einmal.
In der Praxis heißt das: Wenn eine Komponente wie z.B. das Persistenz-Framework einen Bug hat, dann reicht es nicht aus zu warten, bis der Bug in der Komponente selbst behoben ist. Man muss vielmehr warten, bis ein neues Release des Applikationsservers erscheint, in dem die fehlerbereinigte Version der Komponente enthalten ist. Leider bringt ein solches Release meistens weitere Aktualisierungen mit sich, die neue Probleme in ganz anderen Bereichen verursachen können. Eventuell gibt es sogar nur die Alternative, einen ganz großenVersionssprung mitzumachen (wie er z.B. von JEE 6 zu JEE 7 bald ansteht).
Was ist die Alternative? Der Gegenentwurf zur JEE-Anwendung ist ein System, in dem der Architekt genau vorgibt, welche technischen Komponenten in welchen Versionen verwendet werden. Anstelle eines schwergewichtigen JEE-Applikationsservers kommt nur ein leichtgewichtiger Web-Container zum Einsatz. Als Bindeglied zwischen den Komponenten bietet das Spring-Framework viele Werkzeuge, um die Verknüpfung der Komponenten zu beherrschen. Letztlich entsteht dabei ebenso ein komplexes System, jedoch eines, dessen Komplexität der Architekt unter seiner Kontrolle hat.
Zwar ist nun der Architekt dafür verantwortlich, dass die verwendeten Basis-Technologien miteinander harmonieren. Dafür lassen sich die verwendeten Komponenten und Bibliotheken weitgehend unabhängig voneinander aktualisieren. Entsprechend ist es einfacher, Probleme beim Update der Technologien zu isolieren und identifizieren.
Die Sichtweise des Administrators
Interessanterweise dreht sich die Argumentation um, wenn man sie aus der Sicht eines Administrators betrachtet, der für den Betrieb einer Anwendung zuständig ist. Ist dem Architekten die freie Wahl der System-Architektur wichtig, steigt für einen Administrator durch diese Freiheit das Risiko für den sicheren Betrieb der Anwendung.
Wenn jede Aktualisierung einer Anwendung nämlich neue oder geänderte Basis-Technologien einführen kann, dann kann sich das Verhalten der Anwendung jederzeit unerwartet ändern. Jeder Bugfix in einer Komponente kann neue Speicherlecks oder Synchronisierungsfehler unter Last mit sich bringen. Und Werkzeuge zum Messen und Eingreifen, die eben noch funktioniert haben, sind plötzlich untauglich.
Der fest definierte Funktionsumfang eines Applikationsservers bietet einem Administrator die Sicherheit, dass Änderungen im Verhalten einer Anwendung in erster Linie von den Entwicklern verursacht wurden. Je mehr Systemkomponenten sich gleichzeitig ändern können, desto schwieriger ist die Lokalisierung neuer Fehler.
Je mehr Anwendungen ein Administrator gleichzeitig betreuen muss, desto wichtiger ist eine gemeinsame Basis für alle Anwendungen. Wenn jedes Entwicklerteam unterschiedliche Basis-Technologien nutzt bzw. unterschiedliche Versionen der selben Komponenten, ist es kaum möglich, mehrere Anwendungen einheitlich zu verwalten.
Applikationsserver unterstützen standardisierte Schnittstellen zur Überwachung von Anwendungen und bieten grafische Oberflächen, um das System zu verstehen und Systemparameter zu ändern. Ohne einen Applikationsserver müssen solche Mittel erst aufwändig vom Entwicklerteam erschaffen werden.
Gibt es einen Königsweg?
Viele Unternehmen lassen den Architekten neuer Systeme nur wenig Entscheidungsfreiheit. Die Infrastruktur für den Betrieb wird meistens früh entschieden und die Frage nach dem Applikationsserver ist üblicherweise Welcher? und nicht Geht es ohne?
Meine persönliche Präferenz liegt trotzdem in der Kombination eines schlanken Web-Containers mit einer dicken Anwendung. Nur so kann ich als Architekt meiner Verantwortung gerecht werden, eine Anwendung zu bauen, die auch langfristig, d.h. über den Produktzyklus eines Applikationsservers hinweg, weiter entwickelt werden kann.
Um den Konflikt zwischen Architekt und Administrator zu entschärfen, helfen folgende Tipps:
- Die Staging-Umgebung zum Testen entspricht möglichst genau der produktiven Umgebung. Probleme im Zusammenspiel mit der Infrastruktur müssen spätestens hier auffallen.
- Eine Produktivsetzung enthält entweder fachliche Änderungen oder Aktualisierungen der technischen Basis. Nach Änderungen an der technischen Basis läuft das Systeme einige Tage unverändert, um sicherzustellen, dass die Basis keine neuen Probleme mit sich bringt.
- Vor größeren Änderungen an der technischen Basis wird der Administrator frühzeitig involviert, damit er seine Wünsche (z.B. neue Monitoring-Schnittstellen oder Kommandozeilen-Tools) einbringen kann.
Schließlich hilft es sehr, wenn auch der Architekt und einige Entwickler regelmäßig für den Betrieb verantwortlich sind. Nur wenn man selbst einmal bei einem Ausfall geschwitzt hat, wird man sich anschließend entschieden für ein höheres Budget für Monitoring und ähnliche Anforderungen einsetzen…