Struts (Jean-Noël Albert)

Struts et la construction des sites Web dynamiques

• qu’est-ce qu’un site Web dynamique ?
• pourquoi a-t-on besoin d’un produit spécial pour cela ?
• qu’offre Struts ?

Struts est un environnement logiciel (en anglais, on utilise volontiers le terme framework) destiné la construction de sites Web dynamiques. Struts se présente comme un ensemble de bibliothèques sur lesquelles l’application Web sera construite. Mais la démarche va plus loin et c'est bien une méthode de conception de site qui est proposée, et qui, même sans Struts, gagne à être adoptée. L’idée forte est de séparer la présentation et les traitements. Pour ce faire, Struts propose :

• de séparer le code HTML (présentation) du code de traitement (Java) ;
• de séparer la validation des requêtes de leur traitement proprement dit ;
• de séparer la navigation entre les pages de la localisation physique des fichiers sur disque.

Qu’est-ce qu’un site Web dynamique ?

Un site Web dynamique est un site où les pages présentées ne peuvent pas être écrites à l’avance, une fois pour toute, sous la forme de simples fichiers HTML, car les éléments à afficher vont dépendre d’une part des demandes des utilisateurs, et d’autre part de l’évolution du « système d’information » (qu’il s’agisse d’une base de données, d’un système de « contrôle commande » ou de tout autre système évolutif).

Il faut donc construire « au vol » la réponse présentée à l’utilisateur.

Attention : il ne faut pas confondre un site Web dynamique et un site Web interactif (Wiki).

Pourquoi est-ce si compliqué ?

La principale difficulté réside dans la conception même du « Web ». A l’origine, c’est un « système » pour afficher des pages situées sur différents ordinateurs. Il y a donc très peu d’interactivité. L’utilisateur demande une page, typiquement en « cliquant » sur un « lien », le navigateur émet au serveur une requête indiquant l’adresse de la page (URL), le serveur envoie le fichier, le navigateur l’affiche.

Une échappatoire a cependant été prévue sous la forme de CGI (Common Gateway Interface). Pour certaines adresses bien identifiées par l’administrateur du site, le serveur active un programme et lui transmet les éléments de la requête. Le programme écrit « au vol » le code HTML de la page demandée et la renvoie au serveur. Le serveur la transmet au navigateur.

Les principaux CGI ont longtemps (et beaucoup le sont encore) été écrits dans des langages de « scripting », le plus connu étant Perl. Les difficultés inhérentes à cette approche sont nombreuses :

• le code des scripts est difficile à lire car il mêle de la logique de traitement (des if .. then… else… ), la génération des instructions HTML

  (print "<table><tr><td>…</td>\n")
  

  et l’affichage des éléments à présenter ;
• il est très difficile à faire évoluer, car il faut un développeur compétent dans le langage de programmation du script, en infographie (ou du moins dans le langage HTML), et bien sur dans le problème à résoudre ;
• la simple réorganisation du site est délicate, car la navigation entre pages est le plus souvent noyée dans le code du script, et il faut relire tous les scripts et les corriger pour le moindre changement dans les noms des fichiers ou des répertoires ;
• les performances sont médiocres, car les programmes sont le plus souvent exécutés sous la forme de processus extérieurs, longs à créer, même sous UNIX ;
• il est difficile de maintenir un contexte entre deux requêtes puisque chaque CGI est activé comme un nouveau processus, qui n’a pas de « mémoire » explicite du passé – l’accès à une base de données, par exemple, est pénalisant car la connexion doit être ouverte à chaque requête, avec des temps d’attente importants liés à la vérification par la base des droits de l’utilisateur, l’établissement de son contexte de travail, …

Les servlets

Une servlet est une classe Java exécutée par un serveur HTTP pour traiter une requête Web.

Il n’y a donc pas beaucoup de différences entre une servlet et un CGI, si ce n’est qu’une servlet s’exécute au sein du serveur, sous la forme d’un « thread » (une entité interne à une application capable d’exécuter du code d’une manière autonome).

En fait, une servel est un CGI. Elle est activée par le même mécanisme d'association d'une URL donnée et de la servlet.

Mais une servlet présente toute de même pas mal d’avantages sur un CGI / script :

