20 Jahre Erfahrung FreeCall 0800 tutegos

Sie befinden sich hier: Home › Ratgeber › Java

EJB 3.x und JPA Tutorials

Die Seite fasst die Neuerungen der Spezifikation zu EJB3 (JSR 220) zusammen und verweist auf Seiten, die sich mit Entity-Beans, Session Beans und Message Driven Beans auseinandersetzen.

Änderungen von EJB 3.0 und JPA 1.0

  • Metadaten werden durch Annotationen beschrieben.
  • Deployment-Deskriptoren sind nicht nötig, können aber ebenfalls Metadaten beschreiben, wenn Annotationen nicht gewünscht sind. Das ist insbesondere praktisch bei den Mapping-Informationen der Entity-Beans, die somit nicht zwingend im Quellcode stehen müssen.
  • Viele vordefinierte Einstellungen und nur die Ausnahmen von den Regeln werden spezifiziert.
  • Home-Interfaces sind nicht mehr nötig, eine Session-Bean hat nur ein Business-Interface. Entity-Beans sind remote nicht zugänglich, daher ist kein Component- und Home-Interface nötig.
  • Keine Bean muss eine javax.ejb-Schnittstelle wie EntityBean, SessionBean, MessageDrivenBean implementieren und Callback-Methoden anbieten, die vielleicht sowieso nicht aufgerufen werden. (Etwa bei Stateless-SessionBeans die Methoden für Passivierung/Aktivierung.)
  • Falls es zum Beispiel eine remove-Methode geben muss, wird diese annotiert. Für eine Methode wie setSessionContext(...) wird Setter-Injection genutzt. Somit funktionieren die Aufrufe auch ohne Callback-Methoden über ein Interface.
  • Keine Klasse implementiert (und Schnittstelle erweitert) die Markierungsschnitstelle Remote.
  • Exceptions müssen nicht mehr deklariert werden. (Ein Ärgernis mit dem Business-Interfaces für den lokalen und remote Fall).
  • EJB 3 Entity-Beans sind ›Plain Old Java Objects‹ (POJOs) und nicht mehr abstrakt. Die Objekte sind viel leichter zu testen und ein First-Test-Ansatz ist damit viel leichter.
  • Es lassen sich Entity-Beans objektorientiert modellieren, denn Vererbung ist möglich.
  • EJB-QL wird mit Projektion, Inner und Outer Join, Bulk-Updates, Bulk-Deletes, Sub-Queries und GROUP BY vervollständigt.

Änderungen von EJB 3.1 und JPA 2

  • Die lokale Schnittstelle (local view) einer lokalen Session Bean kann nun entfallen, da direkt die öffentlichen Methoden als Schnittstelle verwendet werden können. Eine lokale Session Bean muss daher keine Schnittstelle mehr implementieren, um injiziert zu werden und Methoden anzubieten.
  • EJBs müssen nicht mehr in einem EAR-Archiv verpackt sein, sondern können einfach in einem WAR deployed werden. Im Fall von WAR-Archiven liegen dann die Klassen unter WEB-INF/classes.
  • Mit der Annotation @Singleon lässt ein Singleton markieren, sodass sich eine Session Bean (die auch Business Schnittstellen implementieren kann) von unterschieden Stellen nutzen lässt, aber eben nur einmal in der JVM vorhanden ist.
  • Die Annotation @Startup ist ein Zusatz für @Singleton, um über das Hoch-/Runterfahren des Applikationsservers informiert zu werden. Die Callbackmethoden nutzen das bekannte @PostConstruct und @PreDestroy.
  • Der EntityManager erlaubt ein detach(...).
  • Embeddable's können in JPA 2.0 geschachtelt sein und Relationen eingehen.
  • Weitere Mappings bei JPA-Tabellen. Map-Keys können nun einfache Objekte, Entities und embedded Entities sein.
  • Bisher konnten etwa 1:n-Assoziationen immer nur Verweise auf Entity-Beans realisieren, aber keine Sammlungen etwa von Strings oder Datums-Objekten. Das ändert sich mit JPA 2.0, das Collections von Elementen erlaubt. Hier zieht JPA eine Collection-Table heran.
  • Die Entities im Persistence Context eines Entity-Managers sind in einem Cache, dem Level 1 Cache. Bei zwei Entity-Managern ist es implementierungsabhängig, wie zum Beispiel zwei gleiche Entity-Beans in den beiden EM gehalten werden. Das bestimmt ein Level 2 Cache. Dieser Level 2 Cache lässt sich über die Shared Cache API von JPA 2.0 rudimentär kontrollieren.
  • Mit einer @Version-Spalte erlaubt JPA 1.0 schon immer optimistisches Locking, allerdings nur optimistische Lese- oder Schreib-Sperren. Mit JPA 2.0 wird über die Enum LockMode nun Optimistisches und auch Pessimistisches Locking unterstützt.
  • Eine neue Criteria-API kommt in JPA 2.0 und damit neue Typen wie QueryBuilder, CriteriaQuery. Die API folgt dem Fluent-Interface Prinzip, etwa wie bei criteriaQuery.select(entity.get("id")).where(queryBuilder.cojunction(queryBuilder.equals(...), ...)).
  • JPA-QL kennt für Datumswerte nun auch Literale.
  • JPA-QL unterstützt polymorphe Anfragen der Art WHERE CLASS(e) = Klassenname.
  • JPA-QL ermöglicht CASE-Anfragen wie eine Fallunterscheidung.
  • JPA-QL erlaubt in der WHERE-Klausel Zugriff auf den Index einer Liste.

Spezifikation (Final seit Mai 2006)

EJB allgemein

JPA im Speziellen, JPA-Tutorials

Diskussionen

Neues zu EJB 3.1 und JPA 2.0

Implementierungen

Einige Server (wenn ich IBM sage, weiß jeder Bescheid), brauchen bei der Umsetzung etwas länger. Hier die Zahlen aus einem Beitrag "App Server Powers Race To Embed Java EE 5 Support. Sun and BEA get in early, JBoss not far behind, IBM lags" (Dr. Dobbs, Oktober 2006).

EJB 3 Schulung

Das dreitägige EJB 3-Seminar vermittelt ebenso alle Neuerungen im Bereich Session-Beans (mit Web-Services), Entity-Beans und Message Driven-Beans.