EJB 3.1 professionell (iX Edition) - Oliver Ihns - ebook

EJB 3.1 professionell (iX Edition) ebook

Oliver Ihns

0,0

Opis

Dieses Buch vermittelt Softwareentwicklern und -architekten sowie Projektleitern das notwendige Praxiswissen für die Entwicklung verteilter komponentenorientierter Systeme mit Enterprise JavaBeans 3.0. Geschrieben wurde es von erfahrenen Praktikern, unter ihnen ein Mitglied der EJB 3.1 Expert Group. Anhand praxisnaher Beispiele werden die Architektur sowie die zugrunde liegenden Konzepte beschrieben und illustriert. Weitere Themen sind projektrelevante Themen wie Security und Testen sowie Hinweise für die Migration existierender EJB-Applikationen.

Ebooka przeczytasz w aplikacjach Legimi na:

Androidzie
iOS
czytnikach certyfikowanych
przez Legimi
Windows
10
Windows
Phone

Liczba stron: 627

Odsłuch ebooka (TTS) dostepny w abonamencie „ebooki+audiobooki bez limitu” w aplikacjach Legimi na:

Androidzie
iOS



EJB 3.1 professionell

iX-EditionIn 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.

Oliver Ihns · Stefan M. Heldt · Holger Koschek · Joachim Ehm · Carsten Sahling · Roman Schlömmer

EJB 3.1 professionell

Grundlagen- und Expertenwissen zuEnterprise JavaBeans 3.1 – inkl. JPA 2.0

Unter Mitarbeit von Carl Anders Düvel, Norman Erck und Daniel Steinhöfer

2., aktualisierte und erweiterte Auflage

 

 

 

Lektorat: René SchönfeldtCopy-Editing: Ursula Zimpfer, HerrenbergHerstellung: Birgit BäuerleinUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

 

Bibliografische Information der Deutschen NationalbibliothekDie 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-3PDF 978-3-89864-851-6ePub 978-3-86491-025-8

2., aktualisierte und erweiterte Auflage 2011Copyright © 2011 dpunkt.verlag GmbHRingstraße 19 B69115 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

Inhaltsübersicht

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

Inhaltsverzeichnis

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

Vorwort

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.

Was ist neu in der zweiten Auflage?

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.1 Lite

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.

Session Beans

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.

Java Persistence API (JPA)

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.

Der Lebensraum der Enterprise Beans

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 Service

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.

CDI

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.

Testen von EJB-Komponenten

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.

Für wen ist dieses Buch?

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.

Von wem ist dieses Buch?

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

Oliver Ihns

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.

Stefan M. Heldt

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.

Holger Koschek

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).

Jo Ehm

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.

Carsten Sahling

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.

Roman Schlömmer

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.

Carl Anders Düvel

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.

Norman Erck

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.

Daniel Steinhöfer

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.

Danksagungen

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.

Widmung

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.

Ihre Kommentare und Anmerkungen

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 [email protected] oder persönlich unter <vorname>.<nachname>@holisticon.de.

1 Einleitung – Jetzt wird’s leicht!

»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.

1.1 Die Evolution der Enterprise JavaBeans

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.

1.1.1 Der Fluch der Komplexität

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.

1.1.2 Kritik an den früheren EJB-Versionen

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.

1.1.3 Ein neues Denken schafft eine neue Architektur

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.

1.1.4 Der konsequente nächste Schritt

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.

1.2 Aufbau des Buches

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.

1.2.1 Die Themenbereiche

Die nachfolgenden Kapitel 2–18 dieses Buches lassen sich drei Themenbereichen zuordnen.

Teil 1: Grundlagen – auch für EJB-Profis

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.

Teil 2: Technologie

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.

Teil 3: Ergänzende Themen

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.

1.2.2 Die Kapitel: Struktur und Inhalte

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).

Kapitel 1: Einleitung

Dieses Kapitel lesen Sie gerade. Noch Fragen?

Kapitel 2: Leichtgewichtige, POJO-basierte Enterprise-Applikationen

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.

Kapitel 3: EJB-Komponentenarchitektur

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.

Abgeschlossen wird dieses Kapitel durch die Darstellung der grundlegend verwendeten Kommunikationsmodelle sowie deren Auswirkungen auf Last, Performanz, Laufzeitverhalten und Architekturen von Applikationen.

Kapitel 4: EJB Lite – das abgespeckte EJB

Wem das Ganze noch nicht leichtgewichtig genug ist, für den hält die EJB-3.1-Spezifikation noch eine abgespeckte Version namens EJB Lite bereit. Der in diesem Kapitel vorgestellte reduzierte Funktionsumfang deckt die häufigsten Anwendungsfälle ab und erleichtert Produktherstellern die Integration der EJB-(Lite-)Technologie in ihre Produkte.

Kapitel 5: Session Beans

Session Beans sind die »Arbeitspferde« der EJB-Welt. Sie beschreiben fachliche Dienste (Services) oder ganze Geschäftsprozesse und transportieren Persistent Entities (Kapitel 8). Client-Applikationen können mit Session Beans in Interaktion treten. Auf diesem Weg erhalten sie auch Zugriff auf die Persistent Entities.

Dieses Kapitel beschreibt, wie der EJB-Container Session Beans verwaltet. Sie lernen die drei Typen von Session Beans (Stateless, Stateful und Singleton) und deren Einsatzbereiche kennen.

Kapitel 6: Session Beans als Webservice

In diesem Kapitel zeigen wir Ihnen, wie einfach es ist, die fachliche Schnittstelle einer Session Bean als Webservice zu veröffentlichen – eine einzige Annotation genügt. Nach einer kurzen Einführung in die Webservice-Technologie und die Benutzung eben jener Annotation zeigen wir Ihnen auch, wie Sie die Session-Bean-Webservices an Ihre speziellen Anforderungen anpassen können.

