Servlets Java - Guide du programmeur

1
Introduction
L’arrivée des applications Java sur le serveur, de la servlet autonome à la plate-forme
J2EE (Java 2, Enterprise Edition) complète, a été l’une des plus excitantes orientations de
la programmation en Java. Le langage Java était à l’origine destiné à une utilisation dans
de petits périphériques embarquables. Il a d’abord été utilisé pour le développement de
contenu élaboré du côté client sous la forme d’applets. Mais jusqu’à ces dernières an-
nées, le potentiel de Java comme plate-forme de développement du côté serveur a été
très largement négligé. Maintenant, Java est devenu un langage parfaitement adapté
aux développements côté serveur.
Les entreprises, en particulier, ont très vite vu le potentiel de Java sur le serveur — Java
est intrinsèquement adapté aux grandes applications client/serveur. La nature multi-
plates-formes de Java est extrêmement utile aux entreprises qui ont un ensemble de ser-
veurs hétérogènes exécutant différentes versions des systèmes d’exploitation Unix ou
Windows (et de plus en plus Mac OS X). La conception de Java étant à la fois moderne
et orientée objet, et offrant une protection de la mémoire, les développeurs peuvent ré-
duire les coûts de développement et augmenter la robustesse. De plus, l’intégration
dans Java du support réseau et des API d’entreprise offrent un accès aux données héri-
tées, facilitant la migration depuis les anciens systèmes client/serveur.
Les servlets Java sont une composante clé du développement Java côté serveur. Une ser-
vlet est une petite extension intégrable à un serveur afin d’en étendre les fonctionnali-
tés. Les servlets permettent au développeur d’étendre et de personnaliser tout serveur
web ou tout serveur d’applications supportant Java avec un degré de portabilité, de sou-
plesse et de facilité jusqu’ici inconnu. Mais avant d’aller plus en détail, mettons les cho-
ses en perspective.
Histoire des applications web
Bien que les servlets puissent être utilisées pour étendre les fonctionnalités des serveurs
supportant Java, elles sont aujourd’hui le plus souvent utilisées pour étendre les ser-
veurs web, offrant un remplacement puissant et efficace aux scripts CGI. Lorsque vous
utilisez une servlet pour créer un contenu dynamique dans une page web ou pour éten-
dre d’une autre façon les fonctionnalités d’un serveur web, en fait vous créez une appli-
Servlets 2.book Page 1 Mardi, 12. novembre 2002 4:49 16

2 Chapitre 1 — Introduction
cation web. Tandis qu’une page web ne fait qu’afficher un contenu statique et permettre
à l’utilisateur de naviguer au travers de ce contenu, une application web offre une expé-
rience plus interactive. Une application web peut être aussi simple qu’une recherche de
mot-clé dans une archive ou aussi complexe que servir d’accès à une boutique électro-
nique. Les applications web sont déployées sur l’Internet ou au sein d’intranets et d’ex-
tranets d’entreprise, où elles ont la possibilité d’améliorer la productivité et de changer
la façon dont les sociétés, petites ou grandes, travaillent.
Pour comprendre la puissance des servlets, nous devons revenir en arrière et examiner
les autres approches qui ont été utilisées pour créer des applications web.
Common Gateway Interface (CGI)
Common Gateway Interface, habituellement appelé CGI, a été l’une des premières tech-
niques pratiques pour créer du contenu dynamique. Avec CGI, un serveur web envoie
certaines requêtes à un programme extérieur. La sortie de ce programme est ensuite en-
voyée au client à la place d’un fichier statique. L’arrivée de CGI a permis d’implémenter
toutes sortes de nouvelles fonctionnalités dans des pages web et CGI est vite devenu un
standard de facto, implémenté sur des dizaines de serveurs web.
Il est intéressant de noter que la faculté des programmes CGI à créer des pages web dy-
namiques n’est qu’un effet secondaire de son but initial : définir une méthode standard
pour qu’un serveur d’information communique avec des applications externes. Cela ex-
plique pourquoi CGI a peut-être le pire cycle de vie que l’on puisse imaginer. Lorsqu’un
serveur reçoit une requête qui accède à un programme CGI, il doit créer un nouveau
processus pour exécuter ce programme et ensuite lui passer, via des variables d’environ-
nement et l’entrée standard, chaque bit d’information qui pourrait être nécessaire à la
génération d’une réponse. La création d’un processus pour chacune de ces requêtes de-
mande du temps et d’importantes ressources serveur, ce qui limite le nombre de requê-
tes qu’un serveur peut traiter de façon concurrente. La figure 1-1 montre le cycle de vie
d’un programme CGI.
Même si un programme CGI peut être écrit en n’importe quel langage, Perl est devenu
le choix prédominant. Ses possibilités de gestion de texte avancées sont d’une grande
aide dans le traitement des détails de l’interface CGI. Écrire un script CGI en Perl lui
donne un semblant d’indépendance de la plate-forme, mais il faut aussi que chaque re-
quête démarre un interpréteur Perl séparé, ce qui prend encore plus de temps et deman-
de encore plus de ressources.
Figure 1-1. Cycle de vie de CGI
Servlets 2.book Page 2 Mardi, 12. novembre 2002 4:49 16

