Tutoriel sur les Servlets Java

Le fonctionnement d'une application client-serveur peut être décrit de la manière suivante.

Un programme s'exécutant sur une machine logique proposant un support des connexions vers d'autres ordinateurs au travers d'un réseau offre ses services. Sur une autre machine logique, proposant elle aussi un support des connexions vers d'autres ordinateurs au travers d'un réseau, s'exécute un programme qui émet des requêtes vers des machines faisant office de serveur, afin d'utiliser les services proposés.

Un programme serveur peut gérer, en général, plusieurs requêtes à la fois provenant de clients différents ou identiques. Un programme client peut, en général, utiliser plusieurs connexions vers des serveurs différents ou identiques en même temps.

Ces deux machines logiques (car le programme client peut fonctionner sur la même machine physique que le programme serveur) utilisent un ensemble de protocoles pour communiquer entre elles. Ces protocoles sont un ensemble de règles à respecter pour pouvoir communiquer correctement selon le but recherché (transmission d'informations confidentielles, transmission rapide d'informations peu importantes, etc.).

Ces protocoles se placent à divers niveaux de la couche du modèle OSI qui définit l'architecture logique du support des communications au travers d'un réseau sur la plupart des machines. Ces couches vont des plus abstraites et orientées « applications » en haut aux plus concrètes et orientées « implémentation physique » en bas.

C'est ainsi que les couches les plus basses du modèle OSI permettent de gérer toutes les communications au travers d'un réseau, alors que ce sont les couches les plus hautes qui fournissent des différences notables au programmeur et à l'utilisateur d'applications de haut niveau.

Ces couches les plus hautes définissent donc des protocoles spécifiques à chaque type d'applications que l'on peut trouver sur un réseau : transfert de fichiers (FTP), envoi et réception de courriers électroniques (SMTP), consultation de sites Web (HTTP), etc..

Le client et le serveur dialoguent donc à l'aide des mêmes protocoles, mais d'un côté le serveur fournit les services, de l'autre le client en bénéficie. Un serveur, grâce à la séparation des protocoles orientés « application » peut fournir le type de service qu'il veut. Il n'est pas obligé de fournir tous les services existants (simplement la consultation de sites Web par exemple), mais il peut le faire.

Un client peut en même temps faire office de serveur. Les communications entre ordinateurs ne sont pas unidirectionnelles.

III-A-1-a. Le protocole HTTP▲

telnet adresse_ip_serveur_web 80

GET /index.html HTTP/1.0

GET / index.html HTTP/1.0
Accept: text/html, image/gif
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Linux X11 2.2.17)

HTTP/1.0 200 OK
Server: Apache/1.3.14 mod_php4
Content-type: text/html

Tout d'abord, définissons les différents types de serveurs. Il existe trois types différents de moteurs de Servlets :

1. Les moteurs de Servlets indépendants ;
2. Les moteurs de Servlets embarqués ;
3. Les moteurs de Servlets externes.

Les moteurs de Servlets indépendants constituent une partie intégrante du serveur Web. Pour qu'une telle chose soit possible, il faut en principe que le serveur Web soit développé en Java. Un exemple de ce type de serveurs est le Java Web Server, ou encore Tomcat (dont nous analyserons la configuration en détail ultérieurement).

Les moteurs de Servlets embarqués sont une combinaison d'un ajout à un serveur Web et d'une implémentation de l'API Servlet. L'ajout (le plugin) au serveur Web permet d'aiguiller les requêtes venant des clients et qui concernent des Servlets vers une machine virtuelle contenue dans le processus du serveur Web. Cette machine virtuelle est exécutée dans un thread séparé ce qui implique le fonctionnement du serveur Web en multithreads, ce qui n'est pas le cas de tous les serveurs Web (par exemple Apache sous Unix). Cette configuration apporte de bonnes performances, car les changements de contexte sont moins coûteux, mais est limitée en possibilité d'extensions (un serveur supportant un très grand nombre de requêtes au même moment aura du mal à pouvoir répondre à ces dernières).