• la création d’un thread est beaucoup plus rapide que la création d’un processus, et consomme bien moins de ressources ;
• la servlet et son thread peuvent restés en mémoire dans le serveur, ce qui accélère encore les temps de réponse et améliore la montée en charge;
• un contexte peut être maintenu d’une requête à une autre, par exemple pour conserver les résultats d’un précédent traitement et les afficher rapidement ;
  • une utilisation particulièrement de cette persistance de l’information durant une session est l’accès aux bases de données qui peut être fait lors d’un premier accès et conservé par la suite ;
  • des serveurs comme Tomcat offre même des mécanismes de « pool de connexions », ouvertes au démarrage du serveur et immédiatement utilisables.

En outre –

• le langage Java est un langage fortement typé qui évite bien des erreurs si fréquentes avec les langages de scripting ;
• Java est rapide à développer grâce à son mécanisme de compilation incrémentale et ne nécessite pas d’éditions de lien (ce qui rend le cycle de développement beaucoup plus court qu’en C++) ;
• Java est directement portable au niveau du code compilé sur toutes les plates-formes majeures (UNIX/Linux, Windows, Mac) ;
• Java gère l’utilisation de la mémoire de l’application, ce qui interdit les fuites de mémoire, principale source de l’écroulement des performances des programmes C++ (mal écrits) ;
• Java interdit le débordement des listes et des tableaux, ce qui protège le serveur et évite que son propre espace mémoire ne soit pollué par une application mal écrite ;
• le support des exceptions permet au serveur de rattraper des erreurs de l’application : la servlet se plante peut-être, mais le serveur lui survit.

Java Server Page

On a vu les avantages des servlets Java sur les CGI traditionnels, mais une servlet reste tout de même un CGI.

Cela veut dire que les critiques concernant la mauvaise lisibilité du code et sa rigidité, réduisant considérablement les possibilités d’évolutions, s’appliquent tout au tant aux servlets qu’aux CGI. A cela, Java répond JSP (Java Server Page). Une JSP est « une page HTML avec des bouts de Java dedans »…

L’idée est de décomposer la présentation, faite en HTML par des infographistes, de la programmation, faites en Java par des informaticiens, et de permettre la communication entre les deux mondes grâce à des passerelles, assurées par ces « bouts de code Java » dans la page HTML.

L’enchaînement idéal est donc :

• une page HTML propose un formulaire à l'utilisateur pour définir les critères de la requête ;
• la requête transmise au serveur est dirigée vers une servlet qui traite la demande et construit un résultat qu’elle met à la disposition du serveur ;
  • bien qu’elle soit autorisée à le faire, une servlet idéale n’est pas supposée produire du code HTML, sauf pour assurer le chaînage vers une page de présentation des résultats ;
  • mais elle dialogue avec le serveur pour obtenir les paramètres de la requête, récupérer des informations sur le demandeur, et obtenir l'état d'un précédent contexte ;
• une JSP est appelée pour mettre en page les résultats ;
• cette JSP obtient du serveur le résultat à présenter et n’utilise que le minimum de code Java pour en afficher le contenu.

Un « effet de bord » intéressant : une même JSP peut très bien présenter des résultats obtenus par des traitements (servlet) très différents : lecture d’un fichier, consultation d’une base de données, requêtes à un Web service, …

A l’inverse, les résultats fournis par une même servlet peuvent être présentés par différentes JSP.

[Note: en pratique, la JSP est convertie en une servlet par le serveur, lors de la première invocation.

C’est donc en fait du « Java avec beaucoup de HTML dedans »].

Struts

On voit que les servlets et les JSP offrent déjà tout ce qu’il faut pour un bon « design » d’un site Web dynamique.

Struts aide simplement à conserver le cap : bien isoler la présentation (JSP) du traitement (Java). Pour cela, il ajoute des facilités aussi bien pour la conception du site que pour sa réalisation.

Pour ce qui est de la présentation, Struts fournit plusieurs bibliothèques de balises spécialisées dans le dialogue avec Java. En utilisant ces balises, il est pratiquement possible de faire disparaître toute programmation Java dans la JSP.

Les principaux services offerts par ces balises spécialisées sont :

• vérifier si un objet Java (typiquement, l’objet résultat construit par la servlet) est effectivement présent, et sinon effectué un traitement particulier (appeler une page d'erreur, par exemple) ;
• accéder simplement aux attributs d’un objet complexe via un formalisme similaire à celui de HTML ;
• itérer sur une structure de liste, et accéder à chacun de ces éléments (très utile lors que le résultat de la requête doit être présenté sous la forme d’une table).

Les avantages des balises Struts sur du code Java sont :

• il n'y a plus de dépendance entre la JSP et l'objet Java utilisé pour transmettre les résultats
  • l'accès aux éléments du résultat se fait par « passage de messages » (grâce à l'introspection)
  • l'objet résultat doit juste fournir les services correspondant à ces messages – le paradigme Bean est utilisé : l'attribut invoqué doit être accessible par une méthode "get + nom d'attribut" (exemple: getEnergy( ) ) ;
