L'obiettivo principale di questo sito Web e' quello di presentarmi agli altri attraverso un mezzo di comunicazione efficace e sempre piu' alla portata di tutti, quale Internet.

Inoltre, la mia intenzione e' anche quella di mettere in pratica le conoscenze di programmazione su reti che ho maturato e che continuo a maturare dal momento in cui sono venuto a contatto con il Web.

Idee

La piattaforma di hosting e' basata su due prodotti sviluppati entrambi dall'Apache Software Foundation: HTTPD (Web server Apache) e Tomcat .

Tomcat e' il fratello del Web Server Apache. Tuttavia, Tomcat e' un prodotto molto piu' complesso di Apache. Tomcat puo'anche essere visto come un Web Server, ma in sostanza non lo e'. In poche parole, lo si definisce un 'application server'. Rispetto al concetto tradizionale del Web Server, e' stato aggiunto un livello di astrazione ulteriore che ha come scopo quello di distinguere, in un'applicazione Web, gli aspetti 'presentazionali' dall'applicazione vera e propria.

Dopo un excursus tra i prodotti che hanno permesso di proporre il mio sito su Internet (Apache Web Server -> Jetty Web Server -> Tomcat) e le questioni filosofiche che hanno introdotto ciascune di queste transizioni, oggi mi trovo ad usare congiuntamente Apache Web Server e Tomcat. Difatti, come ho gia' detto, Tomcat - come Jetty - e' un application server e in quanto tale e' piu' giusto che si occupi dell'esecuzione delle applicazioni. Non era, dunque, del tutto senza senso la mia affermazione passata " ...e' come se su una Ferrari c'avessi messo il motore di una 500". Ma gia' pregustavo di star commettendo un'abnormita'. Sostengo pienamente, quindi, chi lascia ad Apache Web server gli aspetti presentazionali di un sito Web.

Proprio per questo oggi sto usando Apache Web Server per erogare il servizio Web. Quando poi e' necessario che venga lanciata un'applicazione Web, allora la richiesta e' 'proxata' a Tomcat. Il modulo di Apache Web Server che realizza cio' e' ' mod_proxy' ed e' uno dei moduli standard di Apache.

Io ho avuto pero' delle difficolta' generate essenzialmente dalle richieste inoltrate a Tomcat. In sostanza, le risposte di Tomcat (pagine Web) contenevano dei link assoluti che facevano riferimento alla applicazione Web cosi' come veniva 'spiegata' ('deployed') in ambiente Tomcat. Non voglio perdermi in inutili discernimenti a riguardo. Ma chi e' interessato, puo' dare un occhio a questo link: Apache Tutor, dove dove sono spiegate in modo molto chiaro determinate problematiche relative al proxying.

