Artikel als PDF anzeigen

ITMAGAZINE
Frameworks intelligent integriert
18. Mai 2006 - Durch die Verzahnung verschiedener Standard-Frameworks soll die Entwicklung von
J2EE-Applikationen nochmals deutlich schneller werden. Die Java Enterprise Edition (Java EE) hat sich als leistungs-fä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 Ein-satz nicht trivial. Das Open-Source- Projekt EL4J hilft dabei.
Warum J2EE-Frameworks?
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).
Qual der Wahl
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.
Offshore-Entwicklungen zu kontrollieren.
Viel Zusatznutzen
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
Automatisch automatisiert
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.
Architektur von EL4J
Konkreter Einsatz
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-TimeApplikation 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.
Quo vadis?
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.
Der Autor
Philipp H. Oser arbeitet bei ELCA und ist Architekt von EL4J. Zudem hat er einen Lehrauftrag an der
Fachhochschule Nordwestschweiz.
Copyright by Swiss IT Media 2017