Histoire des applications web 3
Un autre problème souvent négligé est qu’un programme CGI ne peut pas interagir
avec le serveur web pour tirer parti de ses possibilités une fois qu’il a commencé son exé-
cution parce qu’il s’exécute dans un processus séparé. Par exemple, un script CGI ne
peut pas écrire dans le fichier de journalisation du serveur. Pour plus d’informations sur
la programmation CGI, consultez le livre CGI Programming on the World Wide Web de
Shishir Gundavaram (O’Reilly & Associates).
FastCGI
Une société appelée Open Market a développé une alternative au standard CGI appelée
FastCGI. Globalement, FastCGI fonctionne comme CGI. La différence importante est
qu’un seul processus persistant est créé pour chaque programme FastCGI, comme mon-
tré en figure 1-2. Ceci élimine la nécessité de créer un nouveau processus pour chaque
requête.
Bien que FastCGI soit un pas dans la bonne direction, le problème de la prolifération
de processus n’est pas réglé: il y a au moins un processus pour chaque programme
FastCGI. Si un programme FastCGI doit gérer des requêtes concurrentes, il a besoin
d’une réserve de processus, un par requête. Si l’on considère que chaque processus peut
exécuter un interpréteur Perl, cette approche n’est pas aussi extensible que l’on pourrait
l’espérer. (Cependant, à son crédit, FastCGI peut distribuer ses processus sur de multi-
ples serveurs.) Un autre problème avec FastCGI est qu’il n’aide en rien le programme
FastCGI a interagir plus étroitement avec le serveur. Enfin, les programmes FastCGI
sont aussi portables que le langage dans lequel ils ont été écrits. Pour plus d’informa-
tions sur FastCGI, visitez le site http://www.fastcgi.com.
PerlEx
PerlEx, développé par ActiveState, améliore les performances des scripts CGI écrits en
Perl pour les serveurs web sous Windows NT (Internet Information Server de Micro-
soft, WebSite Professional de O’Reilly et FastTrack Server et Enterprise Server de iPla-
net). Il a les mêmes avantages et inconvénients que FastCGI. Pour plus d’informations
sur PerlEx, consultez le site http://www.activestate.com/plex/.
mod_perl
Si vous utilisez le serveur web Apache, une autre option pour améliorer les performan-
ces CGI est d’utiliser mod_perl. mod_perl est un module pour Apache qui intègre une
Figure 1-2. Cycle de vie de FastCGI
Servlets 2.book Page 3 Mardi, 12. novembre 2002 4:49 16

4 Chapitre 1 — Introduction
copie de l’interpréteur Perl dans l’exécutable Apache, fournissant un accès complet aux
fonctionnalités de Perl dans le serveur. Les scripts CGI sont ainsi précompilés par le ser-
veur et exécutés sans passer par une création de processus. Ils s’exécutent alors beaucoup
plus vite et bien plus efficacement. L’inconvénient est que l’application doit obligatoi-
rement être déployée sur le serveur Apache. Pour plus d’informations sur mod_perl, vi-
sitez le site http://perl.apache.org/.
Autres solutions
L’association CGI/Perl a l’avantage de produire du contenu web dynamique d’une façon
plus ou moins indépendante de la plate-forme. D’autres technologies bien connues
pour créer des applications web, telles que ASP et JavaScript côté du serveur, sont des
solutions propriétaires qui ne fonctionnent qu’avec certains serveurs web.
API d’extension du serveur
Plusieurs sociétés ont créé des API propriétaires pour l’extension de leur serveur web.
Par exemple, iPlanet/Netscape offre une API interne appelée WAI (précédemment
NSAPI) et Microsoft fournit ISAPI. En utilisant l’une de ces API, vous pouvez écrire des
extensions du serveur permettant d’en améliorer ou d’en changer les fonctionnalités de
base, lui permettant ainsi de traiter des tâches qui étaient auparavant déléguées à des
programmes CGI externes. Comme vous pouvez le voir dans la figure 1-3, les extensions
du serveur existent à l’intérieur du processus principal du serveur Web.
Les API spécifiques à un serveur utilisant du code C ou C++, les extensions peuvent
s’exécuter très rapidement et tirer pleinement parti des ressources du serveur. Cepen-
dant, elles ne sont pas une solution parfaite sur plusieurs plans. En dehors d’être diffi-
ciles à développer et à maintenir, elles posent d’importants problèmes de sécurité et de
fiabilité : une extension du serveur qui se plante peut amener le serveur entier à
s’arrêter ; une extension du serveur malveillante peut dérober les mots de passe des uti-
lisateurs et créer des numéros de carte de crédit. Et, bien sûr, une extension propriétaire
est inévitablement liée à l’API du serveur pour laquelle elle a été écrite, et bien souvent
liée à un système d’exploitation particulier.
Figure 1-3. Cycle de vie d’une extension du serveur
Servlets 2.book Page 4 Mardi, 12. novembre 2002 4:49 16

Histoire des applications web 5
JavaScript côté serveur
iPlanet/Netscape a lui aussi une technique pour fournir les scripts sur le serveur, qu’il
appelle server-side JavaScript, ou SSJS pour faire court. Comme ASP, SSJS permet d’in-
clure des morceaux de code dans des pages HTML pour générer du contenu web dyna-
mique. La différence est que SSJS utilise JavaScript comme langage de scripts. Avec SSJS,
les pages web sont précompilées afin d’améliorer les performances. Le support de SSJS
n’est disponible qu’avec les serveurs de iPlanet/Netscape. Pour plus d’informations sur
la programmation avec SSJS, reportez-vous à http://developer.netscape.com/tech/javascript/
ssjs/ssjs.html.
Active Server Pages
Microsoft a développé une technique pour générer du contenu web dynamique appelée
les Active Server Pages, ou ASP. Avec les ASP, une page HTML sur le serveur web peut
contenir des morceaux de code embarqués (habituellement en VBScript ou Jscript, bien
qu’il soit possible d’utiliser à peu près n’importe quel langage). Ce code est lu et exécuté
par le serveur web avant qu’il n’envoie la page au client. Les ASP sont optimisées pour
générer de petites portions de contenu dynamique à l’aide de composants COM pour
les traitements lourds.
Le support des ASP est intégré à Microsoft Internet Information Server version 3.0 et
supérieure, disponible gratuitement à http://www.microsoft.com/iis. Le support pour
d’autres serveurs web est disponible sous forme de produit commercial chez Chili!Soft
à l’adresse http://www.chilisoft.com. Sachez que les ASP s’exécutant sur une plate-forme
non-Windows peuvent avoir des difficultés à réaliser des tâches avancées sans la biblio-
thèque COM de Windows. Pour plus d’informations sur la programmation des Active
Server Pages, reportez-vous à http://www.microsoft.com/asp et à http://www.activeserver-
pages.com/.
JavaServer Pages
Les JavaServer Pages, appelées couramment JSP, sont une alternative Java aux ASP inven-
tée et normalisée par Sun. Les JSP utilisent une syntaxe similaire aux ASP, mais le lan-
gage de script est Java. Contrairement aux ASP, les JSP sont une norme ouverte
implémentée par des dizaines de fournisseurs sur toutes les plates-formes. Les JSP sont
intimement liées aux servlets car une page JSP est transformée en une servlet pendant
son exécution. Les JSP sont détaillées tout au long de ce livre. Pour plus d’informations
sur les JSP, visitez le site http://java.sun.com/products/jsp.
Servlets Java
Bienvenue dans les servlets Java. Comme nous l’avons dit précédemment, une servlet
est une extension de serveur générique — une classe Java qui peut être chargée dynami-
quement afin d’étendre les fonctionnalités d’un serveur. Les servlets sont couramment
utilisées sur les serveurs web, où elles peuvent prendre la place des scripts CGI. Une ser-
vlet est similaire à une extension de serveur propriétaire, excepté qu’elle s’exécute dans
une machine virtuelle Java (JVM) sur le serveur (voir la figure 1-4), elle est donc sûre et
portable. Les servlets opèrent uniquement à l’intérieur du domaine du serveur : con-
trairement aux applets, elles n’imposent pas le support de Java dans le navigateur web.
Servlets 2.book Page 5 Mardi, 12. novembre 2002 4:49 16