Gedanken über stateless vs. stateful

[doensen]

Hallo zusammen!

Zunächst einmal möchte ich erwähnen, dass ich mit EJB an sich noch keine großen Erfahrungen gemacht habe. Ich steige also ganz neu in EJB3.0 ein und bin mir in gewisser Hinsicht nicht sicher, ob ich alles so verstanden habe, wie sich die Entwickler das gedacht haben. Daher bleiben mir ein paar Fragen.

Ich muss eine Anwendung von Grund auf neu entwickeln und muss mir daher erst einmal ein Bild über die Architektur machen. Es sollen JSF und EJB3.0 verwendet werden. In punkto EJB stellt sich dann schonmal eine Frage:

• Stateful oder stateless?

Vielleicht erkläre ich ersteinmal, wie ich es verstanden habe: Stateful Session Beans haben einen Zustand, stateless eben nicht (is ja klar ). Verständlicher ausgedrückt bedeutet es für mich, dass jeder Client seine eigenen SFSB hat, wobei die SLSB sozusagen "static" sind (jeder Client verwendet genau diese Klasse).

Liege ich richtig damit, dass ich (wenn ich eine Anwendung komplett neu entwickle) mich für stateless oder stateful entscheiden kann, oder bin ich je nach Anwendungsfall an das ein oder andere gebunden?

Ich gehe nun davon aus, dass ich frei entscheiden kann. Dann habe ich 2 Architekturen, die mir zur Auswahl stehen (siehe Anhänge).

zu stateless: Die Kommunikation von JSF mit den EJBs dient nur dazu Instanzen der JPA Entities zu bekommen. Die Session (Datenhaltung) liegt also nur bei JSF. Ich muss dazu sagen: die Grafik ist so nicht ganz richtig, weil JSF nicht direkt mit den JPA Entities kommunizieren kann. Es soll nur angedeutet werden, dass auf Instanzen dieser Objekte gearbeitet wird. Das speichern der Daten muss natürlich wieder über EJBs erfolgen.

zu stateful: sowohl JSF als auch die EJBs besitzen eine Session (pro Client). Die EJBs dienen nur als Weiterleitung.


Jetzt würde ich sagen, mit JSF ist es sinnvoller SLSB zu implementieren, damit sich die Sessiondaten wirklich nur an einer Stelle befinden. Die Frage nach Performance stellt sich in diesem Bezug auch: Bei SLSB wird zwischen JSF und EJB immer ein "großes Objekt" übertragen, wobei bei SFSB viele kleine Datenpakete übertragen werden. Gerade bei JSF, wo die Getter und Setter aller sichtbaren Daten automatisch aufgerufen werden, sieht es für mich so aus, als sollte man stateless Beans verwenden.

Was denkt ihr dazu? Befinde ich mich auf dem Holzpfad?

Gruß, Christophe

[ariton]

Also, ich versuch mal möglichst viele deiner Fragen zu beantworten.
Die Frage Stateful oder Stateless stellt sich dir etwas anders als du denkst:
Es ist z.B. so das eine SLSB per Definition keine Attribute enthalten darf um irgendwelche Daten über einen Methodenaufruf hinweg zu retten. SLSB sind so zu verstehen das sie Dieste anbieten die innerhalb einer methode abgearbeitet werden können. wie etwa einen belibigen datensatz aus der DB lesen und dessen Inhalt an den Client weitergeben. SFSB Dagegen Haben einen Zustand, das ist nicht das gleiche wie eine HTTPSession! Sie können mit hilfe von attributen belibige Zustände speichern. SFSB stehen dem jeweiligen Client exclusiv zur verfügung diese verwaltung übernimmt aber im Normalfall der Container. Also mit der Session einer Sessionbean hast Du normal nix zu schaffen. Für Deine Applikation heißt das, dass du sowol SLSB als auch SFSB brauchen wirst. Das mußt du von Fall zu Fall entscheiden ob eine Bean Stateful oder Stateless sein muß. Das Thema Performance ist so 'ne sache. Es ist aufgabe des Applicationservers sich um Performancebelange zu kümmern. Oftmals argumentieren "sehr" erfarene Entwickler mit der Performance und behaupten dann man sollte generell alles nur mit SLSB programmieren. Dann erfinden sie irgendwelche Tweaks um den SLSB doch einen Status zu verpassen weil es manchmal doch nicht ohne geht. Von einer sauberen Architektur ist das dann aber meilenweit entfernt. Wenn ich dich richtig verstanden habe das du planst mit hilfe der SB im prinzip nur an die EntityBeans zu kommen würde ich dir davon abraten das so zu machen. In MVC gesprochen: JSF ist dein Frontend (View), dort gehört logik rein die zum anzeigen der Daten und zu deren Manipulation brauchst. Deine SB's sind deine BusinessLogic(Controller) dort solltest du die Geschäftslogik unterbringen. und die EntityBeans sind die Datenhaltung (Model). Ich hoffe ich hab dich nicht all zu sehr verwirrt.

