Enterprise-Beans

Gesamtübersicht: Enterprise-Beans

• Was ist eine Enterprise-Bean
• Typen von Enterprise-Beans
• Der Lebenszyklus einer Session-Bean
• Der Lebenszyklus einer Entity-Bean
• Bestandteile einer Enterprise-Bean
• Wie alles zusammenspielt

• Session-Beans:  Sie stellen Geschäftsprozesse dar. Sie implementieren Geschäftslogik, -regel und Workflow. Beispielsweise handelt es sich um das Anlegen eines neuen Kunden im Warenwirtschaftssystem, die Durchführung einer Buchung im Buchungssystem, Banktransaktionen oder komplexe Berechnungen. Session-Beans repräsentieren Tätigkeiten, die auf einem Server für Clients durchgeführt werden. Diese Betrachtungsweise durch die Tatsache deutlicher dargestellt, daß eine Session-Bean eine private Ressource eines bestimmten Clients ist. Session-Beans werden als Session-Beans bezeichnet, weil sie solange existieren wie die Sitzung von Clients, die diese Session-Beans benutzen. Beispielsweise wenn ein Client eine bestimmte Bean anfordert, ist der Server dafür zuständig, eine neue Instanz von dieser Bean zu erzeugen. Wird diese Instanz später von dem Client nicht benötigt, wird sie weggeworfen. Es wird unterschieden von zustandslosen und zustandsbehafteten Session-Beans.
  
  Zustandslose Session-Beans speichern von einem Methodenaufruf zum nächsten keine Daten. Die Methoden einer zustandslosen Session-Bean arbeiten nur mit Daten, die als Parameter übergeben werden. Zustandslose Session-Beans des gleichen Typs besitzen alle die gleiche Identität. Da sie keinen Zustand besitzen, besteht es keine Notwendigkeit und Möglichkeit, sie zu unterscheiden.
  
  Zustandsbehaftete Session-Beans speichern dagegen Daten über mehrere Methodenaufrufe hinweg. Aufrufe von Methoden an den zustandsbehafteten Session-Beans können den Zustand einer Bean verändern. Der Zustand geht verloren, wenn die Sitzung vom Client beendet oder der Server heruntergefahren wird. Die zustandsbehaftete Session-Beans des gleichen Typs haben zur Laufzeit unterschiedliche Identitäten. Der EJB-Container muß sie unterscheiden können, weil sie für ihre Clients jeweils die unterschiedliche Zustände verwalten müssen.
  
  
• Entity-Beans:  Entity-Beans repräsentieren Dinge des realen Lebens, die mit bestimmten persistenten Daten assoziiert werden wie z.B. ein Kunde, ein Buchungskonto oder ein Produkt. Eine Instanz von einer Entity-Bean kann von mehreren Clients benutzt werden. Entity-Beans implementieren keine Geschäftsprozesse. Sie modellieren nur Daten und können von Session-Beans zum Repräsentieren von Daten benutzt werden, die sie benötigen.
  
  Entity-Beans lassen sich dadurch unterscheiden, ob sie selbst verantwortlich sind, daß ihre Daten persistent gemacht werden, oder ob der der EJB-Container diese Aufgabe übernehmen soll. In erstem Fall spricht man von bean-managed Persistence und in zweitem container-managed Persistence. Eine Entity-Bean des gleichen Typs wird zur Laufzeit durch ihren Primärschlüssel identifiziert, den sie vom Container zugeteilt bekommt. Dadurch wird sie an bestimmte Daten gebunden, die sie repräsentiert. Die Identität einer Entity-Bean wird nach außen sichtbar.

Der Lebenszyklus einer zustandsbehafteten Session-Bean

Der Client initialisiert den Lebenszyklus einer Session-Bean, indem die Methode create aufgerufen wird. Der EJB-Container initialisiert die Bean und ruft die Methode setContextSession auf. Dadurch bekommt die Session-Bean den Kontext, über den sie mit dem Container kommunizieren kann. Dieser Kontext bleibt mit der Bean während ihrer gesamten Lebensdauer assoziiert. Anschließend wird die Methode ejbCreate vom Container aufgerufen. Und die Bean ist bereit, ihre Arbeit durchzuführen, falls diese von einem Client angefordert wird.

Während sich eine Bean im Bereit-Zustand befindet, kann der Container entscheiden, sie durch den Aufruf der Methode ejbPassivate zu deaktivieren. Typischerweise entscheidet er nach der LRU-Strategie (least recently used). Nach dem die Bean deaktiviert worden ist, befindet sie sich im passiven Zustand. Falls ein Client eine Methode dieser Bean aufruft, wird sie vom Container durch den Aufruf der Methode ejbActivate aktiviert.

Am Ende des Lebenszyklus ruft ein Client die Methode remove auf und der EJB-Container führt die Methode ejbRemove aus. Somit ist die Instanz der Bean bereit für den Garbage-Collector.

Der Lebenszyklus einer zustandslosen Session-Bean

