Côté client et serveur

Une application Web (fig. 3.5) est utilisée par un client, généralement par l’intermédiaire d’un navigateur internet. Les requêtes formulées par son navigateur sont prises en charge par l’application qui va envoyer des pages avec du contenu dynamique en réponse. Pour générer les pages, l’application va chercher de l’information sur des services tiers. L’identification des clients se fait généralement par l’utilisation de cookies produits par l’application. Un client identifié les renvoie attachés dans les en-têtes de ses requêtes HTTP.

3.2.1.1 Point d’entrée d’une application

De manière comparable au langage C, le point d’entrée d’un programme Java est la mé- thode statique main() définie par la classe passée en argument à l’interpréteur Java et respectant la signature suivante :

p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s )

Une application Java peut être exécutée seule, en ligne de commande, ou packagée dans fi- chier d’archivage Java : un JAR exécutable. Elle peut avoir certaines dépendances avec des

FIGURE3.5 – Schéma d’architecture d’une application Web

bibliothèques externes en plus de celles proposées dans le JRE. Une application Java est donc composée de classes (fichier de bytecode .class) et parfois de fichiers de ressources (images, sons, textes) le plus souvent packagées en archive Java (JAR), ainsi que d’éventuelles dépen- dances elles aussi packagées en JAR. Un fichier de description de l’application peut être ajouté pour rendre cette archive exécutable (le manifest).

3.2.1.2 Les bibliothèques

Java possède aussi son système de bibliothèques. C’est une collection de classes compilées packagées en JAR.

3.2.1.3 Les Beans

La spécification JavaBeans de Sun Microsystems définit les JavaBeans comme des « com- posants logiciels réutilisables manipulables visuellement dans un outil de conception ». Un composant JavaBean est une simple classe Java qui respecte certaines conventions sur le nom- mage des méthodes, la construction et le comportement. Le respect de ces conventions rend possible l’utilisation, la réutilisation, le remplacement et la connexion de JavaBeans par des outils de développement. Les conventions à respecter sont les suivantes :

– La classe doit être « Serializable » pour pouvoir sauvegarder et restaurer l’état de ses instances,

– La classe doit posséder un constructeur sans argument,

– Les propriétés de la classe (variables d’instances) doivent être accessibles via des mé- thodes suivant elles aussi des conventions de nommage (getters et setters),

3.2.2 Côté client

3.2.2.1 Les Applets

Les applets sont des applications Web Java fournies sous forme de bytecode. Elles sont exécutées sur la machine cliente à travers un navigateur Web. Ainsi l’utilisateur sélectionne une page HTML qui déclenche le téléchargement de l’applet Java par le navigateur Web du client. Une fois l’application sous forme de bytecode téléchargée, une extension du navigateur Web (un runtime plugin) chez le client exécute l’applet au sein du navigateur. Le principal avantage de ces applets Java est de fournir des fonctionnalités non présentes en HTML et dans les langages de scripts comme le traitement avancé d’images, la 3D, des effets visuels particu- liers,. . .D’autre part, l’exécution d’une applet Java jouit d’une certaine sécurité car par défaut elle ne peut accéder aux ressources de la machine sur laquelle elle s’exécute. Les principales caractéristiques d’une applet sont décrites en annexe D.1.

FIGURE3.6 – Positionnement d’une Applet dans une architecture JEE

3.2.2.2 Les Midlets

Les applications créées avec l’API MIDP (J2ME) sont appelées des midlets. Le cycle de vie d’une Midlet et le principe sont semblables à ceux d’une applet. Les midlets sont spécialement conçues pour des environnements autres que les ordinateurs classiques (téléphones portables, pagers,. . .)

3.2.3 Côté serveur

3.2.3.1 Les Servlets

Une Servlet est une application Java qui génére dynamiquement des données au sein d’un serveur HTTP. Ces données sont le plus généralement présentées au format HTML, mais elles peuvent également l’être au format XML ou tout autre format destiné aux navigateurs Web. Cela permet de développer des applications Web interactives, c’est-à-dire dont le contenu est dynamique, par opposition à des pages Web statiques qui affichent continuellement la même information.

