In un qualsiasi colloquio tecnico è oramai impossibile non sentir nominare Java; ancora di più, nei discorsi con i colleghi si scopre ad un tratto che non esiste nessuno che non lo usi da sempre, o che non ne stia verificando la produttività. D’altro canto quando si parla della praticità di Java, i giudizi in merito si fanno tutt’altro che omogenei, e non è facile sentire opinioni assolutamente contrastanti sul suo valore, sul suo attuale spettro di utilizzo e sulle sue prospettive future. Forse, il problema è che in ogni valutazione di questa piattaforma si fondono questioni politiche e di principio che, per loro natura irrazionali, rischiano di impedire, o quantomeno di traviare, la possibilità di un giudizio obiettivo sulle sue capacità. 
Al di là di ogni opinione personale, infatti, appare evidente che nell’enorme marea di protocolli ed API associati al linguaggio della Sun sia possibile rintracciare due ‘anime’ distinte: l’utilizzo lato client - all’interno di Applet, o in applicazioni stand-alone - e l’utilizzo lato server, associato ai Servlet, agli Enterprise JavaBean, agli Agenti, alle API ed ai servizi di Transaction Management, agli Application Server ed ai protocolli di programmazione distribuita, primo fra tutti CORBA. 
Purtroppo, e nonostante una favorevolissima campagna d’opinione, gli insormontabili problemi di performance e di portabilità reale che affliggono le soluzioni Pure Java lato client (un discorso a parte va fatto per il recente Microsoft Visual J++, il cui intimo legame al mondo Windows permette di risolvere i problemi di prestazioni legati alla complessità di alcune librerie, come le Swing API) hanno impedito a questo linguaggio, almeno sino ad oggi, di affermarsi nel mondo desktop. 
La difficoltà di risolvere le questioni prettamente velocistiche e le eccessive richieste di risorse proprie di questo ambiente sono alla base del ritardo nel rilascio dell’ultima versione del Java Development Kit, e sono ormai così evidenti da aver convinto la Sun a rallentare la spinta di Java in questo settore ed a caratterizzarlo sempre più come una soluzione server-side, sino ad arrivare, si vocifera, alla realizzazione di un Server-only JDK.
Ora, se l’evoluzione di Java nel mondo desktop sta attraversando una fase di stallo, la situazione si presenta in maniera radicalmente opposta dal lato server, dove tutte quelle caratteristiche che ne rendono problematico l’utilizzo nel mondo client si trasformano invece in punti di forza addirittura cruciali. È infatti opinione di chi scrive, opinione confortata dal favore che il mercato sta riservando a questa tecnologia, che la sua dinamicità, interoperabilità, flessibilità, scalabilità e portabilità spicchino particolarmente nella realizzazione di soluzioni server-side, e che i Servlet combinino tutte queste virtù con una naturale semplicità di sviluppo veramente rara nell’informatica odierna.
Quest’affermazione per essere dimostrata richiederebbe un’attenta analisi dei diversi protocolli di interazione Web lato server, argomento che purtroppo esula dal tema di quest’articolo, ma che, in virtù del suo interesse e della sua attualità, ci ripromettiamo di affrontare nei prossimi numeri di questa rivista. 
Quello che invece tenteremo di fare in questa sede è fornire una casistica di problemi e soluzioni tipici del deployment di applicazioni Web basate su Servlet, tentando di mostrare quali scelte si nascondano dietro la realizzazione di un sito basato su queste tecnologie, nei diversi momenti della sua esistenza e della sua crescita. Dunque, il discorso non verterà sulle caratteristiche del protocollo e della sua programmazione: per un’introduzione a queste problematiche rimandiamo il lettore agli articoli già apparsi su questa stessa rivista ([1], [2]) e su MokaByte ([3]), oltre che alle risorse disponibili sul sito Sun ([4]). Ci limiteremo qui a ricordare, molto brevemente, che i Servlet sono degli oggetti Java eseguiti dai server Web in seguito ad una richiesta dell’utente, in grado di generare una normale pagina HTML da inviare al browser; essi sono dunque, dal punto di vista del client, in tutto e per tutto affini a degli script CGI. In particolare, l’uso dei Servlet non richiede un browser Java-enabled, dal momento che l’utilizzo di Java è esclusivamente confinato al server.
 
 

