Spring und custom scopes
Thomas Haaks
wir bauen gerade ein auf JSF, Spring und Hibernate basierendes
Kundenportal um in eine reine Webservices-Diensteschicht.
Dies ist mit Glassfish, EJB3 Stateless SessionBeans und Webservice-
Annotations auch nicht unmöglich.
Den "technologischen Durchstich" haben wir und unsere SessionBeans
bekommen prima Springbeans injected.
Da sich das Kundenportal aber eines langsamen Legacy-Systems bedient,
haben wir gelesene Kundendaten in session scoped beans gepuffert. Dies
ist in einer HTTP-Session-basierten Umgebung ja auch kein Problem. Und
natürlich sind diese session scoped beans auch in einigen Singleton-
Beans (Daos und Services) injected (dank <aop:scoped-proxy/>).
In der neuen Frontend-losen Webservices-Diensteschicht sieht das
leider ganz anders aus. An den Daos und Services wollen wir möglichst
wenig umbauen. Daher müssen wir im Prinzip über Login- und Logoff-
Webservices mit selbstgenerierten Session-IDs so etwas wie eine
Session simulieren, um darin die Kundendaten weiterhin zu puffern. Nur
wie erzeugen wir jetzt die zugeörigen "session" scoped beans und
lassen diese wieder injecten?
Meine Idee war, einen custom scope zu bauen (Implementieren des
Interfaces org.springframework.beans.factory.config.Scope). Nur wie
sorge ich dafür, dass beim Aufruf des Login-Webservices eine neue
custom scope-Instanz aufgemacht wird, in der die custom scope-Beans
dann gehalten werden? Und beim Aufruf des Logoff-Webservices müssen
natürlich alle custom scope beans der aktuellen custom scope Instanz
freigegeben werden.
Muss ich noch irgendwo einen Listener implementieren und den über die
Webservices triggern? Oder kann ich in den Webservices selbst eine
neue custom scope-Instanz erzeugen?
Hat sich schon jemand mit den custom scopes in einem ähnlichen
Problemfeld beschäftigt und kann ein paar Tips geben?
Danke und Gruß,
Tommy Haaks
Eberhard Wolff
bevor wir jetzt die technischen Themen der Scopes diskutieren: Zumindest im Cluster ist die L?sung suboptimal, da dann die Session (mit potentiell viel Daten) replizier wird. Generell w?rde ich versuchen, Sessions klein zu halten, weil sonst eben die Speicher-Belastung steigt. Au?erdem k?nnte es bei einem Cache gut sein, dass man bessere Ergebnisse hat, wenn mehr User auf den Cache zugreifen k?nnen.
Das manuelle Nachbauen einer Session-Verwalltung w?re wg. Speicherverwaltung, Time Outs, Cluster-Replikation ebenfalls etwas, was ich pers?nlich nicht anfassen w?rde.
Bzgl. der Scopes: Die rein technische Implementierung ist nicht so komplex, ich habe selbst zum Beispiel eine f?r eine generic DAO-Implementierung geschrieben.
HTH,
Eberhard
--
Eberhard Wolff
Regional Director
SpringSource GmbH
Sitz der Gesellschaft: Brentanostr. 52a - D-12163 Berlin
Gesch?ftsf?hrer: Steven Schuurman, Rod Johnson
Amtsgericht Charlottenburg - HRB 103773 B
--- original message ---
From: Thomas Haaks <tommy...@gmail.com>
Subject: [sugg] Spring und custom scopes
Date: 7th July 2008
Time: 8:52:49 am
Hallo zusammen,
wir bauen gerade ein auf JSF, Spring und Hibernate basierendes
Kundenportal um in eine reine Webservices-Diensteschicht.
Dies ist mit Glassfish, EJB3 Stateless SessionBeans und Webservice-
Annotations auch nicht unm?glich.
Den "technologischen Durchstich" haben wir und unsere SessionBeans
bekommen prima Springbeans injected.
Da sich das Kundenportal aber eines langsamen Legacy-Systems bedient,
haben wir gelesene Kundendaten in session scoped beans gepuffert. Dies
ist in einer HTTP-Session-basierten Umgebung ja auch kein Problem. Und
nat?rlich sind diese session scoped beans auch in einigen Singleton-
Beans (Daos und Services) injected (dank <aop:scoped-proxy/>).
In der neuen Frontend-losen Webservices-Diensteschicht sieht das
leider ganz anders aus. An den Daos und Services wollen wir m?glichst
wenig umbauen. Daher m?ssen wir im Prinzip ?ber Login- und Logoff-
Webservices mit selbstgenerierten Session-IDs so etwas wie eine
Session simulieren, um darin die Kundendaten weiterhin zu puffern. Nur
wie erzeugen wir jetzt die zuge?rigen "session" scoped beans und
lassen diese wieder injecten?
Meine Idee war, einen custom scope zu bauen (Implementieren des
Interfaces org.springframework.beans.factory.config.Scope). Nur wie
sorge ich daf?r, dass beim Aufruf des Login-Webservices eine neue
custom scope-Instanz aufgemacht wird, in der die custom scope-Beans
dann gehalten werden? Und beim Aufruf des Logoff-Webservices m?ssen
nat?rlich alle custom scope beans der aktuellen custom scope Instanz
freigegeben werden.
Muss ich noch irgendwo einen Listener implementieren und den ?ber die
Webservices triggern? Oder kann ich in den Webservices selbst eine
neue custom scope-Instanz erzeugen?
Hat sich schon jemand mit den custom scopes in einem ?hnlichen
Problemfeld besch?ftigt und kann ein paar Tips geben?
Danke und Gru?,
Tommy Haaks
Thomas Haaks
erstmal danke schön für die Antwort.
Unsere Herausforderung ist eben, das komplette Frontend durch die PHP-
Lösung eines Lieferanten auszutauschen. Somit werden 5-7 PHP-Server-
Applikationen via Webservice-Aufrufen unsere Backend-Schicht benutzen
anstatt der bisherigen HTTP-Sessions der Kunden, die direkt mit ihren
Browsern auf unser System kamen.
Die Menge der gehaltenen Daten im "Cache" ändert sich dadurch nicht,
es sind immer X Datensätze pro Kunde. Auch die Sessionlänge ändert
sich nicht, da ja die PHP-Server-Applikationen die Daten benötigen,
solange der Kunde in deren Frontend aktiv ist.
Der einzige Unterschied ist halt, dass wir nicht unmittelbar erkennen
können, wieviele Kunden-Sessions existieren, da wir ja nur mit den 5-7
PHP-Servern kommunizieren.
Die Cluster-Problematik ist uns bewußt. Wir wollen noch untersuchen,
ob wir die PHP-Server via zwischengeschalteten Apache Loadbalancern
"überreden" können, während einer HTTP-Session immer nur mit dem
gleichen unserer Backend-Server zu kommunizieren. Ansonsten haben wir
überlegt, einen distributed cache einzusetzen (Gibt's da Empfehlungen?
Was klappt prima im Glassfish?).
Inzwischen habe ich dank dieser Infos (http://jroller.com/eu/entry/
implementing_efficinet_id_generator und http://www.jroller.com/eu/entry/more_fun_with_spring_scopes)
einen eigenen Custom Scope implementiert, der sich die aktuelle
Session-ID jeweils aus einer ThreadLocal holt, die vom gerufenen
Webservice/SessionBean gesetzt wird.
Das scheint auch tadellos zu funktionieren und ich denke, der
CustomScope wäre auch der zentrale Punkt, wo ein distributed cache
eingebaut werden könnte.
Timeouts wollten wir durch eine ScheduledTimerTask erledigen.
Für bessere Ideen/Vorschläge sind wir jedoch offen ;-)
Aktuelle Fragestellung ist, wie ich Objekte aus dem Scope (bzw. den
gesamten Scope für die "Session") wieder löschen kann. Dies wäre der
Fall, wenn der logoff-Webservice gerufen wird oder der Timeout der
ScheduledTimerTask zuschlägt.
Danke und Gruß,
Tommy Haaks
wrote: