EJB / Interface / Class Annotationen / Statless & Stateful / remote & local

[JIZZES]

Guten Tag zusammen,

Die Aufgabenstellung: Die Abteilungen aus Berlin und Hamburg will auf Gehaltsdaten zugreifen die Sie zentral mittels eines Servers als EJB Komponente in Frankfurt bereitstellen sollen.

Sie solen dazu eine Klasse SalarayInfoEJB als SessionBean entwickeln die den Abteilungen die float getSalaray (); bereitstellt. Für die eigentliche Gehatsabrechung usw...

Erstellen Sie das Interface abc und die entsprechende EJB Komponente SalaryInfoEJB

Lösung von mir:

Die einzige "Schwierigkeit" beim interface ist mMn. die Annotation, die mich etwas irritiert.
Vor dem Interface muss doch eigentlich deklariert werden ob es sich um @Remote oder @local handelt. In meinem Fall ist die Sache klar: @Remote , da 2 Abteilungen unabhängig und von ausserhalb drauf zugreifen wollen.

In der Musterlösung ist aber keine Annotation vorhanden beim Interface, sondern nur bei der Klasse selber: @stateless und @Remote.

1. Frage: Wäre meine Lösung falsch gewesen, hätte ich das @Remote beim Interface gesetzt? Was für einen Unterschied würde das denn machen?

2. Frage: Unterschied zwischen stateless und stateful: ist das richtig, dass man stateful nur dann verwendet, wenn man bsp. einen Warenkorb hätte, den man sich eben merken muss? Sorry für die vielen Fragen, aber vll. kann mir einer das kurz erläutern.

 

[Steven Hachel]

Huhu,

hier wird es eigtl. ganz gut erklärt, wozu du die Annotation @Remote benötigst.

Nachtrag:
Dieser Link erklärt es sogar noch besser.

Der Unterschied zwischen Statless und Statful ist der, dass eine Stateful EJB Session gebunden ist, es sei denn, du definierst per Annotation die Laufzeit derer. Bei einer Statless EJB sieht das ganze anders aus.
Da entscheidet nämlich der Container (Glasfish, Weblogic), ob der Aufrufer eine neue EJB bekommt, sprich eine vom Server neue generierte Klasse, oder du eine bereits im Speicher liegende zurück bekommst.
Heisst im Klartext, wenn du in dieser Stateless EJB etwas von außen herein gibst, muss es nicht bedeuten, dass du bei einem erneuten Aufruf dieser EJB den Wert zurück bekommst, den du rein gegeben hast. Dieser Wert kann zB. bei einem anderen Aufrufer angezeigt werden, je nachdem, für was sich der Server entscheidet. ^^

viele Grüße
Steven

 

[stg]

1. Frage: Wäre meine Lösung falsch gewesen, hätte ich das @Remote beim Interface gesetzt? Was für einen Unterschied würde das denn machen?
2. Frage: Unterschied zwischen stateless und stateful: ist das richtig, dass man stateful nur dann verwendet, wenn man bsp. einen Warenkorb hätte, den man sich eben merken muss?

Zu 1: Das wäre nicht falsch gewesen. Aber es gibt ein paar kleine Unterschiede bei beiden Ansätzen. Zum einen ist es "a matter of preferences", aber es gibt doch ein paar Unterschiede, wenn du bspw deine API ausliefern willst. In deiner Variante wäre das Interface stark mit der EJB Technologie gekoppelt und der Client, der deine API nutzt muss das zwingend wissen und benötigt auch die passenden Libs. In der Variante aus der Musterlösung muss der Client gar nicht wissen, dass unter der Haube EJB benutzt wird. Es interessiert ihn in der Regel ja auch gar nicht. Für dich als Entwickler ist das aber ein Mehraufwand, insbesondere, wenn mehrere Business-Interfaces implemeniert werden sollen (ggfls auch an mehreren Stellen).
Ich bevorzuge selbst die Variante aus der Musterlösung, aber viel wichtiger finde ich, dass man so etwas (insbesondere, wenn man im Team arbeitet) einheitlich handhabt.

Zu 1: Nur noch eine kleine Ergänzung zu dem, was Steven schon geschrieben hat: Wenn du in der Anwendung @stateful Session Beans verwendest, dann machst du meist was falsch Das ist natürlich überspitzt (und mehr meine Meinung, als tatsächlicher Fakt), aber nach meiner Erfahrung nach gibt es wirklich wenig Anwendungsfälle, in denen man wirklich zwingend eine SFSB braucht.
Ganz allgemein aus dem JEE7 Tutorial hierzu:

Stateful session beans are appropriate if any of the following conditions are true.

• The bean's state represents the interaction between the bean and a specific client.
• The bean needs to hold information about the client across method invocations.
• The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
• Behind the scenes, the bean manages the work flow of several enterprise beans.

 

[Steven Hachel]

Huhu,

