EJB 3.1 professionell
iX-Edition
In der iX-Edition erscheinen Titel, die vom dpunkt.verlag gemeinsam mit der Redaktion der Computerzeitschrift iX ausgewählt und konzipiert werden. Inhaltlicher Schwerpunkt dieser Reihe sind Standardwerke zu professioneller Datenverarbeitung und Internet.
Grundlagen- und Expertenwissen zu
Enterprise JavaBeans 3.1 – inkl. JPA 2.0
Lektorat: René Schönfeldt
Copy-Editing: Ursula Zimpfer, Herrenberg
Herstellung: Birgit Bäuerlein
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Buch 978-3-89864-612-3
PDF 978-3-89864-851-6
ePub 978-3-86491-025-8
2., aktualisierte und erweiterte Auflage 2011
Copyright © 2011 dpunkt.verlag GmbH
Ringstraße 19 B
69115 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Vorwort
1 Einleitung – Jetzt wird’s leicht!
Teil I Grundlagen
2 Leichtgewichtige, POJO-basierte Enterprise-Applikationen
3 EJB-Komponentenarchitektur
4 EJB Lite – das abgespeckte EJB
Teil II Technologie
5 Session Beans
6 Session Beans als Webservice
7 Message-Driven Beans
8 Entity Beans
9 Persistenzabbildung
10 JPA-Abfragen
11 Der Lebensraum der Enterprise Beans
12 Callback-Mechanismen
13 Interzeptoren
14 Timer Service
15 Sicherer Zugriff auf EJB-Komponenten
Teil III Ergänzende Themen
16 CDI (Web Beans)
17 Testen von EJB-Komponenten
18 Migration von EJB 2.x nach 3.x
Anhang
Literatur – offline und online
Stichwortverzeichnis
Vorwort
Was ist neu in der zweiten Auflage?
Für wen ist dieses Buch?
Von wem ist dieses Buch?
Danksagungen
Widmung
Ihre Kommentare und Anmerkungen
1 Einleitung – Jetzt wird’s leicht!
1.1 Die Evolution der Enterprise JavaBeans
1.1.1 Der Fluch der Komplexität
1.1.2 Kritik an den früheren EJB-Versionen
1.1.3 Ein neues Denken schafft eine neue Architektur
1.1.4 Der konsequente nächste Schritt
1.2 Aufbau des Buches
1.2.1 Die Themenbereiche
1.2.2 Die Kapitel: Struktur und Inhalte
1.3 Konventionen
1.3.1 Notation
1.3.2 Literaturverweise bzw. Referenzen
1.3.3 Quellcode
1.3.4 Piktogramme
1.3.5 Verwendung von Anglizismen
1.3.6 Gleichberechtigung in der Sprache
1.4 Die Beispielapplikation »Ticket2Rock«
1.4.1 Kurzbeschreibung
1.4.2 Anwendungsfälle
1.4.3 Fachliche Entitäten
1.5 Verwendete Technologien und Produkte
1.6 Die Website zum Buch
Teil I Grundlagen
2 Leichtgewichtige, POJO-basierte Enterprise-Applikationen
2.1 Kurz gefasst
2.2 Der Blick zurück
2.3 Einleitung
2.4 Hauptziele für EJB 3.x
2.4.1 Motive
2.4.2 »Einfach machen!«
2.4.3 Vereinfachung der Mikroarchitektur von EJB-Komponenten
2.4.4 Vereinfachung des Entwicklungsprozesses
2.4.5 Vereinfachung der Nutzung von EJB-Komponenten
2.4.6 Neuentwicklung einer leistungsfähigen Persistenzlösung
2.5 POJOs und POJIs
2.5.1 POJO
2.5.2 POJI
2.5.3 Unterschiede zwischen EJB 3.x und EJB 2.x
2.6 Inversion of Control und Dependency Injection
2.6.1 Ziele im Kontext von EJB 3.x
2.6.2 Auswirkungen auf die EJB-3.x-Architektur
2.6.3 »Hollywood, wir kommen!« – ein Beispiel
2.7 Annotationen und Deployment-Deskriptoren
2.7.1 Einführung
2.7.2 Deployment-Deskriptoren – so schlecht wie ihr Ruf?
2.7.3 Annotationen
2.7.4 Ein Plädoyer für Deployment-Deskriptoren
2.7.5 Der Deployment-Deskriptor hat das letzte Wort
2.8 Configuration by Exception
3 EJB-Komponentenarchitektur
3.1 Kurz gefasst
3.2 Grundlegende Konzepte
3.2.1 Komponentenarchitektur
3.2.2 Java EE
3.2.3 Java SE
3.2.4 Der Java-EE-Applikationsserver
3.2.5 Der EJB-Container
3.3 Übersicht der EJB-Typen
3.3.1 Session Bean
3.3.2 Message-Driven Bean
3.3.3 Persistent Entity
3.4 Aufrufmodelle
3.4.1 Aufrufmodell: »entfernt«
3.4.2 Aufrufmodell »lokal«
3.4.3 Aufrufmodell »nachrichtenbasiert«
3.4.4 Aufrufmodelle und EJB-Typen im Überblick
4 EJB Lite – das abgespeckte EJB
4.1 Kurz gefasst
4.2 Der Blick zurück
4.3 Leicht zu sein bedarf es wenig
4.4 Was mach ich nun mit dem EJB-Lite-Profil?
Teil II Technologie
5 Session Beans
5.1 Kurz gefasst
5.2 Der Blick zurück
5.3 Einführung
5.4 Stateless Session Beans
5.4.1 Transaktionen
5.4.2 Instanz-Pooling
5.4.3 Webservices
5.5 Stateful Session Beans
5.5.1 Aktivierung und Passivierung
5.5.2 Transaktionen
5.6 Singleton Session Beans
5.6.1 Transaktionen
5.6.2 Nebenläufigkeit
5.7 Stateless, Stateful und Singleton Session Beans im Vergleich
5.8 Mikroarchitektur einer Session Bean
5.8.1 Namenskonventionen
5.8.2 Zusammenspiel der Elemente
5.8.3 Erzeugen von Session Beans
5.8.4 Löschen von Session Beans
5.9 Lebenszyklus von Stateless Session Beans
5.9.1 Zustand »does not exist«
5.9.2 Übergang von »does not exist« zu »method-ready pool«
5.9.3 Zustand »method-ready pool«
5.9.4 Übergang von »method-ready pool« zu »does not exist«
5.10 Lebenszyklus von Stateful Session Beans
5.10.1 Zustand »does not exist«
5.10.2 Übergang von »does not exist« zu »method-ready«
5.10.3 Zustände »method-ready« und »method-ready in TX«
5.10.4 Zustand »passive«
5.10.5 Übergang in den Zustand »does not exist«
5.11 Lebenszyklus von Singleton Session Beans
5.11.1 Zustand »does not exist«
5.11.2 Übergang von »does not exist« zu »method-ready«
5.11.3 Zustand »method-ready«
5.11.4 Übergang von »method-ready« zu »does not exist«
5.12 Business Interface
5.13 No-Interface Client View
5.14 Bean-Klasse
5.14.1 Deklarative Transaktionalität
5.14.2 Transaktionen in Handarbeit
5.14.3 Transaktionen im Ausnahmezustand
5.14.4 EJB-Kontext
5.14.5 Checkliste
5.15 Nebenläufigkeit bei Singleton Session Beans
5.15.1 Nebenläufigkeit – Container-Managed
5.15.2 Nebenläufigkeit – Bean-Managed
5.16 Asynchrone Methodenaufrufe
5.17 Timer Service
6 Session Beans als Webservice
6.1 Kurz gefasst
6.2 Der Blick zurück
6.3 Was ist ein WebService?
6.4 Stateless und Singleton Session Beans als Webservice
6.4.1 @WebService
6.4.2 @SOAPBinding
6.4.3 @WebMethod
6.4.4 @Oneway
6.4.5 @WebParam
6.4.6 @WebResult
6.4.7 @HandlerChain
6.5 Vorgehensweise bei der Erstellung von Webservices
6.6 Die Abbildung von Rückgabetypen und Parametern beeinflussen
6.7 Ein Webservice-Client
7 Message-Driven Beans
7.1 Kurz gefasst
7.2 Der Blick zurück
7.3 Nachrichtenbasierte Kommunikation
7.3.1 Charakteristika und Vorteile
7.3.2 Kommunikationsmodelle
7.4 Java Message Service (JMS)
7.4.1 Service Provider Interface
7.4.2 JMS API
7.5 Charakteristika von Message-Driven Beans
7.5.1 JMS Message-Driven Beans
7.5.2 Connector-based Message-Driven Beans
7.6 Lebenszyklus von Message-Driven Beans
7.7 Transaktionalität
7.8 Bean-Klasse
7.8.1 @MessageDriven
7.8.2 @ActivationConfigProperty
7.8.3 Message Listener Interface
7.8.4 Beantworten von Nachrichten
7.8.5 Checkliste
7.9 Deployment-Deskriptor
7.10 Timer Service
7.11 Ein JMS-Client
7.12 Message Linking
8 Entity Beans
8.1 Kurz gefasst
8.2 Der Blick zurück
8.3 Aus Entity Beans werden Persistent Entities
9 Persistenzabbildung
9.1 Kurz gefasst
9.2 Der Blick zurück
9.3 Persistenz? Abbildung?
9.4 Persistent Entities
9.4.1 Lightweight
9.4.2 Persistent
9.4.3 Domain Object
9.4.4 Lebenszyklus
9.5 Persist my POJO!
9.5.1 Annotation oder Deployment-Deskriptor?
9.5.2 Beispiel
9.6 Grundkonzepte
9.6.1 Persistence Provider
9.6.2 Entity-Manager
9.6.3 Persistenzeinheit
9.6.4 Persistenzkontext
9.7 Deployment-Deskriptoren
9.7.1 persistence.xml
9.7.2 orm.xml
9.8 Arbeiten mit dem Entity-Manager
9.8.1 Dauerhaftes Speichern in der Datenbank (persist)
9.8.2 Aktualisieren des persistenten Objektzustands (merge)
9.8.3 Löschen einer Persistent Entity (remove)
9.8.4 Finden einer Persistent Entity in der Datenbank (find, getReference)
9.8.5 Sofortiges Ausführen der Datenbankoperation (flush)
9.8.6 Blockieren einer Persistent Entity (lock)
9.8.7 Aktualisieren des Zustands der Objektinstanz (refresh)
9.8.8 Leben im Persistenzkontext (clear, contains)
9.8.9 Losgelöst (detach)
9.8.10 Abfragen (create...Query)
9.8.11 Transaktionen (joinTransaction)
9.8.12 Zugriff auf den Persistence Provider (getDelegate)
9.8.13 Beenden des Entity-Managers (close)
9.8.14 Suche nach Entitäten (getCriteriaBuilder)
9.8.15 Das Metamodell der Persistenz (getMetaModel)
9.9 Abbildung von Datentypen
9.9.1 Zugriff auf persistente Felder
9.9.2 Einfache Datentypen (@Basic)
9.9.3 Eingebettete Objekte (@Embeddable)
9.9.4 Große Objekte (@Lob)
9.9.5 Datum und Zeit (@Temporal)
9.9.6 Aufzählungen (@Enumerated)
9.10 Abbildung in Datenbanktabellen
9.10.1 @Table
9.10.2 @Column
9.11 Primärschlüssel
9.11.1 Einfache Primärschlüssel (@Id)
9.11.2 Zusammengesetzte Primärschlüssel (@IdClass, @EmbeddedId)
9.11.3 Generierung von Primärschlüsseln
9.12 Abbildung von Objektbeziehungen
9.12.1 Die glorreichen Sieben
9.12.2 Unidirektionale Eins-zu-Eins-Beziehung
9.12.3 Bidirektionale Eins-zu-Eins-Beziehung
9.12.4 Unidirektionale Eins-zu-Viele-Beziehung
9.12.5 Bidirektionale Eins-zu-Viele-Beziehung
9.12.6 Unidirektionale Viele-zu-Eins-Beziehung
9.12.7 Bidirektionale Viele-zu-Eins-Beziehung
9.12.8 Unidirektionale Viele-zu-Viele-Beziehung
9.12.9 Bidirektionale Viele-zu-Viele-Beziehung
9.12.10 Kaskadieren von Persistenzoperationen
9.13 Eingebettete Objekte
9.14 Abbildung auf mehrere Datenbanktabellen
9.14.1 »Single-Table-Mapping«
9.14.2 Multi-Table-Mapping
9.15 Vererbung und Polymorphie
9.15.1 Erben und Vererben
9.15.2 single table per class hierarchy strategy (SINGLE_TABLE)
9.15.3 single table per concrete entity class strategy (TABLE_PER_CLASS)
9.15.4 joined subclass strategy (JOINED)
9.16 Fetching-Strategien
9.16.1 Eager Load
9.16.2 Lazy Load
9.16.3 Deklaration der Fetching-Strategie
9.16.4 Lazy Load und Detached Objects
9.16.5 Caching von Entitäten
10 JPA-Abfragen
10.1 Kurz gefasst
10.2 Der Blick zurück
10.3 Abfragen mit der Query API
10.3.1 Queries
10.3.2 Named Queries
10.3.3 Native Queries
10.3.4 Criteria Queries
10.4 Java Persistence Query Language (JPQL)
10.4.1 SELECT
10.4.2 FROM
10.4.3 WHERE
10.4.4 ORDER BY
10.4.5 GROUP BY
10.4.6 HAVING
10.4.7 Schreibende Massenoperationen
10.5 Criteria API
10.5.1 Aufbau von Abfragen
10.5.2 CriteriaQuery
10.5.3 Operatoren, Funktionen und Ausdrücke
11 Der Lebensraum der Enterprise Beans
11.1 Kurz gefasst
11.2 Der Blick zurück
11.3 Der Enterprise Naming Context
11.4 Globale JNDI-Namen
11.4.1 Namensschema
11.4.2 Beispiel
11.5 Konfigurationsalternativen
11.5.1 Annotationen
11.5.2 Deployment-Deskriptoren
11.5.3 Kombination von Annotationen und Deployment-Deskriptoren
11.6 Arbeiten mit dem ENC
11.6.1 Bestückung mittels Deployment-Deskriptoren
11.6.2 Bestückung mittels Annotationen
11.6.3 Zugriff via JNDI-Lookup
11.6.4 Zugriff via EJBContext
11.6.5 Dependency Injection mit Deployment-Deskriptoren
11.6.6 Dependency Injection mit Annotationen
11.6.7 Sichtbarkeit von Einträgen im ENC
11.7 Auswirkungen auf den Softwaretest
11.8 Ressourcentypen
11.8.1 Enterprise Beans (@EJB)
11.8.2 Extern verwaltete Ressourcen (@Resource)
11.8.3 Resource Environment Entries (@Resource)
11.8.4 Umgebungsvariablen (@Resource)
11.8.5 Persistenzkontext (@PersistenceContext)
11.8.6 Persistenzeinheiten (@PersistenceUnit)
11.8.7 Message Destinations
11.8.8 Webservices (@WebServiceRef)
12 Callback-Mechanismen
12.1 Kurz gefasst
12.2 Der Blick zurück
12.3 Inversion of Control
12.4 Deklaration einer Callback-Methode
12.4.1 Callback-Annotationen
12.4.2 Deklaration im Deployment-Deskriptor
12.4.3 Für jede Bean die passenden Callbacks
12.4.4 Regeln für Callback-Methoden
12.5 Aufrufreihenfolge für Callback-Methoden
12.6 Callbacks für Stateless Session Beans
12.6.1 @PostConstruct
12.6.2 @PreDestroy
12.7 Callbacks für Stateful Session Beans
12.7.1 @PostConstruct und @PreDestroy
12.7.2 @PrePassivate
12.7.3 @PostActivate
12.8 Callbacks für Singleton Session Beans
12.8.1 @PostConstruct und @PreDestroy
12.8.2 @PostActivate und @PrePassivate werden ignoriert
12.9 Callbacks für Message-Driven Beans
12.9.1 @PostConstruct und @PreDestroy
12.9.2 @PostActivate und @PrePassivate werden ignoriert
12.10 Callbacks für Persistent Entities
12.10.1 Aufrufreihenfolge im Objektverbund
12.10.2 @PrePersist und @PostPersist
12.10.3 @PreUpdate und @PostUpdate
12.10.4 @PreRemove und @PostRemove
12.10.5 @PostLoad
13 Interzeptoren
13.1 Kurz gefasst
13.2 Der Blick zurück
13.3 Was ist aspektorientierte Programmierung?
13.4 Klassifikation
13.4.1 Interzeptoren für Geschäftsmethoden
13.4.2 Interzeptoren für Timeout-Methoden von Timer-Objekten
13.4.3 Interzeptoren für Lebenszyklusereignisse
13.4.4 Default-Interzeptoren
13.4.5 Entity Listener
13.4.6 Default Entity Listener
13.5 Interzeptoren für Geschäftsmethoden
13.5.1 Definition
13.5.2 Verwendung
13.5.3 InvocationContext
13.5.4 Aufrufreihenfolge
13.5.5 Ausnahmebehandlung
13.5.6 @AroundInvoke-Methode in der Bean-Klasse
13.6 Interzeptoren für Timeout-Methoden von Timer-Objekten
13.6.1 Definition
13.6.2 Verwendung
13.6.3 Aufrufreihenfolge
13.6.4 Ausnahmebehandlung
13.7 Interzeptoren für Lebenszyklusereignisse
13.7.1 Definition
13.7.2 Verwendung
13.7.3 Aufrufreihenfolge
13.7.4 Ausnahmebehandlung
13.8 Default-Interzeptoren
13.9 Entity Listener
13.9.1 Definition
13.9.2 Verwendung
13.9.3 Aufrufreihenfolge
13.10 Default Entity Listener
13.11 Sind Interzeptoren und Entity Listener aspektorientiert?
14 Timer Service
14.1 Kurz gefasst
14.2 Der Blick zurück
14.3 Programmgesteuerte Timer
14.3.1 Die Timeout-Methode
14.3.2 Das Interface javax.ejb.TimerService
14.4 Timer-Objekte
14.5 Automatische Timer
14.6 Ausdrucksmöglichkeiten für Zeitpläne
14.7 Timer und EJB-Typen
14.7.1 Stateless Session Bean Timer
14.7.2 Singleton Session Bean Timer
14.7.3 Message-Driven Bean Timer
14.7.4 Timer und Entitäten
14.8 Timer und Transaktionen
14.9 Timer und Interzeptoren
14.10 Checkliste
15 Sicherer Zugriff auf EJB-Komponenten
15.1 Kurz gefasst
15.2 Der Blick zurück
15.3 Überblick
15.4 Authentifizierung
15.5 Sicherheitsrollen
15.6 Verwendung von Rollen
15.6.1 @RolesAllowed
15.6.2 @PermitAll
15.6.3 @DenyAll
15.7 Ausführen in einem anderen Kontext (@RunAs)
15.8 Identität von Message-Driven Beans und Timer Services
15.9 Programmgesteuerter Zugriff auf den Security-Kontext
15.10 Regeln für Security-Annotationen
Teil III Ergänzende Themen
16 CDI (Web Beans)
16.1 Kurz gefasst
16.2 Der Blick zurück
16.3 Einführung
16.3.1 Grundkonzepte
16.3.2 Let’s rock – ein praktisches Beispiel
16.4 Das Bean-Verständnis von CDI
16.4.1 Managed Beans
16.4.2 Session Beans
16.5 Die Werkzeugkiste
16.5.1 Bean-Typen
16.5.2 Qualifier
16.5.3 Alternativen
16.5.4 Scopes
16.5.5 Expression Language Name
16.5.6 Interzeptoren
16.5.7 Dekoratoren
17 Testen von EJB-Komponenten
17.1 Kurz gefasst
17.2 Dies ist kein Buch über Softwaretests!
17.3 Der Blick zurück
17.4 Warum testen?
17.5 Wann testen?
17.6 Wie und wo testen?
17.6.1 Akzeptanztests und fachliche Tests
17.6.2 Integrative Tests
17.6.3 Last- und Performanztests
17.7 Testen von Enterprise Beans
17.7.1 Testen von Stateless Session Beans
17.7.2 Testen von Stateful Session Beans
17.7.3 Testen von Message-Driven Beans
17.7.4 Testen von Persistent Entities
17.7.5 Testen von Transaktionen
17.7.6 Testen von Interzeptoren
17.7.7 Testen von Lebenszyklusmethoden
17.7.8 Testen von Timer Services
18 Migration von EJB 2.x nach 3.x
18.1 Kurz gefasst
18.2 Der Blick zurück
18.3 Sanfte Migration
18.3.1 Gleichzeitiger Betrieb von 2.x- und 3.x-Komponenten
18.3.2 Kommunikation zwischen 2.x- und 3.x-Komponenten
18.3.3 Migration von Session Beans
18.3.4 Migration von Message-Driven Beans
18.3.5 Migration von Entity Beans
18.3.6 Migration von Data Transfer Objects
18.3.7 Migration von Clients
18.4 Der Einfluss von EJB 3.x auf J2EE-Entwurfsmuster
18.4.1 Business Delegate
18.4.2 Session Facade
18.4.3 Message Facade/Service Activator
18.4.4 EJB Command
18.4.5 EJB Home Factory/Service Locator
18.4.6 Business Interface
18.4.7 Data Transfer Object (DTO)/Value Object
18.4.8 DTO Factory
18.4.9 Data Transfer Hash Map
18.4.10 Value List Handler
18.4.11 Generic Attribute Access
18.4.12 Data Transfer Row Set
18.4.13 Composite Entity
18.4.14 Dual Persistent Entity Bean
18.4.15 Data Access Command Bean/Data Access Object (DAO)
18.4.16 JDBC for Reading/Fast Lane Reader
18.4.17 Version Number
18.4.18 Muster zur Generierung von Primärschlüsseln
18.4.19 Fazit
Anhang
Literatur – offline und online
Stichwortverzeichnis
Praxisorientierte Sichtweise
Dieses Buch ist ein praxisorientiertes Grundlagenwerk über die Version 3.1 der Komponententechnologie Enterprise JavaBeans. Es beschreibt und erläutert die Grundlagen, die Konzepte und die praktische Anwendung von EJB 3.1 sowie die Migration von bestehenden Applikationen, die auf Vorgängerversionen der EJB- bzw. Java-EE-Technologie basieren.
Schwerpunkt
Der Schwerpunkt dieses Buches liegt auf der praxisnahen Vermittlung von grundlegendem und tiefer gehendem Wissen über die Enterprise-JavaBeans-3-Technologie. Wir komplettieren die Einführung und Vertiefung durch praxisrelevante Themen, die nicht direkt im EJB-Standard behandelt werden. Dazu gehören das Testen von (verteilten) Komponenten, die Persistenzabbildung von EJB-Komponenten (Java Persistence API, JPA) und deren Verwendung in der Benutzeroberfläche (Contexts and Dependency Injection for the Java EE Platform, CDI) sowie die Beschreibung von Migrationspfaden für bestehende J2EE-Systeme nach EJB 3.
Durchgängiges Beispiel
Bei der Konzeption und Umsetzung dieses Buches haben wir sehr großen Wert auf eine praxisorientierte Sichtweise gelegt. Die Technologie selbst, aber auch die weiterführenden Themen werden anschaulich anhand eines durchgängigen Beispiels beschrieben. Best Practices aus dem Erfahrungsschatz der Autoren, gesammelt in verschiedenen Softwareentwicklungsprojekten, runden das Bild ab.
Der Unterschied zwischen der Version 3.0, die wir in der ersten Ausgabe dieses Buches vorgestellt haben, und der hier beschriebenen Version 3.1 ist klein, wenn man allein die Versionsnummer als Maß wählt. Inhaltlich hat sich in der EJB-Spezifikation und in deren Umfeld jedoch viel getan:
EJB 3.x ist im Vergleich zu den Vorgängerversionen ein leichtgewichtiges Framework. Wer es noch leichtgewichtiger braucht, der kann die abgespeckte Variante namens EJB 3.1 Lite verwenden, die nur die allernötigsten EJB-Funktionen beinhaltet.
Aufrufe können asynchron erfolgen,
alle public
-Methoden werden automatisch ohne explizites Interface zur Verfügung gestellt (No-Interface View),
die Singleton Session Bean feiert ihre Premiere.
Die Java Persistence API (JPA) ist zwar in einer eigenen Spezifikation beschrieben, darf aber in einem EJB-Buch nicht fehlen. Was wäre eine Business-Applikation ohne Persistenz? Die Version 2.0 der JPA bietet eine ganze Reihe von Neuerungen, darunter auch die folgenden:
Abfragen können nicht nur mit der Java Persistence Query Language (JPQL), sondern jetzt auch mithilfe der Criteria API formuliert werden,
optimistisches und pessimistisches Locking ist nun möglich und gezielt steuerbar,
der Entity Manager hat deutliche Verbesserungen erfahren,
zur Optimierung von Datenzugriffen steht ein Level-2-Cache zur Verfügung und
mittels Orphan Removal werden verwaiste Entitäten eines Objektnetzes automatisch gelöscht.
Die in der Spezifikation definierten globalen JNDI-Namen müssen von allen EJB-3.1-Implementierungen unterstützt werden; damit sind JNDI-Namen endlich portabel.
Timer können auf Basis kalenderbasierter Zeitpläne definiert und automatisch angelegt werden (Annotation @Schedule
),
wobei die Zeitangaben sich auf eine bestimmte Zeitzone beziehen können.
Auch bei der Contexts and Dependency Injection (CDI) handelt es sich streng genommen um eine separate Spezifikation. Ihr zentrales Thema ist die Standardisierung und Vereinfachung des Zusammenspiels zwischen der Präsentationsschicht JavaServer Faces (JSF) und der mit EJB-Technologie implementierten Geschäftslogik. Mit dem Überblick über CDI runden wir das Themenspektrum dieses Buches ab; schießlich haben viele Applikationen ein Web-Frontend und müssen sich deshalb mit der Frage auseinandersetzen, wie die Enterprise-Beans möglichst transformationsarm an der Benutzeroberfläche dargestellt und manipuliert werden können.
Als Mock-Framework für die Tests verwenden wir jetzt Mockito,
ausgeführt werden die Tests im neuen Embeddable Container, der sich gut in eine Continuous-Integration-Umgebung einfügt.
Softwareentwickler, -architekten und (technische) Projektleiter
Dieses Buch richtet sich an Softwareentwickler, Softwarearchitekten und (technische) Projektleiter, die sich mit dem Design und der Entwicklung von Enterprise-Applikationen auf der Basis von Enterprise JavaBeans 3 beschäftigen.
Wenn Sie praktische Hinweise für die Entwicklung leichtgewichtiger, mächtiger, komponentenbasierter Enterprise-Java-Systeme suchen, die auf Konzepten wie POJO (Plain Old Java Objects) und Inversion of Control fußen, dann ist dieses Buch etwas für Sie.
Voraussetzungen
Sie sollten fundierte Kenntnisse der objektorientierten Softwareentwicklung, der Unified Modeling Language (UML) sowie der Programmiersprache Java mitbringen. Auch mit den grundlegenden Konzepten von Java 6 sollten Sie vertraut sein. Insbesondere Metadaten (Annotationen) und Generics werden in der EJB-3.1-Spezifikation und in unserer Beispielapplikation intensiv verwendet.
Auch wenn auf dem Buchcover nur sechs Autoren genannt sind, so haben tatsächlich neun Personen ihren Beitrag dazu geleistet.
V.l.n.r.: Oliver Ihns, Jo Ehm, Stefan M. Heldt, Holger Koschek, Carsten Sahling, Roman Schlömmer, Norman Erck, Daniel Steinhöfer, Carl Anders Düvel
beschäftigt sich seit mehr als 20 Jahren mit Architekturen und Technologien verteilter, objekt- und serviceorientierter Systeme als Berater, Coach, Referent auf Fachkonferenzen und Autor von Büchern und Fachartikeln. Er ist Mitglied in verschiedenen Expert Groups (u.a. EJB 3.1, JPA 1.0 und WebBeans/CDI) im Java Community Process (JCP) und definiert und entwickelt auf diese Weise federführend Kerntechnologien der Java-Welt mit. Sein Tätigkeitsfeld erstreckt sich von den technologischen Grundlagen von verteilten Systemen über die Architekturberatung und das Architekturmanagement (EAM, SOA, Bebauungspläne) bis hin zu den strategischen Aspekten von Unternehmensarchitekturen und der Auditierung von Systemen. Oliver Ihns wurde 2005 von Sun Microsystems in den kleinen Kreis der Java Champions berufen. Er ist Mitglied des Vorstands der Holisticon AG, einer international tätigen Management- und IT-Beratung.
arbeitet als Berater, Coach und Trainer bei der Holisticon AG. Als Softwarearchitekt unterstützt er Unternehmen im Bereich Architekturen und Technologien für verteilte unternehmenskritische Anwendungen sowie bei der Modellierung und Implementierung von Geschäftsprozessen. Neben seiner beratenden Tätigkeit ist er als Autor von Fachartikeln und als Referent auf Konferenzen präsent. Als Mitglied der Expert Group für EJB 3.2 im Java Community Process (JCP) wird er diese Technologie zukünftig an der Quelle aktiv mitgestalten.
arbeitet als Berater und Coach bei der Holisticon AG. Seit 1997 ist er in kleinen bis sehr großen, mitunter auch verteilten internationalen IT-Projekten unterwegs. Aufbauend auf seinen Erfahrungen mit der Architektur und Entwicklung verteilter objektorientierter Anwendungssysteme unterstützt er Unternehmen bei der Einführung agiler Vorgehensweisen sowie bei der Modernisierung ihrer Softwarearchitekturen. Sein Wissen gibt er gerne in Form von Büchern, Fachartikeln und Konferenzbeiträgen weiter. Holger Koschek ist Autor der »Geschichten vom Scrum« (dpunkt.verlag 2009) und Koautor von »Unternehmensportale« (mit Martina Großmann, Springer-Verlag 2005).
ist Senior Consultant bei der Holisticon AG. Er ist GPM/IPMA-zertifizierter Projektmanager und unterstützt neben seiner Arbeit als Projektmanager Kundenprojekte auch als Softwarearchitekt, Coach und Lead Software Engineer. Sein Fokus liegt auf den Technologien und Architekturen für serviceorientierte und webbasierte Enterprise-Applikationen sowie auf der Modellierung und Implementierung von Geschäftsprozessen. Daneben hat er einen Schwerpunkt auf (agile) Projektmanagementmethoden und Testmethoden gelegt.
ist Senior Consultant bei der Holisticon AG. Er ist Softwarearchitekt und Experte für Multiprojektmanagement. Dank seiner GPM/IPMA-Projektmanager-Zertifizierung und langjähriger Erfahrung mit der Architektur und der Entwicklung objektorientierter und komponentenorientierter verteilter Systeme verbindet er erfolgreich Führungsqualität in großen Projekten mit softwaretechnischer Expertise. Seit einigen Jahren beschäftigt er sich intensiv mit agilen Methoden und hat als Certified ScrumMaster und Certified Scrum Professional in der Praxis bewiesen, dass agile Methoden auch bei komplexen Architekturen der bessere Weg sind.
ist Senior Consultant bei der Holisticon AG. Er ist Certified Scrum-Master und seit über 10 Jahren als Business Analyst, Softwarearchitekt, Trainer, Coach und leitender Entwickler in IT-Projekten für überwiegend große Unternehmen tätig. Sein Fokus erstreckt sich von der technologischen Basis objekt-, komponenten- und serviceorientierter Architekturen für verteilte Unternehmensanwendungen über agile Softwareentwicklungsprozesse bis hin zur (Enterprise-) Architekturberatung. In seiner beruflichen Praxis hat Roman Schlömmer in diesen Bereichen häufig mit verteilten Teams in einem globalen, multikulturellen Umfeld gearbeitet.
ist Consultant bei der Holisticon AG. Sein Wissen erstreckt sich von den Technologien für objekt-, komponenten- und serviceorientierte Architekturen für verteilte Unternehmensanwendungen bis zur methodisch geführten Anforderungsanalyse. Dabei hilft ihm seine fundierte theoretische sowie praktische Erfahrung im Bereich der Qualitätssicherung von Softwareentwicklungsprojekten und der anwenderzentrierten Softwareentwicklung.
arbeitet als Consultant bei der Holisticon AG. Nach ersten Praxiserfahrungen im Bereich des E-Commerce und der wissenschaftlichen Tätigkeit am Lehrstuhl für Datenbank- und Informationssysteme der BTU Cottbus sowie einem Exkurs in die Automobilindustrie unterstützt er Unternehmen bei der Etablierung moderner Webtechnologien. Dabei konzentriert er sich auf die Themengebiete Web, E-Business und Portale. Als Mitglied der Expert Group für Contexts and Dependency Injection (CDI) im Java Community Process (JCP) gestaltet Norman Erck eine wichtige Java-EE-Technologie aktiv mit.
ist Consultant bei der Holisticon AG und seit mehreren Jahren als Softwareingenieur und Berater in IT-Projekten im Einsatz. Der Entwurf und die Umsetzung von komponentenbasierten, verteilten Systemen und stabilen Softwarearchitekturen, insbesondere im JEE-Umfeld, bilden den Schwerpunkt seiner Arbeit. Testgetriebene Entwicklung und agile Vorgehensweisen hat der Certified ScrumMaster bei verschiedenen namhaften Kunden mit Erfolg einsetzen und etablieren können.
Die Erstellung eines Buches kostet enorm viel Zeit, ist mühsam und zwischendurch immer mal wieder mit Rückschlägen verbunden (vor allem, wenn die Reviewer einem ganze Kapitel um die Ohren hauen). Umso wichtiger ist es, Menschen um sich zu haben, die einen dabei unterstützen.
Wir bedanken uns ganz herzlich bei allen Menschen, die uns – in welcher Form auch immer – bei der Erstellung dieses Buches geholfen haben. Unser Dank gilt
dem Team vom dpunkt.verlag, allen voran René Schönfeldt, für das Vertrauen in dieses Buchprojekt und die gute Zusammenarbeit,
Dierk Harbeck für seine Beiträge zur ersten Auflage, die in dieser zweiten Auflage weiterleben,
Jochen Jörg für die Ticket2Rock-Idee und die tatkräftige Unterstützung bei der Realisierung,
Simon Zambrovski für Ticket2Rock-Support und viele wertvolle Diskussionen, in denen er schonungslos die Sicht der Leser vertreten hat,
Jo Ehm für die Abbildungen, die dieses gehaltvolle Thema verständlich und ansprechend in Szene setzen und unumstritten mehr sagen als die berühmten tausend Worte,
allen aufmerksamen Lesern der ersten Auflage, deren Verbesserungsvorschläge und Fehlerkorrekturen in die zweite Auflage eingeflossen sind,
unseren Familien für ihr Verständnis und ihre Unterstützung.
Für Martina, Joshua, Julina, meinen Vater und Sven.
O.I.
Für Astrid, Mattis und Jasper.
S.M.H.
Für Andrea, Nele, Marit und Lotta.
H.K.
Für Britta
(für die Geduld und die gestohlene Zeit).
J.E.
Für Anni, Annii und Svenni, meine drei Großen,
und det kleene Krümelchen.
C.S.
Für Pubbi und Rona.
R.S.
Für Jaqueline, meine Eltern & Marie.
C.A.D.
Für meine Freunde
(die auch mal ohne mich das Nachtleben genießen konnten).
N.E.
Für Mama, Papa, Roland, Diana –
mein Herz, meine Freunde und meine Koautoren.
D.S.
Genau wie Softwareprogramme, so sind auch Bücher weder fehlerfrei, noch decken sie alle Ideen, Varianten oder Kniffe des jeweiligen Themas ab. Fehler kann man korrigieren. Was fehlt, kann man ergänzen oder nachtragen.
Sollten Sie Kommentare und/oder Anmerkungen zu diesem Buch haben, dann zögern Sie nicht, uns diese zukommen zu lassen. Über Rückmeldungen zum Buch oder zum Thema EJB 3 freuen wir uns sehr. Sie erreichen uns unter der E-Mail-Adresse post@ejb3buch.de
oder persönlich unter <vorname>.<nachname>@holisticon.de
.
»Wer’s nicht einfach und klar sagen kann, der soll schweigen und weiterarbeiten, bis er’s klar sagen kann.«
Karl R. Popper, »Gegen die großen Worte«
Enterprise JavaBeans (EJB) haben in den letzten Jahren weltweit eine enorme Verbreitung und vielfachen Einsatz bei der Entwicklung und dem Betrieb von sogenannten Enterprise-Applikationen1 gefunden. Sie haben sich als Mittel der Wahl für die Umsetzung von geschäftskritischen und hochlastfähigen betriebswirtschaftlichen Applikationen durchgesetzt. Das liegt vor allem am standardisierten, komponentenorientierten Programmiermodell. Enterprise JavaBeans sind Bestandteil der Java Platform, Enterprise Edition (Java EE). Die Ablaufumgebung für Enterprise JavaBeans ist ein EJB-Container. Dieser stellt eine Reihe von Diensten bereit: z.B. die Steuerung von gesicherten Zugriffen (Security Handling), konkurrierenden, parallelen Zugriffen (Concurrency Handling) und Transaktionen (Transaction Handling). Das befreit den Softwareentwickler von der Implementierung solcher Basisdienste. Er kann konfigurieren, wie seine Applikation diese Dienste nutzen soll, und sich ansonsten auf die Implementierung der Geschäftslogik konzentrieren.
Das J2EE2-Programmiermodell wurde seit dem Erscheinen der Version 1.0 im Jahre 1998 kontinuierlich weiterentwickelt. Mit der im Mai 2006 eingeführten Version 3.0 machte die EJB-Technologie einen großen Schritt in Bezug auf Einfachheit und Eleganz bei der Softwareentwicklung. Die Version 3.1 setzt diese Entwicklung konsequent fort. Aber werfen wir zunächst einen Blick zurück.
Die Entwicklung von Applikationen nach dem Programmiermodell früherer EJB-Versionen (bis zur Version 2.1) war alles andere als einfach. Die hohe Komplexität der EJB-Technologie verlangte nach fortgeschrittenen Softwareentwicklern mit einem soliden Verständnis von verteilten Softwaresystemen. Zweifelsohne stellte die EJB-Technologie einen Fortschritt gegenüber älteren, meist proprietären Konzepten dar. Doch je mehr Softwareentwickler auf diese neue Technologie setzten, desto lauter wurde auch die Kritik. In diesem Sinne ist eine deutlich erkennbare Kritik an einer Technologie allerdings auch immer ein Zeichen für eine breite Wahrnehmung und weite Verbreitung dieser Technologie.
Die wesentlichen Argumente von Kritikern der Enterprise JavaBeans bis zur Version 2.1 wollen wir hier kurz wiedergeben.
Hohes Maß an Komplexität
Die EJB-Technologie und ihre technischen Fragmente waren zu komplex. Dieser Kritikpunkt richtete sich vornehmlich gegen die Deployment-Deskriptoren. In diesen XML-Konfigurationsdateien wurden die Eigenschaften der Enterprise Beans sowie deren Zusammenspiel vollständig beschrieben. Aufgrund der Menge an Informationen, die für EJBs dort hinterlegt werden konnten bzw. mussten, wurden sie mit zunehmender Systemgröße immer unübersichtlicher. Eine manuelle Bearbeitung war bald kaum noch möglich. Auch die Spezifikation selbst trug mit einigen Ungereimtheiten zu diesem Umstand bei. So waren einige der vom Entwickler zu implementierenden Methoden in Schnittstellen vorgegeben, was eine Überprüfung bereits zur Übersetzungszeit ermöglichte. Andere Methoden des EJB-Frameworks waren hingegen in keiner Schnittstelle zu finden. Der Entwickler musste schlicht und einfach wissen, welche dieser Methoden in einem bestimmten Artefakt einer EJB-Komponente zu implementieren waren.
Fehlende Transparenz des Softwareentwurfs
Diese Komplexität der EJB-Technologie und ihrer Artefakte war der Grund dafür, dass sich der Entwurf von Softwaresystemen auf der Basis der EJB-Technologie äußerst schwierig gestaltete. Das Modell war für viele Softwarearchitekten nicht transparent und leichtgewichtig genug. Das erschwerte nicht zuletzt auch die Kommunikation untereinander sowie mit der Projektleitung und den Auftraggebern.
Viele Stolpersteine bei der Softwareentwicklung
Entsprechend schwierig und fehleranfällig gestaltete sich oftmals auch die Implementierung von EJB-basierten Softwaresystemen. Schreibfehler, vergessene Elemente in den komplexen Deployment-Deskriptoren, fehlende Implementierungen von Methoden, die zwar von der Spezifikation gefordert, aber in keinem Interface vorgegeben waren: All dies sorgte dafür, dass die Entwicklung von EJB-basierten Systemen einen steinigen Weg darstellte, der nur mit viel Erfahrung (und einem regelmäßigen Blick in Newsgroups und Internet-Foren) zu meistern war.
Ballaststoffreiche Kost
Hinsichtlich ihrer Mikroarchitektur zählten EJB-Komponenten zu den Schwergewichten der Branche. Um beispielsweise eine einfache fachliche Entität Konto abzubilden, war es notwendig, mindestens fünf Artefakte zu implementieren. Während bei der Ernährung eine ballaststoffreiche Kost durchaus positive Effekte hat, ist unnötiger Ballast in der Softwareentwicklung ein ernst zu nehmender Kostenfaktor – insbesondere in größeren Projekten.
Ungenügende Persistenzabbildung
Der Funktionsumfang der in der EJB-Spezifikation definierten Persistenzabbildung (Object-Relational Mapping, O/R-Mapping) reichte nicht einmal aus, um die gängigen praxisrelevanten O/R-Szenarien zu modellieren. Als Beispiel mag die Container-Managed Persistence (CMP) dienen. Der Entwickler konnte zwar deklarativ das O/R-Verhalten einer persistenten EJB-Entität festlegen, ohne auch nur eine Zeile Code dafür zu schreiben. Ein Multi-Table-Mapping, bei dem eine Entität (ein Objekt) auf mehrere Tabellen einer Datenbank verteilt ist, ließ sich mit den zur Verfügung stehenden Beschreibungsmitteln jedoch nicht ausdrücken. War dieses gefordert, so musste der Entwickler den entsprechenden Datenbankzugriff selbst implementieren.
Die genannte Kritik – insbesondere aus der Entwicklergemeinde – wurde im Rahmen des Java Community Process (JCP) gesammelt, konsolidiert und aufgearbeitet, um die beschriebenen Probleme zu beheben. Mit der als Java Specification Request (JSR) 220 entwickelten EJB-3.0-Spezifikation wurde mehr denn je den praktischen Erfahrungen der Entwicklergemeinde Rechnung getragen. Die EJB-Technologie wurde von Grund auf neu konzipiert, um die zum Teil gravierenden Unzulänglichkeiten der vorherigen Versionen zu beheben. EJB 3.0 verfolgte im Kontext von Java EE 5.0 als Hauptziel eine Vereinfachung auf ganzer Linie. Dieses bezog sich sowohl auf den Entwicklungsprozess und die Nutzung von EJB-Komponenten als auch auf deren Mikroarchitektur.
Von POJOs, POJIs und DI
Um dieses Hauptziel zu erreichen, sind etablierte Konzepte wie beispielsweise POJO (Plain Old Java Objects), POJI (Plain Old Java Interfaces) und Dependency Injection sowohl auf konzeptioneller als auch auf technologischer Ebene in die neue EJB-Komponententechnologie eingeflossen. Zu den weiteren Maßnahmen zur Vereinfachung gehören
die Reduzierung der benötigten Softwarefragmente je EJB-Komponente,
der Schritt zurück zu leichtgewichtigen Objekten (POJO/POJI) anstelle schwergewichtiger Komponenten,
die Verwendung von Annotationen,
eine komplett neu entwickelte Persistenzabbildung durch die Zusammenführung der »alten« EJB-Persistenzabbildung mit Konzepten aus JDO, Hibernate, Toplink und anderen Persistenzansätzen.
Investitionsschutz durch sanfte Migration
Natürlich müssen die über Jahre hinweg in den Unternehmen getätigten Investitionen in EJB-basierte Softwareprojekte geschützt werden. Auch erwarten Unternehmen und Entwickler, dass eine sanfte Migration auf EJB 3.x möglich ist. Deshalb sehen die EJB-3.x-Spezifikationen vor, dass die Programmierung gemäß den EJB-Vorgängerversionen auch in EJB-3.x-Containern weiterhin unterstützt wird.
Mit der Version 3.1 wurde die dritte Auflage der Enterprise JavaBeans mit Augenmaß und dem Fokus auf praktischer Relevanz weiterentwickelt. Zu den wichtigsten Weiterentwicklungen zählen
Singleton Session Beans,
asynchrone Session Beans,
der Wegfall des lokalen Business Interface,
die flexiblere Konfiguration nebenläufiger Prozesse,
mehr Möglichkeiten bei der Konfiguration von Timern,
EJB 3.1 Lite, eine Untermenge der EJB-APIs,
die Embeddable API, um Enterprise JavaBeans in einer Java-SE-Umgebung3 verwenden zu können.
Im Folgenden finden Sie eine Übersicht und eine kurze Beschreibung der einzelnen Buchkapitel. Die Kapitel in dieser Reihenfolge zu lesen, stellt aus unserer Sicht einen guten Weg dar, um sich mit der Thematik der Enterprise JavaBeans vertraut zu machen.
EJB 3.1 im Überblick
Eine weitere Orientierungshilfe beim Erarbeiten der EJB-3.1-Technologie und für ein besseres Verständnis der Zusammenhänge dürfte die Abbildung EJB 3.1 im Überblick sein, die Sie im vorderen Inneneinband dieses Buches finden. Sie zeigt die Zusammenhänge zwischen den einzelnen EJB-Elementen. Außerdem wollen wir an dieser Stelle auf unser EJB-3-Online-Glossar verweisen – im Internet zu finden unter http://www.ejb3buch.de/glossar
.
Die nachfolgenden Kapitel 2–18 dieses Buches lassen sich drei Themenbereichen zuordnen.
Architektur und Konzepte
Im ersten Teil des Buches (Kapitel 2 bis 4) bereiten wir die Grundlagen. Hier werden die Architekturaspekte, die grundlegenden Eigenschaften sowie die verwendeten Konzepte beschrieben. Nach der Lektüre dieses Themenbereichs können Sie souverän mit Begriffen wie POJO, POJI, Inversion of Control, Dependency Injection und Configuration by Exception jonglieren. Dafür ist dieser Teil allerdings deutlich theoretischer Natur. Lassen Sie sich davon aber nicht abschrecken. Denn erstens ist das Verständnis dieser Grundlagen die Voraussetzung für den erfolgreichen Entwurf und die Entwicklung von EJB-basierten Systemen. Und zweitens haben wir uns bemüht, die Theorie so lebendig wie möglich zu beschreiben und zu illustrieren.
EJB-Typen und Dienste
Der zweite Themenbereich (Kapitel 5 bis 15) umfasst die eigentliche EJB-Technologie. Hier werden die verschiedenen EJB-Typen und die angebotenen Dienste wie Transaktionalität, Sicherheit und Persistenzabbildung beschrieben, erklärt und in Beispielen veranschaulicht. Dieser Teil dient als Einführung, aber auch als Nachschlagewerk für den praktischen Einsatz.
CDI, Testen und Migration
Der dritte Teil (Kapitel 16 bis 18) widmet sich ergänzenden Themen wie dem Aufsetzen von Frontends auf eine EJB-Applikation, dem Testen von EJB-Komponenten innerhalb und außerhalb des EJB-Containers sowie der Migration von bestehenden J2EE-Systemen auf EJB 3.x. Hier lernen Sie also, wie Sie mit dem »Werkzeugkasten« EJB 3 tatsächlich Softwaresysteme entwerfen und entwickeln können.
Die Kapitel bauen in ihrer Reihenfolge thematisch aufeinander auf. Sachverhalte werden jeweils beim ersten Auftauchen ausführlich erklärt. In den folgenden Kapiteln werden Sie dann Querverweise auf solche grundlegenden Beschreibungen vorfinden. Ergänzungen oder Abweichungen bereits beschriebener Sachverhalte werden – wenn notwendig – an den entsprechenden Stellen beschrieben.
Dies ist eine Marginalie.
Die Marginalien am Seitenrand helfen Ihnen bei der schnellen Orientierung innerhalb eines Kapitels. Sie sind gewissermaßen der »rote Faden« durch das Kapitel. Sie werden feststellen, dass sie weniger beim ersten Lesen als vielmehr beim wiederholten Blick in das Buch von großem Nutzen sein können.
Kapitelaufbau
Die Kapitel im Buch sind generell gleich aufgebaut.
Kurz gefasst
Am Anfang eines jeden Kapitels finden Sie im Abschnitt »Kurz gefasst« eine Zusammenfassung der wesentlichen Inhalte und Ziele des Kapitels. So wissen Sie sofort, was Sie auf den kommenden Seiten erwartet – und sind hoffentlich motiviert, schnell weiterzulesen.
Der Blick zurück
Im darauf folgenden Abschnitt »Der Blick zurück« werden die mit den Inhalten des Kapitels korrespondierenden Konzepte aus den früheren EJB-Versionen kurz beschrieben und kritisch bewertet. Es wird deutlich, warum man in EJB 3.x für die Lösung bestimmter Probleme einen anderen Weg eingeschlagen hat. Außerdem lässt sich die »neue« Lösung besser bewerten, wenn man den »alten« Zustand kennt. Trotzdem kann dieser Abschnitt (zumindest beim ersten Lesen) auch von EJB-Neueinsteigern getrost übersprungen werden.
Checklisten
In vielen Kapiteln finden Sie eine oder mehrere Checklisten. Hier werden die wesentlichen Inhalte der in dem entsprechenden Kapitel vorgestellten Konzepte und Techniken zusammengefasst und (soweit möglich) in eine für den Softwareentwicklungsprozess geeignete Ablaufbeschreibung überführt. Diese Checklisten sind tatsächlich zum Abhaken gedacht. Wir haben mit dieser Form von Standardarbeitsanweisungen gute Erfahrungen gemacht. Sie geben einem das beruhigende Gefühl, nichts vergessen zu haben. Und man hat den Kopf frei für die wirklich wichtigen Dinge in der Softwareentwicklung.
Sie finden die Checklisten auch in elektronischer Form auf der begleitenden Website (siehe Abschnitt 1.6).
Dieses Kapitel lesen Sie gerade. Noch Fragen?
Dieses Kapitel beschreibt die architektonischen Grundlagen, Konzepte und Ansätze von EJB 3.x. Hier lernen Sie Inversion of Control, Dependency Injection und Annotationen kennen. Sie erfahren, was die Motivation für die Verwendung dieser Konzepte in EJB 3.0 bzw. EJB 3.1 gewesen ist. Und Sie bekommen einen ersten Vorgeschmack auf die Vorteile, die diese Konzepte in Bezug auf die Entwicklung und Nutzung von EJB-Komponenten bieten.
In diesem Kapitel lernen Sie die Koordinaten kennen, unter denen die EJB-Komponententechnologie im Java-EE-Universum zu finden ist. Da Konzepte und Modelle (d.h. die Makroarchitektur) allein nicht genügen, um eine Technologie zu definieren, stellen wir Ihnen die Datentypen und deren Zusammenspiel (d.h. die Mikroarchitektur) vor, die der Enterprise-JavaBeans-Technologie zu ihrem Namen verholfen haben. Diese EJB-Typen werden in den folgenden Kapiteln in aller Ausführlichkeit beschrieben und erläutert.