Les moteurs de Servlets externes sont une combinaison entre un plugin « greffé » au serveur et une machine virtuelle tournant à l'extérieur de celui-ci. Afin de communiquer entre eux, le plugin et le processus associé à la machine virtuelle utilisent un mécanisme de communication interprocessus tel que les sockets TCP/IP. Si une requête passée au serveur Web concerne les Servlets, celui-ci passe la requête au moteur de Servlets en utilisant le mécanisme sus-cité. Un des inconvénients de cette méthode est la diminution des performances. Par contre, ce type de serveur est en général plus stable (un arrêt du serveur Web n'agit pas sur le moteur de Servlets et vice-versa) et plus extensible. De plus, étant donné que la machine virtuelle est extérieure au serveur Web, elle peut tourner sur n'importe quelle machine, ce qui vous permet de faire tourner le serveur Web sur une machine différente de celle sur laquelle est lancé le moteur de Servlets. Vous pouvez également mettre en place plusieurs machines virtuelles pour un même serveur Web2.2. En bref, la souplesse que l'on gagne peut être intéressante à de nombreux points.

En général, les personnes désirant fournir un support pour les Servlets sur leur serveur fournissent déjà un support pour d'autres technologies de développement Web côté serveur, ou proposent tout simplement l'hébergement de pages statiques. Il est clair qu'un moteur de Servlets, même s'il peut faire office de serveur Web dans le cas où il peut tourner en mode indépendant (comme pour Tomcat ou le Java Web Server), est beaucoup moins performant que les produits spécialisés lorsqu'il faut fournir un contenu différent des Servlets (pages statiques, fichiers, etc.). On comprend donc facilement qu'il vaut mieux choisir un moteur de Servlets « greffable » sur un serveur Web existant, afin de rester performant en ce qui concerne le contenu statique (c'est le serveur Web qui le gère) et le contenu dynamique faisant appel à des Servlets (c'est le moteur de Servlets qui le gère). Cela nous laisse donc le choix entre la solution un et deux (embarqués ou externes) bien sûr, il est tout à fait possible de travailler avec des moteurs de Servlets indépendants à des fins de développement, je les déconseille simplement pour de la production.

Venons-en aux serveurs d'applications. J'ai dit précédemment qu'ils étaient souvent un assemblage entre un serveur Web existant, un moteur de Servlets existant et des outils orientés « métier » en plus, comme l'incorporation des EJB et d'autres outils spécifique à une activité industrielle (gestion des transactions, relation client, etc.). Ce sont des outils très pointus, qui coûtent souvent très cher, et qui requièrent de multiples compétences. Leur utilisation et leur configuration sont similaires aux solutions plus classiques, avec souvent des outils de configuration plus simples à utiliser pour les taches courantes, mais en ce qui concerne le développement strict de Servlets, ils n'apportent quasiment rien (à part des optimisations des performances ou de la fiabilité dans des environnements bien précis, souvent des gros systèmes comme les S/390). On voit très bien que les aspects intéressants de ces solutions sortent du cadre de mes compétences et de cet ouvrage, et c'est pour cette raison que je les écarterai de mon choix. Pour conclure à propos de ces solutions, elles sont souvent moins souples à utiliser que des applications plus classiques en raison de leur complexité et de leur course à l'utilisation facile. Les problèmes rapportés sur les listes de diffusion ayant trait à la configuration de moteurs de Servlets concernent la plupart du temps ce type de serveurs.

Il apparaît que le type de serveur réunissant le plus d'avantages est le moteur de Servlets externe relié à un serveur Web performant via un plugin. En effet, comme on a pu le voir, c'est une solution fiable, souple et assez performante. De plus, moyennant quelques efforts de configuration, ce type de serveur peut tout à fait inclure un nombre très important de fonctionnalités comme les EJB, ce qui leur donne accès aux composants métiers si chers aux serveurs d'applications, ou le support de plusieurs machines virtuelles.

Maintenant que nous avons choisi (même si je vous ai aidé) le type de serveur à utiliser, choisissons lequel utiliser dans cette catégorie.

