EJB 3.1 JPA 2.0. Java-Framework. Autor Stephan Metzler. About Coders geek & poke

Transkript

1 EJB 3.1 JPA 2.0 Java-Framework Autor Stephan Metzler About Coders geek & poke Version / 2011

2 i-ch223 >> Multi-User-Applikation objektorientiert realisieren >> MileStones 1. Tag 2. Tag 3. Tag Seite A Java Community 5 B Verteilte Systeme 39 C Java EE 45 D EJB 61 E Testen 109 F SLSB 129 G SFSB 143 H Singleton 161 I Messaging 169 J AOP 189 K Timer Service 207 L Web Service 221 M EJB Security 229 N Transaktionen 253 O JPA 281 P Idioms 431 Q Regeln 445 R Deployment Deskriptoren 449 S Trends 465 T Projekt 473 U Referenzen Tag 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 2 >> total: 255 Seiten

3 EJB 3.1 / JPA 2.0 >> Java Framework >> A Java Community Lerninhalte Technologien Entwurfsmuster Entwicklungtools Paradigmen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 3 >> total: 255 Seiten

4 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform 1 Java Plattform Die Java Plattform ist in drei Editionen aufgeteilt JME Micro Edition - Umgebung - robust - flexible - Ziel-Applikationen - embedded devices - Mobil-Telefone - PDAs - Inhalt - VM - Kommunikationsprozesse JSE Standard Edition - Inhalt - JRE - APIs - VM - JDK - JRE - Compiler - Debugger Basis für JEE JEE Enterprise Edition - Definition - Standard (Framework) - Multi-User - Multi-Tier - Enterprise Appl. - Inhalt - Dienstleistungen - Zugriff - transparente Lösungen - Verhalten OOA / OOD Hilfreiche und wichtige Neuerungen im Java-Standard (seit JDK 1.5) - Annotations Metadaten im Source - Generics parametrischer Polymorphie Entwurfmuster - Dependency Injection Objekte erhalten ihre Abhängigkeiten passiv Paradigma - AOP Aspect Orientiertes Programmieren trennt System- von Businesslogik Tools im Umgang mit JEE Technologien - Maven Build-Management-Tool der Apache Software Foundation - Log4J Loggen von Informationen Nachvollziehbarkeit / Wiederverwendbarkeit - JUnit Test-Framework automatisiertes Testen - Mock dynamisches (Dummy-) Test-Objekt Integrationstests 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 4 >> total: 255 Seiten

5 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform 1.1 Annotationen wiki Annotation bedeutet "Anmerkung", "Beifügung", "Hinzufügung". In diesem Sinn haben Annotationen bei Stichworten, Begriffsklärungen oder ausführlichen Texten den Charakter der Erklärung beziehungsweise Ergänzung. In der Softwareentwicklung dienen Annotationen dazu, Metadaten in den Quelltext eines Programms einzubinden. Diese haben keine direkte Auswirkung auf die Übersetzung des Quelltextes, bieten aber zusätzliche Möglichkeiten im Vergleich zu einfachen Kommentaren. Eigenschaften - Metadaten direkt im Sourcecode - zentral - XML- oder Property-Dateien entfallen - mehrere Dateien sind z.t. umständlich - werden von Codegenerierungstools ausgelesen - Controlle bei der Entwicklung - werden zur Laufzeit per Reflection abgefragt - zur dynamischen Verwendung in Frameworks - Zuordnung zum Sourcecode ersichtlich - als Entwickler-Vorteil Verwendung von Annotations - Annotations werden im Sourcecode vor dem zu markierenden Element eingefügt als Kennzeichnung vorangestellt - Leerzeichen sind erlaubt - Parameter als Name/Wert-Paar in Klammern an den Annotationsnamen = "hallo", parameter2 = "world") - Reihenfolge der Parameter spielt keine Rolle - hat die Annotation nur einen Parameter, kann der Name weggelassen werden - bei parameterlosen Annotations ist die Angabe der Klammern optional - Annotations können sich auf folgende Java-Elemente beziehen: - Packages, Klassen, Interfaces, Enumerations, Methoden, Variablen, Methodenparameter 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 5 >> total: 255 Seiten

6 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Annotations in der Java JSE definiert sieben Annotations - Standard Annotation normale Verwendung beim Programmieren - Meta Annotation Definition neuer Annotationstypen Standard Annotations - kennzeichnet Methoden und Klassen, die nicht mehr verwendet werden sollen - der Compiler stellt sicher, dass die Methode überschrieben wird - seit Java SE 1.5 für Superklassen Codesicherheit - seit Java SE 1.6 für Interfaces macht Business-Interfcae Pattern obsolet - unterdrücken Compilerwarnungen - Warnungen werden als Parameter angegeben public class HelloWorld public String sayhello() { return "Hello public String tostring() { return "Hello World"; - sayhello() ist "veraltet" und erzeugt Compilerwarnung - tostring() stellt sicher, dass tostring() aus Object überschrieben wird 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 6 >> total: 255 Seiten

7 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Meta Annotations - zur Erzeugung der Dokumentation bei Javadoc - Annotation-Typ wird vererbt - auch rekursiv - falls keine Annotation in der aktuellen Klasse gefunden wird - Definiert wie lange die Annotation verfügbar ist - SOURCE stehen nur zur Compilerzeit zur Verfügung - CLASS (DEFAULT) werden in Class-Dateien abgespeichert, jedoch nicht von der VM geladen - RUNTIME werden in der Class-Datei abgelegt und von der VM geladen und stehen somit zur Auswertung per Reflection zur Verfügung - definiert Elemente (Klasse, Methode, Parameter etc.), denen eine Annotation zugeordnet werden kann Beispiel selbst definierter Annotation public enum Datentyp { TEXT, Datenfeld { String bezeichnung() default ""; Datentyp datentyp() default Datentyp.TEXT; definiert die Verfügbarkeit - RUNTIME : Auswertung zur Laufzeit definiert wo die Annotation eingesetzt werden kann - FIELD : für Attribute definiert das annotierte API Element "Datenfeld" - Parameter : Bezeichnung und Datentyp (sind optional und mit Default-Werten) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 7 >> total: 255 Seiten

8 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Anwendung: Klasse Person annotiert Attribute als Datenfelder public class Person implements java.io.serializable = "Nummer", datentyp = Datentyp.NUMMER) private int = "Name", datentyp = Datentyp.TEXT) private String private String beschreibung; Auslesen der Annotationen Person p = new Person(); Field[] fields = p.getclass().getdeclaredfields(); for (Field field : fields) { Datenfeld datenfeld = field.getannotation(datenfeld.class); if (datenfeld!= null) { System.out.println("\nannotiertes Attribut: " + field.getname()); if (datenfeld.bezeichnung().length()!= 0) { System.out.println("\tBEZ = " + datenfeld.bezeichnung()); System.out.println("\tTYP = " + datenfeld.datentyp()); Aufgabe selbstdefinierte Annotation - Testen Sie die annotiertes Attribut: nr BEZ = Nummer TYP = NUMMER annotiertes Attribut: name BEZ = Name TYP = TEXT annotiertes Attribut: beschreibung TYP = TEXT 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 8 >> total: 255 Seiten

9 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform 1.2 Generics wiki In der Informatik sind Generische Typen Datentypen mit der Möglichkeit zur Angabe von Typparametern. Man spricht auch von parametrischer Polymorphie. Ein generischer Typ erlaubt es, Datentypen zu erzeugen, die von den zu Grunde liegenden Typen abstrahieren. So würden eine Liste von Zahlen, eine Liste von Zeichen und eine Liste von Datumsangaben im Grunde auf dieselbe Weise programmiert werden. Die Algorithmen zum Einfügen, Suchen und Löschen würden stets gleich ablaufen. Es ist daher wünschenswert, die Implementierung der Liste unabhängig von diesen Typen vorzunehmen Eigenschaften - erlauben die Abstraktion von Typen - erlauben Wiederverwendbarkeit von Funktionalitäten - defineren generische Klassen und Methoden - unabhängig von einem konkreten Typ - definieren parametrische Polymorphie Generics verbessern die Lesbarkeit und helfen durch die erhöhte Typsicherheit die Zuverlässigkeit des Codes zu erhöhen. normale Collections List v = new Vector(); v.add(new Double(1.0)); Double d = (Double)v.get(0); - Cast auf Double ist notwendig, denn der Rückgabewert von get(...) ist Objekt - erlaubt inkompatible Typen in die Liste einzuführen generische Collections List<Double> v = new Vector<Double>(); v.add(new Double(1.0)); Double d = v.get(0); - v ist eine Liste von (nur) Double - Typ in spitzen Klammern definiert den konkreten Typparameter - Verwendung wird durch Compiler sichergestellt und zur Compilezeit erkannt - Casts entfallen, da Rückgabewert von get(...) nur Double ist - mehrere Typparameter werden durch Komma getrennt (z. B. Hashtable<Long, String>) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 9 >> total: 255 Seiten

10 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Wildcards und Bounds - unabhängiger Code - Implementierung von Such- oder Sortieralgorithmen - Wildcardzeichen ist? - Vector<?> steht für einen Vector mit beliebigem Inhalt - Bounds als Angabe von Schranken - extends limitiert auf den angegebenen oder abgeleiteten Typ - super limitiert auf den angegebenen oder vererbten Typ Beispiel parametrisierter Polymorphie Vector<?> v1; Vector<String> v2 = new Vector<String>(); v1 = v2; // nur String List<? extends Number> 100; // Number oder Subtyp List<? super String> 2; // String oder Supertyp generische Typen - Generics sind nicht auf die Verwendung bestehender Klassen beschränkt - eigene generische Typen können definiert werden Definition der generischen Klasse MyGeneric - Enthält zwei Typparameter (K und V) - die Typparameter können wie normale Typen bei der Definition der Klasse verwendet werden public class MyGeneric<K, V> { private K key; private V value; public MyGeneric(K key, V value) { this.key = key; this.value = value; public K getkey() { return key; public V getvalue() { return value; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 10 >> total: 255 Seiten

11 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Aufgabe genererische Typen / generische Methoden - Typparameter wie normale Typen bei der Definition der Klasse public void testmygeneric() { K key = (K) "test"; V value = (V) (new Integer(123)); MyGeneric<K, V> mygeneric = new MyGeneric<K, V>(key, value); assertequals(key, mygeneric.getkey()); assertequals(value, mygeneric.getvalue()); - generische Methoden generische Methode sayhello(...) enthält zwei Typparameter public static <E, T> String sayhello(e pre, T post) { return (pre.tostring() + " hello " + public void testsayhello() { assertequals("generic hello world", sayhello("generic", new StringBuffer("world"))); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 11 >> total: 255 Seiten

12 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform 1.3 Log4J - populäre JAVA Logging-API - Vererbung von Loggern - Logger-Hierachien erlauben feingranulare Kontrolle über Logausgaben - Log-Anweisungen lassen sich durch Konfigurationsdateien ein- und ausschalten Komponenten - Loggers - sind <Named Entities> - sind case sensitive - folgen einer hierarchischen Namenskonvention - Layouts - erlauben das Formatieren der Logmeldungen - Appenders - erlaubt die parallele Ausgabe der Logmeldungen an verschiedene Ausgabemedien - z.b. Konsole, Dateien, GUI Komponenten, Sockets, JMS, etc. Logger wiki Ein Logger ist ein Vorfahre eines anderen Loggers, wenn sein Name, gefolgt von einem Punkt der Präfix des Namens eines Kind Loggers ist. Ein Logger ist ein Vater eines Kind Loggers, wenn es zwischen ihm und dem Nachkomme Logger keine weiteren Vorfahren gibt. Beispiel - Logger mit dem Namen <com.foo> ist Vater von <com.foo.bar> - Logger mit dem Namen <java> ist ein Vater von <java.util> - Root-Logger (z.b. org) ist oberste Instanz - org.apache.log4j - einem Logger kann ein Level zugeordnet werden - DEBUG < INFO < WARN < ERROR < FATAL - Level sind in der Klasse org.apache.log4j.level definiert - wenn einem Logger kein Level zugeordnet wurde, erbt er den Level Level Additivity Logger root root.x Level ERROR Geerbte rbter r Level ERROR 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 12 >> total: 255 Seiten

13 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Layouts erlauben das Formatieren der Loggermeldungen mit Pattern org.apache.log4j Pattern Zweck c Category: Kategorie = Name org.apache C Class = Klassennamen d Date. Beispiel: %d{hh:mm:ss,sss F Filename l Location Information L Line number m Meldung selbst M Methodennamen n Line-Separator (Plattformabhängig) p Priority: INFO, WARN, ERROR etc. r Anzahl der Millisekunden seit dem Start der VM t Name des Threads Beispiel %r [%t ] %-5p %c - %m%n 16 [main ] INFO log.simplelogging entering Application Appenders - definiert Destinationen für Logger Meldungen - Konsolen, Dateien, GUI-Komponenten, JMS, etc. - Zuweisung eines Appenders durch die Methode addappender - Appenders werden vereerbt Appender Additivity Logger root org org.apache org.apache.log4j Appender Target Vererbte Appenders root A1 A1 org B1, B2 A1, B1, B2 org und root org.apache none A1, B1, B2 org und root org.apache.log4j C1 A1, B1, B2, C1 org.apache.log4j, org und root Beispiel #set root logger level to DEBUG and define a appender 'file' log4j.rootlogger=debug, file #set logging of package 'annotation' to Level WARN; inherits also appender 'file' log4j.logger.annotation=warn 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 13 >> total: 255 Seiten

14 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Konfiguration durch Properties-Datei log4j.properties #LEVELS: ALL > DEBUG > INFO > WARN > ERROR > FATAL > OFF #set root logger level to DEBUG and define a appender file log4j.rootlogger=debug, file #set logging of package 'log' to Level WARN and define a appender L1 log4j.logger.log=info, L1 #set logging of package 'annotation' to Level WARN log4j.logger.annotation=warn #L1 appender uses the Console with a Pattern log4j.appender.l1=org.apache.log4j.consoleappender log4j.appender.l1.layout=org.apache.log4j.patternlayout log4j.appender.l1.layout.conversionpattern=%d %-5p [%t] %C{2 - %m\n #file appender uses a LOG File with a Pattern log4j.appender.file=org.apache.log4j.rollingfileappender log4j.appender.file.file=log4j.log log4j.appender.file.maxfilesize=100kb log4j.appender.file.layout=org.apache.log4j.patternlayout log4j.appender.file.layout.conversionpattern=%d %-5p <%t> %F:%L - %m%n #file appender keeps one Backup File log4j.appender.file.maxbackupindex=1 Konfiguration durch XML-Datei log4j.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j=' <appender name="l1" class="org.apache.log4j.consoleappender"> <layout class="org.apache.log4j.patternlayout"> <param name="conversionpattern" value="%d %-5p [%t] %C{2 - %m\n" /> </layout> </appender> <root> <priority value="debug" /> <appender-ref ref="l1" /> </root> <logger name="annotation"> <level value="warn" /> </logger> </log4j:configuration> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 14 >> total: 255 Seiten

15 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Aufgabe Log4J - fügen Sie Ihren Projekten eine Log4J Datei hinzu - testen Sie die verschiedenen Loggers, Layouts und Appenders - definieren Sie eine Output Datei für die DEBUG Meldungen Ansatz SimpleLogger.class public class SimpleLogger { static Logger logger = Logger.getLogger(SimpleLogging.class.getName()); public static void main(string[] args) { // configures Logger from log4j.properties or from log4j.xml PropertyConfigurator.configure("properties/log4j.properties"); PropertyConfigurator.configure("log4j/log4j.xml"); logger.info("entering Application"); Person p = new Person(); p.doit(); logger.info("leaving Application"); Ansatz loggen von Person.class public class Person implements java.io.serializable { static Logger logger = Logger.getLogger(Person.class); public Person(){ logger.info("person konstructed!"); public void doit() { logger.warn("did it again!"); Output auf der Konsole :00:00,781 INFO [main] log.simplelogging - entering Application :00:00,781 INFO [main] log.simplelogging - leaving Application File log4j.log :00:00,234 INFO <main> SimpleLogging.java:20 - entering Application :00:00,234 WARN <main> Person.java:20 - did it again! :00:00,234 INFO <main> SimpleLogging.java:23 - leaving Application 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 15 >> total: 255 Seiten

16 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform 1.4 Project Lombok - Code Generator - umgeht Java Konventionenfür JavaBeans - definieren des Default Konstruktors - generieren von getter / setter - überschreiben von tostring / equals / hashcode - Plugin für Eclipse - ausführbare Datei als JAR ausführen - lombok.jar in den Project ClassPath einbinden import public class Konto { private String nr; private String name; private Float saldo; Lombok Annotations @SneakyThrows Verwendung generiert getter und setter Methoden der verwendeten Attributen generiert entsprechende tostring Methode generiert equals und hashcode Methoden generiert Konstruktorenen Default Konstruktor ohne Argumente Konstruktoren für final / alle Attrbute generiert Artefakte für ein @Getter für alle für non-final Attribute, automatisches Ressourcenmanagment synchronisiert statische und Klassen-Methoden übergeht checked exceptions 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 16 >> total: 255 Seiten

17 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform 1.5 Build Tools wiki Erstellungsprozess oder Build-Prozess (von englisch to build bauen ) bezeichnet in der Programmierung rung einen Vorgang, durch den ein fertiges Anwendungsprogramm automatisch erzeugt wird. verbreitete Programme zur Durchführung von Erstellungsprozessen - Unix - make, CMake, Automake - Java - Apache Ant - Apache Maven - Buildroot -.Net - TFS (Team Foundation Server) Maven wiki Maven ist ein Build-Management Management-Tool der Apache Software Foundation und basiert auf Java.. Mit ihm kann man insbesondere e Java-Programme standardisiert erstellen und verwalten. Eigenschaften - bildet "Convention over Configuration" für gesamten Zyklus der Softwareerstellung ab - automatisiert die Prozesse der Entwicklung - Kompilieren - Testen - Packen - Deployen - definiert vorgegebene Standards - braucht wenige Konfigurationseinstellungen - vereinfacht Aufgaben des Build-Managements - bildet den Lebenszyklus eines Softwareprojekts ab 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 17 >> total: 255 Seiten

18 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform Maven Softwareentwicklung folgt einem vordefinierten Zyklus - validate Validieren - prüft ob die Projektstruktur gültig und vollständig ist - compile Kompilieren - kompiliert den Quellcode - test Testen - testet den kompilierten Code mit einem passenden Testframework (z.b. JUnit) - package Verpacken - der kompilierte Code wird mit nichtkompilierbaren Dateien zur Weitergabe verpackt (z.b. JAR) - integration-test Test der Integrationsmöglichkeit - Softwarepaket wird auf eine Umgebung (z.b. Server) geladen und seine Funktionsfähigkeit geprüft - verify Gültigkeitsprüfung des Software-Pakets - prüfen ob das Softwarepaket eine gültige Struktur und bestimmte Qualitätskriterien erfüllt - install Installieren im lokalen Maven-Repository - installiert das Softwarepaket in dem lokalen Maven-Repository (z.b. für modulare Projekte) - deploy Installieren im entfernten Maven-Repository - installiert das Softwarepaket auf einem entfernten Maven-Repository (Wiederverwendbarkeit) Konfigurationsdatei - als XML-Datei mit dem Dateinamen pom.xml (für Project Object Model) - enthält alle Informationen zum Softwareprojekt - standardisiertes Format / Dateistruktur - Abhängigkeiten - Informationen für Plugins - Produkteinformationen - aktuelle Version Beispiel - Abhängigkeiten von JUnit Framework laden <groupid>junit</groupid> <artifactid>junit</artifactid> <version>4.4</version> <scope>test</scope> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 18 >> total: 255 Seiten

19 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform konventioniertes Standard-Verzeichnisstruktur - vereinfacht die zentrale Konfigurationsdatei pom.xml - Softwareprojekt soll sich an folgende Struktur halten - src/main - Eingabedateien für Erstellung des eigentlichen Produkts - src/main/java - Java-Quelltext - src/main/resources - Dateien für die Übersetzung oder zur Laufzeit z.b. Properties-Dateien - src/test - Eingabedateien für automatisierte Testläufe - src/test/java - JUnit-Testfälle für automatisierte Tests - target/classes - kompilierte Java-Klassen Auflösung von Abhängigkeiten als zentrale Repositories - in der pom.xml werden Softwareabhängigkeiten angegeben - diese Abhängigkeiten werden aufgelöst - Maven ermittelt, ob die benötigten Dateien in einem lokalen Verzeichnis bereits vorhanden sind - oder Maven versucht, sich mit einem konfigurierten Maven-Repository im Intranet zu verbinden - oder Maven versucht, sich mit einem konfigurierten Maven-Repository im Internet zu verbinden - Abhängigkeiten werden in das lokale Repository kopiert - Bekannte öffentliche Maven-Repositories - Apache - Ibiblio - Codehouse - Java.Net - Firmenweite Maven-Repositories stellen Bibliotheken und Frameworks zur Verfügung - Archiva, Artifactory, Proximity - Codehaus Maven Proxy - Dead Simple Maven Proxy 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 19 >> total: 255 Seiten

20 EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform B Verteilte Systeme Lerninhalte Eigenschaften Technologien - Corba - DCOM -.NET - EJB 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 20 >> total: 255 Seiten

21 EJB 3.1 / JPA 2.0 >> Java Framework >> Verteilte Systeme 2 Verteilte Systeme - auf mehreren Prozessen verteilt - kommunizieren mittels Nachrichtenaustausch Eigenschaften - gemeinsame Nutzung von Ressourcen - zuverlässige und konstante Zugriffszeit - Offenheit - Erweiterbarkeit des Systems (Hardware, Software) - Standardisierung von Schnittstellen - Interprozesskommunikation heterogene HW- und SW- Komponenten - Skalierbarkeit - ohne Änderungen der System- oder Anwendungssoftware - Fehlertoleranz - Hardwareredundanz - Softwareredundanz 2.1 Technologien für Verteilte Systeme CORBA Common Object Request Broker Architecture - plattform- und sprachunabhängig - nur "basic distribution" DCOM Distributed Component Object Model - Dienste zur Kommunikation zwischen Prozessen - Microsoft - CORBA-DCOM Bridge 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 21 >> total: 255 Seiten

22 EJB 3.1 / JPA 2.0 >> Java Framework >> Verteilte Systeme.NET Microsoft - sprach- und (plattform-) unabhängig - löst Component Object Model ab - fokussiert auf Client (Services) - auch PDA (Personal Digital Assistant) - seit Januar 2008 OpenSource - CLR ist die Laufzeitumgebung - CLR = Common Language Runtime - Interpreter für den standardisierten Zwischencode - CLI ist der Zwischencode - CLI = Common Intermediate Language EJB Enterprise Java Beans - nur JAVA - entwickelt für Geschäftsprozesse - keine Systemroutinen - integrierte Verbindungslogik - verteilt = unterschiedlicher VM's - standardisierte Komponenten - erlauben transparente Entwicklung - vereinfachte Entwicklung - Sicherheit - rollenbasierter Zugriff auf Methodenebene - Transaktionen - durch Container verwaltet - Kommunikation - synchron / asynchron 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 22 >> total: 255 Seiten

23 EJB 3.1 / JPA 2.0 >> Java Framework >> Verteilte Systeme C Java EE Lerninhalte Plattform Spezifikation Architektur Einsatzgebiete Komponenten 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 23 >> total: 255 Seiten

24 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform 3 Java EE Plattform Spezifikation - JEE ist die Spezifikation einer Softwarearchitektur - JEE bezeichnet ein Applikationsframework, ausgelegt auf - Performance - Skalierbarkeit - Plattformunabhängigkeit Eigenschaften - sauber implementierte Trennung zwischen Tiers - dadurch weitgehende Unabhängigkeit 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 24 >> total: 255 Seiten

25 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform 3.1 Application Server wiki Ein Anwendungsserver ist ein Server in einem Computernetzwerk,, auf dem Anwendungs- programme ausgeführt werden. Im engeren Sinne bezeichnet der Begriff eine Software,, die spezielle Dienste zur Verfügung stellt, wie beispielsweise Transaktionen, Authentifi fizierung oder den Zugriff auf Verzeichnisdienste und Datenbanken über definierte Schnittstellen. JEE Anwendungserver beinhaltet - Components - Applets, Servlets, Enterprise Java Beans - Containers - Web Browsers, Servlet Engines, EJB Containers - Resources - SQL Datenquellen, Nachrichtensysteme, Mailsysteme 3.2 History History der Java Enterprise Edition SOA Java EE 6 Web Services Java EE 5 JPE Project Java Plattform for the Enterprise J2EE 1.2 Servlet /JSP EJB 1.0 JMS 1.1 JTA 1.0 JAAS 1.0 JNDI RMI/IIOP Robustheit J2EE 1.4 J2EE 1.3 EJB 2.0 EJB 2.1 JSS 2.4 JSP 2.0 WS 1.0 JavaMail 1.2 JAXP 1.2 JCA 1.5 EJB 3.0 JPA 1.0 JSS 2.5 JSP 2.1 JSF 1.2 WS 1.2 JavaMail 1.4 JAXB 2.0 JAXP 1.3 JAX-WS 2.0 StAX 1.0 JSTL 1.2 EJB 3.1 JPA 2.0 JSS 3.0 JSF 2.0 Bean Validation / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 25 >> total: 255 Seiten

26 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform 3.3 Features - EJB Enterprise Java Beans - beinhalten die Geschäftslogik einer Enterprise Anwendung - gestatten Zugriff auf persistente Daten - die Beans laufen in einem EJB-Container - Session-Beans, implementieren die Geschäftslogik und sind meistens vom Client zugreifbar - Message-Driven-Beans, für die Verarbeitung von JMS-Nachrichten - Entity-Beans für die Abbildung von persistenten Datenobjekten - JSS Java Servlet API - Erweiterung von Servern, deren Protokoll auf Anfragen und Antworten basiert - JSP JavaServer Pages - Textdokumente, bestehen aus statischem Text und dynamischen Textelementen - WS Web Services - definieren Schnittstellen zu EJBs, die durch den URI eindeutig identifizierbar sind - JNDI Java Naming and Directory Interface - gemeinsame Schnittstelle mit der Klassen auf Namens- und Verzeichnisdienste zugreifen können - JMS Java Message Service - ist API für die asynchrone Nachrichtenverarbeitung - JTA Java Transaction API - erlaubt der Anwendung die Steuerung der Transaktionsverwaltung - ist die Java-Schnittstelle zu Transaktionsmonitoren, z.b. Java Transaction Service (JTS) - JAAS Java Authentication and Authorization Service - eine Java-API um Dienste zur Authentifikation und Zugriffsrechte bereitzustellen - implementiert ein Standard-"Pluggable Authentication Module" (PAM) - JavaMail JavaMail - erlaubt den Zugriff auf Mail Services, wie z.b. SMTP, POP3, IMAP oder NNTP - JAXB Java Architecture for XML Binding - ermöglicht es, ein XML-Schema direkt an Java-Klassen zu binden - JAXP Java API for XML Processing - hilft bei der Bearbeitung von XML-Dokumenten - JAX-RPC Java API for XML-Based Remote Procedure Calls - ermöglicht den entfernten Zugriff auf RPC-Dienste - JACC Java Authorization Contract for Containers - definiert diverse Sicherheitsrichtlinien für die diversen Java-EE-Container - JCA J2EE Connector Architecture - dient dazu, andere Systeme transparent zu integrieren 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 26 >> total: 255 Seiten

27 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform - JAF JavaBeans Activation Framework - bietet die Möglichkeit, verschiedene Daten anhand des MIME-Headers zu erkennen - JAX-WS Java API for XML Web Services - hilft bei der Erstellung von Web Services und zugehörigen Clients, die über XML kommunizieren, z. B. über SOAP - JPA Java Persistence API - stellt eine einheitliche und datenbankunabhängige Schnittstelle für Object-Relational-Mapping und das Arbeiten mit Entitäten bereit - StAX Streaming API for XML - cursor-basierte XML-Verarbeitung in Ergänzung der DOM- und SAX-Parser - JSF Java Server Faces - Mit Hilfe von JSF kann der Entwickler auf einfache Art und Weise Komponenten für Benutzerschnittstellen in Webseiten einbinden und die Navigation definieren - JSTL JavaServer Pages Standard Tag Library - Sammlung von JSP-Tags für die Strukturierung, XML, SQL, Internationalisierung usw. Deployment Deskriptoren wiki Ein Deployment Descriptor (frei übersetzt "Einsatzbeschreibung") ist eine Konfigurationsdatei im Format XML.. Im Umfeld der Java Platform, Enterprise Edition,, beschreibt diese Konfigurationsdatei den spezifischen Bereitstellungsprozess (englisch deployment) ) und dazu benötigte Informationen. - sind eine der Stärken von JEE - jedoch nur durch Tools sinnvoll einsetzbar IDE, Xdoclet, etc. - Grundlage durch JEE Rollenverständnis - Component Developer - Assembler - Deployer - dynamisches Verhalten der Komponenten - Applikationserver muss nicht neu gestartet werden - Komponente muss nicht neu deployed werden - schnell grosse Komplexität - ist oft Migrationshindernis 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 27 >> total: 255 Seiten

28 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform 3.4 Einsatzgebiete In den folgenden Gebieten finden JEE Applikationen ihren Schwerpunkt: - Datenbankzugriff - Trennen der Anwnderschwerpunkte - dynamische Internetseiten - Bereitstellen der Logikkomponenten - Enterprise JavaBeans - als fachliche Domänenklassen - Middle-Tier Server - als feingranulare Architektur - plattformenabhängige Kommunikation - durch definierte Protokolle - Sicherheit - durch übergeordnete Architekturlayer 3.5 Architektur - Komponenten sind funktionelle Einheiten - werden zu einer Komponenten-Architektur zusammengefasst Die folgenden Core Technologien dominieren: - JNDI (Java Naming and Directory Interface) - Zugriff auf "naming" und "directory" Systeme wie LDAP, DNS, etc. - JTA (Java Transaktion API) - Zugriff auf Transaction Systeme wie BEA Tuxedo, etc. - JDBC (Java DataBase Connectivity) - Zugriff zu relationalen Datenbanken - JMS (Java Messaging Service ) - Zugriff zu Message Orientated Middleware, z.b. ibus,ibm MQSeries Tuxedo JTA ORACLE DB2 JDBC JEE JMS MQSeries ibus JNDI DNS LDAP COS 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 28 >> total: 255 Seiten

29 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform 3.6 Konventionen wiki Eine Konvention (lat. conventio Übereinkunft, Zusammenkunft ) ist eine nicht formal festgeschriebene Regel, die von einer Gruppe von Menschen aufgrund eines Konsens eingehalten wird. - Namenskonventionen seit JSR 220 nicht mehr so dominant - orientieren sich am Namensmodell von SUN Ansatz basierend auf dem HelloWorld EJB EJB Namens Konvention Item Syntax Beispiel Enterprise Bean Name (DD) <name>bean HelloWorldBean EJB JAR Display Name (DD) <name>jar HelloWorldJAR Enterprise Bean Class <name>bean HelloWorldBean Business Interface <name> HelloWorld Remote Interface <name>remote HelloWorldRemote Local Interface <name>local HelloWorldLocal Abstract Schema (DD) <name> HelloWorld 3.7 Komponenten funktionierende Software Einheit wiki Eine Software-Komponente ist ein Software-Element, das konform zu einem Komponentenmodell ist und gemäss einem Composition-Standard ohne Änderungen mit anderen Komponenten verknüpft und ausgeführt werden kann. - eine Komponenten ist eine funktionierende Software Einheit - über einen JEE-Server Clients zur Verfügung gestellt Bestandteile - als *.ear Datei (enterprise archive) gepackt - Enterprise Beans *.jar Datei (java archive) - eine oder mehrere Enterprise Beans - WEB-Anwendungen *.war Datei (web application archive) - HTML-Seiten, Servlets, JSP, Bilder - Client-Anwendungen *.jar Datei (java archive) - Stand-Alone Java Applikation - Deployment Descriptors *.xml, optionale für jede Komponente - XML-Dokumente zur Integrationsbeschreibung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 29 >> total: 255 Seiten

30 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform 3.8 Enterprise Archive - folgt standardisierter Struktur - ermöglicht dem Applikationsserver das Entpacken der Komponenten - erlaubt das Deployen der JEE Applikation - in einem EAR-Archiv Java SE - EJBs sind in einem WAR deployed - als JAR-Archive - in WEB-INF/classes 3.9 Verteilte Multi-Tier Applikationen - das Verteilen der Applikation definiert der SoC (Separation of Concerns) Aspekt der OOA (Object-Orientated Analysis) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 30 >> total: 255 Seiten

31 EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform D EJB Lerninhalte Definition Architektur Typen Bestandteile (Entwicklungs-)Szenarien (Entwicklungs-)Rollen Zugriff Kommunikationsmodell 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 31 >> total: 255 Seiten

32 EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans 4 Enterprise JavaBeans EJBs sind als Komponenten konzipiert: - wiederverwendbar - verteilt einsetzbar - lose gekoppelt SoC (Separation of Concerns) ermöglicht: - Trennung der Anwendung (Geschäftslogik) - Bedienerführung (Darstellungslogik) - Datenerhaltung (Persistenz) EJB Technologie definiert: - Interfaces - Patterns - Richtlinien für Komponenten-orientierte, verteilte Systeme. 4.1 Definition Development, Distribution and Deployment of Java-Based Server-Side Software Components Entwicklung, Verteilung und Umsetzung (von Modellen) Militär: Truppenbereitstellung / Installation Java basierten serverseitigen Software Komponenten 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 32 >> total: 255 Seiten

33 EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans EJB Komponente - definiert Funktionalität - Black Box - Zugriff nur über Schnittstelle - Wiederverwendbarkeit EJB Ziele - Entwicklung von Geschäftsprozessen - keine Systemprozesse - Standard für Komponenten-basierte Entwicklung - Wiederverwendbarkeit POJO Plain old Java Object wiki POJO ist eine Abkürzung für Plain Old Java J Object, also ein ganz normales Objekt in der Programmiersprache Java. - ist ein Java-Objekt ohne Einschränkungen - bis auf die der Java Language Specification - ein POJO sollte keine - vorspezifizierte Klasse erweitern - z. B. public class Foo extends javax.servlet.http.httpservlet - vorspezifiziertes Interface implementieren - wie z. B. public class Bar implements javax.ejb.entitybean - vorspezifizierte Annotation enthalten - wie z. public class Person Beispiel - Klasse Person 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 33 >> total: 255 Seiten

34 EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans seit Version 3 ist das EJB ein POJO JPA Query Language Dependency Injection Transactions Bean Ressourcen Annotaions Stateless - Entity Bean Stateful - Session Bean O / R Mapping Message Driven Bean POJO Plain Old Java Object Remote Invocation JDBC JNDI JTA Container Ressourcen Bean Container 4.2 Architektur - Applikationsserver definiert Lebensraum für Anwendungsprogramme Container - bietet Kommunikationsschittstelle - RMI - SOAP WebService - stellt Dienste zur Verfügung - Transaktionsunterstützung - Verteilung - Replikation - Namensdienste - Datenbankanbindung - Sicherheitsdienste EJBs existieren innerhalb von Container 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 34 >> total: 255 Seiten

35 EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans 4.3 Typen - Session Bean - SLSB Stateless Session Bean zustandslose Multitask / Multithread Komponente - SFSB Statefull Session Bean Client Session im verteilten Multi-User Umfeld - Singleton Bean - unique Instanz einer EJB innerhalb der Anwendung - Message Driven Bean - asynchrone Komponente im verteilten Multi-User Umfeld - Entity Bean - modelliert persistente Daten Eigenschaften Session Bean Singleton Message Driven Bean Entity Bean Zweck Stellt einen Prozess für einen Client dar, z.b. Geldautomat Stellt einen uniquen Prozess zur Verfügung. Stellt einen Nachrichtenempfänger dar. Stellt Daten dar. Entitäten oder Objekte im persistenten Speicher (DB) Ausprägung Stateless Session Bean Stateful SessionBean Singleton Message Driven Bean Entity Bean Gemeinsame Nutzung Stateful Session Bean dedizierte Client Zuordnung Stateless Session Bean hat keine Client Zuordnung Singleton hat keine Client Zuordnung, jedoch eine unique Zuordnung in der Applikation keine direkte Clientzuordnung, "horcht" auf einen JMS-Kanal Gemeinsame Nutzung durch mehrere Clients möglich Persistenz Transient Lebenszyklus typischerweise durch Clientprozess bestimmt Transient Lebenszyklus typischerweise durch Clientprozess bestimmt Transient "stirbt" bei Container Terminisierung Persistent Zustand bleibt im persistenten Speicher (DB) auch nach Container Terminierung erhalten 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 35 >> total: 255 Seiten

36 EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans 4.4 Bestandteile - Bean Implementierung - definiert und implementiert alle Methoden, die in den Interfaces deklariert sind - Local Interfcae - definiert Zugriff (Interface) für einen lokalen Client (EJB im Container) - Remote Interface - definiert Zugriff (Business Interface), für einen remote Client - Web-Service Interface - definiert Zugriff als Web Service Deployment Descriptor - XML Datei zur Beschreibung der Komponente - Dateiangaben - Pfadangaben - Datenbankverbindungen - Verhalten - Zugriffskontrolle - Transaktionsverhalten Java ARchive (Datei mit der Endung.jar) Local Interface Remote (Business) Interface Bean Implementation Deployment Descriptor 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 36 >> total: 255 Seiten

37 EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World 5 Hello EJB3 World Aufbau, Installieren und Betreiben einer JEE Applikation. 5.1 Voraussetzungen - JSDK: Java Software Development Kit (min. Version 1.5) JEE Application Server Sun GlassFish - JBoss - OpenJPA - Geronimo - Resign - Entwicklingsumgebung - Eclipse - NetBeans - BlueJ Open Source - Apache Geronimo - Glassfish Referenzimplementierung - JBoss Application Server Closed Source - WebShere - Oracle Application Server - WebLogic - SAP NetWeaver Application Server 5.2 Organisation - /ejbmodule - /server - Source der Middle Tier EJB - /META-INF - Deployment Descriptor ejb-jar.xml - /properties - Eigenschaftsdateien - /test - /junit - Remote Unit-Test - /remote - Remote Application-Client Umgebungsvariablen - Systemvariablen definieren / ergänzen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 37 >> total: 255 Seiten

38 EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World 5.3 Ziel HelloWorld.jar 1. - META-INF - MANIFEST.MF - ejb-jar.xml -server - HelloWorld.class - HelloWorldBean.class JEE Application Server Plattform TestHelloWorldBean HelloWorldBean.class 2. HelloWorld.jar 3. deployen en Hello EJB World Java Source Dateien - das Remote (Business) Interface HelloWorld.java - im Verzeichnis <workspace>\helloworld\ejbmodule\server package server; import public interface HelloWorld { public String echo(string echo); - die Enterprise BEAN Klasse HelloWorldBean.java - im Verzeichnis <workspace>\helloworld\ejbmodule\server package server; import public class HelloWorldBean implements HelloWorld public String echo(string echo) { return "Server Echo : " + echo; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 38 >> total: 255 Seiten

39 EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World - die Client Applikations-Klasse HelloWorldBeanClient.java - im Verzeichnis <workspace>\helloworld\test\remote package remote; import javax.naming.context; import javax.naming.initialcontext; import javax.naming.namingexception; import javax.rmi.portableremoteobject; import server.helloworld; public class HelloWorldBeanClient { public static void main(string[] args) { try { HelloWorld hello = null; Context ctx = new InitialContext(); Object o = ctx.lookup("helloworldbean/remote"); hello = (HelloWorld) PortableRemoteObject.narrow(o,HelloWorld.class); System.out.println(hello.echo("Hello EJB3 World")); catch (NamingException e) { e.printstacktrace(); Bekanntmachen der Serveradresse - als VM Argumente Abhängigkeit durch Entwicklungsumgebung - Eclispe - Run Configurations... - als Systemparameter Abhängigkeit durch Sourcecode System.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory"); System.setProperty("java.naming.provider.url","jnp://localhost:1099"); - den InitialContext parametrisieren Abhängigkeit durch Sourcecode Properties properties = new Properties(); properties.setproperty( Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.namingcontextfactory"); properties.setproperty( Context.PROVIDER_URL, "jnp://localhost:1099"); initialcontext = new InitialContext(properties); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 39 >> total: 255 Seiten

40 EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World - als Property-Datei laden Datei lesen ist teuer (zeitaufwändig) Properties properties = new Properties(); File jndipropertyfile= new File("properties/jndi.properties"); properties.load(new FileInputStream(jndiPropertyFile)); - als Property Datei im ClassPath lose gekoppelt sinnvoll - java.naming.factory.initial - Initialisierungsklasse der Factory für den Namensdienst / JNDI Treiber - java.naming.factory.url.pkgs - Package, in dem sich die Init-Klassen befinden - java.naming.provider.url - Adresse des JNDI-Servers properties/jndi.properties java.naming.factory.initial=org.jnp.interfaces.namingcontextfactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces java.naming.provider.url=localhost:1099 Aufgabe Remote Zugriff - testen Sie die verschiedenen Strategien zum Laden der Server-Properties Aufgabe Proxy Object - Geben Sie die Klasse und das Interface des Proxy aus // zeigt Klassen und Interfaces System.out.println("CLASS > " + o.getclass().getname()); Class[] interfaces = o.getclass().getinterfaces(); for (int i = 0; i < interfaces.length; ++i) { System.out.println("implements > " + interfaces[i].getname()); - Testen Sie alternative Instazierungen des Proxyobjekt // Instanziierung des Business Interface durch ProxyObject hello = (HelloWorld) o; // Instanziierung des Business Interface durch NamingContext hello = (HelloWorld) ctx.lookup(o.getclass().getname()); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 40 >> total: 255 Seiten

41 EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World Aufgabe JNDI - Prüfen Sie die registrierten Nameneinträge des JNDI service=jndiview Deployment Descriptor ejb-jar.xml jar.xml - als Alternative zu Annotationen - Datei <workspace>\helloworld\ejbmodule\meta-inf\ejb-jar.xml <?xml version="1.0" encoding="utf-8"?> <javaee:ejb-jar version="3.1" xmlns:javaee=" xmlns:xml=" xmlns:xsi=" xsi:schemalocation=" "> <javaee:enterprise-beans> <javaee:session> <javaee:ejb-name>helloworldbean</javaee:ejb-name> <javaee:business-remote>server.helloworld</javaee:business-remote> <javaee:ejb-class>server.helloworldbean</javaee:ejb-class> <javaee:session-type>stateless</javaee:session-type> </javaee:session> </javaee:enterprise-beans> </javaee:ejb-jar> Deployment nt-descriptor überschreibt Annotationen tationen! 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 41 >> total: 255 Seiten

42 EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World Aufgabe ejb-jar.xml jar.xml - testen Sie das HelloWorldBean mit einem ejb-jar.xml Deploymentdescriptor - überschreiben Sie den JNDI Namen durch eine JBoss propretäre XML Datei - Datei <workspace>\helloworld\ejbmodule\meta-inf\jboss.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.0//EN" " <jboss> <enterprise-beans> <session> <ejb-name>helloworldbean</ejb-name> <jndi-name>ejb/hello/remote</jndi-name> </session> </enterprise-beans> </jboss> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 42 >> total: 255 Seiten

43 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 6 Inside EJB3 - Elemente der EJB-Architektur Zusammenspiel der fachlichen Komponeneten - Szenarien und Rollen Entwickeln und Bereitstellen der fachlichen Komponenten 6.1 Elemente der EJB-Architektur Die wichtigsten Elemente und ihre wesentlichsten Aufgaben: Java EE Server - Gewährleistung von - Skalierbarkeit - Verfügbarkeit - Verbindungs-Management - Lastausgleich - Fehler-Management - Thread- und Prozessmanagement - Unterstützung von Clustering - Integration von Middleware Diensten - Verwalten von System Ressourcen Aufgaben des EJB Container - stellt die deployten Komponenten zur Verfügung - definiert Laufzeitumgebung - standardisierter Zugang zu den Services JTA, JPA, JNDI, JMS, etc. - Instanzen Verwaltung Session Management - life cycle management auch pooling - Ausführen von Callback Methoden - Aufrufen von Interceptoren Klassen / Methoden - Remote Zugriff - unterstützt Rechner- und Prozessübergreifende Komponentenaufrufe - für standardisierte Protokolle - Sicherheit - Authorisierung von Komponentenzugriffen - deklarativ - rollenbasiert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 43 >> total: 255 Seiten

44 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 - Persistenz - JDBC Anbindung - Java Persistence API - Transaktionen - 2PC Two Phase Commit - distributet Transactions - CMT Container Managed Transaction - BMT Bean Managed Transaction - Namens- und Verzeichnisdienst - JNDI (Java Naming and Directory Interface) - Environment- und Komponenten Information - durch lokales Verzeichnis - Messaging - JMS-API (Java Message Service) - asynchroner Nachrichtenaustausch Enterprise Beans - Server Komponenten - kapseln die Geschäftslogik Ausprägungen - Session Beans - Abbildung der Use Cases - beinhalten Logik - definieren Workflow - Message Driven Beans - verarbeiten asynchron empfangene Nachrichten - Entity Beans - definieren persistente Objekte der JPA - Java Persistence API 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 44 >> total: 255 Seiten

45 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB Deployment Descriptor - ist eine XML (extensible Markup Language) Datei - beschreibt die Deploymenteigenschaften - beeinflusst die Entwicklungslevel (Rollen) Deployment Descriptor Beschreibungskriterien - wie das Bean installiert werden muss - das Deployment (Installieren / Bereitstellen) - die EJB Implementation / Interfaces - Verbindungen zu anderen Quellen - EJB - DB - die Umgebung des Beans - lose gekoppelt - konfigurierbar - Transaktionsvariablen Transactions Attributes - Sicherheitsvariablen Access Control Lists 6.2 Szenarien und Rollen - Client-Szenarien Zugriff auf die fachlichen Komponeneten - Entwickler-Szenarien Bereitstellen der fachlichen Komponeneten Clients - EJBs - transparent - thin - browser basiert - fat - Java -.NET - CORBA - unabhängig - protokolliert - z.b. Webservice, REST, etc / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 45 >> total: 255 Seiten

46 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB Rollen - mögliche Szenarien streben nach - Trennung der verschiedenen Schichten - Robustheit - parallele Entwicklungsprozesse - resultiert in Rollen durch Aufgabenteilung - EJB Provider - besitzt Wissen im Anwendungsbereich - entwickelt die Bean Komponenten - Application Assembler - verbindet die EJB Komponenten zu einer konkreten Anwendung - EJB Deployer - installiert die Applikation (Deployment Unit) in den EJB Container - Server / Container Provider - Hersteller eines JEE Servers, z.b. Sun, BEA, IBM, Borland, JBoss, etc.) - Container Provider stellt die Laufzeitumgebung für EJBs zur Verfügung - Systemadministrator - administriert Gesamtsystem, OS, JEE-Server, etc / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 46 >> total: 255 Seiten

47 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 6.3 Zugriff auf ein EJB - EJBs erlaubten den Remote Zugriff mit Hilfe von zwei Java-EE-Technologien - JNDI, Zugriff auf einen Namens- und Verzeichnisdienst - RMI-IIOP, Protokoll für den entfernten Methodenaufruf - Client Zugriff - Funktionalität von EJBs ist über öffentlichen Methoden des Business Interfaces zugänglich - als Proxy Objekt (Business Interface Referenz) - als Stub für den Remote Client Ablauf - Client ermittelt zunächst per JNDI eine Referenz auf das Business Interface - Referenz wird beim Deployment im Verzeichnisdienst (JNDI) registriert // instantiates Connection to JNDI Service InitialContext ctx = new InitialContext(ProtocolParameter); // lookup returns Proxy Reference of Business Interface Object o = ctx.lookup("helloworld/helloworldbean/remote"); - Cast der Proxyreferenz konvertiert zum Business Interface HelloWorld hello = null; // casts Proxy-Object to Business Interface hello = (HelloWorld) o; - Alternative - statischen Methode narrow konvertiert Proxy-Referenz typsicher zum Business Interface // Typecasting due to RMI over IIOP hello = (HelloWorld) PortableRemoteObject.narrow(o,HelloWorld.class); - Alternative - Zugriff auf das Business Interface durch Refaktorisierung des Proxyobjekts // Refactoring of Naming Context hello = (HelloWorld) ctx.lookup(o.getclass().getname()); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 47 >> total: 255 Seiten

48 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB Zugriff zum EJB über das Proxy - serverseitig wird ein Proxy Objekt erzeut - als Stellvertreterrolle für den anfragenden Client - lokale und remote Zugriffe sind identisch // access to server-side business logic (EJB) hello.echo("hello EJB3 World"); Eigenschaften - Fachlogik ist gekapselt, d.h. veborgen encapsulation - Business Methoden lassen sich nur über die erzeugte Objektinstanz aufrufen - Container fängt die Aufrufe an das Business Object auf und leitet diese weiter - Interception Abfangen, Unterbrechen - kontrollieren der Aufrufe - Vor- und Nachbearbeitung der Aufrufe Sicherheit, Transaktionen, Persistenz EJB Remote Procedure Call 5. Interception und Weiterleiten 4. Instanziierung 3. Remote Aufruf Business Interface obj EJB Instanz Enterprise Java Beans Client 2. Referenz auf Proxy obj JNDI obj erzeugte Referenz in Namensdienst Deployment EJB - Container 1. Anfrage nach Referenz 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 48 >> total: 255 Seiten

49 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB Sequenz Diagramm wiki Ein Sequenzdiagramm (engl. sequence diagram) ) ist eine der 14 Diagrammarten in der Unified Modeling Language (UML), einer Modellierungssprache für Software und andere Systeme. Das Sequenzdiagramm ist ein Verhaltensdiagramm,, genauer eines der vier Interaktionsdiagramme. Es zeigt eine bestimmte Sicht auf die dynamischen Aspekte des modellierten Systems. Ein Sequenzdiagramm ist eine grafische Darstellung einer Interaktion und beschreibt den Austausch von Nachrichten zwischen Ausprägungen mittels Lebenslinien RMI (Remote Method Invocation) - Remote Method Invocation Aufruf entfernter Methoden - ist Aufruf einer Methode eines entfernten Java-Objekts - "entfernt" bedeutet Objekt ist in einer anderen VM virtuellen Maschine - realisiert die Java-eigene Art eines RPC Remote Procedure Call - Aufruf für das aufrufende Objekt ist wie ein lokaler Aufruf - besondere Ausnahmen abfangen NamingException - wie Verbindungsabbruch - Server nicht erreichbar - clientseitig ist der Stub für den Netzwerktransport zuständig - eine mit dem RMI-Compiler rmic erzeugte Klasse - Stub muss lokal oder über das Netz verfügbar sein 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 49 >> total: 255 Seiten

50 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 oder - entfernte Objekte werden durch entferntes Objekt bereitgestellt - erste Verbindungsaufnahme benötigt Adresse des Servers und Bezeichners (RMI-URL) - Namensdienst auf dem Server liefert eine Referenz auf das entfernte Objekt - das entfernte Objekt im Server muss sich unter diesem Namen registriert sein - RMI-Namensdienst wird über statische Methoden der Klasse java.rmi.naming angesprochen - Namensdienst ist als eigenständiges Programm implementiert und wird RMI Registry genannt rmi://[host][:port][/[object]] Kommunikationsprotokoll - RMI bezeichnet Kommunikationsprotokoll für entfernte Aufrufe zwischen Java-Objekten - RMI bezeichnet eine Java-Standard-Klassenbibliothek als Teil der JSE - für RMI sind zwei Ports reserviert - Port 1099 ist für die RMI-Registry reserviert, also den Namensdienst - Port 1098 für den Activator reserviert - IIOP (Internet Inter ORB Protokoll) als alternatives Kommunikationsprotokoll - viele JEE Server Implementationen arbeiten mit RMI over IIOP RMI Kommunikationsmodell - der Server registriert ein Remote Object bei der RMI-Registry unter einem eindeutigen Namen - der Client schaut bei der RMI-Registry unter diesem Namen nach und bekommt eine Objektreferenz, die seinem Remote Interface entspricht - der Client ruft eine Methode aus der Objektreferenz auf (dass diese Methode existiert, wird durch das Remote Interface garantiert) - der Server gibt dem Client die Rückgabewerte dieses Aufrufes, oder der Client bekommt eine Fehlermeldung (z. B. bei einem Verbindungsabbruch) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 50 >> total: 255 Seiten

51 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 RMI Ablauf 1. Client fordert mittels einer URL und der lookup-methode eine Referenz vom Naming Service an 2. Proxy-Referenz wird zurückgeliefert und der Stub-Code vom RMI-Server heruntergeladen 3. Client ruft eine Methode mittels der Proxy Referenz auf 4. Verpacken (Marshalling) des Aufrufs im Stub und übertragen an den RMI-Server 5. Unmarshalling der Anfrage vom Client im Skeleton auf dem Server Verarbeitung auf dem Server 6. Ergebnisse von der Server-Applikation an den Skeleton senden 7. Marshalling des Ergebnisses im Skeleton und senden an den Client 8. Unmarshalling des Ergebnisses im Stub auf dem Client Aufgabe RMI - erstellen und testen Sie eine RMI Client Server "Hallo Welt" - Remote Interface public interface Hello extends Remote { String sayhello() throws RemoteException; - Server Rmi-Registry starten mit: <path to jdk>\bin>start rmiregistry Server obj = new Server(); Hello stub = (Hello) UnicastRemoteObject.exportObject(obj, 0); // Bind the remote object's stub in the registry Registry registry = LocateRegistry.getRegistry(); registry.bind("hello", stub); - Client Registry registry = LocateRegistry.getRegistry(host); Hello stub = (Hello) registry.lookup("hello"); String response = stub.sayhello(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 51 >> total: 255 Seiten

52 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 6.4 EJB Kommunikationsmodelle An Prozesse beteiligte EJBs kommunizieren: - synchron, entfernt - synchron, lokal - asynchron, nachrichtenbasiert synchrone, entfernte Kommunikation - Aufrufe erfolgen als synchrone Methodenaufrufe - mittels RMI-IIOP in einem verteilten System - Übertragung der Daten erfolgt mittels "by-value" Semantik - als Kopie der Originaldaten - Parameter werden vom Client auf den Server kopiert Ablauf 1. EJB-Container erzeugt Proxy Object des Business Interface 2. EJB-Container registriert Proxy Object beim Namensdienst 3. Client fordert vom Namensdienst Referenz auf Proxy Object 4. Namensdienst liefert Referenz auf das Proxy Object 5. Client ruft über das Proxy Object die Geschäftsmethoden der EJB auf 6. Proxy Object delegiert Methodenaufruf an die EJB-Instanz 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 52 >> total: 255 Seiten

53 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB synchrone, lokale Kommunikation - Aufrufe von Diensten einer EJB-Komponente sind synchrone Methodenaufrufe - die Übertragung der Daten erfolgt mittels "by-referenz" Semantik - als Referenz der Originaldaten - Parameter werden als Referenz auf die Originaldaten vom Client auf den Server übergeben Ablauf 1. EJB-Container erzeugt Proxy Object des Business Interface 2. EJB-Container registriert Proxy Object beim Namensdienst 3. Client fordert vom Namensdienst Referenz auf Proxy Object 4. Namensdienst liefert Referenz auf das Proxy Object 5. Client ruft über das Proxy Object die Geschäftsmethoden der EJB auf 6. Proxy Object delegiert Methodenaufruf an die EJB-Instanz asynchron, nachrichtenbasierte Kommunikation - Schnittstelle zwischen objektorientierten und nicht-objektorientierten Prozessen in verteilten Systemen Ablauf: 1. Applikationsserver registriert Nachrichtenempfänger beim Namensdienst 2. EJB-Container registriert sich als Listener für Nachrichten 3. Client fordert vom Namensdienst Referenz des Nachrichtenempfängers 4. Namensdienst liefert Referenz auf Nachrichtenempfänger 5. Client sendet Nachrichten an Nachrichtenempfänger 6. Nachrichtenempfänger übermittelt Listener eingegangene Nachricht 7. Listener delegiert Nachricht an Bean-Instanz 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 53 >> total: 255 Seiten

54 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB Überblick über die Kommunikationsmodelle die folgende Tabelle weist die Aufrufmodelle den verschiedenen EJB-Typen zu Kommunikationsmodel EJB Typen synchron entfernt synchron lokal Stateless Session Bean Stateful Session Bean Message Driven Bean Entity Bean asynchrony achrichtenbasiert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 54 >> total: 255 Seiten

55 EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3 E Testen Lerninhalte Testarten TDD TestDrivenDevelopment Unit Testing Mock Testing Integrationstests 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 55 >> total: 255 Seiten

56 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen 7 Testen wiki Ein Softwaretest ist ein Test während der Softwareentwicklung,, um die Funktionalität einer Software an den Anforderungen und ihre Qualität zu messen und Softwarefehler zu ermitteln. 7.1 Testarten - Unit-Test - Units sind einzelne Objekte - isoliertes Verhalten wird getestet - Integrationstest - mehrere Objekte bilden ein Workflow - deren Interaktion wird getestet - Lasttest - Skalierbarkeit des Workflows - grosse Anzahl von Requests wird getestet - Akzeptanztest - Anforderungen an die Applikation - Grundlage zur Abnahme Testverfahren die Praxis beschreibt eine Kombination von Testverfahren - ZIEL: aussagekräftiges Ergebnis - Review prüft das Ergebnis (Ziel) - Audit prüft die Vorgehensweise und den Ablauf (Weg ins Ziel) - Black-Box Box-Test prüft definierte Schnittstellen (Funktionalität) - White-Box-Test prüft die Details der Logik (Codereview) - Durchführung - Testprotokoll (wer, wozu, wie, was wird getestet) - Programm (Test-Case beschreibt Testfall) die Praxis verlangt Automatisierung der Testverfahren wiki Vor allem bei testgetriebener Entwicklung ist die Testautomatisierung besonders wichtig. Tests werden im Idealfall nach jeder Änderung ausgeführt. Bei nicht automatisierten Tests ist der Aufwand so gross, dass häufig auf die Tests verzichtet wird / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 56 >> total: 255 Seiten

57 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen 7.2 funktional vs. nicht-funktional funktionale Tests Benutzeranforderungen - gemäss Anforderungen - was macht das Programm - beschrieben durch Use Case nicht-funktionale Tests Qualitätsanforderungen - Integration - Zusammenarbeit der einzelnen Teile, z.b. Server, DB, etc. - Belastung - Multi-User Verhalten - Akzeptanz - Kunde, Benutzer, etc. Softwaretests steigern Qualität der Software extreme Programming - alternativer Ansatz - senkt Softwareentwicklungskosten - orientiert an Bedürfnissen der Kunden Der Kunde bekommt das, was er braucht, und dann, wenn er es braucht. - XP (extreme Programming) baut auf - Kommunikation Auftraggeber - Einfachheit klare Schnittstellen - Feedback Testen (TDD) - Courage "code a little, test a little" 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 57 >> total: 255 Seiten

58 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen 7.3 Test Driven Development TDD ist Aspekt von Extreme Programming - einfache Entwicklung in der Erstellung von Software - komplexe Softwaresysteme in kleinen und einfachen Schritten entstehen lassen - Tests des Designs und der Implementierung stehen im Vordergrund - definiert Test, der die Funktion eines kleinen Teils des Systems beschreibt - Treffen von Design-Entscheidungen sind nicht in der Startphase erforderlich - Code muss nicht von Anfang an richtig sein, dieser wird kontinuierlich refaktoriert - Ausführung mit Hilfe von (Software)-Tools - z.b: JUnit ( meist verbreitet - durch Assertion (Engl: Aussage, Behauptung) - asserts(), assertnotnull(), assertequals(), etc. // SYNTAX : Assertion < Assertion> ( <testen> <Kriterium> <gegeben> ) // Beispiel assert( == 3 ) gegeben : 3 Kriterium : EQUALS testen : TDD Konzept definiert Unittests und Refaktorierungen - erstellen (Logik schreiben) - Test beschreibt, wie sich ein kleiner Teil der Software (Unit) verhalten soll - testen (erfolgreiche Tests definieren) - Design des Codes ist zweitrangig - wichtig ist, dass der Test erfolgreich läuft - aufräumen (schönerer Code schreiben) - mittels Refaktorierung (Umorganisation) überarbeiten, bis der Test wieder fehlerfrei läuft 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 58 >> total: 255 Seiten

59 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen 7.4 JUnit wiki JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit- Tests einzelner Units (meist Klassen oder Methoden) ) geeignet ist. ist Framework - erlaubt Werte und Bedingungen zu testen, die erfüllt sein müssen - die Klasse Assert definiert eine Vielfalt von assert Methoden - unterstützt das Testen von Programmen - ein einfacher Test definiert public class BasicTest { public void setup() {... public void testfirstthing() { assert...(...); public void testsecondthing() { assert...(...); public void teardown() {... Aufbau - die Methode setup() initialisiert den Testcase - die Test-Methoden (Testcase) fangen mit test an - testfristthing() - testsecondthing() - die Methode teardown() finalisiert den TestCase - Assertions überprüfen die Test-Methoden - Erfüllen von Anforderungen - Einhalten von Bedingungen - Exceptions sollten nicht gefangen (catch) werden - Test-Methoden Exceptions soll Exception werfen - JUnit-Framework kann dann passend darauf reagieren - Ausführen von Tests - Testklasse in Eclipse ausführen Run As JUnit Test 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 59 >> total: 255 Seiten

60 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen JUnit Annotaions JUnit 4 - Testfunktionen werden als statische Methoden importiert import org.junit.test; import org.junit.before; import static org.junit.assert.assertequals; import static org.junit.assert.assertnotnull; import static org.junit.assert.asserttrue; public class TestHelloWorldBean = NamingException.class) public void noecho() throws NamingException {... JUnit 4 Annotaions kennzeichnet Methoden als ausführbare Testfälle markiert Setup-Aufgaben, die für jeden Testfall wiederholt werden sollen markiert Teardown-Aufgaben, die für jeden Testfall wiederholt werden markiert Setup-Aufgaben, die nur einmal pro Testklasse ausgeführt werden sollen markiert Teardown-Aufgaben, die nur einmal pro Testklasse ausgeführt werden sollen kennzeichnet temporär nicht auszuführende Testfälle 7.5 EJB UnitTests EJB bietet den Vorteil der Abstraktion - stellt Schnittstellen zur Verfügung Integration - läuft im EE und SE Umfeld Independency - lose Kopplung der Dienste Isolation Ziel: jede Klasse in Isolation testen TDD - In der Praxis lassen sich Klassen oft nicht isoliert testen - durch Abhängigkeiten von Geschäftsdarten - durch Integration durch Workflow Lösungsansätze Begriff Stub Dummy Mock Beschreibung fragmentale Implementierung als Stellvertreter Ersatzklasse, um das Verhalten zu testen dynamisches Dummy konfigurierbar 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 60 >> total: 255 Seiten

61 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen 7.6 Mocks wiki Mock-Objekte werden in der Testgetriebenen Softwareentwicklung Dummy-Objekte oder Attrappen genannt, die als Platzhalter für echte Objekte innerhalb von Unit-Tests verwendet werden. - dem zu testenden Objekt wird ein Stellvertreter zugewiesen Mock - referenzierte Objekte lassen sich einfach ersetzen Vorteile - einzelne Klassen können isoliert getestet werden - alle referenzierten Klassen werden durch Mocks ersetzt - Tests sind performant - keine Datenbanken notwendig Mocks sind transient - keine Verteilten Ressourcen notwendig Mocks sind lokale Ressourcen - Fehlerverhalten kann leicht provoziert/simuliert werden - durch Ausnahmen z.b. HostNotFoundException - durch Konfiguration z.b. NullPointerException - durch Workflow z.b. SqlException Mock Testing Isoliertes Testen ist in der Praxis oft nicht möglich! - Mock-Objekte überprüfen Interaktion mit Umgebung - Umgebung nicht vorhanden asynchrone Kommunikation - oder sehr zeitaufwändig keine Daten vorhanden - implementieren Schnittstelle - Mock-Objekt liefert keine Echtdaten simuliert Geschäftsprozess - nur festgelegte Testdaten wenn simulierte Abläufe möglich sind - Mock-Objekte sind nur limitiert einsetzbar - Objekt liefert keine deterministische Ergebnisse keine aktuellen Daten wie Uhrzeit, Temperatur - Objekt basiert nicht auf Interaktion kein Testen von Benutzungsoberflächen Mocktesting erlaubt nur reduziert eine sinnvolle Alternative / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 61 >> total: 255 Seiten

62 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen Ablauf - Mock Objekt eines Proxy erzeugen mybankmock - erwartetes Mock Verhalten aufzeichnen - Funktion testen public void test_getzinssatz() { BankBean totest = this.getbeantotest(); assertnotnull(totest); final Mock mybankmock = this.getmockcontrol(bank.class); assertnotnull(mybankmock); final SessionBean zins = new MockedSessionBean(); // instrument mock mybankmock.expects(once()).method("getrate").will(returnvalue(zins)); // call the expected operation totest.tellrate(); 7.7 Integrationstest Annotation erlaubt das Erkennen der Abhängigkeiten erlaubt parametrisierter = Parameterized.class) public class JunitParameterizedTest { private int number; public JunitParameterizedTest (int number) { this.number = public static Collection<Object[]> data() { Object[][] data = new Object[][] { { 1, { 2, { 3, { 4 ; return public void pushtest() { System.out.println("Parameterized Number is : " + number); ) definiert das = NamingException.class) public void noecho() throws NamingException { Object object = initialcontext.lookup("not bound"); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 62 >> total: 255 Seiten

63 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen 7.8 Funktionale Tests - in der Paxis etablieren sich Werkzeuge - Fit (Framework for Integrated Test) - Bedingungen als HTML - FitNesse - Bedingungen in wiki - Testbedingungen werden formuliert und die Resultate auf einem Browser ausgegeben Aufgabe Fit-Test - testen Sie die SLSB Applikation durch FitPro durch graphische Definition - und Generierung der ColumnFixture generierter Source /** * Generated by FITpro Fixture Generator */ import fit.columnfixture; /* * TODO: modify class to match the FIT test * edit and add methods as required. */ public class CalculateRate extends ColumnFixture { public String amount; public String calculate() { // TODO Auto-generated method stub return null; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 63 >> total: 255 Seiten

64 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen Aufgabe UnitTest - Testen Sie das HelloWorldBean mit JUnit Tests public class TestHelloWorldBean { private InitialContext public void setup() throws NamingException { Properties properties = new Properties(); properties.setproperty(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); properties.setproperty(context.provider_url, "jnp://localhost:1099"); initialcontext = new public void echo() throws NamingException { Object object = initialcontext.lookup("helloworldbean/remote"); assertnotnull(object); asserttrue(object instanceof HelloWorld); HelloWorld hello = (HelloWorld) object; assertequals("server Echo : Hello EJB World", hello.echo("hello EJB = NamingException.class) public void noecho() throws NamingException { Object object = initialcontext.lookup("not bound"); wiki Als Heisenbug bezeichnet man einen Programmfehler (engl.: Bug) der nur äusserst schwer oder garnicht zuverlässig reproduzierbar ist. Das Kennzeichen eines Heisenbugs ist die extrem schwierige Wiederherstellung der für die Reproduktion des Bugs notwendigen Rahmenbedingungen / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 64 >> total: 255 Seiten

65 EJB 3.1 / JPA 2.0 >> Java Framework >> Testen F SLSB Lerninhalte Begriffe Verwendung Lebenszyklus Annotations Kontext 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 65 >> total: 255 Seiten

66 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos 8 SLSB Stateless Session Bean zustandslos - modelliert einfacher Geschäftsprozess - z.b. Zinsberechnung - kann keine Client dedizierten Daten speichern - dediziert Lat: jemandem etwas zueignen / für ihn bestimmen - haben keine Identität - Aufgabe muss mit einem Methodenaufruf erledigt sein - zweimaliger Aufruf des Beans garantiert nicht dieselbe Instanz auf dem Server - sind oft als Fassaden eingesetzt - für Aufrufe an weitere Bean Instanzen - z.b. Persistenz Kontext pooling - mehrere Clients rufen dasselbe Bean auf - gemeinsame Nutzung von Sourcen - weniger Objekte im Einsatz Bean ist single-threaded ein Bean kann nur einen Client behandeln Ablauf - Container erzeugt während Deployment Beaninstanzen im Pool - konfigurierbar Methode steht nicht in direkter Kopplung zum aufrufenden Client C Parameter Beschreibung Typ Default name expliziter Name der Session Bean String unqualifizierter Klassenname mappedname mappen des Namens auf einen weiteren implementierungsspezifischen (JNDI)-Namen (nicht im Standard-Umfang der Spezifikation) String description eine Beschreibung für das Bean String C, I Parameter Beschreibung Typ value alle Schnittstellen, die entfernt zugreifbar sein sollen Class[] Default 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 66 >> total: 255 Seiten

67 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos 8.1 Bean Life Cycle Container Client initiated: business methods does not exist Methode-Ready-Pool Container initiated: Class.newInstance() Dependency Container initiated: Timeout Callback LifeCycleMethoden @Remove Timeout Callback Wird vom Container aufgerufen nachdem die Bean durch den Container instanziiert worden ist. Für den Client ist der Aufruf dieser Methode transparent. Ressourcen werden durch den Bean Provider freigegeben. Für den Client ist der Aufruf dieser Methode transparent. bei SLSB eine NO-OP implementiert, jedoch ohne Wirkung bezieht sich auf eine Container Timer Funktion 8.2 Dependency Injection wiki Dependency Injection (DI) ist ein Entwurfsmuster und dient in einem objektorientierten System dazu, die Abhängigkeiten zwischen Komponenten oder Objekten zu minimieren. Dependency Injection ist eine Anwendung des Prinzips der Inversion of Control (IoC), bezieht sich aber nur auf die Erzeugung und Initialisierung von Objekten. Sie kann als Verallgemeinerung der Fabrikmethoden verstanden werden. Die Funktionalität bleibt trotz dieser Kontrollumkehr als Einfügung enthalten. Dadurch ist es einfach möglich, Abhängigkeiten zu erkennen. - fördert lose Kopplung - Objekte erhalten ihre Abhängigkeiten passiv 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 67 >> total: 255 Seiten

68 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos 8.3 Übung : Zinsberechnung - erstellen und deployen Sie eine Stateless Session Bean - die eine Zinsberechnung als Businessmethode definiert - eines Geldbetrages amount - über eine definierte Laufzeit years - zu einem gegebenen Zinssatz rate Ansatz: - entwicklung einer Geldanlage durch Zins und Zinseszins public double calculate(double amount, double rate, int years) { return amount * Math.pow((rate / 100.0) + 1.0, (double) years); Eigenschaften der SLSB - Interfacebezug in der Beanklasse - implizit (deklariert) oder explizit (programmiert implements) - optionaler Name als = "RateBean") // überschreibt den Namen der // implizite Interfaces // seit EJB 3.1 optional public class ZinsBean {... - parameterloser Konstruktor ist erforderlich - muss public sein - EJB Container initialisiert Bean über Class.newInstance() - wird automatisch erzeugt - abhängig von Implementation public ZinsBean() { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 68 >> total: 255 Seiten

69 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos Zugriff auf das Environment nt Umgebung der Bean private float rate = public void injectrate() { InitialContext ic; ic = new InitialContext(); rate = ((Float) ic.lookup("java:comp/env/rate")).floatvalue(); System.out.println("Rate set:\t" + rate); auf Deploymentdescriptor: ejb-jar.xml jar.xml <ejb-jar xmlns=" version="3.0"> <enterprise-beans> <session> <ejb-name>ratebean</ejb-name> <env-entry> <env-entry-name>rate</env-entry-name> <env-entry-type>java.lang.float</env-entry-type> <env-entry-value>5.2</env-entry-value> </env-entry> </session> </enterprise-beans> </ejb-jar> oder Argument direkt annotiert Dependency public class ZinsBean = "Rate") private float rate; T Parameter Beschreibung description Typ description Beschreibung der referenzierten Ressource String Name der referenzierten Ressource im globalen Namensdienst mappedname (nicht im Standard-Umfang der Spezifikation) String name Name, unter dem die referenzierte Ressource im lokalen Namensdienst (java:comp/env) der Komponente, die die Annotation verwendet, auffindbar sein soll String Default T Parameter Beschreibung value Typ value Liste der einzelnen Ressource-Annotationen Resource[] Default 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 69 >> total: 255 Seiten

70 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos 8.4 EJB Kontext - Zugriff auf EJBContext - Security - z.b. getcalleridentity - Transaction - z.b. setrollbackonly Methoden des EJB-Kontext (Ausschnitt) Methode Beschreibung lookup() getbusinessobject() getinvokedbusinessinterface() Shortcut für Objekte des Enterprise Naming Context (ENC) - im JNDI ist der ENC unter "java: comp/env" zu finden Einträge des ENC können injiziert werden - ENC: lookup("ejb/mybean"); - JNDI: lookup("java:comp/env/ejb/mybean"); nur SessionContext - liefert robuste Referenz auf das EJB nur SessionContext - liefert das Interface der Geschäftsschnittstelle Local, Remote oder WebService Zugriff auf SessionContext extends EJBContext - Referenz auf aktuelle Bean Implementation (z.b. public class ZinsBean private SessionContext sc; public Object getremotereference() { return sc.getbusinessobject(zinsremote.class); public Object getremoteinterface(){ return sc.getinvokedbusinessinterface(); oder Annotation auf public void setsessioncontext(sessioncontext sc) { this.sc = sc; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 70 >> total: 255 Seiten

71 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos EJBContext vs SessionContext - EJBContext ist ein Interface, implementiert vom Container - SessionBeans brauchen eine Subklasse SessionContext - Entity Beans brauchen eine Subklasse EntityContext - EJBContext Objekte versorgen Beanklasse mit Informationen über - Bean - referenzieren der Bean-Referenz als robuster Handle - referenzieren des Proxyobjektes - Container - suchen im Bean's ENC - referenzieren einen Timer-Service - Client - authentifizierter Benutzer - Überprüfung der Benutzerrolle 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 71 >> total: 255 Seiten

72 EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean zustandslos G SFSB Lerninhalte Begriffe Verwendung Lebenszyklus Annotations 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 72 >> total: 255 Seiten

73 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet 9 SFSB Stateful Session Bean zustandsbehaftet - modelliert Geschäftsprozess - z.b. Shopping Cart - kann Client dedizierte Daten speichern - Zustandsbehaftet kann den Zustand (Session) eines Client speichern - mehrmaliger Aufruf des Beans für einen Geschäftsablauf möglich - kein pooling zusätzlicher LIFE-State passivated - wenig Ressourcen und Memory beansprucht - dadurch bessere Performance Eigenschaften - Session Bean darf keine Interfaces implementieren (ausser die eigenen) - alle public Methoden sind sichtbar - Client sieht den Typ der Bean-Klasse - Guard ist immer implementiert wiki Guard-Patter Pattern: Methodenaufrufe werden auf die entsprechenden Zugriffsrechte überprüft. C Parameter Beschreibung name Typ name expliziter Name der Session Bean String mappedname description mappen des Namen auf einen weiteren implementierungsspezifischen (JNDI)-Namen (nicht im Standard-Umfang der Spezifikation) String description eine Beschreibung für das Bean String Default unqualifizierter Klassenname M Parameter Beschreibung retainifexception Typ Default retainifexception Löschverhalten der Bean bei einer Exception Boolean true C,I, optional seit EJB3.1 Parameter Beschreibung eibung Typ value alle Schnittstellen, die lokal zugreifbar sein sollen Class[] Default 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 73 >> total: 255 Seiten

74 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet 9.1 Bean Life Cycle does not exist timeout Container initiated: Container Class.newInstance() Dependency Injection Exception Methode-Ready afterbeginn() beforecompletion() aftercompleteion(*) Client initiated: nichttransaktionale Business Methods in Transaktion Client initiated: transaktionale Business Methods Container initiated: * Client initated: Client initiated: Methodenaufruf (Least Recently Used) Passive COMMIT = true ROLLBACK = false Bean Life Cycle Methoden LifeCycleMethoden @Remove Wird vom Container aufgerufen nachdem die Bean durch den Container instanziiert worden ist. Für den Client ist der Aufruf dieser Methode transparent. Ressourcen werden durch den Bean Provider freigegeben. Für den Client ist der Aufruf dieser Methode transparent. Wird durch den Container aufgerufen, bevor die Bean in den passiven Zustand verschoben wird. Ressourcen werden durch den Bean Provider freigegeben. Für den Client ist der Aufruf dieser Methode transparent. Der Container holt die passivierte Instanz der Bean in den Arbeitsspeicher zurück und ruft danach die markierte parameterlose Methode auf, um Zustand der Bean erneut zu initialisieren. Wird vom Container aufgerufen, nachdem der Client eine Methode des Remote- Interface aufgerufen hat, die durch die Bean mit der gekennzeichnet ist. In dieser Methode sollten die für die Bean reservierten Ressourcen wieder freigegeben werden. Danach löscht der Container die Bean- Instanz / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 74 >> total: 255 Seiten

75 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet Aufgabe Kontoführung ng - erstellen und deployen Sie ein SFSB Bank zur Verwaltung von Konten - benützen Sie dazu das Objekt Konto - verwenden Sie Annotation des Lombok-Projekt - "nr" ist Business-Key, also unique jedoch nicht PK der DB - Anwenderfälle - Benutzer kann Konto speichern - Benutzer kann Konto löschen - Benutzer kann Konten suchen - Speichern Sie die Konten in einer (mysql) Datenbank Tabelle Account DROP TABLE IF EXISTS ACCOUNT; CREATE TABLE ACCOUNT( ID INTEGER PRIMARY KEY AUTO_INCREMENT, NR VARCHAR(20), NAME VARCHAR(20), SALDO FLOAT(5,2), CURRENCY VARCHAR(20) ); LOCK TABLES `account` WRITE; INSERT INTO `account` VALUES (1,'120-1','Sparkonto',100.50,'CHF'), (2,'120-2','Privatkonto',280.20,'CHF'), (3,'120-3','Eurokonto',250.00,'EUR'), UNLOCK TABLES; (4,'120-4','Dollarkonto',305.10,'USD'); - starten Sie den MySQL Datenbank Deamon und erzeugen Sie eine Datenbank jee c:\jee\mysql\bin>mysqld install c:\jee\mysql\bin>net start mysql c:\jee\mysql\bin>mysql u root mysql>create database jee; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 75 >> total: 255 Seiten

76 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet - erzeugen Sie die Datenbankverbindung durch den Bean Lifecycle - mit der Ansatz - vergessen Sie nicht das Schliessen public class BankBean implements Bank public void getdatasource(){ // BMP - Bean Managed Persistence String url = "jdbc:mysql://localhost/bank?user=root"; Class.forName("com.mysql.jdbc.Driver").newInstance(); co = DriverManager.getConnection(url); - testen Sie mit entsprechenden JUnit public void savekonto() { Account k = new Account("120-9", "TestAccount", 100.0F, "EUR"); bank.createaccount(k); Account savedaccount = bank.getaccountbynr("120-9"); assertequals("120-9", savedaccount.getnr()); 9.2 Verschalten von Beans - durch die Bean-Klasse - oder durch das public class BankBean implements Bank = "ejb/zins") private ZinsLocal rate; // das Bean private ZinsBean rate; // die Bean Klasse ZinsLocal zins = null; // über Lookup try { ic = new InitialContext(); // auch: ic.lookup(zins.class.getname()); zins = (ZinsLocal) ic.lookup("ejb/zins"); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 76 >> total: 255 Seiten

77 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet T, M Parameter Beschreibung beaninterface beanname mappedname me name Interface-Typ der referenzierten Bean Remote oder Local logischer Name der referenzierten Bean name @MessageDriven Name der referenzierten Bean im globalen Namensdienst (nicht im Standard-Umfang der Spezifikation) Name, unter dem die referenzierte Bean im lokalen Namensdienst (java:comp/env) der Komponente, die die Annotation verwendet, auffindbar sein soll Typ Class String String String Default Object.class Parameter Beschreibung value Typ value Liste der EJB Annotationen EJB[] Default Aufgabe Local Interface - Berechnen Sie den Zins durch eine SFSB Bank - verwenden Sie das Lokale Interface der ZinsBean "Zins" - verwenden Sie die Beanklasse "ZinsBean" (mappedname = "ejb/zins", name= "RateBean") public class ZinsBean { public double calculate(double amount, int years) { return amount * Math.pow((rate / 100.0) + 1.0, (double) public class BankBean implements Bank private Zins rate; public double tellrate(){ return rate.getrate(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 77 >> total: 255 Seiten

78 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet 9.3 Anbindung einer DataSource Resource-Verwaltung unterscheidet zwischen Bean- und Container-Managed - JDBC Anbindung in der Bean Bean Managed - DataSource Injektion Container Managed Injektion der public class BankBean implements Bank = "java:jdbc/bank") private DataSource ds = = "java:jdbc/bank", name = "bankdb") public class BankBean implements Bank public void getdatasource(){ ds = (DataSource) sc.lookup("bankdb"); - jdbc/bank ist eine serverspezifische (JBoss) Rescource - wird durch den Container bereitgestellt - wird beim Starten des Servers instanziiert JBoss spezifische DataSource: <JBoss_Home>/server/jee/deploy/mysql-ds.xml ds.xml <datasources> <local-tx-datasource> <jndi-name>jdbc/bank</jndi-name> <connection-url> jdbc:mysql://localhost:3306/jee </connection-url> <driver-class>com.mysql.jdbc.driver</driver-class> <user-name>root</user-name> <password></password> <local-tx-datasource> <datasources> - wird beim Serverstart zur Verfügung gestellt - die Resource wird gebunden und ist im Log ersichtlich Bound ConnectionManager 'jboss.jca:service=datasourcebinding,name=jdbc/bank' to JNDI name 'java:jdbc/bank' 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 78 >> total: 255 Seiten

79 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet EJB Ressourcen T Parameter Beschreibung authentication- Type Typ CONTAINER: die Anmeldedaten werden im Deskriptor hinterlegt BEAN: die Anmeldedaten werden explizit bei der Erzeugung der Verbindung übergeben description Beschreibung der referenzierten Ressource String description mappedname name shareable Name der referenzierten Ressource im globalen Namensdienst Name, unter dem die referenzierte Ressource im lokalen Namensdienst (java:comp/env) der Komponente auffindbar sein soll definiert ob die Ressource von mehreren Komponenten genutzt werden kann Default AuthenticationTyp CONTAINER String String Boolean true T Parameter Beschreibung value Typ value Liste der einzelnen Ressource-Annotationen Resource[] Default 9.4 DAO Data Access Object wiki Data Access Object (DAO, deutsch: Datenzugriffsobjekt ) ist ein Entwurfsmuster, das den Zugriff auf unterschiedliche Arten von Datenquellen (z. B. Datenbanken, Dateisystem, etc.) so kapselt, dass die angesprochene Datenquelle ausgetauscht werden kann, ohne dass der aufrufende Code geändert werden muss. Dadurch soll die eigentliche Programmlogik von technischen Details der Datenspeicherung befreit werden und flexibler einsetzbar sein. DAO ist also ein Muster für die Gestaltung von Programmierschnittstellen (APIs). Wenn eine Programmiersprache keine Trennung von Schnittstellendefinition und -Implementierung ermöglicht, muss ein e DAO die definierte Schnittstelle unmittelbar implementieren. DAOs kappseln den Datenbankzugriff - DAOs führen keine Datenbankabstraktion durch - DAOs sind jeweils für ein spezielles Speichermedium optimiert - der Zugriff auf dieses Medium wird über das vom DAO vorgegebene DAOs minimieren den Portierungsaufwand einer Anwendung beim Wechsel des Speichermediums / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 79 >> total: 255 Seiten

80 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet Aufgabe generic DAO - kapselt Sie die Datenbankzugriffe in einem DAO - abstrahieren Sie die allgemeine Funktionalität in ein generic DAO - delegieren Sie die Datenbankfunktionen aus der Bank public class BankBean implements Bank private KontoDAOBean kontodaobean; public void createkonto(konto k) { this.kontodaobean.save(k); public List<Konto> getallkontos() { return this.kontodaobean.findall(); public Konto getkontobynr(string nr) { return this.kontodaobean.findbynr(nr);... Aufgabe lokales les Speichern einer serverseitigen Bean Referenz - Handle definiert robuste Referenz auf Objekte z.b. für Cookie - definiert Wiederverwendbarkeit - Remote Referenz auf EJB3 ist robust - POJO muss serialisierbar public void testserialization() throws Exception { savebank(bank.getremotereference()); assertequals(bank.getremotereference(), loadbank().getremotereference()); private void savebank(object bank) throws IOException { // write "bank" Object Reference to serialized File FileOutputStream f = new FileOutputStream("Bank_Reference.ser"); ObjectOutputStream o = new ObjectOutputStream(f); o.writeobject(bank); private Bank loadbank() throws IOException, ClassNotFoundException { // read "bank" Object Reference from File FileInputStream fi = new FileInputStream("Bank_Reference.ser"); ObjectInputStream oi = new ObjectInputStream(fi); // read the object from the file and cast it to a Bank Instance return (Bank) oi.readobject(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 80 >> total: 255 Seiten

81 EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean zustandsbehaftet H Singleton Lerninhalte Singleton Parallelität Asychronität 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 81 >> total: 255 Seiten

82 EJB 3.1 / JPA 2.0 >> Java Framework >> Singleton Bean 10 Singleton Bean - eine einzige Bean Instanz pro Applikation - verteillt eine Bean Instanz pro VM Lösung SFSB mit dem Lifecycle einer SLSB C Parameter Beschreibung mappedname Typ mappedname Name der referenzierten Ressource im globalen Namensdienst String Name, unter dem die referenzierte Ressource im lokalen name Namensdienst (java:comp/env) der Komponente auffindbar sein soll String Default - markiert ein Singleton für eager loading während der Initialisierung der Applikation C - definiert eine Abhängigkeit zwischen Singleton bei der Initialisierung C Parameter Beschreibung Typ value Singleton, die vorgängig initialisiert werden müssen Class[] Default public class HelloWorldBean implenets Hello { public String echo(string echo) { return "Server Echo : " public class GoodbyWorldBean { public String echo(string echo) { return "Server Echo : " + echo; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 82 >> total: 255 Seiten

83 EJB 3.1 / JPA 2.0 >> Java Framework >> Singleton Bean 10.1 Parallelität - auch Singletons werden durch Client immer parallel genutzt - Nebenläufigkeit muss definiert werden Synchronisation - durch den Container CMC Container-Managed-Concurrency - durch die Bean BMC Bean-Managed-Concurrency - definiert Verhalten bei Nebenläufigkeit für eine SFSB oder eine Singleton Bean C Parameter Beschreibung Typ Default value CONTAINER: die Nebenläfigkeit wird durch den Container garantiert BEAN: die Nebenläfigkeit wird durch die Bean garantiert ConcurrencyManagementType CONTAINER - definiert Verhaltung bei Nebenläufigkeit für eine Singleton Methode M Parameter Beschreibung value WRITE: definiert exclusiven Zugriff auf die Bean Instanz READ: nur lesenden Zugriff Typ Default LockType WRITE 10.2 Asynchroner Aufruf - Session Beans können asynchrone Business-Methothen anbieten - Zustellung garantiert - nach dem COMMIT der Transaktion - persistent - überlebt Serverrestart - konfigurierbar void oder Future<V> als Return - Interface Future kapselt das Ergebnis einer asynchronen Berechnung und bildet den Lebenszyklus eines Tasks ab - auf (EJB) Klassen und für Methoden public class AsyncHelloWorldBean implenets AsyncHello public Future<String> echo(string echo) { // write "konto" Object Reference to serialized File return new javax.ejb.asyncresult<string> "Server Echo : " + echo; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 83 >> total: 255 Seiten

84 EJB 3.1 / JPA 2.0 >> Java Framework >> Singleton Bean Aufgabe Bean-Instanz Hit-Counter - erstellen Sie eine Singleton Bean um die Zugriffe zu zählen public class HitCounter { private long public void resetcounts() { hits = 0; public void inccount() { public long tellhits() { return public class BankBean implements Bank private HitCounter hitcounter; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 84 >> total: 255 Seiten

85 EJB 3.1 / JPA 2.0 >> Java Framework >> Singleton Bean I Messaging Lerninhalte JMS API Messaging Topic vs. Queue Message Driven Lebenszyklus 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 85 >> total: 255 Seiten

86 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging 11 Messaging - unterstützt asynchrone Kommunkationsmodelle - Point-To-Point Queue - Publish / Subscribe Topic - unterstützt Entkoppelung - Verteilungsaspekt 11.1 JMS API Java Messaging Service - API für den Zugang zu Messaging-Systemen - definiert Schnittstelle - als Factory - Message als - Text - Bytes - Streams - Objects - Maps synchron P1 P2 asynchron P1 P2 BROKER Nachrichten erzeugen mit der JMS API Das Erzeugen und Absenden einer Nachricht über JMS erfolgt in sechs Schritten: 1. Treiber lokalisieren 2. Verbindung erzeugen 3. Session erzeugen 4. Destination lokalisieren 5. Consumers oder Producers erzeugen 6. Nachricht senden oder Nachricht empfangen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 86 >> total: 255 Seiten

87 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging Lokalisieren des JMS-Treibers - Treiber für das verwendete JMS-Produkt laden Maven - lookup(connection_factory) - CONNECTION_FACTORY ist JNDI-Name des Treibers - implementiert die Schnittstelle ConnectionFactory Erzeugen der JMS-Verbindung - aktive Verbindung zu einem JMS-Provider erzeugen - kapselt die Netzwerk-Kommunikation - Analog zu JDBC wird der Treiber verwendet, um eine Connection anzufordern - TopicConnection - QueueConnection Erzeugen einer JMS Session - JMS Session ist ein Hilfsobjekt, um Nachrichten zu senden oder zu empfangen - legt die Eigenschaften des Nachrichtenaustauschs fest - integriert den Nachrichtenaustausch in eine Transaktion - TopicSession / QueueSession Lokalisieren einer JMS Destination - JMS Destination ist ein Kommunikationskanal - sendet Nachrichten - empfängt Nachrichten - die Auswahl des Kanals erfolgt über ein lookup(channel) - CHANNEL ist JNDI-Name des Kanals - wird meist durch Applikationserver zur Verfügung gestellt Erzeugen eines JMS Consumers oder eines JMS Producers - Empfänger oder Sender Senden oder Empfangen der Nachricht - Typen von Nachrichten - Text, Bytes, Streams, Objects oder Maps - Nachricht wird instantiiert - Nachricht wird über den Producer gesendet - Nachricht wird über den Consumer empfangen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 87 >> total: 255 Seiten

88 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging jedes Interface hat zwei Ausprägungen, analog zu den beiden Kommunikationsmodellen JMS API Interface Point-To To-Point Publish-Su Subscribe ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection Queue Connection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver, -Browser TopicSubscriber 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 88 >> total: 255 Seiten

89 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging 11.2 JMS in JEE implementiert - EJB Container ist Broker - stellt Topics / Queues zur Verfügung MDB Topic / Queue anlegen - über JBoss admin-console erstellen - jms/testtopic - jms/testqueue Global JNDI Namespace +- jms (class: org.jnp.interfaces.namingcontext) +- testqueue (class: org.hornetq.jms.client.hornetqqueue) +- testtopic (class: org.hornetq.jms.client.hornetqtopic) Aufgabe Topic / Queue bereitstellen - erstellen Sie Topics / Queues - über die Admin-Konsole des Applikationsserver - per XML Deklaration - JBoss Admin Console - User Name admin - Password admin - XML Deklaration hornetq-jms.xml - <jboss server>\server\jee\deploy\hornetq\hornetq-jms.xml <queue name="chatqueue"> <entry name="jms/queue/chat"/> </queue> <topic name="saldobelowzerotopic"> <entry name="jms/topic/saldobelowzero"/> </topic> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 89 >> total: 255 Seiten

90 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging 11.3 Message Driven Bean - Session Beans sind Remote-Procedure-Call basierte Komponenten - werden immer synchron vom Client aufgerufen - Message-Driven-Bean unterstützt die asynchrone Kommunikation - der Client muss nicht warten, bis der Server die Aufgabe erledigt hat - Message-Bean stellt keine direkte Schnittstelle zur Verfügung - Client sendet eine Nachricht an einen Message-Server (Nachrichten-Server) - MDB ist durch das Deployment beim Messageserver registriert - MDB legt Funktionalität in der onmessage-methode fest Konfiguration des MDB C Parameter Beschreibung name Typ name expliziter Name der Bean String activationconfig mappedname description messagelistener Listener- Interface Providerspezifische Properties für die Konfiguration der vom Container realisierten Anbindung der Bean an das Nachrichtensystem mappen des Namens auf einen weiteren implementierungsspezifischen (JNDI)-Namen (nicht im Standard-Umfang der Spezifikation) Activation- Config- Property[] String description eine Beschreibung für das Bean String Default unqualifizierter Klassenname Interface für das Nachrichtensystem Class Object.class [] 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 90 >> total: 255 Seiten

91 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging Konfiguration der ActivationConfig C Parameter Beschreibung Typ acknowledgemode - Auto-acknowledge = Nachrichten werden vom Container bestätigt und Nachrichten werden nur einmal zugestellt - Dups-ok- acknowledge = Nachrichten werden vom String Container bestätigt, es können aber Duplikate vorkommen destination JNDI der Queue- oder Topic- Destination String Typ der Destination: javax.jms.queue oder destinationtype javax.jms.topic String messageselector Filter für empfangene Nachrichten String subscriptiondurability - NonDurable = Ist MDB nicht bereit so ist die Message verloren - Durable = JMS-Provider speichert Nachrichten bis die MDB bereit ist String Default 11.4 Bean Life Cycle Container does not exist Methode-Ready-Pool Container initiated: Class.newInstance() Dependency Container initiated: onmessage() Timeout Callback LifeCycleMethoden onmessage() Timeout Callback Wird vom Container aufgerufen nachdem die Bean durch den Container instanziiert worden ist. Für den Client ist der Aufruf dieser Methode transparent. Ressourcen werden durch den Bean Provider freigegeben. Für den Client ist der Aufruf dieser Methode transparent. Business Methode der MDB Bezieht sich auf eine Container Timer Funktion / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 91 >> total: 255 Seiten

92 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging Aufgabe durch MDB - erstellen und deployen Sie ein ReportMDB - bei negativem Kontosaldo soll über die ReportMDB ein versendet werden Ansatz BankBean - definieren der fachlichen Logik (k.getsaldo() < = "ConnectionFactory") private static TopicConnectionFactory = "jms/topic/saldobelowzero") private static Topic topic; public void withdrawamount(string name, Float amount) { for (Konto k : kontos) { if (k.getname().equals(name)) { k.setsaldo(k.getsaldo() - amount); if (k.getsaldo() < 0f) contactreportmdb(k); Ansatz BankBean.contactReportMDB - definieren der Logik zur asynchroner Kommunikation sender.send(msg); private void contactreportmdb(konto k) { String textmessage = "Balance less than 0 for:" + k.tostring(); javax.jms.connection connect; try { connect = factory.createconnection(); Session session = connect.createsession(false, Session.AUTO_ACKNOWLEDGE); MessageProducer sender = session.createproducer(topic); TextMessage msg = session.createtextmessage(); msg.settext(textmessage); sender.send(msg); connect.close(); catch (JMSException e) { e.printstacktrace(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 92 >> total: 255 Seiten

93 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging Ansatz ReportMDB - definieren der Logik zum Empfang der asynchroner Kommunikation = = "destinationtype", propertyvalue = = "destination", propertyvalue = = "acknowledgemode", propertyvalue = "Auto-acknowledge") ) public class ReportMDB implements MessageListener { public void onmessage(message message) { System.out.println("\n \n" + "ReportMDB - Got message, sending \n" + message + "\n "); - senden Sie eine an einen SMTP Server onmessage(message message) {... Aufgabe senden - testen Sie den Versand von s durch ein MDB - testen Sie mit bekannten SMTP Einstellungen Ansatz private void sendmail(message message) { Authenticator auth = new Authenticator() { protected PasswordAuthentication getpasswordauthentication() { return new PasswordAuthentication("user", "pass"); ; Properties properties = new Properties(); properties.put("mail.smtp.host", "pop.gmail.com"); properties.put("mail.smtp.auth", "true"); javax.mail.session session = javax.mail.session.getdefaultinstance(properties, auth); try { // neue Message erzeugen, konfigurieren und versenden javax.mail.internet.mimemessage msg = new javax.mail.internet.mimemessage(session); msg.set... Transport.send(msg); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 93 >> total: 255 Seiten

94 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging Aufgabe Chat mit MDB - erstellen und deployen Sie ein ChatMDB - ChatMDB soll einen Chatroom (Queue) bereitstellen - erstellen Sie eine eigene Queue : = = "destinationtype", propertyvalue = = "destination", propertyvalue = = "messageselector", propertyvalue = "MessageFormat = = "acknowledgemode", propertyvalue = "Auto-acknowledge") ) public void onmessage(message message) { try { TextMessage txtmsg = (TextMessage) message; String text = txtmsg.gettext(); System.out.println(text); if (factory!= null && topic!= null) { Connection connect = factory.createconnection(); Session session = connect.createsession(false, Session.AUTO_ACKNOWLEDGE); MessageProducer sender = session.createproducer(topic); TextMessage msg = session.createtextmessage(); msg.settext(text); sender.send(msg); connect.close(); else { System.out.println("factory or topic not found"); catch (JMSException ex) { ex.printstacktrace(); Swing Client Applikation InitialContext ctx = new InitialContext(); ConnectionFactory factory = (ConnectionFactory) ctx.lookup("connectionfactory"); javax.jms.queue queue = (javax.jms.queue) ctx.lookup("jms/queue/mychatroom"); connect = factory.createconnection(); session = connect.createsession(false, Session.AUTO_ACKNOWLEDGE); sender = session.createproducer(queue); new Empfaenger(); String anmelden = "NEW:" + jtextfieldname.gettext(); TextMessage msg = session.createtextmessage(anmelden); msg.setstringproperty("messageformat", "ChatMessage"); sender.send(msg); class Empfaenger implements javax.jms.messagelistener { public Empfaenger() { InitialContext ctx = new InitialContext(); ConnectionFactory factory = (ConnectionFactory) ctx.lookup("connectionfactory"); javax.jms.topic topic = (javax.jms.topic) ctx.lookup("jms/testqueue"); Connection connect = factory.createconnection(); Session session = connect.createsession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer receiver = session.createconsumer(topic); receiver.setmessagelistener(this); connect.start(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 94 >> total: 255 Seiten

95 EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging J AOP Lerninhalte Paradigma Begriffe Verwendung Annotations 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 95 >> total: 255 Seiten

96 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12 Aspektorientiertes es Programmieren - Aspektorientierung kapselt wiederholende Aufgaben - Aufgabe einmal programmiert - an mehreren Stellen ausgeführt - AOP trennt Businesslogik von Services - Logging - Transaktions-Management - Sicherheits-Managment - AOP verwaltet zentrale Aufgaben wiederverwendbar - Datenbank-Zugriffe - Caching - Authentisierung Cross ross-cutting Concern - querschnittliche Belange einer Software - erlauben keine Modularisierung AOP bietet Lösungsansatz 12.1 Aspektorientierung wiki Aspektorientierte Programmierung (AOP) ist ein Programmierparadigma, eine Methode der Computer- programmentwicklung, die anstrebt, verschiedene logische Aspekte eines Anwendungsprogramms (kurz Anwendung) ) getrennt voneinander zu entwerfen, zu entwickeln und zu testen. Die getrennt entwickelten Aspekte werden dann zur endgültigen Anwendung zusammengefügt. - erlaubt kohäsive (zusammenhängende) Entwicklung - SoC (Separation of Concerns) - trennt Business-Logik von Systemservices - Logging - Auditing - Transaktionsverwaltung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 96 >> total: 255 Seiten

97 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12.2 Begriffe des AOP - Advice - Cross-Cutting Concern - Softwarecode, der zur Ausführung kommt - Logging - Transaktionsmanagement - JoinPoint - impliziert gegebene Ausführungspunkte für Advise - vor Methodenaufruf - nach Methodenaufruf - bei Exception - etc. - JoinPoints PointCut - eingrenzendes Muster vorhandener JoinPoints - als Klassenfilter und Methodenmatcher - definierte Use Cases Use Case - ServiceMethoden - DAO Funktionalitäten Advice PointCut Begriffe in der Aspektorientierten Programmierung AOP Begriff Aspect Joinpoint Advice Pointcut Target Proxy Weaving Introduction Beschreibung Aufgabe, die an verschiedenen Stellen im Programm benötigt wird, z.b. Logging Punkt im Programmfluss, an dem der Aspect eingreift (z.b. Methoden, Exceptions, etc. Spring erlaubt nur Methoden als Joinpoints) Aktion eines Aspekts am Joinpoint, also der Aspect, der am Joinpoint ausgeführt wird Muster, das den Aspect eingrenzt (als Klassenfilter und Methodenmatcher) Objekt, das Joinpoints zur Verfügung steht (z.b. Parameter der Signature) Proxy-Objekt wird aus dem Target erstellt Weaving beschreibt den Vorgang, aus Targets Proxys zu erstellen - beim Kompilieren (statisches AOP) - zur Laufzeit (dynamisches AOP) ermöglicht einem Target zusätzlich (dynamische) Funktionalität z.b. erkennt das Interface Modifiable Änderungen innerhalb des Targets Dynamisches AOP (weaving zur Laufzeit) hat grundsätzlich schlechtere Performance gegenüber statischem AOP (weaving zur Compilezeit), bietet jedoch mehr Flexibilität / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 97 >> total: 255 Seiten

98 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12.3 EJBs und AOP EJB Spezifikation erlaubt die Definieren von Interceptoren für: - Klassen - Methoden - Container-Callbacks - Lifecycle Methoden 12.4 Interceptoren wiki Interceptor ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung zur Erweiterung eines Framework oder einer Middleware,, ohne diese selbst zu verändern. Es fällt in die Gruppe der Configuration Pattern. Nutzung von gemeinsamem Code Crosscutting Concern - zentrale Codesegmente für die Applikation - wieder verwendbar - für Session Beans und Message Driven Beans - Interceptoren sind zustandslos - können keine Informationen austauschen - Interceptoren für Geschäftsmethoden - fangen Methodenaufrufe ab - führen zentrale Codesegmente aus - z.b. Logging - Lebenszyklus Callbacks - stellen Callbacks des Containers zur Verfügung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 98 >> total: 255 Seiten

99 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12.5 Klassenweiter Interceptor - durch - mit der Interceptor-Klasse als Parameter C Parameter Beschreibung value Typ value alle Interceptoren, die bearbeitet werden sollen Class[] Default - gilt für alle Methodenaufrufe innerhalb public class BankBean implements Bank { - Definition von mehreren Interceptors - Aufruf erfolgt in der Reihenfolge Interceptor2.class) public class BankBean implements Bank { 12.6 InvocationContext - gibt Informationen über den Aufruf der Geschäftsmethode - Parameter - Target - ContextData - z.b. CallerSubject Interface InvocationContext Parameter Beschreibung getcontextdata() gettarget() getmethod() getparameters() getparameters() proceed() gibt die Context Daten der Invocation oder Lyfecycle Callbacks oder eine leere Map zurück, also stellt eine Map für die Informationsübergabe zwischen den Interceptoren zur Verfügung gibt die Targetinstanz des abgefangenen Clientrequests zurück gibt die Methode aus abgefangenen Clientrequests zurück oder null bei Lifecyxle Callbacks gibt die Parameter des abgefangenen Clientrequests zurück setzt die Parameter des aufgerufenen Targets ruft das ursprüngliche Target oder den nächsten Interceptor auf 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 99 >> total: 255 Seiten

100 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12.7 Methoden Intercepter leitet sämtliche Methodenaufrufe durch die Interceptor Methode - Aufrufparameter können analysiert werden auch manipuliert - Signature der Interceptor-Methode ist unabhängig von EJB Interface - Verkettung mehrerer Interceptoren Methoden ist möglich - nur ein Interceptor pro Klasse erlaubt - Funktionen des Interface InvocationContext enthält Informationen der aufgerufenen Methode - proceed() definiert den weiteren Ablauf - nächste Interceptor-Methode / ursprünglich aufgerufene Methode - stoppt den funktionellen Ablauf z.b. Sicherheitsverhalten festzulegen - daher auch throws Exception als unchecked Exception - Return Type Object erlaubt Manipulation der public Object abfangen(invocationcontext ic) throws Exception { System.out.println(ic.getMethod().getName() + " () wird aufgerufen"); return ic.proceed(); Ablauf - bei verschachteleten Interceptoren - Cient ruft Business Methode auf Proxy erzeugt InvocationContext und ruft diesen auf - InvocationContext ruft Interceptor 1 auf Interceptor 1 beendet mit proceed() - InvocationContext ruft Interceptor n auf Interceptor N beendet mit proceed() - InvocationContext ruft EJB auf 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 100 >> total: 255 Seiten

101 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12.8 Lifecycle-Callback Interceptor - allgemein definierte Lifecycle-Methode wieder verwendbar, z.b. PostActivate - als Interceptor annotiert Signature muss eingehalten werden - in eigener Interceptor-Klasse definiert - durch Lifecycle Annotation void intercept(invocationcontext ic) throws Exception Interceptors Geschäftsmethoden vs Lebenszyklus-Ereignisse Typ für Geschäftsmethoden für Lebenszyklus-Ereignisse Kontext alle oder einzelne Methoden Lifecycle Methoden definiert in Interceptor-Klasse Bean- oder Interceptor-Klasse Signature Annotation void <methode>(invocationcontext) Bean-Klasse void<methode>() Interceptor-Klasse <methode>(invocationcontext) vor der Bean-Klassendefinition! Interceptor-Klasse Callback-Annotation Verwendung der Container Callbackmethoden als Interceptoren Callback Methoden des EJB Containers Callback @PostActivate javax.annotation javax.annotation Stateless Session- Stateful Session- MessageDriven- Stateless Session- Stateful Session- javax.ejb javax.ejb Stateful javax.ejb Stateless Session- Stateful Session- MessageDriven- Beschreibung nach der Instanziierung nach Dependency Injection vor der Business-Methode vor dem Beenden der Instanz nach Reaktivierung der Bean aus dem Sekundärspeicher vor Passivierung der Bean in den Sekundärspeicher durch Timeout eines Timers 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 101 >> total: 255 Seiten

102 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren 12.9 Interceptoren ausschliessen unterdrückt alle für die Klassen definierten Interceptoren auf Methodenebene - gilt nicht annotierte public float tellrate() { return rate; unterdrückt alle im Deploymentdescriptor public class BankBean implements Bank { Aufgabe Timelogger mit Inteceptor - implementieren Sie einen Zeitlogger für die Servermethoden per Interceptor - Ausgabe auf der Konsole oder in einer Logdatei Call to fascade.bankbean.createaccount took 57 Micros Call to fascade.bankbean.createaccount took 12 Micros Call to fascade.bankbean.calculate took 29 Micros Call to fascade.bankbean.calculaterate took 3164 Micros Call to fascade.bankbean.getaccountbalance took 12 Micros Call to fascade.bankbean.tellrate took 12 Micros Call to fascade.bankbean.getsaldo took 45 Micros public class BankBean implements Bank { / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 102 >> total: 255 Seiten

103 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren Ansatz TimingInterceptor - Vor- und Nachbearbeitung durch - derfinierte Signature public Object timing(invocationcontext ctx) throws Exception import static java.util.concurrent.timeunit.nanoseconds; public class TimingInterceptor public Object timing(invocationcontext ctx) throws Exception { long invoke = System.nanoTime(); String classinvoked = "", methodinvoked = ""; try { classinvoked = ctx.gettarget().getclass().getname(); methodinvoked = ctx.getmethod().getname(); return ctx.proceed(); finally { long time = System.nanoTime() - invoke; System.out.println("Call to " + classinvoked + "." + methodinvoked + " took " + NANOSECONDS.toMicros(time) + " Micros"); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 103 >> total: 255 Seiten

104 EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren K Timer Service Lerninhalte Eigenschaften Ablauf Timer Schnittstellen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 104 >> total: 255 Seiten

105 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service 13 Timer Service Kontainer Funktionalität um zu vorprogrammierten Zeiten einen Vorgang auszuführen: - Löschung verwaister Daten - jede Nacht alle Datensätze, die älter als eine Woche sind, löschen - Reporting - Bericht über die täglich versendete Anzahl s - Monitoring - Überprüfung ob ein Dienst (EJB) zur Verfügung steht - Remainder - Nachrichten senden bis eine Rückmeldung eintrifft - Workflow - anstehende Aufträge in eine Warteschlange stellen Transa ransaktion tionen - ein Timer wird durch eine EJB erzeugt - EJBs laufen in einem transaktionalen Umfeld - transaktionaler Rollback löscht den Timer wieder 13.1 Eigenschaften - Timer Service für Container Komponenten EJBs - Batch Jobs duch den Container gestartet und verwaltet - als Kurzzeit-Timer ungeeignet - Container benachrichtigt EJB welches Timer definiert hat - Stateless Session Bean - Message Driven Bean - Timer EJB führt die annotierte Methode aus - Timer EJB ist Stateless - Container führt beliebige Instanz der EJB bietet vereinfachte Timer Funktion für EJBs - annotierte Bean Methode wird durch cron-ähnlicher Syntax getriggert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 105 >> total: 255 Seiten

106 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service 13.2 Ablauf 13.3 Timer starten - Timer erzeugen Praxis: durch ein SLSB - über EJB Kontext TimerService ts = SessionContext.getTimerService() - über Injection javax.ejb.timerservice SessionContext sc; public void setuptimer() { TimerService ts = sc.gettimerservice(); long min15 = 15 * 60 * 1000; // 15 Min * 60 Sec * 1000 msec Timer t = ts.createtimer(min15, min15, TimerService timerservice; public void setuptimer() { long std1 = 60 * 60 * 1000; // 60 Min * 60 Sec * 1000 msec Timer t = timerservice.createtimer(sec5, "einmal_in_1_stunden"); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 106 >> total: 255 Seiten

107 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service folgende Methoden stehen zum Erstellen eines Timers zur Verfügung: TimerService create Methoden Methode relativ absolut einmalig periodisch createtimer(long d, Serializable info) - long tendays = 1000 * 60 * 60 * 24 * 10 - createtimer(tendays,null) createtimer(long d, long interval, Serializable info) - long oneminute = 1000 * 60 * 1 - long onehour = 1000 * 60 * 60 - createtimer(oneminute, onehour, null) createtimer(date expiration, Serializable info) - Calendar Date = Calendar.getInstance() - date.set(2008, Calendar.JANUARY, 1) - createtimer(date.gettime(), null) createtimer(date ex, long interval, Serializable info) - Calendar Date = Calendar.getInstance() - date.set(2008, Calendar.JANUARY, 1) - long oneweek = 1000 * 60 * 60 * 24 * 7 - createtimer(date.gettime(), oneweek, null) 13.4 Timer ausführen - Container annotierte Methode beim definierten Zeitintervall public void fire(timer timer) { String info = timer.getinfo(); Timer beenden - Timer sind persistent - überleben einen Server-Restart - timer.cancel() löscht den definierten Timer Service public void stopallmonitors() { for (Object o : timerservice.gettimers()) { // cancel all TimerServices Timer timer = (Timer) o; timer.cancel(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 107 >> total: 255 Seiten

108 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service 13.5 Timer Schnittstellen - TimerService zum Verwalten des Timers - Timer aktuelles zeitgesteuertes Objekt Methoden des TimerService Interface Interface TimerService Methoden Beschreibung createtimer(... gettimers()...) verschiedene Methoden zum Erzeugen des Timers liefert alle Timer, die für ein bestimmtest Bean registriert wurden. Methoden des Timer Interface Interface Timer Methoden Beschreibung cancel() gettimeremaining() getnexttimeout() getschedule() gethandle() / getinfo() ispersitent() iscalendartimer() () Timer kann beendet werden verbleibende Zeitspanne Zeitpunkt des nächsten Timeout liefert das ScheduleExpressionObject zurück liefert serialisierbare Referenz des Timerobjekt liefert serialisierbares InfoObjekt des Timerobjekt liefert entsprechend boolschen Wert liefert entsprechend boolschen Wert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 108 >> total: 255 Seiten

109 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service 13.6 Automatische Timer - Container richtet bei Bedarf automatisch einen Timer ein - javax.ejb.timedobject entfällt - Timer Callbacks exitieren - Timerausdrücke mit cron-ähnlicher public void saldoausgeben() {... M Parameter Bereich Beispiel dayofmonth, dayofweek String dayofmonth = "7-3", dayofweek = "Fri-Mon" hour,, minute, second String second = "10,20,30" minute = "0-10,30,40", minute = "*/5" year, month String month="nov" info String Literal das den Timer beschreibt persitent boolean true / false timezone String timezone = "America/New_York" Beispiele - mehrere automatische = "10", dayofweek = = "12", dayofweek = = "14", minute="30", dayofweek = "Mon-Fre") ) public void sendbreaknotification() { System.out.println("Zeit für eine Pause..."); - nicht persistenter Timer ist an den JVM Lebenscyklus public class CacheBean { // erneuert den Singleton Cache alle 10 */10, hour= *, persistent=false) public void refresh() {... - ScheduleExpression definiert: "jeden Samstag um 13.00" ScheduleExpression schedule = new ScheduleExpression().dayOfWeek("Sat").hour(1); Timer timer = timerservice.createcalendartimer(schedule); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 109 >> total: 255 Seiten

110 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service Aufgabe SimpleEJBTimer - Singleton als EJB public class MyTimerService HelloService = "*/1", minute = "*", hour = "*", persistent = false) public void dowork() { System.out.println("timer: " + public class HelloService { public String sayhello() { return "Service invoked by MyTimerService > " + System.currentTimeMillis(); Aufgabe InterestMonitor mit EJB Timer - SLSB als EJB Timer soll den Zins aller summierten Kontensaldi public class InterestMonitorBean private void getsaldofromaccounts() = "*/15", minute = "*", hour = "*", persistent = false) public void calculateinterest(timer timer) { // 15 sec pro Jahr > 4, = this.currentsaldo += rate.calculate(this.startsaldo, 1) * ; DecimalFormat df = new DecimalFormat("#,###,##0.00"); System.out.println("Interest gained : " + df.format(currentsaldo) + " on Amount " + df.format(startsaldo) + " with " + df.format(rate.getrate()) + " % Interest"); INFO [STDOUT] Interest gained : 0.01 on Amount with % Interest INFO [STDOUT] Interest gained : 0.03 on Amount with % Interest INFO [STDOUT] Interest gained : 0.05 on Amount with % Interest 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 110 >> total: 255 Seiten

111 EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service L Web Service Lerninhalte Definition Begriffe Szenarien Anwendung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 111 >> total: 255 Seiten

112 EJB 3.1 / JPA 2.0 >> Java Framework >> Webservice 14 Webservice wiki Das World Wide Web Consortium definiert die Bereitstellung eines Webservices als Unterstützung zur Zusammenarbeit zwischen verschiedenen Anwendungsprogrammen,, die auf unterschiedlichen Plattformen und/oder Frameworks betrieben werden. Ein Webservice oder Webdienst ist eine Software-Anwendung, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstelle als XML-Artefakt definiert, beschrieben und gefunden werden kann. Ein Webservice unterstützt die direkte Interaktion mit anderen Software-Agenten unter Verwendung XML-basierter Nachrichten durch den Austausch über internetbasierte Protokolle. Beispiel WSDL - generiert durch JBoss - <wsdl:message name="calculateresponse"> <wsdl:part name="ertrag" type="xsd:double" /> </wsdl:message> <wsdl:message name="calculate"> <wsdl:part name="betrag" type="xsd:double" /> <wsdl:part name="zins" type="xsd:double" /> <wsdl:part name="jahre" type="xsd:int" /> </wsdl:message> 14.1 Szenarien - Session Bean stellt WebService zur Verfügung exportiert alle Methoden der Bean annotiert die zu exportierende Methode - AS (JBoss) erstellt WSDL beim Deployment - SessionBean ist Client für WebService - WSDL Datei (Beschreibungsdatei für den WebService) steht zur Verfügung - Session Bean implementiert SEI (Service Endpoint Interface) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 112 >> total: 255 Seiten

113 EJB 3.1 / JPA 2.0 >> Java Framework >> Webservice 14.2 Definition eines Web Service definiert eine Klasse als Webservice - macht alle öffentlichen Methoden sichtbar C, M Parameter Beschreibung endpointinterface name PortName servicename targetnamespace wsdllocation vollqualifizierter Name des Service-Endpoint- Interface Name des Port-Typs innerhalb der WSDL- Definition Name des Webservice-Ports innerhalb der WSDL-Definition Name des Webservices innerhalb der WSDL- Definition Namensraum für Port-Typ und untergeordnete Elemente Angabe einer WSDL-Datei um eine automatische Generierung zu verhindern (eigene Definition zu verwenden) Typ String String String String String String Default implementierenden Klasse [name] [name] Aufgabe WebService zur Zinsberechnung - offerieren Sie die Zinsberechnung des SLSB ZinsBean als WebService - ServiceEndpoint Interface deklariert = SOAPBinding.Style.RPC) public interface RateServiceEndpoint extends Remote = "ertrag") float calculate(@webparam(name = "betrag") float = "zins") float = "jahre") int years) throws RemoteException; - WebServiceZins Bean implementiert WebService = = "ejb/zins", name= "RateBean") public class ZinsBean implements Zins, RateServiceEndpoint { / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 113 >> total: 255 Seiten

114 EJB 3.1 / JPA 2.0 >> Java Framework >> Webservice - generierte WSDL Datei - JUnit public void setup() throws Exception { URL url = new URL(" QName qname = new QName(" "ZinsBeanService"); ServiceFactory factory = ServiceFactory.newInstance(); Service service = factory.createservice(url, qname); se = (RateServiceEndpoint) service.getport(rateserviceendpoint.class); assertnotnull(se); asserttrue(se instanceof public void calculatezins() throws Exception { assertequals(result, se.calculate(amount, rate, years), 0.05); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 114 >> total: 255 Seiten

115 EJB 3.1 / JPA 2.0 >> Java Framework >> Webservice M EJB Security Lerninhalte Architektur Begriffe Rollen Realm RoleMapping Deployment Descriptor Security Elemente Annotationen Security Domänen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 115 >> total: 255 Seiten

116 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security 15 JEE Security - "so wenig wie möglich" programmatische Sicherheit in die Beans - mehr deklarative Sicherheitseinstellungen über den Container 15.1 JAAS (Java Authentication and Authorization Service) Securitythematik - Authentifizierung von Clients - sichere Kommunikationsformen zwischen Client und Server - sichere Kommunikation zwischen Containern - Security Identity Propagation - rollenbasierter Zugriffsschutz innerhalb des Systems - Weiterreichen der Identität eines EJB-aufrufenden Client Securitybereitstellung - Applikation-Client-Authentisierung - über JAAS Java Authentication and Authorisation Service - Client wird bei Anmeldung am System als unidentifiziertes Subjekt angesehen - nach erfolgreicher Authentisierung werden Client-Subject Principals und Credentials zugeordnet - Principals werden über das java.security.principal-interface implementiert - assoziieren das Client-Subject mit einem Benutzernamen oder konto - sicherheitsrelevante Daten wie etwa ein Kerberos-Ticket - Loginpasswort - Principals werden später bestimmten Rollen zugeordnet - principal-to-role-mapping - Teil der umzusetzenden Sicherheitspolitik 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 116 >> total: 255 Seiten

117 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security 15.2 Security Roles Security Rollen werden in verschiedenen Entwicklungsbereichen definiert. Bean Provider (EJB-Entwickler) Entwickler) - "so wenig wie möglich" Sicherheitsfragen - Sicherheitspolitik nicht hart im Code eingebettet - später über den Container kontrollierbar und konfigurierbar - "programmatische Sicherheit" als Alternative - Rollen müssen im Deployment Descriptor referenziert sein public void withdrawmoney(float inamount) { if (inamount < 1000f) { accountbalance -= inamount; else if (sc.iscallerinrole("admin")) SessionContext sc; accountbalance -= inamount; else { System.out.println("Withdraw Denied for: " + sc.getcallerprincipal()); Application Assembler - stellt EJB-Komponenten zusammen - deklariert Sicherheitsrollen <assembly-descriptor> <security-role> <role-name>trustee</role-name> </security-role> <security-role> <role-name>owner</role-name> </security-role> <assembly-descriptor> - deklariert die Rechte der einzelnen Methoden - Name der erlaubten Methodensignature * um alle Methoden für eine Rolle freizugeben <method-permission> <role-name>trustee</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <role-name>owner</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>depositamount</method-name> </method> <method> <ejb-name>bankbean</ejb-name> <method-name>withdrawamount</method-name> </method> <method> <ejb-name>bankbean</ejb-name> <method-name>getsaldo</method-name> </method> <method-permission> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 117 >> total: 255 Seiten

118 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security Deployer - mappt die Systemrollen den Rollen des Beanproviders zu - ist auf gute Spezifikation des Assemblers angewiesen - muss die Rollenreferenzen des Programmierers kennen <security-role-ref> <role-name>trustee</role-name> <role-link>admin</role-link> </security-role-ref> - um programmatische Sicherheit zu ermöglichen - EJBContext.getCallerPrincipal - EJBContext.isCallerInRole - SessionContext.getCallerPrincipal - SessionContext.isCallerInRole 15.3 Client-Tier Sicherheit ApplicationClients - JAAS implementiert Pluggable Authentication Module (PAM) Frameworks - erlaubt den Einsatz von eigens entwickelten Loginmodulen - Loginmodule werden auf Seiten des Clients eingesetzt - verschiedene Loginvarianten werden unterstützt - Name/Passwort-Dialoge - externer Hardware und Smartcards - Zertifikate weiterreichen - Loginmodule steuern Loginvorgang - sammeln Authentifizierungsdaten über Callbackhandler - Statusinformationen vom Server werden an den Client zurückgereicht - durch Interface javax.security.auth.callback.callbackhandler AppCallbackHandler handler = new AppCallbackHandler(name, password); LoginContext lc = new LoginContext("FileRealmSecurityDomain", handler); lc.login(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 118 >> total: 255 Seiten

119 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security 15.4 JNDI Sicherheit - Login Spoofing - unberechtigte JNDI Server Einträge - sichere Verbindung zum Name-Services Properties env = new Properties(); env.setproperty(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); env.setproperty(context.url_pkg_prefixes, "org.jboss.security.jndi.jndilogininitialcontextfactory"); env.setproperty(context.provider_url, "jnp://localhost:1099/"); env.setproperty(context.security_principal, user); env.setproperty(context.security_credentials, password); InitialContext ctx = new InitialContext(env); Realms realm [Engl.] für Bereich - Realms definieren einen Bereich, in dem sich eine Gruppe von Benutzern authetifizieren - LDAP (Lightweight Directory Access Protocol) Server - Datenbank - Dateien 15.6 Legacy Tier Security - authentifizieren von Container bzw. Beans gegenüber Legacy-Systemen - wie Datenbanken oder Gateways - Container-Managed - Bean-Managed 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 119 >> total: 255 Seiten

120 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security 15.7 Declarative vs Programmatische Security Web Tier Web Resources EJB Tier Bean Methods Zugriffskontrolle web.xml ejb-jar.xml Deklaration deklarative Sicherheit Deployment Descriptor programmatische Sicherheit Programm Web Container EJB Container Umsetzung Container Programm Servlet / JSP EJB Bean Codierung "all or nothing" Logikbasiert 15.8 JEE Security Architecture - Hardware Security - SSL, Zertifakte, Schlüssel, etc. - Container Security - Authentifierung von Principals - Komponenten Security - Rollenbasierte Methodenzugriff Role Mapping - definiert durch Pricipal, Groupen und Rollen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 120 >> total: 255 Seiten

121 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security 15.9 ejb-jar.xml Security Deployment Descriptor Security Elemente Architektur Design - feingranulare Architektur - lose gekoppelte Komponenten - XML Deployment ist vorteilhaft Security Annotations - Security kann auch annotiert werden EJB Security Annotation Typ Methode Klasse alle Rollen bekommen sinnvoll bei geerbter selektioniert Methodenzugriff per definiert Methodenzugriffe legt die Rolle zur Ausführung fest, ungeachtet der Client Authorisierung Die Securitydomäne wird Serverspezifisch definiert: definiert Securitydomäne 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 121 >> total: 255 Seiten

122 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security RunAS - definiert das weitere Security-Verhalten C Parameter Beschreibung value Typ value Name der Rolle, die verwendet werden soll String Default - Methoden der Klasse ZinsBean benötigen die Rolle "owner" oder "trustee"damit sie ausgeführt werden können - Methoden der Klasse ZinsBean werden in der Rolle @Stateless(mappedName = "ejb/zins", name= "RateBean") public class ZinsBean implements Zins { Security Domain wiki A Security Domain is the t determining factor in the classification of an enclave of servers / computers. A network with a different security domain is maintained separate from other networks. - EJBs müssen Teil einer Security Domain sein - Konfiguraion ist abhängig von der Infrastulktur JBoss AS (spezifisch) - auth.conf - definiert LoginModul - ist Teil des Client Classpath - login-config.xml - definiert Realm - im <server>/conf Verzeichnis "other" ist die Standard JBoss Security Domäne 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 122 >> total: 255 Seiten

123 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security Security Domain definieren - annotiert - deklarativ Annotiert @RolesAllowed({ "owner", "trustee" ) public class BankBean implements Bank {... - referenziert [JBoss_Home]/server/[server]/conf/login-config.xml <application-policy name="filerealmsecuritydomain"> <authentication> <login-module code="org.jboss.security.auth.spi.usersrolesloginmodule" flag="required"> <module-option name="usersproperties">bank-users.properties</module-option> <module-option name="rolesproperties">bank-roles.properties</module-option> </login-module> </authentication> </application-policy> Deklarativ - jboss.xml <jboss> <security-domain>java:/jaas/filerealmsecuritydomain</security-domain> <unauthenticated-principal>guest</unauthenticated-principal> </jboss> - entsprechend ejb-jar.xml <assembly-descriptor> <security-role> <role-name>trustee</role-name> </security-role> <security-role> <role-name>owner</role-name> </security-role> <method-permission> <role-name>trustee</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <role-name>owner</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>depositamount</method-name> </method> / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 123 >> total: 255 Seiten

124 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security Realms definieren - Security Domain definiert Realms LDAP, DB, Dateien - definieren User und entsprechende Rollen - definieren den Zugriff auf User und entsprechende Rollen - Datei [JBoss_Home]/server/[server]/conf/login-config.xml definiert bestehende Domains Database-Server-Login-Modul <application-policy name = " MySqlRealmSecurityDomain "> <authentication> <login-module code = "org.jboss.security.auth.spi.databaseserverloginmodule" flag = "required"> <module-option name = "unauthenticatedidentity">guest</module-option> <module-option name = "dsjndiname">java:jdbc/account</module-option> <module-option name = "principalsquery">select password FROM users WHERE user=?</module-option> <module-option name = "rolesquery">select role,'roles' FROM roles WHERE roles.user=?</moduleoption> <module-option name = "debug">true</module-option> </login-module> </authentication> </application-policy> - entsprechende DB Schema - MySqlDB.users / MySqlDB.roles mysql> select * from users; user password kunde kunde verwalter verwalter rows in set (0.00 sec) mysql> select * from roles; user role verwalter trustee kunde owner rows in set (0.00 sec) Zusammenfassung EJB Security definiert rollenbasiertes Sicherheitsmodell - Clients mit entsprechenden Rollen bekommen Zugriff auf Methoden - annotiert - deklarativ - programmatisch - auf Session- und MessageDrivenBeans anwendbar - Zugriffsrechte auf EJB Methoden festlegen - ejb-jar.xml Deployment Descriptor - Annotation Annotierte Sicherheit - Security Domain und @RolesAllowed({ "owner", "trustee" ) public class BankBean implements Bank { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 124 >> total: 255 Seiten

125 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security Deklarative Sicherheit - Zugriffsrechte festlegen ejb-jar.xml Security Roles deklarieren <security-role> <role-name>trustee</role-name> </security-role> <security-role> <role-name>owner</role-name> </security-role> - Method Permission deklarieren <method-permission> <role-name>trustee</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <role-name>owner</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>depositamount</method-name> </method> <method> <ejb-name>bankbean</ejb-name> <method-name>withdrawamount</method-name> </method> </method-permission> Programmatische Sicherheit - Zugriffsrechte festlegen ejb-jar.xml <security-role> <role-name>verwalter</role-name> </security-role> <security-role> <role-name>kunde</role-name> </security-role> - Security Role Reference deklarieren <security-role-ref> <role-name>verwalter</role-name> <role-link>admin </role-link> </security-role-ref> - Bean-Methoden Implementierung entscheidet über Zugriff public void withdrawamount(string name, Float amount) { if (amount < 1000f sc.iscallerinrole("admin")) { for (Konto k : kontos) { if (k.getname().equals(name)) k.setsaldo(k.getsaldo() - amount); else { System.out.println("Withdraw Denied : Caller is " + sc.getcallerprincipal()); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 125 >> total: 255 Seiten

126 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security Aufgabe JAAS - testen Sie JAAS für das BankBean - erstellen Sie Principals, Credentials und entsprechende Rollen - testen Sie verschiedene Realms - Dateien im Classpath - bank-users.properties - bank-roles.properties - Datenbank per JNDI - MySQL DB - verwenden Sie verschiedene Client-Login Module - JAAS CallbackHandler LoginContext - oder auch JBoss SecurityClient import org.jboss.security.client.securityclient; import org.jboss.security.client.securityclientfactory; SecurityClient client = SecurityClientFactory.getSecurityClient(); client.setsimple(user, password); client.login(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 126 >> total: 255 Seiten

127 EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security N Transaktionen Lerninhalte Eigenschaften Steuerung Management Annotationen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 127 >> total: 255 Seiten

128 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement 16 Transaktionsmanagement wiki Als Transaktion (von lat. trans über, actio zu agere (durch)führen ) bezeichnet man in der Informatik eine Folge von Operationen, die als eine logische Einheit betrachtet werden. Insbesondere wird für Transaktionen gefordert, dass sie entweder vollständig oder überhaupt nicht ausgeführt werden (Atomarität ( Atomarität). Transaktionen werden von Transaktionssystemen verarbeitet; diese erzeugen dabei aus mehreren Transaktionen eine Historie. Transaktionen kommen meist bei Datenbanksystemen zum Einsatz Transaktion - logisch zusammenhängende Folge von Operationen einer Datenbank - wird von einem konsistenten in einen weiteren konsistenten Zustand überführt - kleinster, unteilbar abzuarbeitender Prozess einer Anwendung - werden vollständig oder gar nicht abgearbeitet Transaktionskonzepte ACID-Eigenschaften - Atomic (atomar) eher Up-Quark, Neutrino oder Myon, etc. - eine Transaktion ist Reihe von "primitiven" unteilbaren Operationen - es werden entweder alle Operationen ausgeführt oder gar keine - Consistent (konsistent) - Transaktionen hinterlassen die Daten in konsistentem Zustand - Isolated (isoliert) - gleichzeitige Transaktionen beeinflussen sich nicht - Durable (dauerhaft) - abgeschlossene Transaktionen sind dauerhaft Transaktionsverhalten - commit - erfolgreiche Beendigung einer Transaktion - die Änderungen sind dauerhaft in der Datenbank abgespeichert für alle (User) sichtbar - rollback - Transaktionsabbruch führt Änderungen am Datenbestand zum letzten konsistenten Zustand 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 128 >> total: 255 Seiten

129 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Lokale und verteilte Transaktionen - lokale Transaktion (local transaction) - nur lokale Daten betroffen - nicht mehrere (Daten)-Ressourcen sind Teil der Transaktion - verteilte Transaktion (distributed transaction) - betreffen mehrere Daten, die auf Verteilten Systemen liegen - müssen in Teiltransaktionen aufgeteilt werden Transaktionsablauf - Business Prozess startet Transaktion 1 - Business Prozess startet Transaktion 2 - Transaktion 1 wird mit commit beendet - Transaktion 2 wird mit commit beendet inkonsistente Zustände sind möglich - zweite Commit-Anweisung fällt aus Zwei Phasen Commit 2PC definiert erweitertes Protokoll mit 2 Phasen - Erste Phase - "Prepare-to-Commit" auf allen Knoten - teure Operation - Zweite Phase - sendet ein Commit an die Knoten - billige Operation 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 129 >> total: 255 Seiten

130 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Isolationsebenen wiki In der Informatik bezeichnet der Begriff Isolation die Trennung von Transaktionen auf eine Weise, dass eine laufende Transaktion nicht von einer parallel ablaufenden Transaktion durch Änderung der benutzten Daten in einen undefinierten Zustand gebracht werden kann. Die Isolation ist eine der vier ACID-Eigenschaften. - komplette Serialisierung der transaktionalen Operationen - sicher, aber teuer - Isolierung ist eine Einschränkung im Vergleich zu idealen ACID Transaktionen - nach ANSI-92 SQL Isolationsebenen Level Beschreibung NONE keine Transaktion möglich READ_UNCOMMITTED alle Transaktionen sehen die Änderungen von anderen Transaktionen READ_COMMITTED nicht abgeschlossene Transaktionen sind unsichtbar für andere Transaktionen REPEATABLE_READ eine Transaktion sieht nur Daten, die vor ihrem Startzeitpunkt vorhanden waren SERIALIZABLE alle Transaktionen verhalten sich, als würden sie hintereinander abgearbeitet Probleme bei parallelen Datenbankoperationen - Multi-User Applikationen definieren folgende Problem-Szenarien Dirty Read - innerhalb einer Transaktion T1 wird ein Datensatz Z verändert - dieser veränderte Datensatz wird innerhalb einer zweiten Transaktion T2 gelesen - Transaktion T1 mit einem Rollback abgebrochen - die Transaktion T2 arbeitet mit einem ungültigen Wert - Dirty Read dirty read Transaktionsablauf User T1 UPDATE ROLLBACK Daten Z User T2 SELECT SELECT 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 130 >> total: 255 Seiten

131 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Non Repeatable Read - innerhalb einer Transaktion T1 wird ein Datensatz Z gelesen - die zweite Transaktion T2 ändert diesen Datensatz Z - die Transaktion T2 wird commited - erneutes Lesen von Z durch die Transaktion T1 ergibt einem ungültigen Wert - Non-Repeatable Read nonrepeatable Transaktionsablauf read User T1 SELECT SELECT Daten Z User T2 UPDATE COMMIT Phantom Read - die Transaktion T1 liest die Ergebnismenge der Daten Z (count = 2) - die Transaktion T2 verändert die Anzahl Datensätze mit Insert / Delete - die Transaktion T2 wird committed - erneutes Lesen von Z durch die Transaktion T1 ergibt eine ungültige Ergebnismenge - Phantom Read phantom Transaktionsablauf read User T1 SELECT SELECT Daten Z 10 10,11 11,11,12 11,11,12 10,11,12 User T2 INSERT COMMIT 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 131 >> total: 255 Seiten

132 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Lost Update - innerhalb einer Transaktion T1 wird ein Datensatz Z gelesen - die zweite Transaktion T2 liest denselben Datensatz Z - die Transaktion T1 wird commited - die Transaktion T2 wird commited - erneutes Lesen von Z durch die Transaktion T1 ergibt einem ungültigen Wert - Lost Update lost Transaktionsablauf update User T1 SELECT COMMIT SELECT Daten Z User T2 SELECT COMMIT mögliche Vorkommen von Datenkonflikten durch Isolationsebenen mögliche Daten-Konflikte Isolationsebene Non Dirty Lost Phantom Repeatable Read Update Read Read Read Uncommitted Read Committed Repeatable Read Serializable - mit zunehmendem Isolationsgrad - sicherere Transaktion - schlechtere Performance, da mehr Sperren innerhalb der Datenbank 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 132 >> total: 255 Seiten

133 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement kontrollierbar durch Lock Strategien - DB LOCK {TABLE TABLES <table name> [AS <alias>] {READ [LOCAL] [LOW_PRIORITY] WRITE [{, <table name> [AS <alias>] {READ [LOCAL] [LOW_PRIORITY] WRITE...] - Funktionalität public void lock(object entity, LockModeType lockmode); - public void getitem(item i) {.. Lock Strategien - Pessimistic vorsorglich sperren - Optimistic meistens geht es gut 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 133 >> total: 255 Seiten

134 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement 16.2 Propagation wiki Unter Propagation oder Propagierung (von Lateinisch propagare ausdehnen ) versteht man im weitesten Sinne eine Ausdehnung. Propagations Bezeichnung Verhalten PROPAGATION_MANDATORY ON_MANDATORY erfordert eine laufende Transaktion Exception PROPAGATION_NESTED erfordert eine eigenständige Transaktion PROPAGATION_NEVER erlaubt keine offene Transaktion Exception PROPAGATION_NOT_SUPPORTED unterbricht eine offene Transaktion PROPAGATION_REQUIRED ATION_REQUIRED startet eine neue oder übernimmt eine bestehende Transaktion PROPAGATION_REQUIRES_NEW startet eine neue Transaktion PROPAGATION_SUPPORTS übernimmt eine geöffnete Transaktion - ermöglicht feingranulares Transaktionssverhalten Transaktionspropagation Bezeichnung aufrufende Methode weiterführende Methode NotSupported, Supports, Never Required, RequiresNew Mandatory NotSupported Supports, Required, Mandatory RequiresNew, Nested Never 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 134 >> total: 255 Seiten

135 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement 16.3 JTS Java Transaction Service - JTS spezifiziert die Implementierung eines Transaktionsmanagers TransaktionsManager anager - realisiert die Koordination von Transaktionen - Start, Abbruch und Abschluss - Realisierung globaler, verteilter Transaktionen - verwaltet die beteiligten Ressourcen einer globalen Transaktion RessourceManger - koordiniert Zwei-Phasen-Commit-Protokoll - kooperiert mit anderen Transaktionsmanagern RessourcenManager - kontrolliert transaktionsunterstützende (XA-kompatible) Ressource 16.4 JTA Java Transaction API - JTA spezifiziert die Programmierschnittstelle - für EJB, JDBC, JMS, JTS - Zugriff erfolgt mit der Java Transaction API Schnittstelle - besteht aus mehreren Interfaces - javax.transaction.usertransaction - Transaktion starten begin() - Transaktion abbrechen rollback() - Transaktion abschliessen commit() - Transaktionsstatus lesen getstatus() - Rollback erzwingen setrollbackonly() - Timeout setzen settransactiontimeout(sec) - javax.transaction.transactionmanager - laufender Transaktionscontext holen gettransaction() - laufende Transaktion anhalten suspend() - Transaktion wieder aufnemen resume(t) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 135 >> total: 255 Seiten

136 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement 16.5 Transaktionshandling wiki Als Konsistenz bezeichnet man bei Datenbanken allgemein die Widerspruchsfreiheit von Daten. Konsistenz ist eine der vier in Datenbank-Transaktionen geforderten ACID-Eigenschaften Eigenschaften. Transaktionen müssen Datenbanken von einem konsistenten in einen anderen konsistenten Zustand überführen. Während der Verarbeitung der Anfrage kann die Konsistenz der Datenbank jedoch durchaus verletzt sein. - ACID-Prinzipien eingehalten Konsistenz - EJB-Spezifikation definiert zwei Typen - explizite bean-managed transactions - implizite container-managed transactions Bean Managed Transaction steuert Transaktionen explizit direkt - durch das JTA Inteface UserTransaction - Transaktionen mit anderen EJBeans - Transaktionen mit Datenbanken über JDBC Deklarativ ejb-jar.xml <enterprise-beans> <session> <ejb-name>bankbean</ejb-name> <transaction-type>bean</transaction-type> <session> public class BankBean implements Bank { / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 136 >> total: 255 Seiten

137 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Steuerung der Transaktion mit UserTransaction-Objekt - als JNDI lookup ic = new InitialContext(); UserTransaction ut = (UserTransaction) ic.lookup("java:comp/env/usertransaction"); ut.begin();... - über SessionContext sc; UserTransaction ut = sc.getusertransaction(); - über public class KontoBean implements Konto UserTransaction ut; Container Managed Transactions - steuert Transaktionen implizit indirekt durch Container - kein zusätzlicher Code in die Geschäftslogik try-catch-blocks definiert Transaktion - Fehler (catch) führt alle schon durchgeführten Anweisungen zurück ROLLBACK - keine verschachtelten Transaktionen möglich CMT für public void transfereamount(konto fromaccount, Konto toaccount, Float amount) { try { withdrawamount(fromaccount, amount); depositamount(toaccount, amount); catch (Exception e) { public void withdrawamount(konto k, Float amount) { k.setsaldo(k.getsaldo() - amount); if (k.getsaldo() < 0) sc.setrollbackonly(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 137 >> total: 255 Seiten

138 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Annotationen für die Transaktionssteuerung steuerung - auf Bean-Ebene C Parameter Beschreibung TransactionManagementType Transaktionsmanagement - auf Methoden-Ebene M Parameter Beschreibung TransactionAttribute AttributeType Type Transaktionsattribut Konstante CONTAINER BEAN Konstante REQIRED REQUIRES_NEW MANDATORY SUPPORTS NOT_SUPPORTED NEVER Default CONTAINER Default REQUIRED - Transaktions-Attribute - Required - die Bean soll immer in einer Transaktion laufen - RequiresNew - es wird immer eine neue Transaktion gestartet - Supports - die Methode wird zur Transaktion des Aufrufers einbezogen - Mandatory - diese Bean-Methode gehört immer zur Transaktion des aufrufenden Clients - NotSupported - diese Methoden können keine Transaktionen Transaktions-Attribut unterstützen oder erzeugen SLSB SFSB MDB - Never Required - die Methode darf nicht in eine Transaktion RequiresNew einbezogen werden - nicht alle Transaktions-Attribute lassen sich mit allen Beans nutzen - Tabelle zeigt Kombinationsmöglichkeiten Mandatory Supports NotSupported Never 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 138 >> total: 255 Seiten

139 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement 16.6 Application Exception - Unterscheidung von Exceptions - System Exception unchecked - Ausnahme der technischen Infrastruktur - Applikation Exception checked - Ausnahme der Geschäfslogik - checked müssen deklariert / gehandelt werden - Subklassen von java.lang.exception - unchecked müssen nicht deklariert / gehandelt werden - Subklassen von java.lang.runtimeexception Applikation Exception führen nicht automatisch zu einem transaktionalen Rollback - ExceptionKlasse muss annotiert werden C Parameter Beschreibung Typ Default rollback lback Rollbackverhalten bei einer Exception Boolean false Aufgabe negative Saldo durch Rollback verhindern - transfere von einem Konto zu einem anderen Konto - wird der saldo eines Kontos dabei negative Rollback (durch public void transferamount(konto from, Konto to, Float amount) { this.withdrawamount(from, amount); this.depositamount(to, private void withdrawamount(konto k, Float amount) { try { Konto debit = this.getkontobynr(k.getnr()); debit.setsaldo(debit.getsaldo() - amount); // Entity Manager synchronisiert DB if (debit.getsaldo() < 0) sc.setrollbackonly(); catch (Exception e) { throw new EJBException("Could not withdraw Amount"); finally { closedatabaseconnection(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 139 >> total: 255 Seiten

140 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement Aufgabe Konfiguration By Exception durch ApplicationException - unterschreiten der Kreditgrenze soll verhindert = true) public class SaldoBelowCreditLimitException extends Exception { public SaldoBelowCreditLimitException (String reason) { private void depositamount(konto k, Float amount) { try { Konto credit = this.getkontobynr(k.getnr()); credit.setsaldo(credit.getsaldo() + amount); this.updatekonto(credit); if (credit.getsaldo() < 0) sc.setrollbackonly(); if (credit.getsaldo() < Konto.saldoLimit) throw new SaldoBelowCreditLimitException("Saldolimite erreicht"); catch (Exception e) { throw new EJBException("Could not deposit Amount"); finally { closedatabaseconnection(); Aufgabe Kontotransfer als Transaktion - testen Sie das transaktionale Verhalten der EJBs mit einem Kontotransfer - explicit BMT Bean Managed Transaction - implezit CMT Container Managed Transaction - ApplicationException Transaktionsverhalten transfereamount() depositamount() withdrawamount() Transaktion REQUIRED REQUIRED REQUIRED REQUIRED REQUIRES_NEW REQUIRED_NEW SUPPORTS REQUIRED REQUIRED REQUIRED SUPPORTS SUPPORTS NOT_SUPPORTED REQUIRED REQUIRED NOT_SUPPORTED NOT_SUPPORTED NOT_SUPPORTED REQUIRED NEVER NEVER 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 140 >> total: 255 Seiten

141 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement O JPA Lerninhalte Begriffe Lebenszyklus Bestandteile Generatorstategien Beziehungen Assoziationen Vererbung Collections Queries Datentypen Transaktionen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 141 >> total: 255 Seiten

142 EJB 3.1 / JPA 2.0 >> Java Framework >> ORM Object-Relation-Mapping 17 ORM Object-Relation Relation-Mapping ORM bietet grundsätzlich folgende Vorteile - Produktivität Vereinfachung und Objektorientierung des Datenzugriffs - Wartbarkeit weniger Codezeilen - Nachvollziehbarkeit serverseitiger Cache - Performance automatisierte Erstellung der SQL Statements - Unabhängigkeit abstrahierter Datenbankzugriff 17.1 Begriffserklärungen EJB3 Version Spezifikation für Container Komponenten - Spezifikation für Managed Persistence Version 3.1 JSR 318 JPA Java Persistence API Version Spezifikation für O/R Mapping - Darstellung der Entitäten durch POJOs - nicht auf den Einsatz unter Java EE begrenzt - lauffähig unter Java SE / ausserhalb eines EE Containers JSR 220 Version 2.0 JSR 317 JBoss AS Hibernate - Implementation eines O/R Mapping Framework - Hibernate Core Definition mit XML - Hibernate Annotation Definition per Annotations - Hibernate Entity Manager Zugriff auf den Persistenzkontext 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 142 >> total: 255 Seiten

143 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA 18 JPA - spezifiziert durch JSR 220 / JSR spezifiziert Persistenz Framework - (Definition) aus Hibernate, TopLink und JDO entstanden - nicht auf den Einsatz unter Java EE begrenzt - lauffähig unter Java SE - als normale Java Anwendungen - ausserhalb eines Java EE Containers - Darstellung der Entitäten durch POJOs (Plain old Java Objects) - Definition der Metadaten durch Annotationen - XML (Deployment) Deskriptor-Dateien zur Angabe der Metadaten als Alternative - orm.xml (Deployment) Deskriptor-Dateien überschreiben Annotationen Ziel Java EE zu vereinfachen 18.1 Persistenz Provider - Entity - Java Repräsentation eines persistenten Datensatzes - Entity Class - Default Konstruktor - private Attribute - Getter- und Setter Methoden - Entity Manager - JPA Standard Interface - synchronisiert mit der Datenbank - Persistence Context - Menge aller Entitäten einer Transaktion - First Level Cache - Persistence Unit - Beschreibung von Entity-Klassen - Data-Source - entspechende Abbildungsinformationen - Database Transaction - garantiert ACID Verhalten der Datenbank 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 143 >> total: 255 Seiten

144 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Persistezprovider JPA Standard synchronisiert mit DB Entity Manager Datenbank Transaktion garantiert ACID der DB lädt / speichert arbeitet auf assoziiert mit Objekt Repräsen- tation eines Tupel Entity umfasst Persistenz Kontext Menge aller Entitäten einer Transaktion First-Level Level-Cache Instanz von bezieht sich auf POJO - serialisierbar - Default Konstruktor - private Attribute - getter / setter Entity Klasse umfasst Persistenz Unit - Entityklassen - Datasource - Abbildungsinfos Entities - leichtgewichtige, persistente Objekte als POJOs - zentraler Teil der Java Persistence API - abstrakte wie auch konkrete Java-Klassen werden verwendet - Vererbung, polymorphe Assoziationen und polymorphe Abfragen sind unterstützt - nicht von einer bestimmten Basisklasse abgeleitet - eigene Vererbungshierarchie kann verwendet werden - Bedingungen - muss einen parameterlosen Konstruktor enthalten public oder protected - muss eine Top-Level-Klasse sein nicht final - Methoden oder persistente Attribute dürfen nicht final sein - implementiert Serializable falls Instanzen "by-value" übertragen werden sollen - muss einen Primärschlüssel enthalten - Deklaration - mit - per XML orm.xml 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 144 >> total: 255 Seiten

145 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Deklaration einer Entity mit Annotations - Markierung der Klassenattribute - oder Markierung der public class Person implements Serializable private Long id; private String = Address.class) private Collection<Address> addresses; getter / setter / Konstructor / hashcode / equals public class Address implements Serializable private Long id; private String street; private String city; getter / setter / Konstructor / hashcode / equals / tostring Deklaration einer Entity per orm.xml - Schemadefinitionen Tabellenname, Spaltennamen, etc. - Relationen One:One, One:Many, Many:One, Many:Many - Vererbungsstrategien Single Table, Table per Class, Joined - Ladestrategien Objekte, Attribute - Generatorstrategien für den Primarykey Sequence, Table, Hi-Lo Algorithm, etc. <entity-mappings> <entity class="person"> <attributes> <id name="id"> <generated-value strategy="auto" /> </id> <basic name="name" /> <one-to-many name="adresses" target-entity="address" mapped-by="address"> </one-to-many> </attributes> </entity> </entity-mappings> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 145 >> total: 255 Seiten

146 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Persistenzunit - erzeugt EntityManager Factory - definiert durch persistence.xml - Persistenz Unit referenziert durch Logik Fassade BankBean - Data Source als Container Rescource - Properties ORM Mapping spezifisch Hibernate <?xml version="1.0" encoding="utf-8"?> <persistence xmlns=" xmlns:xsi=" xsi:schemalocation=" version="2.0"> <persistence-unit name="persistencecontext/bank"> <jta-data-source>java:jdbc/bank</jta-data-source> <properties> <property name="hibernate.dialect" value="org.hibernate.dialect.mysqldialect" /> <property name="hibernate.hbm2ddl.auto" value="create-drop" /> <property name="hibernate.show_sql" value="true" /> <property name="hibernate.format_sql" value="true" /> EntityManager - verwaltet die Entities - ist genau einem Persistenzkontext zugeordnet - als Container-Managed Entity Manager - als Application-Managed Entity Manager Container-Managed Entity Manager - innerhalb eines Java EE Containers - erzeugt und schliesst den Entity Managers - verwaltet JTA (Java Transaction API) Transaktionen - definiert durch Dependency Injection - z.b. JNDI lookup Java Naming and Directory Interface Application-Managed Entity Manager - wird von der Anwendung selbst verwaltet - aus EntityManagerFactory instanziiert - Transaktionen durch - JTA Java Transaction API - lokale Transaktion z. B. JDBC Transaktion 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 146 >> total: 255 Seiten

147 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Persistenzkontext - Menge aller Entitäten einer Transaktion - durch UC Use Case definiert - Cache - First Level Cache definiert durch Framework - public class Konto implements Serializable {... - Second Level Cache als fremde APIs JPA 2.0 Cache APIs Second Level Cache provider Cache Provider Read-Only Read-Write Nonstrict R-W Transactional EHCache OSCache Opensymphony JBossCache JBoss - Gültigkeitsdauer - transaction-scoped - entspricht der Dauer einer Transaktion - nach Abschluss der Transaktion wird der Persistenzkontext geschlossen - extended - ist unabhängig von einer Transaktion - kann mehrere Transaktionen umfassen - der Persistenzkontext muss manuell (Entity Manager) geschlossen werden //emf = EntityManagerFactory ist Application Managed //Neuen EntityManager erstellen EntityManager em = emf.createentitymanager(); em.gettransaction().begin(); //Transaktion starten Person p = em.find(person.class, new Long(1)); p.setname("mein_name"); p.setaddress(new Address("meine_Strasse", "mein_ort"); em.persist(p); em.gettransaction().commit(); //Ende der Transaktion 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 147 >> total: 255 Seiten

148 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA 18.2 Lebenszyklus - der Persistence Provider verwaltet die Zustände eines persistenten Objektes transparent - JPA definiert transparentes O/R-Mapping Framework - Entities ist ihr eigener Zustand nicht bekannt - es ist nicht direkt möglich, eine Entity nach ihrem aktuellen Zustand zu fragen Objektzustände eine Entity definiert vier verschiedene Zustände - New - neue Entity vorübergehend, flüchtig - Removed - gelöschte Relation gelöscht - Managed - synchronisierte Relation persistent, nicht flüchtig - Detached - unsynchronisierte Relation gelöst Entity Lifecycle new() remove() New garbage garbage find() getreference() getresultlist() getsingleresult() persist() merge()** refresh() Managed Removed persist() remove() remove() - JPA Objekt Zustandsdiagramm - Zustandsänderung durch Operationen des Persistenzkontext - Methoden der EntityManager-Instanz - Methoden der Query-Instanz persist() refresh() merge() * betrifft alle Instanzen des Persistenzkontext ** erzeugt persistente Instanz, Originalobjekt bleibt erhalten wirft Exception detach() close()* clear()* lock() merge()** Detached garbage persist() remove() refresh() refresh() merge() 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 148 >> total: 255 Seiten

149 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Entity ObjectState New - durch <new> erzeugtes Entity-Objekt aus normalem POJO - keine Verbindung zwischen der Entity und Entity Manager - Zustand der Entity nicht persistent abgespeichert - Garbage Collector entsorgt Objekte ohne Referenz - keine Repräsentation der Entity innerhalb der Datenbank - alle Daten der Entity sind flüchtig und gehen verloren Garbage Collector - Entities sind transient, nicht Teil einer Transaktion - Rollback nicht anwendbar in transaktionalem Kontext - Primärschlüsselfelder sind noch nicht gesetzt - werden durch den Persistenz-Manger erzeugt - persist() Übergang von New zu Managed - merge() Übergang von New zu Managed Entity ObjectState Managed - Entity wird von dem Entity Manager verwaltet - Entity hat einen Primärschlüssel zugewiesen - (auch ohne) Repräsentation innerhalb der Datenbank - persist() veranlasst keine Datenbankaufrufe - Entities im persistenten Zustand sind Teil einer Transaktion - Änderungen können durch Rollback rückgängig gemacht werden - Exception Rollback - Änderung von Attributen wird erkannt - setter SQL UPDATE - merge() synchronisiert persistente Entity durch den Entity Manager - Return-Wert ist synchronisierte Entity mit entsprechender Id - find() erzeugt persistente Entity - ohne Übergang von New nach Managed - detach() Übergang von Managed zu Detached - remove() Übergang von Managed zu Remove 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 149 >> total: 255 Seiten

150 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Entity ObjectState Detached - durch schliessen des Entity Managers close() - Zuordnung der Entities zum Manager endet - Entities sind nicht mehr Teil einer Transaktion - Änderungen werden nicht mehr mit Datenbank synchronisiert - Java-Objekte enthalten trotzdem (veraltete) persistente Daten - durch Serialisieren (und Übertragen) einer Entity in einen anderen Prozess - Transferieren des POJO in eine Remote-Anwendung Client-Request - als Transfer-Objekte zwischen Präsentationsschicht und Datenbankschicht - merge() Übergang von Detached zu Managed - Kopie der Entity wird wieder in Persistenzkontext aufgenommen - lock() Übergang von Detached zu Managed - unveränderte Entity wird wieder in Persistenzkontext aufgenommen - Parameter lockmode definiert verschiedene Lock-Modi in Verbindung mit Transaktionen Entity ObjectState Removed - Entity-Objekt für das Löschen markiert - wird am Ende der laufenden Transaktion gelöscht z.b. mit flush() - kann wieder in den managed Zustand aufgenommen werden persist() - persist() Übergang von Removed zu Managed remove() löscht die Daten der Entity innerhalb der Datenbank, Java-Objekt bleibt verfügbar, vorausgesetzt, es wird noch referenziert / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 150 >> total: 255 Seiten

151 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA 18.3 Bestandteile eines O/R Mapping Frameworks Entities - leichtgewichtige, persistente Objekte - lösen die schwergewichtigen Entity Beans ab - zentraler Teil der Java Persistence API - abstrakte wie auch konkrete Java-Klassen werden verwendet - Vererbung, polymorphe Assoziationen und polymorphe Abfragen sind unterstützt - nicht von einer bestimmten Basisklasse abgeleitet - eigene Vererbungshierarchie kann verwendet werden - Entities und Java-Klassen können beliebig kombiniert werden - Entity-Klasse muss mit der markiert werden - Entity-Klasse muss einen parameterlosen Konstruktor enthalten (public oder protected) - Entity-Klasse muss eine Top-Level-Klasse sein, darf nicht als final deklariert sein - Methoden oder persistente Attribute der Klasse dürfen nicht final sein - das Interface Serializable muss implementiert werden - falls Instanzen der Klasse "by-value" übertragen werden sollen - jede Entity muss einen Primärschlüssel enthalten Beschreibung durch Annotations - innerhalb der Entity-Klassen - die persistenten Attribute - mit Mapping- und anderen Metadaten - Markierung der Klassenattribute - Markierung der Getter-Methoden Die Markierung persistenter Attribute muss innerhalb einer Klassen- Hirarchie identisch sein. Als Typen von persistenten Attributen gelten: - alle primitiven Javatypen und deren Wrapperklassen / java.lang.string - serialisierbare Javaklassen (z. B. java.math.biginteger, java.math.bigdecimal, etc.) - selbstdefinierte serialisierbare Javaklassen - Enumerations - java.util.collection, java.util.set, java.util.list, java.util.map - Collections von Entity-Klassen - Embeddable Klassen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 151 >> total: 255 Seiten

152 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Primärschlüssel - einfaches Attribut der - alle primitiven Javatypen - java.lang.long / java.lang.string / java.util.date / java.sql.date - java.math.biginteger / java.math.bigdecimal Praxis? - - die Klasse muss das Serializable Interface implementieren - die Methoden equals und hashcode müssen definiert werden - die Klasse muss public sein und einen parameterlosen Konstruktor enthalten - zusammengesetzter - Instanzvariable vom Typ der Primärschlüsselklasse wird definiert als Embeddable Klasse - Entity-Klasse enthält einzelne Felder des Primärschlüssels Innerhalb einer Vererbungshierarchie von Entities darf nur ein Primärschlüssel definiert werden. Auss sserdem muss er in der obersten Klasse der Hierarchie deklariert sein Beziehungen zwischen Entities Embeddable Klassen - durch die markiert - dieselben Bedingungen wie die Entity-Klasse - keinen Primärschlüssel - die persistenten Attribute der embedded Klasse werden auf die gleiche Tabellenzeile wie die der Entity Klasse gemappt - embedded Klasse gehöret zur Entity und kann nicht von mehreren Entity Objekten referenziert werden Sekundärtabellen - deklariert Instanzvariable als Value-Typ - bildet Value-Typ in eigene Tabelle ab Relationship - 1 : - 1 : n / n : - n : 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 152 >> total: 255 Seiten

153 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA uni-direktio direktionale Beziehungen - vom Anwenderfall definiert UCs - einfachere Strategie bi-direktionale Beziehungen - unterscheiden zwischen "Besitzer" und der referenzierten Seite - Besitzer durch Userverhalten (UC) definiert - referenzierte Seite muss auf ihren Besitzer durch mappedby public class Person implements Serializable private Long private = "Adresse") public class Address implements Serializable private Long = "address") private Collection<Person> persons; Vererbung - Polymorphe Assoziationen - als Beziehungen auf verschiedene konkrete Klassen innerhalb einer Vererbungshierarchie - Polymorphe Abfragen - liefern verschiedene konkrete Klassen einer Vererbungshierarchie zurück - können sich auf abstrakte Entities beziehen - liefern immer Instanzen von konkreten Subklassen als Ergebnis - abstrakte Klassen - können definiert werden - können nicht direkt instanziiert werden - MappedSuperclass - deklariert Superklasse einer Entity - wird nicht direkt einer Tabelle zugeordnet - Attribute werden auf die Tabellen der abgeleiteten Entity-Klassen gemappt - kann nicht direkt mittels einer Abfrage gesucht werden - Verwendung in einer Entity-Relationship ist nicht direkt möglich 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 153 >> total: 255 Seiten

154 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Vererbungsstategien - SINGLE_TABLE - eine Tabelle für die ganze Hierarchie - Diskriminator Spalte - Polymorphe Abfragen sind möglich - TABLE_PER_CLASS - Eine Tabelle pro konkreter Entity-Klasse - Unterstützung durch Implementierung optional - jede Tabelle enthält ALLE Attribute - inklusive der geerbten - keine polymorphen Abfragen möglich - SQL UNION als Behelf - JOINED - eine Tabelle je Superklasse und je abgeleitete Entity-Klasse - eine Tabelle je Klasse einer Vererbungshierarchie - jede Tabelle enthält spezifische Attribute der jeweiligen Klasse - polymorphe Abfragen sind möglich (nicht sehr performant) 18.5 Persistenzkontext - erzeugt EntityManager Factory - definiert durch persistence.xml - durch Dependency Injection - in der Fassade BankBean 18.6 EntityManager - verwaltet die Entities - stellt die API für den Zugriff auf einen Persistenzkontext bereit - einem Entity Manager ist immer genau ein Persistenzkontext zugeordnet - Container-Managed Entity Manager - Application-Managed Entity Manager Persistenzkontext bezeichnet Menge von Entity-Objekten die innerhalb der Datenbank höchstens ein Java-Objekt im Kontext repräsentieren / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 154 >> total: 255 Seiten

155 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA EntityManager definiert: - Entity-Lifecycle - auch durch EM Lifecycle - Praxis Transaktion - Praxis Use-Case - Queries - NamedQueries - wiederverwendbar - NativeQueries - ANSI SQL - CriteriaQuerie - OO Ansatz - Finderfunktionalitäten - wenn PK bekannt - Ladestategien - transaktionales Verhalten - feingranular - sperren lock - erweitern join Container-Man Managed aged Entity - kommen innerhalb eines Java EE Containers zum Einsatz - Container ist für das Erzeugen und Schliessen des Entity Managers verantwortlich - der Java EE Container verwaltet JTA Java Transaction API - Verwaltung geschieht transparent für die Anwendung - Zugriff auf den Entity Manager erhält die Anwendung durch - Dependency Injection - JNDI Application-Managed Entity Manager - Entity Manager wird von der Anwendung verwaltet - zum Erzeugen wird eine EntityManagerFactory verwendet - Transaktionen durch - JTA Java Transaction API - lokale Transaktion z.b. JDBC Transaktion 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 155 >> total: 255 Seiten

156 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Gültigkeitsdauer eines Persistenzkontexts - transaction-scoped - entspricht der Dauer einer Transaktion - Transaktion definiert den PersistenceContext - der Persistenzkontext wird geleert - die Entities detached und numanaged - extended - ist unabhängig von einer Transaktion - aber nur innerhalb der JVM gültig Applikationserver - kann mehrere Transaktionen umfassen - Persistencekontext bleibt erhalten - Entities werden automatisch synchronisiert - persist() oder merge() ist nicht notwendig - Persistenzkontext wird manuell verwaltet - durch Schliessen des Entity Manager Methoden der EntityManager API (Ausschnitt) public void persist(object entity); - Übergang zu managed Entity Instanz commit() / flush() persistiert Objekt - ist entity eine neue Entity wird diese zur managed Entity - ist entity eine bestehende managed Entity so wird nichts geschehen - ist entity eine removed Entity wird diese zur managed Entity - ist entity eine detached Entity wird eine IllegalArgumentException geworfen - gilt auch für relationale Felder von entity die mit CascadeType.PERSIST annotiert sind public void remove(object entity); - Übergang zu removed Entity Instanz commit() / flush() löscht Objekt - ist entity eine neue Entity so wird nichts geschehen - ist entity eine bestehende managed Entity so wird diese gelöscht - ist entity eine removed Entity so wird nichts geschehen - ist entity eine detached Entity wird eine IllegalArgumentException geworfen - gilt auch für relationale Felder von entity die mit CascadeType.REMOVE annotiert sind 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 156 >> total: 255 Seiten

157 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA public void refresh(object entity); - synchronisiert die Entity Instanz mit der Datensource überschriebt Entity - ist entity eine neue Entity wird eine IllegalArgumentException geworfen - ist entity eine bestehende managed Entity so wird diese mit der Datensource synchronisiert - ist entity eine removed Entity wird eine IllegalArgumentException geworfen - ist entity eine detached Entity wird eine IllegalArgumentException geworfen - gilt auch für relationale Felder von entity die mit CascadeType.REFRESH annotiert sind public <T> T merge(object entity); - Übergang von einer detached Entity zu einer managed Entity Instanz - ist entity eine detached Entity so wird diese in die existierende managed Instanz von entity kopiert oder eine neue Kopie einer managed entity Instanz erstellt - ist entity eine neue Entity so wird eine neue managed Instanz entity* als Kopie erstellt - ist entity eine bestehende managed Entity so wird nichts geschehen - ist entity eine removed Entity wird eine IllegalArgumentException geworfen - gilt auch für relationale Felder von entity die mit CascadeType.MERGE annotiert sind public void detach(object entity); - Übergang zu einer detached Entity Instanz - ist entity eine bestehende managed Entity so wird diese zu einer detached Entity - ist entity eine detached Entity so wird nichts geschehen - gilt auch für relationale Felder von entity die mit CascadeType.DETACH annotiert sind public void lock(object entity, LockModeType mode); - Sperrt die Entity Instanz - LockModeType.READ - andere Transaktionen können das Objekt lesen aber nicht ändern - LockModeType.WRITE - andere Transaktionen können das Objekt weder lesen noch schreiben 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 157 >> total: 255 Seiten

158 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA public <T> T find(class<t> entity, Object primarykey); - Sucht ein Objekt - lädt die entity aus der Datenbank, welche dem Primärschlüssel zugeordnet ist - liefert null, falls keine Entity gefunden wurde public <T> T getreference(class<t> entity, Object primarykey); - lädt ein Proxy (bzw. eine Referenz) einer Entity - durch den angegebenen Primärschlüssel eindeutig identifiziert - übrige Felder der Entity können zu einem späteren Zeitpunkt nachgeladen werden - Vorgehen ist sinnvoll, wenn eine Entity einer anderen zugeordnet werden soll und der eigentliche Inhalt gar nicht benötigt wird public boolean contains(object entity); - prüft ob sich die Entity im Persistenzkontext des Entity Managers befindet public void flush(); - synchronisiert die Datensource mit den Entity Objekten - weist den EntityManager an, den Zustand aller Entites die dem Persistenzkontext zugeordnet sind, mit der Datenbank zu synchronisieren - Synchronisation geschieht dabei nur in eine Richtung; der Inhalt der Entity-Objekte im Persistenzkontext wird nicht aktualisiert, falls sich der Inhalt der entsprechenden Datenbankfelder geändert haben sollte. - Synchronisation wird nur ausgeführt, wenn eine Transaktion aktiv ist public void clear(); - leert den Persistenzkontext des Entity Managers - Persistenzkontext des Entity Managers wird geleert - alle verwalteten Entities werden detached Entities - Synchronisation mit der Datenbank findet nicht statt 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 158 >> total: 255 Seiten

159 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Exception des EntityManagers Exception des EntityManagers EntityMangers Methoden -Exception Beschreibung Persistence- setzt Transaktionsstatus auf RollbackOnly EntityExists- PK existiert bereits EntityNotFound Found- IllegalArgument Entity existiert nicht (mehr) Argument- Objekt ist keine Entity OptimisticLock Lock- Rollback- Transaction- Required- DB Inhalt wurde geändert Rollback kann nicht durchgeführt werden persist keine laufende Transaktion merge remove find getreference flush refresh lock contains jointransction NoResult- NoUniqueResult Result- Query.getSingleResult() liefert kein oder mehr als ein Ergebnis, kein Rollback 18.7 Entity Listener - informiert über Ereignisse während des Lebenszyklus einer Entity - als Container Callback Methode - als Listener Klasse Listener als Container Callback - Interception durch Container - als Lifecycle Ereignis - erweitert Persistenzmechanismus durch eigene Funktionalitäten Container Callback als EnitiyListener Annotation vor der Ausführung von EntityManger.persist() / ostpersist ostremove nach der Ausführung von EntityManger.persist() / vor der Ausführung von EntityManger.update() / nach der Ausführung von EntityManger.load() / update() 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 159 >> total: 255 Seiten

160 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA Listener als Entity-Listener-Klasse - auf Klassenebene - Methoden werden automatisch aufgerufen - mehrere Methoden mit verschiedenen Callback Annotations können markiert werden - mehrfache Markierung einer Methode durch verschiedene Callback Annotations ist zulässig - jedoch nur eine Methode pro Ereignis - mehrere Listener pro Entity können definiert werden - Reihenfolge abhängig von Annotation - Entity Listener und Callback Methoden gemeinsam möglich - Methoden der Entity Listener werden vor den Callback-Methoden aufgerufen - Callback-Methode muss die folgende Signatur haben - o ist die Entity, auf die sich die Entity-Listener-Klasse bezieht void <METHODENNAME>() void <METHODENNAME> (<KLASSE> o) Verwendung von Callback-Methoden und = { PersonListener1.class, PersonListener2.class ) public class Person implements Serializable protected void postpersistperson() { System.out.println("PostPersist Person called"); public class protected void postpersistmethod1(person p) { System.out.println("PrePersist/PostPersist PersonListener1 called"); [STDOUT] PrePersist/PostPersist PersonListener1 called [STDOUT] PrePersist/PostPersist PersonListener1 called [STDOUT] PostPersist PersonListener2 called [STDOUT] PostPersist Person called public class PersonListener2 protected void postpersistmethod1(person p) { System.out.println("PostPersist PersonListener2 called"); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 160 >> total: 255 Seiten

161 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA 18.8 Queries - als SQL lesbar - durch JPA Query Language definiert polymorph - Massen-Updates und Deletes - Joins - Group By - Subqueries - JPA QL ist portable Datenbank Unabhängigkeit - Native SQL ist proprietär - mehrere Create Methoden stehen zur Verfügung - Query - polimorphe JPA Query liefert Entity Objekte - NativeQuery - native SQL Query liefert Tabelleninhalte - NamedQuery - wiederverwendbar, parametrisierbar durch die Entity definiert Beispiel NamedQuery - definiert durch @NamedQuery(name = "Person.findAll", query = "from Person = "Person.findByName", query = "from Person p where p.name = :name") ) public class Person implements Serializable {... - implementiert und parametrisiert durch die public class BankBean implements Bank = "persistencecontext/bank" ) private EntityManager manager; public void deleteperson(person p){ Person persontodelete = (Person) manager.createnamedquery("person.findbyname").setparameter("name", p.getname()).getsingleresult(); manager.remove(persontodelete); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 161 >> total: 255 Seiten

162 EJB 3.1 / JPA 2.0 >> Java Framework >> JPA ResultSetMapping - benutzerdefinierte Klasse als Resultset native - für komplexe Abfragen - für definierte Resultatlisten public PersonWithMultipleAccounts getpersonwithmultipleaccounts() { String query = "SELECT p.name, k.name FROM Person p, Konto k WHERE p.kontos.size > 2"; Query q = manager.createnativequery(query, "PersonWithMultipleAccounts"); return (PersonWithMultipleAccounts) q.getresultlist(); - definiert eigene ResultSetKlasse durch die Entity = "PersonWithMultipleAccounts", entities = = entity.person.class, fields = = "name", column = "name") = entity.konto.class, fields = = "name", column = "name") ) ) public class Person implements Serializable { / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 162 >> total: 255 Seiten

163 EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate 19 Hibernate - Open-Source-Persistenz- und ORM-Framework für Java - speichert POJOs mit Attributen und Methoden in relationalen Datenbanken - synchronisiert DB Relationen mit Objekten Vorteile - Abstraktion der verwendeten DB - dadurch DB Unabhängigkeit - nicht intrusiv - keine Ableitung eigener Klassen von Hibernate-Klassen erforderlich - keine Voraussetzungen an die Laufzeitumgebung - verwendbar managed und non-managed - Generierung von sehr effizientem SQL Nachteil - exponentieller Komplexitätsgrad 19.1 Hibernate als Persistenzframework - implementiert die standardisierten Annotations somit JPA kompatible - deklariert Bedingungen durch Validators - stellt mit dem EntityManager eine Persistenzengine zur Verfügung 19.2 Hibernate Annotations - Verwendung der Hibernate eigenen Annotations Erweiterung der Funktionalität - Metadaten im XML-Format hbm.xml, resp. orm.xml bei JPA - Lade- / Speicherverhalten - Kaskadierung - Validierung - Geratorstategien für den PrimaryKey Hibernate Annotations erweitern die Persistenzfunktionalität im Umgang mit Polymorphie,, Assoziations,, Collections und Queries. Hibernate Annotations sind immer eine Einschränkung nkung der Portabilität / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 163 >> total: 255 Seiten

164 EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate 19.3 Hibernate Validator - ermöglicht Deklaration von Bedingungen - die eine gültige Entity erfüllen muss - definiert Constraints - werden als Annotations direkt in der betroffenen Entity deklariert - Methoden wie auch Instanzvariablen können markiert werden - werden durch die Entity-Objekte überprüft z.b. durch Entity Listeners - Validator Implementierung führt die tatsächliche Überprüfung durch - Deklaration zentral durch die Entity - Überprüfung innerhalb einer mehrschichtigen Anwendung Hinernate Validatoren Ausschnitt @NotNull überprüfung auf @ überprüft s auf überprüft auf Digits Überprüfung von Stringlängen Min-, Maximalwert für numerische Werte überprüft, ob ein Datum in der Vergangenheit / Zukunft liegt überprüft, ob ein Attribut einem regulären Ausdruck entspricht Wertebereich für numerische Werte überprüfung der Länge von Collections, Arrays und Maps überprüft boolean Werte auf false überprüft boolean Werte auf true führt eine Überprüfung des markierten Objekts durch überprüft Kreditkartennummern auf true überprüft EAN-Nummern auf true 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 164 >> total: 255 Seiten

165 EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate Beispiel Validierung einer Instanzvariablen import org.hibernate.validator.length; import public class Person implements private String name; Beispiel Definition von HibernateConstraints public void createperson(person p) { ClassValidator personvalidator = new ClassValidator(Person.class); InvalidValue[] invalidvalues = personvalidator.getinvalidvalues(p); for (InvalidValue iv : invalidvalues) System.out.println(iv.getBean() + iv.getmessage()); manager.persist(p); Output [STDOUT] Person(id=null, name=testperson1, address=address(id=null, street=strasse1, city=ort1, persons=null), kontos=null) muss zwischen 0 und 10 lang sein 19.4 Hibernate EntityManager - implementiert durch die Java Persistence API - Einsatz innerhalb eines Java EE Containers - Einsatz als Standalone Lösung ausserhalb eines Containers - Hibernate EntityManager - setzt auf dem Hibernate Core auf - verwendet diesen als Persistenzengine 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 165 >> total: 255 Seiten

166 EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate 19.5 Hibernate Tools - Unterstützung bei der Entwicklung - Eclipse Integration - DDL Schema Generation hbm2ddl - von einer Hibernate Mapping-Datei - Java Source Generation hbm2java - von einer Hibernate Mapping-Datei - Middlegen - Generierung einer Hibernate Mapping Datei - Third Party Tool SQL Kategorie Beschreibung Anwendung Data Definition CREATE DDL Language DROP DML DCL DRL Data Manipulation Language Data Control Language Data Retrival Language UPDATE GRANT REVOKE SELECT 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 166 >> total: 255 Seiten

167 EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel 20 Kontoverwaltung als Anwendungsbeispiel - einfache Kontoverwaltung - Person als Kontoinhaber - Trustee als Kontoverwalter - Address - für Person - für Trustee - Account als Konto - Personal - Deposit - Euro - Anwendungsfälle - Hinzufügen - Inhaber - Verwalter - Konto - Verwaltungsfunktionen - Suchfunktionen 20.1 Konfiguration persistence.xml - definiert eine oder mehrere PersitenceUnits - JEE im Verzeichnis META-INF - JSE im Verzeichis WEB-INF/classes <?xml version="1.0" encoding="utf-8"?> <persistence xmlns=" xmlns:xsi=" xsi:schemalocation=" version="2.0"> <persistence-unit name="persistencecotext/bank"> <jta-data-source>java:jdbc/bank</jta-data-source> <properties> <property name="hibernate.dialect" value="org.hibernate.dialect.mysqldialect" /> <property name="hibernate.hbm2ddl.auto" value="create-drop" /> <property name="hibernate.show_sql" value="true" /> <property name="hibernate.format_sql" value="true" /> </properties> </persistence-unit> </persistence> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 167 >> total: 255 Seiten

168 EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel POJO als Entity - einfaches POJO Plain Old Java Object - Annotations der Java Persistence API vor der Klassendefinition - Getter- und Setter-Methoden - Java Nameskonventionen - id als eindeutigen Bezeichner für persistente Klasse Praxis: Long - annotiert - Standardkonstruktor auch private möglich für nicht persistente Felder C Parameter Beschreibung name Typ Default name Name der Entity String public class Person implements Serializable { Tabelle C Parameter Beschreibung name Typ Default name Tabellenname String Klassenname datenbankspezifisches schema Tabellenschema String Schema datenbankspezifischer catalog Tabellenkatalog String Katalog uniqueconstraint - Verwendung - anpassen an Legacy Unique-Constraints, die auf der Tabelle definiert werden = "Adresse") public class Address implements Serializable { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 168 >> total: 255 Seiten

169 EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel Fassade wiki Fassade (engl. facade de) ) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Strukturmuster (Structural ( Patterns). Es bietet eine einheitliche und meist vereinfachte Schnittstelle zu einer Menge von Schnittstellen eines Subsystems. - die Entities sind nicht remote ansprechbar - haben keine Schnittstellen - werden über eine Fassade angesprochen - SLSB / SFSB - durch EntityManger legt Abhängigkeit zu einer EntityManagerFactory / PersistenzUnit fest Referenzen auf den EntityManager C M F Parameter Beschreibung Typ name Name der EntityManagerFactory String unitname Name der PersistenzUnit String type Art des Kontextes PersistenceContextType - TRANSACTION - EXTENDET properties eine Liste von Eigenschaften PersistenceProperies[] properties Default TRANSACTION herstellungsabhängige Eigenschaften für eine Referenz auf den PersistenceContext C M F Parameter Beschreibung Typ Default name Name der Eigenschaft String value Wert der Eigenschaft String Liste von PersistenceContext Annotationen C Parameter Beschreibung Typ Default value Liste von PersistenceContext = "persistence/creditbank", unitname = = "persistence/debitbank", unitname = "debitbank") public class BankBean implements Bank { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 169 >> total: 255 Seiten

170 EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel Abhängigkeit zu einer EntityManagerFactory C M F Parameter Beschreibung Typ name Name der EntityManagerFactory String unitname Name der persistenten Einheit String Liste von PersistenceUnit Annotationen C Parameter Beschreibung Typ value value Liste von PersistenceUnits PersistenceUnit[] Default Default private EntityManager = "persistencecontext/bank") private EntityManager manager; Aufgabe Entities verwalten - erstellen und testen Sie Funktionalitäten der Bank Fassade - Entities erstellen und löschen public void createperson(person p) { manager.persist(p); public void createaccount(konto k) { manager.persist(k); public void deleteperson(person p) { Person persontodelete = (Person) manager.createnamedquery("person.findbyname").setparameter("name", p.getname()).getsingleresult(); manager.remove(persontodelete); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 170 >> total: 255 Seiten

171 EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel 20.2 Application scoped EntityManager - JPA kann ausserhalb eines JEE Umfeld (Applikationsserver) verwendet werden - SE Anwendung - als Session-Per-Request oder Session-Per-Conversation - Spring Anwendung - der EntityManager muss dabei selbst verwaltet werden Entity Manager selber verwalten - aus EntityMangerFactors instanziiert - einer Fassade injected // SetUp from persistence.xml EntityManagerFactory emf = Persistence.createEntityManagerFactory("BankJPA"); em = emf.createentitymanager(); JPABankRepository jpabr = new JPABankRepository(); jpabr.setentitymanager(em); em.gettransaction().begin(); Session-Per-Request Idee jeder Client Request definiert ein Persistenzkontext Ansatz EntityManager em = JpaUtil.getEntityManagerFactory().createEntityManager(); EntityTransaction tx = null; try { tx = em.gettransaction(); tx.begin();... tx.commit(); catch (Exception e) { if (tx!= null) tx.rollback(); throw e; finally { em.close(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 171 >> total: 255 Seiten

172 EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel Session-Per-Conversation Idee Persistenzkontext überlebt mehrere Client Requests Ansatz EntityManager em = JpaUtil.getEntityManagerFactory().createEntityManager(); EntityTransaction tx = null; try { tx = em.gettransaction(); // 1. Transaction tx.begin(); // starten Person p = em.find(person.class, new Long(1L)); // Entity laden tx.commit(); // 1. Transaktion wird beendet tx = null; p.setname("new Name"); // Entity wird verändert tx = em.gettransaction(); // 2. Transaktion tx.begin(); // starten em.lock(p, LockModeType.READ); // bindet die Entity an den EM em.flush(); // EM synchronisiert Entity tx.commit(); // 2. Transaktion wird beendet tx = null; em.close(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 172 >> total: 255 Seiten

173 EJB 3.1 / JPA 2.0 >> Java Framework >> Primarykey vs Businesskey 21 Primarykey vs Businesskey Anforderungen an Primärschlüssel - darf nicht null sein - kann nie verändert werden nicht sinvoll für einen natürlichen Schlüssel - ist in einer Tabelle über alle Einträge eindeutig Datenbankidentität, Objektidentität, Objektgleichheit - Objektidentität in Java Referenz-Semantic mit == - zwei Objekte sind identisch, wenn sie dieselbe Adresse im Speicher der Java VM haben - Objektgleichheit in Java Value-Semantic mit equals - zwei Objekte sind gleich, wenn sie denselben Inhalt public void referenceandvaluesemantic() { Person p = new Person("TestPerson", null); bank.createperson(p); Person newperson = bank.getperson("testperson"); assertfalse (p.getname() == newperson.getname()); // zwei Objekte assertfalse(p.equals(newperson)); // anderer Inhalt Praxis - equals() und hashcode() immer überschreiben - equals() soll geschäftsrelevante, eindeutige Daten vergleichen - hashcode() soll gute Verteilung definieren mehr, aber echte Daten - Problematisch bei - Objekte in Collections (Sets, Maps, etc.) - da Implementation durch java.util.hashset - einbinden von Detached Objekten - bestehendes Objekt wird durch Entity Manger verwaltet PKs werden generiert Beispiel an einer Adressen wohnen zwei Personen - Adresse wird mit einer Collection von zwei Personen erstellt - Objektgleichheit über Primärschlüssel bestimmt, überschreibt das erste Objekt beim Hinzufügen Address a = new Address("Strasse", "Ort"); Collection<Person> persons = new ArrayList(); persons.add(new Person("Person3", a)); persons.add(new Person("Person3", a)); bank.createaddress(a); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 173 >> total: 255 Seiten

174 EJB 3.1 / JPA 2.0 >> Java Framework >> Generatorstrategien 22 Generatorstrategien - persistente Datenbankobjekte haben eine Identität PK definiert Primary Key Attribut definiert Strategie zur Generierung des Primärschlüssels - zwei gleiche Objekte besitzen denselben Primärschlüssel - Verwalten der Primärschlüssel übernimmt Persistenz-Unit Praxisansatz PrimaryKey generieren in der Praxis sinnvoll - man muss sich nicht um PK kümmern oder FK - der Businesskey kann sich ändern z.b. AHV Nummer - der PK darf sich nicht ändern - Daten verlieren ihre Konsistenz - man arbeitet mit konkreten Daten Namen, Orte, etc. - PK ist oft ein Literal oder ein numerischer Ausdruck - oder eine Kombination beider 22.1 Generierung des Primary Key T Parameter Beschreibung strategy generator Strategie zum definieren des Primary Keys generator Name des Primärschlüsselgenerators String Parameter AUTO IDENTITY SEQUENCE TABLE Default AUTO verwendet die Strategy private Long public void createperson() { Person p = new Person(); p.setname("name"); bank.createperson(p); bank.createperson(p); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 174 >> total: 255 Seiten

175 EJB 3.1 / JPA 2.0 >> Java Framework >> Generatorstrategien Generatoren für die Primärschlüssel Strategie Beschreibung AUTO TABLE IDENTITY wählt entsprechend der darunterliegenden Datenbank eine Strategie (TABLE, IDENTIY, SEQUENCE). Entspricht der Hibernate-Generatorstrategie native. IDs sind in einer eigenen Tabelle. Entspricht der Hibernate-Generatorstrategie hilo Hi/Lo Algorithmus unterstützt Identity Columns, die es beispielsweise in MySQL, HSQLDB, DB2 und MS SQL Server gibt. Entspricht der Hibernate-Generatorstrategie identity. ENCE unterstützt Sequences, die es beispielsweise in PostgreSQL, Oracle und Firebird gibt. Entspricht der Hibernate-Generatorstrategie (strategy=generationtype.auto) private Long id; T Parameter Beschreibung name sequencename initalvalue allocationsize eindeutiger Name innerhalb der Persistence-Unit kann von anderen Entities referenziert werden Datenbank abhängiges Sequenz- Objekt Typ String String Default initalvalue Anfangswert für die Generierung int 0 oder 1 allocationsize Schrittweite int 50 abhängig = = "useridgen", strategy = "seqhilo", parameters = = "max_lo", value = = "sequence", value = "mysequence") ) private Long id; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 175 >> total: 255 Seiten

176 EJB 3.1 / JPA 2.0 >> Java Framework >> Generatorstrategien T Parameter Beschreibung name Typ name eindeutiger Name innerhalb der Persistence-Unit String table Tabellenname String schema Tabellenschema String catalog Tabellenkatalog String pkcolumnname Spalte für den Namen der Generatoren String valuecolumn umnname Spalte für den Zählerstand des PK String pkcolumnvalue Generatorname String Default initialvalue Anfangswert für die Generierung int 0 oder 1 allocationsize Schrittweite int 50 uniqueconstraints Definition von Constraints UniqueConstraint[] abhängig vom Persistence-Provider datenbankspezifisches Schema datenbankspezifischer Katalog abhängig vom Persistence-Provider abhängig vom Persistence-Provider abhängig vom Persistence-Provider 22.2 Definition des Primary Key - definiert eine Klasse als fachliche Kombination für den Primärschlüssel E Parameter Beschreibung value Typ value das Klassenobjekt der Primärschlüsselklasse public class Person implements Serializable private Long private String p_context; - definiert eine eingebettete Klasse als zusammengesetzten Primärschlüssel M, F Parameter Beschreibung Typ Default 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 176 >> total: 255 Seiten

177 EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen 23 Beziehungen - Beziehungen zwischen Klassen Relation zwischen Tabellen - Abbilden eines Objektmodells (Vererbung) durch Relationen in einem Datenmodel - Java Objekte werden in Relationen abgebildet - als Komponente - durch Assoziationen - uni-direktional - gibt führendes Ende an - N Seite als Collection - java.lang.list Reihenfolge der Elemente nicht - java.lang.set - java.lang.map - org.hibernate.mapping.bag Collections Eigenschaft List Set Map Bag duplikatfrei indexiert inverse performates Update performates es Inverse 23.1 Entity vs Value Komponenten Entity-Komponente - haben einen Primärschlüssel - haben einen Lebenszyklus Value alue-komponente - haben keine Datenbankidentität - haben keinen Primärschlüssel - gehören zu einer Entity und ihr Zustand wird innerhalb der Tabelle der dazugehörigen Entity gesichert - typisch sind einfache Objekte vom Typ String - Lebensdauer eines Value-Typ ist immer an den Lebenszyklus der enstpr. Entity gebunden Komponenten ermöglichen die Abbildung mehrerer Klassen auf eine Tabelle / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 177 >> total: 255 Seiten

178 EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen Komposition vs. Aggregation wiki Die Komposition (composite ( aggregation oder composition) ) als Sonderfall der Aggregation beschreibt die Beziehung zwischen einem Ganzen und seinen Teilen.. Der Unterschied zur Aggregation ist im Kern, dass die Existenz des Teil-Objektes durch die des übergeordneten Objektes bedingt ist. Ein Teil kann immer nur genau einem Ganzen zugeordnet sein. So kann z. B. ein Raum immer nur zu genau einem Gebäude gehören, nie zu keinem oder mehreren. - Komposition starke Bindung - ausgefüllte Raute - Aggregation schwache Bindung - nicht ausgefüllte Raute Die Komposition verstärkt gegenüber der Aggregation die Bindung einer Assoziation Value Komponenten Aggregation schwache Bindung - Objekt ist ein Teil eines anderen Objekts - Adresse kann auch ohne Person und alleine existieren - mit oder ohne Bezug zur Person Attribut Address.person Komposition strenge Bindung - die Lebensdauer des Objektes Address ist an das Objekt Person gebunden - eine Address wird immer mit oder nach dem Person erzeugt - und mit dem Objekt Person zerstört Die Implementierung mit Java macht keinen Unterschied. Aber Address ist für Persistenzprovider ein Value-Komponente Komponente,, hat also keinen Primärschlüssel. Komposition wird in UML mit einer gefüllten Raute dargestellt / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 178 >> total: 255 Seiten

179 EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen Embeddable - definiert Komponente auf Klassenebene - - Entity Person mit dem Attribut address muss nicht gekennzeichnet werden ist optional Aufgabe Emb Embedded Klasse - testen Sie die Adresse als public class Person implements Serializable // optional private Address public class Address implements Serializable { Sekundärtabellen deklariert Instanzvariable als Value-Typ definiert die Tabelle der Value-Komponente E Parameter Beschreibung Typ name Tabellenname String schema schema Tabellenschema String catalog catalog Tabellenkatalog String uniqueconstraint pkjoincolumns Unique-Constraints, die auf der Tabelle definiert werden sollen PKs der Tabellen über die die Beziehung hergestellt werden soll E Parameter Beschreibung value UniqueConstraint[] PrimaryKey- CoinColumn[] Typ value Liste von SecondaryTables SecondaryTable[ ] Default datenbankspezifisches Schema datenbankspezifischer Katalog alle PKs der Primärtabelle Default 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 179 >> total: 255 Seiten

180 EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen Column Persistenzprovider definiert als Spaltennamen für Komponenten den Attributnamen - definiert den Spaltennamen benutzerspezifisch definiert den Namen der Tabellenspalte T Parameter Beschreibung Typ Default name Spaltenname String Name des Attributs definiert eindeutiges Schlüsselfeld, kann alternative über unique uniqueconstraint auf Tabellenebene deklariert werden Boolean false nullable erlaubt Null-Werte, hat für primitive Java Typen keine Wirkung Boolean true insertable definiert die Insert-Funktionalität Boolean true updatable definiert die Update- Funktionalität Boolean true columndefinition Fragment der SQL Typendefinition String referenzierte Spalte table Namen der Tabelle, welche die Spalte enthält String Primärtabelle length Spaltengrösse nur für String anwendbar int 255 precision Anzahl Stellen nur für numerische Spalten int herstellerabhängig scale Anzahl Nachkommastellen nur numerische Spalten anwendbar int 0 scale Aufgabe SecundaryTable - testen Sie die Addresse mit Instanzvariablen als Sekundärtabellen - - persöhnliche adresse - - owned als = = "OWNED") ) public class Address implements Serializable = "personal_ ", table = " ") private String = "self_owned", table = "OWNED") private boolean owned; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 180 >> total: 255 Seiten

181 EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen Aufgabe Column - setzen Sie die Attribute der Adresse benutzerspezifisch mit Anotation - als unique - owned als = "personal_ ", table = " ", unique = true) private String = "self_owned", table = "OWNED", insertable = false) private boolean = EJBException.class) public void testreadonlyownedunique () { Address a = new Address("Strasse", "Ort", " @ .org", true); bank.createaddress(a); bank.createaddress(a); ERROR [org.hibernate.util.jdbcexceptionreporter] Duplicate entry ' @ .org' for key 'personal_ ' AttributeOverride - überschreibt die Definition eines Feldes in der Superklasse - ermöglicht Wiederverwendung der Komponente C F M Parameter Beschreibung Typ name Attribut String column C F M Parameter Beschreibung Typ value value Liste von AttributeOverride AttributeOverride[] Default Default Aufgabe public class Person implements Serializable name = "street", column = name = "city", column = "personcity", length = 50)) ) private Address address; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 181 >> total: 255 Seiten

182 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen 24 Assoziationen - Verbindung mindestens zweier Klassen - erlaubt das Navigieren von der einen zur anderen Klasse - binäre Assoziation ist eine Beziehung zwischen zwei Klassen - reflexive Assoziation definiert Beziehung zu sich selbst - Kardinalität beschreibt den Grad einer Beziehung zwischen zwei Klassen: - Eins-zu-Eins - eine Klasse steht mit einer anderen Klasse in Beziehung - Eins-zu-Viele / Viele-zu-Eins 1:n / - eine Klasse steht mit mehreren anderen Klassen in Beziehung - Viele-zu-Viele - mehrere Klassen stehen mit mehreren anderen Klassen in Beziehung - Bei allen Assoziationen unterscheidet man - unidirektionale Beziehungen - nur über eine Entity kann navigiert werden - bidirektionale Beziehungen - beidseitige Navigation möglich Entitys müssen beidseitig Getter und Setter definieren 24.1 Überschreiben von Assoziationen - Analog zum Re-Mapping von Attributen - Re-Mappen von Beziehungen überschreiben der FK C F M Parameter Beschreibung Typ name Attribut String joincolumns joincolumns Liste von C F M Parameter Beschreibung Typ value value Menge von AssociationOverride AssociationOverride[] name = "address", joincolumns public class Person implements Serializable { / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 182 >> total: 255 Seiten

183 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen 24.2 Überschreiben von Fremdschlüsselbezeichnungen F M Parameter Beschreibung name Typ Default name Spaltenname String Attribut definiert eindeutiges Schlüsselfeld, kann auch über unique Boolean false uniqueconstraint auf Tabellenebene deklariert werden nullable erlaubt Null-Werte, hat für primitive Typen keine Wirkung Boolean true nullable insertable updatable columndefinition referenced- ColumnName insertable definiert die Insert-Funktionalität Boolean true updatable definiert die Update-Funktionalität Boolean true columndefinition Fragment der SQL Typendefinition String ref. Spalte Name der Spalte auf die referenziert wird String ref. PK F M Parameter Beschreibung value Menge von JoinColumn Annotations Typ JoinColumn[] Default - bei 1:1 Beziehungen haben die beiden Tabellen den gleichen Primary-Key - Primary-Key selbst erzeugen nicht Business-Key verwenden - Generatorstrategie verwenden M F Parameter Beschreibung targetentity cascade fetch Typ Default targetentity Entitätsklasse Class Attributtyp cascade Angabe der Kaskadierungsoperationen CascadeType[] fetch definiert Ladeverhalten des Attribut FetchType EAGER optional mappedby erlaubt Null-Werte muss nicht Assoziation belegt sein hat für primitive Java Typen keine Wirkung definiert Attribut der führenden Entity bei bidirektionalen Beziehungen Boolean String falls keine Kaskadierung für die Beziehung definiert wurde ist ein expliziter Aufruf von persist() notwendig true 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 183 >> total: 255 Seiten

184 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen Aufgabe Primärschlüssel der Relation selbst erzeugen - kennzeichnet Address als 1-zu-1-Beziehung - beide in Beziehung stehende Objekte haben immer denselben Primärschlüssel - - als Unidirektionale 1-zu-1-Beziehung mit gemeinsamem public class Person implements private private Address public class Address implements Serializable private Long public void createpersonwithaddress() { Person p = new Person(); p.setname("name"); bank.createperson(p); persist(p) erzeugt einen Primärschlüssel für die Person id für die Entity Address muss selbst gesetzt werden bank.createaddress(new Address(bank.getPerson(p.getName()).getId(),"Strasse", "Ort")); assertequals("strasse", bank.getperson(p.getname()).getaddress().getstreet()); assertequals("ort", bank.getperson(p.getname()).getaddress().getcity()); Aufgabe bi-direktionale 1:1 Beziehung - Address kann Person referenzieren - Address.person annotiert - Attribut mappedby definiert die führende Entity auch die "owing" Seite der public class Person implements private private Address public class Address implements Serializable private Long = "address") private Person public void bidirektionalepersonaddressbeziehung() { Person p = new Person(); p.setname("name"); bank.createperson(p); bank.createaddress(new Address(bank.getPerson(p.getName()).getId(),"Strasse", "Ort")); assertequals("name", bank.getaddress("strasse","ort").getperson().getname()); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 184 >> total: 255 Seiten

185 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen - jedes Konto gehört einer Person - sonst existiert es nicht Komposition - eine Person hat mehrere Konten - eine Person kann auch kein Konto haben M F Parameter Beschreibung targetentity cascade fetch mappedby orphanremoval Typ Default targetentity Entitätsklasse Class Attributtyp cascade Angabe der Kaskadierungsoperationen CascadeType[] fetch definiert Ladeverhalten des Attributs FetchType LAZY mappedby definiert Attribut der führenden Entity String orphanremoval löscht die in Beziehung stehenden Entities mit boolean = CascadeType.PERSIST, fetch=fetchtype.eager) private List<Account> accounts; Parameter - cascade - Weitergeben der Persistenzfunktionalität an den in Beziehung stehenden Entities - fetch - Laden der in Beziehung stehenden Entities cascade Parameter Beschreibung value Typ Default value Cascade-Stategie CascadeType[] kein Durchreichen CascadeType Parameter Beschreibung ALL REMOVE PERSIST REFRESH MERGE alle Persistenzfunktionen des Entitymangers werden weitergereicht reicht Entitymanager.remove an die in Beziehung stehende Entity weiter reicht Entitymanager.persist an die in Beziehung stehende Entity weiter REFRESH reicht Entitymanager.refresh an die in Beziehung stehende Entity weiter reicht Entitymanager.merge an die in Beziehung stehende Entity weiter org.hibernate.annotations.cacadetype rnate.annotations.cacadetype definiert die Cascadierung feingranularer 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 185 >> total: 255 Seiten

186 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen fetch Parameter Beschreibung value Typ Default value Fetch-Stategie FetchType LAZY FetchType Parameter Beschreibung EAGER LAZY alle in Beziehung stehenden Entities werden sofort vollständig geladen die in Beziehung stehenden Entities werden erst bei Bedarf (nach-) geladen - Eager Load teuer: ressourcen- und zeitintersiv - Daten einer Entität werden sofort vollständig aus der Datenbank gelesen - in entsprechende Attribute geschrieben - alle referenzierten persistenten Objekte werden rekursiv instanziiert - sofort und vollständig aus der Datenbank geladen - Lazy Load sinnvoll bei grossen Datenmengen - Daten einer Entität werden erst aus der Datenbank geladen wenn ein entsprechender Zugriff darauf erfolgt - gilt auch für die referenzierte Objekte Lazy-Loading Loading-Strategie in der Praxis komplex unkla nklare Spezifikation - testen Sie die 1:N Bezehung - als Aggregation zwischen Person und = CascadeType.PERSIST, fetch=fetchtype.eager) private List<Account> public void createpersonwithaccounts() { Person p = new Person(); p.setname("name"); Account a1 = new Account("123-0", "Privatkonto", 100.0f, "CHF"); Account a2 = new Account("123-1", "Sparkonto", 200.0f, "CHF"); Account a3 = new Account("123-2", "Lohnkonto", 300.0f, "CHF"); List<Account> accounts = new ArrayList<Account>(); accounts.add(a1); accounts.add(a2); accounts.add(a3); p.setaccounts(accounts); bank.createperson(p); assertequals(3, bank.getperson(p.getname()).getaccounts().size()); - es wird dabei eine Verbindungstabelle <person_account> erstellt 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 186 >> total: 255 Seiten

187 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen 24.5 JoinColumn - definiert die Tabellenspalte als Fremdschlüssel der Beziehung M F Parameter Beschreibung name Typ Default name Spaltenname String Attributsname unique definiert eindeutiges Schlüsselfeld kann alternativ über uniqueconstraint auf Tabellenebene deklariert werden Boolean false nullable insertable updatable columndefinition erlaubt Null-Werte hat für primitive Java Typen keine Wirkung definiert die Insert-Funktionalität des Persistence Providers für dieses Attribut definiert die Update- Funktionalität des Persistence Providers für dieses Attribut columndefinition Fragment der SQL Typendefinition referenced- ColumnName Name der Spalte auf die referenziert wird Boolean Boolean Boolean String String true true true referenzierte Spalte PK der referenzierten Tabelle mit JoinColumn - referencedcolumnname definiert Name des referenzierten Feldes - testen Sie 1:N Beziehung mit einer JoinColumn - testen Sie ohne cascading und referencedcolumnname="id", nullable=false ) private List<Account> accounts; public void createperson(person person) { manager.persist(person); List<Account> accounts = person.getaccounts(); for (Account account : accounts) manager.persist(account); public Person getperson(string name) { Person person = (Person)manager.createNamedQuery("... person.getaccounts(); return person; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 187 >> total: 255 Seiten

188 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen - gleiche Konstellation - andere Sichtweise Account - Person M F Parameter Beschreibung targetentity cascade fetch Typ Default targetentity Entitätsklasse Class Typ des Attributs cascade Angabe der Kaskadierungsoperationen CascadeType[] fetch definiert Ladeverhalten des Attributs FetchType EAGER erlaubt Null-Werte optional gibt an ob die Assoziation belegt sein muss Boolean true hat für primitive Java Typen keine Wirkung - Account hat ein person Attribut als public class Account implements private Long = CascadeType.ALL, fetch = FetchType.EAGER, optional = false) private Person person; Besitzer der Assoziation - 1:N Beziehung durch Fremdschlüssel gemapped - N-Seite ist immer Besitzer der Assoziation Konto ist public class Person implements private Long cascade = CascadeType.ALL) private List<Account> accounts; - die Refernezielle Integrität muss manuell gesetzt public class Person implements Serializable { public void addaccount(account account){ this.accounts.add(account); account.setperson(this); public void removeaccount(account account){ this.accounts.remove(account); account.setperson(null); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 188 >> total: 255 Seiten

189 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen 24.7 Verbindungstabelle - kann auf alle Beziehungstypen angewendet werden - durch die definiert Tabellen- und Feldnamen - definiert Kompatibiltät zu bestehendem Schema - ermöglicht Nachvollziehbarkeit - durch zusätzliche Spalten in der Jointable z.b. Timestamp M F Parameter Beschreibung name schema catalog joincolumns inversejoincolumn Typ Default name Name der Relationstabelle String schema Tabellenschema String DB Schema catalog Tabellenkatalog String DB Katalog joincolumns PK Spalten der führenden Entity JoinColumn[] inversejoincolumn PK Spalten der nichtführenden Entity JoinColumn[] Unique-Constraints, die auf der uniqueconstraint Relationstabelle definiert werden sollen UniqueConstraint[] Aufgabe Beziehungstabelle - testen Sie die Person Konto Beziehung - definieren Sie eine JoinTable public class Account implements Serializable name = "T_PERSON_KONTO", joincolumns = name = "Konto_PK"), inversejoincolumns = = "Person_PK") ) private Person person; - testen Sie bi-direktional assertequals(3, bank.getperson(p.getname()).getaccounts().size()); assertequals("123-0", bank.getaccount("privatkonto").getnr()); assertequals("name", bank.getaccount("sparkonto").getperson().getname()); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 189 >> total: 255 Seiten

190 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen - werden immer durch eine Verbindungstabelle abgebildet M F Parameter Beschreibung targetentity cascade fetch mappedby Typ Default targetentity Entitätsklasse Class Typ des Attributs cascade Angabe der Kaskadierungsoperationen CascadeType[] fetch definiert Ladeverhalten des Attributs FetchType LAZY mappedby definiert Attribut der führenden Entity String - am Beispiel Verwalter public class Trustee implements private Long = "trustees") private List<Account> public class Account implements private Long = CascadeType.ALL, fetch = FetchType.EAGER) private List<Trustee> trustees; Auzfgabe Verwalter Konto - testen Sie die Beziehung - die JoinTable wird per Default aus den Namen der beiden Tabellen zusammengesetzt - beidseitig müssen die Funktionalitäten zur referenziellen Integrität ermöglicht werden public void addaccount(account account) { this.accounts.add(account); account.gettrustees().add(this); public void removeaccount(account account) { this.accounts.remove(account); account.gettrustees().remove(this); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 190 >> total: 255 Seiten

191 EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen 24.9 Transitive Persistenz - bezeichnet alle Objekte, die von einem persistenten Objekt erreichbar sind - durch Kaskadieren von Persistenzoperationen - erlaubt die Weitergabe von Entity-Operationen persist(), merge(), delete() - durch die Annotation CascadeType - bei = CascadeType.ALL) - A.persist() persistiert auch alle an A hängenden Objekte B - weitere CascadeTypes überschreiben die CascadeTypes der Java Persistence API - - definiert CascadeType = { org.hibernate.annotations.cascadetype.save_update, org.hibernate.annotations.cascadetype.replicate ) CascadeTypes JPA vs. Hibernate CascadeTypes JPA Hibernate PERSIST MERGE DETACH REMOVE PERSIST MERGE REMOVE REFRESH REFRESH Beschreibung Übergang managed Entity commit() oder flush() persistiert Objekt in der Datensource Übergang detached Entity zu managed Entity Übergang managed Entity zu detached Entity Übergang removed Entity commit() oder flush() löscht Objekt in der Datensource Synchronisiert die Entity Instanz mit der Datensource. Änderungen innerhalb der Entity werden dabei überschrieben entspricht javax.persistence.remove DELETE ALL entspricht casade = { PERSIST, MERGE, DETACH, REMOVE, REFRESH SAVE_UPDATE save(object entity) oder update(object entity) wird durchgereicht REPLICATE Objekt unter Verwendung der existierenden Id in der Datenbank persistiert DELETE_ORPHAN Objekte, die nicht mehr referenziert werden, werden gelöscht LOCK LockMode für pessimistisches Locking wird durchgereicht EVICT Objekt wird aus der Session gelöscht ALL Beinhaltet und SAVE_UPDATE, DELETE, EVICT und LOCK / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 191 >> total: 255 Seiten

192 EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung 25 Vererbung - JPA definiert drei verschiedene Vererbungsstrategien SINGLE_TABLE - eine Tabelle als flache Hierarchie - Unterscheidungsmerkmal ist eine Diskriminator-Spalte - Polymorphe Abfragen sind möglich TABLE_PER_CLASS optional - eine Tabelle pro konkreter Entity-Klasse - jede Tabelle enthält ALLE Attribute auch der Superclass - keine polymorphen Abfragen möglich SQL UNION als Behelf JOINED - eine Tabelle pro Klasse auch abstakte - eine Tabelle pro Klasse einer Vererbungshierarchie - polymorphe Abfragen sind möglich nicht performant 25.1 Single_Table - einfachste Möglichkeit Defaultstrategie - Klassen werden in einer einzigen Tabelle abgebildet - als flache Hirarchie bestimmt Vererbungsstrategie definiert Tabelleneintrag definiert Typ und Name der Discriminatorspalte - Typ definiert als Dtype pder String - Name beschreibt Vererbung, z.b: Sparkonto oder Privatkonto C Parameter Beschreibung strategy Typ strategy Vererbungsstrategie InheritanceType Default 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 192 >> total: 255 Seiten

193 EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung Annotations für die Vererbung C Parameter Beschreibung value Typ value Wert der Discriminatorspalte String Default C Parameter Beschreibung Typ name discriminatortype columndefinition lenght Default me Spaltenname String DTYPE Spaltentyp [STRING, CHAR, INTEGER] DiskriminatorTyp STRING Fragment der SQL Typendefinition String Spaltenbreite nur für STRING int 31 entsprechend referenzierte Spalte - MappedSuperclass definiert ein abstraktes Objekt in einer Vererbungsstrategie - ohne eigene Tabelle C Parameter Beschreibung Typ Default Aufgabe Single_Table - testen Sie die Vererbungsstategie Single_Table - abstrakte Klasse Konto bestimmt Vererbungsstrategie mit InheritanceType - konkrete Klassen = InheritanceType.SINGLE_TABLE) public abstract class Account implements = "Sparkonto") public class Deposit extends = "Privat") public class Personal extends = "Euro") public class Euro extends Account { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 193 >> total: 255 Seiten

194 EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung 25.2 Table_Per_Class - jede konkrete Klasse in einer eigenen Tabelle - Tabellen eindeutig den Entities zugeordnet Die Persistenzprovider sind gemäss JPA Spezifikation nicht verpflichtet, die TABLE_PER_CLASS-Strategie Strategie bereitzustellen. Aufgabe Table_Per_Class - testen Sie die Vererbungsstategie Table_Per_Class - abstrakte Klasse bestimmt Vererbungsstrategie - Tabellen für konkrete Entitäten erhalten auch die Attribute der = InheritanceType.TABLE_PER_CLASS) public abstract class Account implements = GenerationType.TABLE) private Long public class Deposit extends Account public class Personal extends Account public class Euro extends Account { - JBoss verlangt TABLE-Generation-Stategy bei "Mapped Tables" 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 194 >> total: 255 Seiten

195 EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung 25.3 Joined - jede abstrakte und jede konkrete Klasse hat eigene Tabelle - jede Tabelle hat einen Primärschlüssel - Primärschlüssel ist auch Fremdschlüssel zur Superklasse - optionale Definition möglich für Implementierungen anderer Persistenzprovider Aufgabe Joined - testen Sie die Vererbungsstategie Joined - abstrakte Klasse bestimmt Vererbungsstrategie - alle Objekt der Vererbungsstategie werden in eigenen Tabellen gemapped - abstrakte und = InheritanceType.JOINED) public abstract class Account implements private Long public class Deposit extends Account public class Personal extends Account public class Euro extends Account { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 195 >> total: 255 Seiten

196 EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung Zusammenfassung Vererbungsstrategien Vererbungsstrategie Strategie Begründung Single_Table Table_Per_Class Joined Vorteil Nachteil Vorteil Nachteil Vorteil Nachteil gute Performance, da polymorphe Abfragen nur immer eine Tabelle betreffen geeignet für wenig Attribute polymorphe Abfragen grosse Vererbungshierarchien erzeugen sehr grosse Tabellen redundante Spalten schlechte Datenintegrität da Felder der abgeleiteten Klassen NULL Werte haben geeignet für Vererbungshierarchien ohne polymorphe Abfragen und Beziehungen Abfragen auf konkrete Klassen sehr einfach und performant Tabellenstruktur ist abhängig von den Superklassen polymorphe Abfragen nicht optimal unterstützt Datenbankintegrität wird nicht verletzt Attribute in den Subklassen haben keine NULL Werte polymorphe Abfragen und Assoziationen sind möglich komplexe Abfragen schlechte Performance Abfrage auf eine konkrete Klasse benötigt Inner-Joins Vererbungsstategieren in der Praxis Vererbungsstategieren Eigeschaft SINGLE_TABLE TABLE_PER_CLASS JOINED wenig Attribute viele Attribute preformant polymorphe Queries ( ) nur konkrete Querries komplexe Hirarchie Querries nur auf eine Tabelle Union Select - Joined für Abfragen über alle Kontos sind Outer Joins notwendig SELECT a.name, a.saldo, a.currency, p.debitinterest, d.interest FROM Account AS a LEFT OUTER JOIN Personal AS p ON a.id = p.id LEFT OUTER JOIN Deposit AS d ON a.id = d.id WHERE... Inner / Outer Joins 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 196 >> total: 255 Seiten

197 EJB 3.1 / JPA 2.0 >> Java Framework >> Collections 26 Collections - Assoziationen zwischen Entities werden als Collections umgesetzt - auch Verwendung von Value Types - repräsentieren keine eigenständigen Entities innerhalb der Datenbank z.b. Liste von Strings - Collections als Attribute von persistenten Klassen - durch Deklaration des Typs als Interface Folgende Interfaces werden unterstützt: - java.util.set / java.util.sortedset - java.util.collection - java.util.list - java.util.map / java.util.sortedmap - selbst definierte Interfaces - org.hibernate.usertype.usercollectiontype Die Verwendung von Collections in persistenten Klassen erlaubt nur die unterstützten Interfaces. folgender Code wirft eine Laufzeit-Exception Verwalter v = bank.getverwalter(1l); Set kontos = v.getkontos(); // ok HashSet my_kontos = (HashSet) v.getkontos(); // RuntimeException - Hibernate als Persistenzprovider ersetzt HashSet während "persist" durch eigene Implementierung - dabei werden durch Entity referenzierte Collection-Instanzvariablen persistiert - und referenzlose Collection-Instanzvariablen werden gelöscht - daher hashcode und equals sinnvoll überschreiben - zwei Entities dürfen nicht auf gleiche Collection-Instanz verweisen - Hibernate unterscheidet nicht zwischen einer Null-Referenz auf eine Collection und einer leeren Collection 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 197 >> total: 255 Seiten

198 EJB 3.1 / JPA 2.0 >> Java Framework >> Collections 26.1 Collections mit Index - indexierte Collections z. B. List, Map oder Arrays - erlauben Zugriff über Index - definieren Indexspalte bzw. ein Key bei Maps - enthält den Index der Collection - List und Array erlauben nur Integer - Map erlaubt beliebiger Basistyp 26.2 Collection von Basistypen erlaubt eine Collection von Basistypen z.b. String M F Parameter Beschreibung Typ fetch targetclass Default fetch Ladestrategie der Collection FetchType LAZY targetclass referenzierte Klasse java.lang.class public class Euro extends Account implements private Set<String> coupons = new HashSet<String>(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 198 >> total: 255 Seiten

199 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen 27 Datenbankabfragen mittels Abfragen Entities in einer Datenbank finden - JPQL Java Persistence Query Language - mit dem Query Interface - zentrale Schnittstelle - DML INSERT / DELETE / UPDATE - DRL SELECT - Parametrisierung der Query - Iteration des Resultset - Flushing- / Lockingparameter - HQL Hibernate Query Language - starke, objektorientierte Abfragesprache - Criteria API - objektorientierte Abfragen - durch Aufruf einer normalen API formuliert - Native SQL - Abfragen per ANSI SQL formuliert 27.1 Query Interface - zentrale Schnittstelle zur Ausführung von Abfragen - immer wenn Primärschlüssel einer Entity nicht bekannt ist - bei PK EntityManager.find() oder EntityManager.getReference() - Suchkriterien zum Finden der Entities - Query-Instanz wird mit Hilfe des EntityManager erzeugt - String-Parameter muss eine gültige JPQL-Abfrage definieren - NativeQuery( ) definiert einen native SQL String datenbankspezifisch - Datenbankunabhängigkeit geht verloren public List<Konto> findaccountpersonaddress(string konto, String name, String city) { Query query = manager.createquery("select k FROM Konto k " + "WHERE k.name LIKE :konto AND k.person.name LIKE :name " + "AND k.person.address.city LIKE :city"); query.setparameter("konto", konto); query.setparameter("name", name); query.setparameter("city", city); return query.getresultlist(); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 199 >> total: 255 Seiten

200 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen Methoden des Query Interface QueryInterface Ausschnitt Methode Beschreibung List getresultlist( ( ) Object getsingleresult( ( ) int executeupdate( ( ) Query setmaxresults() Query setfirstresults() Query sethint() Query setparameter() Query setflushmode() Das Ergebnis wird als Liste zurückgegeben, das heisst, das Resultat der Abfrage befindet sich komplett im Speicher Ist von vornherein bekannt, dass eine Abfrage nur ein einziges Objekt zurück liefert, kann diese Methode verwendet werden, um den Umweg über die Liste zu sparen Ermöglicht UPDATE und DELETE Anweisungen, die sich auf eine ganze Reihe von Entity Beans auswirken könnnen. erlaubt ausschnittweises oder seitenweises Eingrenzen der Ergebnismenge setzen herstellerspezifischer Parameter, z.b. org.hibernate.timeout setzt die Parameter einer dynamischen Query setzt den Synchronisationsmodus AUTO synchronisiert Persistenzkontext und DB vor der Abfrage COMMIT Persistenzkontext synchronisiert erst bei COMMIT 27.2 Ausführen von Abfragen Query Interface liefert: - einfache Instanzen der entsprechenden Wrapperklassen Integer, Long, etc. - Object Array List<Konto> kontos = query.getresultlist(); Vector<Konto> inhaberkontos = new Vector<Kontos>(); for (Object o : kontos) { inhaberkontos.add((konto) o); - auch als benutzerdefinierter Arrays sinnvoll - = = "PersonWithMultipleAccounts", entities = = entity.person.class, fields = = "name", column = "name") ) ) public class Person implements Serializable { 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 200 >> total: 255 Seiten

201 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen 27.3 Eingrenzung der Abfrage - setmaxresults(int maxresults) grenzt die Ergebnismenge ein - setfirstresult(int firstresult) setzt einen Zeiger in der Ergebnismenge - Listenweise Ausgabe der Elemente public List<Konto> findaccountpersonaddress( String konto, String name, String city, int offset, int range) {... query. setfirstresult(offset). setmaxresults(range); 27.4 dynamische Abfragen - benannte Parameter public List<Konto> findaccountpersonaddress(string konto, String name, String city) { Query query = manager.createquery("select k FROM Konto k " + "WHERE k.name LIKE :konto AND k.person.name LIKE :name " + "AND k.person.address.city LIKE :city"); query.setparameter("konto", konto); query.setparameter("name", name); query.setparameter("city", city); 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 201 >> total: 255 Seiten

202 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen 27.5 NamedQuery - wiederverwendbar - für die Entity definiert - Definition per Metadaten - per Annotation - per XML orm.xml - als JPQL - auch als @NamedQuery(name = "Person.findAll", query = "from Person = "Person.findByName", query = "from Person p where p.name:=name") ) public class Person implements Serializable {.. Abfragen mit NamedQueries - durch die Fassade - parametrierbar public List<Person> findpersonbyname(string name) { Query query = manager.createnamedquery("person.findbyname"); query.setparameter("name", name); List<Person> persons = query.getresultlist(); return persons; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 202 >> total: 255 Seiten

203 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen 27.6 JPQL Java Persistence Query Language - Abfragesprache - nicht case sensitive - aber Javaklassen und Properties entsprechend korrekt angeben - objektorientiert - Abfragen von Objekten über deren Vererbungsbeziehung FROM Person - JPQL Abfrage der Entities vom Typ Person oder einem Subtyp - nativ SQL Abfrage der Daten aus der Tabelle Person 27.7 FROM - Abfrage der Entity-Klasse from entity.person from Person // Hibernate-Mappings Attribute auto-import = true (DEFAULT) from Person as p from Person p // mit Alias from Person, Konto // kartesisches Produkt 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 203 >> total: 255 Seiten

204 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen 27.8 WHERE - Einschränkung der Ergebnismenge from Person as p where p.name = 'Name' from Person where name = 'Name' from Person as p where p.name like '%Name%' Formulierung von Bedingungen - praktisch alle SQL bekannten Ausdrücke Bedingungen Ausdruck Beschreibung and, or, not logische Operatoren zur Verknüpfung von Ausdrücken +, -,, *, / mathematische Operatoren =, >=, <=, <>,!=, like Vergleichsoperatoren ( ) Klammern zur Gruppierung von Ausdrücken is null, is not null Vergleiche auf Null in, not in, between, is empty, is not empty, member of, not member of Ausdrücke zum Umgang mit Mengen und Bereichen (Collections etc.) case... when... then... else... end, case when... then... else... end Bedingungen mit Alternativen,, concat(...,...) String Verknüpfungen current_date(), current_time(), current_timestamp(), second(), minute(), hour(), day(),, month(), year() Verwendung von Zeit und Datum substring(), trim(), lower(), upper(), length(), locate() Verwendung von Strings abs(), sqrt(), bit_length(), mod() sonstige mathematische Operatoren str() Umwandlung in einen String cast(), extract() Casts zur Umwandlung in HQL-Datentypen size(), minelement(), maxelement(), minindex(), maxindex() sonstige Ausdrücke zum Umgang mit Collections sign(), rtrim(), sin() sonstige SQL-Funktionen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 204 >> total: 255 Seiten

205 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen Beispiele: from Person p where p.kontos.size > 3 // mit mehr als drei Konten from Person p where p.name between 'A' and 'M' from Person p where p.name in ('Markus', 'Martin') from Konto k where k.name like '%konto%' 27.9 ORDER BY - Sortierung der Ergebnismenge - nur über die aktuelle Klasse (Datenbank Tabelle) from Person order by name from Person order by name asc, konto.name desc 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 205 >> total: 255 Seiten

206 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen Verbundoperationen - liefern Kombinationen der beteiligten Entities - inner join / join 1:1-Zuordnung. Elemente ohne Zuordnung sind ausgeschlossen - left outer join / left join 1:1-Zuordnung. inklusive Elemente ohne Zuordnung der linken Tabelle - right outer join / right join inklusive Elemente ohne Zuordnung der rechten Tabelle - full join kartesisches Produkt select p, konto // alle Personen mit Konten from Person p inner join p.kontos konto select p, k from Person p inner join p.kontos k with k.name like '%konto%' FETCH Fetch Strategien durch die Abfrage definiert analog LAZY / EAGER - Fetch -Joins - erlaubt Abfragen von Beziehungen und Collections inklusive der "Parent Objects" - überschreibt "outer-join" und "lazy" Deklaration für Beziehungen und Collectionen - Einschränkungen von Fetch-Joins - Ergebnismenge kann nicht iteriert werden - with - Konstrukt nicht geeignet - setmaxresults() / setfirstresult() kann nicht verwendet werden - Duplikate der Parents sind möglich from Verwalter v left join fetch v.konten // mit fetch Strategie 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 206 >> total: 255 Seiten

207 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen SELECT - definiert Ergebnismenge der Objekte und Attribute select k from Person p inner join p.konten k // Instanzen der FROM Entities // also Konto-Instanzen select p, k from Person p inner join p.konten k // Liste von Object[] // Object[0] ist Person Object // Object[1] ist Konto Object select p, k.name from Person p inner join p.konten k // Liste von Object[] // Object[0] ist Person Object // Object[1] ist String Object - definiert Ergebnismenge der Objekte und Attribute select new list(i, k) from Inhaber i inner join i.konten k // List als Ergebnistyp select new InhaberKonto(i, k) // typisiertes Java Object from Inhaber i // InhaberKonto als Ergebnis inner join i.konten k // (selbst definierte Javaklasse) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 207 >> total: 255 Seiten

208 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen Aggregat-Funktionen - zur Konsolidierung oder Verdichtung der Ergebnismenge - distributive Funktionen - sum( ), min( ), max( ), count(*), count( ), count(distinct...), count(all...) - algebraische Funktionen - avg( ) select count(*) from Person // Anzahl aller Personen select count(distinct p.name) from Person p // Anzahl aller eindeutiger Namen GROUP BY - Gruppieren von Aggregat-Funktionen select t.name, count(k) from Konto k inner join k.trustee t group by t.name // Liste aller Verwalter // mit Anzahl Konten 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 208 >> total: 255 Seiten

209 EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen Polymorphe Abfragen - SQL kennt das Konzept der Vererbung nicht - JPQL unterstüzt polymorphe Abfragen - liefert Ergebnismenge von Entity-Instanzen einer gemeinsamen Vererbungshierarchie from Konto // liefert auch // Instanzen von Subklassen from java.lang.object // alle persistenten Objekte Subqueries - falls die darunterliegende Datenbank Subqueries verwendet from Konto kavg where kavg.saldo > ( select avg(k.size) from Konto k ) // Konten die mehr Saldo als // das Durchschnittskonto haben from Konto k // mit Wertemenge > 1 where not (k.nr, k.name) in ( select pk.saldo from Personal pk ) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 209 >> total: 255 Seiten

210 EJB 3.1 / JPA 2.0 >> Java Framework >> Datentypen 28 Datentypen - Datenbankzugriffe resultieren in Performance-Problemen - geeignete Fetching-Strategie wählen - geeigneter Typ wählen - Fetching-Strategy bei = FetchType.LAZY) private Object grossedatenmenge; - Fetching-Strategy bei = CascadeType.ALL, fetch = FetchType.EAGER) private Address address; - Fetch Join Syntax from [left [outer]] / [inner] join fetch association 28.1 Fetching-Strategien JPA Spezifikation definiert zwei Fetching-Strategien: - Lazy Loading - Daten erst laden wenn ein Zugriff auf das Attribut oder das Objekt erfolgt - Persistence Provider ist nicht verpflichtet Lazy Loading zu unterstützen - Umfang einer Umsetzung von Lazy Loading ungenau definiert - Eager Loading - Daten sofort vollständig laden JPA unterstützt tützt Lazy Loading - Entity muss vom EntityManager verwaltet werden - Zugriff auf nicht geladenes Attribut einer detached Entity wirft Exception Ladestrategien für Attribute M F Parameter Beschreibung fetch optional Typ Default fetch definiert Ladeverhalten des Attribut FetchType EAGER optional erlaubt Null-Werte, hat für primitive Java Typen keine Wirkung Boolean true 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 210 >> total: 255 Seiten

211 EJB 3.1 / JPA 2.0 >> Java Framework >> Datentypen Zusammenfassung Fetching-Strategien Fetching = FetchType.EAGER / = FetchType.EAGER / = FetchType.EAGER / = FetchType.EAGER / = FetchType.EAGER / LAZY) Defaultwert FetchType.EAGER FetchType.EAGER FetchType.EAGER FetchType.LAZY FetchType.LAZY JPQL Fetch Joins - Spezifikation definiert für JPQL-Abfragen Fetch Joins - Beziehungen zwischen Entities werden bei der Ausführung der Abfrage geladen - als Inner Join implementiert - Loading Strategie (EAGER / LAZY) anwendbar - Hibernate bietet zusätzliche Optionen - Batch-Fetching - Subselect-Fetching 28.2 grosse Objekte - umfangreiche Daten (Streams) werden in spezielle Datentypen abgelegt - meistens generische Objekte oder Strings deklariert Attribut als Large OBject - Datenbank ist verantwortlich für die Abbildung MySQL z.b. als BLOB BinaryLargeObject M F Parameter Beschreibung wird oft im Zusammenhang verwendet - um LazyLoading für Large Objects zu definieren. = FetchType.LAZY) private Object grossedatenmenge; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 211 >> total: 255 Seiten

212 EJB 3.1 / JPA 2.0 >> Java Framework >> Datentypen 28.3 Datums- und Zeitwerte - Datums- und Zeitwerte sind für die Speicherung in der Datenbank nicht vordefiniert - java.util.calender - java.util.date definiert Datenbankrepräsentation - DATE entspricht java.sql.date - TIME entspricht java.sql.time - TIMESTAMP entspricht java.sql.timestamp M F Parameter Beschreibung TemporalType definiert Speichertyp Typ DATE TIME TIMESTAMP Default private java.sql.date startdatum; 28.4 Aufzählungen - Java SE 5.0 kennt Aufzählungstyp ENUM deklariert Aufzählungstyp und definiert Art der Persistierung - ORDINAL : Wert wird als Zahl beginnend mit 0 gespeichert - STRING : Wert wird als String gespeichert M F Parameter Beschreibung value definiert Art der Persistierung ORDINAL oder STRING Beispiel Kontotyp als Aufzählungstyp Typ EnumType Default public enum KontoTyp { PRIVATKONTO, SPARKONTO, private KontoTyp kontotyp; 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 212 >> total: 255 Seiten

213 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionen der Persistence Unit 29 Transaktionen der Persistence Unit - verschiedene Anwendungsszenarien für transaktionale Operationen Patterns - basieren auf der Verwendung von - JDBC Connections - Java Transaction API (JTA) - optimistisches Locking - beim Schreiben wird geprüft ob sich die Daten verändert haben - implementiert durch die Verwendung von - pessimistisches Locking - lesender Client sperrt Daten - implementiert durch API die SELECT FOR UPDATE der Datenbank umsetzt - Repeatable-Read-Semantik definiert Caching innerhalb Persistenz-Session - dabei muss jede Datenbankoperation innerhalb einer Transaktion laufen - auch reine Leseoperationen - aktiver Auto-Commit-Modus wird (durch Hibernate) deaktiviert - sollte generell nicht in Verbindung mit Hibernate eingesetzt werden Verwendung von Transaktionen unterscheidet - managed innerhalb eines JEE Application Servers - BMT (Bean Managed Transactions) - CMT (Container Managed Transactions) - non-managed in einer JSE Anwendung - Spring - Web-Container 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 213 >> total: 255 Seiten

214 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionen der Persistence Unit 29.1 Optimistisches Locking optimistisches Locking bedeutet meistens geht alles gut - hohe Performance - gute Skalierbarkeit Praxis wenn keine Überschneidungen von Änderungen durch parallele Transaktionen - Auftreten einer Überschneidung wird durch aufwändige, manuelle Korrektur behoben - z.b. durch Versionierung der Datensätze Version Pattern / Timestamp in Tabelle - oder auch Last Commit Wins Verwirrungen seitens der User - manuelle Überprüfung mittels Versionsvergleich für jede Entity Version Pattern - Versionsattribut der Entities wird automatisch beim Commit hochgezählt - manueller Ansatz nur bei kleinen, trivialen Persistenzlösungen praktikabel - manuelle Überprüfung eines komplexen Objektgraphen nicht einfach 29.2 Versionsprüfung durch Version Number - Entity Manager prüft beim Speichern auf Zustandsänderungen der Daten - durch ein Commit aktualisiert - JPA definiert automatische Versionsüberprüfung durch Version-Attribut - annotiertes Attribut darf durch Applikation nicht verändert werden - Attribut wird bei jeder Veränderung hochgezählt M F Parameter private int version; Typ Default das Version Pattern ist durch die JPA Spezifikation implementiert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 214 >> total: 255 Seiten

215 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionen der Persistence Unit 29.3 Pessimistisches Locking Praxis bei häufigen Kollisionen zwischen konkurrierenden Transaktionen - restriktives Vorgehen verlangt - Tabellenzeilen werden explizit gesperrt - konkurrierende Transaktion erhält Fehlermeldung - konkurrierende Transaktion muss warten - verschlechtert Gesamtperformance des Systems aufgrund wartenden Transaktionen Locking-Mechanismus - um Deadlocks innerhalb der Datenbank zu vermeiden - Hibernate nutzt für pessimistisches Locking die Datenbank Funktionalität - Hibernate setzt nie Locks auf Entity-Objekte im Speicher! - Klasse LockMode definiert verschiedene Lock-Modi - es stehen nicht immer alle Modi zur Verfügung (Datenbankabhängig) - falls gewünschter Lock-Modus nicht unterstützt wird wählt Hibernate automatisch einen verwandten, verfügbaren Modus LockMode definiert verschiede Lock-Modus LockMode Parameter NONE READ UPGRADE UPGRADE_NOWAIT WRITE Beschreibung Es wird kein Lock auf Zeilen in der Datenbank gesetzt. Mit diesem Modus wird beim Lesen eines Datensatzes nur auf die Datenbank zugegriffen, wenn sich die entsprechende Entity nicht im Cache befindet. Dieser Lockmodus weist Hibernate an, direkt auf die Datenbank zuzugreifen und eine Versionsüberprüfung der betroffenen Entities durchzuführen. Sinnvoll z. B. bei Verwendung von Detached Entities. Dieser Lockmodus wird von Hibernate automatisch verwendet, wenn als Isolationsebene Repeatable Read oder Serializable ausgewählt wurde. Wird für pessimistisches Locking verwendet. Es wird mit SELECT... FOR UPDATE ein Lock auf die Tabellenzeilen gesetzt, wenn die Datenbank dieses Feature unterstützt. Verhält sich wie UPGRADE. Durch ein SELECT... FOR UPDATE NOWAIT, welches in Oracle Datenbanken verfügbar ist, wird die DB angewiesen, nicht darauf zu warten, falls die selektierte Tabellenzeile bereits gelockt ist, sondern eine Locking Exception zu werfen. Ein "interner" Modus, der automatisch von Hibernate verwendet wird, wenn ein Datensatz aktualisiert oder eingefügt wird. Dieser Modus kann nicht explizit durch den User verwendet werden. Lock-Modi erlauben pessimistisches Locking auf feingranularer Ebene 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 215 >> total: 255 Seiten

216 EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionen der Persistence Unit P Idioms Lerninhalte Design Pattern Idioms 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 216 >> total: 255 Seiten

217 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns 30 Design Patterns wiki Entwurfsmuster (engl. design patterns) ) sind bewährte Lösungs-Schablonen für wiederkehrende Entwurfsprobleme in Softwarearchitektur und Softwareentwicklung.. Sie stellen damit eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist. In den letzten Jahren hat der Ansatz der Entwurfsmuster auch zunehmendes Interesse im Bereich der Mensch-Computer Computer-Interaktion gefunden. Aber auch außerhalb der Informatik finden Entwurfsmuster immer mehr Eingang Zweck - Pattern heisst übersetzt Muster oder Beispiel - Design Patterns sind wiederverwendbare Lösungen - zu häufig auftretenden Problemen in der Software Entwicklung - Design Patterns kommen aus der Praxis - widerspiegeln die Erfahrung von Experten - Design Pattern erhöhen die Qualität der Software - erleichtern die Kommunikation zwischen den Entwicklern 30.2 Geschichtliches - Idee stammt ursprünglich aus der Architektur Alexander schreibt ein Buch über die Verwendung von Mustern in der Architektur Cunningham und Beck entwerfen fünf Patterns für die Programmierung von User-Interfaces - Durchbruch der Software Patterns Autoren Gamma, Helm, Vlissides und Johnson schreiben das Buch "Design Patterns" - ISBN , ISBN-10: , EAN: Addison Wesley Verlag, Juli Auflage / 504 Seiten das Buch "Design " Patterns" entwickelte sich zu einem der einflussreichsten Computerbücher überhaupt und ist auch unter dem Begriff GoF (Gang( of Four) bekannt 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 217 >> total: 255 Seiten

218 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns 30.3 JEE Pattern Im Zusammenhang mit JEE Applikationen sind spezielle Anforderungen erwünscht wie: - Transparenz - Stabilität - Performance JEE Entwurfsmuster stellen Idioms dar - also programmiersprache- und oft auch releaseabhängige Lösungen Idioms der Logik Tier - Business Delegate kaspselt Logik - Session Facade kapselt Komplexität - Service Locator kapselt Technologie - Service Activator kapselt teure Prozesse - Transfere Object kapselt Data Objekte - Transfere Object Assembler kapselt mehrere Transfere Objekte - Composite Entity kapselt Graphen von Data Objekten - Data Access Object kapselt Datenquelle - Value List Handler kapselt Queries und deren Resultate Die diskutierten Idioms sind nicht EJB/JPA spezifisch, sondern gelten im Umgang mit JEE Serverkomponenten / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 218 >> total: 255 Seiten

219 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns 30.4 Service Locator - Suche und Erzeugung von EJB ist zeitintensiv und fehleranfällig - Namensdienste (JNDI,...) - Komponentenverteilung (RMI-IIOP) - Factorycaching (Interfaces) Problem - Zugriff auf eine EJB teuer und fehleranfällig - Server wird referenziert - Name muss zuerst von einem DNS aufgelöst werden - Namensdienst wird initialisiert - benötigt produktspezifische Informationen - Verbindung zum Server wird hergestellt - basiert auf CORBA-Technologie Service Locator Idiom stellt ein Entwurfsmuster zur Kapselung der Technologie e und eine Performancesteigerung zur Verfügung. Lösung - bereits instanziierte Instanz des Proxy Objektes wird gecached - bereits instanziierte Ressourcen werden gecached - Handels (robuste Referenzen) werden gecached - JNDI Technologie wird transparent für den Client 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 219 >> total: 255 Seiten

220 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns 30.5 Business Delegate - Remotezugriff erfordert die Implementation entsprechender Technologie - z.b. RMI-IIOP - Client ist nicht an Technologie, sondern an Geschäftslogik interessiert - Business Delegate Idiom ermöglicht Kapselung der Technologie - Vereinfachung der Schnittstelle zur Geschäftslogik Problem - Zugriff auf die Geschäftslogik in einem EJB-Container erfordert Remotezugriff - viel komplexer und zeitintensiver als ein Lokalzugriff - Exceptions müssen abgefangen werden Business Delegate Idiom stellt ein Entwurfsmuster zur Kapselung der Business Services dar und entkoppelt die Presentation-Tier Clients. Lösung - die einzelnen Beans werden über eine zentrale Session Facade angesprochen - Facade hält die Instanzen der verschiedenen Business Services - stellt diese dem Client in einer Schnittstelle zur Verfügung - kann auch Informationen an die anderen Business Services weitergeben - Client produziert "Events" die vom Business Delegate "verteilt" werden - stellt einen einfachen Zugriff auf die Geschäftslogik zur Verfügung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 220 >> total: 255 Seiten

221 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns 30.6 Session Facade - Geschäftslogik liegt typischerweise im EJB Container - durch Komponenten (EJBs) abgebildet - Client muss Zusammenhang der einzelnen Komponenten im Container kennen - Client möchte eine Schnittstelle, die ein Use Case abbildet - korrekte Abbildung des Anwendungsfalles ist wichtig Problem - Entity Beans bilden persistente Objekte ab - repräsentieren aber lediglich den Zustand der darunterliegenden Datenbank - EJBs sind vom Client zu trennen zu kapseln - in Bezug auf Wiederverwendbarkeit - in Bezug auf Transaktionssteuerung - in Bezug auf Zustandserhaltung Session Facade Idiom kapselt die Container-Komponenten durch ein Session Bean Lösung - Abschirmung und Entkoppelung des Client vor Subsystemen EJBs - Erhalt der Unabhängigkeit der Subsysteme - Vereinfachung der Business Schnittstelle - Implementierung von allgemeinen Diensten wie Caching, Autorisierung, etc. - Zustandsverwaltung des Client - Transaktionssteuerung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 221 >> total: 255 Seiten

222 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns 30.7 JEE Entwurfsmuster JEE Idioms Entwurfsmuster Beschreibung Bedeutung für EJB Service Locator kapselt teure Technologien relevant Business Delegate kapselt Businesslogik, vereinfacht Zugriff obsolet, da keine RemoteExeptions Session Facade kapselt die Container Komponenten durch die Spezifikation erzwungen Value Object kapselt Business Data obsolet, Custom DTO relevant Message Façade Service Activator nutzt asynchrone Kommunikation relevant EJB Command Möglichkeit zur Gestaltung der Session Bean, relevant durch Entkopplung des Clients Business Interface stellt Konsistenz zwischen Beanklasse und Businessinterface sicher obsolet DTO Factory Erzeugung eines DTO durch Factory für Custom DTO relevant Data Transfer Hash Map generische Variante zum DTO relevant Value List Handler H serverseitiges Speichern von Ergebnismengen relevant Data Transfer Row Set disconnected RowSet für Serveranwendung ohne Entity Beans relevant Data Access Object kapselt den Datenbank Zugriff relevant, mit JPA jedoch leistungsfähiger Version Number Attribut kontrolliert Lost-Update-Problematik in Spezifikation integriert Muster zur Generierung von Primärschlüsselwerten Generierung von Business Keys in Spezifikation integriert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 222 >> total: 255 Seiten

223 EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns Q Regeln Lerninhalte EJB Programmierregeln 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 223 >> total: 255 Seiten

224 EJB 3.1 / JPA 2.0 >> Java Framework >> Programmiereinschränkungen 31 Programmiereinschränkungen die folgenden sieben Regeln sollten beachtet werden Threads 1 kein Thread Management oder Synchronisation in EJBs Container kontrolliert Lifecycle - ist Aufgabe des Applikationsservers - Bean = einzelner Thread, keine Kongruenz (Gleichheit) - Kontainer kontrolliert Nebenläufigkeit (Concurrency) 2 3 statische Variablen keine schreibenden Zugriffe auf Klassenvariablen durchführen Speicherort bei Cluster unklar - verschiedene Prozesse bei Cluster-Deployment - statische Attribute mit "final final" deklarieren AWT (Abstract Windwing Toolkit) kein stdin / stdout verwenden Ausgabe- / Eingabestream sind nicht definiert - Portabilitäts tätsproblematik 4 Dateizugriff kein direkter Zugriff auf Dateien nicht definierter Speicherort bei Cluster-Deployment - keine Verwendung von java.io-package / keine native Libraries 5 Socket-Listener keine Beans an Sockets binden Lifecycle cle nicht kontrollierbar - Container steuert Bean Life Cycle, daher Bean nicht als Socket Server einsetzen - Bean Instanzen dürfen Socket Clients sein 6 this keine this Referenz als Parameter oder Ereignis eines Methodenaufrufes Remotezugriff - SessionContext.getBusinessObject(Class businessinterface) benützen 7 Systemproperty EJBs dürfen Laufzeitumgebung nicht beeinflussen durch den Container kontrolliert - keine Class-Loader erzeugen, abfragen oder JVM anhalten oder Security Manager installieren 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 224 >> total: 255 Seiten

225 EJB 3.1 / JPA 2.0 >> Java Framework >> Programmiereinschränkungen R Deployment Deskriptoren Lerninhalte Deployment Deskriptoren 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 225 >> total: 255 Seiten

226 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren 32 Deployment Descriptoren - Beschreiben und Bereitstellen der serverseitigen Komponenten - Annotationen - Deployment Descriptoren (überschreiben Annotationen) ejb-jar.xml jar.xml Deployment-Descri Descriptor... <enterprise-beans> <entity> <ejb-name>anwendung1ejb</ejb-name> <home>anwendung1home</home> <remote>anwendung1</remote> <ejb-class>anwendung1bean</ejb-class>... </entity> <session> <ejb-name>anwendung2ejb</ejb-name> <home>anwendung2home</home> <remote>anwendung2</remote> <ejb-class>anwendung2bean</ejb-class>... </session>... </enterprise-beans> Verpackt in eine jar-datei (EJB 2.0) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD EnterpriseJavaBeans 2.0//EN" " <ejb-jar> Verpackt in eine jar-datei (EJB 2.1) <ejb-jar xmlns=" xmlns:xsi=" xsi:schemalocation=" version="2.1"> Verpackt in eine jar-datei (EJB 3.0) <ejb-jar xmlns=" xmlns:xsi=" xsi:schemalocation=" version="3.0"> Versionen unterscheiden zwischen DTDs und XML-Schema / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 226 >> total: 255 Seiten

227 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren 32.1 EJB Deployment Deskriptoren unterscheiden als: - Deployment Deskriptoren der Spezifikation - EJB - JPA - Vender-spezifische Deployment Deskriptoren - Oracle / Sun - JBoss - IMB / Webshere - Auschnitt von: - ejb-jar.xml EJB Standard - jboss.xml JBoss EJB Applikation - application.xml EJB Standard - application-client.xml EJB Standard - jboss-client.jar JBoss Client Applikation - jbosscmp-jdbc.xml JBoss Mapping ejb-jar.xml - beschreibt Bean auf logischer Ebene - Namen der Java-Klassen - Namen der Attribute - Transaktionsverhalten - Security Mapping - Spezifikation der Query-Methoden - Resource Referenzen - ejb-jar.xml ENC Elements (ENC = Enterprise Naming Context) - Name ejb-jar.xml - Ort META-INF-Verzeichnis der Jar-Datei - Root-Element ejb-jar 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 227 >> total: 255 Seiten

228 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren ejb-jar.xml Elementbeschreibung Element Beschreibung description? display-name? small-icon? large-icon? enterprisebean relationships? definiert CMP Beziehungen assembly ssembly- descriptor? ejb-client client-jar? Textbeschreibung der ejb-jar-datei Name, der von Tools benutzt wird Pfad, innerhalb der jar-datei, für jpeg-bilder (16x16) Pfad, innerhalb der jar-datei, für jpeg-bilder (32x32) nähere Beschreibung/ Definition der Beans definiert Transaktionen und Security definiert JAR-Datei, die Stubs und Interfaces für Remote-Clients enhält ejb-jar.xml Session Bean Elementbeschreibung Element Beschreibung ejb-name Spitzname des Beans, dient als Referenz ejb-class Session-Bean Klasse + Package-Name remote? Remote-Interface local? Local-Interface session-type Stateful Stateless transaction ion-type Container Bean description? Textbeschreibung der ejb-jar-datei display-name? Name, der von Tools benutzt wird small-icon? large-icon? env-entry* entry* Definition von Umgebungsvariablen ejb-ref* Definition von Referenzen zu anderen Beans ejb-local local-ref Definition von Referenzen zu lokalen Beans security-role role-ref* ref* definiert Sicherheitsrollen security-identity* identity* resource-ref* ref* definiert Referenzen zu Ressourcen (z.b. JDBC) resource-env env-ref* bindet Ressourcen-Factories zu JNDI Namen Pfad, innerhalb der jar-datei, für jpeg-bilder (16x16) Pfad, innerhalb der jar-datei, für jpeg-bilder (32x32) definiert wie Sicherheitskontexte ermittelt werden können 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 228 >> total: 255 Seiten

229 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren assembly-descriptor - ermöglicht die Festlegung von - Zugriffsberechtigungen - Transaktionen - generellem Zusammenspiel von Beans und einer Applikation ejb-jar.xml Assembly-Descriptor Elementbeschreibung Element Beschreibung security-role* role* definiert Security-Rollen method-permission* container ner-transaction* exclude-list? list? spezifiziert die einzelnen Methoden, und deren Zugriffsrechte Definition der Transaktionen, der einzelnen Methoden Liste von Methoden, die von niemandem aufgerufen werden dürfen 32.2 jboss.xml beschreibt Informationen für den Application Server - JNDI-Mapping: Name unter dem das Home-Interface gefunden wird - Resource Referenzen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 229 >> total: 255 Seiten

230 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren 32.3 jboss.xml ENC Elements - ENC Enterprise Naming Context <jboss> <enterprise-beans> <session> <ejb-name>moneyexchange</ejb-name> <jndi-name>ejb/moneyexchange</jndi-name> <resource-ref> <res-ref-name>jdbc/exchangetable</res-ref-name> <jndi-name>java:/mysqlds</jndi-name> </resource-ref> </session> </enterprise-beans> </jboss> 32.4 application.xml beschreibt eine ganze Enterprise Applikation - die graphische Repräsentation zeigt die Struktur des JEE application.xml Schemas 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 230 >> total: 255 Seiten

231 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren <?xml version="1.0" encoding="utf-8"?> <application xmlns:xsi= " xmlns=" xmlns:application= " xsi:schemalocation= " id="application_id" version="5"> <module> <ejb>bank.jar</ejb> </module> </application> 32.5 application-client.xml beschreibt First Tier Client Program - Client Beschreibung - Environment Entries - EJB Referenzen - Resource Referenzen - Resource Environment Referenzen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 231 >> total: 255 Seiten

232 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren 32.6 jboss-client.xml bescheibt Informationen für den Application Server - Versionsnummern - JNDI-Mapping Name unter dem das Home-Interface gefunden wird - Resource Referenzen <jboss-client> <jndi-name>moneyexchangeclient</jndi-name> <ejb-ref> <ejb-ref-name>ejb/moneyexchange</ejb-ref-name> <jndi-name>moneyexchange</jndi-name> </ejb-ref> </jboss-client> 32.7 jbosscmp-jdbc.xml beschreibt O/R-Mapping für die Datenbank applikationsserverspezifisch - Datasource Information für den DB-Connect im Application Server - jndi-name Name unter dem das Home-Interface gefunden wird <jbosscmp-jdbc> <defaults> <datasource>java:/defaultds</datasource> <datasource-mapping>mysql</datasource-mapping> <create-table>true</create-table> <remove-table>true</remove-table> </defaults> <enterprise-beans> <entity> <ejb-name>product</ejb-name> <table-name>producttable</table-name> </entity> </enterprise-beans> </jbosscmp-jdbc> 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 232 >> total: 255 Seiten

233 EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren S Trends Lerninhalte Agil Groovy DSL Domain Specifi Languages NoSQL Not Only SQL 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 233 >> total: 255 Seiten

234 EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma 33 Programmierparadigma Lat: <Paradigma Paradigma> = begreiflich machen, (para = neben) und (digma = zeigen) wiki Ein Programmierparadigma ist das einer Programmiersprache oder Programmiertechnik zugrunde liegende Prinzip. (einige) bekannte (Programmier)-Paradigmen - Strukturiert (WIE) - Imperativ (lineare Folge von Befehlen) - Prozedural (in Teilaufgaben zerlegt) - Modular (Module als logische Einheiten, Funktion und Daten) - Deklarativ (WAS) - Funktional (ergebnisorientiert) - Logisch (logikbasiert) - Orientiert (WOZU) - Objekt (Kommunikation, polymorph mehrere Formen) - Komponenten (abstrakt) - Aspekt (orthogonal freie Kombinierbarkeit unabhängiger Konzepte) - Agil (DRY Don't Repeat Yourself) Struktur Deklaration Orientation Agilität 33.1 Agiles Programmieren Lat: <agilis agilis> = flink, beweglich (Agile Softwareentwicklung reduziert Aufwand und Regeln) Skript- vs. Programmiersprachen Skriptsprache Ziel Einsatz Kombination bestehender Bausteine (Shell-Skript), Bibliotheken (Perl, Python) spezifisch: GUI (JavaScript), Reporting (Perl) Programmiersprache ache Neuentwicklungen (C, C++) allgemein Ausführung interpretiert oder Bytecode kompilierter Maschinencode Typisierung schwach, flexibel, dynamisch streng, flexibel Vorteile schnelle Entwicklung (Python), Prototypen (Shell-Skript), kleine Systeme (Perl) effiziente Anbindung, Ausnutzung von Ressourcen (C++, Java) 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 234 >> total: 255 Seiten

235 EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma Historie der Skriptsprachen AWK 1977 (Aho Weinberger Kernighan) JCL 1963 (Job Control Language) Sh 1978 (Bourne Shell) Perl 1987 (Practical Extraction and Report Language) Python (Monthy Python) Tcl 1988 (Tool Command Language) PHP (Personal Home Page) Ruby (Eng: Rubin) JavaScript (ECMA 262) Groovy 2003 (JSR 241) 33.2 Groovy wiki dynamisch typisierte Programmier- und Skriptsprache für die Java VM verbindet Java-Syntax mit den Konzepten von Ruby. Groovy ermöglicht: - pragmatisches (selbsterklärend) - extremes (code a little, test a little) - agiles (YWGWYS) - funktionales (funktionale Abhängigkeiten) - objektorientiertes (alles sind Objekte) - abstrahiertes (wieder verwendbarer Code) - effizientes (weniger Codeumfang) - einfaches (Syntax) Programmieren. Groovy Paradigmen Erscheinungsjahr 2003 Entwickler objektorientiert, Skriptsprache, teilweise deklarativ The Codehaus Aktuelle Version 1.7 (2010) Typisierung Betriebssystem Lizenz Groovy. Codehaus stark, statisch, dynamisch plattformunabhängig Open Source, Apache Software License / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 235 >> total: 255 Seiten

236 EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma 33.3 DSL Domain Specific Language wiki Eine domänenspezifische Sprache (engl. domain-speci specific language,, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) ) entworfen und implementiert wird. Beim Entwurf einer DSL wird man bemüht sein, einen hohen Grad an Problemspezifität zu erreichen: die Sprache soll alle Probleme P der Domäne darstellen können und nichts darstellen können, was auss sserhalb der Domäne liegt. Dadurch ist sie durch Domänenspezialisten ohne besonderes Zusatzwissen bedienbar. Idee - weniger Redundanz HTTP - deklarative Beschreibung eines Sachverhaltes - bessere Lesbarkeit - weniger technischer Code - domänenspezifische, statische Validierung - leichte Erlernbarkeit, aufgrund des beschränkten Umfangs http Deamon SQL DBMS DSL Domain DSL Domain 33.4 NoSQL (Not only SQL) wiki NoSQL is a movement promoting a loosely defined class of non-relational data stores s that break with a long history of relational databases. These data stores may not require fixed table schemas, usually avoid join operations and typically scale horizontally. im Web 2.0 (social Nertworking) sind schreibende Zugriffe wichtig (nicht nur lesende) - für Anwendungen, bei denen endgültige Konsistenz der Daten gewährleistet sein muss - Twitter - Facebook - traditionell: RDBMS - Constraints - Transaktionen - Locking - SQL - RDBMS haben Probleme mit der Verarbeitung und Skalierung grosser Datenmengen - neuer Ansatz - NoSQL z.b. "Key/Value" Storage 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 236 >> total: 255 Seiten

237 EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma T Projekt Lerninhalte Inhalt Umfang Voraussetzungen Hilfsmittel Aufträge Bewertung 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 237 >> total: 255 Seiten

238 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis 34 Kompetenznachweis Der Kompetenznachweis ist in drei Teile und als Praxis- und Theorie-Teil unterteilt: PRAXIS THEORIE ERSTER TEIL ZWEITER TEIL DRITTER TEIL Form Projekt als Einzelarbeit Schriftliche Prüfung Hilfsmittel - PC mit Internetzugang / JBoss / Eclipse Entwicklungsumgebung - schriftliche Unterlagen Dauer 16 Lektionen / 600 Minuten 2 Lektion / 100 Minuten Punkte Wertung 50 % 50 % Vorgaben Abgaben - workflow-interceptor.jar (als EJB Interceptor) ch.zli.m223.interceptor.workflowinterceptor.class - JBoss Applikationserver - MySQL RDBMS - JUnit Framework - PDF Dokument: - Use-Case-Diagramm - Deployment-Diagramm - Klassen-Diagramm - Sequenz-Diagramm - JUnit-Testklasse - Source als Eclipse Projekt - (generiert) - keine - schriftliche Modulprüfung - ev. erstellte Zusatzblätter 34.1 Gliederung Der Kompetenznachweis besteht aus Teilen und ist in Praxis- und Theorie-Teile untergliedert. Der erste Teil ist durch die Aufträge P1 P5 detailliert beschrieben und wird als Einzelarbeit durch Analyse der praktischen Projektarbeit definiert. Der zweite Teil besteht aus der Umsetzung der Analyse in Programmcode und ist durch den Auftrag P6 beschrieben. Auch dieser Teil des Kompetenznachweises wird als Einzelarbeit ausgeführt. Der dritte Teil umfasst eine schriftliche Prüfung / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 238 >> total: 255 Seiten

239 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis ERSTER TEIL ZWEITER TEIL DRITTER TEIL PRAXIS THEORIE Aufträge Aufgaben Thema Zeit in Lektionen Punkte Projekt als Einzelarbeit Wertung Punkte Wertung schriftliche Prüf. Punkte Wertung Kapitel Seite P 1 UML Use-Case-Diagramm /3 % 3_1 11 P 2 UML Deployment-Diagramm /3 % 3_2 12 P 3 UML Klassen-Diagramm /3 % 3_3 13 P 4 UML Sequenz-Diagramm /3 % 3_4 14 P 5 TDD JUnit-Testklasse /3 % 3_5 15 P 6 Implementation /3 % 3_6 16 T 1 OOA /3 % 4 17 T 2 OOD /3 % 4 17 T 3 Container-Komponenten /3 % 4 17 T 4 O/R Mapping /3 % 4 17 T 5 Transaktionen /3 % 4 17 T 6 Testkriterien /3 % 4 17 Total % % % Bewertung für die Bewertung des Kompetenznachweises gilt: - die Bewertung folgt der linearen Notenscala (Note = (Punkte x 5) / 120) + 1) - Note des Kompetenznachweises wird auf 0.5 gerundet - für die Note 4 sind 66 Punkte notwendig: ((66 x 5) / 120) + 1 = 3.75) Notenformel Punkte: x 5 Notenscala = 5 4 Note / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 239 >> total: 255 Seiten

240 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis Bezug der Aufträge zu den Handlungszielen Die Projektarbeit (Praxis-Teil) deckt die Handlungsziele wie folgt ab: Handlungsziele HZ Beschreibung Benutzeranforderungen objektorientiert analysieren und Anforderungen an die Datenhaltung mit Struktur und Inhalt der relationalen Datenbank abgleichen und dokumentieren. Last-, Durchsatz-, Verfügbarkeits- und Sicherheitsanforderungen aufgrund der Leistungsspezifikationen bestimmen. Transaktionen Multi-User fähig entwerfen. User Interfaces und Datenbankanpassungen spezifizieren. P1 P2 P3 P4 P5 P6 4 User Interfaces, Datenbankanpassungen und Transaktionen implementieren. 5 Testdrehbuch und Testfälle für funktionale und nicht-funktionale Anforderungen definieren. 6 Applikation testen und Testprotokoll erstellen. 7 Applikation dokumentieren und dabei auf Wartbarkeit und Nachvollziehbarkeit achten schriftliche Prüfung Die schriftliche Prüfung (Theorie-Teil) überprüft die zur Ausübung des praktischen Projektes notwendigen Technologien und steht daher nur indirekt in Bezug zu den Handlungszielen. - Die schriftliche Prüfung behandelt die folgenden Themenbereiche: OOA OOD Container- Komponenten O/R Mapping Transaktionen Testenkriterien 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 240 >> total: 255 Seiten

241 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis Ablauf Die Analyse (Erster Teil) besteht aus 5 Aufträgen. Dazu stehen 10 Lektionen zur Verfügung. Die fünf Aufträge werden als Einzelarbeit geplant, durchgeführt und dokumentiert. Die Dokumentation wird elektronisch und in Papierform am Ende der ersten Phase abgegeben. Die Implementation (Zweiter Teil) besteht aus 1 Auftrag. Die dazu zur Verfügung stehende Zeit sind 6 Lektionen. Dieser Auftrag wird als Einzelauftrag geplant und ausgeführt. Der ausgeführte Auftrag wird am Ende der Projektphase elektronisch abgegeben. Die Prüfung (Dritter Teil) besteht aus einer schriftliche Prüfung, die als Einzelarbeit gelöst werden muss. Es stehen dazu 2 Lektionen zur Verfügung. Lektionen Minuten PRAXIS THEORIE 10 Lektionen 6 Lektionen 2 Lektionen 500 Minuten 300 Minuten 100 Minuten Erster Teil Analyse : P1, P2, P3, P4, P5 - Use-Case-Diagramm - Deployment-Diagramm - Klassen-Diagramm - Sequenz-Diagramm - JUnit-Testklasse Zweiter Teil Implementation : P6 - Implementation Abgabe PDF Datei - Use-Case-Diagramm - Deployment-Diagramm - Klassen-Diagramm - Sequenz-Diagramm - JUnit-Testklasse Dritter Teil Prüfung : T1 T6 - schriftliche Prüfung Projekt Prüfung - Source als Eclipse Projekt - generiert 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 241 >> total: 255 Seiten

242 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis Abgaben Analyse Erster Teil Die Analyse zum Projektauftrag ist in einem Dokument festzuhalten. Dieses Dokument bildet die Basis für die Bewertung. Die inhaltlichen Voraussetzungen der Dokumentation, sowie die Bewertungsgrundlage dazu, sind in den Aufträgen P1, P2, P3, P4 und P5 detailliert. Die Dokumentation wird von jedem Teilnehmer als Einzelarbeit erstellt und am Schluss des ersten (Prüfungs-)teils in elektronischer (PDF Datei) und gedruckter Form (Drucker im Klassenzimmer) entsprechend den Anweisungen der Lehrperson abgegeben. Implementation Zweiter Teil Die Umsetzung als Programmcode wird in der zur Verfügung gestellten Eclipse Entwicklungsumgebung realisiert. Die Applikation muss auf den zur Verfügung gestellten JBoss Applikationsserver deployed werden. Persistente Domänenobjekte müssen durch das MySQL RDBMS abgebildet werden. Die Implementation wird von jedem Teilnehmer als Einzelarbeit erstellt und am Schluss des zweiten (Prüfungs-)teils in elektronischer Form (Eclipse Projekt) entsprechend den Anweisungen der Lehrperson abgegeben. Der zur Verfügung gestellte Interceptor (workflow-interceptor.jar) muss verwendet werden. Das dadurch (erfolgreich und korrekt) generierte ist Bestandteil der Bewertung. schriftliche Prüfung Dritter Teil Die schriftliche Prüfung wird am Anfang des dritten (Prüfungs-)teils ausgeteilt. Die Prüfung ist als Einzelarbeit zu lösen. Die Lösungen sind direkt auf der ausgeteilten Vorlage zu notieren. Persönliche, schriftliche Notizen und Schulungsunterlagen dürfen dabei verwendet werden. Die Prüfung ist am Ende des "Dritten Teils" abzugeben / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 242 >> total: 255 Seiten

243 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis 34.2 Praxis-Teil Ausgangslage Sie müssen die folgenden Technologien zur Lösung des Kompetenznachweis verwenden: JUNIT aktuelle Version 4.8 JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units (meist Klassen oder Methoden) geeignet ist. EJB aktuelle Version 3.1 Enterprise JavaBeans (EJB) sind standardisierte Komponenten innerhalb eines Java-EE- Servers (Java Enterprise Edition). Sie vereinfachen die Entwicklung komplexer mehrschichtiger verteilter Softwaresysteme mittels Java. Mit Enterprise JavaBeans können wichtige Konzepte für Unternehmensanwendungen, z. B. Transaktions-, Namensoder Sicherheitsdienste umgesetzt werden, die für die Geschäftslogik einer Anwendung nötig sind. JPA aktuelle Version 2.0 Die Java Persistence API (auch JPA) ist eine Schnittstelle für Java-Anwendungen, die die Zuordnung und die Übertragung von Objekten zu Datenbankeinträgen vereinfacht. Sie vereinfacht die Lösung des Problems der objekt-relationalen Abbildung, das darin besteht, Laufzeit-Objekte einer Java-Anwendung über eine einzelne Sitzung hinaus zu speichern (Persistenz), wobei relationale Datenbanken eingesetzt werden können, die ursprünglich nicht für objektorientierte Datenstrukturen vorgesehen sind. Die Java Persistence API wurde als Projekt der JSR 220 Expert Group entwickelt und im Mai 2006 erstmals veröffentlicht. JAAS JSE Bestandteil seit J2SDK 1.4 Java Authentication and Authorization Service (JAAS) ist ein Java-API, das es ermöglicht, Dienste zur Authentifizierung und Zugriffsrechte in Java-Programmen bereitzustellen. JAAS orientiert sich an den Pluggable Authentication Modules (PAM) und unterstützt dadurch eine benutzerbasierte Autorisierung / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 243 >> total: 255 Seiten

244 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis Entwicklungsmethoden TDD Aspekt von Extreme Programming (XP XP) Testgetriebene Entwicklung (auch testgesteuerte Programmierung, engl. test first development oder test-driven development (TDD)) ist eine Methode, die häufig bei der agilen Entwicklung von Computerprogrammen eingesetzt wird. Bei der testgetriebenen Entwicklung erstellt der Programmierer Software-Tests konsequent vor den zu testenden Komponenten. Die dazu erstellten Unit-Tests sind Grey-Box-Tests statt klassischer White-Box-Tests / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 244 >> total: 255 Seiten

245 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis Architektur Basierend auf den definierten Technologien ist die folgende Architektur einer verteilten Multi-User Applikation zu spezifizieren, zu implementieren, zu testen und zu dokumentieren. - Client Tier - Implementation von TDD (Test Driven Development) JUnit Testcases - Logik TIER - EJBs als Session Facade / Domänenlogik - persistiert durch JPA - deployed auf JBoss Applikationsserver - generiert durch Interceptor Interceptor (workflow-interceptor.jar) wird zur Verfügung gestellt - EIS Tier - MySQL als RDBMS - persistiert Domänenobjekte - ekslox.edu.zli - Mail Server, empfängt durch Interceptor generierte - die Teilnehmer haben keinen Zugriff auf die generierten / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 245 >> total: 255 Seiten

246 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis Aufgabenstellung Basierend auf den definierten Technologien und der geforderten Architektur entwerfen die Teilnehmer Domänenobjekte einer verteilten Multi-User Applikation. Die Aufgabenstellung der Domänenobjekte können dabei frei gewählt werden. Folgende Bedingungen müssen dabei berücksichtigt werden. Session Fassade - durch ein EJB muss eine Session Fassade zu Domänenobjekten (@Entity) realisiert werden - die Session Fassade muss durch den WorkflowInterceptor abgefangen werden - der WorkflowInterceptor wird als (workflow-interceptor.jar) zur Verfügung gestellt Sicherheits-Kontext - die Session Fassade der Domänenobjekte muss sich in einen Security Context (JAAS) befinden - der Name des Teilnehmers (Name_Vorname) muss als Prinzipal (User) definiert sein - der Name des Teilnehmers soll nach erfolgreicher Authentifizierung durch die Rolle "zli" autorisiert werden - den Realm (Files, DB, Ldap, etc.) kann frei gewählt werden Transaktionaler-Kontext - die Session Fassade der Domänenobjekte muss sich in einen Transaction Context befinden - durch einen JUnit Testcase muss ein Rollback simuliert werden durch Interceptor - der WorkflowInterceptor generiert bei einem Client Request (@Test JUnit Testcase) ein und versendet dieses an ekslox.edu.zli wenn: - der Prinzipal durch die Rolle "zli" autorisiert ist - der Transaktionale-Kontext durch einen Rollback beendet wird 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 246 >> total: 255 Seiten

247 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis 34.3 Aufträge P1 UML Use-Case-Diagramm Auftrag Erstellen Sie ein UML Use-Case-Diagramm der Aufgabestellung. Hinweis Denken Sie an den Anwendungsfall, mit dem ein Rollback simuliert werden kann! Bewertungskriterien - 2 Punkte bei vollständigem und korrektem Resultat - 1 Punkt bei teilweisem oder fehlerhaftem Resultat - 0 Punkte bei keinem Resultat oder bei einem unbrauchbaren Ansatz Richtzeit - die Richtzeit für diesen Auftrag ist 2 Lektionen = 100 Minuten Bewertung in Punkten - achten Sie dabei auf die folgenden Bewertungskriterien Auftrag Bewertung Punkte die Systemgrenze ist vorhanden und mit einen aussagekräftigen Namen (nicht System) benannt und wo notwendig zusätzlich beschrieben die Use Cases sind als messbarer Nutzen benannt (z.b. als verbnomen) und wo notwendig zusätzlich beschrieben der Actor mit der "zli" Autorisierung ist vorhanden und die entsprechende Authentifizierung ist vorhanden (z.b. durch Use Case "login") die Funktionalität des WorkflowInterceptor ist abgebildet (als Use Case) und die asynchrone Kommunikation zu ekslox.edu.zli (ausserhalb des Systems) ist ersichtlich das Use-Case-Diagramm folgt der grafischen UML Notation (Actor als Strichmännchen, Use Case als Eclipse, System als Rechteck, Beziehungen als Linien, etc.) Total / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 247 >> total: 255 Seiten

248 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis P2 UML Deployment-Diagramm Auftrag Erstellen Sie ein UML Deployment-Diagramm basierend auf der Aufgabestellung und dem erstellten Use-Case-Diagramm (P1). Bewertungskriterien - 2 Punkte bei vollständigem und korrektem Resultat - 1 Punkt bei teilweisem oder fehlerhaftem Resultat - 0 Punkte bei keinem Resultat oder bei einem unbrauchbaren Ansatz Richtzeit - die Richtzeit für diesen Auftrag ist 2 Lektionen = 100 Minuten Bewertung in Punkten - achten Sie dabei auf die folgenden Bewertungskriterien Auftrag Bewertung Punkte die einzelnen Tiers (Client / Test, Logik, EIS, etc.) sind vorhanden und beschrieben (Implementierungen, Technologien, Versionen, etc.) die Komponenten sind vollständig vorhanden, korrekt untereinander verbunden und korrekt beschrieben (Namen, Technologien, etc.) die verwendeten Dienstleistungen (Services) sind korrekt gezeichnet und beschrieben (JNDI, JAAS, JPA, JMS, JDBC etc.) die Tiers sind korrekt verbunden und die verwendeten Protokolle (RMI-IIOP, HTTP, SMTP, etc.) sowie die Unterscheidung der synchronen / asynchronen Kommunikation sind ersichtlich das Deployment-Diagramm folgt der grafischen UML Notation (Tier als (3D-) Rechteck, Komponente als (Fahnen-) Rechteck, Service als Kreis, Beziehung als Linie, etc.) Total / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 248 >> total: 255 Seiten

249 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis P3 Klassen-Diagramm Auftrag Erstellen Sie ein UML Klassen-Diagramm basierend auf der Aufgabestellung und dem erstellten Use-Case-Diagramm (P1) und dem erstellten Deployment-Diagramm (P2). Bewertungskriterien - 2 Punkte bei vollständigem und korrektem Resultat - 1 Punkt bei teilweisem oder fehlerhaftem Resultat - 0 Punkte bei keinem Resultat oder bei einem unbrauchbaren Ansatz Richtzeit - die Richtzeit für diesen Auftrag ist 2 Lektionen = 100 Minuten Bewertung in Punkten - achten Sie dabei auf die folgenden Bewertungskriterien Auftrag Bewertung Punkte die einzelnen Klassen (EJBs, Interfaces, Pojos, etc.) sind vollständig vorhanden und korrekt beschrieben (Stereotyp, Namen, Attribute, Methoden, etc.) die Attribute sind vollständig vorhanden (SessionContex, EntityManager, Pojo Eigenschaften, etc.) und korrekt beschrieben (Namen, Typ, Sichtbarkeit, etc.) die Methoden sind vollständig und korrekt vorhanden (Namen, Signature, Sichtbarkeit, etc.); dabei dürfen die Getter/Setter Methoden als "getter/setter" markiert sein der Zusammenhang zwischen den einzelnen Klassen ist korrekt und beschreiben die Art der Beziehung (Polymorphie, Kardinalität, Kommunikationsmodell, etc.) ist ersichtlich das Klassen-Diagramm folgt der grafischen UML Notation (Rechteck mit Unterteilungen, Sichtbarkeiten, Pascal Notation, etc.) Total / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 249 >> total: 255 Seiten

250 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis P4 Sequenz-Diagramm Auftrag Erstellen Sie ein UML Sequenz-Diagramm basierend auf der Aufgabestellung und dem erstellten Use-Case-Diagramm (P1), dem erstellten Deployment-Diagramm (P2) und dem erstellten Klassen-Diagramm (P3). Beschreiben Sie als Sequenz den simulierten Vorgang, der den transaktionalen Kontext durch einen Rollback beendet. Beschreiben Sie, wieso ein Rollback stattfindet. Ergänzen Sie die Methodenaufrufe durch nachvollziehbare und konkrete Informationen, z.b: - Interaktion void transferamount(from:account, to: Account, amount: Amount) - ergänzt mit void transferamount("sparkonto", "Kontokorrent", new (100.00, "EUR")) Bewertungskriterien - 2 Punkte bei vollständigem und korrektem Resultat - 1 Punkt bei teilweisem oder fehlerhaftem Resultat - 0 Punkte bei keinem Resultat oder bei einem unbrauchbaren Ansatz Richtzeit - die Richtzeit für diesen Auftrag ist 2 Lektionen = 100 Minuten Bewertung in Punkten - achten Sie dabei auf die folgenden Bewertungskriterien Auftrag Bewertung Punkte alle notwendigen Objekte sind vorhanden korrekt beschrieben (Klassennamen), und in einer sinnvollen Reihenfolge (Reihenfolge der Aufrufe, Trennung der Schichten, etc.) die Interaktion zwischen den Objekten ist vollständig vorhanden (Client Tier, Logik Tier, etc.) und korrekt beschrieben (Methodennamen, korrekte Signature, etc.) die Informationen, die einen Rollback simulieren, sind vorhanden und korrekt beschrieben (z.b. void transferamount("sparkonto", "Kontokorrent", new (100.00, "EUR")) die Abgrenzung des transaktionalen Kontext ist ersichtlich (Objekte innerhalb, bez. ausserhalb des transaktionalen Kontext), der Rollback findet statt und ist durch eine Beschreibung erklärt das Sequenz-Diagramm folgt der grafischen UML Notation (Objekte in x-achse, Zeit in y- Achse, ObjectLyfeCycle duch X beendet, Interaktion zwischen Objekten als Linie, etc.) Total / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 250 >> total: 255 Seiten

251 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis P5 TDD JUnit-Testklasse Auftrag Erstellen Sie eine Testklasse nach dem Ansatz des TDD (Test-Driven-Development). Fokussieren Sie sich auf den Testcase (@Test), der den transaktionalen Kontext der Session Fassade mit einem Rollback beendet. Stellen Sie die Ressourcen zum Test durch Initialisierungsmethoden (@Before) zur Verfügen und räumen Sie diese Ressourcen nach Beendigung des Tests wieder auf (@After). Bewertungskriterien - 2 Punkte bei vollständigem und korrektem Resultat - 1 Punkt bei teilweisem oder fehlerhaftem Resultat - 0 Punkte bei keinem Resultat oder bei einem unbrauchbaren Ansatz Richtzeit - die Richtzeit für diesen Auftrag ist 2 Lektionen = 100 Minuten Bewertung in Punkten - achten Sie dabei auf die folgenden Bewertungskriterien Auftrag Bewertung Punkte die Testklasse beschreibt den Testcase zur Simulation eines Rollback (korrespondiert mit UML Diagrammen) die Testklasse definiert die notwendigen Ressourcen (z.b. Datensätze in DB speichern, etc.) durch eine Initialisierung die Testklasse räumt die notwendigen Ressourcen (z.b. Datensätze aus DB löschen, etc.) wieder auf der Testcase initialisiert die notwendigen Objekte (Session Faccade, etc.), führt die notwendige Interaktion durch (korrekte Methoden, etc.) und behauptet (Asserts, etc.) relevant die Testklasse ist wartbar (z.b. Typen, Eingaben, Ausgaben, etc.) und nachvollziehbar (z.b. Funktionsbeschreibung, Ablaufbeschreibug, etc.) dokumentiert Total / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 251 >> total: 255 Seiten

252 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis P 6 Implementation Auftrag Implementieren Sie Ihre durch UML und TDD definierte Applikation mit Eclipse und deployen Sie diese auf dem JBoss Applikationsserver. Arbeiten Sie in Ihrem Benutzerprofil und nicht als lokaler Administrator. Verwenden Sie den zur Verfügung gestellten Interceptor um das notwendige zu generieren/versenden: - workflow-interceptor.jar (ch.zli.m223.interceptor.workflowinterceptor.class) - als Interceptor der EJB Session Fassade Bewertungskriterien: - 2 Punkte bei vollständigem und korrektem Resultat - 1 Punkt bei teilweisem oder fehlerhaftem Resultat - 0 Punkte bei keinem Resultat oder bei einem unbrauchbaren Ansatz Richtzeit: - die Richtzeit für diesen Auftrag ist 6 Lektionen = 300 Minuten Bewertung in Punkten - achten Sie dabei auf die folgenden Bewertungskriterien Auftrag Bewertung Punkte 1 ist auf ekslox.edu.zli eingegangen 2 2 Inhalt der der Teilnehmer arbeit mit seinem Userprofil (nicht als Administrator) 2 3 Inhalt der der Prinzipal definiert sich aus Name_Vorname des Teilnehmers 2 4 Inhalt der die Interaktion entspricht der UML Definition (Methodennamen, Signature, etc.) 2 5 Inhalt der die Interaktion simuliert einen Rollback (durch realistische Parameter) 2 Total 10 Hinweis Die wird durch den WorkflowInterceptor automatisch generiert und an ekslox.edu.zli versendet wenn die Interaktion mit der Session Fassade (Domänenobjekte) in einem Security-Kontext stattfindet; der Prinzipal durch die Rolle "zli" autorisiert ist und der transaktionale Kontext durch einen Rollback beendet wird / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 252 >> total: 255 Seiten

253 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis 34.4 Theorie-Teil schriftliche Prüfung Die schriftliche Prüfung ist Bestandteil des Kompetenznachweis und behandelt die folgenden Themenbereiche, die auf den Umfang einer verteilten und objektorientierten Multi-User Applikation reduziert sind: - OOA Objekt-Orientierte-Architektur - OOD Objekt-Orientiertes-Design - Container-Komponenten - O/R Mapping - Transaktionen - Testkriterien Richtzeit: - die Richtzeit für die schriftliche Prüfung sind 2 Lektionen = 100 Minuten Bewertung in Punkten - Jeder Themenbereich setzt sich aus vier Einzelaufgaben zusammen - diese sind wie folgt gegliedert: Teilaufgabe Inhalt Punkte 1 einfacher Multiple-Choice 1 2 schwieriger Multiple-Choice einfache Wissensfrage, wobei die Antwort bildlich, textlich oder als Source verlangt werden kann schwierige Wissensfrage, wobei die Antwort bildlich, textlich oder als Source verlangt werden kann Total / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 253 >> total: 255 Seiten

254 EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis U Referenzen Lerninhalte Bücher Referenzen 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 254 >> total: 255 Seiten