Home
Über uns
Kontakt

Meldungen
Links

Bücher
Artikel
Rezensionen
Poster
Vorträge

Architekturen &
  Muster
Performanz &
  Skalierbarkeit
EJB
CORBA
SOA

EJB 1.x
EJB 2.x
EJB 3.0

Einer der beiden Persistenzmechanismen für Entity Beans vor EJB 3.0

Bei den Entity Beans, die Bean-Managed Persistence (BMP) verwenden, sind Sie als Entwickler dafür verantwortlich, diese Aufgabe durch Implementierung des entsprechenden Java-Codes zu lösen. Das bedeutet im Wesentlichen, dass der Entwickler die persistenten Attribute der Entity Bean in geeigneter Weise der Persistenzschicht (z.B. den Feldern einer Datenbanktabelle) zuordnen muss. Hierzu implementiert er die Logik für den Zugriff auf die Per-sistenzschicht (z.B. Datenbank per JDBC oder Legacy-System wie SAP per JCA ) in der Bean-Klasse.

• Der EJB-Container entscheidet, wann etwas passiert.
• Der Entwickler entschiedet, was passiert

Bei EJB 2.x wird bei der Implementierung der Bean-Klasse einer EJB-Komponente verlangt, dass eben 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. Da man nun nicht mehr gezwungen ist, die entsprechenden Callback-Methoden zu implementieren, führt dies zu einer Reduzierung von Entwicklungszeiten und -aufwänden. Um es 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 Entity Beans stehen folgende Meta-Annotationen zur Verfügung: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpate, @PostLoad.

Das Component Interface ist die Geschäftsschnittstelle einer EJB-Komponente. 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).

Einer der beiden Persistenzmechanismen für Entity Beans vor EJB 3.0

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 Attributen sowie der Beziehungen zwischen Entity Beans. Die Synchronisation zur Laufzeit wird durch einen speziellen Teil des EJB-Containers - den sogenannten Persistenz-Manager - sichergestellt.

EJB 1.x
EJB 2.x
EJB 3.0

Der Begriff Dependency Injection (DI) ist eine spezialisierte Version des Inversion of Control-Musters. Martin Fowler hat diesen Begriff in http://martinfowler.com/articles/injection.html eingeführt, da die Charakteristik der Verwendung der Inversion of Control in den aktuell in den Medien stark vertretenen leichtgewichtigen Container/Frameworks eher den Charakter der Injektion von Referenzen über benötigte Objekte/Klasse hat.

Dependency Injection bedeutet konkret für die EJB-Technologie, dass der Entwickler zukünftig nicht mehr den Code für den Erhalt von Referenzen auf Ressourcen implementieren muss und die EJB-Komponente damit aktiv den sie umgebenden Container fragt, sondern der Entwickler nur noch per Meta-Annotation die Stellen in der EJB-Komponente "markiert", in die der EJB-Container von außen die gewünschten Referenzen in die EJB-Komponente injiziert.

Die Java EE 5.0 Spezifikation stellt dafür zukünftig eine normierte Meta-Annotation @Resource zur Verfügung. Anmerkung: im Zuge der noch nicht abgeschlossenen Entwicklung der EJB 3.0-Spezifikation gab es bereits verschiedene Meta-Annotationen (wie beispielsweise @Inject), die innerhalb der EJB 3.0-Spezifikation definiert worden sind. Diese sind aber im Zuge der Harmonisierung der Java EE-Plattform eliminiert worden. Dafür gibt es nun ein Java Standard-Package, in dem sich u.a. @Rescource befindet und welche eben dazu dient, den Java EE-Container dazu zu veranlassen die Referenz auf eine Ressource in die entsprechend annotierte Komponente (z.B. EJB-Komponente, Web Service, Servlet etc.) zu injizieren.