Le choix d'un serveur dépend essentiellement, en dehors des performances concernant le service de contenu autre que des Servlets, de deux critères : la version de l'API Servlet supportée et la version des JSP supportée. En effet, bien que les comparaisons de performances entre solutions soient abondantes, elles ne signifient rien si elles ne concernent pas directement l'application que vous voulez faire fonctionner. Plus la version de l'API supportée est récente, plus vous pourrez bénéficier de fonctionnalités utiles (par exemple la version 2.0 de l'API des Servlets ne supporte pas le RequestDispatcher). Le raisonnement est similaire en ce qui concerne les JSP. Afin de bénéficier d'une vision claire de ces deux critères, je vous invite à consulter l'URL suivant : http://java.sun.com/products/servlet/industry.html. Ici, le système d'exploitation choisi n'entre pas en compte pour le choix du moteur de Servlets, car, étant donné que ce type de serveur est (en général) programmé entièrement en Java, tout système d'exploitation disposant d'une implémentation de la machine virtuelle Java est censé fonctionner. Cependant, étant donné que nous avons choisi de coupler ce moteur de Servlets à un serveur Web, nous devrons prêter attention aux serveurs Web supportés, afin que nous puissions utiliser ce couple avec le système d'exploitation de notre choix.

Vous pouvez voir que quelques serveurs externes (c'est-à-dire qui peuvent être interfacés avec un serveur Web, à ne pas confondre avec indépendant) correspondent à ces deux critères. Le choix que je vais proposer ici ne dépend que de préférences auxquelles vous n'adhérerez pas forcément, mais je tenterais de justifier le rejet d'autres solutions (comme je l'ai fait pour le choix du type de serveur).

Tout d'abord WAIColRunner doit être utilisé conjointement à un serveur Web Netscape Enterprise Server ou Netscape Fast Track Server (le dernier est une version allégée du premier). Cela limite considérablement le choix quant au serveur Web, même si celui-ci est très largement diffusé au sein des entreprises. C'est un moteur de Servlets payant dès que l'on veut obtenir un support technique. En ce qui concerne JRun de Allaire, il propose, grâce à JRun Studio une suite intégrée séduisante pour le développement de Servlets (débogage à distance, développement rapide, etc., ) et propose quelques caractéristiques intéressantes comme la compatibilité avec la majorité des serveurs Web existants, mais il est payant (le prix varie entre 495 dollars et 18 395 dollars). Il reste alors Resin de Caucho et Tomcat de la Fondation Apache. Le premier possède un nombre impressionnant d'avantages : il supporte les principaux serveurs Web du marché (iPlanet, IIS, Apache), est doté d'outils intéressants comme le support de XSL et X ML pour gérer les modèles de documents (entre autres) et supporte même la version 2.3 de l'API des Servlets (qui n'est qu'au stade de proposition)2.3. Cependant l'utilisation est payante si elle entre dans un cadre commercial. Le dernier qui, vous l'aurez compris, est le moteur de Servlets sur lequel je porte mon choix est Tomcat de la fondation Apache. Je l'ai choisi, car il tourne sur un nombre très important de systèmes d'exploitation différents, qu'il est très bien intégré au serveur Apache (mais aussi à d'autres comme IIS), et qu'il est distribué dans les termes d'une licence en faisant en logiciel libre (il est donc disponible gratuitement). De ces caractéristiques découle qu'il est très simple de se documenter sur ce moteur de Servlets, de trouver des personnes sachant le manipuler et que son développement est très actif2.4. De plus, il n'est pas nécessaire de démontrer l'efficacité du serveur Web Apache auquel on l'associe en général.

Nous disposons maintenant d'une solution souple et performante basée sur le moteur de Servlets Tomcat et le serveur Web Apache. Je vais vous guider maintenant dans l'étape d'installation et de configuration de cette solution, en me concentrant sur ce qui peut vous être utile et en vous laissant consulter la documentation livrée avec le serveur pour les détails.

Tomcat et Apache sont, comme nous l'avons dit précédemment, tous deux disponibles pour un nombre important de systèmes d'exploitation différents. Il m'est impossible de décrire le procédé d'installation de ces deux applications dans tous les environnements possibles. Sachez seulement que l'installation sur des systèmes de la famille Unix ne changera que très peu au pire des cas, et que l'installation sous Windows ne différera qu'au niveau des fichiers à installer (il faudra télécharger les binaires pour Windows et non les sources pour Unix) et ne nécessitera pas de compilation. Je vais donc vous décrire l'installation de Tomcat et Apache sous un système Linux, en particulier une distribution Debian dans sa version 2.2. Il est admis ici que vous disposez d'un compilateur de programmes écrits en C qui fonctionne et qui est compatible avec gcc. Pour vous en assurer, entrez la commande :

gcc -version

qui devrait afficher la version de gcc installée sur votre système.

III-B-3-a. L'installation de l'environnement de développement Java▲

tar xfvz j2sdk-1_3_0-linux.bin -C /usr/local

cd /usr/local/jdk1.3/bin

