Le applet sono progettate per essere eseguite nel Web Browser, mentre le servlet sono progettate per essere eseguite nei Web Server. Sia applet che servlet sono, dal punto di vista logico, simili a delle DLL, ovvero delle librerie dinamiche che, rispettando una determinata interfaccia di interazione, estendono altri programmi (nel nostro caso Web Browser e Server). La differenza tra applet/servlet e una DLL convenzionali è che si tratta di byte-code, quindi portabile, e che hanno inerentemente una interfaccia object oriented.

Le servlet (come pure una applet, o i driver di database JDBC , o i motori crittografici, o i look-and-feel della Swing e mille altre cose in Java) mettono a disposizione degli agganci ben precisi per essere invocate. Per esempio la prima condizione per una una Servlet di tipo Http (come vedremo è un caso particolare) deve estendere la classe javax.servlet.http.HttpServlet. In questo modo tutti i metodi standard della servlet sono implementati e ci possiamo concentrare sulla ridefinizione di solo ciò che ci interessa. Notare la differenza con le DLL: l'ultima volta che mi è capitato di sviluppare una DLL, quando ho implementato un PlugIn di Netscape, ho dovuto definire almeno una quarantina di funzioni. Naturalmente ho preso un esempio, lo ho usato come template e ho lasciato come erano la maggior parte delle funzioni modificandone solo 4 o 5 (con il pericolo di sbagliare…). In Java invece sfruttando l'eredità abbiamo le funzioni base già implementate e ridefiniamo solo quello che serve.

Ritornando alle servlet, in realtà abbiamo a che fare con un un paradigma generico per lo sviluppo di estensioni di server: i server possono essere di vario tipo, non devono essere necessariamente Web Server. Per esempio possono essere utilizzate per estendere un Mail Server, un Database Server o un LDAP Server. Comunque il pacchetto standard prevede due package: javax.servlet e javax.servlet.http, nel senso che l'implementazione canonica prevista è per estensioni di Web Server, e quindi per la programmazione Web Server Side. Ovvero le Servlet sono state sviluppate per (usando una terminologia inesatta ma suggestiva) "fare le CGI in Java", ma lasciando la porta aperta ad altri usi. Naturalmente ricordiamo che la CGI è un protocollo (peggio: una convenzione per le variabili d'ambiente) utilizzata per l'interscambio di dati da programmi mandati in esecuzione da un Web Server, e non un tipo di programmi. In realtà le servlet non hanno nulla in comune con le CGI, a parte alcune eredità terminologiche e una certa similitudine funzionale (per esempio si trova nella documentazione una corrispondenza tra le variabili di ambiente CGI e il metodo da chiamare per ottenere la stessa informazione con le HttpServlet). A parte questo l'implementazione della CGI e delle servlet sono totalmente scorrelate. Per le servlet ogni Web server deve usare un modo diverso per intefacciarsi alla virtual machine di Java. Infatti il difficile è tutto lì: passare le richieste che vengono fatte al Web Server alle applicazioni in Java. Per ogni Web Server questo lavoro va fatto in maniera diversa. Si usa ISAPI per IIS, NSAPI per i server Netscape, i moduli (mod_jserv) per Apache, eccetera. Poiché molti web server di ampia diffusione non supportano le servlet, almeno due ditte fanno business producendo del Servlet Engine, ovvero motori per l'esecuzione di servlet (che per la verità fanno molto di più che questo…) Attualmente le servlet sono supportate nativamente su pochi Web Server, quasi tutti scritti in Java: per esempio Jeeves di Sun, Avenida e AcmeServer. I due principali servlet engine sono il JRun della LiveSoftware (www.livesoftware.com) e il Servet Exec della New Atlanta Communications (www.newatlanta.com) che consentono di dotare di servlet una pletora di Web Server: IIS e PWS sotto NT, Apache e i server Netscape sotto NT e Unix, e anche qualche Web Server Mac. La cosa interessante è che entrambi questi servlet engine sono free per un uso base, ovvero per un uso limitato alle funzionalità essenziali offerte dal JSDK (ovvero il Java Servlet Development Kit, il kit base fornito da sun), anche se offrono numerose funzionalità aggiuntive (che però si pagano). Da citare anche il ServletExpress della IBM e il Jserv (quest'ultimo totalmente free, sviluppato dall'Apache Group).

Una volta risolto il problema di legare la JVM al Web Server (problema di chi fa il Servlet Engine e/o il Web Server), il risultato è uguale per tutti. Una mia esperienza reale è stato quella di una servlet di gestione ordini, sviluppata con PWS e Servlet Exec sotto Windows 98 utilizzando come database Interbase. Questa servlet ha girato subito, cambiando solo i parametri del driver con Apache sotto Linux, utilizzando il JRun come servlet engine e sfruttando come database server un AS/400 remoto con DB/2! Alla facciaccia di chi dubita della portabilità di Java solo perché si è fermato ai bachi delle varie versioni del Netscape 2… In realtà per questi exploit di portabilità immediata bisogna fare molta attenzione all'SQL che si usa e ai tipi di dati, tenedosi ad un livello di SQL molto basso (per esempio io non uso nemmeno i campi interi con autoincrementanto), e a non sfruttare caratteristiche "evolute" del Servlet Engine (ed è dura!). Se ci si tiene molto bassi come feature, la portabilità è elevatissima. Avendo preso la buona abitudine di limitare al massimo le funzioni del JSDK che uso normalmente (e faccio da me per esempio per la gestione delle sessioni o i template HTML) ho la fortuna di avere numerose applicazioni che girano su molti server Web con molti servlet engine e quasi sempre non ho bisogno di pagare la licenza del Servlet Engine! In realtà questo è dovuto sia al fatto che, avendo cominciato a lavorare con le Servlet prima che le feature avanzate fossero disponibili, ho dovuto arrangiarmi costruendomi il mio framework, ovvero quello presentato in questo articolo. Questo framework lo offro gratuitamente ai lettori di PDJ. Personalmente continuo ad usarlo e lo preferisco, per i motivi già detti, alle nuove feature disponibili (a pagamento!) come le Java Server Pages (che danno gli stessi problemi delle ASP), Presentation Templates e via discorrendo. Non mi sembra che migliorino le cose in maniera drastica.