Java EE 7 Grundkurs

Stateless Session Beans

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Stateless Session Beans stellen die klassische Geschäftslogik von Java-EE-Applikationen dar. Diese besitzen keinen Zustand und müssen deshalb nicht aufwendig verwaltet werden.

Transkript

Stateless Session Beans sind eine ganz wesentliche Komponente der Java EE. Sie bilden, wenn man so will, das Rückgrat von Enterprise-Applikationen. Wir werden uns in diesem Video damit auseinandersetzen, was Stateless Session Beans sind, und wir werden auch klären, wie wir welche definieren können. Ebenfalls werden wir eine Stateless Session Bean im Einsatz beobachten können. Stateless Session Beans sind Session Beans. Allerdings halten sie keinen Zustand vor. Das bedeutet: Alle Instanzen sind gleich. Dadurch sind Stateless Session Beans für einen Application Server sehr optimal verwaltbar, denn es müssen keinerlei Daten zwischen verschiedenen Cluster-Membern beispielsweise übertragen werden. Aus diesem Grund bilden Stateless Session Beans üblicherweise die klassische Geschäftsschicht in einer Java-EE-Applikation. Stateless Session Beans sind POJOs, Plain Old Java Objects, also ganz normale Java-Klassen, die mit der Stateless-Annotation versehen sind. Stateless Session Beans können mit Hilfe des sogenannten No Interface Views deklariert werden. Das bedeutet: Es ist eine ganz normale Klasse mit der Stateless-Annotation. Diese können dann anhand der Klasse injiziert und auch verwendet werden. Diese Injektion muss mit Hilfe der EJB-Annotation vorgenommen werden. Das kann so aussehen wie in diesem Beispiel. Hier wird die Account-Session-Bean, eine Stateless Session Bean, in die Variable "Account" injiziert. Die EJB-Annotation wird zwingend benötigt, wenn wir ein No Interface View haben. Das bedeutet: Wir haben keine zusätzlichen Interfaces, die von der Stateless Session Bean implementiert werden und die mit "Home" oder "Remote" annotiert sind. Solche Stateless Session Beans sind auch ausschließlich in der Applikation nutzbar, in der sie deklariert worden sind. Sie sind dafür schnell geschrieben und gut einsetzbar. Damit eine Stateless Session Bean auch für andere Komponenten erreichbar sein kann, also Komponenten, die nicht in derselben Applikation liegen, wird ein sogenannter Remote View benutzt. Dieser Remote View ist nichts anderes als ein Interface. Und auf Ebene dieses Interfaces gibt es die Remote-Annotation. Das kann so aussehen wie in diesem Beispiel. Nun muss die Stateless Session Bean dieses Interface implementieren. Das bedeutet: Die Java-Klasse erweitert das Interface und stellt in diesem Fall die Methoden "withdraw" und "deposit" zur Verfügung. Eine Stateless Session Bean, die über ein Remote View verfügt, wird üblicherweise über dieses Remote-Interface referenziert. Und auch der Proxy, der erzeugt wird, arbeitet auf Ebene des Interfaces. Darüber hinaus gibt es die Möglichkeit, eine sogenannte LocalBean zu deklarieren. Eine LocalBean-Annotation sorgt dafür, dass es eine lokale Sicht auf die Bean geben kann. Sie werden sich fragen: Warum brauche ich das? Schließlich gibt es ja auch den No Interface View. Nun, die LocalView wird dann benötigt, wenn es bereits ein Remote View gibt, das heißt ein Interface. Und so ein Interface schränkt ja üblicherweise die Menge der sichtbaren Methoden stark ein. Und sie wird dann auch sehr gerne eingesetzt, wenn ich so ein Remote View habe, und ein Local View, also ein entsprechendes Interface, das mit "Local" annotiert ist, nicht implementieren möchte. Dann kann ich "LocalBean" als Annotation auf die Klasse schreiben, und alle Komponenten, die im Java-EE- Application-Server deployed sind, können über diese lokale Sicht mit der Bean arbeiten und können alle öffentlichen Methoden der Bean auch erreichen. Remote liegende Komponenten werden weiterhin nur das zu sehen bekommen, was im Remote View definiert ist. Der Lebenszyklus einer Stateless Session Bean ist sehr einfach. Er wechselt nämlich zwischen "Erzeugt" und "Verworfen" hin und her. So ein Lebenszyklus kann dann auch durch Annotationen begleitet werden. Es gibt hier an der Stelle zwei Annotationen, die uns interessieren könnten, nämlich "PostConstruct" und "PreDestroy". Eine Methode die mit "PostContruct" annotiert wird, wird immer dann aufgerufen, nachdem die Instanz erzeugt worden ist und alle Injizierungen vorhanden sind. Das bedeutet, es ist alles Externe bereits dieser Stateless Session Bean hinzugefügt worden, und nun kann sie initialisiert werden. Die PreDestroy-Methode wird aufgerufen, bevor die Instanz verworfen wird auf dem Server. Das erlaubt es uns, Aufräumarbeiten durchzuführen. Lassen Sie uns nun einen Blick darauf werfen, wie wir eine Stateless Session Bean deklarieren können, wie wir ein Remote Interface für diese Stateless Session Bean deklarieren können, und wie wir mit der PostConstruct-Methode einer derartigen Stateless Session Bean arbeiten können. In dieser Web-Applikation definieren wir zunächst ein Remote Interface. Das ist ein ganz normales Interface mit dem Namen BookHandler. Und dieses Remote Interface ist mit der Remote-Annotation aus dem Package "javax.ejb" versehen. Dieses Interface definiert eine Methode, nämlich "getBooks". Implementiert ist dieses Interface auf einer Stateless Session Bean. Diese Stateless Session Bean mit dem Namen BookManager implementiert das Interface. Hier wird der Persistence- Kontext injiziert, das heißt wir arbeiten hier mit einer Datenbank. Es gibt dann hier eine Methode, die uns die Liste aller Bücher zurückgibt. Das ist die Methode, die im Interface deklariert worden ist. Darüber hinaus gibt es eine andere Methode, die nicht im Interface deklariert ist, die also für alle Komponenten, die mit dem Remote Interface arbeiten, nicht sichtbar sein wird. Diese Methode speichert ein Buch. Und wir haben eine Methode, die diese Instanz initialisiert. Sie ist mit der PostConstruct- Annotation versehen und ist privat, das heißt sie ist öffentlich nicht sichtbar. Diese Methode macht nun nichts anderes als zu schauen, ob es in der Bücherliste weniger als hundert Elemente gibt, und wenn es weniger als hundert Elemente gibt, wird ein neues Buch hinzugefügt. Das Buch selbst ist eine ganz normale JPA-Entity, das heißt eine Klasse, die mit "Entity" annotiert ist. Wir haben jetzt hier im Sinne von Wartbarkeit die Abfragen, die gesetzt werden von der JPA noch annotiert, aber das ist etwas Optionales. Ansonsten gibt es an dieser Klasse nichts Besonderes zu bemerken. Injiziert wird das Ganze in ein Book-Servlet. Ich verwende hier an der Stelle ein Servlet, um zu demonstrieren, wo und wie man diese Komponenten nutzen kann. Wir injizieren die Komponente über das Remote Interface mit Hilfe der EJB-Annotation. Jetzt wird hier an dieser Stelle allerdings keine direkte Referenz auf die BookHandler-Klasse beziehungsweise auf das Interface injiziert, sondern ein Stellvertreterobjekt, ein Proxy. Und beim Aufrufen der Funktionalitäten werden die Daten, die gesendet werden, serialisiert werden. Das Ganze geschieht dann, also das Abrufen und Aufrufen der Funktionalitäten, in der Service-Methode. Und hier rufen wir vom BookHandler die Methode "getBooks" auf. Wir lassen uns dann alle Bücher geben und durchlaufen sie. Es wird jetzt hier bei der Ausführung zu einem Fehler kommen. Ich möchte Ihnen das kurz demonstrieren. Der Grund für den Fehler ist, dass die Klasse "Buch" serialisiert werden soll. Das wird immer dann passieren, wenn wir mit einem Remote Interface arbeiten. Hätten wir uns darauf beschränkt, den BookManager direkt zu referenzieren und ins Servlet per EJB-Annotation zu übernehmen, dann hätten wir mit der LocalBean gearbeitet. Und das bedeutet am Ende des Tages: Dort findet, weil das von lokal auf lokal stattfindet, keine Serialisierung statt. Da wir aber mit dem Remote Interface arbeiten, was definitiv die Best Practice ist an der Stelle, müssen wir die Klasse "Book" noch als Serializer bezeichnen. Nachdem dies geschehen ist, können wir die Änderung speichern und können die Applikation neu deployen. Nun können wir die Funktionalität erneut abrufen, indem wir das Servlet aufrufen. Und an dieser Stelle bekommen wir dann auch die Ausgabe, wie wir sie uns vorstellen. Sie sehen übrigens auch, dass die Initialisierung funktioniert. Wenn ich das Ganze jetzt aktualisiere, wird eine neue Instanz der Stateless Session Bean erzeugt und wir werden ein Buch mehr in der Liste Finden. Dasselbe wiederholt sich solange, bis ich insgesamt einhundert Bücher in der Liste habe. Sie sehen: Es ist sehr einfach, Stateless Session Beans zu erzeugen. Aber es gibt dann doch den einen oder anderen Fallstrick, speziell wenn man mit dem Remote Interface arbeitet, bei dem die Daten, die transportiert werden sollen, serialisiert werden müssen. Als Faustregel gilt hier: Alles, was Sie von Stateless oder Stateful Session Beans zurückgeben, sollte serializible implementieren. Dann umgehen sie nämlich die Probleme, die auftreten können, wenn Sie einmal direkt die lokale Bean, also mit dem No Interface View arbeitend, referenzieren, und einmal, wenn Sie mit dem Remote Interface arbeiten. Das ganze Problem ist dann nicht mehr existent. Ansonsten ist die Verwendung und der Aufbau von Stateless Session Beans sehr einfach. Üblicherweise legen Sie zunächst ein Interface an, das mit der Remote-Annotation versehen ist, und implementieren das dann in einer Bean, die mit der Annotation "Stateless" versehen ist. Mehr ist an dieser Stelle nicht zu beachten, außer es gibt keinen Zustand dieser Bean.

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!