Besten Gruß

Ariton

[doensen]

Hi Ariton,

Ersteinmal danke für deine ausführliche Antwort.
Größtenteils ist es so, wie ich es mir gedacht habe. Ein Punkt bleibt aber nicht ganz klar. Ich hatte mir letztendlich gedacht, ich bräuchte keine SFSB, weil ich die JSF-Session nutzen könnte. Dann würde ich mit SLSB die Daten bekommen und sie in der JSF-Session bearbeiten. Das würde auch funktionieren. Das wäre aber nicht so günstig, weil ich dann sozusagen Geschäftslogik in die View holen würde, richtig? Also werde ich dann doch mit 2 Sessions arbeiten müssen, mit der von JSF und den SFSB.

Wenn ich jetzt keinen Stuss erzählt habe, habe ich es verstanden, glaube ich

Gruß, Christophe

[ariton]

Hmm, wie erkläre ichs nur am besten.... Die Session von JSF ist eine HTTP-Session, die Session deine Session-Beans ist was ganz anderes. Es ist so wenn du SFSB verwendest. erzeugt der Container eine Instanz der Bean, diese steht dann ausschießlich dem Client zur verfügung für den sie erzeugt wurde. Sollte zu gleichen zeit noch ein Client einen Lookup auf die Gleiche Bean machen bekommt er vom Container einer andere Instanz der Bean zugeteilt. Ist einer der beiden Clients lange inaktiv kann der Server die Bean dieses Clients passivieren d.h. er serialisiert die Bean und schreibt sie auf die Platte. Sollte der Client der zur Passivierten Bean gehört dann wieder Aktiv werden kann der Server die Bean einfach wieder von der Platte lesen und dem Client zur verfügung stellen. Wenn man so will entsteht einen "Session" bei SessionBeans durch die zuordnung einer Beaninstanz zu einem Client das ist aber Serverinternes geficke. damit hast du nichts zu tun. Du arbeitest mit Deiner HTTP-Session in deiner JSF Anwendung.
Wenn Du von Dort einen Lookup auf eine SFSB machst wird der Server dir eine Referenz auf deren Interface lifern. Bei jeder Methode die Du an dieser Referenz aufrufst wird dein Client immer mit der Selben Bean kommunizieren. wie gesagt du darfst dir das nicht wie ne http-session vorstellen. Stell dir folgendes vor. Ein user lockt sich in deine Applikation ein. was hälst du für günstiger, bei jedem methodenaufruf eines SLSB den usernamen mitzugeben oder ein SFSB benutzen das sich den usernamen merken kann/darf? Andersrum geht das auch, wenn du in deiner Aplikation irgendwo wissen willst wieviele user angemeldet sind, muß die BEan die dir diese Information geben kann unbedingt wissen welcher client danach fragt? Also SFSB immer dann wenn du komplexe operationen machen willst die mehere methodenaufrufe an der bean brauchen, beispiel warenkorb. SLSB immer dann wenn du dinge machen willst die sich in einer methode erledigen lassen. ist es jetzt klarer geworden?

[mr_bemar]

Hi,

deine Erklärung ist wirklich 1a. Jetzt hab ichs glaub ich auch verstanden.
Ich frag mich nur gerade in meiner Naivität was der Sinn von dem ganzen ist
(Sorry EJBs sind auch Neuland für mich).

Ich hab das bisher so gemacht, das ich eine einfache Bean erzeugt habe die als Attribut userid und meinetwegen username hatte. Das ganze habe ich mit setAttribute an die Http-Session gehängt und vor jedem userrequest gefragt, ob die "LoggedInUserBean" != null ist ansonsten muss er sich neu einloggen. Das ganze geht auch mit einem Warenkorb oder was auch immer.
Das würde wohl einer Stateless Bean gleichkommen.

Auf die Idee Businesslogik in eine EJB auszulagern bin ich auch noch nicht gekommen, da ich in meiner Action (Struts) dort alle Methodenaufrufe und somit die Logik unterbringe, teilweise auch in Extra Klassen.

Daher meine Frage: Warum EJBs?

Danke schonmal im voraus

Ben