La soluzione che ho trovato piu' condivisibile e' stata quella che impiega un apposito modulo di Apache per la riscrittura dei link nelle risposte (pagine Web) di un 'proxy server'. Tale modulo e' mod_proxy_html, sviluppato da Nick Kew, dell'Apache Software Foundation . Tale modulo non e' ufficiale, ma e' ben documentato sul sito degli sviluppatori di Apache ( http://apache.webthing.com/).

Per il resto, mi auguro che nessuno si faccia un'impressione sbagliata di me, pero' ho sperimentato combinazioni che io stesso definisco 'aborranti'. Di per se', mi reputo abbastanza 'purista' nel mio modo di agire. Mi definisco tale anche nell'integrazione di sistemi informatici. Tuttavia, le mie idee e la mia voglia di realizzarle, questa volta non si sono piegate ai miei principi di impostazione. Ecco che:

  • mi ostino ad usare un sistema operativo Microsoft per ospitare il mio Tomcat.
  • uso ancora la programmazione CGI per lo sviluppo di applicazioni Web basate su Tomcat.
  • ho portato alcune pagine PHP in Tomcat, quando questo predilige codice JSP.
  • e altro ancora.

Tutto sommato gli esperimenti fatti hanno dato alla luce qualcosa che io ritengo 'accettabile'. La mia non e' vanita', come potete ben capire. D'altronde, come si sara' capito dal preambolo a questa sezione, i miei sforzi sono finalizzati a risaltare i 'contenuti', ovvero quello che sta' sotto al sito, a discapito della 'forma', ovvero dei contenuti del sito. Quindi, il mio giudizio positivo lo rivolgo a come le componenti del motore del sito si sono integrate tra loro, al grado di 'equilibrio' che si e' instaurato mettendo tutto insieme e al comportamento predicibile del sistema.

Tecnologie Usate

Tecnologie per rendere il sito interattivo

Tra le numerose soluzioni a disposizione dei programmatori per rendere quanto piu' dinamica possibile l'interazione con l'enorme database sottostante al Web, ho utilizzato:

  • CGI. Questa tecnologia e' stata usata dal sistema di log analysis basato su Awstats.
  • Server-Side includes. La sezione 'Foto', sia dalla parte 'Frontend' che dal 'Backend' e' realizzata in PHP. Le sezioni 'Guestbook' e 'Mailing-list' sono invece realizzate in JSP.
  • Client-side scripting. Il linguaggio di scripting client-side Javascript e' usato abbondantemente nella implementazione del sito. In particolare, ho utilizzato Javascript per il calcolo del codice fiscale. In questo caso, invece, ho preferito utilizzare Javascript in quanto, essendo un linguaggio client-side, garantisce agli utenti che i propri dati (quelli necessari per calcolare il codice fiscale, appunto) non attraversano Internet evitando, quindi, che altre parti vengano a conoscenza di tali dati.

Piattaforma di hosting

Riguardo le tecnologie usate, c'e' poi da spendere qualche parola sulla piattaforma di hosting.

Il motore del sito e', come detto sopra, Tomcat.

Mi sembra obbligatorio dare una breve descrizione al livello applicativo.

In primo luogo, PHP. Potrebbe sembrare che PHP non abbia nulla a che fare con l'applicazione. Esso dovrebbe essere parte dell'ambiente che ospita l'applicazione. E invece no. Tomcat non puo' essere compilato con PHP. Ne' PHP viene caricato come libreria condivisa di Tomcat . In sostanza, pero' qualcuno si e' preso la briga di implementare una servlet che puo' essere associata ai file PHP. Quando, viene richiesta una pagina PHP succede che la servlet accede alla risorsa richiesta e passa il contenuto a PHP. Il risultato viene reimmesso nel normale ciclo di vita di Tomcat.

Per chiunque fosse desideroso di avere una descrizione piu' approfondita, puo' dare un'occhiata al sito di Alexander Merz, un ragazzo appassionato di Tomcat e PHP, che ha steso una chiara - a mio parere - trattazione sull'argomento.

Una altra parte dell'applicazione degna di menzione e' il menu di sinistra, che permette di navigare da una sezione all'altra del sito.

In sostanza, mi sono trovato nella condizione di importare 'as is' la servlet che ho trovato in Jetty che realizzava il menu di sinistra del mio sito. Tuttavia, il menu di sinistra viene aggiunto dalla servlet solo qualora la risorsa che viene richiesta sia una pagina statica (HTML). Nel caso di pagine dinamiche, come pagine JSP o PHP, il tutto e' risultato molto piu' complicato del previsto. La soluzione trovata e' stata quella di riccorrere ai 'filtri'. I filtri sono degli strumenti introdotti nella specifica JSP 2.3. Essenzialmente, si tratta di programmi che vengono eseguiti sul server prima della pagina JSP o della servlet a cui sono associati. Ho quindi implementato un filtro che interviene sulla risposta HTTP, costruendo il menu di sinistra e attaccandolo al risultato dell'interpretazione della pagina dinamica, prima che quest'ultima venga inviata al browser del visitatore.

Anche per questa tecnologia ho dei riferimenti qualora qualcuno voglia approfondire l'argomento. Si tratta del libro SERVLETS and JAVA SERVER PAGES di Marty Hall, edito dalla Sun Microsystems Press/Prentice Hall PTR . Al capitolo 9 troverete un'esaudiente dissertazione sui filtri.

Sempre rimanendo in tema di aspetti applicativi del sito vorrei esporre le mie considerazioni che ho potuto rilevare usando due linguaggi di server-side include diversi (JSP e PHP).

Non e' che sia un esperto programmatore, ma fino ad oggi ho avuto esperienze di Web Programming e avevo usato solo PHP. La sua flessibilita' e' indiscutibile. Mette a disposizione uno svariato numero di librerie per interfacciarsi ad un altrettanto svariato numero di tecnologie.

D'altra parte lo sviluppo in PHP e' particolarmente favorito anche per la semplicita' di debugging, anche senza un opportuno ambiente di sviluppo.

La stessa cosa non posso dire per JSP.

E' vero, ho avuto modo di lavorare per la prima volta con una ambiente di sviluppo di applicazioni per Tomcat, quale NetBeans IDE 5.0, che e' veramente semplice e comodo, e ti fa rendere conto di quanto conveniente e' lavorare con un'application server, piuttosto che con un semplice Web server, specie quando un'applicazione Web acquisisce crescente complessita'.

Ma oltre a questo mi sono dovuto scontrare con delle asperita' notevoli.

A parte la naturale difficolta' sintattica dovuta all'approccio con un nuovo strumento di sviluppo, c'e' stata la difficolta' di reperire le facility per realizzare nuove funzionalita' per il sito. In particolare, ho impiegato le seguenti librerie:

  • Delle librerie basate sulle API JavaMail per l'invio dei messaggi di posta elettronica.
  • MySQL Connector/J che tramite le API JDBC, permette al mio codice JSP di accedere alla base di dati MySQL.
  • Le API java.util.regex per effettuare un piu' efficace controllo dell' input per le pagine dinamiche del mio sito.

Tra le features di JSP 2.3 che ho avuto modo di usare (e di apprezzare) ci sono i sono i tag personalizzati, che permettono di snellire notevolmente il codice JSP, separando i contenuti dalla presentazione. Ho definito dei tag personalizzati, sviluppando degli appositi gestori di tag, per:

  • Inviare e-mail
  • Controllare l'input
  • Fare il padding dell'input

In quest'ultimo caso, e' stato necessario fare in modo che il gestore di tag restituisse un output al codice JSP, per poi elaborarlo successivamente. Per questo ho fatto ricorso alla classe TEI (TagExtraInfo), estendendola.

Captcha

Un ulteriore considerazione sul sito riguarda la sezione del guestbook. Contendendo questa un modulo HTML preposto all'inserimento dei commenti, era soggetto all'inserimento abusivo di commenti pubblicitari da parte di agenti non-umani. Come risultato, mi sono ritrovato spesso il guestbook invaso da tali commenti. E ogni volta sono dovuto andare a pulire 'a manina' queste inserzioni.

La risposta a questo tipo di attacchi, oggi e' rappresentata dalle 'immagini captcha'. Si tratta di immagini create 'pseudo-casualmente' (il piu' delle volte a partire da valori 'pseudo-casuali gia' disponibili, come ad esempio, l'identificativo della sezione). La proprieta' peculiare di questo tipo di immagini e' che lasciano leggere - a volte non senza difficota', una stringa di lettere e numeri. Il motivo della possibile difficolta' per l'occhio umano nel leggere questa stringa dall'immagine, e' che le lettere sono 'sformate', al fine di rendere difficile la lettura attraverso l'impiego di applicativi (come per esempio, OCR - Optical Character Recognition).

Questa stringa, applicata al mio guestbook, mi ha permesso di salvaguardare i commenti dall'essere sommersi da commenti che esulano dalle finalita' di questo strumento di interazione. Il tutto a discapito di una complessita' nell'inserire i commenti per voi amici, che talvolta puo' risultare 'snervante'.

Mi scuso per questo e chiedo una vostra - piu' che mai - profonda comprensione.

Il mio consiglio per coloro che vogliono lasciare dei messaggi (con mio immenso piacere) e' di fare la massima attenzione nel copiare la stringa letta dall'immagine captcha nell'apposita casella di testo. L'errore causera' la generazione di un nuovo identificativo di sessione e di una nuova immagine captcha, che non verranno mai (o quasi mai) verificati dalla servlet di controllo.

L'unica soluzione sara' quella di salvare il messaggio e cliccare di nuovo, nel menu di sinistra, sul link Guestbook , al fine di rendere nuovamente consapevole la servlet di controllo dell'identificativo di sessione.

Database

A completamento del potenziamento del guestbook, c'e' da segnalare il passaggio a MySQL come metodo per gestire i dati trattati.

Relativamente a questo aspetto, ritengo opportuno fare un'ultima considerazione, relativa al livello dei dati. La dinamicita' di un sito e' desiderabile, perche' tende ad annoiare meno il visitatore (infatti presenta delle forme di interazione che un sito statico, in quanto tale, non ha). Proprio per questo che il mio sito si evolve con l'obiettivo di includere sempre piu' pagine interattive. L'interattivita' richiede la presenza di 'contenitori di dati' dal lato server, capaci di raccogliere le informazioni che il visitatore inserisce.

In questa nuova versione del sito ognuno dei 'contenitori di dati' e' rappresentato da tabelle di un database.

In particolare, oltre che per la sezione Guestbook - come sopra detto, ho impiegato le tabelle database per la realizzazione della sezione Mailing-list e della sezione Foto.

Il gestore di database usato e', naturalmente, MySQL. Le mie considerazioni su MySQL sono molto positive. MySQL, per molti aspetti, non ha nulla da invidiare a prodotti commerciali come Oracle e DB2. Inoltre, e' un prodotto open source e non costa nulla a meno che non si faccia uso a scopo di lucro.

Grazie alle vaste funzionalita' che mettono a disposizione PHP e JSP per manipolare una base di dati in ambiente MySQL, ho potuto realizzare:

  • Un semplice back-office che mi permette di definire nuovi gruppi di foto, inserire/cancellare le foto in un gruppo, modificare le didascalie delle foto e cosi' via.
  • La memorizzazione dei messaggi inviati alla mia mailing-list e per poi farli leggere dalla stessa sezione, cliccando sul link Email Inviate.

Naturalmente, il tutto e' si accessibile tramite Web, ma solo tramite una password di accesso che non e', ovviamente, disponibile a tutti.

Autenticazione

L'autenticazione e' gestita da Tomcat.

Tomcat puo' essere configurato per supportare la container managed security che permette di accedere a dei contenitori (Realm) per autenticare l'accesso degli utenti a delle risorse specifiche.

Tomcat mette a disposizioni diversi modi per accedere a questi contenitori. Uno di questi e' usato per l'accesso alla gestione delle funzionalita' di questo sito.

CSS e Roller

Naturalmente, l'evoluzione delle tecnologie usate su Internet si riflette, piu' o meno di pari passo, anche sul mio sito. In particolare, ho cercato di adattare il mio sito all'evoluzione del World Wide Web nota con il nome di 'Web 2.0' (anche se poi gia' da qualche anno che si parla di Web 3.0). Sostanzialmente, il Web 2.0, prevede l'uso massiccio dei CSS ( cascading style sheet) che non sono altro che script che descrivono la formattazione di un testo HTML. La finalita' per cui sono stati introdotti e' evidentemente quella di separare la parte di un documento HTML che descrive la sua formattazione, dal contenuto vero e proprio. L'utilizzo dei CSS, congiunto a Javascript e altre infrastrutture di sviluppo in ambiente Web, come ad esempio AJAX, consente la realizzazione di applicazioni Web con un grado di dinamicita' notevolmente superiore a quelle che si vedevano nella 'prima era' del Web.

