Dirk Weil. Java EE 6. Enterprise-Anwendungsentwicklung leicht gemacht

Transkript

1

2

3 Dirk Weil Enterprise-Anwendungsentwicklung leicht gemacht

4 Dirk Weil Enterprise-Anwendungsentwicklung leicht gemacht ISBN: entwickler.press Ein Imprint der Software & Support Media GmbH Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Ihr Kontakt zum Verlag und Lektorat: Software & Support Media GmbH entwickler.press Geleitsstr Frankfurt am Main Tel.: +49 (0) Fax: +49 (0) Lektorat: Sebastian Burkart Korrektorat: Frauke Pesch Satz: Dominique Kalbassi Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

5 Inhaltsverzeichnis Vorwort 9 1 Java EE im Überblick Aufgabenstellung Architekturmodell Anwendungsbestandteile und Formate Profile Plattformen 16 2 CDI Was ist das? Wozu braucht man das? Bereitstellung und Injektion von Beans Lifecycle Callbacks Qualifier Alternatives Nutzung der Java-EE-Umgebung Producer und Disposer Kontexte und Scopes Interceptors Decorators Stereotypes Eventverarbeitung Programmgesteuerter Zugriff auf CDI Beans Integration von JPA, EJB und JSF Plattformen und Ergänzungen 53 3 Java Persistence Worum geht s? Lösungsansätze Anforderungen an O/R-Mapper Entwicklung des Standards Architektur von Anwendungen auf Basis von JPA 61 5

6 Inhaltsverzeichnis 3.2 Die Basics Entity-Klassen Konfiguration der Persistence Unit CRUD Detached Objects Entity-Lebenszyklus Mapping-Annotationen für einfache Objekte Generierte IDs Objektgleichheit Objektrelationen Unidirektionale n:1-relationen Unidirektionale 1:n-Relationen Bidirektionale 1:n-Relationen Uni- und bidirektionale 1:1-Relationen Uni- und bidirektionale n:m-relationen Eager und Lazy Loading Kaskadieren Orphan Removal Anordnung von Relationselementen Queries JPQL Native Queries Criteria Queries Vererbungsbeziehungen Mapping-Strategie SINGLE_TABLE Mapping-Strategie TABLE_PER_CLASS Mapping-Strategie JOINED Non-Entity-Basisklassen Dies und das Secondary Tables Zusammengesetzte IDs Dependent IDs Locking Callback-Methoden und Listener Bulk Update/Delete Caching 140 6

7 Inhaltsvrzeichnis 3.8 Erweiterte Entity Manager Java Persistence in SE-Anwendungen Konfiguration der Persistence Unit im SE-Umfeld Erzeugung eines Entity Managers in SE-Anwendungen Transaktionssteuerung in Java-SE-Anwendungen Bean Validation Aufgabenstellung Plattformen und benötigte Bibliotheken Validation Constraints Objektprüfung Internationalisierung der Validierungsmeldungen Validierungsgruppen Integration in JPA und JSF Bean Validation in SE-Umgebungen JavaServer Faces Einsatzzweck von JSF Die Basis: Java-Webanwendungen Grundlegender Aufbau Servlets JavaServer Pages JSF im Überblick Model View Controller Facelets Request-Verarbeitung Konfiguration der Webanwendung Benötigte Bibliotheken und Plattformen Programmierung der Views JSF Tag Libraries Managed Beans Unified Expression Language Navigation Scopes Verarbeitung tabellarischer Daten Internationalisierung 196 7

8 Inhaltsverzeichnis 5.13 Ressourcenverwaltung GET Support Event-Verarbeitung Konvertierung Validierung Immediate-Komponenten Ajax Templating mit Facelets Eigene JSF-Komponenten Komponentenbibliotheken Security Enterprise JavaBeans Aufgabenstellung Aufbau von Enterprise JavaBeans EJB Deployment Lokaler Zugriff auf Session Beans Remote-Zugriff Transaktionssteuerung Asynchrone Methoden Timer Security Ein Real World -Projekt Aufgabenstellung Anwendungsarchitektur Persistenz Views Fachliche Injektion 274 Stichwortverzeichnis 277 8