Kapitel 7: Message-Driven Beans

In vielen Informationssystemen findet die Kommunikation asynchron über den Versand von Nachrichten statt. Um solche Nachrichtensysteme (Message-Oriented Middleware, MOM) integrieren zu können, wurden in EJB 2.0 die Message-Driven Beans eingeführt. Diese unterstützten zunächst nur Nachrichtensysteme, die die standardisierte JMS API (Java Message Service) nutzen. Mit EJB 2.1 wurden die Message-Driven Beans dank der J2EE Connector Architecture (JCA) 1.5 offener im Umgang mit Nachrichtensystemen. Wir stellen Ihnen die Grundzüge der Message-Driven Beans aus dem EJB-3.1-Standard vor und zeigen, wie Sie diese mit einem Nachrichtensystem verbinden.

Kapitel 8: Entity Beans

Dies ist das kürzeste Kapitel im gesamten Buch – und das hat einen ganz einfachen Grund: Entity Beans gibt es in EJB 3.x nicht mehr. Diese Modelle für fachliche Entitäten firmieren jetzt unter dem Namen Persistent Entities. Kapitel 9 bietet einen detaillierten Einblick in das Leben dieser Objekte und die Mechanismen zur Persistenzabbildung.

Kapitel 9: Persistenzabbildung

Die persistente Abbildung der fachlichen Entitäten, z.B. in Datenbanksysteme, ist zweifelsohne der EJB-Themenbereich, der mit der Version 3.0 die radikalste Veränderung erfahren hat. Der EJB 3 Expert Group ist das Kunststück gelungen, die Persistenzabbildung in ihren Möglichkeiten zu erweitern, gleichzeitig aber den Umgang mit ihr zu vereinfachen. Da eine solch elegante Persistenzabbildung viel zu schade ist, um sie nur im Rahmen von EJB-Projekten zu nutzen, wurde sie so offen ausgelegt, dass sie nicht nur im gesamten Java-EE-Umfeld zum Einsatz kommen kann, sondern sogar für Java-SE-Applikationen verwendbar ist. Aus diesem Grund wurde die Persistenzabbildung in eine eigene (Teil-)Spezifikation namens Java Persistence API (JPA) ausgelagert. Parallel zu EJB 3.1 erschien die Java Persistence API in der Version 2.0.

Nach der Beschreibung der grundlegenden Annotationen zur Definition der Persistenzeigenschaften von Persistent Entities (ehemals Entity Beans) geht es ans Eingemachte: Mapping auf mehrere Datenbanktabellen, Vererbungsstrategien und Polymorphie, Abbildung von Objektbeziehungen, Fetching-Strategien und Transaktionssteuerung – nichts ist unmöglich.

Kapitel 10: JPA-Abfragen

Um ein solches kunstvoll aufgebautes Objektmodell nicht nur in die Datenbank hinein zu bekommen, sondern auch gezielt auslesen zu können, wartet EJB 3.1 mit einer umfangreichen, an SQL angelehnten Abfragesprache namens JPQL (Java Persistence Query Language) sowie der Criteria API auf, deren Details in diesem Kapitel enthüllt werden.

Kapitel 11: Der Lebensraum der Enterprise Beans

Wenn Sie mit EJB 3.x arbeiten, dann kommen Sie um die Verwendung von Annotationen kaum herum. Das Potenzial dieses mit Java 5.0 eingeführten Konzepts der deklarativen Programmierung wird in EJB 3 hervorragend ausgeschöpft. Neben der Festlegung der statischen Eigenschaften von Enterprise Beans dienen die Annotationen auch zur Festlegung von »Injektionszielen«, über die der EJB-Container Referenzen auf Ressourcen (z.B. Datenbankverbindungen) zur Laufzeit an einem EJB-Objekt applizieren kann. Dieses mächtige Konzept der Dependency Injection wird für die verschiedensten Ressourcentypen verwendet – und alle sind sie in diesem Kapitel beschrieben.

Kapitel 12: Callback-Mechanismen

Die Enterprise Beans führen im EJB-Container ein regelrechtes Eigenleben. Ihr Lebenszyklus ist von der Spezifikation detailliert vorgegeben. Ab und zu greift der EJB-Container in diesen Lebenszyklus ein. Um den Enterprise Beans ein Mitspracherecht bei der weiteren Lebensplanung einzuräumen, wurden für alle EJB-Typen spezielle Callbacks definiert. Diese Callbacks werden bei bestimmten Lebenszyklusereignissen aufgerufen. Eine Bean-Klasse kann diese Ereignisse abfangen und darauf reagieren. Wie das geht und wo das sinnvoll einzusetzen ist, erfahren Sie in diesem Kapitel.

Kapitel 13: Interzeptoren

Mit den Interzeptoren hält die aspektorientierte Programmierung (AOP) ein kleines Stück weit Einzug in die Welt der Enterprise Java-Beans. Ein Interzeptor wird für bestimmte (oder alle) Geschäftsmethoden oder Lebenszyklus-Callbacks definiert. Er wird immer unmittelbar vor der Ausführung dieser Geschäftsmethode bzw. des Lebenszyklus-Callbacks aufgerufen. Der Interzeptor kann dann eigenen Code ausführen und anschließend entscheiden, ob die Methodenausführung fortgesetzt werden soll.

In diesem Kapitel werden nicht nur die verschiedenen Arten von Interzeptoren vorgestellt, sondern auch eine Bewertung des Interzeptor-Mechanismus im Vergleich zu etablierten AOP-Frameworks vorgenommen.

Kapitel 14: Timer Service

