IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel sur les Servlets Java

Tutoriel sur les Servlets Java


précédentsommairesuivant

III. Introduction au développement

Maintenant que les présentations sont faites, je vous invite à manipuler les Servlets. Cette introduction au développement des Servlets vous donnera les connaissances de base sur les technologies constituant les fondements sur lesquels reposent les Servlets (comme le protocole HTTP). Elle décrira en détail l'installation du moteur de Servlets Tomcat couplé au serveur Apache après avoir fait le tour des solutions et justifié mon choix et vous expliquera précisemment sous quelle forme se présente une Servlet, comment et avec quels outils les développer.

III-A. Les bases des applications Web côté serveur

III-A-1. Les applications client-serveur

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.

Image non disponible

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

Afin d'illustrer et de mieux comprendre comment se déroule une communication entre un client web (qui peut être un navigateur ou toute autre application utilisant le protocole HTTP) et un serveur Web, je vais tenter d'expliquer un peu plus en détail le fonctionnement du protocole HTTP.

Le serveur se place en mode d'écoute sur un port bien défini, qui est généralement le port 80, même si cela n'a rien d'obligatoire. A chaque requête reçue de la part du client, il crée un nouveau processus qui va prendre en charge cette requête. Le dialogue peut alors débuter, et le client doit alors émettre sa requête, qui doit être conforme au protocole HTTP.

Ces requêtes sont transmises au serveur web via la connexion établie entre le client et le serveur et prennent la forme de données classiques (textuelles). Il existe un nombre important de requêtes différentes, mais en réalité beaucoup de requêtes sont très peu utilisées. L'annexe A décrit tous les types de requêtes disponibles dans le protocole HTTP avec une courte description. Le client envoie donc sa requête, le serveur l'analyse et renvoie une réponse au client (adaptée à sa requête) au travers de la même connexion. La connexion est ensuite coupée. Le client doit émettre des requêtes conformes à la version du protocole HTTP implémentée par le serveur. En général les serveurs récents (comme Apache) implémentent la version 1.1 tandis que certains serveurs anciens ne supportent que la version 1.0. Les serveurs supportant la version 1.1 du protocole supportent aussi, en général, la version 1.0. La version du protocole est précisée dans l'entête de la requête émanant du client et dans la réponse faite par le serveur.

Afin de tester les comportements décrits dans les exemples que je donnerai, vous pouvez utiliser l'outil telnet (disponible sur tous les systèmes d'exploitation dignes de ce nom) de la manière suivante :

 
Sélectionnez
telnet adresse_ip_serveur_web 80

où adresse_ip_serveur est l'adresse ip du serveur web cible (je pense que vous le saviez dejà ;-)). Il ne vous reste plus qu'à entrer la requête à l'invite qui vous est proposée.

La partie principale de la requête en ce qui concerne le client est la commande, placée sur la première ligne de la reqûete. Elle détermine l'action à effectuer. Ces commandes sont parfois accompagnées d'arguments qui précisent l'objet sur lequel porte la commande. L'action la plus courament utilisée est la récupération d'un document en utilisant la commande GET ou POST (GET et POSt sont deux méthodes HTTP différentes pour effectuer la même action). Cette commande prend comme argument la ressource à récupérer, c'est-à-dire le chemin vers le fichier à récupérer (ce n'est pas un chemin absolu, mais relatif à la racine du serveur). Par exemple :

 
Sélectionnez
GET /index.html HTTP/1.0

permet de récupérer le fichier index.html qui est situé à la racine du répertoire d'installation du serveur en utilisant la version 1.0 de HTTP.

De manière générale, les clients placent une entête dans leur requête, à la suite de la commande, décrivant par exemple qui ils sont (le nom et le numéro de version pour un navigateur par exemple) et ce qu'ils peuvent accepter (des images, du texte au format HTML pour le même type de logiciel par exemple). Certaines entêtes sont optionelles et d'autres obligatoires, cela dépend de la requête et de la configuration du serveur Web à qui la requête est transmise. Vous devrez par exemple ajouter une entête spécifiant un identifiant et un mot de passe si le serveur Web est configuré de telle manière qu'il n'accepte pas les personnes inconnues. Par exemple :

 
Sélectionnez
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)

