Java et le Web support de cours complet avec exemples d’application

Java et le Web support de cours complet avec exemples d’application

…

Applets

Il y a eu beaucoup d’agitation autour des applets lorsqu’est apparu le langage Java. La technologie Web était alors moins développée et les applets pouvaient passer comme la solution à une partie des problèmes qui se posaient aux développeurs à ce moment là. En fait, les applets sont devenues si populaires qu’aujourd’hui presque toutes les formations Java commencent par vous faire développer une applet. Il s’en suit que beaucoup de développeurs Java commettent l’erreur de trop compter sur les applets. Les applets ont certes leur place mais ne peuvent constituer la solution magique à vos problèmes de développement pour le web.

Parmi les inconvénients des applets, citons:

• Le déploiement et le test peuvent s’avérer difficiles.
• Vous êtes dépendant de la machine client sur laquelle se trouve le navigateur Java.
• Des navigateurs différents supportent des versions du JDK différentes, et généralement pas la dernière.
• L’applet peut être lente à démarrer la première fois, car elle a besoin d’être téléchargée par le client.

Certains de ces problèmes ont de réelles solutions que nous présentons en détail au Chapitre 4, “Utilisation des applets”. Lorsque vous envisagez d’utiliser une applet, cherchez si une autre technologie Java ne pourrait pas vous rendre le même service en mieux.

Il y a cependant quelques avantages à utiliser les applets. Parmi lesquels:

• Les applets peuvent présenter des interfaces utilisateur plus complexes que les servlets ou les JSP.
• Comme les applets sont téléchargées et exécutées côté client, le serveur web n’a pas besoin de prendre en charge Java. Cela peut être important si vous écrivez une application web pour un site où vous n’avez pas le contrôle du serveur web (par exemple, un site hébergé par un ISP extérieur).
• Les applets peuvent valider en local les données saisies par l’utilisateur, ce qui évite la validation côté serveur. Vous pourriez également accomplir cette tâche avec du JavaScript et un servlet ou une JSP.
• Après le téléchargement initial de l’applet, le nombre de requêtes du navigateur au serveur peut être réduit, un bon nombre de traitements pouvant s’accomplir sur la machine client.

Pour plus d’informations sur les applets et la résolution des problèmes qui peuvent se poser, voir Chapitre 4, “Utilisation des applets”.

Servlets

Les servlets sont des programmes Java qui s’intègrent à un serveur web pour fournir le traitement côté serveur des requêtes issues d’un navigateur client. Ils ont besoin d’un serveur web supportant la technologie JavaServer, par exemple le serveur Tomcat livré avec JBuilder. (Tomcat peut aussi être intégré à des serveurs web ne supportant pas la technologie JavaServer pour leur fournir la prise en charge de cette technologie. IIS est un exemple d’un tel serveur.) Les servlets Java peuvent remplacer des programmes CGI (Common Gateway Interface), ou être utilisés dans les situations où auparavant vous auriez utilisé CGI. Il y a cependant quelques avantages à utiliser les servlets plutôt que CGI :

• Réduction de la charge mémoire
• Indépendance par rapport aux plates-formes
• Indépendance par rapport aux protocoles

Vous utilisez un programme client écrit dans n’importe quel langage pour envoyer vos demandes au servlet. Le client peut être une simple page HTML. Vous pourriez utiliser une applet comme client, ou un programme écrit dans un autre langage que Java. Côté serveur, le servlet traite la requête et génère une sortie dynamique qui est retournée au client. Généralement, les servlets n’ont pas d’interface utilisateur, mais vous pouvez en fournir une côté client. Les servlets présentent quelques avantages par rapport aux applets :

