Unterschied Session Scope / Stateful Session Bean

[polarbear]

Hallo Gemeinde,

wann wird der Session Scope, wann eine Stateful Session Bean benutzt, um Client-Zustände zu speichern (z.B. Warenkorb).

Wie sind die Scopes (Request, Page, Session, Application) eigentlich unter der Haube von Java EE realisiert?

Dank und Gruß
polarbear

 

[oopexpert]

Du vergleichst hier Scopes von Variablen mit Session Handling. Das ist aus meiner Sicht nicht ganz symmetrisch. Schließlich versucht Java EE genau von Scopes weiter zu abstrahieren und bzgl. der Kommunikation zwei Fragen zu beantworten: Sollen Anfragen an den Server voneinander unabhängig sein? Soll die Kommunikation synchron oder asynchron laufen? Wie intern in EE mit den Scopes Page, Request, Session und Application umgegangen wird, muss transparent sein.

In Java EE gibt es die Unterscheidung zwischen stateful session und stateless session. Realisiert wird stateless durch stateless session Beans und stateful durch stateful session beans. Wenn man dort einen Vergleich anstrebt, wäre die Abbildung des Request Scope auf stateless und Session Scope auf stateful am naheliegendsten.

Application Scope wäre realisierbar durch stateful oder stateless session beans über static Variablen, wovon ich aber dringend abrate. Der Application Scope sollte sich meiner Meinung nach über den persistenten Zustand des Systems darstellen, weil Dinge, die applikationsweit gültig sein sollen, sind über den Application Server und / oder die DB zu synchronisieren.

Ich würde an dieser Stelle den Page Scope schwer vergleichbar und vereinbar mit Session Handling ansehen.

Wie gesagt: In dem einen Fall sprechen wir über Scope von Variablen, in dem anderen Fall sprechen wir darüber, ob die Client-Server-Kommunikation Request-atomar ist oder Request-übergreifend.

Ergänzung der Vollständigkeit halber: Anfragen an stateful und stateless session beans sind synchron. In Java EE gibt es noch asynchrone Kommunikation: Message Driven Beans.

 

[oopexpert]

Ein Warenkorb muss nicht unbedingt ein Client-Zustand sein sondern kann auch in der Persistenz repräsentiert werden. Insofern erhält der Warenkorb den Application-Scope. Natürlich dürfen nicht alle deinen Warenkorb dann ansehen. Das ist aber eine Rechte-Problematik, und keine Scope-Problematik.

 

[oopexpert]

Unter der Voraussetzung, dass Du Client-seitig dir den Warenkorb merken möchtest, ist es egal, ob du eine stateful session bean oder eine stateless session beans benutzt.

Wenn du serverseitig nicht perisistent deinen Warenkorb halten möchtest, musst du eine statefull session bean verwenden.

Wenn du serverseitig persistent deinen Warenkorb halten möchtest, ist die Wahl zwischen stateful und stateless davon abhängig, was deine Transaktionale Klammer sein soll. Sollen mehrere Anfragen an den Server innerhalb einer Transaktion stattfinden, musst du stateful beans verwenden, ansonsten reichen stateless beans.

Ich persönlich würde immer stateless session beans bevorzugen und den Warenkorb serverseitig persistent halten. Hängt aber natürlich auch von den Anforderungen ab.

 

[polarbear]

Hallo,

zunächst einmal Danke für die Antworten.

Meine Fragen waren eher akademischer Natur. Grundsätzlich KANN ein Warenkorb-Objekt im Session Scope abgelegt werden. Alternativ bietet sich die Verwendung von SFSB an. Mich interessiert das Für und Wider beider Varianten zunächst ohne Persistenz.

Die Frage nach der Realisierung von Scopes ging in die Richtung, ob diese als Objekte z.B. mittels JavaBeans realisiert werden und in welche Datenstruktur die Key/Value-Paare abgelegt werden. Das Ganze ist für den Entwickler ja ziemlich transparent.

Grüße
polarbear

 

[oopexpert]

Es stellt sich noch eine weitere Frage: Handelt es sich beim Client um einen Rich-Client oder einen Web-Client? Oder sollen beide bedient werden?

Wenn es nur Web-Clients gibt, dann skaliert wahrscheinlich die Ablage der Informationen in dem Session Scope der Web-Server-Komponente. Frameworks wie Struts bieten Unterstützung bei der Nutzung der unterschiedlichen Scopes.

Bei einem Rich-Client stellt sich die Frage kaum. Entweder man benutzt Frameworks wie Spring und oder gleich vollwertige Application-Server, die dann vollständig von den "Scopes" des Servlet-Containers abstrahieren und ihre eigenen Schnittstellen definieren, um Daten zwischenzuspeichern. Insofern wären bei der Nutzung von Rich-Clients die Mechanismen des Application-Servers zu nutzen, also SFSB von EJB oder Spring-Mechanismen.

Werden beide Client-Arten verwendet würde ich natürlich ebenfalls SFSB verwenden, damit die Logik der Warenkorbverarbeitung von beiden Client-Arten genutzt werden kann.

 

[Chebura]

Hallo, mir stellt sich die selbe Frage.
Das Problem von dem Scope, wie ich finde davon abhängig, ob man in dem System angemeldet ist:
Man geht z.b auf amazon.
Man ist nicht angemeldet/nicht eingelogt:
1. Artikel ist Warenkorb
2. Im neuen Tab und dem selben Browser-Fenster==>Man sieht den eben bestellten Artikel.
3. Im neuen Fenster des selben Browsers sieht man eben bestellten Artikel.
4. Im anderen Browser sieht man den eben bestellten Artikel nicht.

Welche Rückschlüsse kann man draus ziehen?
Meiner meinen nach, wenn man nach dem MVC geht dann haben wir:
Auf der View: @SessionScoped + @Named
Im Controller: @stateful //Annahme: der Warenkorb-Inhalt wird nicht persistiert
Im Model: gewöhnliche Entity....

Man ist angemeldet:
1. Artikel in den Warenkorb
2. Im neuen Tab des selben Browser-Fensters sieht man, dass man eingelogt ist und den eben bestellten Artikel.
3. Man öffnet neues Fenster vom selben Browser und sieht wieder, dass man eingelogt ist, und den bestellten Artikel.
4. Man logt sich im neuen Fenster eines anderen Browsers ein und man den selben Warenkorb wie in 1;2;3.

Welche Rückschlüsse kann man draus ziehen?
Wenn ich mich anmelde, wird der Warenkorbinhalt persistiert, denn bei dem Punkt 4 im "nicht eingelogten"-Zustand sieht man den Warenkorbinhalt von anderen Browsern nicht.

Nach dem MVC würde ich das genauso machen.
Nur beim Controller würde ich eben die Artikeln speichern lassen, wenn ich angemeldet bin.

Was meint ihr dazu?