Ein Profil bringt mehr Flexibilität

Java EE 6 Web Profile

Lars Röwekamp und Matthias Weßendorf

Dank eines deutlich vereinfachten Entwicklungsmodells – eingeführt in der Version 5 – hat Java EE den Ruf des schwergewichtigen Monstrums abgelegt und erfreut sich in der Enterprise-Java-Community endlich wieder wachsender Beliebtheit. Ein Problem bleibt aber trotz „Ease of Development“-Ansatz weiterhin bestehen: Die Laufzeitkomplexität. An dieser Stelle setzt die Java-EE-6-Spezifikation mit dem neuen Konzept der Profiles an. Ein erstes namens „Web Profile“ existiert bereits.

Java EE 6 – Das Sonderheft

Dieser Artikel erschien im Sonderheft „Java EE 6“. Wer Lust auf mehr bekommen hat, kann das Heft direkt über die Webseite bestellen.

Die standardisierte Enterprise-Java-Welt ist dank Java EE 5 und einer damit einhergehenden, neu gewonnenen „Leichtigkeit“ endlich wieder zurück auf der Erfolgsspur. Ausschlaggebend hierfür sind vor allem das deutlich vereinfachte Entwicklungsmodell sowie die Rückbesinnung auf alte Java-Tugenden. Die fast durchgehende Verwendung von POJOs und Annotationen, statt technologisch bedingterVererbungshierarchien, prägen das Bild der meisten APIs. Die neue Philosophie erlaubt eine deutlich effizientere Entwicklung, als es noch zu Zeiten der Vorgängerversion J2EE 1.4 der Fall war. Hinzu kommt die Möglichkeit des Testens außerhalb des Containers, ein bis dato schmerzlich vermisstes Feature. Doch wie sieht es zur Laufzeit aus? Ein großer Kritikpunkt der Anti-J2EE-Fraktion war stets der mächtige Application Server mit all seinen zu unterstützenden APIs – und dies zurecht. Selbst die kleinste Webanwendung musste in einem „full-fledged“ Application Server deployt werden, wollte sie auf einige der grundlegenden Enterprise-Java-Features wie Security oder Transaktionskontrolle zurückgreifen. Dabei ist es nicht wirklich einzusehen, weswegen die Runtime für eine ausschließlich lokal laufende Webanwendung Dinge wie Remote Communication oder gar – aus Gründen der Abwärtskompatibilität – EJB 2.x unterstützen muss. Dieses Manko hat auch die Java EE Expert Group erkannt und im regen Austausch mit der Enterprise-Java-Community versucht, eine adäquate Lösung zu finden. Das Resultat der Bemühungen ist das in Java EE 6 eingeführte Prinzip der Java EE Profiles (Profiles). Sie sollen zukünftig eine deutlich höhere Flexibilität der Plattform bieten, wie auf der offiziellen JCP Web Page der Java-EE-6-Spezifikation nachzulesen ist: „To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. “

Das Prinzip „Profile“

Was also ist ein Profile? Etwas abstrakt ausgedrückt, ist ein Profile nichts anderes als eine durch den JCP definierte und somit standardisierte Konfiguration der Java-EE-Plattform, die „optimal“ auf eine bestimmte Art von Anwendungen zugeschnitten ist. Ein Profile kann dabei ein Subset der zugehörigen Java-EE-Version beinhalten aber auch zusätzliche Anforderungen bzw. Technologien definieren. Denkbar wäre zum Beispiel ein Web Service Profile, dass bewusst auf alle Visualisieurungstechnologien wie JSF, JSTL und JSP verzichtet. Ebenfalls denkbar wäre aber auch ein spezielles Java EE Portlet Profile, dass zusätzlich zu den bereits in Java EE enthaltenen APIs das Java Portlet API (JSR 286) voraussetzt.

Unabhängig von den jeweils speziellen APIs, die ein Profile mit sich bringt und durch die es sich von anderen Profiles abgrenzt, haben alle ein sehr schmales Basisset an APIs und Features gemein (a. k. a. Base Profile):

  • Resource and Component Lifecycle Annotations aus dem JSR 250 (@Resource, @Resources, @PostConstruct, @PreDestroy)
  • JNDI „java: “ Naming Context
  • Java Transaction API (JTA)

Neben diesen zwingenden Features gibt es noch eine kleine Anzahl optionaler Bestandteile des Base Profiles:

  • RMI/IIOP Interoperability Requirements
  • Unterstützung von java:comp/ORB

Aktuell gibt es eigentlich nur ein bzw. zwei Java EE Profiles. Zunächst ist da die als „Full Java EE Product Requirements“ bekannte Vollversion der Spezifikation, die gelegentlich auch als Java EE Full-Stack Profile bezeichnet wird. Darüber hinaus existiert als eigenständiger Bestandteil von Java EE 6 die „Java Platform, Enterprise Edition 6 Web Profile Specification“ , im Folgenden Web Profile genannt.

Weniger ist mehr

Das Java EE Web Profile ist fester Bestandteil der Java-EE-6-Spezifikation und somit kein eigener JSR. Interessant dabei ist, dass die Spezifikation – lässt man einmal ein paar erläuternde Seiten außer Acht – lediglich zwei Seiten lang ist und eigentlich nur eine Auflistung von zugehörigen Komponenten, also API-Spezifikationen umfasst. Hinzu kommen noch ein paar Seiten mit den Anmerkungen, dass ein Deployment von Web Application Modules unterstützt werden muss und dass es keine optionalen Bestandteile innerhalb des Profiles gibt, fertig ist die Spezifikation. Die Kürze macht deutlich, was das Web Profile eigentlich ist: ein auf moderne Webanwendungen optimiertes Subset des Java EE 6 Full-Stacks; nicht mehr und nicht weniger (Abb. 1).

Abb. 1: Java EE Full-Stack vs. Web Profile

Und dafür all die Aufregung? Da muss doch noch etwas mehr dran sein. Was ist also der Clou an dem neuen Web Profile? Natürlich ist das zugehörige API-Paket im Verglich zur Java-EE-Vollversion deutlich kleiner, wie Abbildung 1 zeigt. Der eigentliche Benefit des ersten echten Java EE Profiles liegt aber zwischen den Zeilen versteckt. Zum einen fällt auf, dass der neue Java EE Web Stack lediglich ein Derivat von EJB 3.1 namens EJB 3.1 Lite unterstützt. Zum anderen profitiert das Web Profile von einer „gelockerten“ Packaging-Struktur für Enterprise Java Beans innerhalb von Java EE 6, die es ermöglicht, EJBs direkt in einem Web Archive (.war) zu deployen. Nutzt man beides in Kombination, eröffnen sich plötzlich völlig neue Möglichkeiten: Java-EE-Anwendungen inkl. EJBs in einem „Lightway Runtime Environment“. Aber immer der Reihe nach …

Geschrieben von
Lars Röwekamp und Matthias Weßendorf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.