Webentwicklung im Licht von Java EE Profiles und "EJB Lite"
Bisweilen nehmen Java-Entwickler alles, was über das eingesetzte Webframework hinaus geht, als zusätzlichen Ballast der Enterprise-Java-Plattform wahr. heise Developer zeigt, wie das neue Java EE 6 den Missstand beziehungsweise das Missverständnis (beinahe) korrigiert.
- Jens Schumann
- Lars Röwekamp
Zentrale Bausteine der Java Enterprise Edition (Java EE) spielen in zahlreichen Java-Webanwendungen bewusst oder unbewusst keine Rolle. Bisweilen nehmen Entwickler sogar alles, was über das eingesetzte Java-Webframework hinaus geht, als zusätzlichen Ballast der Plattform wahr. Wie das neue Java EE 6 den Missstand beziehungsweise das Missverständnis (beinahe) korrigiert, zeigt Teil drei dieser Artikelserie.
Der Irrglaube, ein Java-Web-Container wie Tomcat hätte nichts mit Java EE zu tun, ist in der Java-Community stark verbreitet. Gern übersehen Entwickler, dass Tomcat ohne die Servlet API, die Java ServerPages (JSP) oder das Deployment-Format Web Application Archive (WAR) – alles zentrale "Java EE"-Bestandteile – eine ziemlich düstere Veranstaltung wäre. Sicherlich kommen viele Java-Webanwendungen ohne die Komponententechnik Enterprise JavaBeans (EJB), asynchrone Verarbeitung mit Java Messaging Service (JMS) oder Java-Webservices aus. Dennoch ist bei objektiver Betrachtung zu attestieren, dass Java-Webentwicklung ohne den "Java EE"-Standard und die zugehörige Plattform nahezu unmöglich ist.
Quo vadis Java EE 6?
- Über den Stand der Dinge im "Java EE 6"-Umfeld
- Convention over Code
- Webentwicklung im Licht von Java EE Profiles und "EJB Lite"
- Java Web Services: JAX WS und REST API
- App Server Extensibility: Server-Erweiterungen leicht gemacht
- Java EE Blueprints revisited: Die passende Architektur für die neuen APIs
Zugegebenermaßen ist der objektive Blick nicht einfach. Denn zum Leidwesen vieler verbergen sich hinter der Abkürzung Java EE unzählige Techniken, die auf tausenden Seiten Spezifikation ihre Komplexität manifestieren. Es ist nicht verwunderlich, dass viele Java-(Web-)Programmierer serverseitige Entwicklung zunächst aus der Brille des verwendeten Web-Frameworks und des Tomcat verstehen, ohne jemals den Zugang zur gesamten Plattform gefunden zu haben.
In der Vergangenheit hagelte es deshalb von vielen Seiten Kritik, allen voran aus dem Umfeld der Spring-Schöpfer Rod Johnson und Jürgen Höller. Ihr Tenor – wozu unnötig komplexe Komponententechniken, wenn Teilaspekte der Plattform völlig ausreichen – fiel auf fruchtbaren Boden, wie man unschwer am Erfolg des Spring-Frameworks erkennen kann. Die positiven Reaktionen der gleichen Kritiker zu Java EE 6 und insbesondere zu einem Konzept namens Java EE Profiles verdeutlicht, dass sich die Version 6 einem ihrer zentralen Kritikpunkte angenommen hat: Der Verringerung der Einstiegskomplexität – insbesondere im Bereich der Webentwicklung.
Gestatten, mein Name ist Web Profile
Was bringen nun aber die Java EE Profiles, wenn sie die Kritiker so versöhnlich stimmen? Und wie sieht Webentwicklung im Zeitalter der Java EE 6 aus? Wie schon im ersten Artikel der Reihe angerissen, ist die Idee hinter den Profiles ziemlich einfach: Standen früher ausschließlich vollständige Application Server im Fokus der "Java EE"-Spezifikation, mussten die Experten der Spezifikationskommission anerkennen, dass in vielen serverseitigen Projekten nur Subsets der Spezifikation zum Einsatz kommen. Vor allem bei Web-getriebenen Anwendungen auf Tomcat-Basis finden sich neben den Core-Techniken Java Servlet und JavaServer Pages (JSP) beziehungsweise JavaServer Faces (JSF) selten mehr als die Java Transaction API (JTA) und seit Java EE 5 die Java Persistence API (JPA). Weitere Techniken wurden und werden bewusst oder unbewusst ignoriert. In der Konsequenz blieb es bisher den Anbietern von Web-Containern und -frameworks überlassen, welche Untermenge an "Java EE"-Features einem klassischen Java-Webprojekt zur Verfügung steht.
Abhilfe schafft das Java EE 6 Web Profile, das parallel zur "Java EE 6"-Spezifikation erschienen ist und die Plattform auf ein verträgliches Maß zusammenschrumpft: Ausgehend von dem im ersten Artikel der Serie vorgestellten Basisprofil (Lebenszyklus-Annotationen, Java Transaction API, Java Naming and Directory Interfaces) fasst das Webprofil alle Techniken zusammen, die in einer typischen Webanwendung zum Einsatz kommen. Wie in unten stehender Tabelle zu sehen, haben vor allem die oben genannten üblichen Verdächtigen Servlet API, JSP und JSF sowie die Techniken Expression Language (EL) und Standard Tag Library for Java Server Pages (JSTL) Einzug gehalten. Interessanterweise finden sich dort auch JPA 2.0 und EJB 3.1, Letzteres mit dem Zusatz "lite". Dazu gleich mehr.
| Spezifikation | Version |
| Servlet API | 3.0 |
| JavaServer Pages (JSP) | 2.2 |
| Expression Language (EL) | 1.2 |
| Debugging Support for Other Languages | 1.0 |
| Standard Tag Library for JavaServer Pages (JSTL) | 1.2 |
| Common Annotations for the Java Platform | 1.1 |
| JavaServer Faces (JSF) | 2.0 |
| Java Transaction API | 1.1 |
| Java Persistence API | 2.0 |
| Bean Validation | 1.0 |
| Managed Beans | 1.0 |
| Contexts and Dependency Injection for the Java EE Platform | 1.0 |
| Dependency Injection for Java | 1.1 |
| Enterprise JavaBeans (EJB) Lite | 3.1 |
| Interceptors | 1.1 |