nous indique que le client à l'origine de la requête est le navigateur netscape (basé sur Mozilla, d'où l'apparition de ce nom) tournant sous Linux et qu'il accepte le texte au format HTML et les images au format GIF. La requête d'un client Web doit être suivie de deux sauts à la ligne pour être prise en compte.

Une fois la requête du client analysée (entête et corps de la requête), le serveur dispose de tous les éléments pour produire une réponse. Le premier élément de la réponse est appelé l'état qui spécifie la version du protocole HTTP utilisée, un code d'état et une courte description de cet état. L'entête de la réponse vient après cette ligne d'état. Celle ci décrit par exemple le type de données qui est envoyé (texte au format ASCII, au format HTML, images au format gif, etc.). Le serveur peut ensuite envoyer les données au navigateur qui les analysera correctement en se conformant aux directives données par l'entête de la réponse du serveur. Par exemple :

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

nous indique que la requête peut être traitée avec succès ( code d'état 200 et description du code à "OK" ) et qu'elle est traitée par le serveur Apache dans sa version 1.3.14. On sait également que la réponse contient exclusivement du texte au format HTML.

Une fois cette entête envoyée au client, le serveur peut débuter l'envoi des données (le fichier index.html si on se base sur la requête en exemple au dessus) en séparant l'entête et les données de deux lignes vides. Ces deux lignes vides sont indispensables indispensables.

Je le répète, après l'envoi des données au client, la connexion est interrompue, même si le client est susceptible d'émettre une requête pour accéder à une ressource sur ce même serveur immédiatement après. On dit que le protocole HTTP n'est pas orienté session : il n'y a aucun moyen d'identifier un utilisateur au cours d'une série de connexion à un site Web. Or il est fréquent que des utilisateurs effectuent une série d'actions logiques destinées à atteindre un but bien précis (acheter un produit sur un site marchand par exemple). Il est donc problématique d'identifier correctement cette suite logique avec les seuls outils mis à disposition par le protocole HTTP. Certains outils des Servlets que nous verrons dans le chapitre consacré au suivi de session sont là pour corriger ce manque.

III-B. La mise en place du serveur

Vous avez désormais acquis assez de connaissance à propos du protocole HTTP et du fonctionnement des applications Web côté serveur pour passer à la pratique. Afin de pouvoir tester vos premières Servlets, vous devez installer le serveur Web et le moteur de Servlets qui les exécuteront. Je vais tenter dans un premier temps de vous donner un tour d'horizon des diverses solutions existantes, puis vous faire part de mon choix et des causes de ce choix, et enfin je vous guiderais au travers de l'installation du serveur.

III-B-1. Les différents types de solutions

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 sur, 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 EJBs 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 chers, et qui requièrent de multiples compétences. Leur utilisation et leur configuration est similaire aux solution 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 écar terais 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 EJBs, 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.

III-B-2. Le choix de la solution

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 JSPs. 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 choisit 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 choisis 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 marche (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.

III-B-3. L'installation de Tomcat et Apache

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 :

 
Sélectionnez
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

Avant de procéder à l'installation de Tomcat, il est nécessaire d'installer un environnement de développement Java. Pour cela, je vous conseille d'utiliser le JDK1.3 fournit par Sun. Si vous disposez d'un kit de développement Java d'une version ultérieure ou égale à la version 1.1, vous pouvez ignorer cette étape (bien que pour des raisons évidentes de performances et de fonctionnalités je vous conseille d'installer la dernière version du kit de développement). Il est téléchargeable au format tar.gz (indépendant de la distribution) à l'URL suivant : http://java.sun.com/j2se/1.3/download-linux.html. Une fois ce fichier téléchargé, vous devez le décompresser et le désarchiver dans le répertoire de votre choix (par exemple /usr/local/jdk1.3) grâce à la commande suivante :

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

Une fois ceci effectué, déplacez vous dans le répertoire $JAVA_HOME/bin où $JAVA_HOME est le répertoire dans lequel le JDK est installé (dans notre exemple : /usr/local/jdk1.3/bin) de la manière suivante :

 
Sélectionnez
cd /usr/local/jdk1.3/bin

Lancez alors la commande :

 
Sélectionnez
./javac

Si vous obtenez un message vous indiquant toutes les options disponibles pour le compilateur Java, c'est gagné. afin de faire bénéficier toutes vos applications susceptibles d'utiliser Java (comme Tomcat) de l'environnement installé, je vous conseille d'ajouter les outils du langage dans votre PATH comme ceci :

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

en considérant toujours que vous avez installé le JDK dans /usr/local/jdk1.3. Maintenant vous pouvez utiliser les outils du langage (le compilateur, le visionneur d'applets, etc.) où que vous soyez dans l'arborescence de votre système de fichiers.

Maintenant que l'environnement de développement pour Java est installé, nous allons passer à l'installation du moteur de Servlets Tomcat.

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

Nous allons maintenant procéder à l'installation du moteur de Servlets. Pour cela vous devez d'abord télécharger la version 3.2.1 de Tomcat disponible à l'URL suivant : http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.1/bin/. Cette version n'est pas la dernière version de Tomcat. En effet le développement de Tomcat est vraiment très actif, et de nouveaux concepts sont introduits régulièrement.

Par exemple, en ce qui concerne le protocole de communication entre le serveur Web Apache et le moteur de Servlets Tomcat, un nouveau procédé est apparu depuis la version 3.2.1 : JK. mod_jk (le module dynamique chargé par Apache au démarrage pour prendre en compte JK) est destiné, à moyen terme, au remplacement de mod_jserv (le protocole de communication entre le serveur Web et le moteur de Servlets que je vais décrire dans cette installation). JK apporte un certain nombre d'avantages comme le support de plusieurs serveurs Web différents via la même interface (IIS, Netscape Server, Apache 2.x, etc.), la gestion correcte du protocole HTTPS (protocole HTTP sécurisé grâce à l'utilisation de SSL). De plus, JK n'est pas une adaptation de d'Apache JServ au contraire de mod_jserv qui comporte donc du code inutile.

Cependant, le caractère nouveau de mod_jk ne me permet pas de le maîtriser suffisamment pour vous proposer une aide à propos des configurations complexes, contrairement à mod_jserv que je connais mieux. De plus, mod_jserv est encore largement plus répandu que mod_jk. Je vais donc vous expliquer la configuration basique de Tomcat avec mod_jserv et mod_jk, et je vous proposerais ensuite une configuration avancée avec mod_jserv.

Afin d'installer Tomcat, je vous suggère de télécharger les sources de la dernière version stable à l'URL suivant : http://jakarta.apache.org/builds/tomcat/release/v3.2.1/src/. La dernière version stable est la 3.2.1, donc en ce moment vous devriez télécharger le fichier jakarta-tomcat-3.2.1-src.tar.gz.

Vous devrez ensuite télécharger d'autres outils :

  1. JSSE pour Java Secure Socket Extension permet d'établir des connexions sécurisées au travers d'un réseau (à l'aide de SSL par exemple) entre deux machines. Disponible à http://java.sun.com/products/jsse/.
  2. Ant : c'est un gestionnaire de compilation conditionnelle, au même titre que make sous Unix. Il permet, en écrivant des fichiers de description de compilation, de ne recompiler que les fichiers qui ont changé. C'est très utile pour compiler de gros programmes (comme Tomcat). Disponible à http://jakarta.apache.org/builds/ant/release/v1.2/src/jakarta-ant-src.tar.gz.
  3. JAXP pour Java API for XML Processing permet d'analyser des fichiers au format XML. Disponible à http://java.sun.com/xml/download.html.
  4. Servlet API : les classes qui implémentent l'API des Servlets. Disponible à http://java.sun.com/products/servlet/download.html.

Une fois ces outils téléchargés, vous devez créer un répertoire de base pour la création d'une version binaire de Tomcat : nous utiliserons /usr/local/tomcat-dist :

 
Sélectionnez
mkdir /usr/local/tomcat-dist

Décompressez ensuite tous les fichiers téléchargés dans ce répertoire :

 
Sélectionnez
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

Installons maintenant les packages Java nécessaires à la compilation de Tomcat. Nous avons déjà copié le package des Servlets dans /usr/local/jdk1.3/jre/lib, il faut faire de même avec les fichiers jaxp.jar et parser.jar de la version de JAXP que vous avez récupéré et avec les fichiers jnet.jar, jsse.jar et jcert.jar que vous avez récupéré dans l'archive de JSSE. Ce procédé vous évite d'ajouter le chemin vers ces fichiers dans la variable d'environnement CLASSPATH, mais vous pouvez également utiliser cette méthode.

Maintenant, il faut compiler Ant. Pour cela, allez dans le répertoire dans lequel vous l'avez décompressé et entrez :

 
Sélectionnez
./build.sh

la compilation devrait se dérouler sans aucun problème. Si une erreur de compilation mentionne qu'une classe ou qu'un package est introuvable, vous devriez vérifier que les .jar sus-cités sont à un emplacement correct (ou que la variable d'environnement CLASSPATH contient de bonnes valeurs.).

Il faut maintenant compiler Tomcat. Pour cela positionnez vous dans le répertoire dans lequel vous l'avez décompressé, et lancez :

 
Sélectionnez
./build.sh dist

cette commande va construire une "distribution" binaire identique à celle qui est téléchargeable sur le site de la fondation Apache mais adaptée à votre configuration. Une fois la compilation effectuée, vous pouvez tester le fonctionnement de tomcat.

Pour cela, allez dans le répertoire "bin" de votre distribution de Tomcat qui devrait être $TOMCAT_HOME/build/tomcat/bin si $TOMCAT_HOME est /usr/local/tomcat-dist. Entrez en tant qu'utilisateur "root" :

 
Sélectionnez
./startup.sh

Vous devriez voir un série de messages apparaître mentionnant le démarrage de Tomcat. Ouvrez ensuite un navigateur Web, et demandez d'accéder à l'URL suivant : http://127.0.0.1:8080/. Si vous obtenez la page de garde du serveur Tomcat, tout fonctionne parfaitement.

A ce moment précis, Tomcat fonctionne en mode indépendant, ce qui n'est pas ce que nous souhaitons (voir choix_solution). Nous allons maintenant décrire son association avec le serveur Web Apache de façon à en faire un moteur de Servlets externe.

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

Rassurez vous, cette partie de l'installation de l'environnement de travail est beaucoup plus simple que la précédente.

Tout d'abord, vous devez télécharger une version d'Apache supérieure à la 1.3.9, la dernière si possible (1.3.14) à l'URL suivant : http://httpd.apache.org/dist/apache_1.3.14.tar.gz.

Ensuite, vous devez la décompresser dans le répertoire de votre choix, par exemple /usr/local/src comme ceci :

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

ce qui devrait créer le répertoire /usr/local/src/apache-1.3.14. Allez dans ce répertoire avec la commande :

 
Sélectionnez
cd /usr/local/src/apache-1.3.14

et lancez la configuration du script de compilation comme ceci :

 
Sélectionnez
./configure -enable-module=so

ceci va activer le support des modules chargeables dynamiquement, ce qui sera nécessaire pour la communication entre Apache et Tomcat. Une fois le script de configuration terminé, lancez la commande suivante :

 
Sélectionnez
make install

qui va compiler et installer le serveur Web Apache dans le répertoire /usr/local/apache. Passons maintenant à la prise en charge de Tomcat. Comme je l'ai décrit plus haut, il existe deux façons différentes de procéder (voir jk_versus_jserv).

III-B-3-d. Configuration de mod_jserv

Pour permettre à Apache d'utiliser mod_jserv afin de communiquer avec Tomcat vous devez compiler le module chargeable mod_jserv.so. Pour cela, repositionnez vous dans le répertoire contenant les sources de ce module :

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

si vous avez effectué les mêmes manipulations que celles qui ont été décrites précédemment. Il faut ensuite utiliser l'utilitaire apxs fournit avec Apache et qui se trouve dans /usr/local/apache/bin (toujours si vous avez suivi mes instructions à la lettre) comme ceci :

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

ce qui devrait créer un module chargeable mod_jserv.so. Copiez ce fichier dans le répertoire de stockage des modules chargeables de Apache comme ceci :

 
Sélectionnez
cp mod_jserv.so /usr/local/apache/libexec

et spécifiez à Apache que vous désirez utiliser ce module pour communiquer avec Tomcat. Pour cela, un fichier tomcat-apache.conf a été créé dans l'arborescence de la distribution de Tomcat que vous avez créé. Il suffit de l'inclure dans le fichier de configuration de Apache. Ceci peut être effectué en ajoutant la ligne suivante dans le fichier /usr/local/apache/conf/httpd.conf :

 
Sélectionnez
    Include /usr/local/tomcat-dist/build/tomcat/conf/tomcat-apache.conf

et en validant la modification. Arrêtez ensuite tout processus concernant Apache ou Tomcat et lancez Tomcat puis Apache comme ceci :

 
Sélectionnez
/usr/local/tomcat-dist/build/tomcat/bin/startup.sh
 
Sélectionnez
/usr/local/apache/bin/apachectl start

ce qui devrait afficher quelques messages précisant que ces deux applications se sont correctement lancées. Vous pouvez maintenant tester votre installation en accédant à l'URL http://127.0.0.1/test/. Si vous obtenez une page Web vous souhaitant un joyeux Noël, la configuration est terminée.

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

Mod_jk est lui aussi un module permettant la communication entre Apache et Tomcat, il fonctionne donc selon le même principe que mod_jserv dont nous venons d'aborder la configuration de base. Vous devez donc suivre la même démarche pour installer ce module. Les seules modifications à apporter concernent les fichiers à manipuler. je ne vais donc faire qu'énumérer les commandes nécessaires à son installation, car vous pouvez vous reporter aux explications données dans la section précédente pour d'éventuels détails.

Vous devrez exécuter dans l'ordre les commandes suivantes :

 
Sélectionnez
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

et inclure le fichier /usr/local/tomcat-dist/build/tomcat/conf/mod_jk.conf dans le fichier de configuration d'Apache httpd.conf.

Redémarrez Tomcat et Apache comme précisé dans la section précédente et effectuez le même test.

La configuration des outils de communication entre Apache et Tomcat sont mis en place, mais je n'ai pas expliqué leur comportement en détail, ce qui peut être gênant si vous désirez personnaliser votre système. Je vous conseille donc de vous reporter à la documentation de Tomcat livrée avec les sources de celui-ci pour bénéficier d'avantages comme la répartition de charge, l'utilisation de machines virtuelles java distantes ou encore le réglage fin de la sécurité.

III-C. Ecrire sa première Servlet

L'environnement de travail est désormais correctement installé et configuré à votre goût : vous voilà fin prêt. Nous allons maintenant prendre connaissance avec les rudiments du développement des Servlets, ce qui nous mènera à l'écriture d'une première application : le désormais célèbre "Bonjour monde !". Nous verrons ensuite les différentes formes que peuvent prendre une Servlet et les outils de développement mis à votre disposition.

Comme nous l'avons dit précédemment, une Servlet n'est qu'un programme Java qui implémente une interface particulière : l'interface javax.servlet.Servlet. Une Servlet est donc un programme classique écrit en Java compilé avec le compilateur Javac. En général, une Servlet implémente l'interface javax.servlet.Servlet en étendant une des deux classes suivantes :

  • javax.servlet.GenericServlet.
  • javax.servlet.http.HttpServlet

Le programme Java étendant une de ces deux classes peut également utiliser les classes de l'API standard ou d'autres extensions (Java Mail, JTA ou autres) comme n'importe quel programme Java. La nécessité d'implémenter l'interface javax.servlet.Servlet vient du fait que le moteur de Servlet qui gère les appels à votre Servlet doit pouvoir obtenir un point d'entrée dans votre programme (qui n'est pas la méthode main puisqu'une Servlet est instanciée une seule fois, à son premier lancement) pour chaque requête. Ce point d'entrée est une des méthodes définie dans l'interface javax.servlet.Servlet.

Voici un exemple de code pour vous donner une idée plus précise :

 
Sélectionnez
import javax.servlet.*;
import java.servlet.http.*;
public class BonjourMonde extends HttpServlet {
  public void doGet(HttpServletRequest req, HttpServletResponse res) throws  
  ServletException, IOException) {
    res.setContentType("text/html");
    PrintWriter out = res.getWriter();
    out.println("<html><head></head><body>");
        out.println("Hello world !!!");
    out.println("</body></html>");
  }
}

Dans cet exemple, c'est la méthode doGet() qui sert de point d'entrée. Elle est exécutée quand un client effectue une requête utilisant la méthode HTTP GET et construit une page HTML, qui est retournée au client.

Saisissez cet exemple dans un éditeur de texte quelconque, sauvegardez sous le nom "BonjourMonde.java" et compilez le à l'aide la commande suivante :

 
Sélectionnez
javac BonjourMonde.java

En principe, aucun message ne devrait apparaître. Si ce n'est pas le cas, vérifiez bien que vous avez bien suivi toutes les étapes du procédé d'installation de l'environnement de travail.

Votre première Servlet est maintenant compilée, vous devez la publier sur votre serveur. En ce qui concerne Tomcat, vous devez placer le fichier .class obtenu à la suite de la compilation du source à un endroit bien précis. Le choix de cet emplacement dépend du rôle de votre Servlet et de vos fichiers de configuration relatifs à Tomcat et Apache. Lorsque vous ne modifiez aucun de ces fichiers, vous pouvez par exemple copier les fichiers .class de votre Servlet dans $TOMCAT_HOME/webapps/test/WEB-INF/classes/ où $TOMCAT_HOME correspond au répertoire dans lequel Tomcat est installé. Dans ce cas précis, vous accéderez à votre Servlet via l'URL http://127.0.0.1/test/servlet/BonjourMonde. Un charmant message devrait apparaître sur votre navigateur : vous venez de programmer votre première Servlet.

Il existe d'autres manières de développer des Servlets. Ce sont les JSP (pour Java Server Pages) et SSI (pour Server Side Includes).

III-D. Les autres modes de programmation

Nous avons vu qu'une Servlet était un programme écrit en Java tout à fait classique. Afin de produire un contenu HTML, le programmeur emploie un flux d'écriture auquel il demande l'impression de balises HTML. Il en résulte, même pour une Servlet aussi simple que notre premier exemple, un nombre trop important d'instructions destinées à écrire sur la sortie ce fameux code HTML.

Ceci est un inconvénient car le contenu n'est pas séparé des traitements. Dans le cas où l'intégrateur de code HTML et le programmeur de Servlets sont deux (ou plusieurs) personnes différentes, cela peut devenir rapidement très gênant : le programmeur doit constamment s'assurer que le code HTML qu'il produit lors des traitements est conforme à ce que désire l'intégrateur (ou le webmaster). Deux alternatives à la programmation classiques de Servlets sont donc disponibles : SSI (pour Server Side Includes) et JSP (pour Java Server Pages).

III-D-1. SSI

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 :

 
Sélectionnez
<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'initiali sation 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 :

 
Sélectionnez
 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 prisent 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 :

 
Sélectionnez
    res.setContentType("text/html");

n'est donc plus nécessaire.

III-D-2. JSP

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.

III-D-3. La forme

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) :

 
Sélectionnez
<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. A 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 :

 
Sélectionnez
<%@ import = "monpackage.*"%>

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

 
Sélectionnez
<%@ 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 :

 
Sélectionnez
<%= 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 :

 
Sélectionnez
<%= 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 fonctionement interne.

III-D-4. En coulisses

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 ASPs 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.

III-E. Les outils pour développer

Comme nous l'avons vu précédemment, seul un éditeur de texte classique et un compilateur java sont nécessaires pour programmer une Servlet. Cependant ce type de programme peut bénéficier de certains outils prenant en compte les spécificités du processus de développement des servlets.

Tout d'abord, une Servlet est un programme déployé sur une machine distante (en général). Or, comme tout programme créé par un humain, une Servlet possède des bogues ou des erreurs de conception. Ces erreurs doivent pouvoir être détectées et corrigées depuis la machine du développeur sur la machine de déploiement (donc à distance). De plus, ces corrections ne doivent pas porter préjudice au fonctionnement des autres Servlets ou du serveur de Servlets (ou du serveur Web selon que vous optiez pour un moteur de Servlets embarqué ou externe) lui même car nous avons pu voir (voir possibilités) que les Servlets sont souvent développées dans le cadre d'applications critiques pour l'entreprise (et le temps passé au débogage représente autant d'argent perdu). Un outil prenant en compte ces exigences constitue donc un avantage indéniable.

