Die Java Enterprise Edition (Java EE) hat sich als leistungsfähige Entwicklungsplattform etabliert. Allerdings setzt sie fast niemand im Rohzustand ein, sondern nutzt darauf basierende Frameworks, welche die Java EE ergänzen und deren Komplexität verstecken. Da es eine enorme Anzahl an solchen Frameworks gibt, ist deren Auswahl und Einsatz nicht trivial. Das Open-Source- Projekt EL4J hilft dabei.
Es gibt etliche Motive für den Einsatz von Java-EE-Frameworks. Die Abstraktionsschicht, welche die Frameworks zur Verfügung stellen, hilft dabei, Probleme und Unzulänglichkeiten der darunter-liegenden Plattform zu korrigieren. Die Java EE bietet beispielsweise wenig Unterstützung für langdauernde Verarbeitungen (Batch Jobs), Scheduling sowie für Notification (Benachrichtigung), transaktionelles Journaling oder Background-Daemons. Reine IT-Anwenderfirmen können sich normalerweise auf einen J2EE-Hersteller beschränken, Software-Service-Unternehmen müssen jedoch oftmals alle Implementierungen ihrer Kunden unterstützen. Dabei helfen Frameworks, Applikationen auf verschiedenen Java-EE-Implementierungen laufen zu lassen, ohne sie jedes Mal speziell anzupassen. Es werden also Hersteller- und Spezifikationsabhängigkeiten reduziert. Die Standard-Enterprise-Komponenten (EJB Beans) benötigen einen EJB Container, welcher flexiblen Deployments, etwa für leichte Tests, im Wege steht. Frameworks können hier einen leichtgewichtigeren Ansatz bieten, wo normale Java-Klassen (Plain Old Java Objects, POJOs) zu Komponenten werden können. Dies führt zu schnelleren Entwicklungs-Roundtrips, einfacheren Tests und mehr Einsatzflexibilität.
Java-EE-Frameworks haben auch wesentliche Verbesserungen der Plattform bereits vorweggenommen: etwa der Persistenzmechanismus von EJB 3 (vom Hibernate Framework), die Dependency-Injection von EJB 3 (vom Spring Framework), JDK 1.5 Annotationen (von Commons Attributes oder Xdoclet) oder den leichten POJO-Ansatz in EJB 3 (von Spring).
Aber bei Hunderten von verfügbaren Frameworks in der Java-Welt: Wie soll man passende auswählen und sie zusammen integrieren? Hier bietet der Java-EE-Konkurrent .Net von Microsoft einen klaren Vorteil: Praktisch die gesamte Technologie stammt nur von Microsoft. Das offene und verbreitete Spring-Framework verbessert diesen Zustand für die Java EE zwar, da eine grosse Anzahl von populären Frameworks bereits integriert ist. Doch bei Spezialwünschen muss man wieder selbst Hand anlegen.
Dieses Manko soll EL4J (el4j.sf.net) ausräumen, das zwar auf Spring aufsetzt, aber selektiver bei der Auswahl der dazugehörenden Frameworks ist. Somit wird der Projektstart mit EL4J beschleunigt, da nicht erst lange nach passenden Komponenten gesucht und diese dann integriert werden müssen. Vollständige, skeletale Applikationen (beispielsweise für Web-Applikationen) und Applikations-Templates helfen weiter beim raschen Start mit einer neuen Applikation. Die Anwender sollen dadurch bereits 10 Minuten nach Beginn «einsatzfähig» sein und eine erprobte Struktur für die verschiedenen Schichten einer Applikation erhalten.
Ein Java-EE-Framework kann so die Struktur und die Technologien einer Applikation vorgeben und so eine bewährte Architektur vielen Applikationen zugänglich machen. Dies vereinfacht auch das technische Know-how-Management über Projektgrenzen. Wir setzen diese Vorgaben auch ein, um die Qualität von Offshore-Entwicklungen zu kontrollieren.
Neben dem rascheren Projektstart und der erprobten Struktur bietet EL4J weitere Features, welche aus anderen bewährten Frameworks und aus eigenen Erweiterungen stammen (Übersicht siehe Abbildung auf Seite 52).
Eine Besondersheit von EL4J ist die Möglichkeit, Applikationen in Module aufzuteilen. Jedes Modul kann Quellcode, Bibliotheken und transitive Abhängigkeiten auf andere Module und Default-Konfigurationen enthalten. Letztere sorgen dafür, dass Module bereits Out of the Box funktionieren, was eine typische Quelle von Komplexität versiegen lässt, nämlich aufwendige Konfiguration. Alternative Implementierungen derselben Funktionalität können in verschiedenen Modulen untergebracht werden, sodass die gewünschte Implementierung durch die Wahl des passenden Moduls aktiviert werden kann. Auch für Entwicklungen im Team kann jeder Entwickler an eigenen Modulen arbeiten und ist so besser von anderen isoliert. Module werden in Eclipse als Projekte abgebildet, der Entwickler arbeitet also mit den gewohnten Abstraktionen. Module können definieren, wie sie gestartet oder eingesetzt werden. Damit kann man einem Modul einfach mitteilen, dass es gestartet oder eingesetzt werden soll, ohne sich um die Details dafür kümmern zu müssen. Module sind auch für die Entwicklung von EL4J nützlich: Jedes Modul kümmert sich genau um eine Sache und man braucht nur die nötigen Module einzubinden.
J2EE-Frameworks als Java-EE-Erweiterung
EL4J verwendet EL4Ant, einen leichten Generator für Ant Build-Scripts. Damit werden typische Arbeiten wie das Kompilieren, das Ausführen der Unit Tests oder Überprüfungen von Coding Guide Lines für die Module automatisiert und den Modul-Abhängigkeiten gemäss ausgeführt.
Kommunikationen zwischen Prozessen können mit EL4J einfach mittels Methodenaufrufen auf unveränderten POJOs erfolgen. Somit ist es bei entsprechender Architektur ein leichtes, eine Applikation in einem oder mehreren Prozessen einzusetzen. Den bereits flexiblen Ansatz von Spring macht EL4J dabei noch einfacher, vor allem für das Deployment von POJOs in einem EJB-Container oder bei SOAP. Optional erlaubt EL4J auch, technischen Kontext bei Remote Procedure Calls implizit mitzuliefern.
Interceptors erlauben es, Code vor oder nach gewissen Methodenaufrufen auf POJOs einzuschieben. Interceptors werden heute oft unter dem Schlagwort AOP (Aspect Oriented Programming) angeboten. Mit Interceptors erreicht man elegante Lösungen für Probleme, welche sonst viel aufwendiger und fehleranfälliger wären. Nützlich ist das beispielsweise für rasche Performancemessungen, um Fehler immer gleich zu bemerken, oder für Sicherheitsabfragen für POJO-Methoden.
Für GUI-Applikationen bietet EL4J die eigens verbesserte Spring Rich Client Platform (RCP) an. Sie vereinfacht die Umsetzung der Best-Practices, indem sie die Applikationsstruktur vorgibt, indem es beispielsweise die Operationen hinter Menüs und Buttons vereinheitlicht. Swing-Applikationen sehen damit auch automatisch professioneller aus, weil das Look&Feel verbessert wird und unter anderem bei Benutzereingaben falsche Werte sofort validiert werden. Schliesslich beschleunigt sie auch die Entwicklung, da POJOs automatisch oder durch generische Suchanfragen in GUI-Widgets eingebunden werden.
Der Daemon Manager hilft sicherzustellen, dass essentielle Hintergrundkomponenten einer Applikation auch wirklich immer im Betrieb sind. Dies kann nützlich sein, wenn neue Files ohne Unterbruch aus einem Directory verarbeitet werden sollen oder wenn Anfragen kontinuierlich auf einem Netzwerk-Socket bearbeitet werden müssen. Der Daemon Manager erlaubt es, Threads zuverlässig zu überwachen und bei Fehlern angemessen zu reagieren. Eine Konsole hilft zusätzlich, den Daemon-Status zu überwachen. Der Daemon Manager definiert als Framework auch eine erprobte Architektur für solche Applikationen, was der Qualität zugute kommt.
Das Acegi-Sicherheitsframework kümmert sich primär um die Authentifizierung und die Autorisierung von Applikationen und geht dabei klar über den in der Java EE integrierten JAAS (Java Authentication and Authorization Service) hinaus. Damit ist beispielsweise ein globales Single-Sign-On möglich, oder Authorisierungschecks können auf normale POJOs angewendet werden. Auch Autorisierungsregeln lassen sich viel flexibler gestalten als mit JAAS. Zusätzlich funktioniert es auch ausserhalb eines Java-EE-Containers und stopft einige Sicherheitsprobleme beim Einsatz über mehrere Prozesse hinweg.
Obwohl EL4J erst seit eineinhalb Jahren existiert, wurde es bereits in 14 Kundenprojekten eingesetzt. Durch den Einsatz von State-of-the-Art-Komponenten und seiner Offenheit waren die Entwickler sehr motiviert, EL4J einzusetzen. Dabei variiert die Projektgrösse und -art stark. So wurde EL4J bereits für eine Soft-Real-Time- Applikation im Transportwesen, verschiedene klassische Informationssysteme im öffentlichen und kommerziellen Bereich und eine bi-temporale Datenbankapplikation für das Gesundheitswesen eingesetzt.
Als konkreteres Beispiel können wir eine Intranet-Webapplikation für die Verwaltung von Rückerstattungsanträgen einer Krankenkasse nennen. Operatoren können Anträge eingeben, die Höhe der Rückerstattung wird über eine eigene Business-Rule-Engine automatisch berechnet, die Auszahlung wird selbständig ausgelöst und ein Report informiert den Patienten. Eine Extranet-Schnittstelle erlaubt es Patienten, den Zustand ihrer Rückerstattungsanträge zu verfolgen. Das Projekt hat vor allem von der modularen Java-EE-Architektur, vom raschen Projektstart, und vom leichten und flexiblen POJO-Ansatz von EL4J profitiert. Dies äussert sich in weniger Projektaufwand und besserer Applikationsqualität.
Dank unseren guten Erfahrungen wird EL4J weitergeführt. Neue geplante Features sind unter anderem die Integration eines Ajax-Frameworks.
Auch für das .Net-Framework möchten wir die Erfolgsstory wiederholen: Seit letztem November ist EL4Net (EL4J für .Net) offengelegt.
Philipp H. Oser arbeitet bei ELCA und ist Architekt von EL4J. Zudem hat er einen Lehrauftrag an der Fachhochschule Nordwestschweiz.