Kaum ein größeres EDV-System kommt ohne sie aus: Die Batch Jobs – fleißige Helferlein, die automatisch zu vorgegebenen Zeitpunkten Routineaufgaben ausführen. Schon für CORBA gab es solche Systeme im Umfeld verteilter Systeme (COS Timer Event Service). Da scheint es nur allzu logisch, dass auch das EJB-Modell mit einer API für Timer Services aufwartet. In diesem Kapitel werden Sie sehen, wie Timer für Session Beans und Message-Driven Beans definiert werden können und was man mit ihnen anfangen kann.

Kapitel 15: Sicherer Zugriff auf EJB-Komponenten

Jeder, der sich heute im Internet bewegt, tut das (hoffentlich) mit der gebotenen Vorsicht, denn die Datendiebe lauern überall – und ihre Anzahl nimmt ständig zu. Je sensibler die Daten sind, desto mehr muss man sich vorsehen. Unternehmensdaten rangieren in puncto Gefährdungspotenzial und Schutzbedürfnis sehr weit oben auf der Skala. Gründe genug, um sich dem Thema Sicherheit ausführlich zu widmen. Glücklicherweise hat dies auch die EJB 3 Expert Group getan. Deshalb können wir Ihnen in diesem Kapitel die Möglichkeiten der deklarativen und programmgesteuerten Sicherheit sowie die in der EJB-Spezifikation beschriebenen Rollenkonzepte präsentieren. Natürlich stellen wir auch hier den Bezug zur Praxis her.

Kapitel 16: CDI (Web Beans)

Was bis jetzt nur mit der Unterstützung von Frameworks wie Spring möglich war, möchte EJB 3.1 nun auch alleine können: typsichere Dependency Injection von Managed Beans aller Art, innerhalb von Java-Kontexten, die über einen eigenen Lebenszyklus verfügen. Möglich macht’s die Contexts and Dependency Injection for Java EE (CDI). Deren Anwendungsfälle reichen von Unit-Tests bis hin zum JSF-Frontend. Dieses Kapitel stellt die neuen Konzepte und Sprachmittel vor, die dem Entwickler mit CDI zur Verfügung stehen, darunter Dependency Injection, Scopes und Contexts, Interzeptoren sowie Dekoratoren.

Kapitel 17: Testen von EJB-Komponenten

»Wer testet, der ist sich unsicher« – dieser Aussage möchten wir vehement widersprechen. Testgetriebene Softwareentwicklung ist nicht deswegen auf dem Vormarsch, weil sie besonders cool ist, sondern weil die Qualität der Softwaresysteme durch dieses Programmierparadigma entscheidend verbessert werden kann. Die älteren EJB-Versionen hatten jedoch den Nachteil, dass der Aufbau einer geeigneten Testumgebung ein schwieriges und aufwendiges Unterfangen war. Auch hier wird mit EJB 3 vieles besser. Dank Inversion of Control und Dependency Injection lassen sich die Enterprise Beans auch außerhalb des Containers testen. Wie das funktioniert, lesen Sie in diesem Kapitel.

Kapitel 18: Migration von EJB 2.x nach 3.x

Wenn Sie ein neues EJB-3.x-Projekt beginnen, ist alles ganz einfach. Was aber, wenn Sie bereits ein Softwaresystem haben, das auf einem älteren EJB-Modell basiert? Wie kann man dieses (möglichst schrittweise) migrieren, um die neuen Möglichkeiten von EJB 3.0 bzw. EJB 3.1 zu nutzen? Was genau hat sich verändert? Was muss man wie anpassen, um die Migration möglichst schnell und schmerzlos durchzuführen? Auf alle diese Fragen finden Sie in diesem Kapitel die passenden Antworten.

1.3 Konventionen

Kein Buch kommt ohne Konventionen aus. Auch dieses Buch stellt keine Ausnahme von dieser Regel dar. Warum auch – schließlich schreiben wir über eine Spezifikation, was nichts anderes ist als eine (ziemlich umfangreiche) Sammlung von Konventionen.

Die EJB-3.1-Spezifikation ist übrigens nicht für Softwareentwickler und Architekten geschrieben worden, sondern für die Hersteller von EJB-Containern. Deshalb liest sich die Spezifikation tatsächlich wie ein Regelwerk, das die Rechte und Pflichten des EJB-Containers sowie der an der Entwicklung und dem Betrieb von Enterprise-Applikationen beteiligten Akteure (genauer: deren Rollen) beschreibt.

Sollten Sie bis eben geglaubt haben, dass Sie eigentlich auch die Spezifikation hätten lesen können, so dürfen Sie nun tief durchatmen und mit dem guten Gefühl weiterlesen, dass der Kauf dieses Buches doch eine sinnvolle Investition war.

1.3.1 Notation

UML

In diesem Buch wird zur Darstellung von Sachverhalten, Szenarien, Anwendungsfällen und Modellen die Unified Modeling Language [UML] der Object Management Group (OMG) verwendet.

Wir haben uns für den Einsatz von UML entschieden, da sie die am weitesten verbreitete Notation zur grafischen Darstellung von Konzepten, Architekturen und Systementwürfen in der Softwaretechnik ist und sich in den letzten Jahren zu einem Industriestandard entwickelt hat. Als Einführungs- und Nachschlagewerk empfehlen wir Ihnen das UML-Buch von Bernd Oestereich [Oestereich09]. Es zeichnet sich durch seine Anwendungsnähe und die gelungene theoretische und praktische Aufarbeitung der UML aus und ist im deutschsprachigen Raum das Referenzwerk zu diesem Thema.

1.3.2 Literaturverweise bzw. Referenzen

Literatur