L'introduzione dei CSS, ha 'deprecato' l'uso di molti attributi per i tag HTML.

Da tutto cio', e dalla voglia di documentarmi sull'innovazione tecnologica in questo ambito, ne e' conseguito l'aggiornamento del sito e la conseguente introduzione dei CSS.

In particolare, ho eliminato qualsiasi elemento di formattazione, suddiviso le pagine in tanti blocchi logici (attraverso l'uso del tag HTML 'div') e definito un CSS che determina la formattazione delle pagine del sito, essenzialmente senza alcuna differenza rispetto a prima.

Un indubbio vantaggio di questa modifica e' che, se un domani vorro' cambiare il layout del sito dovro' modificare solamente il CSS.

C'e' da dire, comunque, che l'aggiornamento non e' stato del tutto indolore, visto che il 'grosso' delle modifiche e' stato apportato al filtro che definisce il menu verticale di sinistra. E' stato, quindi, necessario intervenire sul package Java org.mortbay.webapps.jetty modificando la classe JettyPage, che e' una estensione della classe Page contenuta nel package Java org.mortbay.html.

Purtroppo, non sono riuscito ad eliminare del tutto l'uso delle tabelle HTML, che vengono ampiamente usate dal filtro nella sua versione originale. Il massimo che sono riuscito ad ottenere e' stato di inserire il body della pagina dentro una tabella con una sola riga e una colonna.

L'altra modifica grossa, invece, e' stata quella apportata nella sezione 'Blog' del sito. Questa sezione contiene il mio blog. Il motore usato per pubblicare il (e, in generale, per la gestione del) mio blog e' Roller.

Roller e' un progetto dell'Apache Software Foundation, ed e' un gestore di blog (piu' tecnicamente, un weblogger).

