Nachdem Sie das Java™- oder EJB-Projekt erstellt haben,
können Sie Session-Beans, Entity-Beans und Message-driven Bean (nachrichtengesteuerte Beans) erstellen, um diese zum Projekt hinzuzufügen.
Enterprise-Beans
Eine Enterprise-Bean ist eine Java-Komponente, die mit anderen Ressourcen zu Java-Anwendungen kombiniert werden kann. Es gibt drei Arten von Enterprise-Beans: Session-Beans, Entity-Beans und Message-driven Beans. Alle Beans befinden sich in EJB-Containern (EJB - Enterprise
JavaBeans), die eine Schnittstelle zwischen den Beans und dem
Anwendungsserver bereitstellen, auf dem sie sich befinden.
In der EJB 3.1-Spezifikation werden die EJB 1.1-Entity-Beans nicht mehr unterstützt.
Die Spezifikation Java Persistence API (JPA) ist für die Ersetzung der veralteten Enterprise-Beans vorgesehen.
Obwohl die JPA-Ersetzung als Entitätsklasse bezeichnet wird, darf sie nicht mit Entity-Enterprise-Beans verwechselt werden.
Eine JPA-Entität ist keine Enterprise-Bean und muss nicht in einem EJB-Container ausgeführt werden.
Sie können auch EJB 3.0- und 3.1-Beans in Web 3.0-Projekten erstellen.
Komponentendefinierende Annotationen
Mithilfe von komponentendefinierenden Annotationen können Sie die folgenden Enterprise-Beans erstellen: Session-Beans, Message-driven Beans und JPA-Entitäten. Die Angabe der komponentendefinierenden Annotationen @Stateful bzw. @Stateless zeigt an, dass die Klasse eine Session-Bean-Klasse ist, die Angabe der komponentendefinierende Annotation @Singleton zeigt an, dass die Klasse eine Singleton-Klasse ist. Wenn Sie die
komponentendefinierende Annotation @MessageDriven angegeben, handelt es sich um eine Message-driven Bean-Klasse. Die Angabe der komponentendefinierenden Annotation @Entity zeigt an, dass die Klasse eine JPA-Entität ist.
- Session-Beans: Eine mit der Spezifikation EJB 3.1 erstellte Session-Bean benötigt mindestens eine Bean-Klasse.
- Stateful: Eine Stateful Session-Bean speichert clientspezifische
Sitzungsdaten bzw. den Dialogstatus zwischen mehreren Methodenaufrufen und
Transaktionen. Eine Instanz mit einer Stateful Session-Bean hat eine eindeutige Identität, die bei der Erstellung vom Container
zugeordnet wird.
- Stateless: Eine Stateless Session-Bean speichert den Dialogstatus
nicht. Instanzen einer Stateless Session-Bean haben keinen Dialogstatus. Da eine Stateless-Session-EJB den Dialogstatus nicht speichert, müssen
alle Daten, die zwischen dem Client und der EJB ausgetauscht werden, als Eingabeparameter
oder als Rückgabewerte übergeben werden, die in der EJB-Geschäftsmethodenschnittstelle
deklariert werden. Alle Instanzen einer Stateless Session-Bean haben dieselbe Objekt-ID, die vom Container zugeordnet wird.
- Singleton: Eine Singleton-Session-Bean (neu in EJB 3.1) ist ein neuer Session-Bean-Typ, der auf jeden Fall mindestens einmal für eine Anwendung in einer bestimmten JVM (Java Virtual Machine) instanziiert wird. Die Funktionalität von Singletons ähnelt der Funktionalität der Stateless Session-Beans. Der Unterschied besteht jedoch darin, dass es pro Anwendung nur eine Singleton-Session-Bean gibt, während es bei Stateless Session-Beans einen Bean-Pool gibt, bei dem jede beliebige Bean auf eine Clientanforderung antworten kann. Singleton-Session-Beans können ebenso wie Stateless Session-Beans Web-Service-Endpunkte implementieren. Singleton-Session-Beans behalten ihren Status zwischen Clientaufrufen bei, sie müssen ihn jedoch nicht über Serverabstürze und Systemabschlüsse hinaus beibehalten.
- Message-driven Beans: Message-driven Beans wurden in EJB 2.0 eingeführt, um die Verarbeitung asynchroner Nachrichten von einem
Java Message
Service (JMS) zu unterstützen. Die Spezifikation EJB 2.1 erweitert die
Definition von Message-driven Beans,
sodass sie jegliches Nachrichtensystem, nicht nur JMS, unterstützen können. Vereinfacht dargestellt,
ist eine Message-driven Bean ein Nachrichtenkonsument, der vom zugehörigen Container
aufgerufen werden kann. Wenn eine Nachricht eingeht, wird eine solche Bean vom Container aufgerufen. Message-Beans sind ein weiterer Interaktionsmechanismus zum Aufrufen von EJBs. Im
Unterschied zu Session-Beans ist jedoch weder ein Client noch eine andere Bean, sondern
der Container dafür zuständig, diese beim Empfang einer Nachricht aufzurufen.
- Entitäten, die JPA (Java Persistence API) verwenden:
Entitäten verwenden die neue Java Persistence API (JPA) der Java EE
5-Plattform. Im Unterschied zu EJB-Komponenten, die CMP (Container-managed Persistence) verwenden,
sind Entitätsobjekte, die die neuen APIs verwenden, keine Komponenten mehr, sondern einfach Java-Objekte. Dadurch werden Entitäten schlanker und das Programmiermodell ist
einfacher zu handhaben. Weitere Informationen zu JPA finden Sie in der
JPA-Dokumentation.
Richtlinien für die Entwicklung von EJBs
Auch wenn EJB 3.1 ein flexibles und einfaches Programmiermodell bereitstellt, werden nachfolgend ein paar empfohlene Regeln für das Entwickeln von EJBs genannt:
- Jede Entität muss ein POJO sein und die Klasse muss konkret sein (also nicht
abstrakt oder final).
- Die Klasse muss einen Konstruktor ohne Argument aufweisen, andernfalls fügt der Compiler einen
Standardkonstruktor hinzu.
- Das POJO muss mindestens eine POJI implementieren (Plain Old Java Interface). Sie müssen keine Schnittstelle einschließen, aber Sie können andere Schnittstellen für lokale und ferne Clients einschließen.
- Wenn die Geschäftsschnittstelle eine @Remote-Annotation enthält, müssen alle für die Schnittstelle deklarierten Parameter "java.io.Serializable" implementieren.
- Eine Session-EJB kann eine Unterklasse eines POJO erstellen,
jedoch keine Unterklasse einer anderen Session-EJB.
Sie können Enterprise-Beans auf eine der folgenden Arten erstellen:
- Erstellen neuer Enterprise-Beans mithilfe von Assistenten.
- Erstellen neuer Enterprise-Beans mit Java EE-Annotationen.
- Importieren von Enterprise-Beans aus EJB-JAR-Dateien.