Le architetture n-tier
La cresente necessità di accesso da parte di tutti i membri di un'organizzazione al sistema informativo, unita alle necessità di garantire la sicurezza dei sistemi e di accedere sistemi concepiti per lavorare in altre situazioni (es. utilizzando terminali), sta alla base dell'organizzazione n-tier.
Un'architettura n-tier è costituita da n sistemi che contribuiscono in successione, a portare a termine una computazione. In Figura 1 è schematizzata questa struttura.
 

Tra ogni coppia di livelli esiste una relazione client-server e l'interazione viene propagata dal primo all'ultimo livello dell'architettura a viceversa. In ogni passo sono coinvolti programmi che si occupano di rispondere alle richieste eventualmente appoggiandosi ai livelli successivi.
Bisogna fare attenzione però a non confondere un tier con un computer: in ogni tier possono infatti essere coinvolti più calcolatori. Le richieste vengono lavorate dai vari tier fino al loro completamento.
Il modello n-tier si è affermato proprio perché riesce a identificare "isole" di calcolo che possono essere associate alle reti su cui risiedono le risorse su cui un programma opera.

Abbiamo discusso la strutturazione del modello n-tier, pensiamo ora a capire come questa venga messa in pratica. Il numero magico da sostuituire a n per rendere concrete le chiacchere fatte finora è 3. Le applicazioni three-tier prevedono un primo livello costituito dai clienti, questi si connettono al secondo livello in cui vengono elaborate le richieste. Nel livello intermedio si gestisce l'elaborazione della richiesta accedendo a dati che risiedono sul terzo ed ultimo livello.
Con questo modello è possibile ad esempio descrivere un'applicazione sul Web: il browser si collega al web server che per risolvere le richieste si appoggia ad un server database che gestisce i dati necessari all'applicazione.
È importante osservare come l'interfaccia tra i livelli sia ben definita: questo aiuta a effettuare verifiche di sicurezza sulle comunicazioni. Inoltre è possibile separare il livello dei clienti dai restanti due utilizzando un firewall.
Basandosi su questo modello sono nati framework come Microsoft DNA e Java EJB capaci di gestire automaticamente le richieste dei clienti a patto che il programmatore definisca il cliente e la cosiddetta business logic. In entrambi i casi il programmatore è responsabile della programmazione di componenti che saranno poi amministrati dal runtime. Il runtime d'altra parte sarà responsabile per la gestione della concorrenza degli accessi risparmiandoci così un certo numero di linee di codice.

Il piano dell'opera
Negli articoli  che seguiranno troverete allegati pezzi di codice che vi consentiranno di costruire la vostra soluzione 3-tier alla modica cifra di una connessione! Per le costolette necessarie a formare i 4 volumi al termine delle 52 uscite vi faremo sapere come fare.
Scherzi a parte, dopo aver introdotto il modello 3-tier, nei prossimi articoli ci occuperemo delle architetture 3-tier in Java. Come primo obiettivo ci porremo quello di realizzare applicazioni che accedono a database attraverso un applet Java in una pagina Web. Ciò ci consentirà di ripassare le applet e il modello di sicurezza a cui devono sottostare. L'accesso a database secondo tale strutturaè inoltre molto diffuso e quindi merita di essere raccontato.
Dopo aver realizzato il primo esempio ci dedicheremo ad un'attività decisamente più istruttiva: ci programmeremo in Java il nostro framework personale per realizzare applicazioni 3-tier. Realizzeremo quindi una struttura, che possa essere utilizzata dal Web, che ci consenta di definire i componenti gestiti automaticamente per servire le richieste.
Prima di lasciarci anticipiamoci un po' di lavoro e ripassiamo in fretta le limitazioni imposte ad un applet Java.
 
 
 

Applet e sicurezza
Quando un browser mette in esecuzione un'applicazione senza che l'utente possa controllare questa attività è necessario prevedere dei meccanismi che le impediscano di eseguire operazioni potenzialmente dannose. In assenza di controlli di sicurezza infatti un applet potrebbe inviare informazioni riservate in rete oppure danneggiare una macchina cancellando file.
Nella sua prima formulazione, il modello di sicurezza a cui dovevano sottostare gli applet era noto come modello sandbox, ovvero scatola di sabbia. Il nome doveva richiamare una buca nella sabbia in cui viene lasciato un bambino al mare per impedire che possa combinare pasticci. Successivamente il modello, rivelatosi sufficientemente sicuro è stato dapprima esteso con meccanismi di firma elettronica nella versione 1.1 del linguaggio e infine rivoluzionato nella versione 1.2 del linguaggio.
A causa del rapido sviluppo di Java nei browser è disponibile la versione 1.1 del linguaggio (a meno di non fare ricorso all'uso del Java plugin), cerchiamo quindi di capire come funzioni il modello di sicurezza sandbox e come questo possa essere in parte superato grazie ai cosiddetti applet firmati.
L'interprete che esegue le applet per conto di un browser è completo: include quindi tutta la libreria standard del linguaggio, comprese le classi per interagire con i file sul disco della macchina su cui è in esecuzione l'applet. Esiste perì un oggetto, chiamato SecurityManager, che è responsabile di verificare ogni operazione eseguita dall'applet. Se l'applet esegue un'operazione illegale viene sollevata un'eccezione di tipo SecurityException.

Cerchiamo quindi ora di capire cosa può fare l'applet e cosa è invece vietato dal SecurityManager.  Per distinguere cosa è permesso da ciò che è proibito basta tenere presente che sono vietate tutte le operazioni potenzialmente pericolose per la sicurezza e la riservatezza dei dati sulla macchina locale. Quindi non si possono né leggere né scrivere file sul disco della macchina su cui in esecuzione l'applet. Un'altra limitazione meno ovvia é quella di impedire le connessioni di rete eseguite dall'applet verso la rete. Sono consentite infatti solo le connessioni al server da cui è stato caricato l'applet. Questa limitazione serve ad impedire che si possano fare attacchi a nome di altri: supponiamo che un applet possa aprire connessioni a un server qualsiasi, in questo modo potrebbe mandare posta elettronica a nostro nome senza che noi ce ne possiamo accorgere!
Terminiamo la panoramica sulla sicurezza dicendo che nei browser che supportano la sicurezza è possibile che un applet esca dalla sandbox se firmato elettronicamente. Per firmare un applet è necessario uno strumento che normalmente è disponibile sul sito del browser e bisogna disporre di un certificato elettronico che consenta di firmare applet. In tutti i casi il browser chiederà all'utente, dopo aver verificato la provenienza dell'applet, se l'applet è autorizzato ad uscire dalla sandbox. Lo schema della sicurezza appena descritto è riportato in Figura 2.

Conclusioni
In questo articolo introduttivo abbiamo visto la struttura n-tier e come questa sia utilizzata (con n che vale 3) per realizzare applicazioni distribuite. Nelle prossime puntate vedremo come implementare in Java architetture secondo questo modello. Già ora consiglio di rileggere la serie di tre articoli usciti alla fine dello scorso anno su Mokabyte riguardanti la serializzazione degli oggetti attraverso il Web. Utilizzeremo infatti molte tecniche presentate in quegli articoli nella realizzazione delle nostre applicazioni.