Difatti, una peculiarita' di Roller e' quella di poter personalizzare l'interfaccia utente. Chiaramente, una cosa che stonava dal momento che questa sezione e' stata aggiunta al sito era proprio la disomogeneita' di interfaccia tra il blog e il resto del sito. Ho approfittato, quindi, di questa fase di 'upgrade' per uniformare il tutto dal punto di vista presentazionale. Il tema attuale del blog usa, quindi, il CSS del sito.

Velocity

Sebbene il tema attuale del blog usa un CSS in comune con il resto del sito, e' stato anche necessario modificare il layout del tema originale del blog per farlo corrispondere a quello del sito, almeno per le parti comuni. Cio' ha richiesto l'uso di una tecnologia ulteriore che e' usata da Roller per definire i temi, ovvero Velocity.

Velocity e' un progetto dell'Apache Software Foundation, ed e' un linguaggio di template usato per referenziare oggetti implementati in Java.

Conclusioni

Che dire! E' stata (e continuera' ad esserlo) una bellissima esperienza ravvicinata con nuove problematiche e con molteplici soluzioni per ciascuna di esse.

Tuttavia, non mi sento di avere assimilato che la punta di un iceberg di conoscenza degli argomenti trattati.

Sono sempre disponibile (nei limiti dei miei impegni) a elargire questo piccolo tesoro a chi e' vuole beneficiarne.