./javac

export PATH=$PATH:/usr/local/jdk1.3/bin

III-B-3-b. L'installation de Tomcat▲

mkdir /usr/local/tomcat-dist

tar xfvz jakarta-tomcat-3.2.1-src.tar.gz -C /usr/local/tomcat-dist
unzip jsse-1_0_2-gl.zip -d /usr/local/tomcat-dist
mkdir /usr/local/tomcat-dist/jakarta-ant
tar xfvz jakarta-ant-src.tar.gz -C /usr/local/tomcat-dist/jakarta-ant
unzip jaxp-1_0_1.zip -d /usr/local/tomcat-dist
unzip servlet-2_2b.zip -d /usr/local/jdk1.3/jre/lib/ext

./build.sh

./build.sh dist

./startup.sh

III-B-3-c. Installation et configuration de Apache▲

tar xfvz apache_1.3.14.tar.gz -C /usr/local/src

cd /usr/local/src/apache-1.3.14

./configure -enable-module=so

make install

III-B-3-d. Configuration de mod_jserv▲

cd /usr/local/tomcat-dist/jkarta-tomcat-3.2.1-src/src/native/apache/jserv

/usr/local/apache/bin/apxs -o mod_jserv.so -c *.c

cp mod_jserv.so /usr/local/apache/libexec

    Include /usr/local/tomcat-dist/build/tomcat/conf/tomcat-apache.conf

/usr/local/tomcat-dist/build/tomcat/bin/startup.sh

/usr/local/apache/bin/apachectl start

III-B-3-e. La configuration de mod_jk▲

cd /usr/local/tomcat-dist/jkarta-tomcat-3.2.1-src/src/native/apache1.3