• Vous n’avez pas besoin de savoir sur quel JDK le navigateur client va s’exécuter. Java n’a même pas besoin d’être activé sur le navigateur client. Tout le code Java est exécuté côté serveur. Cela apporte le maximum de contrôle à l’administrateur du serveur.
• Après le démarrage du servlet, les requêtes issues des navigateurs client invoquent tout simplement la méthode service() du servlet qui s’exécute. Cela signifie que ces clients ne ressentent pas d’effet sur leurs performances lorsqu’ils attendent que le servlet se charge. Comparez cela au chargement d’une applet.

Le déploiement d’un servlet sur le serveur web peut s’avérer difficile, mais certainement pas impossible. JBuilder propose des outils qui facilitent le déploiement. Il sont présentés au Chapitre 16, “Déploiement de votre application web”.

Pour plus d’informations sur l’exécution les servlets Java, voir Chapitre 5, “Utilisation des servlets”, et Chapitre 6, “Création de servlets dans JBuilder”.

Pages JavaServer (JSP)

Les pages JavaServer sont une extension de la technologie des servlets. C’est essentiellement un moyen simplifié d’écrire des servlets, avec une attention plus forte accordée à la présentation de votre application.

La principale différence entre servlets et JSP est la suivante : avec les servlets, la logique de l’application est dans un fichier Java et totalement séparée du HTML dans la couche présentation. Avec les JSP, Java et HTML sont combinés dans un même fichier dont l’extension est .jsp.

Lorsque le serveur web traite le fichier JSP, un servlet est réellement généré mais, en tant que développeur, vous ne verrez pas ce servlet généré. En fait, lorsque vous compilez et exécutez votre JSP dans l’EDI de JBuilder, vous risquez de voir apparaître des exceptions ou des erreurs qui se produisent en fait dans le servlet généré. Il peut s’avérer difficile de distinguer quelle partie de votre JSP pose problème lorsque le message d’erreur fait référence à une ligne appartenant au code généré.

Les JSP présentent et des avantages et des inconvénients par rapport aux servlets. Parmi les avantages des JSP, citons:

• Moins de code à écrire.
• Facilité d’intégration des Java Beans existants.
• Déploiement plus facile. Prise en charge automatique d’un nombre supérieur de problèmes de déploiement, car les JSP établissent la correspondance avec un serveur web comme le font les fichiers HTML.
• Vous n’avez pas à imbriquer le code HTML que vous prévoyez de faire générer par le servlet dans votre code Java. A la place, des blocs individuels de code Java sont intégrés dans le HTML. Si vous planifiez bien votre travail, ces blocs de code Java peuvent être clairement séparés du code HTML dans le fichier, ce qui rend la JSP plus lisible.

Parmi les inconvénients des JSP, citons:

• La non visibilité du code du servlet généré peut engendrer une certaine confusion, comme indiqué précédemment.
• Le code HTML et le code Java n’étant pas dans des fichiers séparés, un développeur Java et un concepteur web travaillant ensemble sur une application doivent faire très attention à ne pas écraser mutuellement leurs modifications.
• Le code HTML et Java combiné en un seul fichier peut être difficile à lire, surtout si vos pratiques de codage sont peu soigneuses ou peu élégantes.

Les JSP ressemblent beaucoup aux ASP (Active Server Pages) de la plate-forme Microsoft. La principale différence entre JSP et ASP est la suivante : les objets manipulés par les JSP sont des JavaBeans et donc

indépendants des plates-formes. Les objets manipulés par les ASP sont des objets COM, ce qui lie complètement les ASP à la plate-forme Microsoft.

Pour plus d’informations sur la technologie des JSP, voir Chapitre 9, “Développement des pages JavaServer”.

InternetBeans Express

La technologie InternetBeans Express s’intègre aux servlets et aux JSP pour améliorer vos applications et simplifier les tâches de développement des servlets et des JSP. InternetBeans Express est un ensemble de composants associé à une bibliothèque de balises JSP, permettant de générer la couche présentation d’une application web, et d’y répondre. InternetBeans Express prend des pages modèles statiques, leur insère un contenu dynamique issu du modèle de données réel, et les présente au client ; ensuite, il écrit dans le modèle de données les modifications postées par le client. Cela facilite la création des servlets et des JSP orientés données.

