11.2 Exkurs: Java Annotations 12 EJB 3 - ... · Keine automatische Persistenz in EJB3.0 Entity-Beans ... Spring, Hibernate, Ruby on ... Franz J. Hauck, Verteilte Systeme, Univ. Ulm,

© 2002-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2007s-AvID-E-EJB.fm, 2007-06-20 09.18] http://www-vs.informatik.uni-ulm.de/teach/ss07/avid/

11.2 Exkurs: Java Annotations

■ Sprachelemente mit Metadaten verknüpfbar

◆ typisiert, vom Compiler prüfbar, gute IDE-Unterstützung

■ Deklaration als spezielle „@…“ Schnittstelle

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.METHOD,ElementType.TYPE})

public @interface MyCMS {String [] authors() default {""};

}

@MyCMS({"Me","She"}) class Test { ... }

■ Anwendung auf verschiedene Ziele bzw. „Targets“

◆ Typen, Methoden, Parameter, …

■ Sichtbarkeit je nach „Retention“

◆ nur im Quellcode, im Class-File, auch zur Laufzeit per Reflection E.101© 2002-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2007s-AvID-E-EJB.fm, 2007-06-20 09.18] http://www-vs.informatik.uni-ulm.de/teach/ss07/avid/

12 EJB 3.0

■ Neue Version des EJB-Standards (2006)

◆ basiert extensiv auf Java-Annotationen

• alternativ auch Angaben im Deployment-Descriptor

◆ kompatible zu EJB 2.1

• alter Anwendungscode läuft auch in einem EJB 3.0 Application Server

■ Bean-Arten

◆ Session-Beans

• ähnlich EJB 2.1

◆ Entity-Beans

• Konzept völlig verändert

◆ Message-Driven-Beans

• nur geringe Änderungen gegenüber EJB 2.1

E.102


12.1 Session-Beans

■ Zustandslose Session Bean

◆ Annotierung der Bean-Klasse als @Stateless

◆ keine Basisklasse erforderlich

◆ Beispiel:

@Stateless public class SayHelloBean implements SayHelloRemote {public String sayHello() {

return "Hello";}

}

✱ Vorteil

◆ vernünftige Voreinstellungen benötigen weniger/keine Konfiguration

• z.B. falls nur ein Interface implementiert ist es das Remote-Bean-Interface

◆ alle relevanten Informationen im Code

• keine weiteren Angaben im Deployment-Descriptor notwendig

E.103© 2002-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2007s-AvID-E-EJB.fm, 2007-06-20 09.18] http://www-vs.informatik.uni-ulm.de/teach/ss07/avid/

12.1 Session-Beans (2)

■ Interfaces zur Bean

◆ Annotation der Interfaces als lokal oder entfernt

• Beispiele:

@Remote interface SayHelloRemote implements java.rmi.Remote {public String sayHello() throws RemoteException;

}

@Local interface SayHelloLocal {public String sayHello();

}

◆ Bean muss Interfaces gar nicht implementieren

• Methodensignaturen müssen übereinstimmen

• entsprechende Annotation erforderlich, z.B.

@Stateless @Local(SayHelloLocal.class) public class ...

E.104



■ Injektion von Umgebungsvariablen und Kontextinformationen

◆ im Gegensatz zu EJB 2.1 keine Methode setSessionContext notwendig

◆ Annotation von Variablen oder Methoden zur Injektion von Zuweisungen beim Deployment

◆ Beispiele

public class SayHelloBean implements ... {@Resource private String formatString;

@Resource void setSessionContext( SessionContext ctx ) {...

}}

• direkte Zuweisung einer Umgebungsvariable– definiert im Deployment-Deskriptor

• Aufruf einer Setter-Methode

◆ Implementierung im Container (vermutlich) durch Codemanipulationauf Class-File-Ebene E.105



■ Lebenszyklusunterstützung

◆ keine obligatorischen Methodenimplementierungen

◆ annotierte Methoden für

• @PostConstruct – Operationen nach dem Erzeugen

• @PreDestroy – Operationen vor dem Zerstören

◆ alternativ: Deklaration der Methoden im Deployment-Descriptor

■ Lebenszyklus

◆ im Wesentlichen identisch zu zustandsloser Session-Bean aus EJB 2.1

■ Erzeugung

◆ Lookup im Namensdienst reicht für Erzeugung aus

• kein Home-Interface nötig

E.106



■ Zustandsbehaftete Session-Bean

◆ Annotierung:

@Stateful public class SayHelloWithCounterBean ... {...

}

◆ Erzeugung durch Lookup im Namensdienst

