Bean stateless: trovare l'equilibrio tra prestazioni e sicurezza

Question

Ho un client Web JSF e un client Java che utilizzano entrambi lo stesso layer EJB senza stato per la loro logica dell'applicazione. Non sono sicuro di come bilanciare la necessità di prestazioni (limitando la quantità di dati trasportati tra la presentazione e i livelli dell'applicazione) con la sicurezza (nel senso di garantire che tutte le decisioni siano prese sulla base di dati aggiornati).

Capisco che questo è un argomento soggettivo, quindi forse posso renderlo più obiettivo con esempi concreti:

• Devo solo inviare il nome utente agli EJB, quindi caricare l'entità Utente su ciascuna chiamata EJB o invio l'entità Utente dai livelli di presentazione?
• Se ho bisogno di più informazioni rispetto alla sola entità Utente (diciamo che devo caricare un'entità aggiuntiva su ciascuna chiamata EJB), devo inviare il nome utente e la chiave dell'altra entità e caricare entrambe le entità nel livello applicazione, oppure posso inviare entrambe le entità dai livelli di presentazione?
• E se avessi bisogno di ulteriori informazioni per determinate chiamate EJB (> = 3 entità)?

Quando ha senso inviare l'entità effettiva anziché solo la sua chiave, o la risposta non viene mai, ricaricata sempre dal lato del livello dell'applicazione? Dovrei essere preoccupato per le prestazioni? Ho sentito che Hibernate (che sto usando) impiega la memorizzazione nella cache intelligente, il che significa che l'entità Utente probabilmente non verrà ricaricata dal DB ogni volta? Che cosa succede se i miei metodi EJB hanno una granularità molto piccola e le azioni frontend a volte potrebbero causare la chiamata di 3 o più metodi EJB, ognuno dei quali deve caricare l'entità utente?

Un'ultima domanda correlata: intendo utilizzare il principal JAAS per memorizzare il nome utente che viene caricato dagli EJB. Che cosa succede se i miei bean frontali remoti chiamano un gruppo di bean locali senza stato che richiedono anche le informazioni dell'utente, uso ancora l'entità JAAS e carico anche l'entità utente in ognuno di essi o esiste un modo migliore?

Answer 1

Dovresti prendere in considerazione EJB con stato, poiché sembra che i client abbiano bisogno di uno stato non banale per rispondere a una serie di richieste riguardanti lo stesso stato da un utente. Detto questo, i bean con stato sono una specie di orso da scrivere e configurare correttamente.

Per motivi di progettazione, non vorrei che i client inviassero informazioni utente al livello di logica aziendale. Uno, risolve semplicemente il problema sul client, no? caricare, archiviare e inviare queste informazioni? inoltre mi rende nervoso dal punto di vista della sicurezza, lasciare che un livello client presumibilmente meno sicuro invii i dati sensibili dell'utente a un livello backend più sicuro che poi si fida e utilizza tali informazioni.

Ma, davvero, penso che tu abbia già menzionato l'approccio migliore: il caricamento lento di Hibernate. Basta interagire con l'oggetto e lasciarlo caricare i dati su richiesta. Per funzionare bene con Hibernate a questo proposito, l'oggetto Utente dovrebbe essere piccolo, in modo che il caricamento sia abbastanza veloce e spinga tutte le informazioni grandi e pesanti in oggetti figlio o altre entità. Quindi non importa se devi caricare molto l'Utente; è solo un po 'un' puntatore 'ad altre informazioni.

Non penso che cambi cose se usi JAAS, no. Anche se potrei dire, per quello che immagino siano i tuoi scopi, JAAS potrebbe o meno essere utile. Nel tempo necessario per l'integrazione, la scrittura delle autorizzazioni, l'utilizzo di tali autorizzazioni, la gestione delle conseguenze del SecurityManager e così via, probabilmente avresti potuto comunque scrivere un semplice framework di autorizzazioni per te stesso.

Answer 2

se si crea un solo bean, creare una sessione senza stato. personalmente l'ho trovato interfacce vuote humbug