Innerhalb einer EJB 3.0 Entity Bean können POJOs, die ihrerseits nicht als Entity Beans ge-kennzeichnet sind, in die Entity Bean eingebettet werden. Diese eingebetteten Objekte werden als "Embeddable Objects" bezeichnet. Gefüllt werden die Attribute der in eine Entity Bean eingebetteten Objekte aus den Spalten der Tabelle(n) mit der die Entity Bean assoziiert ist.

Es handelt sich hierbei beispielsweise um das Mappen einer Tabelle auf eine Entity Bean und darin eingebetteter weitere POJOs (einfacher Java-Klassen), um eine denormalisierte Tabelle auf ein Objektnetz zu projizieren.

Entity Bean mit dem Mapping auf ein Embeddable Object

@Entity
@Table(name = "KUNDE")
public class Kunde implements java.io.Serializable {
    private int id;
    private Adresse adresse;
    private String Name;
    private String Vorname;

    public Kunde(String name, String vorname, String strasse, String stadt) {
      this.adresse = new Adresse(strasse, stadt);
      this.name= name;
      this.vorname = vorname;
    }
    ...

    @Embedded
    @AttributeOverrides({
    @AttributeOverride(name = "strasse", column = @Column(name = "STRASSE")),
    @AttributeOverride(name = "stadt", column = @Column(name = "STADT")) })
    public Adresse getAdresse() {
       return adresse;
    }

    public void setAdresse(Adresse adresse) {
       this.adresse = adresse;
    }

    @Column(name = "NAME")
    public String getName() {
       return name;
    }

    public void setName(String name) {
       this.name = name;
    }
    ...
}

Embeddable Object

@Embeddable
public class Adresse implements java.io.Serializable {
    private String strasse;
    private String stadt;
    ...
}

Das Home Interface einer EJB-Komponente enthält alle Methoden zur Steuerung des Le-benszyklus der EJB-Komponente. Da Clients rein technisch keine Möglichkeiten besitzen, Instanzen von EJB-Komponenten über Rechner- und/oder Prozessgrenzen hinweg erzeugen, löschen oder laden zu können, müssen sie sich dazu an das jeweilige Home Interface der gewünschten EJB-Komponente wenden. Dieses stellt die entsprechenden Funktionalitäten zur Verfügung. Durch die Verwendung vom Home Interface wird eine Entkopplung von Clients und EJB-Komponenten erreicht. Das Home Interface entspricht dem Entwurfsmuster der "Factory Method".

Konkret gibt es von einem Home Interface zwei Varianten:

• Remote Home Interface
  für entfernte Zugriffe über Rechner- und/oder Prozessgrenzen hinweg
• Local Home Interface
  für lokale Kommunikation durch In-Prozess-Methodenaufrufe

Mit EJB 3.0 ist es möglich - analog CORBA-basierten Systemen, in denen Interceptor-Mechanismen seit langem bekannt sind und eingesetzt werden - Methodenaufrufe von Geschäftsmethoden abzufangen, die darin enthaltenen Parameterwerte zu untersuchen, bei Bedarf zu manipulieren und die Aufrufe weiterzuleiten oder bei Bedarf abzubrechen bzw. zu verhindern.

Mit dem Interceptor-Mechanismus hält die aspektorientierte Programmierung - zumindest in Ansätzen - Einzug in die EJB-basierte Entwicklung. Interceptors ermöglichen das transparente Einflechten von Funktionalitäten (z.B. Logging, Tracing, Zeitmessung, Sicherheitsprüfungen), die fachliche Entwickler von technischen Aspekten entkoppelt.

Der Entwickler eines Interceptors kann für eine abgefangene Methode innerhalb des aktivierten Interceptors beliebigen von ihm hinterlegten Code ausführen zu lassen.

Inversion of Control (IoC) ist eine allgemeine Eigenschaft von Frameworks, wird gemeinhin gerne mit dem Satz "don't call us, we call you" umschrieben und soll ausdrücken, dass die Verantwortlichkeiten bei der Programmausführung beim Framework liegen und nicht bei den Komponenten, die auf Basis eines Frameworks entwickelt und ausgeführt werden.