◆ Initialisierung durch individuelle Zusatzmethoden

◆ Lebenszyklusunterstützung (zusätzlich):

• @PrePassivate – Operationen vor dem Passivieren

• @PostActivate – Operationen nach dem Aktivieren

◆ Erzeugung durch Lookup im Namensdienst


12.2 Entity-Beans

■ Komplette Überarbeitung des Persistenzkonzepts

◆ eigener Substandard: Java Persistence API

■ Entity-Beans sind POJOs

◆ “Plain Old Java Objects”

◆ in der Regel serialisierbar

◆ benötigen Standard-Konstruktor

◆ keine weiteren Verpflichtungen

◆ @Entity-Annotierung der Klasse oder Angaben im Deployment-Descriptor

■ Persistente Attribute

◆ Variablen der Entity-Bean(nicht transient deklariert bzw. @Transient annotiert)

◆ alternativ oder zusätzclih Getter- und Setter-Methoden

◆ Auszeichnung des eindeutigen Primärschlüssels durch @Id-Annotation

E.108


12.2 Entity-Beans (2)

■ Zusätzliche Annotierungen zur Datenbankanbindung

◆ Tabellen- und Spaltenbezeichnungen

◆ Beziehungen zwischen Tabellen

◆ Multiplizitäten bei Beziehungen (1-zu-1, 1-zu-viele, viele-zu-viele)

▲ Keine automatische Persistenz in EJB3.0 Entity-Beans

■ Persistenzkontexte

◆ benannte Menge von Entity-Beans, um die sich ein Entity-Manager kümmert

◆ Injektion des Entity-Managers in z.B. Session-Bean

@Stateless public class SayHelloBean implements ... {@PersitstenceContext(unitName="JavaEE")private EntityManager enMgr;...

}



■ Lebenszyklus einer Entity-Bean (gesehen aus der Sicht der Beaninstanz)

nicht existent

unmanaged

Erzeugung Garbage Collection

1. Class.newInstance

managed

Ende desSynchronisieren

1. enMgr.merge

Business-Logik

Zerstörung

1. enMgr.remove

Anmeldung

1. enMgr.persist Persistenzkontexts

Business-Logik

E.110



■ Lebenszyklus

◆ persist()-Aufruf im Entity-Manager

• erzeugt Datensatz in der Datenbank anhand der Entity-Bean (falls noch nicht vorhanden)

• wird ansonsten ignoriert

• verfolgt Referenzen auf andere Entities

◆ remove()-Aufruf im Entity-Manager

• löscht Datensatz, falls managed und vorhanden in der Datenbank

• wird ansonsten ignoriert

◆ merge()-Aufruf im Entity-Manager

• synchronisiert Bean-Inhalt in die Datenbank

• erzeugt evtl. eine neue managed Bean und gibt Referenz zurück

◆ Transaktionskonzept führt evtl. zu Fehlermeldungen beim Aktualisieren

✱ Vollständige und einfache Integration des Konzepts der Data-Value-Objects



■ Einfacher Deployment-Descriptor

◆ enthält lediglich Angaben zur Abbildung eines Persistenzkontexts auf die konkrete Datenbank

• z.B. Datenbank-Connector-Konfiguration

■ Ersatz für Findermethoden

◆ Annotierung oder Deklaration im Deployment-Descriptor von benannten Abfrageoperationen

• definiert in EJB QL

◆ Beispiel:

@Entity @NamedQuery( name=”Account.findByOwner”,

query=”SELECT a FROM ACCOUNT a WHEN owner = :name” )public class Account implements Serializable {

...}

E.112


12.4 Transaktionsunterstützung

■ Annotation der Transaktionsattribute an der Bean-Klasse

◆ Beispiel

@Stateful @TransactionAttribute(TransactionAttributeType.REQUIRE_NEW)public class SayHelloWithCounterBean implements ... {

...}


13 Finale Bewertung

■ Nicht-funktionale Eigenschaften unterstützt

◆ Authorisierung, Transaktionsmanagement, Persistenz, Logging, Assembly, …

◆ in der Regel Querschnittsaspekte, sog. „Crosscutting Concerns“

◆ Vermeidung von enger Kopplung eigener Logik mit Bibliotheksfunktionen

• negative Effekte: Code–Tangling und Scattering/Crosscutting

13.1 EJB 2.1

■ Zentrale, implizite Unterstützung im Container

◆ deklarative Konfiguration, ggf. mit vorbereitetem Code (abstract …)

✱ Teilweise Umsetzung der „Separation of Concerns“ (SoC)

◆ nur eine Illusion?

E.114


13.1 EJB 2.1 (2)