• le formalisme utilisé est bien accepté par les infographistes (même s'il est un peu déroutant pour les programmeurs C++ / Java), car proche de celui de HTML ;
• ces balises pourraient être supportées par les éditeurs graphiques de sites Web.

Côté du traitement, Struts décompose les requêtes entre la validation du formulaire et le traitement proprement dit.

La validation d’un formulaire représente une part conséquente du codage, d'autant plus désagréable à écrire qu'elle est répétitive : récupérer les valeurs des champs du formulaire, vérifier si les champs obligatoires sont bien renseignés, si les dates sont bien saisies, si les champs numériques sont corrects …

Struts permet d’associer à chaque formulaire un objet Java (ActionForm) à qui il va transmettre automatiquement les valeurs saisies dans les champs, puis (en fonction d’une option de configuration) invoquée une méthode de validation.

La classe ActionForm à fournir doit respecter la convention Bean : chaque attribut publié doit être associé à une méthode « set » et à une méthode « get ». En outre, la classe doit fournir une méthode « validate ». Grâce à ces conventions, Struts automatise le transfert des champs du formulaire à l'objet Action Form (avec conversion des types numériques).

Une fois le formulaire validé, l’objet ActionForm est passé à un objet Action chargé de traiter la requête. Selon l’issue du traitement, l’Action passe le contrôle à une page de présentation ou à une page d'erreur.

La dernière des difficultés liées aux CGI, l'évolutivité du site, est prise en compte par Struts grâce à l'utilisation de « noms symboliques » dans la navigation entre les pages du site, en remplacement des URL statiques. La correspondance entre « noms symboliques » et URL est assurée dans un fichier de configuration. En cas de modification de l'organisation du site, seul ce fichier devra être modifié.

Ce fichier de configuration est également utilisé pour définir les associations entre formulaires, actions et action forms.

Grâce à cette approche modulaire, la conception du site est simplifiée car les composants mis en œuvre sont plus simples, car plus spécialisés. La mise au point est rapide.

Et les servlets

Struts n’a pas fait disparaître les servlets. Il a simplement décomposer le travail de la servlet en 3 éléments : deux propres à l’application : la vérification du formulaire (ActionForm) et le traitement (Action) ; et un réutilisable : la mise en correspondance du formulaire, de l’action form et de l’action.

C’est une servlet, fournie par Struts, qui assure cette mise en correspondance grâce au fichier de configuration.

En guise de conclusion

Struts offre des moyens efficaces pour mettre en œuvre des sites Web dynamiques performants et évolutifs en facilitant une conception favorisant la séparation entre la présentation et les traitements. Un point intéressant dans l’approche Struts est qu’il se prête bien au « maquettage ». Le site présenté aux futurs utilisateurs peut être constitué au début de pages statiques, mais ayant leur apparence finale. Pendant que les infographistes assument les affres de la guerre des boutons et des couleurs, inhérente au Web, les informaticiens mettent en place les services (Action et ActionForm) qui seront progressivement intégrés via des JSP. La maquette peut même être assez poussée en utilisant des « proto-actions » simulant les futurs résultats des requêtes.

Mais l’approche modulaire prônée par Struts a les inconvénients de ses avantages. La décomposition des requêtes en composants élémentaires (formulaire, action form, action, JSP de présentation) suppose une compréhension raisonnable du fonctionnement du site, de l’enchaînement des pages, et donc des attentes des futures utilisateurs.

Il y a donc un « niveau minimum de motivation » pour démarrer un projet avec Java et Struts. La bonne question étant de savoir si le développement envisagé devra être durable.

Entièrement en Java, Struts est immédiatement portable sur les plates-formes traditionnelles (UNIX/Linux, Windows, Mac). Il ne suppose aucune installation à priori : il suffit que les librairies Struts soient dans le répertoire « librairie » standard de l’application Web. Il est supporté tous les serveurs Web acceptant Java, comme par exemple le célèbre Tomcat, de la fondation Apache.

Liens

• Struts : ​http://struts.apache.org/
• Apache : ​http://apache.org/
• Tomcat : ​http://jakarta.apache.org/tomcat/
• Servlet : ​http://java.sun.com/products/servlet/index.jsp
• JSP : ​http://java.sun.com/products/jsp/