/usr/local/apache/bin/apxs -o mod_jserv.so -c *.c ../jk/*.c -I ../jk 

-I /usr/local/jdk1.3/include -I /usr/local/jdk1.3/include/linux

cp mod_jserv.so /usr/local/apache/libexec

C'est une méthode qui existe déjà pour d'autres techniques de programmation d'applications qui tournent sur un serveur Web. En effet, il est possible d'utiliser SSI en programmant des scripts CGI par exemple.

Afin de pouvoir utiliser cette technique, le serveur Web doit proposer un support pour les SSI. Ce support varie d'un serveur à l'autre. Une Servlet utilisée avec SSI se compose de deux parties : le code de la Servlet elle-même et le code HTML de la page Web qui inclue le résultat de cette Servlet. Voici un exemple de code HTML pour une page désirant utiliser la Servlet Bonjour :

<HTML>
<BODY>
<TITLE>Essai d'utilisation de SSI</TITLE>
<P> 
Voici un exemple d'utilisation de la sortie produite par une Servlet.
</P>
<SERVLET CODE=Bonjour CODEBASE=http://localhost:8080/>
<PARAM NAME="nom" VALUE="Julien">
Si vous lisez ce texte, c'est que votre serveur Web ne supporte pas
les Servlets utilisées via SSI.
</SERVLET>
</BODY>
</HTML>

Afin de signaler au serveur Web que cette page HTML comprend une directive SSI, il faut nommer le fichier avec l'extension « .shtml », et non « .html ». Ceci est le comportement par défaut et dépend en réalité de la configuration de votre serveur Web.

Tout d'abord on remarque une balise inhabituelle : la balise <SERVLET>. C'est elle qui indique que l'on veut inclure le contenu produit par une Servlet dans la page Web. Cette balise reconnaît plusieurs paramètres. Le paramètre CODE indique le nom de la Servlet à invoquer. Le paramètre CODEBASE doit, juxtaposé à la valeur du paramètre CODE, former l'URL grâce auquel on peut accéder à la Servlet en temps normal (sans utiliser SSI). Ensuite, il est possible de passer des paramètres à cette Servlet, grâce à la balise PARAM. Le nom de ce paramètre est précisé par l'attribut NOM et la valeur par VALUE. Ces paramètres seront récupérés par la méthode getParameter(String nomParametre) de l'objet de type HttpServletRequest passé à la Servlet lors de son invocation. Le texte écrit juste avant la fermeture de la balise SERVLET s'affiche au cas où le serveur Web ne supporte pas cette balise (et donc les Servlets invoquées via SSI). Il est également possible de déterminer les valeurs de certains paramètres dès l'initialisation grâce à un attribut placé dans la balise <SERVLET> de la forme initParamètre1=valeur1.

La servlet Bonjour, appelée lors de l'analyse de la page HTML ci-dessus, pourrait être la suivante :

import javax.servlet.*;
 import java.servlet.http.*;

 public class BonjourMonde extends HttpServlet {
   public void doGet(HttpServletRequest req, HttpServletResponse res) throws  
   ServletException, IOException) {

         PrintWriter out = res.getWriter();

         String param1 = req.getParameter("nom");

         out.println("Hello "+param1+" !");
    }

Il suffit de compiler cette Servlet de manière classique et de la placer à l'emplacement indiqué par la balise « CODEBASE » du code HTML de la page incluant la sortie de la Servlet. On note la compacité du code par rapport à une Servlet autonome produisant le même effet. Les Servlets invoquées via SSI sont intéressantes lorsque le contenu statique est plus important que le contenu dynamique. Cela permet à l'intégrateur du code HTML et au développeur de Servlets une plus grande liberté : ils n'ont rien à modifier pour que les modifications soient prises en compte des deux côtés.

On remarque aussi qu'il ne faut pas définir le type MIME de la réponse, car la réponse du serveur Web a déjà débuté au moment de l'appel à la Servlet, et ce début de réponse contenait l'entête précisant son type MIME (voir protocole_http). La ligne :

    res.setContentType("text/html");

n'est donc plus nécessaire.

Une autre technique d'inclusion de code dans des pages HTML est JSP. Cette technique est née d'un besoin émanant des développeurs : ils avaient besoin d'un mode de développement similaire aux ASP de Microsoft (voir ASP_microsoft) et à PHP (voir la même section que pour ASP). De cette manière ils pourraient inclure directement du code (et non pas un marqueur appelant une Servlet) dans la structure de leurs documents écrits en HTML.

Les JSP permettent donc d'éviter au programmeur d'employer l'instruction out.println(String chaine_a_imprimer) trop souvent lorsque le contenu est en majorité statique. Cependant, elles ne garantissent pas une très bonne coopération entre l'intégrateur HTML et le développeur de Servlets, dans le cas où ils ne sont pas la même personne. En effet si le programmeur désire changer son code, il doit ouvrir le fichier contenant le code HTML et si l'intégrateur HTML désire changer la structure ou le contenu de la page Web, il doit ouvrir le fichier contenant le code de la Servlet. C'est donc à priori moins souple, mais il s'avère que cette technique est très bien adaptée pour les développements de petite envergure, et lorsque le développeur et l'intégrateur HTML ne sont qu'une seule personne.

Voici comment se présente une JSP qui produit le même message que les Servlets précédentes (une salutation amicale très célèbre) :

<HTML>
<HEAD>
<TITLE>Essai de JSP</TITLE>
</HEAD>
<BODY>
<% if (request.getParameter("nom") == null) {
      out.println("Bonjour monde !");
   } else {
      out.println("Bonjour " + request.getParameter("nom")  + " !");
   }
%>
</BODY>
</HTML>

Il suffit d'enregistrer ce fichier avec un nom ayant pour extension « .jsp » et de le placer dans le répertoire adéquat, ce qui peut dépendre de la configuration de votre serveur Web ou du moteur de Servlets que vous utilisez.

Je vais vous donner maintenant quelques explications sur les écritures pouvant vous sembler mystérieuses. Premièrement, la balise « <% » permet d'indiquer le début d'une section de code dynamique. La balise « %> » permet donc de marquer la terminaison d'une telle section (on appelle ce type de section une scriptlet). Je garde une appellation aussi générale, car il est possible d'écrire des JSP avec un autre langage que Java (comme javascript qui est complètement différent) même si ce n'est pas très courant. À l'intérieur de ce code, on peut placer plusieurs types d'instructions :

• les directives ;
• les expressions ;
• le code classique.

Les directives permettent de définir certains aspects structurels de la servlet de fond, comme l'importation d'un package, l'extension d'une classe, le type de contenu produit ou encore la méthode HTTP utilisée (voir méthodes http pour connaître ce qu'est une méthode HTTP). Les définitions sont effectuées par l'intermédiaire d'affectation de valeurs à des variables bien définies. Ces directives sont encadrées d'une balise ouvrante « <%@ » et d'une balise fermante « %> ». Par exemple, pour importer le package « monpackage » dans la JSP, il suffit d'insérer le code suivant :

<%@ import = "monpackage.*"%>

Pour définir une extension de classe, on utilise :

<%@ extends = "maClassePersoHttp" %>

si l'on veut que la servlet de fond étende la classe maClassePersoHttp. Je ne vais pas énumérer toutes les directives disponibles ici, pour cela je vous invite à vous reporter à l'annexe B et à la documentation de référence à propos de jsp disponible à http://java.sun.com/products/jsp/.

Les expressions permettent de convertir le résultat de l'expression évaluée en String et d'inclure ce résultat converti dans le code HTML de la page Web générée par la Servlet de fond. Cela permet d'éliminer les appels à la méthode println(String chaine). Une expression débute par la balise ouvrante « <%= » et se termine par la balise fermante « %> ». Par exemple, l'expression suivante :

<%= ma_variable %>

inclut la valeur de la variable ma_variable dans le code HTML généré. On peut bien entendu utiliser des méthodes comme expression à évaluer comme dans :

<%= request.getParameter("parametre") %>

qui permet d'inclure la valeur du paramètre de nom parametre passé à la Servlet de fond. Remarquez que l'absence de « ; » à la fin de l'expression n'est pas un oubli.

Le code classique utilise les mêmes conventions que les Servlets traditionelles, mais vous pouvez remarquer l'emploi d'identifiants qui n'ont pas été définies. Ces identifiants sont :

• request : l'objet représentant la requête venant du client ;
• out : l'objet représentant le flux d'impression en sortie.

Ils sont utilisables dans chaque page Web utilisant JSP.

Maintenant que nous avons décrit la forme du développement de Servlets grâce à JSP, intéressons-nous au fonctionnement interne.

Je mentionne dans la section précédente le terme de « Servlet de fond ». En effet, le moteur de Servlets ne procède pas un interpréteur spécifique aux Servlets et un autre spécifique aux documents utilisant JSP. Le procédé d'exécution d'une JSP se déroule en plusieurs étapes.

Tout d'abord, le fichier correspondant à la JSP, qui comprend à la fois du code HTML, du code Java ainsi que les directives et déclarations, est traduit afin d'obtenir le code d'une Servlet aboutissant au même résultat. Cette traduction est quasiment directe pour le code dynamique tandis que le code statique est traduit grâce à des appels à la méthode println(String chaine).

Une fois la traduction effectuée, la Servlet de fond obtenue (qui est alors une servlet tout à fait classique jusqu'à la fin de son cycle de vie) est déplacée dans un emplacement particulier du système de fichier du moteur de Servlet pour y être compilée, comme une Servlet traditionnelle.

Une fois compilée, la Servlet de fond est chargée, initialisée et exécutée.

De ce procédé d'exécution des JSP découlent plusieurs de leurs comportements propres. En effet, lors de la première exécution d'une JSP, vous constaterez qu'il est nécessaire de patienter un certain temps avant d'obtenir le résultat du traitement, alors que lors des appels ultérieurs, ce n'est pas le cas. Cela est dû au fait que lors du premier appel, il faut réaliser tout le procédé de la traduction à l'exécution (en passant par la compilation) alors que lors des appels suivants, seule l'exécution est nécessaire. Ensuite, il est maintenant clair et légitime de ne pas disposer d'une API spécifique aux JSP, car ce sont en définitive des Servlets classiques avant leur compilation. Seul le support proposé par le moteur de Servlets influe sur les possibilités dont vous pouvez bénéficier (comme de nouvelles directives permettant d'inclure des Java Beans par exemple). Enfin, vous pourrez comprendre que votre JSP se recharge automatiquement dès que le fichier contenant son code est modifié (le fichier possédant l'extension « .jsp »), car une Servlet est rechargée par le moteur de Servlets pour les mêmes raisons.

Il me semble nécessaire de préciser que malgré les services que peuvent rendre les JSPs pour de petites applications, elles ont surtout été créées pour opposer une réponse aux ASP de Microsoft. Ces dernières ressemblent en effet énormément aux JSPs à tous les niveaux, et sont appréciées des programmeurs Web côté serveur pour leur facilité d'utilisation.

Vous connaissez maintenant les principales formes de développement des Servlets, je vais maintenant vous proposer quelques références à propos d'outils de développement pouvant faciliter la programmation en tirant parti des avantages de la technologie de la plate-forme Java côté serveur.