Ce programme Java s’exécute dynamiquement sur le serveur Web et permet l’extension des fonctions de ce dernier, typiquement : accès à des bases de données, transactions d’e- commerce, etc. Elles sont donc au serveur Web ce que les applets sont au navigateur pour le client. Une servlet est chargée automatiquement lors du démarrage du serveur Web ou lors de la première requête du client. Elle s’exécute indépendamment du serveur Web grâce à la plateforme Java par l’intermédiaire d’un moteur de servlet (Tomcat, WebSphere, WebLogic, JBoss, . . .). Une fois chargées, les servlets restent actives dans l’attente des requêtes client.

Les servlets gérent des requêtes HTTP et fournissent au client une réponse HTTP dyna- mique.

FIGURE3.7 – Positionnement d’une Servlet dans une architecture JEE.

3.2.3.2 Les Server Side Includes (SSI)

Lorsqu’une servlet n’a pour fonction que la génération partielle d’une page HTML, elle est appelée SSI. Elle est invoquée en la spécifiant dans le code HTML de la page et fonctionne exactement comme une servlet classique. Les Servlets invoquées via SSI sont intéressantes lorsque le contenu statique est plus important que le contenu dynamique.

3.2.3.3 Les Enterprise Java Beans (EJB)

Conçus pour être intégrés dans une architecture trois tiers ou plus, les Enterprise Java Beans sont des beans composants d’une application J2EE distribuée côté serveur. De la version 1.0 à la version 2.1, un EJB était accompagné d’un ou plusieurs fichiers de déploiement écrits en XML qui permettaient au serveur applicatif de déployer correctement l’objet au sein d’un conteneur. Depuis la version 3.0, le fichier de code source de l’EJB se suffit à lui-même car le modèle EJB utilise le principe d’annotation Java (méta-données) pour spécifier toute la configuration et les propriétés transactionnelles de l’objet.

Un exemple de configuration est présenté en annexe D.5

3.2.3.4 Les Java Server Pages (JSP)

Les JSP ont été créées principalement pour permettre à des développeurs ne maitrisant pas Java d’inclure des éléments dynamiques dans leurs pages Web en simplifiant la syntaxe nécessaire. Une page utilisant les Java Server Pages est exécutée au moment de la requête par un moteur de JSP, fonctionnant généralement avec un serveur Web ou un serveur applicatif. Le modèle des JSP étant dérivé de celui des servlets (en effet les JSP sont un moyen d’écrire des servlets), celle-ci est donc une classe Java dérivant de la classe HttpServlet, et utilisant les méthodes doGet() et doPost() permettant de renvoyer une réponse par le protocole http. Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java. Un compilateur de JSP génère un servlet Java en code source Java qui peut à son tour être compilé par le compilateur Java. Tout ceci s’effectue de manière transparente par le moteur de servlet. Depuis la version 2.0 des spécifications, la syntaxe des JSP est purement XML. Une JSP peut être écrite en servlet et inversement. Pour la création d’une page complète, elles peuvent s’appeler entre elles pour fournir des zones de pages, le plus souvent par l’utilisation de frames. Dans le patron de conception Modèle-Vue-Contrôleur, les JSP sont plutôt dédiés à la ’vue’ (présentation).

3.2.3.5 Les Portlets (JSR 168)

Le fonctionnement d’un portlet est similaire à une servlet, mais contrairement à la servlet il est fait pour ne générer qu’une partie d’une page html. Il est invoqué par un portail uni- quement (Jahia, Liferay, Joomla, . . .). Il doit hériter de Javax.portlet.Portlet. Les portlets d’une application sont listés dans le fichier portlet.xml ou bien directement dans le Web.xml.(voir §Packaging des application Java).

3.2.3.6 Les Aglets

Un aglet est un agent mobile Java. Il hérite de la clase com.ibm.aglet.Aglet. Il possède la faculté de transiter de machine en machine pour y exécuter du code. Son nom est un mot- valise de « Agile applet ». Pour fonctionner il requiert un serveur d’aglet. Il est autonome car il s’exécute sans intervention externe, et réactif car il peut répondre à des évènements de son environnement, parfois par l’intermédiaire d’un proxy.

Le fonctionnement d’un Aglet est proche d’une applet avec la mobilité en plus. D’autres informations sont présentées en annexe D.4