9 Vorwort Java steht uns als leistungsfähige Basis für die Softwareentwicklung schon seit mehr als 15 Jahren zur Verfügung, einen großen Teil davon auch inklusive der Enterprise Edition, d. h. der Plattform für Unternehmensanwendungen, die verteilte Systeme mit oder ohne Browser als Client, (Web-) Services, Clustering, integrierte Systemlandschaften etc. beherrschbar machen soll. Warum dann jetzt ein Buch über die Softwareentwicklung mit Java EE? Java EE ist zweifellos schon seit vielen Jahren eine verlässliche und tragfähige Plattform zur Entwicklung von Enterprise-Anwendungen. Die hohe Komplexität der ersten Versionen hat aber viele bewogen, sich ganz oder teilweise zugunsten anderer Frameworks abzuwenden. Die Kritik war bis zur Version 1.4 auch durchaus berechtigt nun aber sind die Weichen neu gestellt in Richtung Einfachheit der Softwareentwicklung. Ein Wert von Java EE besteht sicher in ihrer abwärtskompatiblen Weiterentwicklung. Für ältere Versionen erstellte Anwendungen bleiben also weiter lauffähig. Als Kehrseite der Medaille sind somit auch die alten Strukturen der Plattform noch vorhanden. Um in den Genuss der leichtgewichtigen Softwareentwicklung zu kommen, muss man sich somit auf die neuen Wege konzentrieren und alten Ballast rechts und links liegen lassen. Dieses Buch soll Ihnen bei der Auswahl aus dem großen Angebot der Java EE eine Hilfe sein. Es hat nicht den Anspruch einer allumfassenden Darstellung, sondern beschränkt sich auf die Teile der Gesamtspezifikation, mit denen sich ein leistungsfähiger, aber überschaubarer Stack für Enterprise-Anwendungen zusammensetzen lässt. Es zeigt anhand vieler Beispiele, wie einfach Software für die Java-EE-Plattform erstellt werden kann. In einem durchgängigen Real World -Projekt werden am Ende alle behandelten Teile zu einer kompletten Anwendung zusammengesetzt und so das Zusammenspiel der Einzelteile verdeutlicht. Begleitprojekte Die im Buch gezeigten Beispiele stammen aus den Begleitprojekten zu den jeweiligen Buchkapiteln. Sie stehen unter dem URL javaee6buch zum Download bereit. Dort ist auch das erwähnte übergreifende Projekt enthalten. Weiterführende Dokumentation Im Sinne der Auswahl der zur leichtgewichtigen Softwareentwicklung benötigten Teile der Java EE geht das Buch nicht auf sämtliche Details der Plattformbestandteile ein, son- 9

10 Vorwort dern verweist für weniger häufig genutzte Informationen auf die jeweiligen Spezifikationen. Sie können über auf diese Texte zugreifen. Am Anfang der Buchkapitel finden Sie jeweils einen entsprechenden Link. Wir haben weitgehend darauf verzichtet, die Java-Dokumentation der Plattformklassen im Buch abzudrucken, da sie online verfügbar ist. Sie kann unter javaee/6/api/ direkt gelesen werden und ist unter javaee/documentation/ downloadbar. 10

