Gavin King [1], der Vater von Hibernate, empfahl Entwicklern ein Upgrade auf die Java EE 6-Plattform und wies darauf hin, dass die derzeitige Zurückhaltung gegenüber einem Upgrade eigentlich unbegründet sei.
Nach der Veröffentlichung von Java EE 6 sah ich großen Widerstand gegen ein Upgrade auf die neue Plattform. Die meisten dieser Einwände werden von Benutzern von Tomcat/Jetty und einigen Open-Source-Frameworks (wie Hibernate und Spring) geäußert.
Natürlich bietet die Wahl einer nicht standardmäßigen Open-Source-Technologie viele Vorteile. Darüber hinaus können Sie in EE 6 die Open-Source-Frameworks verwenden, die Sie interessieren. Servlet 3 und CDI können Frameworks von Drittanbietern nahtlos integrieren. Es gibt also keinen Grund, EE 6 nicht zu verwenden. Trotzdem sah ich jemanden sagen:
Ein Upgrade auf EE Application Server ist schwierig
Dies scheint eher ein politisches Problem für die jeweilige Organisation als ein tatsächliches technisches Problem zu sein. Natürlich ist das Upgrade eines Servers wie GlassFish oder JBoss eine sehr triviale Aufgabe. (Das Aktualisieren von Frameworks von Drittanbietern ist noch mühsamer.) Einige Organisationen haben einen sehr aufwändigen Prozess für das Upgrade von Servern, aber nicht so sehr für das Upgrade der auf den Servern ausgeführten Frameworks. Daher ist es für das Entwicklungsteam einfacher, Frameworks von Drittanbietern zu aktualisieren.
Ich denke, dass die Entwicklung eines überzeugenderen und besseren Prozesses das Wichtigste ist, anstatt Java EE aufzugeben. Mit der Ausführung Ihrer Anwendung auf einer alten, veralteten Serverplattform sind viele Risiken verbunden, und der Prozess sollte solche Praktiken nicht fördern.
Aus praktischer Sicht plant jedoch fast jeder, in naher Zukunft ein Upgrade auf Servlet 3 durchzuführen. Unabhängig davon, ob Sie Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle oder WebSphere verwenden, bedeutet dies ein Server-Upgrade. Dies ist eine großartige Gelegenheit für ein Upgrade auf EE 6 Web Profile, eine goldene Zeit.
Der EE-Anwendungsserver ist zu groß
Der Einwand besteht darin, dass EE Server viele Funktionen enthält, die (derzeit) nicht verfügbar sind. In den Argumenten der Gegner geht es in der Regel um die Diskussion der Größe des JAR-Pakets und des von der Servlet-Engine + dem Drittanbieter-Framework und dem EE-Anwendungsserver belegten Speicherplatzes. Tatsächlich ist dieses Argument problematisch:
Die besprochene Festplattennutzung und der Speicherplatz sind, gemessen in $, eigentlich trivial, und das Anwendungs-War-Paket ist viel wichtiger als die Größe des Server-Installationspakets. Der Server enthält tatsächlich viele Funktionen, um die Größe des War zu minimieren.
Darüber hinaus denke ich, dass das Überzeugendste ist, dass das Java EE 6 Web Profile überhaupt nicht riesig ist. Sobald zertifizierte Web-Profile-Server auf dem Markt sind, können wir ein Gleichgewicht zwischen großen EE-Anwendungsservern und kleinen Servlet-Containern finden.
Schlechtes J2EE und EJB2!
Mit dem Standardisierungsprozess von JCP besteht dieses Problem tatsächlich nicht mehr:
1. Es ist 8 Jahre her, seit EJB2 erschienen ist! Ist es immer noch Ihre beste Wahl?
2. Durch die kontinuierliche Standardisierung von JCP sind gute Spezifikationen zusammengeführt worden und einige davon können mit großer Sicherheit verwendet werden. JCP ist jedoch bei der Standardisierung nicht zu 100 % erfolgreich.
3. Jeder, der an der EE 6-Plattform arbeitet, hasst EJB2 und J2EE. Aus diesem Grund treten dem JCP ständig Menschen bei, um bei der Lösung dieser Probleme zu helfen. Zum Beispiel der Gründer von Hibernate und der Autor dieses Artikels. Wollen Sie ihm wirklich eine Lektion über EJB2 erteilen? :-)
4. Fast alle Leute, die an Entity Beans arbeiten, sind jetzt im Ruhestand!
Tatsächlich reicht Java EE 6 Web Profile aus. Wenn Sie Java EE 6 nicht selbst ausprobieren, werden Sie die Vorteile von EE6 für die Entwicklung nicht wirklich spüren.
Die Portabilität von Anwendungsservern ist ein Rätsel!
Wirklich? Wir sehen viele Leute, die ihre Anwendungen aufteilen und sie auf verschiedenen Anwendungsservern bereitstellen? Oh, ich habe gesehen, dass das eine 100 % fehlerfreie Anwendungsportierung ohne Änderung bedeutet, ein platonisches Ideal der Portabilität. Ich verstehe die Schwäche für absolute Wahrheit und platonische Ideale, aber schauen wir uns zunächst Beispiele an.
Hier ist eine sehr typische Ansicht eines Portabilitätsproblems:
9 % des Codes und 85 % der externen Metadaten sind auf verschiedenen Serverplattformen vollständig kompatibel und die restlichen 1 % und 15 % können entsprechend aufgeteilt werden
0 % Code, 80 % externe Metadaten, gebunden an nicht standardmäßige Containerarchitektur eines einzelnen Anbieters
Als ich diese Punkte aufteilte, wollte ich plötzlich das Thema dieses Abschnitts von „Anwendungsserver-Portabilität ist zu mysteriös“ zu „Ich kümmere mich überhaupt nicht um Container-Portabilität“ ändern. Die Idee einer Themenänderung bestätigt, dass das Problem der Serverportabilität real ist und für viele Organisationen von großem Nutzen sein wird.
Ich wollte schon immer echte Rezensionen von EE 6 von technischen Betreuern sehen, die nicht an EE 6 beteiligt sind. Einige der oben genannten Argumente stammen nicht aus der Praxis, sodass es schwierig ist, Diskussionen zu tatsächlichen technischen Fragen der Anwendungsentwicklung auf der EE-Plattform anzustoßen. Die jüngste Runde der JCP-Spezifikationen scheint das Anti-EE-Lager (vorübergehend?) verlassen zu haben, es fehlt jedoch an sachlicher Unterstützung für den Erfolg.
Anmerkung des Herausgebers:
[1] Gavin King: Gründer von Hibernate, Mitglied des EJB3-Expertenkomitees, eines der Kernmitglieder von JBoss, Leiter des Seam-Frameworks, Leiter der JSR-299 (CDI)-Spezifikation und Autor des Buches „Hibernate in Action“ .
Quelle: Sie sollten auf Java EE 6 aktualisieren