Spring: Klassen in anderer "Anmelden"

[SegFault]

Ich hoffe ich kann das problem jetzt genau erklären. Das wird etwas umfangreicher.
Also folgendes:

Ich habe eine RMI application bei welcher ich mich an einen application server anmelden kann.
diese login Methode liefert mir ein ServiceObjekt über dem ich weitere anfregen stelle. Im server wird zu dem ServiceObjekt entsprechende Nutzerrechte gespeichert die ich weiterverwende.
[Java]
myService = RemoteService.login("foo","bar");
[/code]
ich kann in meinen Server jetzt ein Subservice anfordern auf den ich verschiedene subfunktionen ausühren kann.

mySubservice = myService.getSubservice();
mySubservice.liefereDatensätze()...

nun das problem am Server selbst. Damit ich im Subservice die Rechte abfragen kann muss ich wissen über welche Instanz von myService dieser Subservice angefordert wurde. Anfangs hatte ich das im Constructor der mySubservice Implementation übergeben. Da ich aber Spring verwende geht das gar nicht mehr so einfach. Wie krieg ich es jetzt also hin das wenn der client myService.getSubservice() aufgerufen wurde, die Implementation von mySubservice instanziert wird und myService als Objekt angemeldet wird über das die rechte abgefragt werden können. Ich könnte in das interface von mySubservice eine setServiceObjekt methode liefern. Aber das finde ich blöd weil ich das interface für die Spring sache und als Remote interface nutze. Und der client sollte die set... methode nicht kennen. Daher muss es doch auch irgendwie in Spring direkt eine methode geben mit der ich bei.
getBean("MySubservice"); das Serviceobjekt über das der Subservice angefordert wurde zu übergeben bzw in die klasse ein zu tragen.

Ich hoffe das Problem ist halbwegs verständlich.

 

[maki]

Ehrlich gesagt hört sich "subservice" für mich nach dem Problem an, bricht das sog. "Law of Demeter".

 

[SegFault]

wie kann ichs umgehen? Irgendwie muss ich mich um die rechtevergabe kümmern. Da im Server mehrere Clients eingeloggt sein können muss ich den Anfragen die Nutzer zuordnen. Und ich möchte nicht bei jeder Anfrage zusätzlich noch den User oder ähnliches mitsenden.

 

[maki]

wie kann ichs umgehen?

Wie gesagt, imholiegt der Fehler im Design.

Und ich möchte nicht bei jeder Anfrage zusätzlich noch den User oder ähnliches mitsenden.

Warum denn nicht?
Muss ja nicht der Nutzer sein (kann aber), kann auch sowas wie eine SessionId sein.

 

[SegFault]

D.H. beim Login würde ich anstatt myService eine Session bekommen? und mit dieser kann ich mir dann die verschiedenen Services holen?

 

[Noctarius]

Nein die SessionId dient auf Serverseite zur Identifizierung des Users.

 

[maki]

Das liegt doch gnz an dir, es könnte ja auhc mit einem Userobejkt geabreitet werden, oder einem Principal, oder oder oder

 

[SegFault]

Nein die SessionId dient auf Serverseite zur Identifizierung des Users.

Wie setze ich das ganze um. Irgendwie stehe ich da total auf den Schlauch.
Auch die anderen genannten Konzepte verstehe ich (noch) nicht. Bin noch relativ neu auf den gesamten gebiet.

 

[maki]

Dann nimm doch ein Userobjekt und halte die Sachen einfach

Ist dir das "Law of Demeter" klar?

 

[Noctarius]

Beim Login generierst du eine eindeutige ID für jeden User (z.B. die UserId der DB + Timestamp *hust*) und sendest diese an den Client.

Der Client holt sich nun eine Instanz (eine Referenz) des eigentlichen Userservices und übergibt als ersten Parameter bei Methodenaufrufen die UserId und schwupp weißt du auf Serverseite welcher User das ist ;-)

Du kannst damit sogar mehrere gleiche Userlogins an verschiedenen Terminals auseinander halten (dank dem Timestamp ^^).

 

[SegFault]

"Law of Demeter" ist mir klar. Zumindest denke ich das. Soweit ich das verstanden habe, ist das die abhängigkeiten von anderen Klassen innerhalb einer klasse. D.H. ich sollte nicht meine Serviceklasse in einer anderen Klasse anmelden und in späteren Methodenaufrufen mit dieser Klasse weiterarbeiten. Ist das richtig? Arbeiten aber nicht andere Prinzipien genau damit? Model Controll View wurde uns z.B. so beigebracht das Controll Klassen auf genau diesen Weg bei den View Klassen angemeldet werden.

Aber zurück zum Thema: Ziel ist also folgendes

mySession = Service.login("blah","blubb");
subService = Service.getSubService(mySession);

 

[SegFault]

Wie mache ich das? Ich möchte Services mit lokalen Daten an Client übergeben. Leider Arbeitet Spring standardmässig mit Singletons. Was das ganze aushebt. Denn immer wenn ich das objekt exportieren will kommt eine Exception "Object Already Exported" wie kann ich also das ganze umstellen das jedesmal ein neues Objekt erzeugt wird.

 

[Noctarius]

Chapter3.The IoC container
Scope Prototype wäre hier eine Möglichkeit aber die Frage ist, ob du an dieser Stelle den Service nicht lieber von Hand instanzieren magst.

 

[SegFault]

Von Hand kann ich nicht, da der Service ja Db Abfragen enthält. Ich brauche also das Spring Framework um auf die Datensätze zu kommen.

 

[Noctarius]

Naja du kannst ja Daos als Konstruktor-Parameter mitgeben ;-)

 

[SegFault]

Aktuell trenne ich nicht strikt das DAO und das Remote Interface, da die angebotenen Funktionen genau die selben sind.
Warum soll ich zwei interfaces halten wenn diese die gleichen funktionen anbieten?

 

[SegFault]

Mir fällt gerade nochwas auf. Ich könnte das ganze als Singleton verwenden, da ich keine lokalen Klassenvariablen benutzt. Muss ich explizit absichern wenn verschiedene nutzer zeitgleich auf bestimmte Aktionen zugreifen? Ansonsten laufen ja die DB Abfragen jeweils in transaktionen (Die gesamte Klasse ist auf @Transactional(propagation = Propagation.REQUIRED) ) gesetzt. Eigentlich sollte es klappen wenn ich sie als Singleton einsetze?