Die Rückkehr der Einfachheit 62

Transkript

1 7.09 Plus CD! Stellenmarkt S. 58 Das war die JAX 2009 S. 15 Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile CD-Inhalt JavaRebel 2.0 Squish WebCastellum QF-Test Groovy Scala Apache Trinidad specs Keynote von der JAX 2009 Mobile JavaFX Mobile Neal Ford: Ancient Philosophers & Blowhard Jamborees Alle CD-Infos 3 Plattformübergreifend entwickeln 92 Web Web Application Security Gib Hackern keine Chance 48 Architektur Lose gekoppelte Systeme ActiveMQ und Camel 83 Java Core Einführung in Scala, Teil 4 Pattern Matching & Co 24 Die Rückkehr der Einfachheit 62 Google App Engine 38 D Cloud Computing mit Java Cloud Computing erobert die IT-Welt. Zu verlockend ist die Möglichkeit, Hardwareressourcen nach Bedarf hinzuzufügen und so immense Fixkosten einzusparen. Anfang April wurde die GAE für Java als Early Look veröffentlicht. Wie zeigen, wie die Google App Engine funktioniert.

2 Enterprise Persistenzschichten mit JPA und Spring Hades Mit der Java Persistence API (JPA) gibt es einen Standard zur Implementierung von Persistenzschichten in Java. Dennoch ist Datenzugriffscode zu 90 % Boilerplate. Im Java Magazin [1] hat Eberhard Wolff bereits einen ersten Schritt zur Vereinfachung dieser Art Code vorgestellt. Darauf aufbauend ist das Open-Source-Projekt Hades, benannt nach der griechischen Unterwelt, entstanden, das diese Ideen aufgreift und weiterdenkt. von Oliver Gierke Quellcode auf CD entrales Konzept der JPA ist der EntityManager. Auf diesem können die gängigen Persistenzoperationen direkt per Methodenaufruf ausgeführt werden. Detailliertere Anfragen stellt man über die JPA QL, eine eigene Anfragesprache. Jedoch fehlen dem EntityManager viele Funktionalitäten, die im alltäglichen Gebrauch oft notwendig sind: Pagination (die Verteilung eines Anfrageergebnisses auf mehrere Seiten), einfaches Sortieren, Auditing von Entitäten usw. Natürlich lassen sich diese Features mit JPA implementieren. Daher findet man in vielen verschiedenen Projekten auch immer wieder Code, der eben diese Probleme immer wieder aufs Neue löst. Um Geschäftslogik von Persistenzlogik zu trennen, bedient man sich im Allgemeinen des Data Access Object (DAO) Patterns [2]. Es dient vor allem der Umsetzung des Prinzips Separation of Concerns (Trennung von Geschäftslogik und Persistenz) sowie der Testbarkeit der Geschäftslogik. Das Open-Source-Projekt Hades widmet sich nun genau diesen Themen: Vereinfachen der Entwicklung von Persistenzschichten auf Basis des DAO Patterns, weniger Implementierungsaufwand und Hilfestellungen, um alltägliche Aufgaben einer Persis tenzschicht zu lösen. Kern des Frameworks ist die Abstraktion eines GenericDao, das CRUD-(Create-, Read-, Update- und Delete-)Operationen pro Entitätstyp anbietet, ohne dass man sie selbst implementieren muss. Gegenüber dem reinen EntityManager Interface erlaubt es zusätzliche Leseoperationen wie readall(pageable pageable), um einfache Pagination sowie Sortieroperationen anzuwenden. Für dieses Interface steht mit GenericJpaDao eine Implementierung zur Verfügung, die mit allen JPA-Persistenzprovidern genutzt werden kann. Zusätzlich zu dieser grundsätzlichen Funktionalität bietet Hades das Interface ExtendedGenericDao, das Methoden wie readbyexample(t... examples) enthält, die mit der reinen JPA API gar nicht oder nur sehr schwer implementiert werden können. readbyexample(..) ermöglicht es, diejenigen Entitäten zu selektieren, die den übergebenen Beispielentitäten entsprechen. Viele Persistenzprovider bieten in ihren APIs diese Möglichkeit jedoch an. Um das Rad nicht neu zu erfinden, bietet Hades dafür ExtendedGenericDao-Implementierungen, die diese Funktionalität mit den APIs von Hibernate und EclipseLink umsetzen, was bedeutet, dass sie mit Hades nur mit diesen Persistenzprovidern genutzt werden kann. Abbildung 1 zeigt die Klassenhierarchie der DAO-Implementierungen. Finder-Methoden Ein Großteil der Datenzugriffslogik von Applikationen besteht aus so genannten Finder-Methoden, in denen lesende Zugriffe auf die Datenquelle durch Bedingungen eingeschränkt werden. In JPA werden hierfür NamedQueries eingesetzt, die es erlauben, JPA Queries unter einem Namen abzulegen und diese so später zu referenzieren. Um diese Finder-Methoden mit Hades zu realisieren, reicht es, wie in Listing 1 ein Interface zu definieren, das GenericDao erweitert. Es deklariert die benötigten Methoden und versieht sie mit einem bestimmten Präfix, um die generische Ausführung als Query zu veranlassen. Eine manuelle Implementierung des Interface ist nicht notwendig. Um die DAO-Instanz für das Interface zu erzeugen, bedient man sich nun der GenericDaoFactory und übergibt ihr das DAO-Interface. Ebenfalls konfigurieren lässt sich der Methodenpräfix, mit dem die Ausführung der JPA Queries getriggert wird. Dieser ist per Default fi n d By. Die Factory kann Methoden, die eine einzelne Entität zurückliefern, von Methoden unterscheiden, die eine Liste von Entitäten zurückliefern. Dementsprechend sind User und List<User> in unserem Beispiel gültige Rückgabetypen. Von der Methode zum Query Die Frage, die sich nun stellt ist: Wie kommt man vom Methodennamen zum Query? Zum einen kann man über die Namenskonvention ${entitätstyp.${fin dermethodename direkt einen Named- Query benutzen. Zum anderen ist es für sehr einfache Queries möglich, diese direkt aus dem Methodennamen abzuleiten. Ein findbylastname würde in diesem Fall zu select u from User u where u.lastname =? und findbyusername zu select from User u where u.username =? umgewandelt werden. Hades unterstützt in Version 0.5 die Operatoren AND und OR in den Methodennamen. Die genaue Art und Weise, wie das DAO die Methodenaufrufe umsetzen soll, kann man der GenericDaoFactory über die Enum QueryLookupStrategy mitgeben. Default ist hierbei CREATE_IF_NOT_ 70 javamagazin

3 Abb. 1: Klassenhierarchie DAO-Implementierungen FOUND. Diese Strategy ist mit zwei Auflösungsschritten die flexibelste. Der erste große Auflösungsschritt besteht im Suchen von deklarierten Queries. Hierbei stehen NamedQueries aus der JPA zur Verfügung, die an die Domänenklassen annotiert werden müssen oder in META- INF/orm.xml deklariert werden. Möchte man die Queries jedoch eher im DAO- Interface selbst pflegen, bedient man sich der direkt an der Finder-Methode. Schlägt die Auflösung über die Annotationen fehl, wird ein Query aus dem Methodennamen erzeugt und dieser ausgeführt. Auf diese Art und Weise kann man sehr einfach simple Queries von Hades direkt erzeugen lassen, während man diese in späteren Entwicklungsiterationen eventuell durch das explizite Hinzufügen von NamedQueries überschreiben und detaillierter festlegen kann. Integration des eigenen Codes Das GenericDao-Interface und die Möglichkeit, Finder-Methoden auszuführen, decken einen Großteil der Persistenzoperationen vieler Applikationen ab. Zum einen ist es aber ab und zu notwendig, eigene Datenzugriffsfunktionalität zu implementieren, zum anderen ist für einige Persistenzoperationen auch JPA bzw. ein O/R Mapper gar nicht das richtige Mittel und man möchte eher auf JDBC zurückgreifen, um bestimmte Anfragen gezielt zu optimieren. Unabhängig davon, was man genau vor hat, ist es nötig, eigenen Datenzugriffscode zu schreiben. Auch dies ist mit Hades möglich. Hierzu ist es notwendig, ein Interface mit den Methoden anzulegen, die die eigene Logik enthalten soll (Listing 4). Ebenso benötigt man natürlich eine passende Implementierung dafür, und UserDao muss nun UserDaoCustom erweitern. Um eine DAO-Instanz zu erhalten, die sowohl die generischen Methoden als auch die Finder-Ausführung sowie unseren eigenen Code enthält, nutzen wir wieder die GenericDaoFactory und übergeben ihr eine Instanz unserer eigenen Implementierung beim Aufruf an getdao. Spring Um die Integration in Spring-Applikationen zu vereinfachen, gibt es in Ha- Anzeige Welche GenericDao-Implementierung wird genutzt? Hades bietet in Version Implementierungen des GenericDao-Interfaces. GenericJpaDao implementiert nur dieses Interface und hat nur Abhängigkeiten zur JPA. Als Implementierungen von ExtendedGenericDao stehen GenericHibernateJpaDao und GenericEclipseLinkJpaDao zur Verfügung. Diese implementieren die zusätzliche Funktionalität auf den APIs von Hibernate bzw. EclipseLink und können daher nur genutzt werden, wenn die entsprechenden Persistenzprovider eingesetzt werden. Autoselect der GenericDaoFactoryBean Erzeugt man die Instanzen der DAOs manuell im Code, muss man explizit eine Implementierung auswählen. Wird die GenericDaoFactory(Bean) genutzt, entfällt diese explizite Entscheidung. Die Factory inspiziert den konfigurierten EntityManager und entscheidet daraufhin, welche Implementierung genutzt wird. Nutzt man einen Persistenzprovider, für den keine spezielle Implementierung vorliegt, und konfiguriert trotzdem ein Interface, das von ExtendedGenericDao ableitet und daher eine spezielle Implementierung benötigt, wirft die Factory bei ihrer Aktivierung eine Exception.

4 Enterprise Persistenzschichten mit JPA und Spring Listing 1 des eine GenericDaoFactoryBean, die Springs FactoryBean-Interface implementiert und so ein sehr einfaches Aufsetzen von DAO-Instanzen per Spring- Konfiguration erlaubt. Listing 5 zeigt die Konfiguration der Bean userdao, die neben der normalen Hades-Funktionalität mit eigener Funktionalität angereichert wird. Allerdings ist dies nur eine DAO- Instanz, d. h. der Konfigurationsumfang für viele DAOs wird erheblich. Des Weiteren muss man die beiden BeanPost- public interface UserDao extends GenericDao<User, Long> { Listing 2 // EntityManager injected bekommen oder manuell erzeugen GenericDaoFactory factory = GenericDaoFactory. create(entitymanager) UserDao dao = factory.getdao(userdao.class); Listing 3 public interface UserDao extends GenericDao<User, Long> { // Triggert NamedQuery User.findByLastname // Triggert den Query in der select u from User u where u.username =? ) Listing 4 public interface UserDaoCustom { void mycustomdaomethod(); public class UserDaoImpl implements UserDaoCustom { public void mycustomdaomethod() { // Eigene Implementierung public interface UserDao extends GenericDao<User, Long>, UserDaoCustom { Listing 5 Processors explizit deklarieren, die das Injizieren des EntityManager und bzw. die Übersetzung von proprietären Exceptions in Springs DataAccessException- Hierarchie übernehmen. Der Spring Namespace Seit Spring 2.0 lassen sich eigene XML Namespaces deklarieren, die es ermöglichen, komplexe Konfiguration zu vereinfachen. In Eberhard Wolffs <bean id= userdao class=...genericdaofactory Bean > <property name= daointerface value=...userdao /> <property name= customdaoimplementation ref= userdaocustom /> </bean> <bean id= userdaocustom class=...userdaoimpl /> <bean class=...persistenceannotationbeanpost Processor /> <bean class=...persistenceexceptiontranslation PostProcessor /> Listing 6 <hades:dao-config base-package= com.acme.dao > <hades:dao id= user /> </hades:dao-config> Listing 7 <hades:dao-config base-package= com.acme.dao > <bean id= userdaoimpl class=...userdaoimpl /> Listing 8 <aop:auto-proxy /> <bean class=...auditingadvice > <property name= auditoraware > <bean class=...myauditorawareimpl /> </property> </bean> Artikel wurde dieser Ansatz bereits, ähnlich wie in Listing 6 gezeigt, vorgestellt. Dieser Namespace löst die DAO- Interfaces über eine Namenskonvention ${package.${dao.iddao (in unserem Fall com.acme.dao.userdao) auf und deklariert eine GenericDaoFactory Bean- Instanz dafür, die letztendlich eine Instanz des DAOs erzeugt. Ebenfalls werden alle benötigten BeanPostProcessor implizit deklariert. Das Hinzufügen weiterer DAO-Instanzen ist so relativ einfach über das Hinzufügen von <dao />- Elementen möglich. Hades geht nun einen Schritt weiter und macht die <dao />-Elemente innerhalb des <dao-config />-Elements komplett optional. Wird dieser weggelassen, werden durch Springs Classpath-Scanning-DAO-Interfaces in dem konfigurierten Package gesucht und passende DAO-Instanzen erzeugt. Eigene Implementierungsklassen werden über eine Konvention aufgelöst, die eine Bean-ID mit dem DAO-Interfacenamen und dem Postfix Impl erwartet. Die Konfiguration aus Listing 5 kann also zu der in Listing 7 vereinfacht werden. Gerade wenn man mit sehr vielen DAOs arbeitet, erspart dieser Ansatz jede Menge Konfiguration. Neben dem Package für die DAO-Interfaces können auch der Finder-Präfix sowie die Strategie zur Query-Auflösung im <daoconfig />-Element konfiguriert werden. Weiterhin ist es in <dao />-Elementen möglich, die Konfiguration des <daoconfig />-Elements für ein einzelnes DAO zu überschreiben. Eine detaillierte Übersicht über die Konfigurationsmöglichkeiten findet man unter [3]. Eclipse-Integration Für Entwickler von Spring-Applikationen, die mit Eclipse arbeiten, ist die SpringIDE [4] ein unabkömmliches Hilfsmittel. Damit die DAO Beans des Hades Namespace dort ebenfalls angezeigt werden, empfiehlt es sich, das Hades Eclipse Plug-in von [5] zu installieren. Es sorgt dafür, dass sowohl durch Classpath Scanning deklarierte Beans als auch manuell konfigurierte Beans in der Spring Elements Sektion des Project Explorer auftauchen (Abb. 2). Hierdurch werden sie auch von der SpringIDE bei 72 javamagazin

5 Abb. 2: Hades Eclipse- Plug-in Abb.3: Klassendiagramm zum Auditing der Code-Completion für Bean-Referenzen herangezogen. Ebenfalls werden die DAO-Interfaces als Spring Beans markiert, sodass sie leicht als solche identifiziert werden können. Domänenbasisklassen und Auditing Hades bietet neben den DAO-Interfaces und -Implementierungen auch Basisklassen zur Implementierung der gängigsten Varianten von JPA-Entitäten an (Abb. 3). In vielen Fällen ist es z. B. notwendig, das Datum und den Benutzer der Erstellung bzw. der letzten Modifikation einer Entität zu speichern. Auch dies ist mit Hades sehr einfach möglich. Zu auditierende Entitäten implementieren das Interface Auditable bzw. leiten von AbstractAuditable ab. Die Audit-Information selbst kann nun per aspektorientierter Programmierung (AOP) beim Speichern der Entität gesetzt werden. Dazu steht mit dem AuditingAdvice ein Advice zur Verfügung, der speichernde Aufrufe an das GenericDao-Interface per AOP abfängt und die entsprechenden Informationen auf der zu speichernden Entität setzt. Die Information, welcher Benutzer gerade Auditor ist, kann man dem Advice über das Interface AuditorAware bekanntmachen. Hierfür ist eine eigene Implementierung notwendig, die im Normalfall an die Authentifizierungslogik ihrer Applikation angeschlossen ist (Listing 8). Fazit Mit Hades steht ein Open-Source-Framework zur Verfügung, das die Entwicklung von Datenzugriffsschichten mithilfe von Spring und der JPA stark vereinfacht. Hades liefert Abstraktionen für die Umsetzung von Pagination und Sortierung sowie das Formulieren von Findern. Weiterhin stehen viele Basisklassen für die Implementierung von Domänenklassen zur Verfügung. Die nahtlose Integration in Spring-Applikationen ist durch den eigenen Namespace sowie das Eclipse Plug-in zur Erweiterung der SpringIDE gewährleistet. Oliver Gierke ist Softwarearchitekt bei der Firma Synyx GmbH & Co. KG in Karlsruhe. Seine Arbeitsschwerpunkte liegen in den Bereichen Enterprise- Applikationen, Architekturmanagement und agile Prozesse. Links & Literatur [1] Wolff, Eberhard: Einmalige DAOs, Java Magazin [2] Data Access Object: Access_Object [3] Hades-Projekthomepage: [4] Webseite der SpringIDE: [5] Updatesite für das Eclipse Plug-in: Anzeige