Kommunikation zwischen zwei Servlets

[mmm]

Hallo,

ich möchte eine kleine Web-Applikation schreiben, die folgendermaßen aussieht:

Javabeans zur Abbildung der Entities ("Modell"), zentrales Servlet "Main" als Controller und einzelne JSP-Seiten als View.

Nun würde ich gerne eine Datenbankverbindung aufbauen, um User zu authentifizieren. Ursprünglich wollte ich das über eine JavaBean (DatabaseBean.java), welche eine Funktion "match(Username, Password) -> boolean" hat - das geht aber soweit nicht, da ich in der DatabaseBean.java kein Objekt vom Typ "UserBean" (da sollen später die User-Daten drinstehen) zurückgeben kann. Ist das allgemein so? Ich meine, okay, klar, Beans sollten ja eigentlich nur aus setter/getter-Methoden bestehen, aber ich dachte, das wäre keine strikte Vorgabe.

Also habe ich mich dran gemacht, ein Datenbank-Servlet zu schreiben, das die Verbindung aufbaut und entsprechende Methoden bereitstellt ( getUserBean(username), match(username, password)).

Nun zum eigentlichen Problem: Die Login.jsp ruft als "action" die Main.java auf (das zentrale Servlet).

Innerhalb dieses zentralen Servlets möchte ich nun prüfen, ob die Daten aus dem Request korrekt sind. Dazu muss ich die Daten irgendwie an das Datenbank-Servlet bringen.

Nur wie?

Nach einiger Suche bei google & co habe ich folgende Möglichkeiten:

1. RMI: Ich verzichte auf das Datenbank-Servlet und implementiere stattdessen einen RMI-Server, der die Methoden bereitstellt. Das Main-Servlet greift dann unmittelbar über RMI darauf zu. Ist zwar etwas aufwendig, aber IMHO vom Design her schön.

2. Ich packe die Username/Password-Daten in die Session und dispatche dann vom Main-Servlet an das Datenbank-Servlet, prüfe dort, packe das Ergebnis in die Session und dispatche zurück zum Main-Servlet. Ist das wirklich 100% sicher? Eigentlich dürfte das kein Problem geben, oder? Denn der User kann ja von remote aus nicht seine eigene Session manipulieren.

Habe ich das alles richtig verstanden? Gibt es nicht einen einfacheren Weg, die Methoden aufzurufen?

Ich nutze Netbeans 5.5 mit eingebautem Tomcat 5.5.

Vielen Dank!

mmm

 

[SlaterB]

ganz einfach: die Login-Logik gehört nicht in ein einzelnes begrenzt zugreifbares Servlet sondern in eine andere Klasse,

das Login-Servlet sowie jedes andere Servlet kann dann diese 3. Klasse aufrufen
(ob nun statische Operation, Singleton oder was auch immer sei mal dahingestellt)

das ganze sollte wahrschein eh etwas genereller aufgebaut werden, der Login z.B. grundsätzlich bei jedem Request geprüft werden

 

[mmm]

Vielen Dank für deine Antwort.

ganz einfach: die Login-Logik gehört nicht in ein einzelnes begrenzt zugreifbares Servlet sondern in eine andere Klasse,

das Login-Servlet sowie jedes andere Servlet kann dann diese 3. Klasse aufrufen
(ob nun statische Operation, Singleton oder was auch immer sei mal dahingestellt)

das ganze sollte wahrschein eh etwas genereller aufgebaut werden, der Login z.B. grundsätzlich bei jedem Request geprüft werden

Der Login-Status wird natürlich jedes Mal bei jeder JSP-Seite geprüft (ob in der Session entsprechende Variablen liegen).

Nur zur Sicherheit, damit ich dich richtig verstanden habe:
Ich baue also eine weitere Klasse "login", die mir z.B. folgende Funktionen zur Verfügung stellt:

- matchPassword(username,password)
- getUserBean(username)

Diese Methoden erwirken dann ihrerseits eine entsprechende Datenbankabfrage. Das habe ich schon mit der Database-Bean versucht, was nicht funktioniert, da ich dort kein UserBean-Objekt zurückgeben konnte (obwohl es eigentlich schon gehen müsste, oder?).

Nur wie macht man das, wenn man es einigermaßen "schön" machen will?

 

[SlaterB]

was genau ist ein UserBan wenn nicht einfach nur eine Klasse mit set + get,
und wieso kann die irgendwo nicht erzeugt werden?

zu schön sag ich mal nix, schön wirds vielleicht mit vielen Schichten, aber das ist eine allgemeine Sache:
Präsentation
|
v
Logikklasse (checkLogin/ getUser)
|
v
UserDao (loadUser/ searchUser, DB-Klasse)
|
v
User (DB-Objekt, z.B. in Hibernate gemappt, mit Referenzen auf andere DB-Objekte)
+ UserBean (einfaches Übertragungsobjekt, maximal mit Referenzen auf andere einfache Übertragungsobjekte)

 

[Guest]

was genau ist ein UserBan wenn nicht einfach nur eine Klasse mit set + get,
und wieso kann die irgendwo nicht erzeugt werden?

zu schön sag ich mal nix, schön wirds vielleicht mit vielen Schichten, aber das ist eine allgemeine Sache:
Präsentation
|
v
Logikklasse (checkLogin/ getUser)
|
v
UserDao (loadUser/ searchUser, DB-Klasse)
|
v
User (DB-Objekt, z.B. in Hibernate gemappt, mit Referenzen auf andere DB-Objekte)
+ UserBean (einfaches Übertragungsobjekt, maximal mit Referenzen auf andere einfache Übertragungsobjekte)

Danke, ich hatte da vorher einen Fehler drin in der Bean.

Nochmal kurz zu den Schichten: Ich versuche schon, weitgehend Präsentation und Logik zu trennen. Präsentation erfolgt nur über JSP, JSPs kommunizieren nicht untereinander sondern nur über ein zentrales Servlet (JSP enthalten auch keine Logik). Daten werden in Beans gehalten. Wo ist deiner Meinung nach hier keine Trennung vorhanden?

Aus verschiedenen Gründen kann/möchte ich eine reine Tomcat-Lösung haben, also fallen Dinge wie CMP, BMP und EJB etc. weg.

Über Hibernate werde ich später nachdenken.

Vielen Dank jedenfalls!

 

[SlaterB]

wichtig:
JSPs machen nur die Anzeige,
sie rufen auf keinen Fall Logikklassen auf um etwa Login zu prüfen,

das machen Servlets die dann zu JSPs weiterleiten,

wenn man Servlets weglässt, na gut dann eben die JSPs,
aber man läst normalerweise Servlets nicht weg

wenn du das mit dem zentralen Servlet so hast, dann geht das ja anscheinend,

ansonsten hast du noch den Satz 'Daten werden in Beans gehalten.',
der trifft wohl auf jedes Programm der Welt zu (und sei das Bean auch nur ein einzelner String oder int),
was soll man dazu noch sagen?
Beans sind gut, ja, besser ein Bean als 10 Strings einzeln in der Session, klar