InternetBeans Express supporte les ensembles de données et les modules de données DataExpress. InternetBeans Express peut aussi être utilisé avec des modèles de données et des EJB génériques.

Pour plus d’informations sur InternetBeans Express, voir Chapitre 11, “Utilisation d’InternetBeans Express”.

Choix des technologies à utiliser dans votre application web

Vous avez maintenant un aperçu des diverses technologies web, il vous reste à choisir celle que vous allez utiliser dans votre application web. Les conseils suivants vous aideront à prendre cette décision:

• Votre interface utilisateur est-elle particulièrement complexe ? Si votre interface utilisateur doit contenir d’autres composants que ceux destinés à la saisie de données (comme des champs texte, des boutons radio, des boîtes à options, des boîtes liste, des boutons submit, etc.) et aux images, vous souhaiterez sans doute utiliser une applet.
• Si vous voulez effectuer beaucoup de traitements côté serveur, vous devrez utiliser un servlet ou une JSP.
• Si vous voulez éviter à vos utilisateurs de charger beaucoup de code et si vous souhaitez accélérer le démarrage de votre application, choisissez un servlet ou une JSP.
• Si vous voulez contrôler le JDK utilisé par votre application (sans téléchargement), ou si vous savez que vos utilisateurs ont des navigateurs non Java, utilisez un servlet ou une JSP.
• Si vous recherchez un moyen de remplacer CGI, avec une charge mémoire moindre, utilisez un servlet ou une JSP.
• Si vous avez besoin de quelque chose se rapprochant d’une ASP, mais privilégiez l’indépendance par rapport aux plates-formes, vous choisirez une JSP.
• Si votre interface utilisateur est complexe et si vous voulez bénéficier de certaines caractéristiques des servlets ou des JSP, envisagez de combiner une applet et un servlet. Vous pouvez avoir une configuration faisant dialoguer une applet côté navigateur (client) et un servlet côté serveur.
• Si vous voulez utiliser un servlet ou une JSP et si vous voulez que ce dispositif contienne des données, vous devrez employer InternetBeans Express.
• Les servlets et les JSP se ressemblent suffisamment pour que votre choix se fonde sur vos préférences personnelles.
• En fait, beaucoup d’applications web utiliseront une combinaison de deux de ces technologies, ou même plus.

Présentation générale du processus de développement des applications web

Quelles que soient les technologies web choisies, les étapes fondamentales du développement de votre application web et de son fonctionnement sur un serveur web seront les mêmes. Voici ces étapes:

...

Applications web et applications distribuées

Vous pouvez envisager d’utiliser pour votre programme une application distribuée plutôt qu’une application web. Les deux gèrent la programmation client/serveur. Cependant, les deux technologies sont différentes.

En général, les applications distribuées gèrent et lisent les données des systèmes existants. Le système standard peut exister sur de nombreux ordinateurs travaillant sous des systèmes d’exploitation différents. Une application distribuée utilise un serveur d’applications, comme le Borland Application Server, pour la gestion de l’application. Les applications distribuées n’ont pas besoin d’être fondées sur Java ; en fait, une application distribuée peut contenir beaucoup de programmes différents, indépendamment du langage dans lequel ils sont écrits ou de l’emplacement où ils résident.

Les applications distribuées sont habituellement cantonnées à un réseau à l’intérieur d’une société. Des parties de votre application distribuée peuvent être rendues accessibles à des clients sur Internet, mais ensuite vous devrez combiner application distribuée et application web.

Les technologies utilisées dans une application distribuée sont notamment l’architecture CORBA (Common Object Request Broker Architecture) et RMI (Remote Method Invocation) :

