Perché WAR non può condividere le informazioni sulla sessione?

Tratta un EAR come una macchina pseudo-virtuale

Un EAR è semplicemente una raccolta di file WAR che condividono la configurazione e le librerie comuni, in genere da JAR. Ciò consente di gestire più facilmente una raccolta di servizi interdipendenti all'interno di un contenitore di applicazioni. Quindi puoi pensare a un EAR come una semplice forma di macchina virtuale una volta che è stata implementata nel suo contenitore.

Allo stesso modo in cui un processo su una macchina virtuale non può influire su un altro, lo stesso è vero per un EAR. Tutti i WAR sono isolati per proteggere il loro stato interno.

Autenticazione in scala

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

Il Single Sign On e il Single Sign Off richiedono un'attenta segnalazione per funzionare correttamente (si consideri il Sign Off parziale), in particolare quando lo scaling orizzontale è a posto. La semplice condivisione dello stato di 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 tutti i nodi del cluster hanno accesso.

Concentrarsi sul veloce accesso in cache alle informazioni pertinenti produrrà risultati molto più scalabili rispetto a una soluzione di condivisione di sessione complessa e fragile.

È qualcosa che ritengo manchi di funzionalità dalla specifica JEE EAR: la possibilità di condividere sessioni Web su più archivi Web associati a un EAR.

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

Bene, AFAIKS, non c'è una vera ragione per cui ti piacerebbe farlo. A WAR è un'applicazione web autonoma, con i propri ambiti (specifici dell'applicazione web) (come l'ambito della sessione). Se hai bisogno di condividere funzionalità (codice Java, pagine JSP, file CSS), tra più WAR hai l'opzione molto più sensata di impacchettarli come file JAR e di distribuirli nel tuo server delle applicazioni. Un pacchetto WAR è una soluzione di packaging più complessa e progettata per incapsulare qualcosa di diverso dal semplice "codice / funzionalità comune". Il JAR è un formato più semplice ed è progettato per l'imballaggio e la condivisione di codice e funzionalità. Perché dovresti usare una confezione più complessa e non specificatamente progettata per condividere qualcosa, quando hai già un formato di pacchetto più semplice e più adatto a quello. Pensa ai tag JSTL, al plug-in JQuery Struts, alla sicurezza Spring, vengono tutti come JAR.

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