[objects-at-work] EJB Glossar: D

Unser EJB (3.0)-Glossar entzaubert und erklärt die vielen Buzzwords wie beispielsweise Inversion of Control, Configuration by Exception, POJO, POJI, Dependency Injection etc., die durch alle möglichen eZines und Printmedien geistern, und erklärt, was denn hinter den Buzzwords bzw. Begrifflichkeiten steckt.

D nach oben
DD	EJB 1.x EJB 2.x EJB 3.0	Akronym für Deployment Descriptor
Detached Entity	EJB 3.0	siehe Detached Object
Detached Object	EJB 3.0	Bezeichnet eine Instanz einer EJB 3 Entity, die nicht mehr mit ihrem originären Persistence Context assoziiert ist. Damit ist eine Synchronisierung ihrer Daten mit der Datenbank nicht mehr gegeben. Ein solches Objekt wird nicht mehr durch den EntityManager verwaltet; es ist also eine vom EntityManager nicht mehr gemanagte Instanz einer EJB 3 Entity. Detached Objects können durch verschiedene Umstände entstehen. U.a. beispielsweise dann, wenn eine Instanz einer EJB 3 Entity serialisiert wird. In diesem Fall ist die serialisierte Form der EJB 3 Entity ein Detached Object.
Dependency Injection	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/Klassen hat. Die Motivation für die Einführung von DI in EJB 3 ist es, für EJB-Komponenten den Zugriff auf Ressourcen bzw. den Erhalt von Referenzen auf Ressourcen zu vereinfachen und damit letztlich auch die Notwendigkeit des Implementierens von Code für den Zugriff über die JNDI API. Dependency Injection bedeutet für die EJB-Technologie, dass der Entwickler den Code für den Erhalt von Referenzen auf Ressourcen mittels der Nutzung der JNDI API nicht mehr selbst implementieren muss, sondern die benötigten Referenzen durch die Verwendung von Annotationen bzw. die Hinterlegung in XML anfordert. Der Container stellt dann zur Laufzeit die benötigten Referenzen auf Ressourcen zur Verfügung. D.h. EJB-Komponenten fragen nicht mehr aktiv den sie umgebenden Container nach Referenzen, sondern bekommen Referenzen auf Ressourcen von außen - vom Container - injiziert. Der Entwickler annotiert dazu mittels Meta-Annotation wahlweise Instanzvariablen oder Setter-Methoden einer EJB-Komponente, wo der EJB-Container die gewünschten Referenzen injizieren (einfügen) soll. Optional kann der Entwickler diese Informationen auch in XML hinterlegen. Der Container sorgt automatisch dafür, dass spätestens vor der Ausführung der ersten Methode der EJB-Komponente die entsprechenden Referenzen der EJB-Komponente zur Verfügung gestellt werden. Die für EJB 3 bevorzugte Variante ist die Nuztung von Annotationen.
Deployment Descriptor	EJB 1.x EJB 2.x EJB 3.0	Der Deployment Deskriptor enthält im XML-Format Informationen für die Generierung und Ausführung von EJB-Komponenten zur Lauf- und Kompilierungszeit. Hierbei handelt es sich um deklarative Programmierung, da der Entwickler Features/Funktionalitäten der EJB-Komponenten durch "einfaches" Angeben bestimmter Schlüsselwörter innerhalb eines Deployment Deskriptors erreichen kann, ohne programmieren zu müssen. Beispielsweise lässt sich darüber die Transaktionalität von EJB-Komponenten steuern.