Wie teilt man SFSB Facade auf?

Question

Ich habe einige Probleme, eine Anwendung zu entwickeln, die auf EJB 3-Technologie basiert.

Ich möchte ein Facade-Muster in den Session-Beans verwenden, um meinen Client (eine Webanwendung) von meinen Entity Beans zu entkoppeln.

Ich verwende ein SFSB, um die Benutzersitzung zu verwalten. So

Ich habe eine FacadeLoginRemote Remote-Schnittstelle, die die Methoden zum Client macht doLogin(), doLogout(), etc ... Derzeit wird diese SFSB auch andere Methoden wie getCourse(int id) umfasst, getResource(int id). Nicht alle Benutzer können tatsächlich erhalten den Kurs und erhalten Sie die Ressource, so dass die Fassade einige Prüfungen vor der Rückgabe der Werte an den Client durchführen.

Ich möchte die Fassade teilen, setzen die Methoden getCourse() und getResource() in eine spezielle Klasse für sie, aber unter der FacadeLoginRemote die Funktionen der Überprüfung von Benutzerprivilegien.

Wenn ich einige verschiedene SLSBs mache, werde ich sie dem Kunden aussetzen. Somit hätte der Client die Möglichkeit, sich direkt mit ihnen zu verbinden, indem er die Überprüfungen von FacadeLoginRemote vermeidet.

Bin ich falsch? Gibt es eine Möglichkeit, dies zu tun?

Vielen Dank im Voraus,

Andrea

Answer 1

Zuerst ein Wort der Beratung; Wenn Sie eine Webanwendung erstellen, ist es typischer, dass Sie die Webschicht und die Geschäftsschicht in derselben Anwendung haben. In diesem Fall ist kein Remoting erforderlich. Ihre Session-Beans werden in derselben JVM wie die Web-Ebene ausgeführt.

Das ist nicht zu sagen, es gibt keine legitimen Gründe für die Verwendung von Remote-Schnittstellen (es gibt viele), aber beim Lesen Ihrer Problembeschreibung scheint es mir, dass Sie besser mit lokalen Beans sind.

Oder spricht die Webanwendung von einer Remoteanwendung, die von einer anderen Person auf ihren Servern gehostet wird, und verbrauchen sie Dienste von Ihren EJB-Beans?

In Java EE kann die Authentifizierung im Web-Modul durchgeführt werden. Insbesondere wenn Sie lokale Beans verwenden, wird diese Authentifizierung (der Sicherheitsprinzipal) automatisch an die EJB-Beans weitergegeben. Sie können Ihre EJB-Beans annotieren, um eine bestimmte Sicherheitsrolle zu erfordern. Wenn der Benutzer nicht authentifiziert ist, hat er diese Rolle nicht und der Dienst wird abgelehnt.

In diesem Fall ist es egal, ob der Client versucht, eine direkte Verbindung zu den Beans mit den Methoden getCourse() usw. herzustellen.

Ich frage mich, wie Sie die doLogin() in Ihrem EJB implementiert. Meine Vermutung ist, dass Sie dort etwas Brauchbares gemacht haben, da EJB3 leider nach meinem besten Wissen keine direkte Möglichkeit hat, eine programmatische Anmeldung über eine bestimmte Methode für eine bestimmte Bean durchzuführen. Sicherheit ist meist deklarativ, und Authentifizierungsdetails müssen dann vom Client beim Zugriff auf eine beliebige Bean bereitgestellt werden. Z.B. Wenn Sie Beans von einem Remote-JNDI anfordern, müssen Sie diese Details mit der anfänglichen JNDI-Verbindung zum Remote-Server bereitstellen.