Ensuite, outre la programmation de Servlets écrites en Java avec une syntaxe classique, nous avons vu qu'il était possible d'utiliser les JSP. Ce procédé de développement utilise une syntaxe différente qui doit être clairement présentée pour être comprise et faciliter le développement. La prise en compte de la syntaxe utilisée pour le développement des JSP est donc une caractéristique intéressante.

Après, nous avons vu que la diffusion des Servlets sur des serveurs d'application ou leur utilisation dans le cadre d'applications "métiers" amène le développeur de Servlets à utiliser de nombreux composants propres à la version entreprise du kit de développement Java. Ces composants, comme les EJB (Enterprise Java Beans) voient leur dévelopement considérablement facilité par l'utilisation d'outils spécifiques réduisant l'effort nécessaire de développement concernant le "protocole" de développement propre aux Beans (la génération du squelette pour le nommage des accesseurs en lecture et en écriture par exemple) ou le développement "visuel" des Beans. Ces composants étant par définition amenés à être utilisés par d'autres composants pour former un système, leur déploiement à distance doit aussi être facilité.

Enfin, pour pouvoir tester localement le développement des Servlets, il est nécessaire de disposer d'un moteur de Servlet et de la version entreprise du JDK. Ces deux composants, lorsqu'ils sont intégrés à l'outil de développement, permettent une facilité et une efficacité de programmation accrue.

