EJB 3.1 JPA 2.0

EJB 3.1
3.1
JPA 2.0
Java-Framework
Autor
Stephan Metzler
About Coders
geek & poke
Version 4.1
© 2010 / 2011
i-ch223 >> Multi-User-Applikation objektorientiert realisieren >>
Seite
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
5
39
45
61
109
129
143
161
169
189
207
221
229
253
281
431
445
449
465
473
507
Java Community
Verteilte Systeme
Java EE
EJB
Testen
SLSB
SFSB
Singleton
Messaging
AOP
Timer Service
Web Service
EJB Security
Transaktionen
JPA
Idioms
Regeln
Deployment Deskriptoren
Trends
Projekt
Referenzen
4. Tag
3. Tag
2. Tag
1. Tag
MileStones
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 2 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
1
Java Plattform
Die Java Plattform ist in drei Editionen aufgeteilt
JME
JSE
JEE
Micro Edition
Standard Edition
Enterprise Edition
- Umgebung
- robust
- flexible
- Ziel-Applikationen
- embedded devices
- Inhalt
- JRE
- Definition
- Standard (Framework)
- APIs
- VM
-
- Mobil-Telefone
- PDAs
- Inhalt
- VM
- Kommunikationsprozesse
JDK
- JRE
- Compiler
- Debugger
- Multi-User
- Multi-Tier
- Enterprise Appl.
- Inhalt
- Dienstleistungen
- Zugriff
Basis für JEE
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
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,
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.
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 angehängt
@MyAnnotation(parameter1 = "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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
Annotations in der Java JSE 5.0
- definiert sieben Annotations
- Standard Annotation ►normale Verwendung beim Programmieren
- Meta Annotation ►Definition neuer Annotationstypen
Standard Annotations
- @Deprecated
- kennzeichnet Methoden und Klassen,
die nicht mehr verwendet werden sollen
- @Override
- 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
- @SuppressWarnings
- unterdrücken Compilerwarnungen
- Warnungen werden als Parameter angegeben
Beispiel @Deprecated / @Override
public class HelloWorld {
@Deprecated
public String sayHello() {
return "Hello World";
}
@Override
public String toString() {
return "Hello World";
}
}
- sayHello() ist "veraltet" und erzeugt Compilerwarnung
- toString() mit @Override stellt sicher, dass toString() aus Object überschrieben wird
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 6 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
Meta Annotations
- @Documented
- zur Erzeugung der Dokumentation bei Javadoc
- @Inherited
- Annotation-Typ wird vererbt
- auch rekursiv
- falls keine Annotation in der aktuellen Klasse
gefunden wird
- @Retention
- 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
- @Target
- definiert Elemente (Klasse, Methode, Parameter etc.), denen eine Annotation zugeordnet werden
kann
Beispiel selbst definierter Annotation
public enum Datentyp {
TEXT, NUMMER, DATUM
}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface Datenfeld {
String bezeichnung() default "";
Datentyp datentyp() default Datentyp.TEXT;
}
- @Retention(RetentionPolicy.RUNTIME) definiert die Verfügbarkeit
- RUNTIME : Auswertung zur Laufzeit
- @Target({ElementType.FIELD}) definiert wo die Annotation eingesetzt werden kann
- FIELD : für Attribute
- @interface 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
Anwendung: Klasse Person annotiert Attribute als Datenfelder
public class Person implements java.io.Serializable {
@Datenfeld(bezeichnung = "Nummer", datentyp = Datentyp.NUMMER)
private int
nr;
@Datenfeld(bezeichnung = "Name", datentyp = Datentyp.TEXT)
private String name;
@Datenfeld
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 Annotation @Datenfeld
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
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.
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
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
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
Aufgabe ► genererische Typen / generische Methoden
- Typparameter wie normale Typen bei der Definition der Klasse verwenden
@Test
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 " + post.toString());
}
@Test
public void testSayHello() {
assertEquals("generic hello world", sayHello("generic", new StringBuffer("world")));
}
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 11 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
1.3
-
Log4J
populäre JAVA Logging-API http://logging.apache.org/log4j
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
Level
root
root.x
ERROR
Geerbte
Geerbter
rbter Level
ERROR
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 12 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
Layouts ► erlauben das Formatieren der Loggermeldungen mit Pattern
org.apache.log4j
Pattern Zweck
Category: Kategorie = Name org.apache
Class = Klassennamen
Date. Beispiel: %d{HH:mm:ss,SSS}
Filename
Location Information
Line number
Meldung selbst
Methodennamen
Line-Separator (Plattformabhängig)
Priority: INFO, WARN, ERROR etc.
Anzahl der Millisekunden seit dem Start der VM
Name des Threads
c
C
d
F
l
L
m
M
n
p
r
t
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
Appender Target
Vererbte Appenders
root
org
org.apache
org.apache.log4j
A1
B1, B2
none
C1
org und root
org und root
org.apache.log4j, org und root
A1
A1, B1, B2
A1, B1, B2
A1, B1, B2, C1
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
Konfiguration ► durch PropertiesProperties-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 XMLXML-Datei ► log4j.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j='http://jakarta.apache.org/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
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
2010-01-01 12:00:00,781 INFO
2010-01-01 12:00:00,781 INFO
[main] log.SimpleLogging - entering Application
[main] log.SimpleLogging - leaving Application
File ► log4j.log
2010-01-01 12:00:00,234 INFO
2010-01-01 12:00:00,234 WARN
2010-01-01 12:00:00,234 INFO
<main> SimpleLogging.java:20 - entering Application
<main> Person.java:20 - did it again!
<main> SimpleLogging.java:23 - leaving Application
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 15 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
1.4
Project Lombok
- Code Generator ► http://projectlombok.org/
- umgeht Java Konventionenfür JavaBeans
- definieren des Default Konstruktors
- generieren von getter / setter
- überschreiben von toString / equals / hashcode
- Plugin für Eclipse ► http://projectlombok.googlecode.com/files/lombok.jar
- ausführbare Datei ► als JAR ausführen
- lombok.jar in den Project ClassPath einbinden
import lombok.Data;
@Data public class Konto {
private String nr;
private String name;
private Float saldo;
}
Lombok Annotations
Annotation
Verwendung
generiert getter und setter Methoden der verwendeten Attributen
@Getter / @Setter
@ToString
generiert entsprechende toString Methode
@EqualsAndHashCode
generiert equals und hashCode Methoden
generiert Konstruktorenen
@NoArgsConstructor
@RequiredArgsConstructor Default Konstruktor ohne Argumente
Konstruktoren für final / alle Attrbute
@AllArgsConstructor
@Data
generiert Artefakte für ein Data Objekt
@ToString, @EqualsAndHashCode, @Getter für alle Attribute, @Setter
für non-final Attribute, und @RequiredArgsConstructor
@Cleanup
automatisches Ressourcenmanagment
@Synchronized
synchronisiert statische und Klassen-Methoden
@SneakyThrows
übergeht checked exceptions
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 16 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Java Plattform
1.5
Build Tools
wiki Erstellungsprozess oder BuildBuild-Prozess (von englisch to build „bauen“) bezeichnet in der
Programmierung
Programmierung einen Vorgang, durch den ein fertiges Anwendungsprogramm automatisch
erzeugt wird.
verbreitete Programme zur Durchführung von Erstellungsprozessen
- Unix
- make, CMake, Automake
- Java
- Apache Ant ► http://ant.apache.org/
- Apache Maven ► http://maven.apache.org/
- Buildroot ► http://buildroot.uclibc.org/
- .Net
- TFS (Team Foundation Server) ► http://msdn.microsoft.com/en-us/vstudio
1.5.1
Maven
wiki Maven ist ein BuildBuild-ManagementManagement-Tool der Apache Software Foundation und basiert auf Java.
Java. Mit
ihm kann man insbesondere
insbesondere JavaJava-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
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 http://maven.apache.org/pom.html
- 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
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 http://mvnrepository.com/
- 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
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Verteilte Systeme
.NET
Microsoft http://de.wiki.org/wiki/.NET
-
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 http://de.wiki.org/wiki/Enterprise_JavaBeans
- nur JAVA http://java.sun.com/javaee
- 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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform
3
Java EE Plattform
http://java.sun.com/javaee/5/docs/tutorial/doc/
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform
3.1
Application Server
wiki Ein Anwendungsserver ist ein Server in einem
Computernetzwerk,
Computernetzwerk, auf dem AnwendungsAnwendungsprogramme ausgeführt werden.
Im engeren Sinne bezeichnet der Begriff eine
Software,
Software, die spezielle Dienste zur Verfügung
stellt, wie beispielsweise Transaktionen,
Transaktionen,
Authentifi
Authentifizierung
fizierung oder den Zugriff auf
Verzeichnisdienste und Datenbanken
über definierte Schnittstellen.
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
http://de.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
Robustheit
J2EE 1.3
J2EE 1.2
JPE Project
Java
Plattform for
the Enterprise
1998
Servlet /JSP
EJB 1.0
JMS 1.1
JTA 1.0
JAAS 1.0
JNDI
RMI/IIOP
1999
EJB 2.0
2001
Web Services
J2EE 1.4
EJB 2.1
JSS 2.4
JSP 2.0
WS 1.0
JavaMail 1.2
JAXP 1.2
JCA 1.5
2003
SOA
Java EE 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
Java EE 6
2006
2010
EJB 3.1
JPA 2.0
JSS 3.0
JSF 2.0
Bean
Validation
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 25 >> total: 255 Seiten
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
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.
XML. Im Umfeld der Java Platform, Enterprise Edition,
Edition, beschreibt diese
Konfigurationsdatei den spezifischen Bereitstellungsprozess
Bereitstellungsprozess (englisch deployment)
deployment) und dazu
benötigte Informationen.
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
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.
ORACLE
- JDBC (Java DataBase Connectivity)
- Zugriff zu relationalen Datenbanken
- JMS (Java Messaging Service )
- Zugriff zu Message Orientated
Middleware, z.B. iBus ,IBM MQSeries
DB2
JDBC
Tuxedo
JTA
JEE
JNDI
LDAP
DNS
COS
JMS
MQSeries
iBus
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 28 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Java EE Plattform
3.6
Konventionen
wiki Eine Konvention (lat.
(lat. conventio „Übereinkunft, Zusammenkunft“)
Zusammenkunft“)
ist eine nicht formal festgeschriebene
festgeschriebene Regel,
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™ ►
http://www.oracle.com/technetwork/java/codeconv-138413.html
Ansatz basierend auf dem HelloWorld EJB
EJB Namens Konvention
Item
Syntax
<name>Bean
Enterprise Bean Name (DD)
<name>JAR
EJB JAR Display Name (DD)
<name>Bean
Enterprise Bean Class
<name>
Business Interface
<name>Remote
Remote Interface
<name>Local
Local Interface
<name>
Abstract Schema (DD)
3.7
Beispiel
HelloWorldBean
HelloWorldJAR
HelloWorldBean
HelloWorld
HelloWorldRemote
HelloWorldLocal
HelloWorld
Komponenten ► funktionierende Software Einheit
wiki Eine SoftwareSoftware-Komponente ist ein SoftwareSoftware-Element,
das konform zu einem Komponentenmodell ist und gemäss
einem CompositionComposition-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 (eenterprise archive)
gepackt
ar
-
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
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
-
3.9
als JAR-Archive
- in WEB-INF/classes
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
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
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,
Entwicklung,
Distribution
Verteilung
and
und
Deployment
of
Umsetzung (von Modellen)
Militär: Truppenbereitstellung / Installation
Java-Based
Java basierten
Server-Side
serverseitigen
Software Components
Software Komponenten
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 32 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans
EJB Komponente
-
definiert Funktionalität
Black Box
Zugriff nur über Schnittstelle
Wiederverwendbarkeit
http://www.ejip.net/images/ejb.jpg
EJB Ziele
- Entwicklung von Geschäftsprozessen
- keine Systemprozesse
- Standard für Komponenten-basierte Entwicklung
- Wiederverwendbarkeit
4.1.1
POJO Plain old Java Object
wiki POJO ist eine Abkürzung für Plain Old Java
Java Object,
Object,
also ein „ganz normales“ Objekt in der
Programmiersprache Java.
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. B. @javax.ejb.Entity public class Person
Beispiel
- Klasse Person
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 33 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Enterprise JavaBeans
seit Version 3 ist das EJB ein POJO
Dependency
Injection
JPA
Query Language
Bean Ressourcen
Annotaions
Stateless Stateful Session Bean
Entity Bean
O / R Mapping
Transactions
Remote
Invocation
JDBC
JNDI
JTA
Message Driven Bean
Container
Ressourcen
POJO Plain Old Java Object
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
innerhalb von Container
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 34 >> total: 255 Seiten
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
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
Ausprägung
Stateless Session Bean
Stateful SessionBean
Singleton
Message Driven Bean
Entity Bean
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
Transient
Lebenszyklus
typischerweise durch
Clientprozess
bestimmt
Transient
"stirbt" bei Container
Terminisierung
Persistent
Zustand bleibt im
persistenten Speicher (DB)
auch nach Container
Terminierung erhalten
Stateful Session Bean
dedizierte Client
Zuordnung
Gemeinsame
Nutzung
Stateless Session Bean
hat keine Client
Zuordnung
Persistenz
Transient
Lebenszyklus
typischerweise durch
Clientprozess bestimmt
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 35 >> total: 255 Seiten
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
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)
- http://www.oracle.com/technetwork/java/javase/downloads/index.html
- JEE Application Server
- http://de.wikipedia.org/wiki/Liste_von_Anwendungsservern
- Sun GlassFish ► https://glassfish.dev.java.net/public/downloadsindex.html
- JBoss ► http://jboss.org/jbossas/downloads/
Open Source
- OpenJPA ► http://openjpa.apache.org/downloads.html
- Apache Geronimo
- Geronimo ► http://geronimo.apache.org/downloads.html - Glassfish ► Referenzimplementierung
- JBoss Application Server
- Resign ► http://www.caucho.com/download/
Closed Source
- WebShere
- Entwicklingsumgebung
- Oracle Application Server
- Eclipse ► http://www.eclipse.org/downloads/
- WebLogic
- NetBeans ► http://netbeans.org/downloads/
- SAP NetWeaver Application Server
- BlueJ ► http://www.bluej.org/download/download.html
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
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
2. HelloWorld.jar
HelloWorld.jar 3. deployen
deployen
4. TestHelloWorldBean
TestHelloWorldBean.class
HelloWorldBean.class
5.4
Hello EJB World Java Source Dateien
- das Remote (Business) Interface
- im Verzeichnis
HelloWorld.java
<workspace>\HelloWorld\ejbModule\server
package server;
import javax.ejb.*;
@Remote public interface HelloWorld {
public String echo(String echo);
}
- die Enterprise BEAN Klasse
- im Verzeichnis
HelloWorldBean.java
<workspace>\HelloWorld\ejbModule\server
package server;
import javax.ejb.*;
@Stateless public class HelloWorldBean implements HelloWorld {
@Override public String echo(String echo) {
return "Server Echo : " + echo;
}
}
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 38 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World
- die Client Applikations-Klasse
- im Verzeichnis
HelloWorldBeanClient.java
<workspace>\HelloWorld\test\remote
package remote;
import
import
import
import
javax.naming.Context;
javax.naming.InitialContext;
javax.naming.NamingException;
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World
Aufgabe ► JNDI
- Prüfen Sie die registrierten Nameneinträge des JNDI
- http://localhost:8080/jmx-console + service=JNDIView
Deployment Descriptor ► ejbejb-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="http://java.sun.com/xml/ns/javaee"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd ">
<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>
Deployme
Deploymentnt-Descriptor überschreibt Annotationen
Annotationen!
tationen!
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 41 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Hello EJB3 World
Aufgabe ► ejbejb-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" "http://www.jboss.org/j2ee/dtd/jboss_5_0.dtd">
<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
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:
6.1.1
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
6.1.2
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
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
6.1.3
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
6.1.4
Deployment Descriptor
- ist eine XML (eX
Xtensible 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
6.2.1
Clients
- EJBs
- transparent
- thin
- browser basiert
- fat
- Java
- .NET
- CORBA
- unabhängig
- protokolliert
- z.B. Webservice, REST, etc.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 45 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
6.2.2
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 46 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
6.3.1
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. Instanzii
Instanziierung
EJB
Instanz
Enterprise
Java Beans
3. Remote Aufruf
Business
Interface
Client
obj
2. Referenz auf Proxy
obj
JNDI
obj
erzeugte
Referenz in
Namensdienst
EJB - Container
►Deployment
1. Anfrage
nach Referenz
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 48 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
6.3.2
Sequenz Diagramm
wiki Ein Sequenzdiagramm (engl. sequence diagram)
diagram) ist eine der 14 Diagrammarten in der Unified
Modeling Language (UML), einer Modellierungssprache
Modellierungssprache für Software und andere Systeme.
Das Sequenzdiagramm ist ein Verhaltensdiagramm,
Verhaltensdiagramm, genauer eines der vier Interaktionsdiagramme.
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.
Lebenslinien.
6.3.3
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
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
6.3.4
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
RMI Ablauf
1.
2.
3.
4.
5.
Client fordert mittels einer URL und der lookup-Methode eine Referenz vom Naming Service an
Proxy-Referenz wird zurückgeliefert und der Stub-Code vom RMI-Server heruntergeladen
Client ruft eine Methode mittels der Proxy Referenz auf
Verpacken (Marshalling) des Aufrufs im Stub und übertragen an den RMI-Server
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
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
6.4.1
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
6.4.2
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
6.4.3
asynchron, nachrichtenbasierte Kommunikation
- Schnittstelle zwischen objektorientierten
und nicht-objektorientierten Prozessen
in verteilten Systemen
Ablauf:
Ablauf:
1.
2.
3.
4.
5.
6.
7.
Applikationsserver registriert Nachrichtenempfänger beim Namensdienst
EJB-Container registriert sich als Listener für Nachrichten
Client fordert vom Namensdienst Referenz des Nachrichtenempfängers
Namensdienst liefert Referenz auf Nachrichtenempfänger
Client sendet Nachrichten an Nachrichtenempfänger
Nachrichtenempfänger übermittelt Listener eingegangene Nachricht
Listener delegiert Nachricht an Bean-Instanz
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 53 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Inside EJB3
6.4.4
Überblick über die Kommunikationsmodelle
Stateless Session Bean
Stateful Session Bean
Message Driven Bean
Entity Bean
asynchrony achrichtenbasiert
synchron lokal
EJB Typen
synchron entfernt
die folgende Tabelle weist die Aufrufmodelle den verschiedenen EJB-Typen zu
Kommunikationsmodel
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 54 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Testen
7
Testen
wiki Ein Softwaretest ist ein Test während der Softwareentwicklung,
Softwareentwicklung, um die Funktionalität einer
Software an den Anforderungen und ihre Qualität zu messen und Softwarefehler
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)
- BlackBlack-BoxBox-Test – prüft definierte Schnittstellen (Funktionalität)
- WhiteWhite-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
Aufwand so gross, dass häufig auf die Tests verzichtet wird.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 56 >> total: 255 Seiten
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
nichtnicht-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.
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
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 (http://junit.org/) meist verbreitet
- durch Assertion (Engl: Aussage, Behauptung)
- asserts(), assertNotNull(), assertEquals(), etc.
// SYNTAX : Assertion
< Assertion> ( <testen> <Kriterium> <gegeben> )
// Beispiel
gegeben : 3
assert( 1 + 2 == 3 )
Kriterium : EQUALS
testen : 1 + 2
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Testen
7.4
JUnit
wiki JUnit ist ein Framework zum Testen von JavaJava-Programmen, das besonders für automatisierte UnitUnitTests einzelner Units (meist Klassen oder Methoden)
Methoden) geeignet ist.
ist Framework ► www.junit.org
-
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Testen
JUnit Annotaions ►JUnit 4
- Testfunktionen werden als statische Methoden importiert
import
import
import
import
import
org.junit.Test;
org.junit.Before;
static org.junit.Assert.assertEquals;
static org.junit.Assert.assertNotNull;
static org.junit.Assert.assertTrue;
public class TestHelloWorldBean { ...
@Test(expected = NamingException.class)
public void noEcho() throws NamingException { ...
JUnit 4 Annotaions
Begriff
Beschreibung
kennzeichnet Methoden als ausführbare Testfälle
@Test
markiert Setup-Aufgaben, die für jeden Testfall wiederholt werden sollen
@Before
markiert Teardown-Aufgaben, die für jeden Testfall wiederholt werden sollen
@After
@BeforeClass markiert Setup-Aufgaben, die nur einmal pro Testklasse ausgeführt werden sollen
@AfterClass markiert Teardown-Aufgaben, die nur einmal pro Testklasse ausgeführt werden sollen
kennzeichnet temporär nicht auszuführende Testfälle
@Ignore
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 TD
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
Beschreibung
Stub
fragmentale Implementierung als Stellvertreter
Dummy
Ersatzklasse, um das Verhalten zu testen
Mock
dynamisches Dummy ► konfigurierbar
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 60 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Testen
7.6
Mocks
wiki Mock
Mock--Objekte werden in der Testgetriebenen Softwareentwicklung
Softwareentwicklung DummyDummy-Objekte oder
Attrappen genannt, die als Platzhalter für echte Objekte innerhalb von Unit
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
7.6.1
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 61 >> total: 255 Seiten
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
- @RunWith Annotation erlaubt das Erkennen der Abhängigkeiten z.B. @Parameters
- @Parameters erlaubt parametrisierter Test
@RunWith(value = Parameterized.class)
public class JunitParameterizedTest {
private int number;
public JunitParameterizedTest (int number) {
this.number = number;
}
@Parameters public static Collection<Object[]> data() {
Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
return Arrays.asList(data);
}
@Test public void pushTest() {
System.out.println("Parameterized Number is : " + number);
}
}
- @Test(expected= …) definiert das Mockverhalten
@Test(expected = 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Testen
7.8
Funktionale Tests
- in der Paxis etablieren sich Werkzeuge
- Fit (Framework for Integrated Test) http://fit.c2.com/
- Bedingungen als HTML
-
FitNesse http://www.fitnesse.org/
- Bedingungen in wiki
- Testbedingungen werden formuliert und die Resultate auf einem Browser ausgegeben
Aufgabe ► FitFit-Test
- testen Sie die SLSB Applikation durch FitPro
- ► http://www.luxoft.com/fit/
- 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Testen
Aufgabe ► UnitTest
- Testen Sie das HelloWorldBean mit JUnit Tests
public class TestHelloWorldBean {
private InitialContext initialContext;
@Before 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 InitialContext(properties);
}
@Test 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 World"));
}
@Test(expected = 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
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 64 >> total: 255 Seiten
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
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 singleein Bean kann nur einen Client behandeln
single-threaded ►ein
Ablauf
- Container erzeugt während Deployment Beaninstanzen im Pool
-
konfigurierbar
@ProConstruct Methode steht nicht in direkter Kopplung zum aufrufenden Client
Annotation @Stateless ► C
Parameter
Beschreibung
name
expliziter Name der Session Bean
mappedName
mappen des Namens auf einen weiteren
implementierungsspezifischen (JNDI)-Namen
Typ
Default
unqualifizierter
String
Klassenname
String
(nicht im Standard-Umfang der Spezifikation)
description
eine Beschreibung für das Bean
String
Annotation @Remote ► C, I
Parameter
Beschreibung
value
alle Schnittstellen, die entfernt zugreifbar sein sollen
Typ
Class[]
Default
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 66 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean ► zustandslos
8.1
Bean Life Cycle
does not exist
Container initiated:
@PreDestroy
Methode-Ready-Pool
Client initiated:
business methods
Container initiated:
Class.newInstance()
Dependency Injection
@PostConstruct
@PostConstruct
Container initiated:
Timeout Callback
LifeCycleMethoden
Annotation
Beschreibung
@PostConstruct
Wird vom Container aufgerufen nachdem die Bean durch den Container
instanziiert worden ist. Für den Client ist der Aufruf dieser Methode transparent.
@PreDestroy
Ressourcen werden durch den Bean Provider freigegeben. Für den Client ist der
Aufruf dieser Methode transparent.
@Remove
Timeout Callback
8.2
bei SLSB eine NO-OP ► implementiert, jedoch ohne Wirkung
bezieht sich auf eine Container Timer Funktion
Dependency Injection
wiki Dependency Injection (DI) ist ein Entwurfsmuster und
dient in einem objektorientierten System dazu, die
Abhängigkeiten zwischen
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
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
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 über @Remote / @Local in der Beanklasse
-
implizit (deklariert) oder explizit (programmiert ► implements)
optionaler Name als Parameter
@Stateless(name = "RateBean")
@Remote(ZinsRemote.class)
@Local(ZinsLocal.class)
public class ZinsBean { ...
// überschreibt den Namen der Bean
// implizite Interfaces Implementation
// seit EJB 3.1 optional
- 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
EJB 3.1 / JPA 2.0 >> Java Framework >> SLSB Stateless Session Bean ► zustandslos
Zugriff auf das Environment
Environment ► Umgebung der Bean
private float rate = 0.0f;
@PostConstruct 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: ejbejb-jar.xml
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" ... 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
Argument direkt mit @Resource annotiert ► Dependency Injection
@Stateless(mappedName = "ejb/zins")
@Remote(ZinsRemote.class)
@Local(ZinsLocal.class)
public class ZinsBean {
@Resource(name = "Rate") private float rate;
Annotation @Resource ► T
Parameter
Beschreibung
Beschreibung der referenzierten Ressource
description
mappedName
name
Typ
String
Name der referenzierten Ressource im globalen Namensdienst
(nicht im Standard-Umfang der Spezifikation)
Name, unter dem die referenzierte Ressource im lokalen
Namensdienst (java:comp/env) der Komponente, die die
Annotation verwendet, auffindbar sein soll
Annotation @Resources ► T
Parameter
Beschreibung
Liste der einzelnen Ressource-Annotationen
value
Default
String
String
Typ
Default
Resource[]
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 69 >> total: 255 Seiten
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
Beschreibung
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 mit @Resource injiziert werden
lookup()
-
ENC: lookup("ejb/myBean");
JNDI: lookup("java:comp/env/ejb/myBean");
nur SessionContext
getBusinessObject()
-
liefert robuste Referenz auf das EJB
nur SessionContext
getInvokedBusinessInterface()
getInvokedBusinessInterface()
-
liefert das Interface der Geschäftsschnittstelle Local,
Remote oder WebService
Zugriff auf SessionContext ► extends EJBContext
- Referenz auf aktuelle Bean Implementation (z.B. BusinessObject)
@Stateless(name = "RateBean")
@Remote(ZinsRemote.class)
@Local(ZinsLocal.class)
public class ZinsBean {
@Resource private SessionContext sc;
public Object getRemoteReference() {
return sc.getBusinessObject(ZinsRemote.class);
}
public Object getRemoteInterface(){
return sc.getInvokedBusinessInterface();
}
}
oder mit @Resource Annotation auf Methodenebene
@Resource public void setSessionContext(SessionContext sc) {
this.sc = sc;
}
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 70 >> total: 255 Seiten
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean ► zustandsbehaftet
9
SFSB Stateful Session
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 LIFELIFE-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 GuardGuard-Pattern:
Pattern: Methodenaufrufe werden auf die entsprechenden Zugriffsrechte überprüft.
Annotation @Stateful ► C
Parameter
Beschreibung
Typ
Default
name
expliziter Name der Session Bean
String
unqualifizierter
Klassenname
mappedName
mappen des Namen auf einen weiteren
implementierungsspezifischen (JNDI)-Namen
String
(nicht im Standard-Umfang der Spezifikation)
description
eine Beschreibung für das Bean
Annotation @Remove ► M
Parameter
Beschreibung
retainIfException Löschverhalten der Bean bei einer Exception
String
Typ
Default
Boolean
true
Annotation @Local ► C,I, optional seit EJB3.1
Parameter
Beschreibung
Typ
Beschreibung
value
alle Schnittstellen, die lokal zugreifbar sein sollen Class[]
Default
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 73 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean ► zustandsbehaftet
9.1
Bean Life Cycle
does not exist
Container initiated:
@PreDestroy
Container initiated:
Class.newInstance()
Dependency Injection
@PostConstruct
@PostConstruct
Client initated:
@Remove
Exception
Methode-Ready
timeout
afterBeginn()
beforeCompletion()
afterCompleteion(*
afterCompleteion(*)
in Transaktion
Container initiated:
@PostActivate
Client initiated:
nichttransaktionale
Business Methods
Client initiated:
transaktionale
Business Methods
Container initiated:
@PrePassivate
@PrePassivate
Client initated:
Methodenaufruf
Client initiated:
(Least Recently Used)
*
COMMIT = true
ROLLBACK = false
Passive
Bean Life Cycle Methoden
LifeCycleMethoden
Annotation
Beschreibung
@PostConstruct
@PreDestroy
@PrePassivate
@PrePassivate
@PostActivate
@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 mit @PostActivate markierte parameterlose Methode auf, um
Zustand der Bean erneut zu initialisieren.
Wird vom Container aufgerufen, nachdem der Client eine Methode des RemoteInterface aufgerufen hat, die durch die Bean mit der Annotation @Remove
gekennzeichnet ist. In dieser Methode sollten die für die Bean reservierten
Ressourcen wieder freigegeben werden. Danach löscht der Container die BeanInstanz.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 74 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean ► zustandsbehaftet
Aufgabe ► Kontoführung
Kontoführung
- erstellen und deployen Sie ein SFSB Bank
zur Verwaltung von Konten
- benützen Sie dazu das Objekt Konto
- verwenden Sie die @Data 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
EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean ► zustandsbehaftet
- erzeugen Sie die Datenbankverbindung durch den Bean Lifecycle
- mit der Annotaion @PostConstruct ► Ansatz
- vergessen Sie nicht das Schliessen der Resource ► @PreDrestroy
@Stateful
public class BankBean implements Bank {
@PostConstruct
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 Tests
@Test
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 Interface
@Stateful public class BankBean implements Bank {
@EJB(mappedName = "ejb/zins")
private ZinsLocal rate;
// das Bean Interface
@EJB 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
EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean ► zustandsbehaftet
Annotation @EJB ► T, M
Parameter
Beschreibung
beanInterface
beanName
mappedName
mappedName
name
Interface-Typ der referenzierten Bean
Remote oder Local
logischer Name der referenzierten Bean
name Attribut der @Stateless, @Stateful,
@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
Annotation @EJBs
Parameter
Beschreibung
Liste der EJB Annotationen
value
Typ
Default
Class
Object.class
String
String
String
Typ
Default
EJB[]
Aufgabe ► Local Interface
- Berechnen Sie den Zins durch eine SFSB Bank
-
verwenden Sie das Lokale Interface der ZinsBean "Zins"
verwenden Sie die Beanklasse "ZinsBean"
Ansatz
@Stateless (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) years);
}
}
@Stateful public class BankBean implements Bank {
@EJB(mappedName="ejb/zins")
private Zins rate;
public double tellRate(){
return rate.getRate();
}
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 77 >> total: 255 Seiten
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 über @Resource ► Container Managed
Injektion der DataSource
@Stateful
public class BankBean implements Bank {
@Resource(mappedName = "java:jdbc/bank")
private DataSource ds = null;
oder
@Stateful
@Resource(mappedName = "java:jdbc/bank", name = "bankDB")
public class BankBean implements Bank {
@PostConstruct
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_Home>/server/jee/deploy/mysql--ds.xml
JBoss spezifische DataSource: <JBoss_Home>/server/jee/deploy/mysql
<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
EJB 3.1 / JPA 2.0 >> Java Framework >> SFSB Stateful Session Bean ► zustandsbehaftet
9.3.1
EJB Ressourcen
Annotation @Resource ► T
Parameter
Beschreibung
authenticationauthenticationType
description
mappedName
name
shareable
shareable
CONTAINER: die Anmeldedaten werden im
Deskriptor hinterlegt
BEAN: die Anmeldedaten werden explizit bei der
Erzeugung der Verbindung übergeben
Beschreibung der referenzierten Ressource
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
Annotation @Resources ► T
Parameter
Beschreibung
Liste der einzelnen Ressource-Annotationen
value
9.4
Typ
Default
AuthenticationTyp CONTAINER
String
String
String
Boolean
true
Typ
Default
Resource[]
DAO Data Access Object
wiki Data Access Object (DAO, deutsch: „Datenzugriffsobjekt“) ist ein Entwurfsmuster, das den Zugriff
auf unterschiedliche Arten
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
ein 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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 79 >> total: 255 Seiten
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 Bean
@Stateless
public class BankBean implements Bank {
@EJB 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
lokales 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 sein
@Test 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
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
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
Annotation @Singleton ► C
Parameter
Beschreibung
Typ
mappedName Name der referenzierten Ressource im globalen Namensdienst String
name
Name, unter dem die referenzierte Ressource im lokalen
Namensdienst (java:comp/env) der Komponente auffindbar
sein soll
Default
String
- markiert ein Singleton für eager loading während der Initialisierung der Applikation
Annotation @Startup ► C
- definiert eine Abhängigkeit zwischen Singleton ► bei der Initialisierung
Annotation @DeppendsOn ► C
Parameter
value
Beschreibung
Singleton, die vorgängig initialisiert werden müssen
Typ
Class[]
Default
Beispile ►Singleton
@Startup @Singleton
public class HelloWorldBean implenets Hello {
public String echo(String echo) {
return "Server Echo : " + echo;
}
}
@Singleton @DependsOn("HelloWorldBean")
public class GoodbyWorldBean {
public String echo(String echo) {
return "Server Echo : " + echo;
}
}
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 82 >> total: 255 Seiten
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
Annotation @ConcurrencyManagement ► C
Parameter Beschreibung
Beschreibung
Typ
CONTAINER: die Nebenläfigkeit wird durch
den Container garantiert
BEAN: die Nebenläfigkeit wird durch die
Bean garantiert
value
Default
ConcurrencyManagementType CONTAINER
- definiert Verhaltung bei Nebenläufigkeit für eine Singleton Methode
Annotation @Lock ► M
Parameter
Beschreibung
Typ
value
WRITE: definiert exclusiven Zugriff auf die Bean Instanz
READ: nur lesenden Zugriff
LockType WRITE
10.2
Default
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
Annotation @Asynchronous ► M
@Statless public class AsyncHelloWorldBean implenets AsyncHello {
@Asynchronous 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Singleton Bean
Aufgabe ► BeanBean-Instanz HitHit-Counter
- erstellen Sie eine Singleton Bean um die Zugriffe zu zählen
Ansatz
@Singleton public class HitCounter {
private long hits;
@PostConstruct public void resetCounts() {
hits = 0;
}
public void incCount() {
hits++;
}
@Lock(LockType.READ) public long tellHits() {
return this.hits;
}
}
@Stateless public class BankBean implements Bank {
@EJB private HitCounter hitCounter;
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 84 >> total: 255 Seiten
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
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
synchron
P1 P2
asynchron
P1
P2
BROKER
JMS API Java Messaging Service
- API für den Zugang zu Messaging-Systemen
- definiert Schnittstelle
- als Factory
- Message als
-
Text
Bytes
Streams
Objects
Maps
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging
jedes Interface hat zwei Ausprägungen, analog zu den beiden Kommunikationsmodellen
JMS API
Interface
PointPublishPoint-ToTo-Point
Publish-Subscribe
Subscribe
QueueConnectionFactory
TopicConnectionFactory
ConnectionFactory
Queue Connection
TopicConnection
Connection
Queue
Topic
Destination
QueueSession
TopicSession
Session
QueueSender
TopicPublisher
MessageProducer
TopicSubscriber
MessageConsumer QueueReceiver, -Browser
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 88 >> total: 255 Seiten
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
11.2.1
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)
|
Aufg
Aufgabe ► Topic / Queue bereitstellen
- erstellen Sie Topics / Queues
-
über die Admin-Konsole des Applikationsserver
per XML Deklaration
- JBoss Admin Console ► http://localhost:8080/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
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
Annotation @MessageDriven ► C
Parameter
Beschreibung
Typ
Default
name
expliziter Name der Bean
String
unqualifizierter
Klassenname
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)
eine Beschreibung für das Bean
ActivationConfigProperty[]
[]
activationConfig
mappedName
description
messageListener
messageListenerListenerInterface für das Nachrichtensystem
Interface
String
String
Class
Object.class
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 90 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging
Konfiguration der ActivationConfig
AnnotationProperty @ActivationConfigProperty ► C
Parameter
Beschreibung
Typ
acknowledgeMode
destination
destinationType
messageSelector
subscriptionDurability
11.4
- Auto-acknowledge = Nachrichten werden vom
Container bestätigt und Nachrichten werden nur
einmal zugestellt
- Dups-ok- acknowledge = Nachrichten werden vom
Container bestätigt, es können aber Duplikate
vorkommen
JNDI der Queue- oder Topic- Destination
Typ der Destination: javax.jms.Queue oder
javax.jms.Topic
Filter für empfangene Nachrichten
- NonDurable = Ist MDB nicht bereit so ist die
Message verloren
- Durable = JMS-Provider speichert Nachrichten bis
die MDB bereit ist
Default
String
String
String
String
String
Bean Life Cycle
Container initiated:
@PreDestroy
does not exist
Methode-Ready-Pool
Container initiated:
Class.newInstance()
Dependency Injection
@PostConstruct
Container initiated:
onMessage()
Timeout Callback
LifeCycleMethoden
Annotation
Beschreibung
@PostConstruct
@PreDestroy
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 91 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging
Aufg
Aufgabe ► Email durch MDB
- erstellen und deployen Sie ein ReportMDB
-
bei negativem Kontosaldo soll über die ReportMDB ein Email versendet werden
Ansatz ► BankBean
- definieren der fachlichen Logik ► (k.getSaldo() < 0f)
@Resource(mappedName = "ConnectionFactory")
private static TopicConnectionFactory factory;
@Resource(mappedName = "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
EJB 3.1 / JPA 2.0 >> Java Framework >> Messaging
Ansatz ► ReportMDB
- definieren der Logik zum Empfang der asynchroner Kommunikation ► MDB
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "destination",
propertyValue = "jms/topic/SaldoBelowZero"),
@ActivationConfigProperty(propertyName = "acknowledgeMode",
propertyValue = "Auto-acknowledge") })
public class ReportMDB implements MessageListener {
public void onMessage(Message message) {
System.out.println("\n----------------\n"
+ "ReportMDB - Got message, sending email\n"
+ message + "\n----------------");
}
}
- senden Sie eine Email an einen SMTP Server ► onMessage(Message message) { ...
Aufg
Aufgabe ► Email senden
- testen Sie den Versand von Emails 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
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 : jms/queue/myChatRoom
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "jms/queue/myChatRoom"),
@ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "MessageFormat = 'ChatMessage'"),
@ActivationConfigProperty(propertyName = "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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren
12
Aspektorientiertes
Aspektorientiertes 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
Crossross-Cutting Concern
- querschnittliche Belange einer Software
-
erlauben keine Modularisierung
► AOP bietet Lösungsansatz
12.1
Aspektorientierung
wiki Aspektorientierte Programmierung (AOP) ist ein
Programmierparadigma,
Programmierparadigma, eine Methode der ComputerComputerprogrammentwicklung, die anstrebt, verschiedene
logische Aspekte eines Anwendungsprogramms
(kurz Anwendung)
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
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.
Advice
JoinPoints
- PointCut
- eingrenzendes Muster vorhandener JoinPoints
- als Klassenfilter und Methodenmatcher
- definierte Use Cases
- ServiceMethoden
- DAO Funktionalitäten
PointCut
-
Use Case
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 97 >> total: 255 Seiten
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,
Middleware, ohne
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren
12.5
Klassenweiter Interceptor
- durch Annotation @Interceptors
- mit der Interceptor-Klasse als Parameter
Annotation @Interceptors ► C
Parameter
Beschreibung
alle Interceptoren, die bearbeitet werden sollen
value
Typ
Default
Class[]
- gilt für alle Methodenaufrufe innerhalb der Klasse
@Stateful @Interceptors(MyInterceptor.class)
public class BankBean implements Bank {
- Definition von mehreren Interceptors
- Aufruf erfolgt in der Reihenfolge der Deklaration
@Stateful @Interceptors({Interceptor1.class, 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()
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren
12.7
Methoden Intercepter
- @AroundInvoke 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 Parameter
@AroundInvoke
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
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 markiert
@PostActivate void intercept(InvocationContext ic) throws Exception
Interceptors Geschäftsmethoden vs Lebenszyklus-Ereignisse
Typ
für Geschäftsmethoden
für LebenszyklusLebenszyklus-Ereignisse
alle oder einzelne Methoden
Lifecycle Methoden
Kontext
Bean- oder Interceptor-Klasse
definiert in Interceptor-Klasse
Signature
void <methode>(Invocationcontext)
Annotation
Bean-Klasse ► @Interceptors
Interceptor-Klasse ► @AroundInvoke
Bean-Klasse ► void<methode>()
Interceptor-Klasse ► <methode>(Invocationcontext)
Bean-Klasse ► @Interceptors
vor der Bean-Klassendefinition!
Interceptor-Klasse ►Callback-Annotation
Verwendung der Container Callbackmethoden als Interceptoren
Callback Methoden des EJB Containers
Callback
Package
-Bean
Stateless SessionStateful SessionMessageDrivenStateless SessionStateful SessionMessageDriven-
@PostConstruct
javax.annotation
@PreDestroy
javax.annotation
@PostActivate
javax.ejb
Stateful Session-
@PrePassivate
javax.ejb
Stateful Session-
javax.ejb
Stateless SessionStateful SessionMessageDriven-
@Timeout
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren
12.9
Interceptoren ausschliessen
- @ExcludeClassInterceptors unterdrückt alle für die Klassen definierten Interceptoren auf
Methodenebene
-
gilt nicht für @AroundInvoke annotierte Methoden
@ExcludeClassInterceptors
public float tellRate() {
return rate;
}
- @ExcludeDefaultInterceptors unterdrückt alle im Deploymentdescriptor definierten
Default-Interceptoren
@ExcludeDefaultInterceptors
@Interceptors(TimingInterceptor.class)
@Stateful
@Remote(Bank.class)
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
Call
Call
Call
Call
Call
Call
to
to
to
to
to
to
to
fascade.BankBean.createAccount took 57 Micros
fascade.BankBean.createAccount took 12 Micros
fascade.BankBean.calculate took 29 Micros
fascade.BankBean.calculateRate took 3164 Micros
fascade.BankBean.getAccountBalance took 12 Micros
fascade.BankBean.tellRate took 12 Micros
fascade.BankBean.getSaldo took 45 Micros
Ansatz ► BankBean
@Interceptors(TimingInterceptor.class)
@Stateful
public class BankBean implements Bank { ...
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 102 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Aspektorientiertes Programmieren
Ansatz ►TimingInterceptor
- Vor- und Nachbearbeitung durch Interceptor ► @AroundInvoke
-
derfinierte Signature ► public Object timing(InvocationContext ctx) throws Exception
import static java.util.concurrent.TimeUnit.NANOSECONDS;
public class TimingInterceptor {
@AroundInvoke
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
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
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 Emails
- 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
Transak
ransaktionen
tionen
- ein Timer wird durch eine EJB erzeugt
-
13.1
EJBs laufen in einem transaktionalen Umfeld
- transaktionaler Rollback löscht den Timer wieder
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 mit @Timeout annotierte Methode aus
- Timer EJB ist Stateless
- Container führt beliebige Instanz der EJB aus
@Schedule
- @Schedule 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service
13.2
13.3
Ablauf
Timer starten
- Timer erzeugen ► Praxis: durch ein SLSB
- über EJB Kontext – TimerService ts = SessionContext.getTimerService()
- über Injection - @Resource javax.ejb.TimerService ts
@Resource 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, "in_und_alle_15_Minuten");
}
@Resource 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service
createTimer(long d, Serializable info)
- long tenDays = 1000 * 60 * 60 * 24 * 10
- createTimer(tendays,null)
periodisch
einmalig
relativ
Methode
absolut
folgende Methoden stehen zum Erstellen eines Timers zur Verfügung:
TimerService create Methoden
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 ruft @Timeout annotierte Methode beim definierten Zeitintervall auf
@Timeout
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
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
Methoden
createTimer(
createTimer(...)
...) verschiedene Methoden zum Erzeugen des Timers
liefert alle Timer, die für ein bestimmtest Bean registriert wurden.
getTimers()
Methoden des Timer Interface
Interface Timer
Methoden
cancel()
cancel()
getTimeRemaining()
getNextTimeout()
getSchedule()
getHandle() /
getInfo()
isPersitent()
isCalendarTimer()
Beschreibung
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
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 Syntax
@Schedule(second="30")
public void saldoAusgeben() { ... }
Annotation @Schedule ►
Parameter
Bereich
dayOfMonth, dayOfWeek String
String
hour,
hour, minute, second
String
year, month
String
info
boolean
persitent
String
timezone
M
Beispiel
dayOfMonth = "7-3", dayOfWeek = "Fri-Mon"
second = "10,20,30" minute = "0-10,30,40", minute = "*/5"
month="Nov"
Literal das den Timer beschreibt
true / false
timezone = "America/New_York"
Beispiele
Beispiele
- mehrere automatische Timer erzeugen
@Schedules({
@Schedule(hour = "10", dayOfWeek = "Mon-Fre"),
@Schedule(hour = "12", dayOfWeek = "Mon-Fre"),
@Schedule(hour = "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 gebunden
@Singleton public class CacheBean {
// erneuert den Singleton Cache alle 10 Minuten
@Schedule(minute=”*/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
EJB 3.1 / JPA 2.0 >> Java Framework >> Timer Service
Aufgabe ► SimpleEJBTimer
- Singleton als EJB Timer
@Singleton
public class MyTimerService {
@EJB
HelloService helloService;
@Schedule(second = "*/1", minute = "*", hour = "*", persistent = false)
public void doWork() {
System.out.println("timer: " + helloService.sayHello());
}
}
@Stateless
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 ausgeben
@Singleton
public class InterestMonitorBean {
@PostConstruct
private void getSaldoFromAccounts() { ... }
@Schedule(second = "*/15", minute = "*", hour = "*", persistent = false)
public void calculateInterest(Timer timer) {
// 15 sec pro Jahr > 4,7564688 × 10-7 = 0.00000047564688
this.currentSaldo += rate.calculate(this.startSaldo, 1) * 0.00000047564688;
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
INFO
INFO
[STDOUT] Interest gained : 0.01 on Amount 935.80 with 12.50 % Interest
[STDOUT] Interest gained : 0.03 on Amount 935.80 with 12.50 % Interest
[STDOUT] Interest gained : 0.05 on Amount 935.80 with 12.50 % Interest
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 110 >> total: 255 Seiten
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
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,
Anwendungsprogrammen, die auf unterschiedlichen
Plattformen und/oder Frameworks betrieben werden. Ein Webservice oder Webdienst ist eine
SoftwareSoftware-Anwendung, die mit einem Uniform Resource
Resource Identifier (URI) eindeutig identifizierbar ist
und deren Schnittstelle als XMLXML-Artefakt definiert, beschrieben und gefunden werden kann. Ein
Webservice unterstützt die direkte Interaktion mit anderen SoftwareSoftware-Agenten unter Verwendung
XMLXML-basierter Nachrichten
Nachrichten durch den Austausch über internetbasierte Protokolle.
Protokolle.
Beispiel WSDL
- generiert durch JBoss
-
http://localhost:8080/Bank/ZinsBean?wsdl
<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
- @WebService exportiert alle Methoden der Bean
- @WebMethod 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Webservice
14.2
Definition eines Web Service
- @WebService definiert eine Klasse als Webservice
- macht alle öffentlichen Methoden sichtbar
Annotation @WebService ► C, M
Parameter
Beschreibung
vollqualifizierter Name des Service-Endpoint-
endpointInterface Interface
Name des Port-Typs innerhalb der WSDLDefinition
Name des Webservice-Ports innerhalb der
PortName
WSDL-Definition
Name des Webservices innerhalb der WSDLserviceName
Definition
Namensraum für Port-Typ und untergeordnete
targetNamespace Elemente
Angabe einer WSDL-Datei um eine
automatische Generierung zu verhindern
wsdlLocation
(eigene Definition zu verwenden)
name
Typ
Default
String
String
implementierenden
Klasse
String
[name]
String
[name]
String
String
Aufgabe ► WebService zur Zinsberechnung
- offerieren Sie die Zinsberechnung des SLSB ZinsBean als WebService
-
ServiceEndpoint Interface deklariert WebService Schnittstelle
@WebService
@SOAPBinding(style = SOAPBinding.Style.RPC)
public interface RateServiceEndpoint extends Remote {
@WebMethod
public @WebResult(name = "ertrag")
float calculate(@WebParam(name = "betrag")
float amount, @WebParam(name = "zins")
float rate, @WebParam(name = "jahre")
int years) throws RemoteException;
}
- WebServiceZins Bean implementiert WebService Schnittstelle
@WebService(endpointInterface = "zins.RateServiceEndpoint")
@Stateless(mappedName = "ejb/zins", name= "RateBean")
public class ZinsBean implements Zins, RateServiceEndpoint { ... }
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 113 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Webservice
- generierte WSDL Datei ►http://localhost:8080/Bank/ZinsBean?wsdl
- JUnit Test
@Before public void setUp() throws Exception {
URL url = new URL("http://127.0.0.1:8080/Bank/ZinsBean?wsdl");
QName qname = new QName("http://zins/", "ZinsBeanService");
ServiceFactory factory = ServiceFactory.newInstance();
Service service = factory.createService(url, qname);
se = (RateServiceEndpoint) service.getPort(RateServiceEndpoint.class);
assertNotNull(se);
assertTrue(se instanceof RateServiceEndpoint);
}
@Test 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
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security
15.2
Security Roles
Security Rollen werden in verschiedenen Entwicklungsbereichen definiert.
Bean Provider (EJB(EJB-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;
@Resource
} 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
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
-
15.3
SessionContext.getCallerPrincipal
SessionContext.isCallerInRole
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
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);
...
15.5
Realms
realm [Engl.] für Bereich
- Realms definieren einen Bereich, in dem sich
eine Gruppe von Benutzern authetifizieren
15.6
LDAP (Lightweight Directory Access Protocol) Server
Datenbank
Dateien
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
EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security
15.7
Declarative vs Programmatische Security
Web Tier
Web
Resources
web.xml
deklarative programmatische
Sicherheit
Sicherheit
EJB Tier
Bean Methods Zugriffskontrolle
ejb-jar.xml
Deklaration
Deployment
Descriptor
Programm
Web Container EJB Container
Umsetzung
Container
Programm
Servlet / JSP
Codierung
"all or
nothing"
Logikbasiert
15.8
EJB Bean
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
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
15.10
Security Annotations
- Security kann auch annotiert werden
Annotation
Typ
Methode
Klasse
EJB Security
@PermitAll
@DenyAll
@RolesAllowed
@DeclaredRoles
@RunAs
Beschreibung
alle Rollen bekommen Zugriff
sinnvoll bei geerbter Security
selektioniert Methodenzugriff per Liste
definiert Methodenzugriffe per Liste
legt die Rolle zur Ausführung fest, ungeachtet der Client
Authorisierung
Die Securitydomäne wird Serverspezifisch definiert: org.jboss.ejb3.annotation.SecurityDomain
@SecurityDomain
definiert Securitydomäne
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 121 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security
15.11
RunAS
- definiert das weitere Security-Verhalten
Annotation @RunAs ► C
Parameter
Parameter Beschreibung
Name der Rolle, die verwendet werden soll
value
Typ
Default
String
- 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 "admin" ausgeführt
@SecurityDomain("FileRealmSecurityDomain")
@RolesAllowed({"owner", "trustee"})
@RunAs("admin")
@Stateless(mappedName = "ejb/zins", name= "RateBean")
public class ZinsBean implements Zins { ... }
15.12
Security Domain
wiki A Security Domain is the
the 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
EJB 3.1 / JPA 2.0 >> Java Framework >> JEE Security
Security Domain definieren
- annotiert
- deklarativ
Annotiert
- @SecurityDomain
import org.jboss.ejb3.annotation.SecurityDomain;
@Stateful
@SecurityDomain("FileRealmSecurityDomain")
@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>
...
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 123 >> total: 255 Seiten
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>
mysql> select * from roles;
mysql> select * from users;
</authentication>
+-----------+-----------+
+-----------+---------+
</application-policy>
- entsprechende DB Schema
- MySqlDB.users / MySqlDB.roles
15.13
| user
| password |
+-----------+-----------+
| kunde
| kunde
|
| verwalter | verwalter |
+-----------+-----------+
2 rows in set (0.00 sec)
| user
| role
|
+-----------+---------+
| verwalter | trustee |
| kunde
| owner
|
+-----------+---------+
2 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 Zugriffsrechte deklarieren
@Stateful
@SecurityDomain("MySqlRealmSecurityDomain")
@RolesAllowed({ "owner", "trustee" })
public class BankBean implements Bank {
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 124 >> total: 255 Seiten
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
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
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
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
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).
Atomarität). Transaktionen werden von Transaktionssystemen verarbeitet;
diese erzeugen dabei aus mehreren Transaktionen eine Historie. Transaktionen kommen meist bei
Datenbanksystemen zum Einsatz.
16.1
-
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
16.1.1 Transaktionskonzepte
ACIDACID-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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
16.1.2
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
16.1.3
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
ablaufenden Transaktion durch Änderung
der benutzten Daten in einen undefinierten Zustand gebracht werden kann. Die Isolation ist eine
der vier ACIDACID-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
READ_UNCOMMITTED
READ_COMMITTED
REPEATABLE_READ
SERIALIZABLE
16.1.4
keine Transaktion möglich
alle Transaktionen sehen die Änderungen von anderen Transaktionen
nicht abgeschlossene Transaktionen sind unsichtbar für andere Transaktionen
eine Transaktion sieht nur Daten, die vor ihrem Startzeitpunkt vorhanden waren
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
1
2
User T1
Daten Z
User T2
3
UPDATE
10
11
4
5
ROLLBACK
11
SELECT
10
10
SELECT
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 130 >> total: 255 Seiten
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
read
Transaktionsablauf
1
2
User T1
Daten Z
3
4
SELECT
10
10
User T2
5
SELECT
11
11
UPDATE
COMMIT
11
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
read
Transaktionsablauf
1
User T1
Daten Z
User T2
2
3
4
SELECT
10
10,11
5
SELECT
11,11,12
11,11,12
INSERT
COMMIT
10,11,12
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 131 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
Lost Update
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
update
Transaktionsablauf
1
2
User T1
SELECT
Daten Z
10
3
4
COMMIT
10
User T2
5
SELECT
11
12
SELECT
12
COMMIT
mögliche Vorkommen von Datenkonflikten durch Isolationsebenen
mögliche Daten-Konflikte
Isolationsebene
Read Uncommitted
Read Committed
Repeatable Read
Serializable
Dirty
Read
Lost
Update
Non
Repeatable
Read
Phantom
Read
- 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
kontrollierbar dur
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);
- Methoden
@Lock(LockType.READ)
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
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.
Ausdehnung.
Propagations
Bezeichnung
Verhalten
PROPAGATION_MANDATORY
PROPAGATION_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
PROPAGATION_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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
16.3
JTS Java Transaction Service
- JTS spezifiziert die Implementierung eines Transaktionsmanagers
TransaktionsM
TransaktionsManager
- 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
16.5
Transaktionshandling
wiki Als Konsistenz bezeichnet man bei Datenbanken
allgemein die Widerspruchsfreiheit von Daten.
Daten.
Konsistenz ist eine der vier in DatenbankDatenbank-Transaktionen
geforderten ACIDACID-Eigenschaften.
Eigenschaften.
Transaktionen
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
16.5.1
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>
<enterprise-beans>
Annotiert
@TransactionManagement(TransactionManagementType.BEAN)
@Stateful
public class BankBean implements Bank { ... }
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 136 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
Steuerung der Transaktion ► mit UserTransactionUserTransaction-Objekt
- als JNDI lookup
ic = new InitialContext();
UserTransaction ut = (UserTransaction) ic.lookup("java:comp/env/UserTransaction");
ut.begin();
...
- über SessionContext
@Resource SessionContext sc;
UserTransaction ut = sc.getUserTransaction();
- über Dependency Injection
@TransactionManagement(TransactionManagementType.BEAN)
@Stateful public class KontoBean implements Konto {
@Resource UserTransaction ut;
16.5.2
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 Methoden
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void transfereAmount(Konto fromAccount, Konto toAccount, Float amount) {
try {
withdrawAmount(fromAccount, amount);
depositAmount(toAccount, amount);
} catch (Exception e) {
e.printStackTrace();
}
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
Annotationen für die Transaktionssteuerung
Transaktionssteuerung
- auf Bean-Ebene
Annotation @TransactionManagement ► C
Parameter
Beschreibung
TransactionManagementType Transaktionsmanagement
Konstante
Default
CONTAINER
BEAN
CONTAINER
- auf Methoden-Ebene
Annotation @TransactionAttribute ► M
Parameter
Beschreibung
Beschreibung
TransactionAttribute
TransactionAttributeType
AttributeType
Transaktionsattribut
Konstante
Default
REQIRED
REQUIRES_NEW
MANDATORY
REQUIRED
SUPPORTS
NOT_SUPPORTED
NEVER
- 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
unterstützen oder erzeugen
-
Never
- die Methode darf nicht in eine Transaktion
einbezogen werden
- nicht alle Transaktions-Attribute lassen sich
mit allen Beans nutzen
-
Tabelle zeigt Kombinationsmöglichkeiten
Transaktions-Attribut
SLSB SFSB MDB
Required
RequiresNew
Mandatory
Supports
NotSupported
Never
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 138 >> total: 255 Seiten
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 mit @ApplicationException annotiert werden
Annotation @ApplicationException ► C
Parameter
rollback
rollback
Beschreibung
Typ
Default
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 Kontainer)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void transferAmount(Konto from, Konto to, Float amount) {
this.withdrawAmount(from, amount);
this.depositAmount(to, amount);
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionsmanagement
Aufgabe ► Konfiguration By Exception durch ApplicationException
- unterschreiten der Kreditgrenze soll verhindert werden
@ApplicationException(rollback = true)
public class SaldoBelowCreditLimitException extends Exception {
public SaldoBelowCreditLimitException (String reason) {
System.out.println(reason);
}
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
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()
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
Transaktion
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 140 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> ORM Object-Relation-Mapping
17
ORM ObjectObject-RelationRelation-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
-
Darstellung der Entitäten durch POJOs
nicht auf den Einsatz unter Java EE begrenzt
-
Version 2.0
lauffähig unter Java SE / ausserhalb eines EE Containers
JBoss AS
JPA Java Persistence API – Version 1.0
- Spezifikation für O/R Mapping
Version 3.1
JSR 220
EJB3 – Version 3.0
- Spezifikation für Container Komponenten
- Spezifik
Spezifikation für Managed Persistence
JSR 318
Begriffserklärungen
JSR 317
17.1
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
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
18
JPA
- spezifiziert durch JSR 220 / JSR 317
- 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
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
Persistezprovider
JPA Standard
synchronisiert mit DB
Datenbank
Transaktion
Entity
Manager
garantiert ACID der DB
lädt / speichert
arbeitet auf
Entity
Objekt RepräsenRepräsentation eines Tupel
umfasst
Instanz von
POJO
- serialisierbar
- Default Konstruktor
- private Attribute
- getter / setter
18.1.1
assoziiert mit
Menge aller
Entitäten einer
Transaktion
Transaktion
FirstFirst-LevelLevel-Cache
Persistenz
Kontext
bezieht sich auf
Entity
Klasse
Persistenz
Unit
- Entityklassen
- Datasource
- Abbildungsinfos
umfasst
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 Annotation @Entity
- per XML orm.xml
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 144 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
Deklaration einer Entity mit Annotations
- Markierung der Klassenattribute
- oder Markierung der Getter-Methoden
@Entity
public class Person implements Serializable {
@Id
private Long id;
private String name;
@ManyToMany(targetEntity = Address.class)
private Collection<Address> addresses;
getter / setter / Konstructor / hashCode / equals / toString
@Entity
@Table(name="Adresse")
public class Address implements Serializable {
@Id
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
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
18.1.2
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="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" 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" />
...
18.1.3
EntityManager
- verwaltet die Entities
- ist genau einem Persistenzkontext zugeordnet
- als Container-Managed Entity Manager
- als Application-Managed Entity Manager
ContainerContainer-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
ApplicationApplication-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
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
18.1.4
Persistenzkontext
- Menge aller Entitäten einer Transaktion
- durch UC Use Case definiert
- Cache
- First Level Cache definiert durch Framework
- z.B. Hibernate
@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE)
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
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
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()
garbage
remove()
New
garbage
refresh()
find()
getReference()
getResultList()
getSingleResult()
persist()
merge()**
Removed
persist()
remove()
Managed
- JPA Objekt Zustandsdiagramm
- Zustandsänderung durch
persist()
refresh()
merge()
Operationen des Persistenzkontext
- Methoden der EntityManager-Instanz
-
Methoden der Query-Instanz
remove()
refresh()
merge()
detach()
close()*
clear()*
lock()
merge()**
Detached
* betrifft alle Instanzen des Persistenzkontext
** erzeugt persistente Instanz, Originalobjekt bleibt erhalten
wirft Exception
garbage
persist()
remove()
refresh()
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 148 >> total: 255 Seiten
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
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,
JavaJava-Objekt bleibt verfügbar, vorausgesetzt,
vorausgesetzt, es wird noch referenziert.
referenziert.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 150 >> total: 255 Seiten
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 Annotation @Entity 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
KlassenHirarchie 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
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
18.3.1
Primärschlüssel
- einfaches Attribut der Klasse ► @Id
- alle primitiven Javatypen
- java.lang.Long / java.lang.String / java.util.Date / java.sql.Date
- java.math.BigInteger / java.math.BigDecimal ► Praxis ?
- Primärschlüsselklasse ► @IdClass
- 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 Schlüssel ► @EmbeddedId
- 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
Ausserdem
sserdem muss er in der obersten
Klasse der Hierarchie deklariert sein.
18.4
Beziehungen zwischen Entities
Embeddable Klassen
- durch die Annotation @Embeddable markiert ► nicht @Entity
- 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 ► @OneToOne
- 1 : n / n : 1 ► @OneToMany / @ManyToOne
- n : m ► @ManyToMany
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 152 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
uni
uni-direktionale
direktionale Beziehungen
- vom Anwenderfall definiert ► UCs
-
einfachere Strategie
bibi-direktionale Beziehungen
- unterscheiden zwischen "Besitzer" und der referenzierten Seite
-
Besitzer durch Userverhalten (UC) definiert
referenzierte Seite muss auf ihren Besitzer durch mappedBy verweisen
@Entity public class Person implements Serializable {
@Id private Long id;
...
@ManyToOne private Address address;
...
@Entity @Table(name = "Adresse")
public class Address implements Serializable {
@Id private Long id;
...
@OneToMany(mappedBy = "address") private Collection<Person> persons;
18.4.1
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 mit @Entity 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
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
bezeichnet Menge von EntityEntity-Objekten die innerhalb
der Datenbank höchstens ein JavaJava-Objekt im Kontext repräsentieren.
repräsentieren.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 154 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
EntityMana
EntityManager definiert:
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
ContainerContainer-Managed
Managed Entity Manager ►@PersistenceContext
- 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
ApplicationApplication-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
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
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
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
Exception des EntityManagers
IllegalArgument
IllegalArgumentArgument-
Objekt ist keine Entity
OptimisticLock
OptimisticLockLockRollbackRollbackTransactionTransactionRequiredRequired-
DB Inhalt wurde geändert
Rollback kann nicht durchgeführt werden
keine laufende Transaktion
joinTransction
Entity existiert nicht (mehr)
contains
EntityNotFound
EntityNotFoundFound-
lock
PK existiert bereits
refresh
EntityExistsEntityExists-
flush
setzt Transaktionsstatus auf RollbackOnly
getReference
PersistencePersistence-
find
Beschreibung
remo
remove
ve
-Exception
EntityMangers Methoden
merge
Exception des EntityManagers
persist
18.6.1
NoResultQuery.getSingleResult() liefert kein
NoResultNoUniqueResult
NoUniqueResultResult- 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
18.7.1
Listener als Container Callback
- Interception durch Container
- als Lifecycle Ereignis
- erweitert Persistenzmechanismus durch eigene Funktionalitäten
Container Callback als EnitiyListener
Annotation
Beschreibung
@PrePersist / @PreRemove
@Post
@PostPersist
ostPersist / @Post
@PostRemove
ostRemove
@PreLoad / @PreUpdate
@PreUpdate
@PostLoad
@PostLoad / @PostUpdate
@PostUpdate
vor der Ausführung von EntityManger.persist() / remove()
nach der Ausführung von EntityManger.persist() / remove()
vor der Ausführung von EntityManger.update() / refresh()
nach der Ausführung von EntityManger.load() / update()
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 159 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> JPA
18.7.2
Listener als Entity-Listener-Klasse
- durch @EntityListeners 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 der @EntityListener 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
Verwendung von CallbackCallback-Methoden und Entity Listenern
@Entity
@EntityListeners(value = { PersonListener1.class, PersonListener2.class })
public class Person implements Serializable {
@PostPersist protected void postPersistPerson() {
System.out.println("PostPersist Person called");
}
public class PersonListener1 {
@PrePersist @PostPersist 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 {
@PostPersist protected void postPersistMethod1(Person p) {
System.out.println("PostPersist PersonListener2 called");
}
}
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 160 >> total: 255 Seiten
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 die Entity
@Entity
@NamedQueries({
@NamedQuery(name = "Person.findAll",
query = "from Person p"),
@NamedQuery(name = "Person.findByName",
query = "from Person p where p.name = :name") })
public class Person implements Serializable { ... }
- implementiert und parametrisiert durch die Fassade
@Stateless public class BankBean implements Bank {
@PersistenceContext(unitName = "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
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 definiert
@SqlResultSetMapping(name = "PersonWithMultipleAccounts", entities = {
@EntityResult(entityClass = entity.Person.class, fields = {
@FieldResult(name = "name", column = "name") }),
@EntityResult(entityClass = entity.Konto.class, fields = {
@FieldResult(name = "name", column = "name") }) })
public class Person implements Serializable { .. }
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 162 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate
19
Hibernate
- Open-Source-Persistenz- und ORM-Framework für Java www.hibernate.org
- speichert POJOs mit Attributen und Methoden in relationalen Datenbanken
- synchronisiert DB Relationen mit Objekten
Vorteile
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,
Polymorphie, Assoziations
Assoziations, Collections
Collections und Queries.
Queries.
Hibernate Annotations sind immer eine Einschrä
Einschränkung der Portabilität.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 163 >> total: 255 Seiten
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
Annotation
Beschreibung
Überprüfung von Stringlängen
@Lenght
Min-, Maximalwert für numerische Werte
@Min / @Max
überprüfung auf NULL
@NotNull
überprüft, ob ein Datum in der Vergangenheit / Zukunft liegt
@Past / @Future
überprüft, ob ein Attribut einem regulären Ausdruck entspricht
@Pattern
Wertebereich für numerische Werte
@Range
überprüfung der Länge von Collections, Arrays und Maps
@Size
überprüft boolean Werte auf false
@AssertFalse
überprüft boolean Werte auf true
@AssertTrue
führt eine Überprüfung des markierten Objekts durch
@Valid
überprüft Kreditkartennummern auf true
@CreditCardNumber
überprüft EAN-Nummern auf true
@EAN
überprüft Emails auf true
@Email
überprüft auf Digits
@Digits
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 164 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate
Beispiel ►Validierung einer Instanzvariablen
import org.hibernate.validator.Length;
import org.hibernate.validator.NotNull;
@Entity public class Person implements Serializable {
@Length(max=10) @NotNull private String name;
Beispiel ► Definition von HibernateConstraints
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Hibernate
19.5
Hibernate Tools
SQL
- 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
Kategorie Beschreibung Anwendung
Data Definition CREATE
DDL
Language
DROP
DML
Data
Manipulation
Language
UPDATE
DCL
Data Control
Language
GRANT
REVOKE
DRL
Data Retrival
Language
SELECT
- Third Party Tool
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 166 >> total: 255 Seiten
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
-
20.1
Verwaltungsfunktionen
Suchfunktionen
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="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" 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
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
- @Entity vor der Klassendefinition
-
Getter- und Setter-Methoden
- Java Nameskonventionen
-
id als eindeutigen Bezeichner für persistente Klasse ► Praxis: Long
- durch @Id annotiert
-
Standardkonstruktor ► auch private möglich
@Transient für nicht persistente Felder
Annotation @Entity ► C
Parameter
Beschreibung
Name der Entity
name
Typ
Default
String
Klassenname
@Entity(name="Person")
public class Person implements Serializable {
Tabelle
Annotation @Table ► C
Parameter
Beschreibung
Tabellenname
name
Typ
Default
String
schema
Tabellenschema
String
catalog
Tabellenkatalog
String
Klassenname
datenbankspezifisches
Schema
datenbankspezifischer
Katalog
uniqueConstraint
Unique-Constraints, die auf der
Tabelle definiert werden sollen
UniqueConstraint[]
- Verwendung
- anpassen an Legacy
@Entity
@Table(name = "Adresse")
public class Address implements Serializable {
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 168 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel
Fassade
wiki Fassade (engl. facade
facade)
de) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und
gehört zu der Kategorie der Strukturmuster (Structural
(Structural Patterns).
Patterns). Es bietet eine einheitliche und
meist vereinfachte Schnittstelle zu einer Menge von Schnittstellen eines Subsystems.
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
Annotation @PersitenceContext ► C M F
Parameter Beschreibung
Typ
Name der EntityManagerFactory
String
name
String
unitName Name der PersistenzUnit
type
Art des Kontextes
properties
eine Liste von Eigenschaften
PersistenceContextType
- TRANSACTION
- EXTENDET
PersistenceProperies[]
Default
TRANSACTION
herstellungsabhängige Eigenschaften für eine Referenz auf den PersistenceContext
Annotation @PersitenceProperty ► C M F
Parameter Beschreibung
Typ
Default
Name der Eigenschaft
String
name
Wert der Eigenschaft
String
value
Liste von PersistenceContext Annotationen
Annotation @PersitenceContexts ► C
Parameter Beschreibung
Typ
Liste von PersistenceContext
PersistenceContext[]
value
Default
Beispiel
@PersistenceContexts({
@PersistenceContext(name = "persistence/creditBank", unitName = "creditBank"),
@PersistenceContext(name = "persistence/debitBank", unitName = "debitBank")
})
@Stateless
public class BankBean implements Bank {
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 169 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel
Abhängigkeit zu einer EntityManagerFactory
Annotation @PersitenceUnit ► C M F
Parameter Beschreibung
Typ
Name der EntityManagerFactory
String
name
String
unitName Name der persistenten Einheit
Liste von PersistenceUnit Annotationen
Annotation @PersitenceUnits ► C
Parameter Beschreibung
Typ
Liste von PersistenceUnits
PersistenceUnit[]
value
Default
Default
Beispiel
@PersistenceUnit
private EntityManager manager;
@PersistenceContext(unitName = "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
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 ► http://www.springsource.com
- der EntityManager muss dabei selbst verwaltet werden
20.2.1
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();
...
20.2.2
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Kontoverwaltung als Anwendungsbeispiel
20.2.3
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
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,
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 haben
@Test 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
}
Prax
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Generatorstrategien
22
Generatorstrategien
- persistente Datenbankobjekte haben eine Identität ► PK
- @Id definiert Primary Key Attribut
- @GeneratedValue 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
Annotation @GeneratedValue ► T
Parameter Beschreibung
strategy
Strategie zum definieren des Primary Keys
generator
Name des Primärschlüsselgenerators
Parameter
AUTO
IDENTITY
SEQUENCE
TABLE
String
Default
AUTO
verwendet die Strategy
der Datenbank
@Id @GeneratedValue private Long id;
@Test 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Generatorstrategien
Generatoren für die Primärschlüssel
Strategie
Beschreibung
AUTO
TABLE
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
IDENTITY
SQL Server gibt.
Entspricht der Hibernate-Generatorstrategie identity.
SEQUENCE
ENCE unterstützt Sequences, die es beispielsweise in PostgreSQL, Oracle und Firebird gibt.
SEQU
Entspricht der Hibernate-Generatorstrategie sequence.
@Id
@GeneratedValue (strategy=GenerationType.AUTO)
private Long id;
Annotation @SequenceGenerator ► T
Parameter
Beschreibung
Typ
name
sequenceName
initalValue
allocationSize
eindeutiger Name innerhalb der
Persistence-Unit
kann von anderen Entities
referenziert werden
Datenbank abhängiges SequenzObjekt
Anfangswert für die Generierung
Schrittweite
Default
String
String
int
int
abhängig vom
Persistence-Provider
0 oder 1
50
@Id
@GeneratedValue(generator = "useridgen")
@GenericGenerator(name = "useridgen", strategy = "seqhilo", parameters = {
@Parameter(name = "max_lo", value = "5"),
@Parameter(name = "sequence", value = "mysequence") })
private Long id;
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 175 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Generatorstrategien
Annotation @TableGenerator ► T
Parameter
Beschreibung
Typ
name
eindeutiger Name innerhalb der Persistence-Unit
String
table
Tabellenname
schema
Tabellenschema
catalog
Tabellenkatalog
pkColumnName
Spalte für den Namen der Generatoren
valueColumn
valueColumnName
umnName
Spalte für den Zählerstand des PK
pkColumnValue
Generatorname
initialValue
allocationSize
uniqueConstraints
uniqueConstraints
Anfangswert für die Generierung
Schrittweite
Definition von Constraints
22.2
Default
abhängig vom
Persistence-Provider
datenbankspezifisches
String
Schema
datenbankspezifischer
String
Katalog
abhängig vom
String
Persistence-Provider
abhängig vom
String
Persistence-Provider
abhängig vom
String
Persistence-Provider
int
0 oder 1
int
50
UniqueConstraint[]
String
Definition des Primary Key
- definiert eine Klasse als fachliche Kombination für den Primärschlüssel
Annotation @IdClass ► E
Parameter
Beschreibung
Typ
value
Class
das Klassenobjekt der Primärschlüsselklasse
Default
@Entity(name="Person")
@IdClass(PersonPK.class)
public class Person implements Serializable {
@Id private Long p_id;
@Id private String p_context;
- definiert eine eingebettete Klasse als zusammengesetzten Primärschlüssel
Annotation @EmbeddedId ► M, F
Parameter
Beschreibung
Typ
Default
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 176 >> total: 255 Seiten
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
- bi-direktional ► @mappedBy gibt führendes Ende an
- N Seite als Collection
- java.lang.List ► Reihenfolge der Elemente nicht gegeben ► @OrderBy
- java.lang.Set
- java.lang.Map
- org.hibernate.mapping.Bag
Collections
Eigenschaft
duplikatfrei
indexiert
inverse
performates Update
performates
performates Inverse
23.1
List Set Map Bag
Entity vs Value Komponenten
EntityEntity-Komponente
- haben einen Primärschlüssel
- haben einen Lebenszyklus
Valuealue-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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 177 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen
Komposition vs. Aggregation
wiki Die Komposition (composite
(composite aggregation oder composition)
composition) als
als Sonderfall der Aggregation
beschreibt die Beziehung zwischen einem Ganzen und seinen Teilen.
Teilen. Der Unterschied zur
Aggregation ist im Kern, dass die Existenz des TeilTeil-Objektes durch die des übergeordneten
Objektes bedingt ist.
Ein Teil kann immer nur genau
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.
Assoziation.
23.2
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 ► ev. @NotNull
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 ValueValue-Komponente,
Komponente, hat also
keinen Primärschlüssel.
Komposition wird in UML mit einer gefüllten Raute dargestellt ► http://www.omg.org
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 178 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen
23.2.1
Embeddable
- Annotation @Embeddable definiert Komponente auf Klassenebene
- ohne @Id
- Entity Person mit dem Attribut address muss nicht gekennzeichnet werden
- @Embedded ist optional
Aufgabe ►Embe
Embedded Klasse
- testen Sie die Adresse als Value-Komponente
@Entity public class Person implements Serializable {
@Embedded // optional
private Address address;
@Embeddable public class Address implements Serializable { ... }
23.2.2
Sekundärtabellen
- @SecondaryTable deklariert Instanzvariable als Value-Typ
- @SecondaryTable definiert die Tabelle der Value-Komponente
Annotation @SecondaryTable ► E
Parameter
name
Beschreibung
Typ
Tabellenname
String
schema
Tabellenschema
String
catalog
Tabellenkatalog
String
uniqueConstraint
pkJoinColumns
Annotation
Parameter
value
Default
datenbankspezifisches
Schema
datenbankspezifischer
Katalog
Unique-Constraints, die auf der
UniqueConstraint[]
Tabelle definiert werden sollen
PKs der Tabellen über die die
PrimaryKeyalle PKs der
Beziehung hergestellt werden soll CoinColumn[]
Primärtabelle
@SecondaryTables ► E
Beschreibung
Liste von SecondaryTables
Typ
Default
SecondaryTable[ ]
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 179 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen
Column
Persistenzprovider definiert als Spaltennamen für Komponenten den Attributnamen
- Annotation @Column definiert den Spaltennamen benutzerspezifisch
- @Column definiert den Namen der Tabellenspalte
Annotation @Column ► T
Parameter
Beschreibung
Typ
Default
name
String
Name des Attributs
Boolean
false
Boolean
Boolean
Boolean
String
String
int
int
int
true
true
true
referenzierte Spalte
Primärtabelle
255
herstellerabhängig
0
unique
nullable
insertable
updatable
columnDefinition
table
table
length
precision
scale
Spaltenname
definiert eindeutiges Schlüsselfeld, kann alternative über
uniqueConstraint auf Tabellenebene deklariert werden
erlaubt Null-Werte, hat für primitive Java Typen keine Wirkung
definiert die Insert-Funktionalität
definiert die Update- Funktionalität
Fragment der SQL Typendefinition
Namen der Tabelle, welche die Spalte enthält
Spaltengrösse ► nur für String anwendbar
Anzahl Stellen ►nur für numerische Spalten
Anzahl Nachkommastellen ► nur numerische Spalten anwendbar
Aufgabe ►SecundaryTable
- testen Sie die Addresse mit
Instanzvariablen als Sekundärtabellen
-
- email ►persöhnliche Emailadresse
- owned ►als Boolscher Wert
@Entity
@SecondaryTables( {
@SecondaryTable(name = "EMAIL"),
@SecondaryTable(name = "OWNED") })
public class Address implements Serializable {
@Column(name = "personal_email",
table = "EMAIL")
private String email;
@Column(name = "self_owned",
table = "OWNED")
private boolean owned;
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 180 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Beziehungen
Aufgabe ► Column
- setzen Sie die Attribute der Adresse benutzerspezifisch mit der @Column Anotation
-
email als unique
owned als read-only
@Column(name = "personal_email", table = "EMAIL", unique = true)
private String email;
@Column(name = "self_owned", table = "OWNED", insertable = false)
private boolean owned;
@Test(expected = EJBException.class)
public void testReadOnlyOwnedUniqueEmail () {
Address a = new Address("Strasse", "Ort", "[email protected]", true);
bank.createAddress(a);
bank.createAddress(a);
}
ERROR [org.hibernate.util.JDBCExceptionReporter] Duplicate entry '[email protected]' for key 'personal_email'
AttributeOverride
- überschreibt die Definition eines Feldes in der Superklasse
-
ermöglicht Wiederverwendung der Komponente
Annotation @AttributeOverride ► C F M
Parameter
Beschreibung
Typ
Attribut
String
name
Spaltenname
@Column
column
Annotation @AttributeOverrides ► C F M
Parameter
Beschreibung
Typ
Liste von AttributeOverride
AttributeOverride[]
value
Default
Default
Aufgabe ► AttributeOverride
@Entity public class Person implements Serializable {
@AttributeOverrides( {
@AttributeOverride( name = "street", column = @Column(name = "personstreet")),
@AttributeOverride( name = "city", column = @Column(name = "personcity", length = 50)) })
private Address address;
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 181 >> total: 255 Seiten
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 ► 1:1 ► @OneToOne
- eine Klasse steht mit einer anderen Klasse in Beziehung
-
Eins-zu-Viele / Viele-zu-Eins ► 1:n / n:1 ► @OneToMany / @ManyToOne
- eine Klasse steht mit mehreren anderen Klassen in Beziehung
-
Viele-zu-Viele ► n:n ► @ManyToMany
- 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
- @AssociationOverride resp. @AssociatenOverrides
Annotation @AssociationOverride ► C F M
Parameter
Beschreibung
Typ
p
Ty
Attribut
String
name
Liste von Spaltenname
@JoinColumn[]
joinColumns
Annotation @AssociationOverrides ► C F M
Parameter
Beschreibung
Typ
Menge von AssociationOverride AssociationOverride[]
value
Default
Default
@Entity
@AssociationOverride( name = "address",
joinColumns = @JoinColumn(name="address_fk"))
public class Person implements Serializable { ... }
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 182 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
24.2
Überschreiben von Fremdschlüsselbezeichnungen
Annotation @JoinColumn ► F M
Parameter
Beschreibung
Spaltenname
name
definiert eindeutiges Schlüsselfeld, kann auch über
uniqueConstraint auf Tabellenebene deklariert werden
erlaubt Null-Werte, hat für primitive Typen keine Wirkung
nullable
definiert die Insert-Funktionalität
insertable
definiert die Update-Funktionalität
updatable
columnDefinition Fragment der SQL Typendefinition
unique
referencedreferencedColumnName
Name der Spalte auf die referenziert wird
Annotation @JoinColumns ► F M
Parameter
Beschreibung
Menge von JoinColumn
Annotations
value
24.3
Typ
Default
String
Attribut
Boolean false
Boolean
Boolean
Boolean
String
true
true
true
ref. Spalte
String
ref. PK
Typ
Default
JoinColumn[]
@OneToOne
- bei 1:1 Beziehungen haben die beiden Tabellen den gleichen Primary-Key
- Primary-Key selbst erzeugen ► nicht Business-Key verwenden
- Generatorstrategie verwenden
Annotation @OneToOne ► M F
Parameter
Beschreibung
targetEntity Entitätsklasse
Angabe der Kaskadierungsoperationen
cascade
definiert Ladeverhalten des Attribut
fetch
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
Typ
Default
Class
Attributtyp
CascadeType[]
FetchType
EAGER
Boolean
true
String
falls keine Kaskadierung für die Beziehung
Beziehung definiert wurde ist ein
expliziter
expliziter Aufruf von persist() notwendig
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 183 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
Aufgabe ► Primärschlüssel der Relation selbst erzeugen
- Annotation @OneToOne kennzeichnet Address als 1-zu-1-Beziehung
-
beide in Beziehung stehende Objekte haben immer denselben Primärschlüssel
- Annotation @PrimaryKeyJoinColumn
-
als Unidirektionale 1-zu-1-Beziehung mit gemeinsamem PK
@Enity public class Person implements Serializable {
@Id @GeneratedValue private Long id;
@OneToOne @PrimaryKeyJoinColumn private Address address;
@Enity public class Address implements Serializable {
@Id private Long id;
@Test public void createPersonWithAddress() {
persist(p) erzeugt einen Primärschlüssel für die Person
Person p = new Person();
p.setName("Name");
id für die Entity Address muss selbst gesetzt werden
bank.createPerson(p);
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 ► bibi-direktionale 1:1 Beziehung
- Address kann Person referenzieren
-
Address.person mit @OneToOne annotiert
- Attribut mappedBy definiert die führende Entity ► auch die "owing" Seite der Beziehung
@Enity public class Person implements Serializable {
@Id @GeneratedValue private Long id;
@OneToOne @PrimaryKeyJoinColumn private Address address;
@Entity public class Address implements Serializable {
@Id private Long id;
@OneToOne(mappedBy = "address") private Person person;
@Test 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
24.4
@OneToMany
- jedes Konto gehört einer Person
- sonst existiert es nicht ► Komposition
- eine Person hat mehrere Konten
- eine Person kann auch kein Konto haben
Annotation
Parameter
targetEntity
cascade
fetch
mappedBy
orphanRemoval
@OneToMany ► M F
Beschreibung
Typ
Entitätsklasse
Angabe der Kaskadierungsoperationen
definiert Ladeverhalten des Attributs
definiert Attribut der führenden Entity
löscht die in Beziehung stehenden Entities mit
Class
Attributtyp
CascadeType[]
FetchType
LAZY
String
boolean
false
Default
@OneToMany(cascade = CascadeType.PERSIST, fetch=FetchType.EAGER)
private List<Account> accounts;
24.4.1
@OneToMany Parameter
- cascade
- Weitergeben der Persistenzfunktionalität an den in Beziehung stehenden Entities
- fetch
- Laden der in Beziehung stehenden Entities
cascade
Parameter
value
Beschreibung
Beschreibung
Typ
Default
Cascade-Stategie
CascadeType[] kein Durchreichen
CascadeType
Parameter Beschreibung
alle Persistenzfunktionen des Entitymangers werden weitergereicht
ALL
REMOVE reicht Entitymanager.remove an die in Beziehung stehende Entity weiter
PERSIST 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
MERGE
org.hibernate.annotations.CacadeType
org.hibernate.annotations.CacadeType definiert die Cascadierung
feingranularer
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 185 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
fetch
Parameter
value
Beschreibung
Typ
Default
Fetch-Stategie
FetchType
LAZY
FetchType
Parameter Beschreibung
alle in Beziehung stehenden Entities werden sofort vollständig geladen
EAGER
die in Beziehung stehenden Entities werden erst bei Bedarf (nach-) geladen
LAZY
- 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
LazyLazy-LoadingLoading-Strategie in der Praxis komplex ► unkla
unklare
nklare Spezifikation
Aufgabe ► @OneToMany
- testen Sie die 1:N Bezehung
-
als Aggregation zwischen Person und Konto
@OneToMany(cascade = CascadeType.PERSIST, fetch=FetchType.EAGER)
private List<Account> accounts;
@Test 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
24.5
JoinColumn
- definiert die Tabellenspalte als Fremdschlüssel der Beziehung
Annotation @JoinColumn ► M F
Parameter
Beschreibung
Spaltenname
name
Typ
Default
String
Attributsname
Boolean
false
Boolean
true
Boolean
true
Boolean
true
updatable
definiert eindeutiges Schlüsselfeld
kann alternativ über uniqueConstraint auf
Tabellenebene deklariert werden
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
String
referencedreferencedColumnName
Name der Spalte auf die referenziert wird
String
unique
nullable
insertable
referenzierte
Spalte
PK der
referenzierten
Tabelle
Aufgabe ► @OneToMany mit JoinColumn
- referencedColumnName definiert Name des referenzierten Feldes
-
testen Sie 1:N Beziehung mit einer JoinColumn
testen Sie ohne cascading und mit FetchType=LAZY
@OneToMany
@JoinColumn(name="p_fk", 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
24.6
@ManyToOne
- gleiche Konstellation
- andere Sichtweise ► Account - Person
Annotation
Parameter
targetEntity
cascade
fetch
optional
@ManyToOne ► M F
Beschreibung
Entitätsklasse
Angabe der Kaskadierungsoperationen
definiert Ladeverhalten des Attributs
erlaubt Null-Werte
gibt an ob die Assoziation belegt sein muss
hat für primitive Java Typen keine Wirkung
Typ
Default
Class
Typ des Attributs
CascadeType[]
FetchType
EAGER
Boolean
true
- Account hat ein person Attribut als Komposition
@Entity public class Account implements Serializable {
@Id @GeneratedValue private Long id;
@ManyToOne(cascade = 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 N-Seite
@Entity public class Person implements Serializable {
@Id @GeneratedValue private Long id;
@OneToMany(mappedBy="person", cascade = CascadeType.ALL)
private List<Account> accounts;
- die Refernezielle Integrität muss manuell gesetzt werden
@Entity 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
24.7
Verbindungstabelle
- kann auf alle Beziehungstypen angewendet werden
- durch die Annotation @JoinTable
- @JoinColumns definiert Tabellen- und Feldnamen
- definiert Kompatibiltät zu bestehendem Schema
- ermöglicht Nachvollziehbarkeit
- durch zusätzliche Spalten in der Jointable ► z.B. Timestamp
Annotation @JoinTable ► M F
Parameter
Beschreibung
Name der Relationstabelle
name
Tabellenschema
schema
Tabellenkatalog
catalog
PK Spalten der führenden Entity
joinColumns
inverseJoinColumn PK Spalten der nichtführenden Entity
uniqueConstraint
Unique-Constraints, die auf der
Relationstabelle definiert werden sollen
Typ
String
String
String
JoinColumn[]
JoinColumn[]
Default
DB Schema
DB Katalog
UniqueConstraint[]
Aufgabe ► Beziehungstabelle
Beziehungstabelle
- testen Sie die Person – Konto Beziehung
-
definieren Sie eine JoinTable ► T_PERSON_KONTO
@Entity public class Account implements Serializable {
@ManyToOne(cascade=CascadeType.ALL ,fetch= FetchType.EAGER)
@JoinTable( name = "T_PERSON_KONTO",
joinColumns = { @JoinColumn( name = "Konto_PK") },
inverseJoinColumns = { @JoinColumn(name = "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
EJB 3.1 / JPA 2.0 >> Java Framework >> Assoziationen
24.8
@ManyToMany
- werden immer durch eine Verbindungstabelle abgebildet
Annotation @ManyToMany ► M F
Parameter
Beschreibung
Entitätsklasse
targetEntity
Angabe der Kaskadierungsoperationen
cascade
definiert Ladeverhalten des Attributs
fetch
definiert Attribut der führenden Entity
mappedBy
Typ
Default
Class
Typ des Attributs
CascadeType[]
FetchType
LAZY
String
- am Beispiel Verwalter – Konto
@Entity public class Trustee implements Serializable {
@Id @GeneratedValue private Long id;
@ManyToMany(mappedBy = "trustees") private List<Account> accounts;
@Entity public class Account implements Serializable {
@Id @GeneratedValue private Long id;
@ManyToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
private List<Trustee> trustees;
Auzfgabe ► Verwalter – Konto
- testen Sie die entsprechende
@ManyToMany 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
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 allen Beziehungen ► @OneToOne, @OneToMany, @ManyToOne und @ManyToMany
@ManyToMany(cascade = CascadeType.ALL)
- A.persist() persistiert auch alle an A hängenden Objekte B
- weitere CascadeTypes überschreiben die CascadeTypes der Java Persistence API
- Annotation @org.hibernate.annotations.Cascade
- definiert CascadeType mit Annotation @org.hibernate.annotations.CascadeType
@org.hibernate.annotations.Cascade(value = {
org.hibernate.annotations.CascadeType.SAVE_UPDATE,
org.hibernate.annotations.CascadeType.REPLICATE })
CascadeTypes ► JPA vs. Hibernate
CascadeTypes
JPA
Hibernate
Beschreibung
Übergang ► managed Entity
commit() oder flush() persistiert Objekt in der Datensource
Übergang ► detached Entity zu managed Entity
MERGE
MERGE
Übergang ► managed Entity zu detached Entity
DETACH
Übergang ► removed Entity
REMOVE REMOVE
commit() oder flush() löscht Objekt in der Datensource
Synchronisiert die Entity Instanz mit der Datensource.
REFRESH REFRESH
Änderungen innerhalb der Entity werden dabei überschrieben
entspricht javax.persistence.REMOVE
DELETE
DELETE
entspricht casade = { PERSIST, MERGE, DETACH, REMOVE, REFRESH }
ALL
save(Object entity) oder update(Object entity) wird durchgereicht
SAVE_UPDATE
Objekt unter Verwendung der existierenden Id in der Datenbank persistiert
REPLICATE
DELETE_ORPHAN Objekte, die nicht mehr referenziert werden, werden gelöscht
LockMode für pessimistisches Locking wird durchgereicht
LOCK
Objekt wird aus der Session gelöscht
EVICT
Beinhaltet … und SAVE_UPDATE, DELETE, EVICT und LOCK.
ALL
PERSIST
PERSIST
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 191 >> total: 255 Seiten
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
- @Inheritance bestimmt Vererbungsstrategie
- @DiscriminatorValue definiert Tabelleneintrag
- @DiscriminatorColumn definiert Typ und Name der Discriminatorspalte
- Typ definiert als Dtype pder String
- Name beschreibt Vererbung, z.B: Sparkonto oder Privatkonto
Annotation @Inheritance ► C
Parameter
Beschreibung
Vererbungsstrategie
strategy
Typ
Default
InheritanceType
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 192 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung
Annotations für die Vererbung
Annotation @DiscriminatorValue ► C
Parameter
Beschreibung
Typ
Wert der Discriminatorspalte
String
value
Default
Annotation @DiscriminatorColumn ► C
Parameter
Beschreibung
Typ
Spaltenname
String
name
name
Default
discriminatorType
columnDefinition
lenght
Spaltentyp
[STRING, CHAR, INTEGER]
Fragment der SQL
Typendefinition
Spaltenbreite
nur für STRING
DTYPE
DiskriminatorTyp
STRING
String
entsprechend
referenzierte Spalte
int
31
- MappedSuperclass definiert ein abstraktes Objekt in einer Vererbungsstrategie
- ohne eigene Tabelle
Annotation @MappedSuperclass ► C
Parameter
Beschreibung
Typ
Default
Aufgabe ► Single_Table
- testen Sie die Vererbungsstategie Single_Table
-
abstrakte Klasse Konto bestimmt Vererbungsstrategie mit InheritanceType
konkrete Klassen definieren Discriminatorvalue
@Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public abstract class Account implements Serializable {
@Entity
@DiscriminatorValue(value = "Sparkonto")
public class Deposit extends Account {
@Entity @DiscriminatorValue(value = "Privat")
public class Personal extends Account {
@Entity @DiscriminatorValue(value = "Euro")
public class Euro extends Account {
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 193 >> total: 255 Seiten
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_CLASSTABLE_PER_CLASS-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 geerbten Klasse
@Entity @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Account implements Serializable {
@Id @GeneratedValue(strategy = GenerationType.TABLE)
private Long id;
@Entity public class Deposit extends Account {
@Entity public class Personal extends Account {
@Entity 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
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 konkrete Entities
@Entity @Inheritance(strategy = InheritanceType.JOINED)
public abstract class Account implements Serializable {
@Id @GeneratedValue private Long id;
@Entity public class Deposit extends Account {
@Entity public class Personal extends Account {
@Entity public class Euro extends Account {
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 195 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Vererbung
Zusammenfassung ► Vererbungsstrategien
Joined
Table_Per_Class
Single_Table
Vererbungsstrategie
Strategie
Begründung
Vorteil
Nachteil
Vorteil
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
Nachteil polymorphe Abfragen nicht optimal unterstützt
Vorteil
Nachteil
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
wenig
wenig Attribute
viele Attribute
preformant
polymorphe Queries
TABLE_PER_CLASS
JOINED
()
nur konkrete Querries
komplexe Hirarchie
Querries
nur auf eine Tabelle
Union Select
Inner / Outer Joins
- 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 ...
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 196 >> total: 255 Seiten
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
Die Verwendung von Collections in persistenten
Klassen erlaubt nur die unterstützten Interfaces.
Interfaces.
folgender Code wirft eine LaufzeitLaufzeit-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
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
- @ElemetCollection erlaubt eine Collection von Basistypen ► z.B. String
Annotation @ElementCollection ► M F
Parameter
Beschreibung
Typ
Ladestrategie der Collection
FetchType
fetch
referenzierte Klasse
java.lang.Class
targetClass
Default
LAZY
Klasse
@Entity public class Euro extends Account implements Serializable{
@ElementCollection private Set<String> coupons = new HashSet<String>();
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 198 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen
Methoden des Query Interface
QueryInterface ► Ausschnitt
Methode
Beschreibung
List getResultList(
getResultList( )
Object getSingleResult(
getSingleResult( )
int executeUpdate(
executeUpdate( )
Query setMaxResults()
setMaxResults()
Query setFirstResults()
Query setHint()
Query setParameter()
Query setFlushMode()
27.2
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
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
- InhaberKonto
@Entity(name = "Person")
@SqlResultSetMapping(name = "PersonWithMultipleAccounts", entities = {
@EntityResult(entityClass = entity.Person.class,
fields = { @FieldResult(name = "name", column = "name") }) })
public class Person implements Serializable {
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 200 >> total: 255 Seiten
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
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 Native SQL
@Entity
@NamedQueries({
@NamedQuery(name = "Person.findAll", query = "from Person p"),
@NamedQuery(name = "Person.findByName", query = "from Person p where p.name:=name")
})
public class Person implements Serializable { .. }
Abfragen
Abfragen mit NamedQueries
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
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
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
+, -, *, /
=, >=, <=, <>, !=, like
()
is null, is not null
in, not in, between, is empty, is not empty,
member of, not member of
case ... when ... then ... else ... end,
case when ... then ... else ... end
||,
||, concat(..., ...)
current_date(), current_time(), current_timestamp(),
second(), minute(), hour(), day()
day(), month(), year()
substring(), trim(), lower(), upper(), length(), locate()
abs(), sqrt(), bit_length(), mod()
str()
cast(), extract()
size(), minelement(), maxelement(), minindex(), maxindex()
sign(), rtrim(), sin()
logische Operatoren zur Verknüpfung von Ausdrücken
mathematische Operatoren
Vergleichsoperatoren
Klammern zur Gruppierung von Ausdrücken
Vergleiche auf Null
Ausdrücke zum Umgang mit Mengen und Bereichen (Collections
etc.)
Bedingungen mit Alternativen
String Verknüpfungen
Verwendung von Zeit und Datum
Verwendung von Strings
sonstige mathematische Operatoren
Umwandlung in einen String
Casts zur Umwandlung in HQL-Datentypen
sonstige Ausdrücke zum Umgang mit Collections
sonstige SQL-Funktionen
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 204 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen
27.10
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%'
27.11
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen
27.12
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen
27.13
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
27.14
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Datenbankabfragen
27.15
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
27.16
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
where not (k.nr, k.name) in
( select pk.saldo
from Personal pk )
// mit Wertemenge > 1
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 209 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Datentypen
28
Datentypen
Datentypen
- Datenbankzugriffe resultieren in Performance-Problemen
- geeignete Fetching-Strategie wählen
- geeigneter Typ wählen
- Fetching-Strategy bei Attributen
@Basic(fetch = FetchType.LAZY)
private Object grosseDatenMenge;
- Fetching-Strategy bei Beziehungen
@OneToOne(cascade = 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
unterstützt Lazy Loading
Loading
- Entity muss vom EntityManager verwaltet werden
- Zugriff auf nicht geladenes Attribut einer detached Entity wirft Exception
Ladestrategien für Attribute
Annotation @Basic ► M F
Parameter
Beschreibung
definiert Ladeverhalten des Attribut
fetch
erlaubt Null-Werte, hat für primitive Java Typen keine Wirkung
optional
Typ
Default
FetchType EAGER
Boolean
true
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 210 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Datentypen
Zusammenfassung ► FetchingFetching-Strategien
Fetching
Annotation
@Basic(fetch = FetchType.EAGER / LAZY)
@OneToOne(fetch = FetchType.EAGER / LAZY)
@ManyToOne(fetch = FetchType.EAGER / LAZY)
@OneToMany(fetch = FetchType.EAGER / LAZY)
@ManyToMany(fetch = FetchType.EAGER / LAZY)
Defaultwert
FetchType.EAGER
FetchType.EAGER
FetchType.EAGER
FetchType.LAZY
FetchType.LAZY
JPQL Fetch
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
- @Lob deklariert Attribut als Large OBject
- Datenbank ist verantwortlich für die Abbildung ► MySQL z.B. als BLOB BinaryLargeObject
Annotation @Lob ► M F
Parameter
Beschreibung
Typ
Default
- @Lob wird oft im Zusammenhang mit @Basic verwendet
- um LazyLoading für Large Objects zu definieren.
@Lob @Basic(fetch = FetchType.LAZY)
private Object grosseDatenMenge;
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 211 >> total: 255 Seiten
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
- @Temporal definiert Datenbankrepräsentation
- DATE entspricht java.sql.Date
- TIME entspricht java.sql.Time
- TIMESTAMP entspricht java.sql.Timestamp
Annotation @Temporal ► M F
Parameter
Beschreibung
TemporalType
definiert Speichertyp
Typ
Default
DATE
TIME
TIMESTAMP
TIMESTAMP
@Temporal(TemporalType.DATE)
private java.sql.Date startDatum;
28.4
Aufzählungen
- Java SE 5.0 kennt Aufzählungstyp ENUM
- @Enumerated deklariert Aufzählungstyp und definiert Art der Persistierung
- ORDINAL : Wert wird als Zahl beginnend mit 0 gespeichert
- STRING : Wert wird als String gespeichert
Annotation @Enumerated ► M F
Parameter
Beschreibung
value
definiert Art der Persistierung
ORDINAL oder STRING
Typ
Default
EnumType
Beispiel ► Kontotyp als Aufzählungstyp
public enum KontoTyp { PRIVATKONTO, SPARKONTO, ANLEGEKONTO }
@Enumerated(EnumType.ORDINAL)
private KontoTyp kontoTyp;
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 212 >> total: 255 Seiten
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 Versionsattributen @Version
- 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
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
-
manueller Ansatz nur bei kleinen, trivialen Persistenzlösungen praktikabel
- manuelle Überprüfung eines komplexen Objektgraphen nicht einfach
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
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
- mit @Version annotiertes Attribut darf durch Applikation nicht verändert werden
- Attribut wird bei jeder Veränderung hochgezählt
Annotation @Version ► M F
Parameter
Beschreibung
Typ
Default
Beispiel
@Version
@Column(name="Versionfeld")
private int version;
das Version Pattern ist durch die JPA Spezifikation implementiert
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 214 >> total: 255 Seiten
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
LockingLocking-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 LockLock-Modus
LockMode
Parameter
NONE
READ
UPGRADE
UPGRADE_NOWAIT
WRITE
Beschreibung
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.
LockLock-Modi erlauben pessimistisches Locking auf feingranularer
feingranularer Ebene
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 215 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Transaktionen der Persistence Unit
P
Idioms
Lerninhalte
Lerninhalte
Design Pattern
Idioms
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 216 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns
30
Design Patterns
wiki Entwurfsmuster (engl.
(engl. design patterns)
patterns) sind bewährte LösungsLösungs-Schablonen für wiederkehrende
Entwurfsprobleme in Softwarearchitektur und Softwareentwicklung.
Softwareentwicklung. Sie stellen damit eine
wiederverwendbare Vorlage
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 MenschMensch-ComputerComputer-Interaktion gefunden. Aber auch außerhalb der
Informatik finden Entwurfsmuster immer mehr Eingang.
30.1
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
- 1977
- Alexander schreibt ein Buch über die Verwendung von Mustern in der Architektur
- 1987
- Cunningham und Beck entwerfen fünf Patterns für die Programmierung von User-Interfaces
- Durchbruch der Software Patterns
- 1994
- Autoren Gamma, Helm, Vlissides und Johnson schreiben das Buch "Design Patterns"
- ISBN 3-8273-2199-9, ISBN-10:3-8273-2199-9, EAN:9783827330437
- Addison Wesley Verlag, Juli 2004
- 6. Auflage / 504 Seiten
das Buch "Design
"Design Patterns"
Patterns" entwi
entwickelte sich zu einem der
einflussreichsten Computerb
Computerbücher überhaupt und ist auch unter dem
Begriff GoF (Gang
(Gang of Four)
Four) bekannt
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 217 >> total: 255 Seiten
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
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 218 >> total: 255 Seiten
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
Technologie 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
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 PresentationPresentation-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
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 ContainerContainer-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
EJB 3.1 / JPA 2.0 >> Java Framework >> Design Patterns
30.7
JEE Entwurfsmuster
JEE Idioms
Entwurfsmuster
Service Locator
Business Delegate
Session Facade
Value Object
Message Façade
Service Activator
EJB Command
Business Interface
DTO Factory
Data Transfer Hash Map
Value List Handler
Handler
Data Transfer Row Set
Data Access Object
Version Number
Number
Muster zur Generierung von
Primärschlüsselwerten
Beschreibung
Bedeutung für EJB
kapselt teure Technologien
kapselt Businesslogik, vereinfacht Zugriff
kapselt die Container Komponenten
kapselt Business Data
relevant
obsolet, da keine RemoteExeptions
durch die Spezifikation erzwungen
obsolet, Custom DTO relevant
nutzt asynchrone Kommunikation
relevant
Möglichkeit zur Gestaltung der Session Bean,
durch Entkopplung des Clients
stellt Konsistenz zwischen Beanklasse und
Businessinterface sicher
Erzeugung eines DTO durch Factory
generische Variante zum DTO
serverseitiges Speichern von
Ergebnismengen
disconnected RowSet für
Serveranwendung ohne Entity Beans
kapselt den Datenbank Zugriff
Attribut kontrolliert Lost-Update-Problematik
Generierung von Business Keys
relevant
obsolet
für Custom DTO relevant
relevant
relevant
relevant
relevant, mit JPA jedoch leistungsfähiger
in Spezifikation integriert
in Spezifikation integriert
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 222 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Programmiereinschränkungen
31
Programmiereinschränkungen
Programmiereinschränkungen
die folgenden sieben Regeln sollten beachtet werden
Threads
1
2
kein Thread Management oder Synchronisation in EJBs
EJBs ► Container kontrolliert Lifecycle
- ist Aufgabe des Applikationsservers
- Bean = einzelner Thread, keine Kongruenz (Gleichheit)
- Kontainer kontrolliert Nebenläufigkeit (Concurrency)
statische Variablen
keine schreibenden Zugriffe auf Klassenvariablen durchführen ► Speicherort bei Cluster unklar
- verschiedene Prozesse bei ClusterCluster-Deployment
- statische Attribute mit "final"
final" deklarieren
3
AWT (Abstract Windwing Toolkit)
4
Dateizugriff
5
6
7
kein stdin / stdout
stdout verwenden ► AusgabeAusgabe- / Eingabestream sind nicht definiert
- Portabilitäts
Portabilitätsproblematik
tätsproblematik
kein direkter Zugriff auf Dateien ► nicht definierter Speicherort bei ClusterCluster-Deployment
- keine Verwendung von java.iojava.io-Package / keine native Libraries
SocketSocket-Listener
keine Beans an Sockets binden ► Lifecycle
Lifecycle nicht kontrollierbar
- Container steuert Bean Life Cycle, daher Bean nicht als Socket Server einsetzen
- Bean Instanzen dürfen Socket Clients sein
this
keine this – Referenz als Parameter oder Ereignis eines Methodenaufrufes ► Remotezugriff
- SessionContext.getBusinessObject(Class
SessionContext.getBusinessObject(Class businessInterface) benützen
Systemproperty
EJBs dürfen Laufzeitumgebung nicht beeinflussen ► durch den Container kontrolliert
- keine ClassClass-Loader erzeugen, abfragen oder JVM anhalten oder Security Manager installieren
installieren
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 224 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren
32
Deployment Descriptoren
- Beschreiben und Bereitstellen der serverseitigen Komponenten
- Annotationen
- Deployment Descriptoren (überschreiben Annotationen)
ejbejb-jar.xml DeploymentDeployment-Descriptor
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 jarjar-Datei (EJB 2.0)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD
EnterpriseJavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
Verpackt in eine jarjar-Datei (EJB 2.1)
<ejb-jar xmlns="http://java.sun.com/xml/ns/JEE"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/JEE
http://java.sun.com/xml/ns/JEE/ejb-jar_2_1.xsd"
version="2.1">
Verpackt in eine jarjar-Datei (EJB 3.0)
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
version="3.0">
Versionen unterscheiden zwischen DTDs und XMLXML-Schema.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 226 >> total: 255 Seiten
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
32.1.1
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren
ejb-jar.xml Elementbeschreibung
Element
Beschreibung
Textbeschreibung der ejb-jar-Datei
description?
Name, der von Tools benutzt wird
displaydisplay-name?
Pfad, innerhalb der jar-Datei, für jpeg-Bilder (16x16)
smallsmall-icon?
Pfad, innerhalb der jar-Datei, für jpeg-Bilder (32x32)
largelarge-icon?
nähere Beschreibung/ Definition der Beans
enterprisebean
definiert CMP Beziehungen
relationships?
assemblyssemblydefiniert Transaktionen und Security
descriptor?
definiert JAR-Datei, die Stubs und Interfaces für Remote-Clients enhält
ejbejb-clientclient-jar?
ejb-jar.xml Session Bean Elementbeschreibung
Element
Beschreibung
ejbejb-name
ejbejb-class
remote?
local?
sessionsession-type
transaction
transactionion-type
description?
displaydisplay-name?
smallsmall-icon?
largelarge-icon?
envenv-entry*
ejbejb-ref*
ejbejb-locallocal-ref
securitysecurity-rolerole-ref*
securitysecurity-identity*
resourceresource-ref*
resourceresource-envenv-ref*
Spitzname des Beans, dient als Referenz
Session-Bean Klasse + Package-Name
Remote-Interface
Local-Interface
Stateful | Stateless
Container | Bean
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)
Definition von Umgebungsvariablen
Definition von Referenzen zu anderen Beans
Definition von Referenzen zu lokalen Beans
definiert Sicherheitsrollen
definiert wie Sicherheitskontexte ermittelt werden können
definiert Referenzen zu Ressourcen (z.B. JDBC)
bindet Ressourcen-Factories zu JNDI Namen
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 228 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren
assemblyassembly-descriptor
- ermöglicht die Festlegung von
-
Zugriffsberechtigungen
Transaktionen
generellem Zusammenspiel von Beans und einer Applikation
ejb-jar.xml Assembly-Descriptor Elementbeschreibung
Element
Beschreibung
definiert Security-Rollen
securitysecurity-role*
methodmethod-permission*
container
containerner-transaction*
excludeexclude-list?
32.2
spezifiziert die einzelnen
Methoden,
und deren Zugriffsrechte
Definition der Transaktionen,
der einzelnen Methoden
Liste von Methoden,
die von niemandem
aufgerufen werden dürfen
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Deployment Descriptoren
<?xml version="1.0" encoding="UTF-8"?>
<application
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:application=
"http://java.sun.com/xml/ns/javaee/application_5.xsd"
xsi:schemaLocation=
"http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/application_5.xsd"
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
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
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma
33
Programmierparadigma
Lat: <Paradigma
Paradigma>
Paradigma = begreiflich machen, (para = neben) und (digma = zeigen)
wiki Ein Programmierparadigma ist das einer Programmiersprache oder Programmiertechnik zugrunde
liegende Prinzip.
Prinzip.
(einige) bekannte (Programmier)-Paradigmen
Struktur
- Strukturiert (WIE)
- Imperativ (lineare Folge von Befehlen)
- Prozedural (in Teilaufgaben zerlegt)
Deklaration
- Modular (Module als logische Einheiten, Funktion und Daten)
- Deklarativ (WAS)
- Funktional (ergebnisorientiert)
- Logisch (logikbasiert)
Orientation
- Orientiert (WOZU)
- Objekt (Kommunikation, polymorph – mehrere Formen)
- Komponenten (abstrakt)
- Aspekt (orthogonal freie Kombinierbarkeit unabhängiger Konzepte)
- Agil (DRY Don't Repeat Yourself)
Agilität
33.1
Agiles Programmieren
Lat: <agilis
agilis>
agilis = flink, beweglich (Agile Softwareentwicklung reduziert Aufwand und Regeln)
Skript- vs. Programmiersprachen
Skriptsprache
Ziel
Einsatz
Ausführung
Typisierung
Typisierung
Vorteile
Kombination bestehender
Bausteine (Shell-Skript),
Bibliotheken (Perl, Python)
spezifisch:
GUI (JavaScript),
Reporting (Perl)
interpretiert oder Bytecode
schwach, flexibel, dynamisch
schnelle Entwicklung (Python),
Prototypen (Shell-Skript),
kleine Systeme (Perl)
Programmiersprache
Programmiersprache
Neuentwicklungen (C, C++)
allgemein
kompilierter Maschinencode
streng, flexibel
effiziente Anbindung, Ausnutzung von
Ressourcen (C++, Java)
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 234 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma
Historie der Skriptsprachen
JCL 1963
(Job Control Language)
AWK 1977
1977
(Aho Weinberger Kernighan)
Sh 1978
1978
(Bourne Shell)
Perl 1987
(Practical Extraction and Report Language)
Tcl 1988
1988
Python 1990
1990
(Tool Command Language)
(Monthy Python)
PHP 1995
1995
Ruby 1995
1995
JavaScript 1995
1995
(Personal Home Page)
(Eng: Rubin)
(ECMA 262)
Groovy 2003
(JSR 241)
33.2
Groovy
wiki dynamisch typisierte ProgrammierProgrammier- und Skriptsprache für die Java VM
verbindet JavaJava-Syntax mit den Konzepten von Ruby.
Ruby.
Groovy
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.
Paradigmen
objektorientiert,
Skriptsprache,
teilweise deklarativ
Erscheinungsjahr
2003
Entwickler
The Codehaus
Aktuelle Version
1.7 (2010)
Typisierung
stark, statisch, dynamisch
Betriebssystem
plattformunabhängig
Lizenz
Open Source,
Apache Software License 2.0
Groovy. Codehaus
http://groovy.codehaus.org/
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 235 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Programmierparadigma
33.3
DSL Domain Specific Language
wiki Eine domänenspezifische Sprache (engl. domaindomain-specific
specific language,
language, DSL) ist eine formale Sprache,
Sprache,
die speziell für ein bestimmtes Problemfeld (die Domäne)
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
Probleme der Domäne darstellen können und nichts darstellen können, was
auss
ausserhalb
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
DSL
33.4
Domain
DSL
http
Deamon
SQL
DBMS
Domain
NoSQL (Not only SQL)
wiki NoSQL is a movement promoting a loosely defined class of nonnon-relational data stores
stores that break
with a long history of relational databases. These data stores may not require fixed table schemas,
schemas,
usually avoid join operations and typically scale horizontally.
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
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
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
ERSTER TEIL
Form
Projekt als Einzelarbeit
Hilfsmittel
-
THEORIE
ZWEITER TEIL
DRITTER TEIL
Schriftliche Prüfung
PC mit Internetzugang / JBoss / Eclipse Entwicklungsumgebung
-
schriftliche Unterlagen
Dauer
16 Lektionen / 600 Minuten
2 Lektion / 100 Minuten
Punkte
60
60
Wertung
50 %
50 %
Vorgaben
-
Abgaben
34.1
-
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
Email (generiert)
-
keine
-
schriftliche Modulprüfung
ev. erstellte Zusatzblätter
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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 238 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
ERSTER TEIL
ZWEITER TEIL
DRITTER TEIL
Seite
2
10
8 1/3 %
3_1
11
P2
UML Deployment-Diagramm
2
10
8 1/3 %
3_2
12
P3
UML Klassen-Diagramm
2
10
8 1/3 %
3_3
13
P4
UML Sequenz-Diagramm
2
10
8 1/3 %
3_4
14
P5
TDD JUnit-Testklasse
2
10
8 1/3 %
3_5
15
P6
Implementation
6
3_6
16
T1
OOA
10
8 1/3 %
4
17
T2
OOD
10
8 1/3 %
4
17
T3
Container-Komponenten
10
8 1/3 %
4
17
T4
O/R Mapping
10
8 1/3 %
4
17
T5
Transaktionen
10
8 1/3 %
4
17
T6
Testkriterien
10
8 1/3 %
4
17
60
50 %
Punkte
Punkte
8 1/3 %
2
Total
34.1.1
10
18
50
37.5 %
Wertung
UML Use-Case-Diagramm
Thema
Wertung
P1
Aufträge
Aufgaben
Kapitel
schriftliche Prüf.
Wertung
Projekt als Einzelarbeit
Punkte
THEORIE
Zeit in
Lektionen
PRAXIS
10
12.5 %
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
+ 1
120
=
Notenscala
6
5
4
Note
3
2
1
0
1
3
5
7
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
39
41
43
45
47
49
51
53
55
57
59
61
63
65
67
69
71
73
75
77
79
81
83
85
87
89
91
93
95
97
99 101 103 105 107 109 111 113 115 117 119
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 239 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.1.2
Bezug der Aufträge zu den Handlungszielen
Die Projektarbeit (Praxis-Teil) deckt die Handlungsziele wie folgt ab:
Handlungsziele
HZ Beschreibung
P1 P2 P3 P4 P5 P6
1
Benutzeranforderungen objektorientiert analysieren und Anforderungen an die
Datenhaltung mit Struktur und Inhalt der relationalen Datenbank abgleichen und
dokumentieren.
2
Last-, Durchsatz-, Verfügbarkeits- und Sicherheitsanforderungen aufgrund der
Leistungsspezifikationen bestimmen.
3
Transaktionen Multi-User fähig entwerfen. User Interfaces und
Datenbankanpassungen spezifizieren.
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.
34.1.3
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
ContainerContainerKomponenten
O/R
Mapping
Transaktionen Testenkriterien
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 240 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.1.4
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.
PRAXIS
THEORIE
Lektionen
10 Lektionen
6 Lektionen
2
Minuten
500 Minuten
300 Minuten
100
Lektionen
Minuten
Erster Teil
Analyse
lyse : P1, P2, P3, P4, P5
Ana
- Use-Case-Diagramm
- Deployment-Diagramm
- Klassen-Diagramm
- Sequenz-Diagramm
- JUnit-Testklasse
Zweiter Teil
Implementation : P6
- Implementation
Dritter Teil
Prüfung
Prüfu
ng : T1 –T6
- schriftliche Prüfung
Abgabe
PDF Datei
-
Use-Case-Diagramm
Deployment-Diagramm
Klassen-Diagramm
Sequenz-Diagramm
JUnit-Testklasse
Projekt
-
Source
-
Email
Prüfung
► als Eclipse Projekt
► generiert
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 241 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.1.5
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 Email 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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 242 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.2
Praxis-Teil
34.2.1
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-EEServers (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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 243 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.2.2
Entwicklungsmethoden
TDD ► Aspekt von Extreme Programming (XP
(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.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 244 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.2.3
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
- Email 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 Email
- die Teilnehmer haben keinen Zugriff auf die generierten Email
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 245 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.2.4
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
SicherheitsSicherheits-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
TransaktionalerTransaktionaler-Kontext
- die Session Fassade der Domänenobjekte muss sich in einen Transaction Context
befinden
- durch einen JUnit Testcase muss ein Rollback simuliert werden
Email durch Interceptor
- der WorkflowInterceptor generiert bei einem Client Request (@Test ► JUnit Testcase)
ein Email 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
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.3
Aufträge
34.3.1
P1 ► UML Use-Case-Diagramm
Auftrag
Erstellen Sie ein UML Use-Case-Diagramm der Aufgabestellung.
Hinweis ► Denken Sie an den Anwendungsfall,
Anwendungsfall, mit
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
1
2
3
4
5
Total
Punkte
Auftrag
Bewertung in Punkten
- achten Sie dabei auf die folgenden Bewertungskriterien
Bewertung
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.)
2
2
2
2
2
10
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 247 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.3.2
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
1
2
3
4
5
Total
Punkte
Auftrag
Bewertung in Punkten
- achten Sie dabei auf die folgenden Bewertungskriterien
Bewertung
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.)
2
2
2
2
2
10
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 248 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.3.3
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
1
2
3
4
5
Total
Punkte
Auftrag
Bewertung in Punkten
- achten Sie dabei auf die folgenden Bewertungskriterien
Bewertung
Bewertung
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.)
2
2
2
2
2
10
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 249 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.3.4
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
1
2
3
4
5
Total
Punkte
Auftrag
Bewertung in Punkten
- achten Sie dabei auf die folgenden Bewertungskriterien
Bewertung
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 yAchse, ObjectLyfeCycle duch X beendet, Interaktion zwischen Objekten als Linie, etc.)
2
2
2
2
2
10
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 250 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.3.5
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
1
2
3
4
5
Total
Punkte
Auftrag
Bewertung in Punkten
- achten Sie dabei auf die folgenden Bewertungskriterien
Bewertung
die Testklasse beschreibt den Testcase (z.B. @Test) 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 (z.B. @Before)
die Testklasse räumt die notwendigen Ressourcen (z.B. Datensätze aus DB löschen, etc.)
wieder auf (z.B. @After)
der Testcase (z.B. @Test) 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
2
2
2
2
2
10
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 251 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.3.6
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 Email 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
Auftrag
Bewertung
Punkte
Bewertung in Punkten
- achten Sie dabei auf die folgenden Bewertungskriterien
1
Email ist auf ekslox.edu.zli eingegangen
2
2
Inhalt der Email: der Teilnehmer arbeit mit seinem Userprofil (nicht als Administrator)
2
3
Inhalt der Email: der Prinzipal definiert sich aus Name_Vorname des Teilnehmers
2
4
Inhalt der Email: die Interaktion entspricht der UML Definition (Methodennamen, Signature, etc.)
2
5
Inhalt der Email: die Interaktion simuliert einen Rollback (durch realistische Parameter)
2
Total
10
Hinweis ►D
Die Email wird durch den WorkflowInterceptor automatisch
generiert und an ekslox.edu.zli versendet wenn die Interaktion mit der
Session Fassade (Domänenobjekte) in einem SecuritySecurity-Kontext
stattfindet; der Prinzipal durch die Rolle "zli" autorisiert ist und
und der
transaktionale Kontext durch einen Rollback beendet wird.
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 252 >> total: 255 Seiten
EJB 3.1 / JPA 2.0 >> Java Framework >> Kompetenznachweis
34.4
Theorie-Teil
34.4.1
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
Inhalt
Punkte
diese sind wie folgt gegliedert:
Teilaufgabe
-
1
einfacher Multiple-Choice
1
2
schwieriger Multiple-Choice
2
3
4
Total
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
3
4
10
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 253 >> total: 255 Seiten
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
EJB 3.1 / JPA 2.0 >> Java Framework >> Anhang
35
Anhang
- Bücher
- Online Referenzen
Bücher
ISBN
987987-3-8986489864-431431-0
978978-3-8680286802-014014-4
3-82738273-21842184-0
0-1313-142246142246-4
3-82738273-21242124-7
3-82738273-18621862-9
0-76457645-76827682-8
9-780321780321-118899
1-932394932394-8888-5
0-1313-140264140264-1
Titel
EJB 3 professionell
JPA mit Hibernate
J2EE, Einstieg für Anspruchsvolle
Core J2EE Patterns, Best Practices and Design Strategies
J2EE Patterns, Entwurfsmuster für die J2EE
Entwurfsmuster, Elemente wiederverwendbarer objektorientierter Software
Mastering Enterprise JavaBeans
Enterprise Java Security
Java Persistence with Hibernate
J2EE Security
Online Referenzen
URL
http://www.java.com
http://www.java.com
http://www.jboss.org
http://www.hibernate.org
http://www.ejbkomplett.net
http://geekandpoke.typepad.com/
Inhalt
Java
JBoss
Hibernate
EJB
geek & poke
© 2010 / 2011 >> Version 4.1 >> Stephan Metzler >> Seite 255 >> total: 255 Seiten