Tra i grandi vantaggi dall'adozione della piattaforma Java enterprise abbiamo più volte citato quello della scalabilità. In questa lezione vedremo come questa caratteristica viene implementata senza alcun effetto collaterale (side effects) sul codice prodotto.
Per scalabilità si intende la possibilità di mantenere inalterate le caratteristiche del sistema al crescere del numero di utenti e quindi delle risorse necessarie a soddisfare tutte le richieste. Per applicazioni web based utilizzate da un ristretto gruppo di utenti (piccole intranet aziendali, ad esempio) il problema non si pone, in quanto, generalmente le risorse delle macchine messe a disposizione sono sufficienti a gestire il carico delle richieste.
Quando però siamo di fronte a sistemi su larga scala bisogna prendere in considerazione l'aspetto delle risorse in maniera opportuna. Immaginate come esempio un sito web come Amazon e le milioni di richieste che letteralmente bombardano il server. È evidente che una singola macchina, indipendentemente dalle risorse hardware presenti, non può essere sufficiente ad erogare il servizio.
Quello che viene fatto in casi del genere è quello di raggruppare un gruppo di macchine parallele (ognuna con le proprie risorse hardware) e bilanciare le richieste in entrata, in modo da suddividere il lavoro equamente e quindi di poter erogare il servizio. Il gruppo di macchine è noto come cluster, e la tecnologia J2EE ne gestisce gli aspetti di implementazione che andiamo a discutere.
Senza un coordinamento ben preciso sarebbe impossibile fornire il servizio per le ragioni più immediatamente evidenti: accesso ai dati, gestione delle sessioni utente (in ambito web).
Non entreremo nel dettaglio di implementazione, in quanto ogni application server ha le sue tecniche ed i suoi modi per coordinare il lavoro tra application server. Ci limiteremo ad elencare le ragioni ed i motivi per cui attraverso J2EE diventa meno difficile la gestione di una questione complessa come questa.
L'implementazione di un cluster generalmente prevede la presenza di una o più macchine su cui viene installato l'application server. Sugli application server verranno definiti opportuni descrittori (la procedura varia per ogni application server) che si preoccuperanno di cercare altre istanze di application server presenti sulla rete (nodi). Una volta definita la topologia dei nodi presenti sulla rete (quindi indirizzi fisici e porte sulle quali destinare determinati servizi) si installano le applicazioni (web o enterprise application) sulle macchine.
Ci sono diverse possibili configurazioni che andranno vagliate di caso in caso, tipo la replica delle sessioni (in modo che un utente che viene indirizzato ad ogni richiesta ad una macchina diversa, mantenga il riferimento ai dati di sessione), la gestione dell'High Avalability (cioè la possibilità di mantenere vivo il servizio anche in seguito alla caduta di una macchina del cluster) ed altri aspetti che generalmente si definiscono in maniera descrittiva (file di proprietà o XML).
La discussione fatta tiene conto di un application server sulla stessa macchina del web server. In testa al cluster comunque sarà necessario predisporre un server in modo da esporre alla rete il servizio in maniera trasparente. La scelta generalmente ricade sul web server Apache, che semplicemente inoltra le richieste verso il cluster (sarà cura del server poi gestirne carico e risposta da dare).
La possibilità di mettere in cluster gli application server implica una cosa particolarmente importante. Lo sviluppatore non dovrà preoccuparsi minimamente di questo aspetto. Infatti abbiamo visto che la gestione è demandata interamente ai meccanismi di middleware dell'application server e la relativa sincronizzazione di informazioni viene gestita in maniera trasparente. Ciò significa che al crescere del numero di utenti (quindi del carico) sarà sufficiente affiancare un'altra macchina da mettere in cluster.