• Le principal avantage de CORBA est que les clients et les serveurs peuvent être écrits dans n’importe quel langage de programmation. Cette possibilité existe parce que les objets sont définis avec le langage IDL (Interface Definition Language) et que la communication entre objets, clients et serveurs est gérée via les ORB (Object Request Brokers).
• RMI ou Remote Method Invocation permet de créer des applications Java-à-Java distribuées, dans lesquelles les méthodes des objets Java distants peuvent être appelées depuis des machines virtuelles Java et sur différents hôtes.

Les applications web peuvent être rendues accessibles à quiconque dispose d’un accès à Internet, ou placées derrière un “pare-feu” et uniquement utilisés à l’intérieur de l’intranet de votre société.

Les applications web nécessitent l’utilisation d’un navigateur côté client et d’un serveur web côté serveur. Par exemple des applets sont téléchargées sur des plates-formes client multiples où elles sont exécutées par la machine virtuelle Java (Java Virtual Machine, JVM) fournie par le navigateur qui s’exécute sur l’ordinateur client. Les servlets et les JSP s’exécutent à l’intérieur d’un serveur web Java supportant les spécifications JSP/Servlet.

...

La WebApp

Une WebApp décrit la structure d’une application web. C’est essentiellement une arborescence de répertoires renfermant le contenu web utilisé dans votre application. Elle correspond à un ServletContext. Un fichier de descripteur de déploiement, appelé web.xml, est toujours associé à chaque WebApp. Ce descripteur de déploiement contient les informations que vous devez fournir au serveur web lorsque vous déployez votre application.

L’utilisation d’une WebApp est utile si votre projet contient des servlets ou des JSP. Vous n’utiliserez probablement pas de WebApp si votre application web ne contient qu’une applet, mais vous souhaiterez en utiliser une dans une application web contenant une applet et un servlet ou une JSP. Ainsi, vous pourrez stocker la WebApp entière dans un fichier WAR unique. Vous pourriez avoir plusieurs WebApps sur un site web. JBuilder prend en compte cette notion en vous permettant d’avoir plusieurs WebApps dans un même projet.

Il est important de réfléchir à la structure de vos applications web pendant les phases de planning. Combien de WebApps y a-t-il ? Quels sont leurs noms ? Stockerez-vous ces WebApps dans des fichiers WAR ?

En prévoyant la structure depuis le début, vous faciliterez le déploiement ultérieur. JBuilder ne se sert pas de la notion d’une WebApp par défaut qui serait “enracinée” dans le répertoire <répertoireprojet>/racinedéfaut. Si vous ne spécifiez pas de WebApps pour vos applications web, elles utilisent la WebApp par défaut.

Pour plus d’informations sur la façon dont JBuilder fonctionne avec les WebApps, voir “L’expert application web”, page 3-3, et “La WebApp et ses propriétés”, page 3-4.

Fichiers archive web (WAR)

Un fichier WAR est le fichier servant d’archive à une application web. Il ressemble à un fichier JAR. En enregistrant toute votre application et les ressources qu’elle nécessite dans un fichier WAR, vous facilitez son déploiement. Vous copiez simplement le fichier WAR sur votre serveur web, au lieu de vérifier qu’un grand nombre de petits fichiers ont été copiés aux bons emplacements. JBuilder peut générer automatiquement un fichier WAR lorsque vous construisez votre projet.

Pour plus d’informations sur la façon dont JBuilder fonctionne avec les fichiers WAR, voir “Le fichier WAR”, page 3-11.

Outils pour travailler avec les WebApps et les fichiers WAR

Voici la liste des outils fournis par JBuilder pour travailler avec les WebApps et les fichiers WAR :

Tableau 3.1 Outils de JBuilder destinés aux WebApps et aux fichiers WAR

Outil Description

Expert C’est un expert servant à créer une WebApp. Il vous permet application web de spécifier le nom de la WebApp, le répertoire racine pour les documents de l’application web, et si vous voulez ou non générer un fichier WAR.

