Reale Welt Anwendungsfälle für Stateful Session EJB

Question

Bezüglich der Verwendung von Session EJBs, was ich bis jetzt in "realen Anwendungen" gesehen habe (wenn ich mich richtig erinnere) sind Stateless Session EJB als "Fassaden" für transaktionale (über CMT) Business-Logik-Methoden. Ich habe jedoch keine Stateful Session EJBs gesehen. In der Tat scheint es, dass ihre Verwendung als "Einkaufswagen" zum Beispiel, die in Java EE-Büchern gefunden werden, bedeutet, dass ihr Zustand in irgendeiner Weise in dem dauerhaften Speicher gespeichert werden sollte. Dies scheint jedoch darauf hinzudeuten, dass auch andere Teile der Anwendungsdomäne, wie sie in der Datenbank modelliert sind, auf zustandsbehaftete EJB-s abgebildet werden sollten, was übermäßig komplex zu sein scheint.

Könnten Sie anhand Ihrer Erfahrung/Ihres Fachwissens spezifische Beispiele dafür geben, wie Stateful Session EJBs in heutigen (im Gegensatz zu 2003) Anwendungen verwendet werden?

Answer 1

Stateful EJB kann ihren Status in der Datenbank beibehalten, Stateful EJB muss jedoch nicht unbedingt ihren Status in einer Datenbank beibehalten. Ein Stateful EJB ist verpflichtet, den Gesprächszustand mit dem Kunden nur für die Dauer des "Gesprächs" im Speicher zu speichern und zu speichern.

Im Folgenden finden Sie einige Beispiele aus der Praxis, die in einigen Fällen für die Stateful EJB-Verwendung gemäß Java EE 7 Tutorial geeignet sind: Stateful Session-Beans sind geeignet, wenn eine der folgenden Bedingungen zutrifft.

Der Status der Bean repräsentiert die Interaktion zwischen der Bean und einem bestimmten Client. Real World Beispiel: Stateful EJB Implementierung einer Online-Transaktion mit Login, Aktion, Abmeldung.

Die Bean muss Informationen über den Client über Methodenaufrufe hinweg speichern. Real World Beispiel: Stateful EJB könnte verwendet werden, um eine Einkaufskarte zu implementieren. Daten können persistiert werden oder nicht, zum Beispiel für einen Eshop, der keine Anmeldung erfordert, könnte die Einkaufskarte weggeworfen werden, wenn der Benutzer die von ihm gesammelten Gegenstände nicht abschließend auscheckt.

Die Bean vermittelt zwischen dem Client und den anderen Komponenten der Anwendung und bietet dem Client eine vereinfachte Ansicht. Stateful EJB könnte verwendet werden, um eine Persistenzabstraktion zu implementieren.

Hinter den Kulissen verwaltet die Bean den Arbeitsablauf mehrerer Enterprise-Beans. Echtes Beispiel: Stateful EJB könnte verwendet werden, um eine Online-Urlaubsbuchung zu implementieren, bei der der EJB einen Agenten modelliert, der ein Flugticket, ein Auto und ein Hotel von verschiedenen Anbietern mit anderen EJBs bucht und die Ergebnisse dann an den Kunden zurückgibt.

Die obigen Beispiele demonstrieren die Anwendbarkeit des Konzepts in einigen Beispielen. Tatsächlich würde das Verwenden von Stateful EJBs in einer realen Umgebung heutzutage zu einem reineren Design führen, jedoch wäre es nicht optimal, wenn Leistung und Komplexität in Betracht gezogen werden. Siehe auch Stateful EJBs in web application?.

Answer 2

Wir haben derzeit einige Stateful EJBs in einer unserer Anwendungen, die auf Produktion laufen. Ich nehme an, es kann als ein Beispiel der realen Welt betrachtet werden.

Diese EJBs werden verwendet, um den Clients große Datenmengen zur Verfügung zu stellen, indem diese Daten in Blöcke aufgeteilt und diese Blöcke bei Bedarf gesendet werden.All dies funktioniert wie folgt:

Client erstellt eine Anfrage mit Angabe von Filtern, nach denen Daten gesucht werden sollen;

Er reicht diese Anfrage mit Stateful EJB-Methode;

Anfrage wird auf einem Server verarbeitet und Ergebnismenge ist vorbereitet;

als Antwort auf seine Anfrage erhält der Client einen Deskriptor für die serverseitige Ergebnismenge;

mit diesem Deskriptor kann er jetzt Datenblöcke mit Stateful-Bean-Methoden abrufen.

War eine Stateful Bean eine Notwendigkeit, ein solches Problem zu lösen? Ganz und gar nicht.

Beschriebene Funktionalität könnte mit einer zustandslosen Bohne erreicht werden. Aber in diesem Fall haben wir nur zwei Möglichkeiten, es zu implementieren. Entweder sind wir gezwungen, Ergebnismengen für Anforderungen jedes Mal vorzubereiten, wenn ein Client den nächsten Datenblock benötigt (da wir keinen Zustand haben), oder wir verwenden einen statischen Speicher und kümmern uns selbst um die Sicherheit und den gleichzeitigen Zugriff. /Unter Sicherheit verstehe ich das Verhindern von Situationen, in denen ein Client mit dem Deskriptor/

Zugriff auf die Ergebnismenge eines anderen erhält. Der erste Weg ist im Vergleich zur Implementierung auf Stateful Beans einfach langsamer und weniger effizient. Der zweite Weg ist komplizierter und weniger stabil aufgrund der Synchronisation.

Mit Stateful Bohne bekommen wir nur das, was wir brauchen, effizient und ohne zusätzlichen Aufwand.