I servlets sono applicazioni scritte in java che risiedono nel WEB Server e che operano in modo molto simile ai CGI. Le differenze principali sono:
Un servlet può funzionare come una sorta di servizio NT: inizializzato e sempre attivo, in attesa di richieste oppure come applicazione eseguita ogni volta.
Per ogni richiesta non viene attivato un processo ma un thread, che è una sorta di processo alleggerito (per quanto riguarda risorse di memoria e cpu)
Il codice utilizzato, java, permette di sfruttare tutti gli oggetti utilizzati con JScript, più tutti quelli scaricabili gratuitamente dal sito della SUN, sotto forma di packages. Ed inoltre, proprio per le caratteristiche del linguaggio in se stesso, rende indipendente dalla piattaforma contrariamente ai CGI.
Il concetto di servlet è quindi molto simile a quello di script java, tranne per il fatto che il codice non viene interpretato ad ogni chiamata ma è già disponibile in formato bytecode (per servlet eseguiti come applicazioni) oppure già residente in memoria.
La caratteristica principale sta nell’implementazione di alcuni metodi (doGet, doPost etc.) per gestire direttamente le richieste nel formato HTTP con cui arrivano. Tali metodi operano infatti, con gli oggetti HTTPServletRequest e HTTPServletResponse che contengono tutte le informazioni da e per il client.
Internet Information Server non supporta i servlets, è quindi necessario installare un servlet server che li renda disponibili come servizi http. Esistono in commercio vari tipi di servlet server; personalmente ho testato Servlet EXEC ISAPI della New Atlanta. L’applicativo non è un server vero e proprio come IIS, si tratta in realtà di una libreria dll che viene installata sotto la directory script di IIS, il cui compito è eseguire i servlet installati nel sistema quando questi vengono richiesti tramite http. Una volta installato, un servlet è disponibile con un indirizzo del tipo http://www.sito.com/servlet/ServletProva. Il default WEB site non è in grado d’interpretare questo indirizzo e demanda il compito alla libreria suddetta. La directory /servlet/ è virtuale, viene mappata dalla libreria sulla directory servlets nel path d’installazione di New Atlanta. Qui risiedono tutti i servlet del sistema, sotto forma di file .class.
Tramite il servlet /servlet/Admin si possono installare e configurare i servlets, definendo aliases ed eventuali parametri d’ingresso. Se questi ultimi non sono necessari, è sufficiente posizionare un file .class nella directory /servlets/ affinchè questo sia disponibile in rete come servlet.
Tra le varie opzioni di Admin esiste anche la possibilità di mappare i servlet su un indirizzo diverso da quello di default /servlet/NomeServlet; basta definire un alias differente ad esempio /FileServlet/NomeServlet2.
Per realizzare un servlet è sufficiente scrivere un file .java (implementando tutte le classi e metodi necessari) e compilarlo con, ad esempio, il compilatore di linea javac disponibile con jdk1.4.
Se si utilizza jdk bisogna installare i packages per i servlets ed eventualmente jdbc, necessario per il collegamento a database. Sul sito della sun (www.sun.com), sono disponibili entrambi. Una volta scaricati è necessario eseguire le seguenti operazioni:
Aprire una finestra dos con il comando cmd
Settare la variabile d’ambiente PATH: set PATH=c:\jdk1.4\bin
Il package per i servlet si chiama servlet.jar, copiarlo nella directory jdk1.4\lib
I packages per jdbc sono una serie di file .class, copiarli in un’unica directory e compattarli con il comando: jar cvf SQL.jar *.class
Copiare il file SQL.jar nella directory jdk1.4\lib
Creare un file batch da eseguire ogni volta che si vuole utilizzare javac in cui vi sia:
set classpath=c:\jdk1.4\lib\servlet.jar; c:\jdk1.4\lib\SQL.jar
A questo punto è possibile compilare i servlet semplicemente con javac nomeServlet.java.
Facile no ?
Per problemi non esistate a lasciarci un commento.
Alla prossima..