Nœud WebApp Un nœud dans le volet projet de l’EDI de JBuilder, représentant la WebApp. Ce nœud possède une boîte de dialogue de propriétés permettant de configurer la WebApp. Contenus dans le nœud WebApp, vous trouverez des nœuds pour les descripteurs de déploiement, le répertoire racine et un fichier WAR facultatif.

...

L’expert application web

L’expert application web crée une nouvelle WebApp. Pour afficher l’expert application web, ouvrez la galerie d’objets (Fichier|Nouveau), cliquez sur l’onglet Web, sélectionnez Application web et cliquez sur OK.

L’expert est très simple. Il est constitué d’une page, avec deux champs texte et une case à cocher. Dans le premier champ texte, dont le libellé est Nom, entrez un nom pour votre WebApp. Dans le seconde champ texte, dont le libellé est Répertoire, entrez l’emplacement qui sera la racine du document de votre WebApp. Y saisir un nom de répertoire crée un sous-répertoire dans le répertoire du projet. Vous pouvez également cliquer sur le bouton Points de suspension pour naviguer jusqu’à un répertoire existant où vous pouvez créer un nouveau répertoire ou le choisir. Il n’est pas conseillé de choisir la racine du projet ni le répertoire src.

En cochant la case Générer WAR, vous indiquez que vous voulez générer un fichier WAR lors de la construction du projet. Si la case à cocher est sélectionnée, le fichier WAR aura le même nom que la WebApp et sera placé dans le répertoire contenant le répertoire racine du document. Si vous ne cochez pas Générer WAR, ne vous inquiétez pas. Vous pourrez toujours changer d’avis. Cette case à cocher correspond à un valeur des Propriétés de la WebApp.

Vous pouvez utiliser également l’expert application web pour importer une application web existante que vous pouvez avoir construite auparavant. Donnez un nom à la WebApp, et pointez sur l’emplacement du répertoire contentant votre application web existante. Si l’application web est valide, elle peut être exécutée dans l’EDI de JBuilder immédiatement.

La WebApp et ses propriétés

Un serveur web Java localise une application web par son ServletContext, qui est associé à la WebApp. Une WebApp est représentée dans l’EDI de JBuilder sous la forme d’un nœud. Il se trouve dans l’arborescence du volet projet et porte le nom de la WebApp.

Le nœud WebApp a deux ou trois nœuds enfant, le Répertoire racine de l’application, un nœud Descripteurs de déploiement représentant le répertoire WEB-INF de la WebApp, et un nœud Fichier WAR facultatif.

Vous devez placer les fichiers du contenu web (comme les fichiers HTML, SHTML et JSP) dans le répertoire racine de la WebApp ou dans un de ses sous-répertoires. Les fichiers de contenu web sont des fichiers directement accessibles par le navigateur client. Les ressources Java utilisées par la WebApp (comme les servlets ou les JavaBeans) doivent avoir leur fichiers source dans le répertoire source du projet. Ces fichiers ne sont pas directement accessibles par le navigateur client, mais ils sont invoqués par autre chose, par exemple un fichier JSP. Les experts servlet, JSP et Lanceur de démarrage Web de JBuilder facilitent la création des applications web respectant ces règles. Soyez bien sûr de spécifier une WebApp nommée existante lorsque vous utilisez ces experts.

Répertoire racine

Le répertoire racine définit l’emplacement de base de l’application web. Chaque partie de l’application web sera placée relativement à ce répertoire racine. Tous les fichiers de contenu web, comme les fichiers HTML, SHTML, JSP ou d’images, seront placés dans ce répertoire. Les fichiers de contenu web sont des fichiers directement accessibles par le navigateur client.

