Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Java EE 7 Grundkurs

Überblick über die EJB Lite

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Die Enterprise Java Beans stellen standardisierte Komponenten innerhalb eines Java EE Server dar. Dabei steht eine Lite-Version zur Verfügung, welche ausschließlich bestimmte Teile der gesamten Spezifikation unterstützt.

Transkript

Die Enterprise JavaBeans oder auch EJBs sind ein ganz wesentlicher Bestandteil der Java EE, und sicherlich auch einer der bekanntesten. Fast jeder Java-Entwickler hat schon einmal von EJBs gehört und möglicherweise auch die eine oder andere Horrorgeschichte über deren Konfiguration und Verwendung vernommen. Nun, wir werden in diesem Video den Vorhang ein wenig lüften und erklären, was EJB Lite ist. Ebenfalls werden wir uns in diesem Video mit den Stateful Session Beans auseinandersetzen. EJB Lite selbst ist ein Subset der "großen" EJB-Spezifikation. Das heißt, es werden nur Teile der ganz großen Spezifikation unterstützt, und zwar Stateful Session Beans, Stateless Session Beans, Singleton Beans. Es gibt die Transaktionen, es gibt die Sicherheitskonzepte, und es gibt einen sogenannten Embedded Container for Testing. Diesen Embedded Container for Testing verwenden Sie aber bitte wirklich nur für das Testen. EJB Lite selber verfügt über die Komponenten, die man im Webumfeld normalerweise benötigt. Das heißt, wir können EJB Lite als Lösung für Java-EE-Applikationen ansehen, die ausschließlich auf dem Web Profile laufen. Ein ganz wesentlicher Bestandteil von EJB Lite sind die Stateful Session Beans. Diese Stateful Session Beans sind selber POJOs, also Plain Old Java Objects, ganz normale Java-Klassen. Diese halten den Status für einen Client vor. Das machen sie, indem sie mit der Stateful-Annotation versehen sind. Stateful Session Beans werden für den Client durch einen sogenannten Proxy repräsentiert. Das heißt, es ist eine Stellvertreter-Klasse. Diese übernimmt die Kommunikation mit der Stateful Session Bean. So eine Stateful Session Bean veröffentlicht Methoden. Diese Methoden können vom Client aufgerufen werden. Wenn eine Methode mit der Remove-Annotation versehen ist, dann wird der Status der Bean gelöscht. Das bedeutet nicht, dass die Bean gelöscht wird. Eigentlich wissen wir nie, ob so eine Bean gelöscht wird. Was wir aber wissen, ist, dass der Status der Bean, der mit einem Client assoziiert ist, gelöscht wird und verworfen wird. Eine Stateful Session Bean kann den sogenannten No-interface view definieren. So ein no-interface view ist dann gegeben, wenn die Bean selber nur über die Stateful-Annotation verfügt. Das heißt, sie definiert kein zusätzliches Interface. So eine Stateful Session Bean ist nur in derselben Java-EE-Applikation erreichbar. Das heißt, sie wird zum Beispiel von der Webschicht aus erreichbar sein. Sie kann aber nicht zum Beispiel von einem externen Client erreicht werden, der nicht in derselben Java-EE-Applikation deployed worden ist. Bei so einer Stateful Session Bean wird ein Proxy vom Typ der "Klasse" erzeugt. Es gibt darüber hinaus den sogenannten Remote View. Dieser Remote View wird genutzt, um die Bean auch nichtlokalen Clients zugänglich zu machen. Dieser Remote View, früher war das sehr kompliziert, ist heutzutage nichts anderes als ein einfaches Java-Interface annotiert mit der Remote-Annotation. Dies führt dann dazu, dass Clients, egal, ob sie in derselben Applikation liegen oder ob sie extern liegen, einen Proxy vom Typ des Interfaces bekommen und damit letztlich nur noch einen Teil der Funktionalitäten der Bean sehen können. Das ist durchaus sinnvoll. Schließlich wollen wir ja nicht alle Funktionalitäten außerhalb des Java-EE-Application- Servers verfügbar machen. Wichtig: Die Clients müssen sich dann nicht innerhalb derselben Java-EE-Applikation befinden. Und sie müssen auch nicht auf demselben Server liegen. Wir werden uns normalerweise EJBs injizieren lassen, in unsere Webkomponenten beispielsweise. Dabei wird dann Lookup und Injizierung vom System vorgenommen. Uns stehen dabei zwei mögliche Annotationen zur Verfügung: entweder Inject oder EJB. EJB erlaubt es, mehr Kontrolle zu halten, weil wir bei EJB in der Lage sind, einen sogenannten JNDI-Pfad zu definieren. Sie müssen wissen, dass eine Stateful oder auch eine Stateless Session Bean nicht einfach nur im Server bereitgestellt wird, sondern sie wird über einen benannten Pfad im Java Naming and Directory Interface (JNDI) bereitgestellt. Jede Komponente, die diesen Pfad kennt, kann diese Bean erreichen. Wenn wir einen JNDI-Pfad bei der Suche einer EJB verwenden wollen, machen wir das mit Hilfe des Lookup-Attributs. Die CDI-Möglichkeit, per Inject sich Beans injizieren zu lassen, funktioniert nur für Beans, die innerhalb derselben lokalen Applikation liegen. Und Inject funktioniert nicht für die no-interface views. Das bedeutet für uns, dass, wenn wir nicht einen Remote View definieren, wir Inject nicht verwenden können. Und das führt dazu, dass man in den meisten Fällen tatsächlich die EJB-Annotation verwendet. Darüber hinaus gibt es einen sogenannten Local View. Der Local View ist genau wie der Remote View ein Interface. Und dieses Interface ist mit der Local-Annotation versehen. Das ist ein zusätzliches Interface, und dieses zusätzliche Interface kann genutzt werden für Komponenten, die im selben EJB-Container veröffentlicht sind. Und diese Komponenten können dann über den Local View auf zusätzliche Funktionalitäten zugreifen. Wichtig: Die Bean muss dabei nicht innerhalb derselben Java-EE-Applikation liegen, sondern nur im selben Server laufen. Auch hier wird wieder ein Proxy erzeugt. Und dieser Proxy wird wieder auf dem Interface erzeugt. Eine Stateful Session Bean hat einen Zustand. Dieser Zustand führt dazu, dass diese Bean zwischen verschiedenen Lebenszyklus- Stati hin- und herwechselt. Sie wird initial erzeugt. Nach der Erzeugung ist die Bean aktiv. Eine aktive Bean wird von uns gerade verwendet. Wenn die Bean nicht mehr aktiv ist, wird sie passiviert. Das ist ein Prozess, der wird vom Server angestoßen. Und die Bean ist im Anschluss passiv. Das bedeutet, dass die Daten serialisiert worden sind und dass die Bean-Hülle, die auf der Serverseite verwaltet wird, nun andere Daten vorhalten kann. Das ist übrigens eine ganz wichtige Information. Sie sollten sich niemals bei der Verwendung von EJBs darauf verlassen, dass Sie wirklich immer exakt dieselbe Bean zurückbekommen. Sie bekommen immer nur dieselben Daten zurück. Das ist ein fundamentaler Unterschied. Sollte die Bean wieder benötigt werden, oder eigentlich, genauer genommen, sollte derselbe Client eine erneute Anfrage an den Server machen und wir benötigen den Status der Bean wieder, dann wird dieser Status geladen. Dieser Prozess nennt sich Aktivierung. Irgendwann wird die Bean nicht mehr benötigt. Dann wird sie verworfen und ihr Lebenszyklus endet. Diesen Lebenszyklus können wir über sogenannte Callback-Methoden begleiten. Da gibt es einige von. Zum einen gibt es die Methode "PostConstruct". Diese Methode wird nach dem Erzeugen und dem Injizieren von Abhängigkeiten aufgerufen. Es gibt die Möglichkeit, eine Methode mit "PreDestroy" zu annotieren. Diese Methode wird dann aufgerufen, bevor der Status der Bean endgültig verworfen wird. Ebenfalls gibt es die Möglichkeit, eine Methode mit "PrePassivate" zu annotieren. Und diese Methode wird dann eingebunden, bevor der Status der Bean gespeichert wird. Das ist der gerade eben besprochene Prozess der Passivierung. Und wenn der Status wieder benötigt wird, dann wird die Bean ja wieder aktiviert. Und eine Methode, die mit "PostActivate" annotiert ist, wird dann eingebunden. Nach soviel Vorrede lassen Sie uns einen Blick darauf werfen, wie wir eine Stateful Session Bean definieren können, und wie wir sie auch verwenden können. Wie bereits erwähnt handelt es sich bei Stateful Session Beans um ganz normale Java-Klassen. Ich habe dies hier einmal demonstriert mit einer Klasse mit dem Namen "StatefulBean". Diese Klasse ist mit der Stateful-Annotation versehen. Damit ist diese Klasse bereits als eine ganz normale Stateful Session Bean deklariert worden. Ich habe sie innerhalb eines dynamischen Web-Projektes angelegt, also nicht einer spezifischen Java-EE-Applikation, sondern innerhalb einer normalen Java-Web-Applikation. Dies geht mit der Einführung von EJB Lite, denn da können solche Stateful Session Beans Bestandteil der Webschicht sein. Das nutzen wir hier aus, sodass wir jetzt hier auch eine Stateful Session Bean in einer normalen Web-Applikation nutzen können. Ganz wesentlich: Stateful Session Beans, genau wie Stateless Session Beans, sind normalerweise Bestandteil der Geschäftslogikschicht. Das heißt, wenn Sie eine wirklich verteilte Applikation haben, liegen die Dinger wirklich auf dem EJB-Container und nicht auf der Webschicht. Aber es ist voll und ganz legitim, sie auch hier zu benutzen. Für das Einbinden gilt es eigentlich, gar nichts weiter zu beachten. Ich habe, um das Einbinden zu demonstrieren, ein Servlet geschrieben, ein ganz normales Servlet. Hier habe ich eine private Member-Variable vom Typ der Stateful Session Bean. Und ich lasse mir die Bean über die EJB-Annotation injizieren. Sie erinnern sich: Die EJB- Annotation muss ich verwenden, weil diese Stateful Session Bean keine Form von zusätzlichem Interface implementiert. Deswegen geht es nur mit EJB. Diese Stateful Session Bean stellt mir jetzt zwei Methoden zur Verfügung: Zum einen die Methode "erhoeheZugriffe". Da wird die interne Member-Variable "Zugriffe" immer um Eins erhöht. Und eine weitere Methode, mit der ich die aktuelle Anzahl der Zugriffe erfahren kann. Diese Methoden habe ich in der Service-Methode des Servlets eingebunden. Beim Aufruf dieser Methode erhöhe ich halt die Anzahl der Zugriffe. Und danach gebe ich die Anzahl aus. Wenn wir das Ganze einmal ausführen, werden wir gleich sehen, wie das funktioniert. Ich bekomme nun beim ersten Mal die Anzeige "Dein 1. Zugriff". Ein zweiter Klick, ein dritter Klick, ein vierter Klick, die Anzahl erhöht sich. Ich mache das mal parallel. Schließlich haben wir es ja mit einer Stateful Session Bean zu tun. Das heißt, es geht ja hier um die Benutzersitzung. Ich habe den Chrome-Browser geöffnet. Das geht natürlich auch mit jedem anderen Browser. Ich rufe jetzt dieselbe Adresse auf. Und ich sehe, dass ich schon das fünfte, das sechste, das siebte, das achte Mal auf die Applikation zugreife. Genau dasselbe, wenn ich jetzt hier weitermache in der Applikation, erhöht sich offensichtlich ein zentraler Zugriffszähler. Wir haben es hier mit einem typischen Problem zu tun, nämlich mit einem Denkproblem. Eine Stateful Session Bean ist tatsächlich eine Bean, die stateful ist und den Zustand für einen bestimmten Client und dessen Sitzung vorhält. Der Client ist in diesem Fall das Servlet. Und dieses Servlet wird genau einmal erzeugt. Das heißt, die Injizierung findet auch nur einmal statt. Und solange, wie das Servlet aktiv bleibt, bleibt auch derselbe Status für diese Session Bean, für dieses Servlet, aktiv. Das ist natürlich nicht das, was wir wollen. Aus diesem Grund habe ich noch eine weitere Klasse eingebaut, die das Servlet von der Stateful Session Bean entkoppelt und tatsächlich uns die Möglichkeiten bietet, dass wir diesmal mit Benutzersitzungen arbeiten können. Diese Klasse nennt sich BeanManager. Und dieser BeanManager ist eine ganz normale CDI-Bean, die session scoped ist. Dieser session scope bezieht sich jetzt hier auf den scope der Web-Applikation. Ich lasse mir in diese CDI-Bean die Stateful Bean injizieren und führe im Grunde die Methoden beziehungsweise die Aufrufe auf die Stateful Bean durch. Das Einzige, was ich jetzt machen werde, ist, im Servlet mir die CDI-Bean injizieren zu lassen. Das mache ich über die Inject-Annotation, und statt der Stateful Bean lasse ich mir jetzt die andere Klasse "BeanManager" injizieren. Weitere Änderungen sind auf dem Servlet nicht nötig. Nun werde ich die Applikation noch einmal neu deployen. Und nachdem ich dies erledigt habe, kann ich das Servlet noch einmal aufrufen. Das Verhalten ist genau wie vorher. Jetzt wechsle ich auf den Chrome-Browser. Und nun sehen wir, dass wir tatsächlich unterschiedliche Benutzersitzungen haben. Stateful Session Beans sind ein sehr, sehr mächtiger Mechanismus, um Zustände vorzuhalten. Allerdings müssen Sie immer darauf achten, wo Sie diese Stateful Session Beans injizieren. Noch ein Wort generell zur Verwendung von Stateful Session Beans: Bitte benutzen Sie sie nicht als Zwischenspeicher für irgendwie geartete größere Daten. Sie sind kein Datenbankersatz oder ähnliche Dinge, sondern sie sollen dazu dienen, kleine Zustände, einfache Felder oder ähnliche Daten zu halten. Es gibt auf vielen Produktivumgebungen sogar Festlegungen, wie groß die Daten sein dürfen, die in einer Stateful Session Bean liegen. Das sind meistens wenige Kilobytes. Der Hintergrund ist der, dass die Daten der Stateful Session Bean potenziell über ein komplettes Cluster repliziert werden können. Und das wollen Sie nicht, dass dann dort Megabytes an Daten ständig zwischen den verschiedenen Clusterknoten hin- und herrepliziert werden, denn damit erhöhen Sie letztlich die Netzwerklast und die Systemlast der Maschinen, auf denen die Application Server laufen. Deshalb verwenden Sie Stateful Session Beans nur dort, wo Sie wirklich einen kleinen Zustand vorhalten wollen. Für alles andere benutzen Sie lieber Entitäten und speichern sich eventuell auf Seiten von JSF oder auf Seiten von Servlets einen Schlüssel zwischen, mit dem Sie die Daten eindeutig adressieren können. Stateful Session Beans sind schnell geschrieben. Sie sind eine schöne Geschäftslogikkomponente, die einen Zustand vorhalten kann. Wichtig ist dabei, darauf zu achten, dass dieser Zustand möglichst klein ist. Und man muss darauf achten, wie und wo man diese Stateful Session Beans einbindet. Wenn man das aber korrekt macht, dann gewinnt man bei der Verwendung von Stateful Session Beans eine sehr, sehr schöne Möglichkeit, um die verschiedenen Schichten der Applikationen voneinander zu trennen und Geschäftslogikaspekte auszulagern.

Java EE 7 Grundkurs

Lernen Sie die Grundlagen der Programmierung mit Java EE 7 verstehen und anwenden.

6 Std. 4 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!