Das Problem mit Java EE oder: Die reale Realität vs. die Konfernenz-Realität Wenn man Konferenzen besucht und sich Vorträge anhört, bekommt man leicht den Eindruck, dass Java EE eine ernsthafte Alternative zu Spring ist und vor allem - es ist ja im Application Server enthalten, warum also Spring nutzen? Dabei ist die Rede natürlich von Java EE 5 und dem noch nicht fertig spezifizierte Java EE 6. Diese Standards haben neue Programmiermodelle eingeführt - über die Probleme von Java EE 1.4 und EJB 2.x braucht man wohl nichts zu sagen.

Interessanterweise hat diese Konferenz-Realität aber nichts mit der realen Realität zu tun, die da draußen in den Projekten wirklich gelebt wird. Zunächst einmal sagen zahlreiche Statistiken, dass Tomcat die führende Java-Plattform ist. So zeigt der JAXenter Quick Vote zum Beispiel, dass 58% aller Java-Entwickler Tomcat als Basis aller Web-Projekte verwenden, 24% gelegentlich je nach technischer Entscheidung und 12% gelegentlich je nach politischer Entscheidung - zusammen 94%. Das 2008 Evans Data Survey geht von 68% Markt-Anteil von Tomcat aus. Das TheServerSide Survey kommt zu ähnlichen Ergebnisse. Ingesamt arbeitet die Mehrheit der Java-Anwendung also mit Tomcat und hat daher keine vollständige Java-EE-Umgebung. Sie können oder wollen also nicht die vollständigen Java-EE-APIs nutzen. Es kann auf keinen Fall die Rede davon sein, dass man die Java-EE-APIs "eh schon im Application Server hat". Das Gegenteil ist der Fall - der Java-EE-Application-Server ist die Ausnahme, nicht die Regel. Und selbst wenn einer genutzt wird, ist es oft eine alte Version, die noch kein Java EE 5 unterstützt. Der Betrieb ist eben eher konservativ. Java EE 6 ist noch nicht einmal fertig standardisiert - es macht also wenig Sinn, das weiter zu betrachten.

Diese Wahrnehmung spiegelt sich auch in konkret in letzter Zeit erlebten Projekt-Szenarien wieder:

• So das Projekt, das zwar auf einem vollständigen Java-EE-Server läuft, aber auf JDK 1.4. Java EE würde hier EJB 2.x anbieten, was niemand wirklich will. Die einzige sinnvolle Alternative ist also Spring.


• Oder das Projekt, dass auf einer Standard-Software aufbaut. Die läuft auf einem gebundelten Tomcat - der eben kein vollständiges Java EE anbietet. Selbst wenn man wollte, kann man kein vollständiges Java EE nutzen.


• Oder das Projekt, das von EJB 3 wegmigriert, um auf Tomcat umzusteigen - weil man Tomcat als gegenüber Java EE als Ablaufumgebung vorzieht.

Die Realität im Java-Bereich ist, dass eine vollständige Java-EE-Unterstützung - im Gegensatz zu dem Stand vor einigen Jahren - bei Enterprise-Anwendungen keine große Rolle mehr spielt. Und ich denke, dass sich dieser Trends aufgrund der Dominanz von Tomcat und dem OSGi-Aufschwung noch weiter verstärken wird.

Labels: Java EE, Spring, Tomcat

  ¶ 11:30 0 comments

  Spring Day WJAX Ich habe auch dieses Jahr wieder das Vergnügen, den Spring Day auf der WJAX zu organisieren.

Den Anfang werde ich dieses Jahr bestreiten mit einem Überblick über Spring 3.0, das dann auch zur Verfügung stehen sollte. Mein Kollege Agim Emruli spricht dann über Rich Internet Applikationen mit Spring. Gerade in diesem Bereich stehen mit Spring Faces und der BlazeDS-Integration einige interessante neue Ansätze bereit. Zusammen mit Papick Taboada präsentiert Agim dann den dm Server insbesondere für den Einsatz für Web-Anwendungen. Thomas Biskup von Quinscape spricht im Anschluß über Möglichkeiten, wie man Spring gewinnbringend einführen kann. Ein wie ich finde interessantes Thema, weil man bei der Einführung naturgemäß noch nicht so viel über Spring weiß, aber eigentlich erst mit viel Erfahrung erkennt, wo Spring am besten einzusetzen ist.

Labels: Spring Day, WJAX

  ¶ 12:18 0 comments

  Spring EInführungsartikel Unter http://robbbert.hostrator.com/ steht ein recht umfangreicher Artikel mit einer Einführung zu Spring bereit.

Labels: Spring

  ¶ 12:14 0 comments