Toutes ces caractéristiques et d'autres encore sont reprises par plusieurs outils que je vais présenter succintement ici, il ne tient qu'à vous de devenir un utilisateur averti de ces logiciels.

Le premier de ces outils est JBuilder de Borland. La version 4.0 a apporté de sensibles améliorations et cet IDE (pour Integrated Development Environmnent) propose quelques caractéristiques intéressantes comme l'intégration de la version 1.3 du JDK, le débogage à distance, le débogage et mise en valeur du code source pour JSP, le support de la version 2.2 de l'API Servlet et de la version 1.1 des JSP, un moteur de Servlets intégré (WebLogic de BEA, voir weblogic_bea), la création visuelle de Java Beans et le déploiement de ceux-ci sans redémarrer le moteur de Servlets. Toutes ces caractéristiques sont disponibles avec la version "Entreprise" du logiciel, qui est la plus aboutie mais aussi la plus chère . Certaines sont disponibles avec des versions moins évoluées, pour en savoir plus reportez vous à l'URL http://www.borland.com/jbuilder/jb4/feamatrix/. Il est à noter que la version personnelle disponible gratuitement ne propose aucun de ces avantages.

Nous trouvons ensuite JRun Studio de Allaire, qui en est actuellement à sa version 3.1. C'est un outil de développement destiné à être couplé au serveur d'application JRun du même éditeur. Ce produit ne fonctionne que sous Windows et dispose de fonctionalités similaires à JBuilder mais il contient de nombreuses fonctionnalités destinées à la conception d'applications Web, à la manière d'un outil d'intégration HTML. Certains peuvent le percevoir comme un avantage (les intégrateurs de code HTML), d'autres comme un inconvénient (les programmeurs) car cela peut ajouter un peu de confusion.


précédentsommairesuivant

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2013 Julien Gilli. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.