also ich würde nicht sagen, dass die Nutzung von @Stateful Beans falsch wäre. Für Warenkörbe oder einfach nur um Werte die Session über im Speicher zu halten, kann nicht falsch sein. Hängt auch stark von der Anwenung ab. Ich denke, wenn @Stateful ein Antipattern wäre, gäbe es sie nicht mehr.

Zudem bestimmt eine CDI Bean zum Beispiel die Lebensdauer einer @Stateful Bean. Man braucht sich also um nix kümmern was Performance und Speicherverbauch angeht.

Man sollte eben nur darauf achten, dass man nicht alles in die Session feuert, um den Speicher nicht unnötig aufzublähen.
Man kann eine EJB sogar mit @Named annotieren, um diese für JSF zu nutzen etc.. Da ist es auch keine Seltenheit, Session weit zu arbeiten. Also, ich möchte sie nicht missen. ^^

viele Grüße
Steven

 

[stg]

also ich würde nicht sagen, dass die Nutzung von @Stateful Beans falsch wäre. Für Warenkörbe oder einfach nur um Werte die Session über im Speicher zu halten, kann nicht falsch sein. Hängt auch stark von der Anwenung ab. Ich denke, wenn @Stateful ein Antipattern wäre, gäbe es sie nicht mehr.

Wie gesagt, mehr meine Meinung und kein Fakt, und ihre Daseinsberechtigung wollte ich der SFSB auch nicht absprechen. Aber selbst beim Beispiel Warenkorb kann man sich streiten. Warum sollte die Business-Schicht sich um die Verwaltung des Warenkorbs kümmern und nicht der Client selbst? Bei unterschiedlicher Arten von Clients kann das sinnvoll sein, aber bei einer einfachen Web-Anwendung ist das z.B. nicht nötig. Da kann man den Warenkorb auch direkt in der CDI Bean (oder was auch immer) halten und seine Geschäftslogik komplett Zustandslos lassen.
Und wie gesagt, ja, es mag durchaus Fälle geben, in denen eine SFSB sinnvoll ist, aber (und da spreche ich wieder nur aus Erfahrung) in den meisten Fällen, die ich gesehen habe, wurden SFSB einfach nur aus Faulheit genutzt, oder weil der Entwickler es einfach nicht besser wusste.

Man sollte eben nur darauf achten, dass man nicht alles in die Session feuert, um den Speicher nicht unnötig aufzublähen.

Du redest jetzt aber vermutlich von der HTTPSession und nicht von der "EJB Session", nehme ich an. Wir sollten das hier klar auseinander halten, um nicht noch mehr Verwirrung zu stiften

Man kann eine EJB sogar mit @Named annotieren, um diese für JSF zu nutzen etc.. Da ist es auch keine Seltenheit, Session weit zu arbeiten. Also, ich möchte sie nicht missen. ^^

Ich kann auch mit dem Gabelstapler rückwärts über die Autobahn fahren. Nur weil etwas möglich ist, macht es das noch lange nicht zu einer guten Idee. EJBs haben in der Präsentationsschicht jedenfalls rein gar nichts verloren!

 

[Steven Hachel]

Manchmal ist es wichtig, Dinge zu wissen, um sie besser zu verstehen. Was nun Sinnvoll ist und was nicht, sei mal dahin gestellt ^^ Letztendlich liegen CDI und EJB auf der gleichen Maschine. Da wird sich Zukünftig so und so ne Menge ändern. Bin gespannt auf JavaEE 8. Vielleicht gibt es bald nur noch CDI.

@EJB hat für mich irgendwie etwas von "altbackenes". Klar, hat seine Berechtigung, aber warum noch länger beibehalten, wenn CDI in der nächsten Version genau das kann, was EJB kann. Seit JavaEE7 hat CDI einen großen Sprung gemacht. Bei EJB passiert irgendiw nix und das hat wohl auch seinen Grund, denke ich.

Spring zum Beispiel macht es gut vor. Da gibt es nicht zichtausend Schichten. Alles eine Frage der Architektur des Systems. Je mehr Schichten um so größer der Klops. Bei einer sauberen Softwarearchitektur, brauche ich die Pseudoebenen nicht mehr.

...und, HttpSession meine ich.

viele Grüße
Steven

 

[JIZZES]

Hallo zusammen!

vielen Dank für die tolle Erklärung! mir ist so einiges klar geworden

 

[Steven Hachel]

Kleine Diskussionen darüber für das hin und wieder bringen ja auch gute Einblicke. Sei froh, dass du nicht mehr EJB unter JavaEE5 kennen gelernt hast. Das war vielleicht gruselig.

Wieso realisiert ihr den Zugriff nicht über einen RestFul Service. Wäre das nicht eine günstigere und vor allem flexiblere Variante? Dieser könnte dann mit verschiedensten Technologien genutzt werden. Wie letztendlich die Inhalte aussehen sollen, kann ja auch per Interface beschrieben werden.


viele Grüße
Steven