D.h. das die Komponenten umgebende Framework verlangt von den Komponenten, dass bestimmte Callback-Methoden durch sie implementiert werden, über die das Framework bzw. der Container zur Laufzeit Informationen in die Komponenten injiziert ober bestimmtes Verhalten (über Methodenaufrufe) auslöst.

Im Kontext von EJB 3.0 wird IoC und Dependency Injection vielfach synonym verwendet, auch wenn es im Detail sehr wohl Unterschiede gibt (siehe hierzu auch Dependency Injection). Das, was bei EJB 3.0 zum Einsatz kommt, ist eine spezialisierte Form von Inversion of Control und wird als Dependency Injection bezeichnet.

Die lokale Variante des Home Interfaces ist das Local Home Interface. Es ist sozusagen die "Hochgeschwindigkeits-Variante" des Home Interfaces. Das Local Home Interface kommt ausschließlich dann zum Einsatz, wenn sich Client und zu rufende EJB-Komponente im selben EJB-Container (bzw. Prozess) befinden. Analog dem Remote Home Interface dient auch das Local Home Interface dazu, EJB-Komponenten erzeugen, löschen und ggf. laden zu lassen.

Das Local Home Interface ist "schlanker" als das Remote Home Interface, da es nicht über RMI angesprochen werden kann und keine Funktionalitäten für das Packen, Entpacken und Transferieren von Methodenaufrufen zum Transport über das Netzwerk zur Verfügung stellen muss. Die Kommunikation zwischen Client und EJB-Komponente erfolgt mittels In-Prozess-Methodenaufrufen und ist somit schneller als unter Verwendung eines Remote Home Interfaces. Das Local Home Interface ist nicht in der Lage, entfernte Methodenaufrufe zu empfangen.

<insert Grafik Local Home Interface>

Das Multi-table Mapping bezeichnet die Fähigkeit einer EJB 3.0 Entity Bean, auf mehrere physikalische (normalisierte) Datenbanktabellen gemappt zu werden. Diese Fähigkeit gab es in EJB 2.x - ohne expliziten Programmieraufwand - nicht. In EJB 3.0 ist eine Entity Bean kein stumpfes 1:1 Mapping einer Tabelle mehr, sondern vielmehr die technische Hülle für ein logisches Geschäftsobjekt, dessen Daten physikalisch über mehrere Tabellen verteilt sein können. Es wird innerhalb der Entity Bean über Annotationen einfach angegeben, aus welchen Tabellen/Feldern die entsprechenden Daten stammen. Der Entity Manager sorgt dafür, das relationale Modell zur Laufzeit aufzulösen und die Daten in die Entity Bean zu übertragen (siehe Abbildung).

Logisches Geschäftsobjekt (Entity Bean), bestehend aus drei Tabellen

@Entity
@Table(name = "KUNDE")
@SecondaryTables({
@SecondaryTable(name = "ADRESSE")
@SecondaryTable(name = "TYP") })
public class Kunde implements java.io.Serializable {
   private int id;
   private String name; // Aus Tabelle "KUNDE"
   private String vorname ; // Aus Tabelle "KUNDE"
   private String strasse; // Aus Sekundärtabelle "ADRESSE"
   ...

   // Attribut aus der Haupttabelle "Kunde"
   @Column(name = "NAME")  
   public String getName() {
     return name;
   }
   ...

   // Attribut aus der Sekundärtabelle "ADRESSE"
   @Column(name = "STRASSE", secondaryTable = "ADRESSE")
   public String getStrasse() {
     return strasse;
   }
   ...

   // Per Default wird, wenn kein @Column angeben ist,
   // davon ausgegangen, dass der Spaltenname gleich dem
   // Attributnamen ist.
   public String getVorname() {
     return vorname ;
   }
}

Der Begriff taucht verstärkt seit 2004 in Fachzeitschriften und eZines im Java-Bereich auf. Mit Plain Old Java Interface bzw. POJI wird ein normales - nicht durch technischen oder infrastrukturellen Code verschmutztes - Java Interface bezeichnet.