Les fichiers du répertoire racine de la WebApp (et tous les sous-répertoires de ce répertoire) sont automatiquement affichés dans le nœud Répertoire racine du volet projet. Seuls les fichiers des types que vous spécifiez dans la page WebApp de la boîte de dialogue Propriétés de la WebApp sont affichés. Les types de fichiers par défaut sont ceux que vous utilisez habituellement dans une application web. Cela vous permet de travailler avec des fichiers HTML ou des fichiers d’images sans renoncer à vos outils favoris. Enregistrez ces fichiers dans le répertoire racine de la WebApp ou dans un de ses sous-répertoires. Cliquer ensuite simplement sur le bouton Rafraîchir du volet projet permet de voir l’ensemble de fichiers en cours dans JBuilder.

Descripteurs de déploiement

Chaque WebApp doit avoir un répertoire WEB-INF. Ce répertoire contient les informations nécessaires au serveur web pour le déploiement de l’application. Ces informations sont mises en forme dans les fichiers descripteurs de déploiement. Ces fichiers utilisent l’extension .xnl. Ils sont affichés dans le nœud Descripteurs de déploiement du volet projet. Le répertoire WEB-INF est en fait un sous-répertoire du répertoire racine de votre WebApp. Il ne figure pas dans le volet projet sous le nœud Répertoire racine car c’est un répertoire protégé qui ne peut être servi par le serveur web.

Le nœud Descripteurs de déploiement de la WebApp contient toujours un fichier descripteur de déploiement appelé web.xnl. Ce fichier est nécessaire à tous les serveurs web Java et il est créé par JBuilder lorsque vous créez la WebApp. Votre serveur web peut exiger des descripteurs de déploiement supplémentaires qui lui sont spécifiques. Ils peuvent être modifiés dans JBuilder et seront créés s’ils figurent dans la liste des descripteurs requis par le plugin du serveur web en cours de configuration. Recherchez dans la documentation de votre serveur web les descripteurs de déploiement qui lui sont nécessaires.

JBuilder fournit un éditeur de descripteur de déploiement pour modifier le fichier web.xnl. Dans JBuilder, vous pouvez également modifier des descripteurs de déploiement spécifiques au serveur. Dans le fichier web.xnl, certaines affectations, ou mappages, doivent être faites pour que la WebApp fonctionne comme prévu dans l’EDI de JBuilder. Ces mappages seront écrits pour vous si vous utilisez les experts de JBuilder pour créer les différentes parties de votre application web. D’autres mappages peuvent être nécessaires au moment du déploiement de votre application. Pour plus d’informations sur les descripteurs de déploiement et l’éditeur DD WebApp, voir la section “Descripteurs de déploiement”, page 16-4.

Propriétés de la WebApp

Le nœud WebApp du volet projet possède diverses propriétés que vous pouvez modifier. Pour modifier les propriétés du nœud WebApp, cliquez avec le bouton droit sur le nœud et sélectionnez Propriétés dans le menu. La boîte de dialogue Propriétés de la WebApp a quatre onglets:

• WebApp
• Classes
• Dépendances
• Manifest

L’onglet WebApp

L’onglet WebApp de la boîte de dialogue Propriétés de la WebApp indique le nom de la WebApp, l’emplacement du répertoire de la WebApp, l’emplacement du répertoire du fichier WAR. Il y a deux cases à cocher indiquant de générer (ou de mettre à jour) ou non le fichier WAR lorsqu’est construit le projet, et de compresser ou non l’archive. La case à cocher de création de l’archive correspond à la case à cocher “Générer WAR” de l’expert application web. Il peut être commode de désactiver la génération du fichier WAR pendant le développement et de l’activer au moment de la dernière construction du projet, juste avant le déploiement.

Cet onglet contient également la liste des types de fichiers à inclure, que ce soit pour la navigation dans les fichiers ou la génération du fichier WAR. Seuls les types de fichiers qui sont sélectionnés seront inclus, conformément aux extensions qu’ils utilisent. Les extensions associées à chaque type de fichiers peuvent être visualisées et modifiées dans la boîte de dialogue Options de l’EDI, accessible depuis le menu Outils.