Die in diesem Buch verwendeten Literaturverweise bzw. Referenzen verweisen auf Ressourcen jeglicher Art – von Printmedien (Bücher, Zeitschriften) bis hin zu elektronischen Medien (Websites oder Verweise auf Dateien im Internet). Wir stellen Literaturverweise durch in eckigen Klammern eingeschlossene Bezeichner dar. Diese verweisen auf das Literaturverzeichnis am Ende dieses Buches.

1.3.3 Quellcode

Die in diesem Buch enthaltenen Code-Fragmente werden in der Schriftart Letter Gothic dargestellt (siehe Listing 1–1).

Quellcode im Internet

Die abgedruckten Code-Fragmente oder Listings stellen in der Regel nur Ausschnitte aus dem Quellcode unseres Beispiels dar (vgl. Abschnitt 1.4) und sind in dieser Form nicht direkt kompilierbar. Den vollständigen Quellcode finden Sie im Internet auf der dieses Buch begleitenden Website (vgl. Abschnitt 1.6).

Listing 1–1 Beispiel-Listing

1.3.4 Piktogramme

Zur schnellen und klaren Kennzeichnung bestimmter Sachverhalte oder um Sie auf bestimmte Dinge hinzuweisen, verwenden wir in diesem Buch die nachfolgend aufgeführten Piktogramme. Diese finden Sie immer in der Marginalspalte. Die entsprechend gekennzeichneten Praxishinweise, Hilfestellungen und Anmerkungen sollen Ihnen Unannehmlichkeiten, Probleme oder aufwendige Fehleranalysen ersparen. Es reicht, wenn Fehler und schmerzvolle Erfahrungen ein einziges Mal gemacht werden. Profitieren Sie von unseren Erfahrungen (schmerzwie freudvoller Natur), die wir in den vergangenen Jahren als Berater in vielen verschiedenen Softwareentwicklungsprojekten bei unterschiedlichen Kunden gesammelt haben.

Mit dem Piktogramm »Hinweis« weisen wir auf Textpassagen hin, die weiterführende Informationen enthalten oder Hintergrundwissen vermitteln.

Die mit dem Piktogramm »Achtung« markierten Abschnitte sollten Sie auf jeden Fall lesen. Hier beschreiben wir Fehlerfallen, wie sie wohl jede Technologie besitzt, und zeigen den richtigen Weg bzw. praktikable Lösungsansätze auf.

Sie erkennen wichtige Textpassagen auch an den grau hinterlegten Absätzen. Es lohnt sich, diese »grauen Kästen« genau zu studieren.

1.3.5 Verwendung von Anglizismen

Wie in vielen deutschsprachigen Fachbüchern, insbesondere im Bereich der Informatik, so stellt sich auch in diesem Buch die Frage des Umgangs mit englischen Fachbegriffen. Diese haben in den letzten Jahren verstärkt in den Sprachgebrauch Eingang gefunden.

Wir möchten und können an dieser Stelle keine Wertung darüber abgeben, ob es generell gut oder schlecht ist, englische Fachbegriffe in der deutschen Sprache einfach weiter zu verwenden.

In diesem Buch benutzen wir nur dann deutsche Übersetzungen der englischen Originalbegriffe, wenn es eine sinnvolle und allgemein anerkannte Übersetzung gibt. Wenn dies aus unserer Sicht bei bestimmten Begriffen nicht der Fall zu sein scheint, so verwenden wir die englischen Originalbegriffe.

Wir sind uns der Verantwortung gegenüber unserer Muttersprache durchaus bewusst und setzen uns gegen eine unnötige Verwässerung durch englischsprachige Begriffe ein. Auf der anderen Seite sind wir pragmatisch genug, um die Verwendung der in der deutschen IT-Welt etablierten englischsprachigen Begriffe zugunsten einer besseren Lesbarkeit und eines schnelleren Verständnisses zu befürworten. Wir hoffen, dass Sie sich mit diesem Kompromiss arrangieren können.

1.3.6 Gleichberechtigung in der Sprache

Frau und Mann

Zugunsten eines besseren Leseflusses und einer kurzen und prägnanten Schreibweise haben wir uns entschieden, für die in diesem Buch genannten fachlichen Rollen nur die maskuline Form zu verwenden, beispielsweise Projektleiter, Softwareentwickler oder Architekt. Gemeint sind damit aber stets beide Geschlechter. Wir hoffen, dass Sie, liebe Leserinnen, uns diese Vereinfachung nachsehen.

1.4 Die Beispielapplikation »Ticket2Rock«

Damit Sie die Materie schnell und sicher durchdringen können, wird Sie ein durchgängiges fachliches Beispiel durch dieses Buch begleiten. Wir haben eigens zu diesem Zweck eine Beispielapplikation entworfen: Ticket2Rock ist eine Webapplikation zum Bestellen von Tickets für Rockkonzerte. Jeder Themenkomplex im Buch wird durch Beispielcode aus dieser Applikation illustriert. Wir beschränken uns auf Ausschnitte aus dem Quellcode, um Ihnen das Blättern in seitenlangen Listings (die sowieso niemand liest) zu ersparen. Da Sie den kompletten Ticket2Rock-Quellcode von unserer Buch-Website herunterladen (siehe Abschnitt 1.6), übersetzen und ausführen können, lässt sich das in diesem Buch vermittelte Wissen sogleich am praktischen Beispiel ausprobieren. Zudem unterstützt Sie die Entwicklungsumgebung Ihres Vertrauens viel besser bei der Navigation im Quellcode, als wir das in gedruckten Listings jemals könnten.

