Click here for the english version

C     nach oben

Callback-Methoden

EJB 2.x
EJB 3.0

Bei EJB 2.x wird bei der Implementierung der Bean-Klasse einer EJB-Komponente verlangt, dass diese Klassen entsprechend dem Typ der EJB-Komponente das entsprechende Callback Interface (@javax.ejb.SessionBean, javax.ejb.MessageDrivenBean oder javax.ejb.EntityBean@) implementiert. Zum Einen kennzeichnen diese Interfaces, um was für einen Typ einer EJB es sich handelt. Zum Anderen definieren diese Interfaces Callback-Methoden, die vom EJB-Container im Lebenszyklus einer EJB-Komponente aufgerufen werden. Der Entwickler ist verpflichtet, die im jeweiligen Interface deklarierten Callback-Methoden in seiner Bean-Klasse zu implementieren.

Bei EJB 3.0 müssen die zuvor genannten Callback Interfaces nicht mehr von der Bean-Klasse implementiert werden. Dies führt zu einer Reduzierung von Entwicklungszeiten und -aufwänden. Um zu ermöglichen, sich in den Ablauf der Steuerung des Lebenszyklus einer EJB-Komponente einzuklinken, gibt es ein Set von vordefinierten Meta-Annotationen. Diese erlauben, beliebige Methoden in der Bean-Klasse zu kennzeichnen, sodass diese in Abhängigkeit der verwendeten Meta-Annotation zu definierten Zeitpunkten aufgerufen werden. Angewendet werden können diese Meta-Annotationen auf alle EJB-Typen. Für das Einklinken in die Steuerung des Lebenszyklus von Session Beans und Message-driven Beans stehen die Meta-Annotationen @PostConstruct, @PreDestroy, @PostActivate und @PrePassivate zur Verfügung. Für das Einklinken in die Steuerung des Lebenszyklus von EJB 3 Entitys stehen folgende Meta-Annotationen zur Verfügung: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpate, @PostLoad.

CMP

EJB 2.x

Akronym für Container-managed Persistence

Component Interface

EJB 1.x
EJB 2.x

Das Component Interface ist die Geschäftsschnittstelle einer EJB-Komponente vor EJB 3.0. Diese kann es in zwei Ausprägungen geben: als lokale Schnittstelle (Zugriffe sind hierbei nur innerhalb des selben Prozesses möglich --> siehe Local Interface) und/oder als remote Schnittselle (hierbei können die Client über Rechner- und Prozessgrenzen hinweg auf die EJB-Komponente zugreifen --> siehe Remote Interface). Ein Component Interface muss zwangsweise von EJB[Local]Object erben.

Configuration by Exception

EJB 3.0

Der Configuration by Exception-Ansatz ist mit EJB 3.0 eingeführt worden. Ziel dieses Ansatzes sind die Minimierung und die Reduzierung von Entwicklungszeiten und Aufwänden für die Konfiguration bzw. Entwicklung von EJB-Komponenten. Der Entwickler soll nur noch in Ausnahmefällen (daher: Configuration by Exception) konfigurierende oder laufzeitsteuernde Angaben für eine EJB-Komponente vornehmen müssen. Nämlich nur in den Fällen, in denen das gewünschte Verhalten von dem definierten und vorgegebenen Standardverhalten für EJB-Komponenten eines Typs abweicht. Es wird also das Ziel verfolgt, die Notwendigkeit der expliziten Angabe von Konfigurationsparametern für allgemein gültiges, erwartetes Verhalten von EJB-Komponenten und Anforderungen an den EJB-Container zu minimieren bzw. zu reduzieren.

Konkret bedeutet dies, dass mit EJB 3.0 eine Menge von Funktionalitäten bzw. Verhaltensweisen von EJB-Komponenten per default voreingestellt sind. Dieses Defaultverhalten sollte den Großteil (80-90%) der typischen Anwendungsfälle der EJB-Komponenten (bzw der jeweiligen EJB-Typen) abdecken. Trifft das Standardverhalten nicht das Anforderungsprofil, dann kann der Entwickler diese Standardwerte bzw. das Standardverhalten leicht übersteuern. Als Beispiel dafür sei angeführt, dass EJB 3 Entitys per default einen Eager Load-Mechanismus verwenden. Will der Entwickler Lazy Load als Fetching-Strategie verwendet haben, muss er dieses explizit angeben.

Container-managed Persistence

EJB 2.x

Einer der beiden Persistenzmechanismen für Entity Beans vor EJB 3.0. In EJB 3.0 gibt es den Begriff Container-managed Persistence so nicht mehr.

Bei der Verwendung von Container-Managed Persistence (CMP), brauchen Sie als Entwickler die Logik zur Synchronisation zwischen Entity Beans und Persistenzschicht nicht zu implementieren. Sie wird durch Werkzeuge des Applikationsservers generiert. Die Aufgabe des Entwicklers beschränkt sich auf die Deklaration der persistenten Attribute sowie der Beziehungen zwischen Entity Beans. Die Synchronisation zur Laufzeit wird durch einen speziellen Teil des EJB-Containers - den so genannten Persistenz-Manager - sichergestellt.