Perché le WAR non possono condividere le informazioni sulla sessione?

Ho visto diversi sviluppatori alla ricerca di una soluzione a questo problema: accedere alle informazioni sulla sessione da una WAR diversa (anche se all'interno della stessa EAR) - ecco alcuni esempi: un modo per condividere lo stato della sessione tra diverse applicazioni in Tomcat? , Accedi alla sessione di un'altra applicazione web , file WAR diversi, risorse condivise , Tomcat: come condividere i dati tra due applicazioni? , Che cosa fa l'attributo crossContext in Tomcat? Abilita la condivisione della sessione? e così via...

Da tutto quello che ho cercato, ci sono alcune soluzioni specifiche a seconda del contenitore, ma è in qualche modo " contrario alle specifiche ". Ho anche esaminato le specifiche Java EE senza alcuna fortuna nel trovare una risposta.

Alcuni sviluppatori parlano dell'accoppiamento tra le applicazioni Web, ma tendo a non essere d'accordo. Qual è il motivo per cui si dovrebbero tenere le WAR all'interno della stessa EAR se non si accoppiano? Gli EJB, ad esempio, sono accessibili localmente (anche se all'interno di un altro JAR EJB all'interno dello stesso EAR).

Più specificamente, uno dei miei WAR gestisce l'autenticazione e l'autorizzazione e vorrei condividere queste informazioni con altri WAR (nella stessa EAR). In passato sono riuscito a risolvere problemi simili confezionando WAR come JAR e inserendoli in un singolare progetto WAR (WEB-INF / lib). Eppure questa soluzione non mi piace (richiede uno sforzo enorme per la denominazione dei servlet e così via).

E nessuna soluzione ha risposto alla prima (e più importante) domanda: perché i WAR non possono condividere le informazioni sulla sessione?

Tratta una EAR come una macchina pseudo-virtuale

Una EAR è semplicemente una raccolta di file WAR che condividono configurazioni e librerie comuni, generalmente da JAR. Ciò consente di gestire più facilmente una raccolta di servizi interdipendenti all'interno di un contenitore di applicazioni. Quindi puoi pensare a una EAR come a una semplice forma di macchina virtuale una volta distribuita nel suo contenitore.

Allo stesso modo in cui un processo su una macchina virtuale non può influire su un altro, lo stesso vale per un EAR. Tutte le GUERRE sono isolate per proteggere il loro stato interno.

Autenticazione in scala

In generale, le applicazioni Web devono essere apolidi per scalare bene. Avere molte informazioni nella sessione è un anti-pattern che impedisce questo. Ciò porta a un conflitto tra la natura apolide di HTTP e la necessità di mantenere un'esperienza utente rapida e personalizzata. L'autenticazione è un caso d'uso classico ed è prevalente nelle API chat che richiedono molte richieste autenticate per fornire funzionalità all'utente finale.

Single Sign On e Single Sign Off necessitano di un'attenta segnalazione per funzionare correttamente (considerare il Sign Off parziale), in particolare quando è presente il ridimensionamento orizzontale. La semplice condivisione dello stato della sessione non è quasi mai una buona soluzione e un approccio migliore consiste nell'utilizzare un singolo punto di riferimento per le informazioni utente a cui hanno accesso tutti i nodi del cluster.

Concentrarsi sull'accesso rapido alle informazioni pertinenti memorizzato nella cache produrrà risultati molto più scalabili rispetto a qualche soluzione complessa e fragile di condivisione delle sessioni.

È qualcosa a cui ritengo manchi la funzionalità della specifica EEE JEE: la possibilità di condividere sessioni Web su più archivi Web associati all'interno di una EAR.

I server di app come Weblogic hanno implementazioni non standard per questa funzionalità.

Bene, AFAIKS, non c'è un vero motivo per cui ti piacerebbe farlo. Una WAR è un'applicazione web autonoma, con i propri ambiti (specifici dell'applicazione Web) (come l'ambito della sessione). Se devi condividere funzionalità (codice Java, pagine JSP, file CSS), tra più WAR hai la possibilità molto più sensata di comprimerli come file JAR e distribuirli nel tuo server delle applicazioni. Un pacchetto WAR è una soluzione di imballaggio più complessa e progettata per incapsulare qualcosa di diverso dal semplice "codice / funzionalità comune". Il JAR è un formato più semplice ED è progettato per il packaging e la condivisione di codice e funzionalità. Perché vorresti utilizzare un packaging più complesso e non specifico per quel progetto per condividere qualcosa, quando hai già un formato di pacchetto più semplice e più adatto a quel pacchetto?

Penso che ciò sia stato fatto apposta, per evitare che diverse app Web sovrascrivessero accidentalmente le informazioni sulla sessione. Potrebbe essere utile nel tuo caso, ma in generale, non vuoi che gli utenti rompano l'app o aumentino i loro privilegi solo perché usano due app Web contemporaneamente. Non è esattamente difficile condividere esplicitamente informazioni tra app Web; basta creare una classe con una HashMap statica, utilizzare i GUID come chiavi e trasferirli come parte del parametro URL o HTTP.