Es soll nicht unerwähnt bleiben, dass die Beispielapplikation in erster Linie als »Proof of Concept« für die im Buch beschriebenen Konzepte und Technologien dient. Der fachliche Bezug macht das Beispiel zwar praxisnah, aber dennoch ist Ticket2Rock kein »fertiges« Ticketing-System. Da der Quellcode frei verfügbar ist, können Sie es aber gerne entsprechend erweitern.

1.4.1 Kurzbeschreibung

Ticket2Rock ist ein webbasiertes Softwaresystem zum Bestellen von Tickets für Rockkonzerte. Das System unterstützt

die Verwaltung von Interpreten (Musikern und Bands), deren Diskografie sowie ihrer Konzerte und Tourneen,

die Suche nach Interpreten, Musikalben, Songs, Konzerten und Tourneen,

den Verkauf von Konzerttickets,

die Stornierung gekaufter Konzerttickets,

die Erstellung von Auswertungen des Kaufverhaltens und Musikinteresses der Ticketkäufer.

Abb. 1–1 Die Beispielapplikation Ticket2Rock

1.4.2 Anwendungsfälle

Anwendungsfälle beschreiben den Funktionsumfang der Applikation (vgl. z.B. [Cockburn01] oder [Oestereich09]). Im folgenden Anwendungsfalldiagramm (Abb. 1–2) sind alle Akteure und Anwendungsfälle dargestellt.

Von den oben skizzierten Anwendungsfällen wollen wir nun exemplarisch einen genauer beschreiben. Wir haben uns für den Anwendungsfall Tourneen verwalten entschieden. Die anderen Verwaltungsanwendungsfälle sind ähnlich aufgebaut. Die Anwendungsfälle zur Suche müssen wohl kaum näher erläutert werden. Ebenso wollen wir auf die Beschreibung von Ticketkauf und -stornierung an dieser Stelle verzichten – schließlich wollen wir Ihnen vor allem den professionellen Umgang mit EJB 3.1 zeigen.

Tourneen verwalten ist ein gruppierender Anwendungsfall, dessen Verfeinerung in Abbildung 1–3 grafisch dargestellt ist. Diese UMLDarstellung wird in der Praxis in einer textuellen Beschreibung weiter detailliert. Hier werden Vor- und Nachbedingungen genannt und die einzelnen Schritte bei der Abarbeitung des Anwendungsfalls beschrieben. Der Aufbau solcher Anwendungsfallbeschreibungen ist in [Cockburn01] ausführlich und praxisnah dargestellt.

Abb. 1–2 Anwendungsfalldiagramm der Beispielapplikation Ticket2Rock

Abb. 1–3 Verfeinerung des Anwendungsfalls »Tourneen verwalten«

1.4.3 Fachliche Entitäten

Nachdem die Anwendungsfälle definiert sind, wissen Sie nun, was das Ticket2Rock-System leisten soll. Noch nicht bekannt sind jedoch die fachlichen Entitäten, die das System erzeugen, sondieren, verändern und vor allem speichern soll. Diese Entitäten wollen wir im Folgenden beschreiben. Dabei sind die Namen aller fachlichen Entitäten kursiv gesetzt. Im UML-Klassendiagramm (Abbildung 1–4) sind zudem die Beziehungen zwischen den Entitäten dargestellt.

Um das Modell so schlank (und somit so verständlich) wie möglich zu halten, haben wir einige Vereinfachungen vorgenommen, die den Anforderungen der realen Welt nicht standhalten. So wird ein Album in unserem Modell von genau einem Interpreten veröffentlicht. Wer braucht schon Compilations und Soundtracks? Auf der anderen Seite haben wir versucht, so viele »typische« Objekttypen und Objektbeziehungen wie möglich im Modell zu versammeln, um Ihnen im Beispielcode realitätsnahe Vorlagen zu bieten, die sich leicht wiederverwenden lassen. Deshalb finden Sie viele Informationen rund um die Konzerte und ihre Interpreten, die man eher in Applikationen wie Apples iTunes erwarten würde.

Abb. 1–4 Klassendiagramm der Ticket2Rock-Entitäten

Interpret

Ein Interpret ist ein Musiker oder eine Band. Ein Interpret besitzt einen Namen. Er veröffentlicht einen oder mehrere Songs. Ein Interpret kann Konzerte geben (eventuell im Rahmen von Tourneen) und Alben veröffentlichen.

Musiker

Ein Musiker ist ein Interpret, der Mitglied einer oder mehrerer Bands sein kann.

Band

Eine Band ist ein Interpret. Sie besteht aus mehreren Musikern.

Musikgenre

Ein Musikgenre steht für eine bestimmte Musikrichtung.

Song

Ein Song ist ein Musikstück, das von einem Interpreten veröffentlicht wird. Ein Song hat einen Titel und kann einem Musikgenre zugeordnet werden. Ein Song kann Bestandteil eines Albums sein.

Album

Ein Album ist eine Zusammenstellung von Songs eines Interpreten. Es hat einen Titel und ein Erscheinungsdatum.

Konzert

Ein Konzert ist eine Veranstaltung eines Interpreten, die von einem Veranstalter organisiert wird. Ein Konzert findet zu einem bestimmten Datum an einem Veranstaltungsort statt. Für ein Konzert wird ein Kontingent von Tickets festgelegt.

Veranstaltungsort

An einem Veranstaltungsort finden Konzerte statt. Ein Veranstaltungsort hat einen Namen und eine Adresse. Er fasst eine bestimmte Anzahl von Besuchern.

Veranstalter

Ein Veranstalter organisiert Konzerte.

Tournee

Im Rahmen einer Tournee werden von einem Interpreten eines oder mehrere Konzerte durchgeführt. Eine Tournee hat einen Namen.

Ticketbestellung