11 1 Java EE im Überblick 1.1 Aufgabenstellung Java EE steht für Java Platform, Enterprise Edition und ist eine Dachspezifikation mit gut drei Dutzend einzelnen Spezifikationen, die als Ergänzung der Standard Edition für unterschiedliche Bereich der Anwendungsentwicklung dienen. Im Kern geht es um verteilte Anwendungen, die ggf. auf mehreren Servern laufen, von Clients unterschiedlichen Typs genutzt werden und mit anderen Anwendungen im Unternehmensverbund vernetzt sind. Einige Teilspezifikationen sind aber auch im reinen Standard-Umfeld anwendbar. Die Spezifikationen legen die Schnittstellen und Umgebungseigenschaften sehr strikt fest und definieren zudem eine Menge standardisierter Infrastrukturdienste wie bspw. Transaktionssteuerung oder Komponentenregistrierung. Entwickler erhalten dadurch einen vorgegebenen Rahmen, in dem sie Software erstellen können, ohne stets die komplexe Laufzeitumgebung vor Augen zu haben. Sie können sich idealerweise auf das konzentrieren, was ihre eigentliche Aufgabe ist: Fachlogik implementieren. 1.2 Architekturmodell Java-EE-Anwendungen lassen sich grob aufteilen in eine Clientschicht, die serverseitige Implementierung und eine Schicht, in der Daten abgelegt oder von anderen Systemen weiterverarbeitet werden. Als Clients von Java-EE-Anwendungen werden häufig Browser eingesetzt. Die Präsentationslogik wird in diesem Fall serverseitig bereitgestellt, vielfach durch JavaServer Faces in einem Web Container. Desktopclients implementieren die Präsentationslogik i. d. R. selbst. Sie greifen entweder direkt auf die Geschäftslogik zu oder bedienen sich bspw. Web Services. Die Geschäftslogik kann mittels CDI und/oder EJB programmiert werden und diverse weitere serverseitige Techniken wie Java Persistence, Connector, Messaging etc. verwenden. Die verarbeiteten Daten werden häufig in Datenbanken abgelegt, können aber auch in anderen Backend-Systemen liegen, die auf unterschiedliche Weise angebunden werden können. 11

12 1 Java EE im Überblick Abbildung 1.1 zeigt dieses Modell schematisch. Es ist aus Gründen der Übersichtlichkeit etwas vereinfacht: Neben Browser und Desktop sind andere Clients denkbar wie bspw. mobile Geräte In der Webschicht sind andere Framework als JavaServer Faces einsetzbar Aus der Geschäftslogikschicht ließen sich die eher technische Aspekte wie Connector, Messaging etc. in eine Infrastrukturschicht extrahieren Abbildung 1.1: Java-EE-Architekturmodell 1.3 Anwendungsbestandteile und Formate Java-EE-Anwendungen sind aus wohldefinierten Teilen aufgebaut, die sich grob an den Architekturbestandteilen orientieren. Technisch werden die Teile in separaten Jar-Dateien bereitgestellt. Da in den weiteren Kapiteln des Buches näher auf die Bestandteile eingegangen wird, soll hier zunächst nur ein grober Überblick geschaffen werden. 12

13 Anwendungsbestandteile und Formate Webanwendung Dieser Anwendungsteil fasst die Webdokumente, Servlets etc. zusammen, die für die serverseitige Präsentationslogik der Anwendung benötigt werden, und zwar in ein Jar-File mit der Endung.war. Ein optionaler Deployment Descriptor WEB-INF/web.xml erlaubt die Konfiguration der Anwendung. Enterprise JavaBeans Im ursprünglichen Ansatz der Java EE waren EJBs der Platz für die serverseitige Geschäftslogik. Die Klassen und Interfaces mehrerer EJBs werden dann zu einem Jar-File zusammengepackt. Auch hier können Konfigurationswerte in einem Descriptor META-INF/ ejb-jar.xml beigefügt werden. Die Endung.jar lässt leider keine direkte Unterscheidung von einer einfachen Bibliothek zu. CDI Die Aufgaben von EJBs können weitgehend von CDI übernommen werden. Java EE definiert dafür kein spezielles Anwendungsformat. Vielmehr werden die CDI-Klassen und Interfaces direkt oder als einfache Bibliothek in die gesamte Anwendung integriert. Hier ist ein Descriptor namens beans.xml notwendig. Enterprise-Anwendung Hierin werden die zuvor genannten Bestandteile nochmals zusammengefasst, und zwar zu einem Jar-File mit der Endung.ear. Zusätzlich können auch Konnektoren und Application Clients integriert werden, worauf hier aber nicht weiter eingegangen werden soll. Konfigurationsparameter dürfen in META-INF/application.xml eingetragen werden. In einem speziellen Verzeichnis üblicherweise lib genannt können Bibliotheken eingetragen werden, die der gesamten Anwendung zur Verfügung stehen sollen. Abbildung 1.2 zeigt schematisch den Aufbau einer Enterprise Application, wobei die Inhalte der Applikationsteile ihrerseits Jar-Files exemplarisch angegeben sind. 13