Da eine zustandslose Session-Bean nie passiv ist, hat ihr Lebenszyklus nur zwei Zustände: nicht-existiert oder bereit für Aufruf von Business-Methoden.

Wie beim Life-Cycle einer Session-Bean wird auch der Lebenszyklus einer Entity-Bean vom EJB-Container kontrolliert. Nachdem der Container eine Instanz einer Entity-Bean erzeugt hat, ruft er die Methode setEntityContext auf. Diese Methode übergibt einer Entity-Bean einen Kontext, über den ihre Identität vom Container verwaltet wird. Über eine Änderung des Kontextes kann der EJB-Container die Identität verändern. Nach der Erzeugung einer Instanz wandert sich diese in einen Pool, in dem die Instanzen verwaltet werden. In diesem Pool ist keine Instanz mit irgendeinem EJB-Objekt assoziiert. Alle in dem Instanzen sind identisch. Sobald eine Instanz sich in den Zustand bereit bewegt, wird ihr eine Identität vom Container zugewiesen.

Es gibt zwei Möglichkeiten, vom Zustand pooled zum Zustand bereit zu wechseln. Die erste ist, daß ein Client die Methode create aufruft. Dies führt dazu, daß der EJB-Container die beiden Methoden ejbCreate und ejbPostCreate ausführt. Nach dieser Ausführung bekommt die Bean-Instanz eine neue Identität und befindet sich im Zustand bereit. Die zweite Möglichkeit ist, daß der EJB-Container die Methode ejbActivate aufruft. Um in den Zustand pooled zurückzukehren, wird dieser Vorgang vom Client durch den Aufruf der Methode remove, die den Container dazu leitet, die Methode ejbRemove auszuführen, oder vom Container durch den Aufruf der Methode ejbPassivate angestoßen.

Will der EJB-Container zu einem Zeitpunkt die Menge der Bean-Instanzen im Pool verringern, so ruft er die Methode unsetEntityContext auf und verwirft die Instanz danach.

• Remote-Interface
  Das Remote-Interface definiert diejenigen Methoden, die von einer Enterprise-Bean nach außen hin angeboten werden. Diese Methoden können von Clients aufgerufen werden. Das Remote-Interface muß von javax.ejb.EJBObject abgeleitet werden. EJBObject ist seinerseits wiederum von java.rmi.Remote abgeleitet.Beispiel

  

• Home-Interface
  Im Home-Interface werden alle Methoden deklariert, die den Lebenszyklus einer Enterprise-Bean betreffen. Auch dieses Interface wird nach außen veröffentlicht.Clients benutzten es um Bean-Instanzen zu erzeugen, aktivieren, passivieren, zu finden oder zu löschen. Das Home-Interface muß von javax.ejb.EJBHome abgeleitet sein, das seinerseits wiederum von java.rmi.Remote abgeleitet ist. Beispiel

  

• Bean-Klasse
  Die Bean-Klasse implementiert die Methoden, die im Home- und im Remote-Interface definiert wurden, ohne diese beiden Interfaces im Sinne des Schlüsselwortes implements tatsächlich einzubinden. Die Signaturen der im Home- und im Remote-Interface deklarierten Methoden müssen mit den entsprechenden Methoden in der Bean-Klasse übereinstimmen. Die Bean Klasse muß in Abhängigkeit von ihrem Typ ein Interface implementieren, und zwar javax.ejb.EntityBean oder javax.ejb.SessionBean. Beispiel
  
  
• Der Primärschlüssel (Primärschlüsselklasse)
  Er ist nur bei Entity-Beans relevant. Er dient dazu, eine Entität eines bestimmten Typs eindeutig zu identifizieren, die dann vom Container mit einer Entity-Bean-Instanz eines passenden Typs assoziiert wird. Über diesen Schlüssel wird die Identität einer Entity-Bean nach außen sichtbar. Diese Bean-Klasse muß das Interface java.io.Serializable implementieren.
  
  
• Der Deployment-Deskriptor
  Der Deployment-Deskriptor ist eine Datei im XML-Format und beschriebt eine oder mehrere Beans. In diesem Diskriptor befinden sich deklarative Informationen, die im Code einer Bean nicht zu finden sind. Diese Informationen sind für diejenigen Personen wichtig, die die Beans zu Anwendungen zusammenfassen bzw. sie in einem Container installieren. Über diesen Deployment-Deskriptor wird der Container mitgeteilt, wie er die Enterprise-Beans zur Laufzeit zu behandeln hat.

  Informationen, die sich im Deployment-Deskriptor befinden, sagen zum einen über die Struktur einer Bean und ihre externe Abhängigkeit aus wie z.B. zu anderen Beans oder zu Verbindungen zu einer Datenbank aus. Zum anderen sagen sie aus, wie sich eine Komponente zur Laufzeit verhalten soll bzw. wie sie mit anderen Beans zu komplexeren Bausteinen kombiniert werden kann.