Zum Besuch eines Konzerts benötigt man ein Ticket. Ein Kunde kann über Ticket2Rock ein oder mehrere Tickets für ein bestimmtes Konzert bestellen. Diese Ticketbestellung kann später unter Angabe der Bestellnummer storniert werden.

Kunde

Ein Kunde von Ticket2Rock wird aus Vereinfachungsgründen nur über eine E-Mail-Adresse identifiziert.

News

Hinweise auf neue Konzerte werden als News in Ticket2Rock angezeigt.

1.5 Verwendete Technologien und Produkte

Java 6

Da EJB 3.1 auf Java 6 aufsetzt, ist diese Version auch Voraussetzung für die im Buch verwendeten Beispiele.

JBoss-Applikationsserver

Als Java-EE-Applikationsserver setzen wir den JBoss Application Server 6 ein. JBoss ist ein mächtiger und leistungsfähiger, frei verfügbarer Java-EE-Applikationsserver. Als erster Open-Source-Applikationsserver hat er seinerzeit die Kompatibilität zu J2EE 1.4 (und somit auch zu EJB 2.1) bescheinigt bekommen. Weitere Informationen finden Sie unter [JBossAS].

Glassfish

Wenn Sie lieber mit einem anderen Applikationsserver arbeiten möchten, dann empfehlen wir Ihnen die zurzeit größte »Konkurrenz« aus dem Open-Source-Lager: [Glassfish] ist die Referenzimplementierung für Java EE 6 und die Java Persistence API. Wir haben Glassfish nur sporadisch verwendet, um die JBoss-Implementierung bestimmter EJB-3.1-Funktionen zu verifizieren.

JavaServer Faces für das Frontend

Das Frontend für Ticket2Rock haben wir auf Basis von JavaServer Faces [JSF] realisiert. Dieses Framework für die Entwicklung von Webapplikationen wurde im Rahmen des Java Community Process (JCP) als Java Specification Request (JSR) 127 entwickelt. Die JSFArchitektur folgt dem Model-View-Controller-Konzept. Dementsprechend sind JSF-Applikationen komponentenorientiert und gut strukturiert.

MagicDraw

