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:

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

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:

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

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 ?

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.

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.

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.

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.