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:
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
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
Comment