Als UML-Modellierungswerkzeug verwenden wir MagicDraw UML von der Firma No Magic, Inc. (http://www.magicdraw.com). Sämtliche UML-Diagramme in diesem Buch sind mit MagicDraw erstellt worden. An dieser Stelle möchten wir uns bei No Magic für die sehr gute, fruchtbare und unkomplizierte Zusammenarbeit bedanken.

1.6 Die Website zum Buch

Wir betreiben begleitend zu diesem Buch eine Website. Auf dieser finden Sie

den kompletten Quellcode der Beispiele in diesem Buch,

die Checklisten in elektronischer und gegebenenfalls aktualisierter Form,

ein EJB-3-Glossar,

Errata,

eine Möglichkeit, mit den Autoren Kontakt aufzunehmen,

sowie allerhand Neues und Wissenswertes rund um EJB 3.

Die Website zum Buch ist unter folgender Adresse erreichbar:

http://www.ejb3buch.de

1. Den Begriff der Enterprise-Applikationen erklären wir im folgenden Kapitel.

2. Java 2 Platform, Enterprise Edition; der Name wurde später vereinfacht zu Java Platform, Enterprise Edition (Java EE).

3. Java Platform, Standard Edition (Java SE)

Teil I

Grundlagen

2 Leichtgewichtige, POJO-basierte Enterprise-Applikationen

»Der Wert eines Dialogs hängt vor allem von der Vielfalt der konkurrierenden Meinungen ab.«

Karl R. Popper

2.1 Kurz gefasst

Dieses Kapitel beschreibt die architektonischen Grundlagen von EJB 3.x sowie die verwendeten Konzepte – darunter Inversion of Control, Dependency Injection, Configuration by Exception und Annotationen. Diese Konzepte sind die Zutaten für die Entwicklung von leichtgewichtigen, POJO-basierten Enterprise-Applikationen auf Basis der EJB-3.x-Technologie.

Wir beschreiben die technischen Aspekte, die hinter diesen Konzepten stehen, motivieren deren Einsatz und erläutern die Auswirkungen auf die EJB-Softwareentwicklung und das Laufzeitverhalten von EJB-Komponenten (bzw. dessen Steuerung). Klingt komplizierter, als es tatsächlich ist.

2.2 Der Blick zurück

Geht man der Frage nach, warum die oben aufgeführten Konzepte erst mit der Version 3.0 in der EJB-Technologie verankert wurden, so lassen sich im Wesentlichen zwei Gründe anführen: Einige der Konzepte gab es zum Zeitpunkt des Erscheinens der EJB-2.x-Versionen noch gar nicht. Andere wurden bei der Definition der EJB-2.x-Spezifikationen schlichtweg nicht berücksichtigt.

Neben dem einen oder anderen Ansatz, der damals noch nicht State of the Art (zumindest für die EJB-Technologie) gewesen ist, haben sich über die Zeit neue Ansätze und Erkenntnisse entwickelt.

Ausgehend von der praktischen Erfahrung mit der EJB-2.x-Technologie, wurden im Laufe der Zeit eine Reihe von Anforderungen, Wünschen und Ansprüchen an die EJB-Technologie gerichtet: Einfachere Nutzung, Reduzierung unnötiger Aufwände bei der Programmierung sowie eine mächtigere und zugleich einfacher bedienbare Persistenzabbildung waren die »Top 3« dieser Wunschliste. In der Tat: Die Mikroarchitektur von EJB-2.x-Komponenten war zu komplex. Es existierten zu viele Fragmente, die in Korrelation gebracht werden mussten. Deployment-Deskriptoren waren sehr komplex. Entity Beans (persistente EJB-Komponenten) besaßen eine komplizierte Persistenzabbildung, der zudem noch Eigenschaften wie Vererbung oder Multi-Table-Mapping1 fehlten. Es gab also ein enormes Verbesserungspotenzial.

2.3 Einleitung

Objektorientierung

Die Objektorientierung an sich ist etwas Feines. Man bildet die Umwelt (zumindest einen fachlichen Ausschnitt) auf objektorientierte Modelle (Klassen, Schnittstellen, Beziehungen) ab. Um Beziehungen und Eigenschaften zu modellieren, nutzt man Vererbung, Polymorphie, Delegation und weitere schöne Konzepte, die einem die Objektorientierung zur Verfügung stellt. Die Programmiersprache Java bietet die technischen Möglichkeiten, um solche objektorientierten Modelle relativ leicht umzusetzen, ohne dabei so ein tief gehendes technisches Verständnis wie bei der Programmierung in C++ zu benötigen. Das ist auch einer der Gründe dafür, dass Java eine solch große Verbreitung erfahren hat.

Irgendwann stellt man fest, dass die Klassen, die man entworfen und implementiert hat, aus den verschiedensten Gründen Aspekte wie Sicherheit, Transaktionalität, Nebenläufigkeit oder dynamische Lastverteilung aufweisen sollen. Hier treten Komponentenmodelle wie Enterprise JavaBeans auf den Plan, die eben solche Aspekte mit sich bringen und dem Entwickler einen großen Teil der Entwicklungsarbeit für diese technischen Aspekte abnehmen.

Die EJB-Idee

Die Idee bei der EJB-Technologie war und ist, im Rahmen der Java-EE-Technologie Komponenten zur Verfügung zu stellen, die dem Entwickler die Pflicht und den Aufwand zur Implementierung von infrastrukturellem Code abnehmen und die den Anforderungen an Enterprise-Applikationen (siehe folgenden Abschnitt) gerecht werden. Der Einsatz der EJB-Technologie soll zu kürzeren Entwicklungszeiten für neue Applikationen führen und gleichzeitig die Qualität der Applikationen steigern, da ein signifikanter Anteil des Programmcodes nicht mehr implementiert werden muss, sondern von der EJB-Technologie beigesteuert wird. Diese Vision ist Realität geworden. Die EJB-Container stellen eine Menge dieser Dienste zur Verfügung, und die EJB-Komponenten, die innerhalb der EJB-Container ausgeführt werden, sind entsprechend mächtig in ihrem Leistungsumfang.

EJB 2.x ist zu einfach und zu schwergewichtig.

So weit, so gut. Allerdings stellten EJB-2.x-Komponenten zum einen elementare Merkmale der Objektorientierung, wie beispielsweise Vererbung und Polymorphie, aus technologischen bzw. architekturbedingten Gründen nicht oder nur eingeschränkt zur Verfügung.

Zum anderen wird wohl jeder, der sich bereits in der Anwendung der EJB-2.x-Technologie versucht hat, eine negative Bewertung abgeben, wenn es um den Aufwand, die Anwendbarkeit und Komplexität sowie die Fehleranfälligkeit bei der Entwicklung von EJB-Komponenten geht.

Strukturell betrachtet waren EJB-Komponenten der Vorgängerversionen (vor EJB 3.0) weit davon entfernt, das Attribut »einfach« verliehen zu bekommen. Für eine EJB-Komponente waren in der Regel mindestens fünf Softwareartefakte notwendig. Damit einhergingen ein erheblicher Entwicklungsaufwand, eine hohe inhärente Komplexität der Komponenten, höhere Fehleranfälligkeit bei der Implementierung und eine Menge rein infrastrukturellen Codes. Genau diese Eigenschaften der EJB-Komponenten waren es, die der EJB-Technologie das Attribut »schwergewichtig« einbrachten.

Unzufriedenheit und neue Ansätze

Die zuvor genannten Nachteile führten in der Entwicklergemeinde zu einer latenten Unzufriedenheit gegenüber der EJB-Technologie. Die Vorteile dieser Komponenten und die Dienste, die der EJB-Container anbot (beispielsweise Concurrency Handling, Instance Pooling, Security Handling und Transaktionssteuerung) erkaufte man sich mit den oben erwähnten Nachteilen. Da die kommerzielle Softwareentwicklung sehr stark vom Faktor Zeit getrieben ist, war dies zunehmend nicht mehr akzeptabel.

Leichtgewichtige Ansätze

Mit der Zeit entstanden parallel zur EJB-Technologie die sogenannten leichtgewichtigen Ansätze. Der Unterschied lag zum einen darin, dass hierbei einfache Java-Klassen anstelle von komplexen Komponenten verwendet wurden. Zum anderen waren die Container, in denen diese leichtgewichtigen Objekte lebten, ebenfalls leichtgewichtig in dem Sinne, dass sie nur mit den nötigsten Funktionen ausgestattet waren. Nicht alle Applikationen benötigen den Funktionsumfang der großen Applikationsserver. Die meisten Applikationen kommen mit kleinen, leichten und nicht so umfangreich ausgestatteten Containern aus.

Dieser Gegensatz von schwergewichtig und leichtgewichtig übte letztlich einen zunehmenden Druck auf die EJB-Technologie (siehe auch [Ihns05]) und auf die gesamte J2EE-Plattform aus. Dieser Druck führte zur Entwicklung der J2EE-Nachfolgeversion Java EE 5. Ein Bestandteil dieser Plattform ist EJB 3.0. Als Ziel für die gesamte Java-EE-Plattform und erst recht für das EJB-Komponentenmodell wurde der Wechsel von einem schwergewichtigen zu einem leichtgewichtigen Modell vorgegeben – unter der Maßgabe, nicht im Leistungsumfang abzuspecken, sondern das Leistungsvermögen dabei noch zu steigern.

EJB 3.x ist leichtgewichtig.

Seit EJB 3.0 sind EJB-Komponenten nun endlich leichtgewichtig. Auf der Ebene des Java-Quellcodes können sie sich jetzt mit den konkurrierenden leichtgewichtigen Ansätzen wie [Spring] oder [Hibernate] messen. Die Mikroarchitektur ist sehr einfach gehalten: EJB-3.x-Komponenten bestehen nur noch aus einer einfachen Java-Klasse (Plain Old Java Object, POJO) und einem einfachen Java-Interface (Plain Old Java Interface, POJI). Damit entfallen die Hauptkritikpunkte, EJB-Komponenten seien zu komplex und ihre Mikroarchitektur zu kompliziert. Die Merkmale leichtgewichtiger Ansätze lassen sich jetzt im Wesentlichen auch auf EJB-Komponenten übertragen.

EJB 3.x hat Charme.

Gleichzeitig – und das hat einen gewissen Charme – offerieren EJB-3.x-Komponenten Funktionen wie beispielsweise Transaktionsverwaltung, Concurrency Handling und Security Handling, die man bis dato nur von den schwergewichtigen Komponenten kannte. Man hat es also tatsächlich geschafft, leichtgewichtige Objekte bzw. Komponenten mit dem Funktionsumfang von schwergewichtigen Komponenten zu verbinden. Das ist der große Vorteil von EJB 3.x im Vergleich zu den sehr leichtgewichtigen Ansätzen. Dort ist der Entwickler nämlich gezwungen, die genannten Funktionen bei Bedarf selbst zu implementieren oder aus verschiedenen Produkten und Frameworks zusammenzusetzen. Der Programmieraufwand steigt und mit ihm die Gefahr eines instabilen (weil zusammengesetzten) Systems. Ob diese Lösung dann einem Best-of-Breed-Ansatz entspricht, ist stark abhängig vom Wissen und der Erfahrung derjenigen, die diese Aspekte selbst implementiert oder ausgewählt haben.

Objektorientierung, wir kommen!

In der Reihe der EJB-Versionen stehen ab EJB 3.0 erstmals alle elementaren Merkmale der Objektorientierung zur Verfügung. Vorher hatte die EJB-Technologie Probleme mit Vererbung und Polymorphie, was den Freiheitsgrad bei der Objektmodellierung stark einschränkte. Da mit EJB 3.x die Komponenten elementar aus POJOs und POJIs bestehen, sind EJBs nun in der Lage, mit den eigentlich üblichen objektorientierten Aspekten wie Vererbung, Polymorphie und Delegation umzugehen. Dies führt dazu, dass sauber modellierte Klassenmodelle ohne technische Einschränkungen in EJB-Komponentenmodelle überführt werden können.

Enterprise-Applikationen

EJBs sind nicht dafür gedacht, um mal eben eine kleine dynamische Website zu basteln oder die klassische Adressverwaltung zu implementieren. Wer diese Technologie zu einem solchen Zweck verwendet, der darf sich nicht wundern, dass die Entwicklung solcher Applikationen viel zu lange dauert und nicht so leichtgewichtig erscheint.

EJBs sind für die Entwicklung und den Betrieb von Enterprise-Applikationen ausgelegt. Darunter verstehen wir Applikationen mit einer großen Anzahl an Benutzern und hohem Lastaufkommen in heterogenen Systemlandschaften, die QoS2-Aspekte wie hohe Transaktionalität, Sicherheit, Abbildung komplexer Datenbankmodelle, Ausfallsicherheit, Lastverteilung und Skalierbarkeit aufweisen.

2.4 Hauptziele für EJB 3.x

Sie haben gesehen, dass die EJB-Version 2.1 und ihre Vorgängerversionen einige Nachteile hatten. Diese wollte man mit der Version 3.0 endgültig ausräumen. Zunächst aber sollten die Motive und die Ziele für eine neue EJB-Version konkret formuliert werden, bevor sich die Expert Group an die Spezifizierung machte. In diesem Abschnitt wollen wir Ihnen die Hauptziele von EJB 3.x ausführlich vorstellen. Anschließend können Sie losgehen und Ihre Kollegen von den Vorteilen der EJB-3.x-Technologie überzeugen. Übrigens haben sich die Hauptziele mit dem Versionswechsel von 3.0 auf 3.1 nicht verändert. Es gibt zwar ein paar erwähnenswerte Neuerungen in EJB 3.1, die wir in diesem Buch selbstverständlich vorstellen. Die grundsätzliche Architektur und Ausrichtung bleibt jedoch unverändert.

2.4.1 Motive

Einige der hauptsächlichen Motive für die Entwicklung von EJB 3.0 und Java EE 5 haben wir weiter oben bereits genannt. Es ging darum, die Entwicklung von Java-EE- bzw. EJB-basierten Applikationen deutlich zu vereinfachen, zu beschleunigen und die Komplexität der Technologie zu reduzieren.

Microsoft .NET

Ein weiteres nicht zu vernachlässigendes Motiv ist die zunehmende Präsenz der .NET-Entwicklungsplattform von Microsoft, die zugegebenermaßen eine erheblich schnellere und einfachere Entwicklung von Applikationen aller Größenordnungen erlaubt. An dieser Stelle werden wir keinen dogmatischen Streit entfachen, welche Technologie-plattform die bessere aus Sicht der Softwarearchitektur und des Entwicklungsprozesses ist. Schauen wir uns lieber die Ziele an, die mit EJB 3.x verfolgt und umgesetzt worden sind.

2.4.2 »Einfach machen!«