EJB-Glossar
Unser EJB (3.0)-Glossar entzaubert und erklärt die vielen Fachbegriffe 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 hinter den Begrifflichkeiten steckt. Lesen Sie auch unser Buch EJB 3 komplett, in dem wir die Themen ausführlich erläutern.
Wenn Sie Begriffe vermissen, die Ihrer Meinung nach erklärt gehören oder falls Sie Fragen haben, mailen Sie uns doch einfach unter
Index
A·B·C·D·E·F·G·H·I·J·K·L·M·N·O·P·Q·R·S·T·U·V·W·X·Y·Z·Alle
| 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) implementieren. 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 das Einklinken in den Ablauf der Steuerung des Lebenszyklus einer EJB-Komponente zu ermöglichen, 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 Siehe auch JPA-Glossar |
| 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 ist 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. Siehe auch JPA-Glossar |
| 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. |
Copyright © 2005–2009 Holisticon AG
Dieses Glossar darf in vollständiger Form und unverändert jederzeit kopiert und kostenlos weitergegeben werden. Der Hinweis auf die Originalquelle http://www.holisticon.de/cms/EJBGlossar/Startseite muss ebenso wie dieser Copyright-Hinweis stets angegeben werden. Es ist nicht zulässig, das Glossar kommerziell zu vertreiben, gegen Entgelt weiterzugeben oder Inhalte zu verändern. Im Rahmen nicht-kommerzieller Verwendungen, beispielsweise Diplomarbeiten, darf das Glossar gerne übernommen werden. Die Verwendung in kommerziellen Zusammenhängen, beispielsweise in öffentlichen oder internen Schulungen, firmeninternen Netzwerken, Publikationen, Produkten etc. ist prinzipiell gestattet, wenn eine entsprechende Meldung an gesendet wird. Die Weitergabe ist sowohl in elektronischer als auch gedruckter Form zulässig. Im Internet zugängliche Kopien sind ebenfalls zu melden.
Hinweis zu den Urhebern der dargestellten Abbildungen: Alle hier wiedergegebenen Grafiken wurden von uns erstellt und sind NICHT von Dritten bezogen!
Nehmen Sie Kontakt mit uns auf!
Ihre Ansprechpartner:
| Stefan M. Heldt | Oliver Ihns |
| Telefon: +49 40 5074 2722 |