Dans une architecture client-serveur, une application cliente initialise un dialogue avec une application serveur. Nous avons vu que ce type de dialogue peut être réalisé par objets distribués en RMI ou en Corba. Un protocole personnel peut également être mis en place par sockets. Les servlets quant à elles sont des applications serveur qui viennent "en couche" au dessus d'un protocole existant. Elle permettent de donner de 'l'intelligence' coté serveur à un protocole. Typiquement - et nous nous en tiendrons ici à cette utilisation - les servlets sont utilisées avec le protocole HTTP. Nous connaissons les applets du coté client. Ce sont des petites applications téléchargées du serveur qui s'exécutent sur le client. Elle sont téléchargées via le protocole HTTP à l'initiative d'un navigateur web. Cependant, elles ne possèdent aucun mécanisme permettant de communiquer avec un serveur. Elle sont simplement stockées coté serveur, au même titre que des images ou des pages HTML mais s'exécutent sur le client de façon autonome. La servlet HTTP vient alors comme partie serveur naturelle de l'applet. Elle est une application s'exécutant coté serveur uniquement et pouvant intervenir entre le client HTTP ( le navigateur ) et le serveur HTTP (Apache, IIS...) pour contrôler les requêtes et effectuer des actions que le protocole HTTP ne sait pas faire. L'une des applications les plus répandues des servlets est la génération de pages HTML dynamiques. L'intérêt des servlets est alors évident vis à vis de solutions distribuées type RMI / Corba ou sockets : les servlets possèdent toutes les méthodes pour gérer facilement le HTTP.
Pour bien comprendre le rôle des servlets, donnons un bref rappel du protocole HTTP. Ce protocole est très simple: le client effectue une requête au serveur par un GET URL ou URL est l'adresse de la ressource à afficher ( une page HTML, une applet... ). Le serveur HTTP envoi alors le fichier au client. Le client peut également effectuer sa requête par un POST si cette dernière est très longue. Le port par défaut de ce protocole est le 80.
Le rôle de la servlet va alors être de modifier ce protocole très statique pour le compléter. Ainsi, une HttpServlet peut surcharger la requête GET par sa propre méthode doGet() dans laquelle elle peut faire tout ce que Java permet. Par exemple, générer une page HTML dynamique qui va être renvoyer au client. Cependant, pour pouvoir 'surcharger le protocole HTTP', il faut disposer d'un serveur de servlet qui a pour tâche d'aiguiller la requête vers la servlet. Il existe des serveurs de servlet pour Apache, comme JServer ou Tomcat qui est intégré dans l'ensemble d'outils serveurs open-source Jakarta.
Dans cet exemple très simple, nous gênerons une page dynamique affichant "Votre IP est:" et donnant l'IP du client.
import
java.servlet.*;
import javax.io.*;
import
javax.servlet.http.*;
class DonneIPClient extends HttpServlet{
public void doGet(HttpServletRequest hsrReq,HttpServletResponse
hsrRes){
try{
hsrRes.setContentType("text/html"); //précise au
HTTP que l'on transfert du texte
PrintWriter pwOut=hsrRes.getWriter(); //donne un flux HTTP vers le
poste client
pwOut.println("<HTML><BODY>");
pwOut.println("Votre IP est :
"+hsrRes.getRemoteHost());
pwOut.println("</BODY></HTML>");
}
catch(Exception
e){
e.printStackTrace();
}
}
}
La seconde grande utilisation des servlets réside dans les SSI (Server Side Includes ). Les SSI sont de simples servlets dont le résultat à une requête peut être stocké directement dans une page HTML. Le tag <SERVLET> dans une page HTML suivi de l'url complet de la servlet signifie au navigateur qu'il doit insérer dans la page le résultat de l'exécution de cette servlet. La servlet est exécutée côté serveur et ne transmet que le résultat de son exécution. Imaginons par exemple un SSI effectuant une requête SQL via JDBC qui est exécutée coté serveur et qui renvoie sous forme de texte le résultat de la requête. Cette dernière s'affichera alors dans la page HTML.