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.
|
M nach oben
|
|
Managed Object
|
EJB 3.0
|
Bezeichnet eine vom EntityManager überwachte EJB 3 Entity bzw. Persistent Entity. "Überwacht" bezieht sich hierbei auf die Steuerung des Persistenzverhaltens der Entität.
|
|
Message-driven Bean
|
EJB 2.x
EJB 3.0
|
Message-driven Beans werden für die Implementierung asynchroner Kommunikation in J2EE bzw. Java EE-basierten Systemen eingesetzt. Message-driven Beans sind Nachrichtenkonsumenten von Message-Brokern. Sie sind in der Lage asynchrone Nachrichten von diesen entgegenzunehmen und zu verarbeiten. Im Kontext von Messaging-Systemen agieren Message-driven Beans somit als Nachrichten-Endpunkte, die vom EJB-Container bzw. originär vom JMS-Provider beim Eintrefen von Nachrichten asynchron benachrichtig werden.
Message-driven Beans besitzen weder ein Home- noch ein Component Interface bzw. auch kein Business Interface. Dies impliziert, dass Message-driven Beans also keine Client-Sichtbarkeit haben, d.h. Message-driven Beans (MDB) können niemals direkt von einem Client angesprochen werden.
Gänzlich ohne Clients sind MDBs natürlich nicht sinnvoll. Die Clients von MDBs sind Nachrichten-Sender, die indirekt mit den Instanzen einer Message-driven Bean kommunizieren, indem sie Nachrichten an bestimmte Message Destinations senden. MDB werden für Message Destinations registriert. Diese Registrierung geschieht über die Deployment Deskriptoren. Damit wird letztlich die Verbindung zwischer einer Message Destination und einer oder mehrerer MDBs hergestellt, welche die Nachrichten aus der Message Destination verarbeiten können. MDBs werden beim Eintreffen dieser Nachrichten benachrichtigt, indem der EJB-Container eine Nachrichtenverarbeitungs-Methode einer Bean-Instanz der registrierten MDB aufruft. Diese Methode implementiert die Geschäftslogik der Bean und erhält als Parameter die empfangene Nachricht aus der Message Destintation.
MDBs sind zustandslos (aus Client-Sicht) und nicht-persistent. Sie ermöglichen die parallele Verarbeitung von Nachrichten durch eine Vielzahl von Instanzen einer MDB. Dies ist ein Performance-Booster für die Abarbeitung von hohen Aufkommen von Nachrichten in MOM-basierten Systemen.
Message-driven Beans gibt es als
JMS Message-driven Bean und
Connector-based Message-driven Bean.
|
|
Meta-Annotationen
|
EJB 3.0
|
Meta-Annotationen sind dynamische Spracherweiterungen der Java-Programmiersprache. Sie sind mit dem JDK 1.5 eingeführt worden. Meta-Annoationen ermöglichen es, direkt im Java-Code Meta-Informationen unterzubringen, die sowohl zur Compile- als auch zur Laufzeit ausgewertet werden können. Diese Informationen können u.a. dafür genutzt werden, um Code zu generieren oder das Laufzeitverhalten eines Objektes bzw. einer Komponente zu steuern.
|
|
Multi-table Mapping
|
EJB 3.0
|
Das Multi-table Mapping bezeichnet die Fähigkeit einer EJB 3.0 EJB 3 Entity, auf mehrere physikalische Datenbanktabellen gemappt zu werden. Diese Fähigkeit gab es in EJB 2.x - ohne expliziten Programmieraufwand - nicht. In EJB 3.0 ist eine EJB 3 Entity 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 EJB 3 Entity über Meta-Annotationen angegeben, aus welchen Tabellen/Feldern die entsprechenden Daten stammen. Der EntityManager sorgt dafür, das relationale Modell zur Laufzeit aufzulösen und die Daten in die EJB 3 Entity zu übertragen (siehe Abbildung).
Logisches Geschäftsobjekt (EJB 3 Entity), 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", table = "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 ;
}
}
|