14 1 Java EE im Überblick Abbildung 1.2: Aufbau einer Enterprise-Anwendung inklusive der Inhalte der Anwendungsteile Deployment-Formate Im Sinne der Spezifikation sind Web- und Enterprise-Anwendungen deploy-fähig. Das eigentliche Deployment-Verfahren ist abhängig vom verwendeten Application Server. Vielfach wird ein Autodeploy-Ordner angeboten, in den die.war- bzw..ear-dateien kopiert werden können. Alternativ oder zusätzlich bieten die Hersteller Administrationswerkzeuge an, mit denen ein Deployment von Anwendungen vorgenommen werden kann. Einige Server erlauben auch das Deployment von Verzeichnissen. Sie haben die interne Struktur der genannten Archivdateien, sind aber eben nicht gepackt. Die gängigen Ent- 14

15 Profile wicklungsumgebungen nutzen dies häufig für ein schnelles und inkrementelles Deployment-Verfahren direkt aus der IDE heraus. Die Entscheidung für eines der beiden offiziellen Deployment-Formate ist weniger technischer, sondern eher organisatorischer Natur: Das EAR-Format eignet sich recht gut, wenn die Anwendungsteile klar abgegrenzt sind und sich das auch in der erstellten Dateistruktur widerspiegeln soll. Die Anwendung wird im Betrieb mit mehreren Classloadern geladen, die einander in der Art referenzieren, dass die Webanwendungen die Klassen der gesamten Anwendung nutzen können, umgekehrt aber die Klassen einer Webanwendung für andere Anwendungsteile nicht sichtbar sind. Die Abhängigkeiten der Anwendungskomponenten untereinander spiegeln sich hier also im Classloading passend wider. In vielen Fällen benötigt man die zwar klare, aber doch komplexe Struktur des EAR- Deployments nicht. Dann kann ein WAR-Deployment gewählt werden (entsprechend dem oberen umrahmten Teil der Abbildung 1.2). Obwohl es sich nun dem Namen nach um eine Webanwendung handelt, können auch EJBs oder CDI Beans integriert werden 1, sodass das WAR-Format keine Nachteile im Hinblick auf die verwendbaren Teile hat. Die Anwendung wird nun allerdings mit nur einem Classloader geladen, sodass zwischen den Anwendungsklassen keinerlei Isolation gegeben ist. Die Begleitprojekte zu den Buchkapiteln sind als WAR-Deployments aufgebaut. 1.4 Profile Beginnend mit der Version 6 der Java EE wurde eine Gruppierung der Teilspezifikationen in sog. Profile eingeführt. Damit wird der Tatsache Rechnung getragen, dass für viele Anwendungstypen nur bestimmte Teile der Java EE benötigt werden. Ein Serverhersteller ist damit nicht mehr gezwungen, für einen Java-EE-Server die gesamte Bandbreite der Spezifikation abzudecken. Er kann vielmehr einen Server anbieten, der ein bestimmtes Profil unterstützt. Derzeit ist neben dem Gesamtumfang dem Full Profile nur das Web Profile definiert, das die Teile der Java EE enthält, die man i. d. R. zum Aufbau von webbasierten Anwendungen benötigt (Abb. 1.3). In der Zukunft werden sicher weitere Profile definiert werden, z. B. zur Unterstützung von Web Services oder Messaging. 1 Die Descriptoren aus META-INF werden im WAR-Deployment in WEB-INF platziert. 15