di Michele Sciabarrà

La Web Programming è nata con la server side programming. Quelli che in origine erano statici documenti HTML, sono divenuti, grazie al server side programming, pagine dinamiche costruite on the fly per processare moduli e visualizzare i risultati di interrogazioni di database. Il primo linguaggio usato per rendere interattive le pagine Web è stato il Perl, sfruttando la rudimentale, limitata e inefficiente specifica nota come Common Gateway Interface. La CGI è rimasta per anni il principale strumento per la server side web programming. Anche se oggi gli script CGI sono abbastanza diffusi, sono da tempo comparse soluzioni tecnicamente più solide e pratiche per lo sviluppo di applicazioni Web di qualità professionale e respiro industriale. Citiamo ad esempio il Server JavaScript di Netscape, le Active Server Pages di Microsoft o l'IntraBuilder di Borland. Java deve gran parte del suo iniziale successo alle applet, che insieme ai plugin/ActiveX e al JavaScript/VBScript rappresentano la parte client side del web programming.

Tuttavia, sviluppare in ambiente Internet significa nella maggior parte dei casi dover gestire entrambe le parti, tanto il server quanto il client. Facciamo un esempio: supponiamo di dover generare un grafico utilizzando dei dati contenuti in un database. Una buona soluzione è generare una pagina HTML contenente i parametri per una applet che visualizza il grafico. La parte server quindi interroga il database e costruisce una pagina HTML contente la descrizione del grafico, ma la visualizzazione vera e propria viene gestita dalla applet che gira sul client.

Data la necessità di dover considerare entrambi le facce della medaglia, è naturale che molti sviluppatori desiderino utilizzare un solo linguaggio per lo sviluppo di applicazioni sia lato client che lato server. Chiunque abbia tentato di fare server side programming in Java avrà scoperto che sebbene Java è un ottimo linguaggio per molti usi, di per sé non si presta particolarmente allo sviluppo di applicazioni CGI, perché non fornisce nessuno supporto specifico. Anzi le CGI in Java sono goffe e inefficienti e presentano più problemi che in altri linguaggi. Oltre all'overhead considerevole dovuto al bootstrap dell'interprete e al caricamento di librerie non utilizzate per ogni richiesta, Java ha il difetto di non consentire l'accesso all'ambiente, che viene utilizzato dalla CGI per il passaggio di parametri. Per questo motivo si ricorre solitamente da un wrapper in C che invoca l'interprete Java passando l'ambiente sulla riga di comando e utilizzando lo switch standard -D che consente di impostare le System Property. Di conseguenza, ad ogni richiesta il principale fattore di inefficienza dell'interfaccia CGI, la necessità di creare un nuovo processo per ogni richiesta, è addirittura raddoppiata! Infatti occorre prima caricare il wrapper in C il quale poi manda in esecuzione l'interprete Java. Le CGI in Java sono molto lente, e questo difetto si vede ad occhio nudo anche richiamandole da una rete locale. Alle esigenze di rendere pratica la server side programming in Java, JavaSoft ha dato una eccellente risposta, per certi versi definitiva: le servlet.