Im Kontext von EJB 3.0 wird der Begriff Plain Old Java Interface bzw. POJI nun auch angewandt. Eine Kernidee von EJB 3.0 ist, dass die EJB-Komponenten aus Sicht des Entwicklers - in ihrer Nutzung und in ihrer Mikroarchitektur so weit vereinfacht werden, dass Component Interfaces (also die Geschäftsschnittstellen)

Der Begriff taucht verstärkt seit 2004 ärkt in Fachzeitschriften und eZines im Java-Bereich auf. Mit Plain Old Java Object wird eine normale, einfache Java-Klasse (na ja, vielleicht sollte POJO dann lieber POJC heissen ;-) bezeichnet, die nicht durch infrastrukturellen Code, technische Code etc. "verschmutzt" ist, wie dies beispielsweise bei komplexeren Komponenten vorkommt.

Im Kontext von EJB 3.0 wird der Begriff Plain Old Java Object bzw. POJO nun auch angewandt. Eine Kernidee von EJB 3.0 ist, dass die EJB-Komponenten - aus Sicht des Entwicklers - in ihrer Nutzung und in ihrer Mikroarchitektur so weit vereinfacht werden, dass die Bean-Klassen (die Implementierungs-Klassen der EJB-Komponenten) von ihrem Typ her - im Vergleich zu EJB-Vorgängerversionen - als POJOs bezeichnet werden können.

Das Remote Home Interface ermöglicht es entfernten Clients, über das Netzwerk Anfragen zum Erzeugen, Laden und Löschen von Instanzen zu stellen. Clients kommunizieren mit einem Remote Home Interface über entfernte Methodenaufrufe, die über das RMI/IIOP-Protokoll transferiert werden. Diese Art der Kommunikation ist langsamer als die Kommunikation mittels In-Prozess-Methodenaufrufe innerhalb eines Prozesses. Die Verwendung dieser Ausprägung des Home Interfaces ist notwendig, wenn man Clients, die sich in einem verteilten System auf einem beliebigen Rechner in einem Netzwerk befinden können, eine EJB-Komponente offerieren möchte.

<insert Grafik Remote Home Interface>

Die technische Ausprägung der Geschäftsschnittstelle (Component Interface) einer EJB-Komponente, welche die Remote-Kommunikation (also entfernte Kommunikation) ermöglicht, wird als Remote Interface bezeichnet.

Wenn eine EJB-Komponente ein Remote Interface besitzt, ist es Clients in anderen Prozessräumen möglich über das Netzwerk und Rechner- und Prozessgrenzen hinweg auf eben diese EJB-Komponete zuzugreifen. Die Kommunikation erfolgt dabei über RMI/IIOP.

Selbst wenn sich Client und EJB-Komponente im selben Prozessraum befinden (z.B. ist der Client auch eine EJB-Komponente, die eine andere EJB-Komponente verwendet), und der Client die EJB-Komponente über ihr Remote Interface anspricht, so erfolgt die Kommunikation für gewöhnlich über RMI/IIOP, was in diesem Fall eine unnötige Verlangsamung der Zugriffs wäre, der durch zur Verfügungstellen einer lokalen Geschäftsschnittstelle (Local Interface) sehr einfach behoben werden kann und zu Performanzsteigerungen führt.

  
EJB 3.0-Kolumne im Javamagazin!

Im Javamagazin gibt es seit Ausgabe 2/2005 die EJB 3.0-Kolumne von Oliver Ihns, in der er jeden Monat - bis zur finalen Version in 2006 - einen dedizierten Aspekt von EJB 3.0 beleuchtet. [mehr]

Das aktuelle Buch zu EJB 2.1.

Erschienen im Oldenbourg Wissenschafts-verlag. Vielfach eingesetzt in Praxis und Studium.

[mehr]

Siehe [Poster]