Il ruolo dei Servlet nelle scelte iniziali

La selezione del sistema operativo e del server Web cui demandare la gestione di un sito è tradizionalmente complicata e deve tener conto di differenti istanze, alcune delle quali in reciproca contraddizione:

• l’ambiente prescelto deve essere sufficientemente conosciuto, in modo da rendere possibile il reperimento di programmatori ed amministratori dotati del relativo know-how e da non richiedere il retraining di quelli già disponibili;
• lo stesso ambiente deve però essere tecnologicamente all’avanguardia e dotato di caratteristiche pari, se non superiori, alle offerte della concorrenza, in maniera da poter rispondere alle esigenze del cliente e garantirne la massima soddisfazione;
• siti ad elevata interazione richiedono una stretta coesione tra applicazioni e Web server, costringendo all’utilizzo di API assolutamente non portabili e spesso di difficile utilizzo;
• le API di comunicazione non sono, inoltre, l’unico fattore che precluda la portabilità delle applicazioni realizzate: oltre al dialogo con il server, i servizi Web richiedono un framework in grado di supportare funzionalità avanzate come il controllo delle sessioni, la comunicazione con database relazionali o ad oggetti, l’accesso a filesystem remoti e l’interoperabilità con servizi distribuiti in rete; 
• d’altronde nel mercato odierno la scalabilità è un valore importante: è possibile, se non molto probabile, che lo stesso sito Web al crescere del numero di utenti richieda una conversione ad un altro ambiente o ad un differente Web server, cosa che, proprio per via dell’utilizzo spinto di API proprietarie, può richiedere la completa riscrittura delle applicazioni e l’adozione di un nuovo framework;
• le scelte iniziali possono, nel mondo reale, rivelarsi sbagliate: si ricade così nel punto precedente, e per evitare la fatidica riscrittura si è costretti ad intervenire sulle altre componenti del sistema allo scopo di aumentarne le prestazioni, sbilanciandone l’architettura generale e nascondendo o ritardando l’insorgere dei problemi anziché risolverli.

• sessioni, incapsulate nella classe javax.Servlet.http.HttpSession, la quale si avvale di un utilizzo ottimizzato e personalizzabile dei cookie; 
• utilizzo di sorgenti di dati relazionali e non, tramite le librerie di classi JDBC ([5]);
• interoperabilità estrema, basata sul supporto nativo per CORBA, RMI, Enterprise JavaBean, Agenti, serializzazione e caricamento dinamico di classi in rete;
• pieno accesso a filesystem e socket, sia locali che remoti; 
• garanzia totale di portabilità fornita dal linguaggio Java e dalle sue librerie di classi.

Il supporto dei Servlet: implementazioni native e Java Servlet engine

La novità rappresentata dal protocollo Java Servlet - o per essere più precisi, il suo successo - ha colto di sorpresa diversi produttori di Web server, che non riuscendo ad adeguarsi con sufficiente velocità hanno di fatto aperto il mercato ad una nuova classe di prodotti, i Java Servlet engine. Si tratta di estensioni - spesso interamente gratuite - che implementano il meccanismo dei Servlet secondo le specifiche Sun. 
Quella che segue è una panoramica dei principali engine attualmente disponibili; ricordiamo ancora una volta che, dal punto di vista dei Servlet, non esistono differenze tra queste soluzioni, ed è possibile in ogni momento portare la propria applicazione sotto un altro server, un altro engine, e addirittura un altro sistema operativo:

• LiveSoftware JRun Servlet engine ([6]): disponibile sotto Windows 95/NT, Unix e Macintosh, compatibile con i server Web Microsoft, Netscape ed Apache, e gratuito nella versione base, deve parte della sua fama all’endorsement ufficiale operato nei suoi confronti dalla Microsoft; la LiveSoftware è inoltre produttrice di un’intera linea di tool ed estensioni dedicati a questo protocollo della Sun, come un Web server interno - incluso nell’ultima versione di questo engine - che lo trasforma in una soluzione completa adatta ad ambienti di testing, un toolkit comprendente il supporto per le Java Server Pages (l’analogo delle pagine ASP nel mondo Java) e diversi tool mirati a facilitare lo sviluppo ed il debug dei Servlet;
• IBM Servlet Express, oggi parte dell’IBM WebSphere Application Server ([7]): disponibile in licenza gratuita per lo sviluppo ed il debug sotto Windows NT, AIX e Solaris, e compatibile con i server IBM Domino, Microsoft, Netscape ed Apache; si tratta di un Servlet engine estremamente potente, dotato di un framework con estensioni proprietarie, dello stesso tool di amministrazione remota del Sun Java Web Server, di un’implementazione completa delle Java Server Pages, nonché del supporto nativo per il pooling degli accessi JDBC (una tecnica per ottimizzare l’utilizzo di connessioni multiple contemporanee alla medesima sorgente dati, in gran voga in architetture multithreaded come quella dei Servlet) e dell’interoperabilità CORBA; 

 

 

New Atlanta ServletExec ([8]): disponibile sotto Unix, Windows e Macintosh, compatibile con i server Microsoft, Netscape ed Apache; nella sua ultima versione - ancora in beta al momento della stesura di quest’articolo - supporta le Java Server Pages; 

• Apache JServ ([9]): Servlet engine per il server freeware Apache, disponibile sotto diverse piattaforme e leader incontrastato del mercato; 
• ATG Dynamo Application Server ([10]): application Web server di fascia alta compatibile con i server Microsoft, Netscape ed Apache, disponibile sotto Solaris, AIX ed NT. 

 

 

Inoltre, i Servlet sono ormai supportati in maniera nativa da un buon numero di server Web, tra i quali ricordiamo: 
La prima implementazione dei Servlet, per così dire "di riferimento", effettuata dal Java Web Server originariamente noto come Jeeves ([11]) e giunto ormai alla versione 1.1.2, tra i cui punti di forza si segnala l’Applet di amministrazione remota realizzato in Java;

• KonaSoft Enterprise Server ([12]): oltre ad una completa implementazione della Servlet API fornisce il supporto per una nuova categoria di oggetti Java eseguibili associati alle sorgenti dati JDBC, chiamati Proclets, lontanamente affini alle SQL stored procedure; 
• O’Reilly WebSite ([13]): prodotto limitato alle piattaforme Microsoft, ma molto conosciuto ed apprezzato per l’alto numero di API, estensioni e protocolli supportati;
• Zeus Web Server ([14]): disponibile per piattaforme Unix ed NT, è un server Web mission-critical; si segnala non solo per il supporto fornito ai Servlet ed alle altre soluzioni di interoperabilità Java (RMI, CORBA), ma anche per un insieme di funzionalità strettamente legate alla sua fascia di mercato, in particolar modo per quanto riguarda la gestione della sicurezza. 
• Sono state volutamente omesse tutte le soluzioni a carattere sperimentale - come il server Jigsaw ([15]) realizzato dal consorzio W3C - o semplicemente troppo recenti per essere considerate realmente affidabili, come il Web Server Avenida ([16]). Infatti, non si è cercato di fornire l’elenco completo di tutte le attuali implementazioni del protocollo Servlet, ma solo di quelle la cui stabilità, facilità di amministrazione e scalabilità in ambienti di produzione sono ampiamente provati.

Il framework standard e le estensioni di terze parti

Come si è visto le Servlet API implementano in maniera portabile i due meccanismi fondamentali della programmazione lato server, vale a dire il concetto di sessione - l’identificazione di una serie di richieste provenienti da un’unica coppia utente/browser - e l’accesso alle funzioni native di autenticazione fornite dal sistema operativo. Essi, insieme a tutte le rimanenti funzionalità fornite dall’ambiente run-time Java, realizzano un framework vasto e completo. Tuttavia è ragionevole pensare che applicazioni particolarmente complesse possano trarre dei benefici da strumenti ancora più avanzati, mirati all’ottimizzazione dell’attività dei Servlet in ambienti mission-critical. Tali strumenti sono disponibili agli sviluppatori attraverso librerie di classi aggiuntive implementate direttamente da alcuni Servlet engine, o disponibili sotto forma di prodotti di terze parti, e non risultano utili nelle iniziali fasi di sviluppo del sito, o nel deployment di soluzioni di fascia medio-bassa, ma rappresentano piuttosto un’importante arma nelle mani dei programmatori al crescere delle esigenze del cliente. Un notevole sforzo in questo senso è stato compiuto da IBM che, molto attenta all’evoluzione del mondo Java, ha incluso nel suo Servlet Express alcune estensioni di grande potenza ed utilità:

• Un sistema di clustering delle sessioni (Session Tracker) mediante il quale è possibile distribuirne la gestione tra più server in maniera da bilanciare ed ottimizzare le perfomance in ambienti ad alto carico di lavoro; 
• l’implementazione delle sessioni tramite un meccanismo alternativo (URL rewriting) che ne consente l’uso anche da parte di browser in cui il supporto per i cookie non sia presente o sia stato esplicitamente disattivato; 
• il supporto per l’archiviazione ed il retrieving di profili utente persistenti e personalizzabili tramite una qualsiasi connessione JDBC;
• un layer di astrazione all’accesso ai dati realizzato tramite JavaBean, che fornisce al programmatore un insieme di funzionalità avanzate; è vero che molte di esse sono state rese standard dalla stessa Sun nell’ultima versione della JDBC API, ma alcune caratteristiche, come il caching dei risultati delle interrogazioni SQL e la loro suddivisione in sottoinsiemi (subpackaging) rappresentano tutt’ora un qualcosa di unico; 
• un completo meccanismo di pooling e condivisione delle connessioni JDBC, punto fondamentale nell’evoluzione di una soluzione Servlet nell’ottica della scalabilità.

• Gestione di cursori bidirezionali e di aggiornamento (comunque presenti anche nell’ultima versione del JDBC); 
• accesso diretto alle SQL stored procedure; 
• un design realmente orientato agli oggetti, che si traduce in un insieme di classi e metodi coerenti e di più facile utilizzo rispetto al framework Sun; 
• supporto per i pool di connessioni a database; 
• completa compatibilità con il JDBC;
• implementazione interamente thread-safe;
• piena portabilità in ogni ambiente ed in ogni server Web o Servlet engine.

L’amministrazione dei Servlet

Al di là delle funzionalità aggiuntive di alcuni particolari ambienti (come il pooling di connessioni JDBC, o la possibilità di politiche personalizzate nel tracking delle sessioni) che richiedono passi specifici di configurazione, le linee guida da seguire nell’amministrazione dei Servlet engine sono comuni a tutte le implementazioni, esattamente come unico è il framework di base. Sia che i tool di gestione prendano la forma di servizi esterni, o che risultino inglobati nel Web server; sia che la loro esecuzione sia demandata ad un Applet Java sia che avvenga attraverso un software nativo, i due punti fondamentali nella customizzazione dei motori Servlet sono le procedure di sicurezza e la registrazione dei Servlet stessi. 
L’organizzazione dei permessi di accesso può, in funzione dei diversi engine, basarsi sulle User Access Control List native del sistema operativo, su un database di utenti e password parallelo o su una combinazione di questi due metodi. Qualunque sia la scelta effettuata occorrerà fornire alle procedure di amministrazione la topologia degli utenti e dei gruppi che dovranno avere accesso alle risorse condivise e, in particolare per quanto riguarda i Servlet, definire le operazioni cui essi risulteranno abilitati nei confronti del server Web che li istanzia ed esegue. Queste operazioni, differenziabili per lo stesso Servlet su base utente, sono suddivise in un numero di categorie funzionali che - seppur con nomi diversi - si equivalgono nella maggior parte degli ambienti visti in precedenza. Per la precisione, esse sono:

• Load Servlet: permesso di caricamento ed esecuzione; 
• Write files: permesso di accesso in scrittura ai filesystem locali del server; 
• Listen to socket: permesso di interazione con socket locali al server; 
• Link libraries: permesso di caricamento ed utilizzo di librerie dinamiche locali al server; 
• Read files: permesso di accesso in lettura ai filesystem locali del server; 
• Open remote socket: permesso di interazione con socket remoti; 
• Execute programs: permesso di esecuzione di programmi locali al server; 
• Access system properties: permesso di accesso alle proprietà di sistema (tramite la classe java.lang.System).

 http://www.nomeserver.it/Servlet/<nomeServlet>

Dove <nomeServlet> equivale esattamente al nome della classe del Servlet; l’accesso ad un URL di questo genere viene intercettato dall’engine, che "dietro le quinte" dialoga con il Servlet in maniera completamente trasparente all’utilizzatore, ritornandone l’output HTML al browser. In aggiunta - ed a patto di aver effettuato la procedura di registrazione - è possibile avvalersi di un meccanismo detto aliasing che consiste semplicemente nell’associare ad ogni Servlet uno o più URL addizionali del tipo:
 

 http://www.nomeServlet.it/<nome.html>

Questo meccanismo, supportato da ogni engine, permette - una volta convertita in Java una soluzione preesistente basata su un altro protocollo - di lasciarne invariata la modalità di accesso da parte dell’utenza. 
Infine, crediamo giusto citare un bug che si manifesta in quei tool che fanno uso delle classi Sun (contenute nel package com.sun.server.admin.toolkit) per la realizzazione dei loro front-end di amministrazione. Si tratta di un problema relativo al rendering di alcuni form dell’Applet di configurazione, che si verifica solo su macchine Windows configurate alla risoluzione di 640x480 pixel e che non è aggirabile, essendo indipendente dal browser e dalla versione del JDK. 
Le uniche soluzioni possibili sono cambiare la risoluzione dello schermo o rinunciare al tool integrato e procedere alla configurazione attraverso la modifica diretta dei relativi file.

 Il debug dei Servlet: consigli e strumenti

La prima osservazione da fare riguarda i Java Development Kit e le Java Virtual Machine. 
Essi sono disponibili in molteplici versioni, che non si differenziano solo per le API supportate ma, come avviene un po’ per tutti i moderni ambienti di sviluppo, anche per i diversi bug e problemi in essi presenti. Dunque, è necessario leggere attentamente la documentazione del proprio Servlet engine, e seguire i consigli in essa contenuti riguardo agli strumenti di run-time supportati: infatti è opportuno sapere, ad esempio, che tra le versioni 1.1.5 e 1.1.6 del JDK esistono realmente delle differenze e che altrettante ne esistono tra la Virtual Machine Sun e quella Microsoft, e che potrebbero essere proprio queste diversità il motivo di quei misteriosi crash nel vostro ultimo Servlet! In linea di massima ogni engine non solo specifica chiaramente le VM e i JDK supportati, ma spesso li include addirittura nella propria distribuzione. In questo caso raccomandiamo sempre di scaricarli dalla rete e di configurarli correttamente, perché il tempo perso in queste operazioni verrà ampiamente ripagato dal guadagno in solidità e affidabilità che ne deriva. 
Lo stesso principio vale ovviamente per i Servlet engine: nel momento in cui ci si accinge a sviluppare una nuova applicazione - specie se di una certa importanza - il suggerimento è di controllare l’ultima versione del motore prescelto, eventualmente procedendone all’aggiornamento. Così facendo vi assicurerete il supporto per le versioni più recenti del JDK e di tutte le API - incluse quelle dei Servlet stessi - ed eviterete i problemi di stabilità riscontrati nelle precedenti versioni di numerosi engine, problemi che si traducevano in frequenti ed inspiegabili crash. Al di là dei consigli pratici, di quali strumenti di debug possono avvalersi gli sviluppatori di Servlet? Innanzitutto, ogni programmatore ha bisogno di testare rapidamente le modifiche apportate al proprio codice: punto di forza, questo, delle soluzioni CGI basate su linguaggi interpretati (come il Perl) in cui è sufficiente un semplice click sul tasto Reload del proprio browser, ed iniziale motivo di critica nei confronti del protocollo Sun. 
Oggi la situazione è molto cambiata, ed i motori più evoluti - come l’IBM Servlet Express - verificano automaticamente che l’istanza in memoria del servlet sia aggiornata, ed in caso contrario provvedono a ricaricarlo da disco alla prima richiesta. Utilizzando ambienti più spartani è comunque sufficiente, prima di ricaricare la pagina del servlet, effettuarne l’unload dalla memoria dell’engine con il relativo tool di amministrazione, ed il server lo riinizializzerà al successivo accesso. In alternativa è possibile, specialmente nelle prime fasi del testing, eseguire i Servlet non all’interno di un Web server reale ma tramite un ambiente di esecuzione dedicato. Le scelte a disposizione in questo senso sono essenzialmente due:

• Il tool a linea di comando servletrunner incluso nel Sun JDK; limitato sotto alcuni punti di vista - particolarmente nel supporto per le procedure di autenticazione e security - ma pur sempre una soluzione pratica e veloce;
• il Servlet engine dedicato, incluso nell’Inprise JBuilder 2 ([20]), un importante ambiente di sviluppo visuale in Java orientato alla realizzazione di software Pure Java client/server; in particolare esso permette di operare all’interno dell’IDE durante tutto il ciclo di vita del Servlet, rendendone possibile il debug in maniera analoga ad ogni altra applicazione.

Conclusioni

Rispetto alle tante soluzioni server-side esistenti, il protocollo Java Servlet presenta un impressionante numero di vantaggi. Non solo, come già è stato fatto notare nell’introduzione, possiede una potenza semantica ed una flessibilità, dinamicità e scalabilità uniche, ma esso è l’unico protocollo lato server universale: un Servlet Java, una volta realizzato, è immediatamente portabile in qualsiasi ambiente senza necessità di ricompilazione. Inoltre, cosa che non si può dire di molti suoi concorrenti, la tecnologia dei Servlet non è un prodotto a sé stante, ma si trova al centro di una costellazione di protocolli e soluzioni intrinsecamente multipiattaforma e rappresenta la porta d’ingresso ad un framework globale orientato al mondo dei server, con il quale Sun intende fornire una soluzione solida ed esaustiva ad ogni esigenza di condivisione distribuita di dati ed applicazioni. Nomi come Enterprise Java Bean, Aglet, JTA e JNDI non sono solo delle sigle, ma strumenti dai quali sarà impossibile prescindere già nell’immediato futuro e che impareremo a conoscere meglio nei mesi a venire.

Bibliografia

[1] Michele Sciabarrà, "Server Side Programming con Java Servlet", Computer Programming No.66, Febbraio  1998;
[2] Giovanni Puliti, "Gestire gli accessi Web con un server Java", Computer Programming n.69, Maggio 1998; 
[3] Fabrizio Giudici, "I Servlet", MokaByte, Settembre 1997: http://www.mokabyte.it/1999/09/Servlets.htm; 
[4] Sun Servlet: http://java.sun.com/products/Servlet/index.html
[5] Sun JDBC: http://java.sun.com/products/jdbc/index.html;
[6] Live Software: http://www.livesoftware.com
[7] IBM Servlet Express: http://www.software.ibm.com/webservers/appserv/download.html;
[8] New Atlanta ServletExec: www.newatlanta.com;
[9] Java-Apache Project: http://java.apache.org;
[10] Dynamo Application Server: http://www.atg.com/develop/products/d3;
[11] Sun Java Web Server: http://jserv.java.sun.com/products/webserver/index.html;
[12] Konasoft: http://www.konasoft.com;
[13] O’Reilly WebSite: http://website.ora.com;
[14] Zeus Web Server: http://www.zeustech.net/products/zeus3;
[15] W3C Jigsaw: http://www.w3.org/Jigsaw;
[16] Avenida Web Server: http://www.avenida.co.uk;
[17] RogueWave DBToolsJ: http://www.roguewave.com/products/dbtoolsj;
[18] Sun Java Server Engine: http://java.sun.com/products/javaserverengine/index.html;
[19] WithinReach RSVP: http://www.withinreach.co.il/RSVP;
[20] Inprise JBuilder 2: http://www.inprise.com/jbuilder.