▲ Hohe Anforderungen an Bean-Code

◆ Signaturen, Interfaces, System-Aufrufe, …

◆ enge Kopplung der eigenen Logik an EJB-Prinzipien

▲ Keine echte „Separation of Concerns“

◆ Entwicklung nie ganz losgelöst von einem Querschnittsaspekt realisierbar

◆ konzentrierte Entwicklung eines einzelnen Aspekts schwierig

▲ „Inversion of Control“ (IoC) unvollständig

◆ lose Kopplung mit externer Konfiguration

◆ „Dependency Lookup“ an JNDI-Service im eigenen Code

▲ Enge Kopplung an EJB-Container

◆ Portabilitätsprobleme zwischen EJB-Versionen

◆ kein eigenständiger Test ohne Container/Datenbank/Aspekt möglich

◆ aufwändige Entwicklungszyklen und langwieriges Deployment


13.2 EJB 3.0

■ Leichtgewichtiger Ansatz

◆ reguläres Java-Objekt ohne Bindung an spezielles Framework

◆ Testumgebung ohne Container/Datenbank/Querschnittsaspekte möglich

◆ schnellere Entwicklungszyklen

◆ höhere Portabilität, da weniger Bindung an konkrete Technologie

■ Nicht-invasives Frameworks

◆ Aufrufe an POJO-Methoden werden abgefangen

• zur Realisierung Transaktionen, Authorisierung, …

◆ oft präzisere, benutzerfreundliche Metadaten (subjektiv?)

◆ Evolution/Austausch mit geringeren Änderungen in Code und Metadaten

E.116


13.2 EJB 3.0 (2)

■ Inversion of Control konsequent umgesetzt

◆ Dependency Injection

• Hollywood Principle: „Don’t call us, we’ll call you!“

◆ deklarative Konfiguration der Daten-Umgebung

◆ Container sorgt für Verknüpfung mit benötigten Objekten

■ Erleichterung der Konfiguration

◆ sinnvolle Defaulteinstellungen

• weniger Konfigurationsaufwand

◆ gestützt durch „Convention over Configuration“

• Schnittstellen und Konfiguration aus Defaults, Namen, Typen abgeleitet

• optionale Deskriptoren ergänzen/verändern Standardverhalten

▲ EJB 3.0: Reaktion auf einfacher zu handhabende Frameworks

◆ Spring, Hibernate, Ruby on Rails

◆ vielleicht „zu spät“ am Markt E.117© 2002-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2007s-AvID-E-EJB.fm, 2007-06-20 09.18] http://www-vs.informatik.uni-ulm.de/teach/ss07/avid/

14 EJB-Anbindung an den Client

■ Direkte Anbindung

◆ Zugang zum Home-Interface eines Bean-Typs

• z.B. über JNDI aus Namensdienst des Containers

◆ Zugriff auf Beans über RMI-IIOP

■ Zugriff über dynamische Webseiten

◆ z.B. Bestellformular, „Einkaufswagen“

◆ Implementierung

• CGI-Skript greift direkt auf Beans zu

• JSP (Java-Server-Pages)– Taglib für EJB-Anbindung (z.B. Referenz auf Home-Interface in JNDI suchen)

• Servlets

E.118


15 Literatur

■ Verwendete und weiterführende Referenzen

◆ E. Roman, S. Ambler, T. Jewell: Mastering Enterprise Java Beans. 2nd Ed., Wiley & Sons, 2002.

◆ Enterprise JavaBeans Ver. 2.1, Specification<http://java.sun.com/products/java/docs.html>

◆ Developer’s Bookshelf about Java 2 Enterprise Edition (J2EE)<http://java.sun.com/developer/Books/j2ee/>

◆ Richardson: Untangling Enterprise Java. ACM Queue, Vol.4 No.5, Juni 2006.

◆ L. DeMichiel, M. Keith (Eds.): EJB Simplified API, JSR 220: Enterprise Java Beans, Version 3.0. Sun Microsystems, 2006.

◆ L. DeMichiel, M. Keith (Eds.): EJB Core Contracts and Requirements, JSR 220: Enterprise Java Beans, Version 3.0. Sun Microsystems, 2006.

◆ L. DeMichiel, M. Keith (Eds.): Java Persistence API, JSR 220: Enterprise Java Beans, Version 3.0. Sun Microsystems, 2006.

E.119

Documents

11.2 Exkurs: Java Annotations 12 EJB 3 - ... · Keine automatische Persistenz in EJB3.0 Entity-Beans ... Spring, Hibernate, Ruby on ... Franz J. Hauck, Verteilte Systeme, Univ. Ulm,