Chapitres traités : Déploiement
des applications, Les
applets
Pour conclure le thème sur les bases de données, je vous invite à vous pencher dans cette étude, sur le problème de déploiement des applications. Il est vrai, que lorsque que nous mettons en une application, à la fin, il existe beaucoup de fichiers disparates que nous devons déployer. La solution, nous l'avons déjà vu, est d'utiliser l'archivage. Le déploiement consistant alors uniquement à récupérer un seul fichier de type <jar>.
Nous profiterons de cette étude pour mettre en oeuvre une applet distribuée sur Internet, qui sera en communication permanente avec la base de données situées sur votre réseau local. La communication s'établira alors au travers d'une servlet.
Pour bien comprendre cette étude, nous nous servirons du projet “Personnel.jpx” mis en oeuvre dans l'étude précédente. Il est également nécessaire de maîtriser parfaitement tout ce qui concerne les bases de données, ainsi que les systèmes de communication Web tels que les applets, les JSP et les servlets. Enfin, il faut, bien entendu, savoir archiver.
Pour en savoir plus sur les bases de données , sur les technologies Web , et sur l'archivage.
Déploiement des applications avec bases de
donnéesPour ce chapitre, je vais donc me servir du projet “Personnel.jpx” mis en oeuvre dans l'étude précédente dont voici la représentation lorsque vous lancer l'application.
Si nous consultons le répertoire où sont stockées les différentes classes, voilà ce que nous obtenons.
A priopri, on pourrait se dire qu'il suffirai de prendre ce répertoire “personnel”, et de le déployer sur l'ordinateur hôte pour que cela fonctionne.
N'oubliez surtout pas que l'ordinateur hôte doit possèder impérativement la machine virtuelle java, qui en plus, doit être au moins du même niveau que le JDK qui a servi à la compilation. La machine virtuelle java permet de s'affranchir du système d'exploitation utilisé, et elle utilisée pour interpréter les fichiers de type <class>. Je vous rappelle que la machine virtuelle java sans les outils de conception s'appelle JRE (Java Runtime Environment).
Je vous invite donc à tenter l'expérience en déployant ce répertoire “personnel” sur votre machine hôte qui doit posséder le JRE adapté sans avoir JBuilder d'installé. Lancez ensuite la commande adaptée qui va mettre en oeuvre votre machine virtuelle qui exécute une application fenêtrée et qui s'appelle javaw.
Rien ne se passe. Nous allons procéder autrement en lançant l'application avec la commande java pour visualiser les exceptions.
Vous remarquez que le système n'arrive pas à trouver la définition d'une classe “com/borland/dbswing/JdbCheckBox”. C'est la première classe qu'il a trouvé dans le code dont il ne trouve pas la définition, mais se serait vrai pour bien d'autres classes de ce style. En fait, pratiquement tous les composants relatifs aux bases de données (sauf JDBC) ne font pas partie du JRE, notamment, tous les composants DataExpress ainsi que tous les composants de dbSwing. Ces composants spécifiques sont propriétaires à Borland.
Si vous désirez avoir un fonctionnement correct, il est impératif de déployer en même temps que votre application, les composants utilisés relatifs aux bibliothèques de DataExpress et de dbSwing. Plus que cela, il est même nécessaire de déployer “le pilote” de MySQL pour que votre application se connecte à la base de données. Effectivement, c'est le client qui doit pouvoir se connecter au serveur, et la description de la connexion s'effectue bien du côté du client.
Il serait possible de rechercher les bibliothèques au bon endroit et de les déployer tel quel. Je trouve que se serait très compliqué, et de plus, la syntaxe pour lancer l'application serait longue et délicate. Le plus adapté, bien entendu, est de fabriquer une archive qui regroupera tout ce qui est nécessaire pour le bon fonctionnement de votre application. Nous aurons donc un seul fichier qui disposera des classes de l'application ainsi que de certaines classes issues des bibliothèques qui ne font pas parties du JRE.
Je vous propose de revenir sur le système qui dispose de JBuilder pour fabriquer l'archive. Nous en profiterons pour faire également un exécutable natif dont le système d'exploitation sera choisi en conséquence de l'ordinateur hôte. Ouvrez JBuilder sur le projet “Personnel.jpx”, et demander à fabriquer une nouvelle archive à l'aide de la rubrique “Fichier/Nouveau”.
Le type d'archive à sélectionner est le type Application. Ce type permet de renseigner le fichier “manifest” qui comportera entre autre le nom de la classe principale à lancer lorsque que nous exécuteront l'archive.
Ce qui est proposé à la deuxième étape, me convient parfaitement à priori. Le nom du fichier crée s'appelle “Personnel.jar”. Le processus d'archivage sera appelé Application. C'est lui qui récupère toutes les propriétés nécessaires relatives à la gestion de l'archivage. Vous remarquez qu'il est possible de compresser l'archive. Cela dépend du poids du fichier créé. La décompression prend du temps à l'exécution. Si c'est possible, il est préférable de s'en passer. Par contre, si le poids du fichier est prohibitif, il est absolument nécessaire de proposer la compression. Nous tentons l'experience sans compression, nous verons ensuite.
Dans la troisième étape, le choix proposé est presque systématiquement le bon, quelque soit le projet. En effet, c'est avec ce dernier choix que le système récupère les classes que vous avez mis en oeuvre dans votre projet. En fait le système regarde et récupère les classes compilées dans le répertoire prévu a cet effet <classes>. Pour les autres choix, il est nécessaire de spécifier chacune des classes que vous utilisez dans votre projet pour qu'elles soient effectivement intégrées.
La quatrième étape est la plus imporante, puisque c'est elle qui va définir les resources supplémentaires à utiliser. Vous voyez, en effet, la liste des bibliothèques annexes qui sont nécessaires pour le bon fonctionnement de votre projet. Si elles vous sont proposées, c'est qu'elles sont nécessaires. Tout dépend du degré d'inclusion. Doit-on mettre toute la bibliothèque ou qu'une partie ? Je vous invite à faire différentes expériences pour prendre juste ce qui est nécessaire sans trop grevé le poids du fichier produit.
Une fois que l'archive est réalisée, il est toujours possibles de changer ses caractéristiques sans pour cela tout recommencer. Il suffit de faire appel aux propriétés et ensuite de la reconstruire.
D'après l'expérience que j'ai mené, il est impératif de prendre toute la bibliothèque du “pilote MySQL”. dbSwing a également besoin de beaucoup de ressources sans pour cela tout inclure. Enfin, pour les autres, il suffit de prendre juste le minimum requis.
Les cinquième et sixième étapes n'appellent aucun commentaire particulier. La plupart du temps, il suffit de prendre les options proposées par défaut. En fait, elles sont dépendantes du choix réalisé à la première étape. Pour la septième étape, choisissez le type d'exécutable suivant le système d'exploitation que vous utilisez. Profitez-en pour personnalisé le nom de votre fichier.
Vous pouvez cliquer sur “Terminer”. Il ne reste plus qu'à exécuter la construction de l'archive. Ce que nous venons de réaliser est simplement de récupérer toutes les propriétés nécessaires au gestionnaire d'archive Application. Pour exécuter le processus d'archivage, cliquez avec le bouton droit de la souris sur Application, et sélectionnez la rublique “Construire”.
Du coup, deux fichiers sont créés :
Je vous invite maintenant à déployer ces deux fichiers sur votre ordinateur hôte pour contrôler le fonctionnement. Si vous regardez l'explorateur, vous remarquez que pour l'exécutable natif, il suffit de double-cliquez sur l'icône correspondante pour lancer le logiciel se qui est très agréable à l'utilisation. Par contre, ce type de fichier n'est pas portable sur les autres systèmes d'exploitation. A vous de choisir ce que vous désirer faire.
Par contre, si vous désirez utiliser l'archive quelque soit le système d'exploitation mis en oeuvre, vous devez taper la commande ci-dessous.
Profitez en pour regarder la taille des fichiers générés. La taille est très conséquente. Bon nombre de classes ont été introduites pour bien maîtriser le fonctionnement de votre logiciel.
Je vous avais dit qu'il était toujours possible de changer les propriétés de l'archive afin de réaliser un réglage au plus fin. Le but final est d'obtenir une archive dont la taille est la plus réduite possible, tout en concervant, bien entendu, un fonctionnement correct. Comme la taille des fichiers est énorme, je vous propose de régler les propriétés afin que le système effectue une compression lors du processus d'archivage.
Il suffit, encore une fois, de cliquez avec le bouton droit de la souris sur la gestion de l'archive Application, pour faire apparaître le menu contextuel. Sur le menu contextuel, sélectionnez la rubrique “Propriétés...”. La boîte de dialogue relative au propriétés d'archivage apparaît alors. Vous retrouvez toutes les rubriques sur lesquelles nous avons déjà effectués nos réglages. Il suffit de sélectionner l'onglet approprié. La compression est visible depuis le premier onglet, il suffit de cocher la case correspondante.
Ensuite, vous pouvez sortir de la boîte de dialogue “Propriétés”. Il faut, bien entendu, de nouveau, relancer la construction pour les derniers soient pris en compte.
Même, si la taille des fichiers est encore conséquente, nous avons obtenu en gros, une réduction de 50% par rapport aux originaux. Par ailleurs, si vous réeffectuez les test, vous ne remarquerez pas une grosse différence de vitesse par rapport aux fichiers non compressés. Je pense que c'est la meilleure alternative. En fait, réalisez plusieurs test dans différentes conditions pour vous forger une opinion.
Applet en relation avec une base de données
Je vais profiter de cette étude pour mettre en oeuvre une applet distribuée sur Intranet ou sur Internet qui
permettra de représenter la base de données “Entreprise”.
L'avantage d'utiliser une applet par rapport aux pages JSP ou autre PHP, ASP, est que nous nous trouvons toujours avec la même page Web. Il n'est pas nécessaire de demander la fabrication d'une nouvelle page Web à chaque requête. Il est même possible d'avoir une communication permanente afin d'éviter tout le protocole de demande de connexion HTTP qui prend pas mal de temps et de bande passante. Pour que ce principe puisse fonctionner, il est impératif de passer par un élément intermédiaire qu'est la servlet. et qui se trouve au sein du serveur Web.
Dans l'application que nous allons voir ensemble, je vais donc utiliser une applet qui sera en relation avec la base de données. La récupération des données se fera au travers de la servlet. Toutefois, les données ne seront transmises qu'au moment de l'établissement de la connexion. Dès que l'opération sera effectuée, la connexion sera interrompue afin d'éviter d'encombrer le réseau inutilement et de surcharger la base de données. L'applet ne servira qu'à consulter le contenu de la table “Personnel”.
Pour appréhender cette étude, il est absolument nécessaire de connaître la mise en oeuvre des applets, des servlets et également des pages JSP. Consultez les études concernées si vous vous ne vous sentez pas très à l'aise.
Pour en savoir plus sur les technologies Web.
Lorsque nous developpons une application relative aux base de données, souvenez-vous qu'il existe systématiquement deux domaines. D'abord, à l'aide des composants DataExpress, il s'agit de se mettre en connexion avec la base de données et d'établir la requête désirée, avec éventuellement tout un tas d'options supplémentaires. Ensuite, quand tout est prêt, dans la même application, on s'occupe de l'interface visuelle grâce aux composants dbSwing.
Avec l'applet, l'approche sera différente. En effet, jusqu'à présent, nous avions systématiquement, une seule application qui s'occupait de tout. Lorsque nous sommes sur Internet et donc que nous utilisons un navigateur, nous ne pouvons pas atteindre directement la base de données qui se trouve quelque part sur notre réseau local. Nous sommes protégés de l'extérieur par le pare-feu (heureusement). Nous sommes obligé de transiter par le serveur Web (port 80 et 8080 autorisés par le pare-feu), et c'est là que la servlet intervient. N'oubliez pas qu'une servlet est un programme (compilé) qui se trouve au sein du serveur Web et qui répond aux requêtes fournies par la page Web déjà téléchargée (très souvent, cette page web contient un formulaire que la servlet doit être à même de traiter). Dans notre cas, la servlet va servir d'intermédiaire, et c'est elle qui va mettre en relation l'applet avec la base de données.
Nous nous trouvons donc avec deux parties. D'une part, l'applet qui va représenter le contenu de la table désirée, et c'est donc elle qui utilise les composants dbSwing. D'autre part, la servlet qui va établir la connexion avec la base de données et demander de récupérer la bonne table par une requête SQL adéquate (avec un QueryDataSet), et ceci, grâce aux composants DataExpress.
Toutefois, nous avons un problème. Les composants dbSwing doivent être en relation directe avec un DataSet comme, par exemple, un QueryDataSet. Or, les composants dbSwing et DataExpress sont complètement séparés, les premiers se situant sur l'applet, les autres sur la servlet. Il faudra donc que nous ayions également un QueryDataSet sur notre applet, sinon, cela ne pourra pas fonctionner.
Nous avons également un autre problème. Il faut pouvoir faire transister toutes les données relatives à la table au travers du réseau. Heureusement, il existe un objet très performant qui a été conçu spécialement pour envoyer tout le contenu de la base de données relatif à une requête au travers du réseau. Ce seul objet peut contenir toute une table, si on le désire. Puisque c'est un objet qui passe sur le réseau, il s'agit bien entendu, d'un objet sérialisé. Cet objet s'appelle DataSetData. Il a été également spécialement conçu pour être en relation directe avec les composants DataSet. Ce DataSetData est en fait un représentant (un ambassadeur) d'un DataSet. Il contient juste ce qu'il faut, mais malgré tout, il comporte toutes les données requises, et c'est lui qui se déplace. C'est lui qui s'occupe de véhiculer l'information demandé par un QueryDataSet, pour les donner à un autre QueryDataSet.
La classe DataSetData vous permet de séparer l'état d'un DataSet (définie par ses propriétés) de ses données en n'extrayant que les données. Cette classe est sérialisable et peut s'utiliser pour placer les données dans un flux de sortie ou de les transmettre simplement sous forme de paramètre à une méthode exécutable à distance (RMI). La classe DataSetData permet également de recharger les données dans un autre DataSet. Utilisez la classe DataSetData pour développer des applications de base de données à 3 niveaux. Bien que cette classe sépare les données de leurs propriétés, quelques propriétés de colonne de type métadonnées sont stockées dans la classe.
| méthodes de DataSetData | Description |
|
DataSetData
extractDataSet(DataSet) |
Remplit le DataSetData avec des données et des données membre non-transitoires qui spécifient les informations métadonnée et les bits d'état pour chaque ligne. Les informations métadonnée incluent le décompte de colonne et de ligne, les noms de colonnes, les types de données, l'identificateur de ligne (rowId) et l'information spécifiant si chaque colonne est cachée. Les bits d'état sont utilisés en interne. |
| loadDataSet(DataSet) | Charge les données contenues dans DataSetData et les enregistre dans le dataSet destination en initialisant les propriétés de colonne comme hidden ou rowID. Toutes les colonnes qui n'existent pas déjà dans l'ensemble de données destination sont ajoutées. |
Pour mettre en oeuvre notre page Web, nous allons utiliser comme support d'étude la base de données “Entreprise” qui comporte une seule table “Personnel” dont je vous rappelle les caractéristiques.
Voici le contenu de la table au moment où nous l'utilisons.
Comme nous avons l'habitude de le faire maintenant, passons dans l'ordre, par l'élaboration de notre projet. Toutefois, il faut être très attentif, notre projet ne peut pas être placé n'importe où. En effet, n'oubliez pas que c'est une consultation d'une page Web depuis un navigateur. Il est donc nécessaire que l'ensemble des programmes soient positionnés au sein du serveur Web dans le répertoire adéquate. Votre projet s'appellera “BaseDonneesWeb”.
Comme nous utilisons pas mal de technologies Web différentes et pour permettre une parfaite corrélation entre les pages JSP, les applets, les servlets et également les archives, il est nécessaire d'avoir une architecture particulière et bien précise. Par exemple, il est obligatoire de disposer d'un répertoire dénommé “WEB-INF”. Mais surtout, la pièce maîtresse de toute technologie Web, est le descripteur de déploiement “web.xml” qui recence l'ensemble des éléments constituant l'application Web . Heureusement, JBuilder nous aide dans l'élaboration de ce dispositif. L'expert “Application Web” de la galerie d'objets que vous avez en cliquant sur l'icône “Nouveau” permet de réaliser toute cette infrastructure de façon automatique.
Vous pouvez choisir comme nom de l'application Web du même nom que votre projet, mais ceci n'a pas beaucoup d'importance. Par contre, placez-le dans le bon répertoire, c'est à dire dans le répertoire de votre projet. Par la suite, il vous sera possible de consulter les différents éléments qui constitue votre application web comme, par exemple, le descripteur de déploiement que j'ai évoqué plus haut.
Nous allons nous occuper maintenant de la servlet qui va nous permettre d'établir la connexion avec la base de données et de transférer un DataSetData vers l'applet. Vous appellerez cette servlet ServletBaseDonnees. Cliquez sur le bouton “Nouveau” pour faire appel à la galerie d'objets pour avoir l'expert de servlet.
A l'étape 2, précisez bien que nous devons implémenter la méthode doPost uniquement.
Pour les étapes 3 et 4, il suffit de cliquer sur le bouton “Suivant>”. Attention, pour la dernière étape, il ne faut pas créer de configuration d'exécution. Il suffit ensuite de cliquer sur “Terminer”.
Lorsque vous consultez le code source, vous voyez que nous obtenons une écriture automatique avec l'envoie d'une page Web minimale. Vous pouvez effacer tout ce qui concerne le HTML. Nous allons maintenant établir la connexion avec la base de données entreprise. En fait, il suffit de faire comme d'habitude, c'est à dire de se placer en mode conception, et de sélectionner le composant Database qui se trouve sur la palette DataExpress. Vous nommerez votre composant entreprise et vous règlerez la propriété connection pour que la connexion se face effectivement.
Comme d'habitude également, nous allons établir la requête pour récupérer la bonne table. Vous choisirez donc un composant QueryDataSet que vous appellerez requêtePersonnel auquel vous règlerez la propriété query afin de permettre la récupération de la table “Personnel”.
Il nous reste plus qu'à écrire le code nécessaire pour envoyer le résultat de la requête vers l'applet. Comme nous l'avons découvert en préambule, nous devons passer par un DataSetData qui va extraire le contenu de l'objet requêtePersonnel. Par ailleurs, comme il s'agit d'un objet sérialisé, nous le faisons passer par un flux de type ObjectOutputStream.
Normalement, nous devons envoyer uniquement une information et non pas en recevoir. Toutefois, il ne faut pas oublier que le principe des pages Web dynamiques et de répondre à une requête HTML issue du client, à savoir ici de l'applet. Je veux dire par là, que la servlet est opérationnelle que si l'applet en fait la demande. Côté applet, une demande consiste à envoyer une information quelconque, par exemple une chaîne de caractères, par la méthode HTTP POST. Cette information doit donc être récupérée avant d'envoyer nos données. Dans le code donc, message représente la requête HTML envoyée par l'applet. Cette information est également un objet sérialisé de type String.
Au tour de l'applet. Nous allons procéder en deux étapes. Nous allons tout d'abord nous occuper de toute la partie visuelle, en rajoutant les composants dbSwing nécessaires, et ceci, en mode conception. Ensuite nous écrirons le code pour établir le dialogue avec la servlet afin de récupérer les données envoyées par le DataSetData pour que le QueryDataSet soit complet afin qu'il puisse fonctionner correctement et donc être en phase avec les composants visuels dbSwing.
Sollicitez d'abord l'expert d'applet. Le nom de votre applet sera AppletBaseDonnees. Ne prenez pas la construction d'une page Web automatique puisque nous allons plutôt composer une page JSP. Ne créer pas également une configuration d'exécution automatique.
Placez-vous ensuite en mode conception. Réglez les dimensions de votre applet en 200 par 200 (Il faut basculer en mode “Caché” dans le “Niveau d'exposition de la propriété”). Avant de placer les composants visuels dbSwing, placez en premier, un composant QueryDataSet que vous appellerez, comme pour la servlet, requêtePersonnel. Toutefois, vous ne règlerez pas la propriété query puisque c'est le DataSetData qui fournira les informations nécessaires.
Placez ensuite sur la partie nord de l'applet le composant dbSwing JdbNavToolBar. Faites en sorte qu'il soit rattacher à requêtePersonnel grâce à la propriété dataSet. Nous allons utiliser que quelques boutons de la barre de navigation puisque nous ne faisons que de la consultation. Réglez donc les propriétés nécessaires en conséquence. Placez ensuite sur la partie sud de l'applet un JdbStatusLabel dont vous règlerez également la propriété dataSet comme pour la barre de navigation ainsi que la propriété border pour que ce composant soit surélevé.
Au niveau de la présentation de mes informations, je préfère avoir une visualisation personne par personne. Donc, plutôt que d'avoir la visualisation de la table entière directement, je vais utiliser des composants JdbTextField qui vont respectivement représentés le nom, le prénom et l'âge de la personne. Je vais les placer sur la partie centrale de mon applet. Nous avons donc besoin d'un JPanel auquel vous donnerez la couleur orange comme couleur de fond.
Vous placerez ensuite alternativement un JdbLabel et un JdbTextField. Le premier servira à désigner le nom du champ utilisé, le second à être effectivement en connexion avec la valeur du champ. Vous aurez donc besoin besoin de trois couples de composant. Pour que la présentation soit agréable, vous donnerez la même largeur de 60 pixels aux JdbLabel en utilisant la propriété preferredSize. De même vous règlerez la propriété columns des JdbTextField pour avoir le même nombre de colonnes, savoir 10. Pour ces derniers, il faut réglez également la propriété dataSet ainsi que la propriété columnName afin de récupérer les valeurs requises issues de requêtePersonnel, et par là même, indirectement, les valeurs issues de la base de données. Pour le dernier champ, celui qui correspond à l'âge, vous pouvez éventuellement règler la propriété horizontalAlignment à LEFT afin d'avoir la visualisation de la valeur à gauche (comme c'est une valeur numérique, elle s'affiche par défaut à droite).
Passons maintenant sur la partie codage. Nous devons récupérer les données issues de la table “Personnel”. Il faut le demander dès que l'applet s'initialise afin d'avoir le résultat tout de suite. Nous devons donc communiquer avec la servlet pour qu'elle nous envoie le DataSetData correspondant. N'oubliez pas que pour que la servlet s'active, il est absoluement nécessaire d'envoyer au moins une requête depuis l'applet. Vous pouvez envoyer ce que vous voulez. Pour être en parfaite correspondance avec la servlet nous devons également utiliser la méthode POST du protocole HTTP. Une fois que le DataSetData est récupéré, il suffit de l'associer à requêtePersonnel pour que cette dernière récupère toutes les informations nécessaires afin qu'elle puisse fonctionner correctement, et donc de propager les données aux différents composants dbSwing.
Nous sommes confrontés aux même problème que pour le déploiement d'une application. En effet, le client ne va disposer que de la “Machine Virtuelle Java” standard. Il n'aura pas, à sa disposition, les bibliothèques relatives aux composants DataExpress et dbSwing. Par contre, cette fois-ci, il n'est pas nécessaire de déployer le pilote de base de données puisque c'est la servlet qui s'en occupe, et elle, elle se trouve sur le serveur Web dans le réseau local.
Faites donc appel au constructeur d'archives. Le type d'archive cette fois-ci est “JAR de l'applet”. L'avantage, c'est que le fichier produit est le plus réduit possible. Systématiquement, l'archive est compressée pour minimiser le temps de téléchargement vers le client.
A l'étape 2, vous pouvez conserver les valeurs proposées par défaut. Pour l'étape 3, comme d'habitude, il faut systématiquement prendre l'option “Toujours inclre toutes les classes et resources”.
Pour les dépendances, il faut juste prendre ce qui est nécessaire, c'est à dire, une toute petite partie de la bibliothèque relative aux composants DataExpress et une partie plus conséquente des composants dbSwing. Pour la dernière étape, vous prenez les valeurs proposées par défaut, l'archive va donc proposé le manifest adéquat.
Il ne reste plus qu'à construire la page JSP qui va contenir notre applet et c'est elle qui va servir d'interface avec le client. C'est également, au sein de cette page que vous allez définir les différents éléments à prendre en compte comme, par exemple, l'archive à télécharger.
Faites appel à l'expert JSP. La page s'appellera “BaseDonnees.jsp”. Nous allons travailler sans fiche de soumission et sans bean d'exemple. Pour une fois, vous aller créer une configuration d'exécution puisque c'est cette page qui démarre tout le processus. Vous lui donnerez le nom que vous voulez.
Cette configuration d'exécution n'est pas absolument nécessaire, puisque nous allons effectuer le test en dehors de JBuilder en utilisant directement le navigateur. De toute façon, c'est le client qui fait l'appel.
Il suffit maintenant de compléter le code de la page JSP. Le plus important est la partie du plugin. Il faut faire appel à la bonne applet en tenant compte du paquetage utilisé, et surtout ne pas oublier de demander le téléchargement de l'archive qui contient tous les classes et les parties de bibliothèques utiles au bon fonctionnement.
Tout est prêt. Il ne vous reste plus qu'à tester notre projet. Tout d'abord, il faut, bien entendu, le construire. Ensuite démarrer votre serveur Tomcat. Enfin, lancer votre navigateur sur le poste client en précisant bien la bonne URL.